On Tue, Jul 5, 2011 at 3:58 PM, Matthew L. Creech wrote:
>
> Separately, I set up 2 test devices to run while I was away last week.
> One of them contained 2 patches:
>
> - Mike Hench's patch which eliminates this block of code in fsl_elbc_nand.c
> - Adam
(and potentially problematic)
block of code.
v2: elbc_fcm_ctrl->oob_poi is removed entirely, since this code block was the
only place it was actually used.
v3: local 'full_page' variable is no longer used either.
Signed-off-by: Matthew L. Creech
---
drivers/mtd/nand/fsl_elbc_
On Tue, Jul 5, 2011 at 7:01 PM, Scott Wood wrote:
>
> Just noticed, full_page can come out as well.
>
> Otherwise, ACK
>
Oh right, didn't notice that - thanks.
--
Matthew L. Creech
___
Linuxppc-dev mailing list
Linuxppc-dev@li
(and potentially problematic)
block of code.
v2: elbc_fcm_ctrl->oob_poi is removed entirely, since this code block was the
only place it was actually used.
Signed-off-by: Matthew L. Creech
---
drivers/mtd/nand/fsl_elbc_nand.c | 25 -
1 files changed, 0 insertions(+),
(and potentially problematic)
block of code.
Signed-off-by: Matthew L. Creech
---
drivers/mtd/nand/fsl_elbc_nand.c | 17 -
1 files changed, 0 insertions(+), 17 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 0bb254c..050a2fc
w days), but it
seems like removing that block of code in fsl_elbc_nand.c is a good
idea.
--
Matthew L. Creech
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
still there, and one with it
removed. If the former device sees bit-flips in the BBT and the
latter one doesn't, we'll be sure of the culprit. I'll try this and
come back with the results.
Thanks!
--
Matthew L. Creech
___
Linuxppc-
BBT
was written to NAND. Any ideas on what I can do to isolate the
problem? Thanks in advance!
More info on this board:
- MPC 8313 SoC
- 1GB Samsung NAND flash (K9K8G08U0B)
- Linux 2.6.31
- U-Boot 2009.06
--
Matthew L. Creech
___
Linuxppc-dev mailin
deed I'm currently using CONFIG_PREEMPT_VOLUNTARY on
this board. I'll change it to fix this problem for now.
Do you happen to know whether the Freescale folks intend to fix this?
If not, it seems like at least some sort of warning is in order.
--
Matthew L. Creech
__
m not sure what an
appropriate fix is, since just replacing it with GFP_ATOMIC causes
allocation failures. Any helpful tips?
Thanks
--
Matthew L. Creech
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/lin
s initialization order in the kernel.
Anyway, seems to work fine. :) Thanks Antolij!
--
Matthew L. Creech
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Sat, Feb 19, 2011 at 1:01 PM, Matthew L. Creech wrote:
>
> Yes, it's there. Here's the DTS entry in case anything else sticks out:
>
> usb@23000 {
> compatible = "fsl-usb2-dr";
>
phy_type = "utmi_wide";
dr_mode = "peripheral";
sleep = <&pmc 0x0030>;
};
I think dr_mode was required in past kernel versions as well (since I
seem to recall bumping in to the problem you des
eal much, so I was hoping someone
here would have a better idea what could've changed between 2.6.36 and
2.6.37 that broke fsl_udc_core/fsl_usb2_udc. Thanks!
--
Matthew L. Creech
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
htt
{
GFAR_ERRATA_74 = 0x01,
GFAR_ERRATA_76 = 0x02,
GFAR_ERRATA_A002= 0x04,
+ GFAR_ERRATA_12 = 0x08,
};
/* Struct stolen almost completely (and shamelessly) from the FCC enet source
--
Matthew L. Creech
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
if it is. Presumably there's some alignment magic needed in
the sk_buff or gfar_add_fcb() to make sure that the microcontroller is
happy with the FCB offset?
Any tip on how I can solve this, or at least verify that this errata
is at fault?
like it expects all partitions to
be named "partition", otherwise they're just skipped. Is there some
peculiarity in my setup that makes this not work, or is it a general
problem? I see no major differences between my DTS file and the
stardard "mpc8313erdb.dts".
Than
if (interface == PHY_INTERFACE_MODE_RGMII_ID)
+ return PHY_INTERFACE_MODE_RGMII_ID;
+
+ return PHY_INTERFACE_MODE_RGMII;
}
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_GIGABIT)
--
Matthew L. Creech
_
as simply to disable CONFIG_SERIAL_OF_PLATFORM, as
it's unnecessary in my case.
--
Matthew L. Creech
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
r the help, and sorry for the noise.
--
Matthew L. Creech
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
I'd just run it to this point and then examine the memory - either
> using a BDI if one is attached, or press RESET (I hope you have one!)
> and then look using your boot loader (uBoot, RedBoot, ...)
>
I think I can get my hands on a BDI tomorrow, so I'll give this a try
then.
50/16550 driver, 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
console handover: boot [udbg0] -> real [ttyS0]
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
========
(nothing after this)
Thanks
--
Matthew L. Creech
___
problem lies.
Could someone point me in the right direction, or suggest what might
cause a console problem like this?
Thanks!
--
Matthew L. Creech
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
hat might
cause a console problem like this?
Thanks!
--
Matthew L. Creech
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
24 matches
Mail list logo
