* RE: Badness in 2.6.15-rc1 on 8xx
From: Joakim Tjernlund @ 2005-11-28 10:52 UTC (permalink / raw)
To: Chris Down, linuxppc-embedded
=20
> -----Original Message-----
> From: Chris Down [mailto:chris@alcor.co.uk]=20
> Sent: 28 November 2005 11:01
> To: Joakim Tjernlund; linuxppc-embedded@ozlabs.org
> Subject: RE: Badness in 2.6.15-rc1 on 8xx
>=20
> From: linuxppc-embedded-bounces@ozlabs.org
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of=20
> Joakim Tjernlund
> Sent: 25 November 2005 13:28
> To: linuxppc-embedded@ozlabs.org
> Subject: Badness in 2.6.15-rc1 on 8xx
>=20
> Anyone seen this when booting 2.6.15-rc1 on 8xx?
> Mount-cache hash table entries: 512
> Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
> Call trace:
> [c00039e8] check_bug_trap+0x80/0xa8
> [c0003c1c] program_check_exception+0x20c/0x480
> [c00031e0] ret_from_except_full+0x0/0x4c
> [c01b86b8] dma_alloc_init+0x40/0xcc
> [c000225c] init+0x8c/0x288
> [c00050ac] kernel_thread+0x44/0x60
> NET: Registered protocol family 16
> The kernel boots just fine into user space so it seems harmless, but I
> suspect it will bite me later.
>=20
>=20
> I am currently working with 2.6.15-rc1 on MPC852 and I am=20
> seeing a similar
> problem.
>=20
> Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
> Call trace:
> [c00036f8] check_bug_trap+0xa4/0xb8
> [c0003f9c] program_check_exception+0x2f0/0x4c4
> [c0003320] ret_from_except_full+0x0/0x4c
> [c024c530] dma_alloc_init+0x3c/0xbc
> [c0002280] init+0xbc/0x25c
> [c000538c] kernel_thread+0x44/0x60
>=20
> Have not had time to look at it yet, however I was not getting this on
> 2.6.11.
>=20
> Chris
Let me guess you have IMAP_ADDR set to 0xff000000? Then you need to
change
CONSISTENT_START to something else(like 0xffa00000). Its somwhere in the
Advanced setup.
Jocke
^ permalink raw reply
* RE: Badness in 2.6.15-rc1 on 8xx
From: Chris Down @ 2005-11-28 10:01 UTC (permalink / raw)
To: 'Joakim Tjernlund', linuxppc-embedded
In-Reply-To: <F6AD7E21CDF4E145A44F61F43EE6D9393FE122@tmnt04.transmode.se>
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Joakim Tjernlund
Sent: 25 November 2005 13:28
To: linuxppc-embedded@ozlabs.org
Subject: Badness in 2.6.15-rc1 on 8xx
Anyone seen this when booting 2.6.15-rc1 on 8xx?
Mount-cache hash table entries: 512
Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
Call trace:
[c00039e8] check_bug_trap+0x80/0xa8
[c0003c1c] program_check_exception+0x20c/0x480
[c00031e0] ret_from_except_full+0x0/0x4c
[c01b86b8] dma_alloc_init+0x40/0xcc
[c000225c] init+0x8c/0x288
[c00050ac] kernel_thread+0x44/0x60
NET: Registered protocol family 16
The kernel boots just fine into user space so it seems harmless, but I
suspect it will bite me later.
I am currently working with 2.6.15-rc1 on MPC852 and I am seeing a similar
problem.
Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
Call trace:
[c00036f8] check_bug_trap+0xa4/0xb8
[c0003f9c] program_check_exception+0x2f0/0x4c4
[c0003320] ret_from_except_full+0x0/0x4c
[c024c530] dma_alloc_init+0x3c/0xbc
[c0002280] init+0xbc/0x25c
[c000538c] kernel_thread+0x44/0x60
Have not had time to look at it yet, however I was not getting this on
2.6.11.
Chris
^ permalink raw reply
* Re: kernel 2.6.14 on MPC8272ADS
From: Ingo Hornberger @ 2005-11-28 10:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <02AA386EB831044F8537A696BA785C7807645A@ILEX5.IL.NDS.COM>
[-- Attachment #1: Type: text/plain, Size: 760 bytes --]
Hi Bracha,
I assume that you're using an 8xx!?
This code isn't completely updated yet, but here is a small patch which
should be more or less working...
regards,
Ingo
On Sun, 2005-11-27 at 12:22 +0200, Landau, Bracha wrote:
> I'm trying to move to the latest kernel release from linux 2.6.13.4 on the MPC8272ADS board.
> 2.6.13.4 works, but from 2.6.14 and up (I don't know where from 2.6.13.4 to 2.6.14 the problem starts) the kernel crashes on bootup with the message
> "Kernel BUG in ppc_sys_init at arch/ppc/syslib/ppc_sys_init.c:131"
> Anyone know how to fix this problem?
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: ppc_8xx_2.6.14_syslib.patch --]
[-- Type: text/x-patch, Size: 2326 bytes --]
diff -Nurb a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
--- a/arch/ppc/syslib/m8xx_setup.c 2005-10-28 02:02:08.000000000 +0200
+++ b/arch/ppc/syslib/m8xx_setup.c 2005-11-25 11:11:03.000000000 +0100
@@ -82,7 +82,7 @@
ROOT_DEV = Root_HDA1; /* hda1 */
#endif
-#ifdef CONFIG_BLK_DEV_INITRD
+#if defined(CONFIG_BLK_DEV_INITRD) || defined(CONFIG_EXTRACT_ROOTFS)
#if 0
ROOT_DEV = Root_FD0; /* floppy */
rd_prompt = 1;
@@ -389,7 +389,7 @@
m8xx_setup_pci_ptrs();
#endif
-#ifdef CONFIG_BLK_DEV_INITRD
+#if defined(CONFIG_BLK_DEV_INITRD) || defined(CONFIG_EXTRACT_ROOTFS)
/* take care of initrd if we have one */
if ( r4 )
{
@@ -404,6 +404,15 @@
strcpy(cmd_line, (char *)(r6+KERNELBASE));
}
+ /*
+ * Check if we are really on a Power QUICC CPU.
+ * Note, that we do not halt the Kernel at this point,
+ * because we won't get any output here otherwise.
+ */
+ if( (mfspr(SPRN_PVR) >> 16) != 0x0050 )
+ printk( KERN_ERR "ERROR: %s: %d: Wrong CPU Type! (We assumed a Power QUICC CPU)\n" );
+ identify_ppc_sys_by_id(mfspr(SPRN_IMMR));
+
ppc_md.setup_arch = m8xx_setup_arch;
ppc_md.show_percpuinfo = m8xx_show_percpuinfo;
ppc_md.irq_canonicalize = NULL;
diff -Nurb a/arch/ppc/syslib/mpc8xx_sys.c b/arch/ppc/syslib/mpc8xx_sys.c
--- a/arch/ppc/syslib/mpc8xx_sys.c 2005-10-28 02:02:08.000000000 +0200
+++ b/arch/ppc/syslib/mpc8xx_sys.c 2005-11-25 11:11:03.000000000 +0100
@@ -20,9 +20,16 @@
struct ppc_sys_spec *cur_ppc_sys_spec;
struct ppc_sys_spec ppc_sys_specs[] = {
+ /* The mpc85x and 86x, all have the system ID 0x00.
+ * And as it seems that even the 885 has the ID 0x00,
+ * I assume 0x00 for all MPC8XX systems.
+ * For other cases, you should add a new entry above the
+ * MPC8XX. You could use the first 8 bits to make
+ * a more specific match for your system.
+ */
{
- .ppc_sys_name = "MPC86X",
- .mask = 0xFFFFFFFF,
+ .ppc_sys_name = "MPC8XX",
+ .mask = 0x00FF0000,
.value = 0x00000000,
.num_devices = 2,
.device_list = (enum ppc_sys_devices[])
^ permalink raw reply
* RE: Badness in 2.6.15-rc1 on 8xx
From: Ingo Hornberger @ 2005-11-28 10:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <TMNT04vAauNjVuMhvqg000000ab@tmnt04.transmode.se>
Hi Joakim,
I was recently faced with the same problem. It's right that it boots
fine into user land. But the bad 'consistent' start address would cause
trouble as soon as you try to initiate some dma transfer.
It is configurable under [Advanced setup].
I now use a value, seen on another 8xx board (it was some siemens board)
which was 0xf0000000. It works just fine.
As far as I understood the exact address isn't important, only that it
is unused in the kernel.
regards,
Ingo
On Fri, 2005-11-25 at 22:41 +0100, Joakim Tjernlund wrote:
> >
> > > -----Original Message-----
> > > From: linuxppc-embedded-bounces@ozlabs.org
> > > [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of
> > > Joakim Tjernlund
> > > Sent: Freitag, 25. November 2005 14:28
> > > To: linuxppc-embedded@ozlabs.org
> > > Subject: Badness in 2.6.15-rc1 on 8xx
> > >
> > > Anyone seen this when booting 2.6.15-rc1 on 8xx?
> > > Mount-cache hash table entries: 512
> > > Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
> > > Call trace:
> > > [c00039e8] check_bug_trap+0x80/0xa8
> > > [c0003c1c] program_check_exception+0x20c/0x480
> > > [c00031e0] ret_from_except_full+0x0/0x4c
> > > [c01b86b8] dma_alloc_init+0x40/0xcc
> > > [c000225c] init+0x8c/0x288
> > > [c00050ac] kernel_thread+0x44/0x60
> > > NET: Registered protocol family 16
> > > The kernel boots just fine into user space so it seems
> > > harmless, but I suspect it will bite me later.
> > >
> > > Something anoying:
> > > Why did the new cpm_uart driver change major and minor number
> > > for the tty?
> > > As it is now I can't boot my 2.4 rootfs as init think it
> > > should find the console on ttyS0.
> > > Would be great if major and minor could be configurable.
> > Because it's a new driver...with a new name (ttyCPM0) and a new
> > device number. It shared the device number and name in 2.4
> > with the "standard" device driver (8250/16550), and that made
> > it very difficult to use both in 2.4.
>
> To me it makes more sense to let a major number represent a function, not a driver.
> Shouldn't be that hard to make these drivers cooperate wrt. minor number.
>
> To allow for easy customization one could instead do:
> #ifndef SERIAL_CPM_MAJOR
> #define SERIAL_CPM_MAJOR 204
> #endif
> #ifndef SERIAL_CPM_MINOR
> #define SERIAL_CPM_MINOR 46
> #endif
>
> Each platform could then define major and minor as they like.
>
> Jocke
>
> > Maybe you should use console=ttyCPM0 in your boot parameters for 2.6.
> >
> > Regards,
> > Torsten
> > >
> > > Jocke
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* yosemite flash confusion
From: Peter Fercher @ 2005-11-28 9:59 UTC (permalink / raw)
To: 'linux-ppc-embedded'
hi,
the yosemite (revision 1.1) i got has a 512 MBit Flash chip on it
(S29GL512).
u-boot 1.1.3 that came with it was configured to use only 32 Mbytes ???
trying to use the whole size of the flashchip on the board I run into the
following problem:
when i try to use the u-boot.bin (newest from the denx homepage:
ftp://ftp.denx.de/pub/u-boot/images/amcc/yosemite/) then i get:
(reprogrammed using the yosemite.cfg that was mailed to this list some days
ago)
U-Boot 1.1.4 (Oct 24 2005 - 09:23:33)
AMCC PowerPC 440EP Rev. B
Board: Yosemite - AMCC PPC440EP Evaluation Board
VCO: 1066 MHz
CPU: 533 MHz
PLB: 133 MHz
OPB: 66 MHz
EPB: 66 MHz
PCI: 66 MHz
I2C: ready
DRAM: 256 MB
FLASH: 64 MB
*** Warning - bad CRC, using default environment
PCI: Bus Dev VenId DevId Class Int
In: serial
Out: serial
Err: serial
Net: No ethernet found.
Type "run flash_nfs" to mount root filesystem over NFS
Hit any key to stop autoboot: 0
it sees the 64MB flash but somehow can't find the ethernet anymore..
does anybody know what the problem is there ?
cheers, peter
^ permalink raw reply
* Re: [PATCH] Make ARCH=ppc build again with new syscall path
From: David Woodhouse @ 2005-11-28 10:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17290.28508.336476.478948@cargo.ozlabs.ibm.com>
On Mon, 2005-11-28 at 13:45 +1100, Paul Mackerras wrote:
> Hmmm. If we need to do this then maybe we should just get rid of the
> arch/ppc versions of the relevant files and make ARCH=ppc use the
> versions from arch/powerpc.
>
> What do people think? Do we make ARCH=ppc use more and more stuff
> from arch/powerpc, and delete the duplicates from arch/ppc, or do
> people want to be conservative and keep arch/ppc largely unchanged?
> (I would prefer the former, myself.)
I also prefer the former, in general -- it makes it easier for people to
port their platform from ppc to powerpc if we don't let the two diverge
too much.
There's also a third option, which _encourages_ people to port their
platform without necessarily making it easier: just let arch/ppc break.
I'm not sure I'd necessarily advocate that one _yet_ but maybe in the
not-so-distant future.
--
dwmw2
^ permalink raw reply
* Re: MPC8272ADS stability issues
From: Alex Zeffertt @ 2005-11-28 9:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051126052207.GA11393@gate.ebshome.net>
Thanks everybody. I was hoping to hear that others had seen this
problem and that it is probably hardware, not software.
My ADS is just about stable enough to use for development till our
custom hardware arrives, at which point - hopefully - the problems
will disappear!
Alex
^ permalink raw reply
* porting linux ppc on custom board, stuck in timer loop ?
From: David H. Lynch Jr. @ 2005-11-28 6:48 UTC (permalink / raw)
To: grave, linuxppc-embedded
Xavier;
I am having/had the exact same problem on a Xilinx VI based system and 2.6.12-2.6.14.2
I was eventually able to resolve it by removing MSR_ME from MSR_KERNEL. After that I have been able to successfully boot through to
starting init where I am hanging now. I beleive I do not have a working timer and that may be related to the problem with Machine Check Exceptions.
Were you ever able to resolve your problem aside from switching to 2.4.20, and if so what solution did you come up with ?
>Hi !
>I still try to port linux ppc on our ppc405 based hardware, after a look
>at xilinx_ml300.c file that gives the list of function calls I wait for
>a call to start_kernel but I found that start_kernel is never reached...
>In fact the code in head_4xx.S jumps to 0x00001000 which is Decrementer
>exception :
>/* Now turn on the MMU for real! */
> lis r4,MSR_KERNEL at h <https://ozlabs.org/mailman/listinfo/linuxppc-dev>
> ori r4,r4,MSR_KERNEL at l <https://ozlabs.org/mailman/listinfo/linuxppc-dev>
> lis r3,start_kernel at h <https://ozlabs.org/mailman/listinfo/linuxppc-dev>
> ori r3,r3,start_kernel at l <https://ozlabs.org/mailman/listinfo/linuxppc-dev>
> mtspr SPRN_SRR0,r3
> mtspr SPRN_SRR1,r4
> rfi /* enable MMU and jump to start_kernel */
> b . /* prevent prefetch past rfi */
>Is this my hardware implementation that is incorrect ? Or I missed
>something in my kernel configuration ?
>Thanks in advance for any answer...
>xavier
^ permalink raw reply
* Re: [PATCH] Make ARCH=ppc build again with new syscall path
From: Eugene Surovegin @ 2005-11-28 5:02 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, David Woodhouse
In-Reply-To: <17290.28508.336476.478948@cargo.ozlabs.ibm.com>
On Mon, Nov 28, 2005 at 01:45:48PM +1100, Paul Mackerras wrote:
>
> What do people think? Do we make ARCH=ppc use more and more stuff
> from arch/powerpc, and delete the duplicates from arch/ppc, or do
> people want to be conservative and keep arch/ppc largely unchanged?
> (I would prefer the former, myself.)
I thought initial idea was to keep arch/ppc mostly unchanged (we are in
"stable" series after all :), and migrate code to arch/powerpc when
it's ready.
Personally, the amount of PPC/PPC64 changes in 2.6 make me nervous,
looks like I'll stick with 2.4 longer than I thought for production.
--
Eugene
^ permalink raw reply
* 8248 Reboot Puzzle
From: Sam Song @ 2005-11-28 3:21 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I met a reboot puzzle those days. Nearly every boards
of 20 samples had a symptom
that after issuing a reboot command in Linux land more
than 10 times or so, the
target would encounter some unexpections like hang
after kernel uncompresing or
reset the target when initializing USB[VT6212L] 1.1
host controller. But I never
see any problem if cycle power. Then I have to switch
for a replacement method.
In 8248 restart function, use a GPIO to pull LOW
POWER_RESET# to get a similar
result and it did solve the problem. Well, if I use
the GPIO to pull LOW
HARD_RESET#, problems still existed. I use 2.4.31
kernel.
So I wonder what the problem could be according to
your experience. Can we get
the same result with software as POWER_RESET does? I
also want to know more on the
difference among software reboot and Power On reset
and Hard reset. I mean the
possibble effect on target running or initialization.
What I wanna to implement is a software power off and
on operation.
Power-on -> waitting for power button pushing in
u-boot -> boot the target
-> power off the target in Linux land by pushing the
power button
-> back to u-boot in a software power off state for
next power button pressing
-> ...
Thanks in advance for any comments/suggestion,
Sam
___________________________________________________________
雅虎免费G邮箱－中国第一绝无垃圾邮件骚扰超大邮箱
http://cn.mail.yahoo.com
^ permalink raw reply
* Re: CPU off power consumption
From: Benjamin Herrenschmidt @ 2005-11-28 2:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: LinuxPPC-dev
In-Reply-To: <17290.26688.710369.613144@cargo.ozlabs.ibm.com>
On Mon, 2005-11-28 at 13:15 +1100, Paul Mackerras wrote:
> Giuliano Pochini writes:
>
> > Out of curiosity, what's the difference between a cpu that has never been
> > enabled and one that has been disabled with echo 0>/sys/.../online ? It
> > happens that when I boot with maxcpus=0 the temperature always stays low
> > enoung that the fan never spins up. If I enable and then I immediately
> > disable the 2nd cpu, the temperature goes a few degrees up. I have a dual
> > G4-MDD.
>
> Interesting. A cpu that has been disabled will be in sleep mode with
> interrupts disabled and its caches flushed. One that has never been
> started may possibly be held in the reset state. The way to check
> would be to check the state of the GPIO register that controls the
> soft reset line of the second CPU.
No, I think CPUs that have not been started are held in a similar sleep
loop in ROM. I don't see right away why there would be any power
consumption difference unless some bug causing us to never actually call
the sleep loop ....
Ben.
^ permalink raw reply
* Re: [PATCH] Make ARCH=ppc build again with new syscall path
From: Paul Mackerras @ 2005-11-28 2:45 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1133016287.4044.65.camel@baythorne.infradead.org>
David Woodhouse writes:
> This makes ARCH=ppc build in your powerpc tree again, with the new
> syscall entry/exit path.
Hmmm. If we need to do this then maybe we should just get rid of the
arch/ppc versions of the relevant files and make ARCH=ppc use the
versions from arch/powerpc.
What do people think? Do we make ARCH=ppc use more and more stuff
from arch/powerpc, and delete the duplicates from arch/ppc, or do
people want to be conservative and keep arch/ppc largely unchanged?
(I would prefer the former, myself.)
Paul.
^ permalink raw reply
* Re: CPU off power consumption
From: Paul Mackerras @ 2005-11-28 2:15 UTC (permalink / raw)
To: Giuliano Pochini; +Cc: LinuxPPC-dev
In-Reply-To: <20051126113805.709ee538.pochini@shiny.it>
Giuliano Pochini writes:
> Out of curiosity, what's the difference between a cpu that has never been
> enabled and one that has been disabled with echo 0>/sys/.../online ? It
> happens that when I boot with maxcpus=0 the temperature always stays low
> enoung that the fan never spins up. If I enable and then I immediately
> disable the 2nd cpu, the temperature goes a few degrees up. I have a dual
> G4-MDD.
Interesting. A cpu that has been disabled will be in sleep mode with
interrupts disabled and its caches flushed. One that has never been
started may possibly be held in the reset state. The way to check
would be to check the state of the GPIO register that controls the
soft reset line of the second CPU.
Paul.
^ permalink raw reply
* [PATCH] powerpc: More serial probing fixes
From: Benjamin Herrenschmidt @ 2005-11-28 0:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, linuxppc-dev list
Serial port detection code at boot needs a few more fixes, especially
to deal with MMIO based ports. Here they are. An additional patch to
the serial core is needed for a boot-time MMIO port to not conflict
with 8250_pci.c, that patch is reviewed separately by Russell King.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-serialfix/arch/powerpc/kernel/legacy_serial.c
===================================================================
--- linux-serialfix.orig/arch/powerpc/kernel/legacy_serial.c 2005-11-28 11:18:08.000000000 +1100
+++ linux-serialfix/arch/powerpc/kernel/legacy_serial.c 2005-11-28 11:24:20.000000000 +1100
@@ -38,12 +38,15 @@ static int __init add_legacy_port(struct
int iotype, phys_addr_t base,
phys_addr_t taddr, unsigned long irq)
{
- u32 *clk, *spd, clock;
+ u32 *clk, *spd, clock = 0;
int index;
/* get clock freq. if present */
clk = (u32 *)get_property(np, "clock-frequency", NULL);
- clock = clk ? *clk : BASE_BAUD * 16;
+ if (clk)
+ clock = *clk;
+ if (clock == 0)
+ clock = BASE_BAUD * 16;
/* get default speed if present */
spd = (u32 *)get_property(np, "current-speed", NULL);
@@ -85,7 +88,7 @@ static int __init add_legacy_port(struct
if (iotype == UPIO_PORT)
legacy_serial_ports[index].iobase = base;
else
- legacy_serial_ports[index].membase = (void __iomem *)base;
+ legacy_serial_ports[index].mapbase = base;
legacy_serial_ports[index].iotype = iotype;
legacy_serial_ports[index].uartclk = clock;
legacy_serial_ports[index].irq = irq;
@@ -145,17 +148,17 @@ static int __init add_legacy_pci_port(st
{
phys_addr_t addr, base;
u32 *addrp;
- int iotype, index = -1;
+ int iotype, index = -1, lindex = 0;
-#if 0
/* We only support ports that have a clock frequency properly
* encoded in the device-tree (that is have an fcode). Anything
* else can't be used that early and will be normally probed by
- * the generic 8250_pci driver later on.
+ * the generic 8250_pci driver later on. The reason is that 8250
+ * compatible UARTs on PCI need all sort of quirks (port offsets
+ * etc...) that this code doesn't know about
*/
if (get_property(np, "clock-frequency", NULL) == NULL)
return -1;
-#endif
/* Get the PCI address. Assume BAR 0 */
addrp = of_get_pci_address(pci_dev, 0, NULL);
@@ -180,7 +183,23 @@ static int __init add_legacy_pci_port(st
if (np != pci_dev) {
u32 *reg = (u32 *)get_property(np, "reg", NULL);
if (reg && (*reg < 4))
- index = legacy_serial_count + *reg;
+ index = lindex = *reg;
+ }
+
+ /* Local index means it's the Nth port in the PCI chip. Unfortunately
+ * the offset to add here is device specific. We know about those
+ * EXAR ports and we default to the most common case. If your UART
+ * doesn't work for these settings, you'll have to add your own special
+ * cases here
+ */
+ if (device_is_compatible(np, "pci13a8,152") ||
+ device_is_compatible(np, "pci13a8,154") ||
+ device_is_compatible(np, "pci13a8,158")) {
+ addrp += 0x200 * lindex;
+ base += 0x200 * lindex;
+ } else {
+ addrp += 8 * lindex;
+ base += 8 * lindex;
}
/* Add port, irq will be dealt with later. We passed a translated
@@ -261,7 +280,6 @@ void __init find_legacy_serial_ports(voi
DBG("legacy_serial_console = %d\n", legacy_serial_console);
/* udbg is 64 bits only for now, that will change soon though ... */
-#ifdef CONFIG_PPC64
while (legacy_serial_console >= 0) {
struct legacy_serial_info *info =
&legacy_serial_infos[legacy_serial_console];
@@ -278,7 +296,6 @@ void __init find_legacy_serial_ports(voi
udbg_init_uart(addr, info->speed, info->clock);
break;
}
-#endif /* CONFIG_PPC64 */
DBG(" <- find_legacy_serial_port()\n");
}
@@ -340,6 +357,15 @@ static void __init fixup_port_pio(int in
}
}
+static void __init fixup_port_mmio(int index,
+ struct device_node *np,
+ struct plat_serial8250_port *port)
+{
+ DBG("fixup_port_mmio(%d)\n", index);
+
+ port->membase = ioremap(port->mapbase, 0x100);
+}
+
/*
* This is called as an arch initcall, hopefully before the PCI bus is
* probed and/or the 8250 driver loaded since we need to register our
@@ -374,6 +400,8 @@ static int __init serial_dev_init(void)
fixup_port_irq(i, np, port);
if (port->iotype == UPIO_PORT)
fixup_port_pio(i, np, port);
+ if (port->iotype == UPIO_MEM)
+ fixup_port_mmio(i, np, port);
}
DBG("Registering platform serial ports\n");
^ permalink raw reply
* kernel 2.6.14 on MPC8272ADS
From: Landau, Bracha @ 2005-11-27 10:22 UTC (permalink / raw)
To: linuxppc-embedded
I'm trying to move to the latest kernel release from linux 2.6.13.4 on =
the MPC8272ADS board.
2.6.13.4 works, but from 2.6.14 and up (I don't know where from 2.6.13.4 =
to 2.6.14 the problem starts) the kernel crashes on bootup with the =
message=20
"Kernel BUG in ppc_sys_init at arch/ppc/syslib/ppc_sys_init.c:131"
Anyone know how to fix this problem?
^ permalink raw reply
* Re: Is there some articles discussing how to change bare-board code to linux driver?
From: David H. Lynch Jr. @ 2005-11-27 1:53 UTC (permalink / raw)
To: zengshuai; +Cc: Linuxppc-embedded
In-Reply-To: <13329014.1132900964930.JavaMail.postfix@mx3.mail.sohu.com>
zengshuai@sogou.com wrote:
> Where can i find them?thanks.
>
http://lwn.net/Kernel/LDD3/
also Googling works.
> ------------------------------
> 我现在使用Sogou.com的2G邮箱了，你也来试试吧!
> http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitation&s_EMAIL=zengshuai%40sogou.com&username=Linuxppc-embedded&FullName=Linuxppc-embedded&Email=Linuxppc-embedded%40ozlabs.org&verify=777667b18eda2b5dd1bbd47542afad9b
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* [PATCH] Make ARCH=ppc build again with new syscall path
From: David Woodhouse @ 2005-11-26 14:44 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
This makes ARCH=ppc build in your powerpc tree again, with the new
syscall entry/exit path.
Still doesn't actually boot on my Pegasos; the last thing I see is
'MMU:exit'. But at least it builds -- I'll look at why it doesn't boot
later, so that I can see if the mv643xx_eth actually works with ARCH=ppc
(it doesn't with ARCH=powerpc; two in every three packets I receive are
offset by 4 bytes).
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/arch/ppc/kernel/asm-offsets.c b/arch/ppc/kernel/asm-offsets.c
index fe0e767..7964bf6 100644
--- a/arch/ppc/kernel/asm-offsets.c
+++ b/arch/ppc/kernel/asm-offsets.c
@@ -131,7 +131,7 @@ main(void)
DEFINE(CPU_SPEC_FEATURES, offsetof(struct cpu_spec, cpu_features));
DEFINE(CPU_SPEC_SETUP, offsetof(struct cpu_spec, cpu_setup));
- DEFINE(TI_SC_NOERR, offsetof(struct thread_info, syscall_noerror));
+ DEFINE(TI_SIGFRAME, offsetof(struct thread_info, nvgprs_frame));
DEFINE(TI_TASK, offsetof(struct thread_info, task));
DEFINE(TI_EXECDOMAIN, offsetof(struct thread_info, exec_domain));
DEFINE(TI_FLAGS, offsetof(struct thread_info, flags));
diff --git a/arch/ppc/kernel/entry.S b/arch/ppc/kernel/entry.S
index f044edb..a48b950 100644
--- a/arch/ppc/kernel/entry.S
+++ b/arch/ppc/kernel/entry.S
@@ -200,8 +200,6 @@ _GLOBAL(DoSyscall)
bl do_show_syscall
#endif /* SHOW_SYSCALLS */
rlwinm r10,r1,0,0,18 /* current_thread_info() */
- li r11,0
- stb r11,TI_SC_NOERR(r10)
lwz r11,TI_FLAGS(r10)
andi. r11,r11,_TIF_SYSCALL_T_OR_A
bne- syscall_dotrace
@@ -222,25 +220,21 @@ ret_from_syscall:
bl do_show_syscall_exit
#endif
mr r6,r3
- li r11,-_LAST_ERRNO
- cmplw 0,r3,r11
rlwinm r12,r1,0,0,18 /* current_thread_info() */
- blt+ 30f
- lbz r11,TI_SC_NOERR(r12)
- cmpwi r11,0
- bne 30f
- neg r3,r3
- lwz r10,_CCR(r1) /* Set SO bit in CR */
- oris r10,r10,0x1000
- stw r10,_CCR(r1)
-
/* disable interrupts so current_thread_info()->flags can't change */
-30: LOAD_MSR_KERNEL(r10,MSR_KERNEL) /* doesn't include MSR_EE */
+ LOAD_MSR_KERNEL(r10,MSR_KERNEL) /* doesn't include MSR_EE */
SYNC
MTMSRD(r10)
lwz r9,TI_FLAGS(r12)
- andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SIGPENDING|_TIF_NEED_RESCHED)
+ li r8,-_LAST_ERRNO
+ andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SIGPENDING|_TIF_NEED_RESCHED|_TIF_RESTOREALL)
bne- syscall_exit_work
+ cmplw 0,r3,r8
+ blt+ syscall_exit_cont
+ lwz r11,_CCR(r1) /* Load CR */
+ neg r3,r3
+ oris r11,r11,0x1000 /* Set SO bit in CR */
+ stw r11,_CCR(r1)
syscall_exit_cont:
#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
/* If the process has its own DBCR0 value, load it up. The single
@@ -292,46 +286,113 @@ syscall_dotrace:
b syscall_dotrace_cont
syscall_exit_work:
- stw r6,RESULT(r1) /* Save result */
+ andi. r0,r9,_TIF_RESTOREALL
+ bne- 2f
+ cmplw 0,r3,r8
+ blt+ 1f
+ andi. r0,r9,_TIF_NOERROR
+ bne- 1f
+ lwz r11,_CCR(r1) /* Load CR */
+ neg r3,r3
+ oris r11,r11,0x1000 /* Set SO bit in CR */
+ stw r11,_CCR(r1)
+
+1: stw r6,RESULT(r1) /* Save result */
stw r3,GPR3(r1) /* Update return value */
- andi. r0,r9,_TIF_SYSCALL_T_OR_A
- beq 5f
- ori r10,r10,MSR_EE
- SYNC
- MTMSRD(r10) /* re-enable interrupts */
+2: andi. r0,r9,(_TIF_PERSYSCALL_MASK)
+ beq 4f
+
+ /* Clear per-syscall TIF flags if any are set, but _leave_
+ _TIF_SAVE_NVGPRS set in r9 since we haven't dealt with that
+ yet. */
+
+ li r11,_TIF_PERSYSCALL_MASK
+ addi r12,r12,TI_FLAGS
+3: lwarx r8,0,r12
+ andc r8,r8,r11
+#ifdef CONFIG_IBM405_ERR77
+ dcbt 0,r12
+#endif
+ stwcx. r8,0,r12
+ bne- 3b
+ subi r12,r12,TI_FLAGS
+
+4: /* Anything which requires enabling interrupts? */
+ andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP|_TIF_SAVE_NVGPRS)
+ beq 7f
+
+ /* Save NVGPRS if they're not saved already */
lwz r4,TRAP(r1)
andi. r4,r4,1
- beq 4f
+ beq 5f
SAVE_NVGPRS(r1)
li r4,0xc00
stw r4,TRAP(r1)
-4:
+
+ /* Re-enable interrupts */
+5: ori r10,r10,MSR_EE
+ SYNC
+ MTMSRD(r10)
+
+ andi. r0,r9,_TIF_SAVE_NVGPRS
+ bne save_user_nvgprs
+
+save_user_nvgprs_cont:
+ andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP)
+ beq 7f
+
addi r3,r1,STACK_FRAME_OVERHEAD
bl do_syscall_trace_leave
REST_NVGPRS(r1)
-2:
- lwz r3,GPR3(r1)
+
+6: lwz r3,GPR3(r1)
LOAD_MSR_KERNEL(r10,MSR_KERNEL) /* doesn't include MSR_EE */
SYNC
MTMSRD(r10) /* disable interrupts again */
rlwinm r12,r1,0,0,18 /* current_thread_info() */
lwz r9,TI_FLAGS(r12)
-5:
+7:
andi. r0,r9,_TIF_NEED_RESCHED
- bne 1f
+ bne 8f
lwz r5,_MSR(r1)
andi. r5,r5,MSR_PR
- beq syscall_exit_cont
+ beq ret_from_except
andi. r0,r9,_TIF_SIGPENDING
- beq syscall_exit_cont
+ beq ret_from_except
b do_user_signal
-1:
+8:
ori r10,r10,MSR_EE
SYNC
MTMSRD(r10) /* re-enable interrupts */
bl schedule
- b 2b
+ b 6b
+
+save_user_nvgprs:
+ lwz r8,TI_SIGFRAME(r12)
+
+.macro savewords start, end
+ 1: stw \start,4*(\start)(r8)
+ .section __ex_table,"a"
+ .align 2
+ .long 1b,save_user_nvgprs_fault
+ .previous
+ .if \end - \start
+ savewords "(\start+1)",\end
+ .endif
+.endm
+ savewords 14,31
+ b save_user_nvgprs_cont
+
+
+save_user_nvgprs_fault:
+ li r3,11 /* SIGSEGV */
+ lwz r4,TI_TASK(r12)
+ bl force_sigsegv
+ rlwinm r12,r1,0,0,18 /* current_thread_info() */
+ lwz r9,TI_FLAGS(r12)
+ b save_user_nvgprs_cont
+
#ifdef SHOW_SYSCALLS
do_show_syscall:
#ifdef SHOW_SYSCALLS_TASK
@@ -401,28 +462,10 @@ show_syscalls_task:
#endif /* SHOW_SYSCALLS */
/*
- * The sigsuspend and rt_sigsuspend system calls can call do_signal
- * and thus put the process into the stopped state where we might
- * want to examine its user state with ptrace. Therefore we need
- * to save all the nonvolatile registers (r13 - r31) before calling
- * the C code.
+ * The fork/clone functions need to copy the full register set into
+ * the child process. Therefore we need to save all the nonvolatile
+ * registers (r13 - r31) before calling the C code.
*/
- .globl ppc_sigsuspend
-ppc_sigsuspend:
- SAVE_NVGPRS(r1)
- lwz r0,TRAP(r1)
- rlwinm r0,r0,0,0,30 /* clear LSB to indicate full */
- stw r0,TRAP(r1) /* register set saved */
- b sys_sigsuspend
-
- .globl ppc_rt_sigsuspend
-ppc_rt_sigsuspend:
- SAVE_NVGPRS(r1)
- lwz r0,TRAP(r1)
- rlwinm r0,r0,0,0,30
- stw r0,TRAP(r1)
- b sys_rt_sigsuspend
-
.globl ppc_fork
ppc_fork:
SAVE_NVGPRS(r1)
@@ -447,14 +490,6 @@ ppc_clone:
stw r0,TRAP(r1) /* register set saved */
b sys_clone
- .globl ppc_swapcontext
-ppc_swapcontext:
- SAVE_NVGPRS(r1)
- lwz r0,TRAP(r1)
- rlwinm r0,r0,0,0,30 /* clear LSB to indicate full */
- stw r0,TRAP(r1) /* register set saved */
- b sys_swapcontext
-
/*
* Top-level page fault handling.
* This is in assembler because if do_page_fault tells us that
@@ -626,16 +661,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_601)
.long ret_from_except
#endif
- .globl sigreturn_exit
-sigreturn_exit:
- subi r1,r3,STACK_FRAME_OVERHEAD
- rlwinm r12,r1,0,0,18 /* current_thread_info() */
- lwz r9,TI_FLAGS(r12)
- andi. r0,r9,_TIF_SYSCALL_T_OR_A
- beq+ ret_from_except_full
- bl do_syscall_trace_leave
- /* fall through */
-
.globl ret_from_except_full
ret_from_except_full:
REST_NVGPRS(r1)
@@ -658,7 +683,7 @@ user_exc_return: /* r10 contains MSR_KE
/* Check current_thread_info()->flags */
rlwinm r9,r1,0,0,18
lwz r9,TI_FLAGS(r9)
- andi. r0,r9,(_TIF_SIGPENDING|_TIF_NEED_RESCHED)
+ andi. r0,r9,(_TIF_SIGPENDING|_TIF_NEED_RESCHED|_TIF_RESTOREALL)
bne do_work
restore_user:
diff --git a/arch/ppc/kernel/misc.S b/arch/ppc/kernel/misc.S
index 5e61124..fb5658b 100644
--- a/arch/ppc/kernel/misc.S
+++ b/arch/ppc/kernel/misc.S
@@ -1197,7 +1197,7 @@ _GLOBAL(sys_call_table)
.long sys_ssetmask
.long sys_setreuid /* 70 */
.long sys_setregid
- .long ppc_sigsuspend
+ .long sys_sigsuspend
.long sys_sigpending
.long sys_sethostname
.long sys_setrlimit /* 75 */
@@ -1303,7 +1303,7 @@ _GLOBAL(sys_call_table)
.long sys_rt_sigpending /* 175 */
.long sys_rt_sigtimedwait
.long sys_rt_sigqueueinfo
- .long ppc_rt_sigsuspend
+ .long sys_rt_sigsuspend
.long sys_pread64
.long sys_pwrite64 /* 180 */
.long sys_chown
@@ -1374,7 +1374,7 @@ _GLOBAL(sys_call_table)
.long sys_clock_gettime
.long sys_clock_getres
.long sys_clock_nanosleep
- .long ppc_swapcontext
+ .long sys_swapcontext
.long sys_tgkill /* 250 */
.long sys_utimes
.long sys_statfs64
--
dwmw2
^ permalink raw reply related
* CPU off power consumption
From: Giuliano Pochini @ 2005-11-26 11:38 UTC (permalink / raw)
To: LinuxPPC-dev
Out of curiosity, what's the difference between a cpu that has never been
enabled and one that has been disabled with echo 0>/sys/.../online ? It
happens that when I boot with maxcpus=0 the temperature always stays low
enoung that the fan never spins up. If I enable and then I immediately
disable the 2nd cpu, the temperature goes a few degrees up. I have a dual
G4-MDD.
--
Giuliano.
^ permalink raw reply
* Re: MPC8272ADS stability issues
From: Eugene Surovegin @ 2005-11-26 5:22 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <438732FD.7090201@ru.mvista.com>
On Fri, Nov 25, 2005 at 06:51:25PM +0300, Vitaly Bordug wrote:
> Unfortunately, low stability occasionally follows this boards. I have the
> same symptoms, and it is relative to something wrong with memory.
Yeah, I wasn't able to do any development on my 8272ADS due to
the same stability problems. Sometimes I wonder how Freescale can even
ship hw of such "quality".
--
Eugene
^ permalink raw reply
* Re: MPC8272ADS stability issues
From: Walter L. Wimer III @ 2005-11-26 4:46 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <438732FD.7090201@ru.mvista.com>
Hi Alex,
We've had increasing difficulty with our MPC8272ADS board as well. It
will often hang or reboot while just sitting at the U-Boot prompt, or
while running Linux. I've pretty much given up trying to use our board.
One of these days we'll get around to shipping it back to Freescale....
In a perverse sort of way, I'm glad I'm not the only one seeing this
problem, but it's unfortunate that any of us are...
Walt
On Fri, 2005-11-25 at 18:51 +0300, Vitaly Bordug wrote:
> Alex Zeffertt wrote:
> > I am using an MPC8272ADS development board. I was wondering if
> > anybody on this list experienced hardware reliability problems with
> > this platform.
> >
> Unfortunately, low stability occasionally follows this boards. I have
> the same symptoms, and it is relative to something wrong with memory.
^ permalink raw reply
* RE: Badness in 2.6.15-rc1 on 8xx
From: Joakim Tjernlund @ 2005-11-25 21:41 UTC (permalink / raw)
To: 'Demke Torsten-atd012', linuxppc-embedded
>
> > -----Original Message-----
> > From: linuxppc-embedded-bounces@ozlabs.org
> > [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of
> > Joakim Tjernlund
> > Sent: Freitag, 25. November 2005 14:28
> > To: linuxppc-embedded@ozlabs.org
> > Subject: Badness in 2.6.15-rc1 on 8xx
> >
> > Anyone seen this when booting 2.6.15-rc1 on 8xx?
> > Mount-cache hash table entries: 512
> > Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
> > Call trace:
> > [c00039e8] check_bug_trap+0x80/0xa8
> > [c0003c1c] program_check_exception+0x20c/0x480
> > [c00031e0] ret_from_except_full+0x0/0x4c
> > [c01b86b8] dma_alloc_init+0x40/0xcc
> > [c000225c] init+0x8c/0x288
> > [c00050ac] kernel_thread+0x44/0x60
> > NET: Registered protocol family 16
> > The kernel boots just fine into user space so it seems
> > harmless, but I suspect it will bite me later.
> >
> > Something anoying:
> > Why did the new cpm_uart driver change major and minor number
> > for the tty?
> > As it is now I can't boot my 2.4 rootfs as init think it
> > should find the console on ttyS0.
> > Would be great if major and minor could be configurable.
> Because it's a new driver...with a new name (ttyCPM0) and a new
> device number. It shared the device number and name in 2.4
> with the "standard" device driver (8250/16550), and that made
> it very difficult to use both in 2.4.
To me it makes more sense to let a major number represent a function, not a driver.
Shouldn't be that hard to make these drivers cooperate wrt. minor number.
To allow for easy customization one could instead do:
#ifndef SERIAL_CPM_MAJOR
#define SERIAL_CPM_MAJOR 204
#endif
#ifndef SERIAL_CPM_MINOR
#define SERIAL_CPM_MINOR 46
#endif
Each platform could then define major and minor as they like.
Jocke
> Maybe you should use console=ttyCPM0 in your boot parameters for 2.6.
>
> Regards,
> Torsten
> >
> > Jocke
^ permalink raw reply
* Re: [PATCH] cpm_uart: fix xchar sending
From: Marcelo Tosatti @ 2005-11-25 11:32 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho; +Cc: linuxppc-embedded
In-Reply-To: <20051125143851.GJ7163@cathedrallabs.org>
On Fri, Nov 25, 2005 at 12:38:51PM -0200, 'Aristeu Sergio Rozanski Filho' wrote:
> Hi,
> while using SCC as uart and as serial console at same time I got this:
>
> [ 138.214258] Oops: kernel access of bad area, sig: 11 [#1]
> [ 138.218832] PREEMPT
> [ 138.221021] NIP: C0105C48 LR: C0105E60 SP: C03D5D10 REGS: c03d5c60 TRAP: 0300 Not tainted
> [ 138.229280] MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
> [ 138.234713] DAR: 00000000, DSISR: C0000000
> [ 138.238745] TASK = c0349420[693] 'sh' THREAD: c03d4000
> [ 138.243754] Last syscall: 6
> [ 138.246402] GPR00: FEFFFFFF C03D5D10 C0349420 C01FB094 00000011 00000000 C1ECFBBC C01F24B0
> [ 138.254602] GPR08: FF002820 00000000 FF0028C0 00000000 19133615 A0CBCD5E 02000300 00000000
> [ 138.262804] GPR16: 00000000 01FF9E4C 00000000 7FA9A770 00000000 00000000 1003E2A8 00000000
> [ 138.271003] GPR24: 100562F4 7F9B6EF4 C0210000 C02A5338 C01FB094 00000000 C01FB094 C1F14574
> [ 138.279376] NIP [c0105c48] cpm_uart_tx_pump+0x4c/0x22c
> [ 138.284419] LR [c0105e60] cpm_uart_start_tx+0x38/0xb0
> [ 138.289361] Call trace:
> [ 138.291762] [c0105e60] cpm_uart_start_tx+0x38/0xb0
> [ 138.296547] [c010277c] uart_send_xchar+0x88/0x118
> [ 138.301244] [c01029a0] uart_unthrottle+0x6c/0x138
> [ 138.305942] [c00ece10] check_unthrottle+0x60/0x64
> [ 138.310641] [c00ecec4] reset_buffer_flags+0xb0/0x138
> [ 138.315595] [c00ecf64] n_tty_flush_buffer+0x18/0x78
> [ 138.320465] [c00e81b0] tty_ldisc_flush+0x64/0x7c
> [ 138.325078] [c010410c] uart_close+0xf0/0x2c8
> [ 138.329348] [c00e9c48] release_dev+0x724/0x8d4
> [ 138.333790] [c00e9e18] tty_release+0x20/0x3c
> [ 138.338061] [c006e544] __fput+0x178/0x1e0
> [ 138.342076] [c006c43c] filp_close+0x54/0xac
> [ 138.346261] [c0002d90] ret_from_syscall+0x0/0x44
> [ 138.352386] note: sh[693] exited with preempt_count 2
>
> a easy way to reproduce it is log into the system using ssh and do:
> cat >/dev/ttyCPM0
> then, switch to minicom and write some stuff on it back to ssh, a control C
> produce the oops
>
> this happens because uart_close calls uart_shutdown which frees xmit.buf,
> currently used by xchar sending in cpm_uart_tx_pump(), which seems wrong.
>
> the attached patch fixes the oops and also fixes xchar sending.
Looks good to me.
^ permalink raw reply
* Re: MPC8272ADS stability issues
From: Vitaly Bordug @ 2005-11-25 15:51 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <20051125153126.0385ddef.ajz@cambridgebroadband.com>
Alex Zeffertt wrote:
> Hi all,
>
> I have a question that is a bit off topic here, but you seem the most
> knowledgable people to ask so please don't flame me... :)
>
> I am using an MPC8272ADS development board. I was wondering if
> anybody on this list experienced hardware reliability problems with
> this platform.
>
> I am running ELDK 3.1.1. I have seen the kernel hang several times,
> and a Oops a few times too. The reason I suspect that this is a
> hardware problem is that these seem to happen at completely random
> times, and the Oopses, in random places. It doesn't seem to make
> any difference whether I have any of my own modules loaded or not, and
> I've even seen these problems occur in the bootloader.
>
> I'm hoping for an answer along the lines of "Ah, you must have the
> 'fail randomly' dip switch set!"
>
Unfortunately, low stability occasionally follows this boards. I have the same symptoms,
and it is relative to something wrong with memory.
The mtest utility run in U-Boot will follow to crash or hang sooner or later. Hence its
either broken memory or some hidden setting (probably undocumented) that the bootloader
forgot to tweak in the time of memory controller init.
That question has been forwarded to FS, but still no response from them in this regard.
All I can suggest is to replace the board if it crashes more frequently than
debug/development could proceed.
> TIA,
>
> Alex
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] MTD: Add support for the PM82x Boards.
From: Clemens Koller @ 2005-11-25 15:06 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev, tglx, dwmw2, linux-mtd
In-Reply-To: <AHEILKONAKAEJPHNMOPNKEMMCDAA.hs@denx.de>
Hello, Heiko!
> i made the changes in the code you suggested to me.
>
> Additional changes:
> - I now use the CFI interface (I tested it, and it seems OK
> to me)
Datasheets should confirm the same.
Just in case you do the PM854 support anytime soon,
the i128J3C150 Flash supports CFI, too, which makes
these things also pretty simple.
Best greets,
--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* MPC8272ADS stability issues
From: Alex Zeffertt @ 2005-11-25 15:31 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I have a question that is a bit off topic here, but you seem the most
knowledgable people to ask so please don't flame me... :)
I am using an MPC8272ADS development board. I was wondering if
anybody on this list experienced hardware reliability problems with
this platform.
I am running ELDK 3.1.1. I have seen the kernel hang several times,
and a Oops a few times too. The reason I suspect that this is a
hardware problem is that these seem to happen at completely random
times, and the Oopses, in random places. It doesn't seem to make
any difference whether I have any of my own modules loaded or not, and
I've even seen these problems occur in the bootloader.
I'm hoping for an answer along the lines of "Ah, you must have the
'fail randomly' dip switch set!"
TIA,
Alex
^ 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