* Re: UCC UART
From: Chuck Meade @ 2010-06-22 21:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4C2128E6.7010201@mlbassoc.com>
>> Also in the current Linux kernel, there is a dependence on the
>> correctness
>> of the "brg-frequency" property from the dts. Look up above
>> qe_setbrg() at
>> the qe_get_brg_clk() function. Before the return (there are multiple
>> return
>> points) printk the brg_clk being returned. That must be correct for your
>> hardware -- must be the actual brg freq. I assume that you are
>> booting from
>> U-Boot. I believe in modern implementations that U-Boot fills in the
>> brg-frequency in the device tree at boot time.
>
> The driver claims to work with either bus-frequency or brg-frequency set.
> I only had bus-frequency; when I set brg-frequency, it has started to work.
> Now to test it with a scope to see what else is wrong...
>
> BTW, I use RedBoot - being the original author, how could I not?
>
> Thanks for the help
No problem -- I am glad it is working for you now.
Chuck Meade
chuck@ThePTRGroup.com
^ permalink raw reply
* Re: UCC UART
From: Gary Thomas @ 2010-06-22 21:19 UTC (permalink / raw)
To: Chuck Meade; +Cc: linuxppc-dev
In-Reply-To: <4C210892.3040503@ThePTRGroup.com>
On 06/22/2010 01:01 PM, Chuck Meade wrote:
>>> What BRGs did you choose for tx and rx?
>>
>> BRG1& BRG2
>
> OK
>
>>> Get a scope on the UCC3 tx pin and try to output some chars. See if
>>> there is
>>> any digital activity on that pin at all. If you are looking at a
>>> terminal for
>>> output, there are too many things that could be wrong between that tx
>>> pin and
>>> your display (e.g. level translation issue, null modem issue, baud
>>> incompatibility,
>>> terminal program set for XON/XOFF or HW flow control and UART not set
>>> up compatibly).
>>>
>>> For now get the probe directly on the CPU's UCC3 Tx pin, output chars
>>> and see
>>> if there is any activity.
>>
>> We've done all this - nothing on the pins directly at the CPU.
>>
>> This is behaving very much like there is no clock to the device.
>> Is there something special that needs to be done to get the BRGs
>> to work?
>
> If I was doing this, at this point I would do some strategic printk debugging
> within ucc_uart.c. You said that you are using 2.6.33.3, so you already have
> all the fixes in ucc_slow.c that I had to backport to my older kernel.
>
> If you question the setup of the BRGs, go to your function that sets them up.
> I don't know about 2.6.33.3, but in the latest kernel it is qe_setbrg() in
> qe.c. At the very bottom there is an out_be32().
> printk both the address, and the value that is being written to that address.
> You may need to cast the values to unsigned longs to printk them. I will look
> at your numbers if you send them to me. In my implemenation (which again was
> a backport, so this may not apply to you) the BRG writes were off by 4 bytes.
> But I think that this error was due to the backport -- a logic mismatch I
> needed to resolve during the port.
>
> Also in the current Linux kernel, there is a dependence on the correctness
> of the "brg-frequency" property from the dts. Look up above qe_setbrg() at
> the qe_get_brg_clk() function. Before the return (there are multiple return
> points) printk the brg_clk being returned. That must be correct for your
> hardware -- must be the actual brg freq. I assume that you are booting from
> U-Boot. I believe in modern implementations that U-Boot fills in the
> brg-frequency in the device tree at boot time.
The driver claims to work with either bus-frequency or brg-frequency set.
I only had bus-frequency; when I set brg-frequency, it has started to work.
Now to test it with a scope to see what else is wrong...
BTW, I use RedBoot - being the original author, how could I not?
Thanks for the help
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 0/5] Rework MPC5121 DIU support (for 2.6.35)
From: Timur Tabi @ 2010-06-22 16:29 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: linux-fbdev, wd, dzu, devicetree-discuss, linuxppc-dev, yorksun
In-Reply-To: <1272584978-19063-1-git-send-email-agust@denx.de>
On Thu, Apr 29, 2010 at 6:49 PM, Anatolij Gustschin <agust@denx.de> wrote:
> This patch series rework DIU support patches submitted
> previously. Comments to the previos patch series have
> been addressed, not related changes are dropped and some
> changes are split out to separate patches to simplify
> review. Furthermore a patch has been added to support
> setting display mode using EDID block in the device tree.
All five patches:
Acked-by: Timur Tabi <timur@freescale.com>
Tested on an MPC8610 HPCD.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: UCC UART
From: Chuck Meade @ 2010-06-22 19:01 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4C2103DE.6020801@mlbassoc.com>
>> What BRGs did you choose for tx and rx?
>
> BRG1 & BRG2
OK
>> Get a scope on the UCC3 tx pin and try to output some chars. See if
>> there is
>> any digital activity on that pin at all. If you are looking at a
>> terminal for
>> output, there are too many things that could be wrong between that tx
>> pin and
>> your display (e.g. level translation issue, null modem issue, baud
>> incompatibility,
>> terminal program set for XON/XOFF or HW flow control and UART not set
>> up compatibly).
>>
>> For now get the probe directly on the CPU's UCC3 Tx pin, output chars
>> and see
>> if there is any activity.
>
> We've done all this - nothing on the pins directly at the CPU.
>
> This is behaving very much like there is no clock to the device.
> Is there something special that needs to be done to get the BRGs
> to work?
If I was doing this, at this point I would do some strategic printk debugging
within ucc_uart.c. You said that you are using 2.6.33.3, so you already have
all the fixes in ucc_slow.c that I had to backport to my older kernel.
If you question the setup of the BRGs, go to your function that sets them up.
I don't know about 2.6.33.3, but in the latest kernel it is qe_setbrg() in
qe.c. At the very bottom there is an out_be32().
printk both the address, and the value that is being written to that address.
You may need to cast the values to unsigned longs to printk them. I will look
at your numbers if you send them to me. In my implemenation (which again was
a backport, so this may not apply to you) the BRG writes were off by 4 bytes.
But I think that this error was due to the backport -- a logic mismatch I
needed to resolve during the port.
Also in the current Linux kernel, there is a dependence on the correctness
of the "brg-frequency" property from the dts. Look up above qe_setbrg() at
the qe_get_brg_clk() function. Before the return (there are multiple return
points) printk the brg_clk being returned. That must be correct for your
hardware -- must be the actual brg freq. I assume that you are booting from
U-Boot. I believe in modern implementations that U-Boot fills in the
brg-frequency in the device tree at boot time.
Let me know how it goes,
Chuck Meade
chuck@ThePTRGroup.com
^ permalink raw reply
* Re: UCC UART
From: Gary Thomas @ 2010-06-22 18:41 UTC (permalink / raw)
To: Chuck Meade; +Cc: linuxppc-dev
In-Reply-To: <4C20FDA0.5050208@ThePTRGroup.com>
On 06/22/2010 12:14 PM, Chuck Meade wrote:
>>> I did not do that, and I have it running here. I will say though that I
>>> hardcoded the driver to run in soft UART mode. You will need to at least
>>> add the appropriate line to your dts to get the driver to operate in
>>> Soft UART mode.
>>>
>>> I hardcoded mine because I had to backport this UCC UART driver to an
>>> older
>>> Linux kernel, and that kernel was from before dts existed.
>>>
>>> Add whatever you need to your dts to make it run in soft UART mode and
>>> get
>>> the firmware loaded. Use two different BRGs for tx and rx. Make sure
>>> your
>>> BRG choice is valid for your UCC3.
>>>
>>> I believe that the UCC UART support has not had too much use so far, but
>>> I do have it working (in that older kernel after backporting).
>>
>> I've done all this but sadly the behaviour is the same :-(
>>
>> Any ideas what I might be missing?
>
> Check your setup of the UCC3 pins for UART mode. Make sure you either have
> the UCC3 CD, CTS, RTS pins at the correct levels, or deconfigure those pins
> (set them up as GPIOs). Just verify every pin is properly set up for UCC3.
> The UCC3 TxD and RxD signals must be set up properly.
Only UCC3 RxD and TxD are configured
> What BRGs did you choose for tx and rx?
BRG1 & BRG2
>
> Get a scope on the UCC3 tx pin and try to output some chars. See if there is
> any digital activity on that pin at all. If you are looking at a terminal for
> output, there are too many things that could be wrong between that tx pin and
> your display (e.g. level translation issue, null modem issue, baud incompatibility,
> terminal program set for XON/XOFF or HW flow control and UART not set up compatibly).
>
> For now get the probe directly on the CPU's UCC3 Tx pin, output chars and see
> if there is any activity.
We've done all this - nothing on the pins directly at the CPU.
This is behaving very much like there is no clock to the device.
Is there something special that needs to be done to get the BRGs
to work?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: UCC UART
From: Chuck Meade @ 2010-06-22 18:14 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4C20F671.9090605@mlbassoc.com>
>> I did not do that, and I have it running here. I will say though that I
>> hardcoded the driver to run in soft UART mode. You will need to at least
>> add the appropriate line to your dts to get the driver to operate in
>> Soft UART mode.
>>
>> I hardcoded mine because I had to backport this UCC UART driver to an
>> older
>> Linux kernel, and that kernel was from before dts existed.
>>
>> Add whatever you need to your dts to make it run in soft UART mode and
>> get
>> the firmware loaded. Use two different BRGs for tx and rx. Make sure
>> your
>> BRG choice is valid for your UCC3.
>>
>> I believe that the UCC UART support has not had too much use so far, but
>> I do have it working (in that older kernel after backporting).
>
> I've done all this but sadly the behaviour is the same :-(
>
> Any ideas what I might be missing?
Check your setup of the UCC3 pins for UART mode. Make sure you either have
the UCC3 CD, CTS, RTS pins at the correct levels, or deconfigure those pins
(set them up as GPIOs). Just verify every pin is properly set up for UCC3.
The UCC3 TxD and RxD signals must be set up properly.
What BRGs did you choose for tx and rx?
Get a scope on the UCC3 tx pin and try to output some chars. See if there is
any digital activity on that pin at all. If you are looking at a terminal for
output, there are too many things that could be wrong between that tx pin and
your display (e.g. level translation issue, null modem issue, baud incompatibility,
terminal program set for XON/XOFF or HW flow control and UART not set up compatibly).
For now get the probe directly on the CPU's UCC3 Tx pin, output chars and see
if there is any activity.
Chuck Meade
chuck@ThePTRGroup.com
^ permalink raw reply
* Re: [PATCH 1/2] mtd: m25p80: Fix false-positive probing
From: Mike Frysinger @ 2010-06-22 17:56 UTC (permalink / raw)
To: Anton Vorontsov
Cc: David Brownell, Artem Bityutskiy, Barry Song, linux-kernel,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton,
David Woodhouse
In-Reply-To: <20100622165734.GA20699@oksana.dev.rtsoft.ru>
On Tue, Jun 22, 2010 at 12:57, Anton Vorontsov wrote:
> Since commit 18c6182bae0acca220ed6611f741034d563cd19f ("Rework
> probing/JEDEC code"), m25p80 driver successfully registers chips
> even if JEDEC probing fails.
>
> This was needed to support non-JEDEC flashes. Though, it appears
> that some platforms (e.g. blackfin bf533 stamp[1]) used the old
> behavior to detect if there's any flash connected, so the driver
> have to fail on JEDEC probing errors.
>
> This patch restores the old behavior for JEDEC flashes, and adds
> "-nonjedec" SPI device IDs for M25Pxx flashes, so that the kernel
> still supports non-JEDEC flashes.
Acked-by: Mike Frysinger <vapier@gentoo.org>
> [1] http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=5975
http://blackfin.uclinux.org/gf/tracker/5975
> Reported-by: Mingquan Pan
<Grace.Pan@analog.com>
-mike
^ permalink raw reply
* Re: UCC UART
From: Gary Thomas @ 2010-06-22 17:44 UTC (permalink / raw)
To: Chuck Meade; +Cc: linuxppc-dev
In-Reply-To: <4C20DC5F.80902@ThePTRGroup.com>
On 06/22/2010 09:53 AM, Chuck Meade wrote:
>>> Sure. Go to opensource.freescale.com/firmware and download (for your
>>> MPC8358)
>>> the 8360 soft UART mode microcode patch. You will need to know if
>>> your CPU
>>> is a 2.0 or 2.1 silicon, since there is a different microcode patch
>>> for each.
>>>
>>> Then in the kernel config I believe I included CONFIG_FW_LOADER and
>>> CONFIG_HOTPLUG
>>> (one of those may have autoselected the other).
>>>
>>> Make sure in your ucc_uart.c driver that soft uart mode is enabled.
>>>
>>> At boot time, the driver will kick off a 10 second timer that will expect
>>> the microcode patch to be loaded before the end of that 10 secs.
>>>
>>> Very early in my boot sequence, I have a startup script send the
>>> microcode patch
>>> file to the driver through the firmware-loading sysfs entry. But you
>>> need to
>>> be aware that the UCC number in the sysfs path will be offset by one.
>>> Since you
>>> are using UCC3, you should use a '2' in the path as shown below. This
>>> sequence
>>> worked for me (I changed the number for you to '2' in my command
>>> sequence, since
>>> I use a different UCC):
>>>
>>> echo 1> /sys/class/firmware/fsl-ucc-uart2/loading
>>> cat /root/fsl_qe_ucode_uart_8360_21.bin>
>>> /sys/class/firmware/fsl-ucc-uart2/data
>>> echo 0> /sys/class/firmware/fsl-ucc-uart2/loading
>>>
>>> Note that the above presupposes you are using the file for silicon 2.1.
>>> Also presupposes that you have put the microcode under your rootfs
>>> /root directory.
>>
>> Thanks, I'll give this a try. When I download the firmware this way,
>> do I need to follow the directions in
>> Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt
>
> I did not do that, and I have it running here. I will say though that I
> hardcoded the driver to run in soft UART mode. You will need to at least
> add the appropriate line to your dts to get the driver to operate in
> Soft UART mode.
>
> I hardcoded mine because I had to backport this UCC UART driver to an older
> Linux kernel, and that kernel was from before dts existed.
>
> Add whatever you need to your dts to make it run in soft UART mode and get
> the firmware loaded. Use two different BRGs for tx and rx. Make sure your
> BRG choice is valid for your UCC3.
>
> I believe that the UCC UART support has not had too much use so far, but
> I do have it working (in that older kernel after backporting).
I've done all this but sadly the behaviour is the same :-(
Any ideas what I might be missing?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* [PATCH 2/2] mtd: m25p80: Make jedec_probe() return proper errno values
From: Anton Vorontsov @ 2010-06-22 16:57 UTC (permalink / raw)
To: David Woodhouse
Cc: David Brownell, Mike Frysinger, Artem Bityutskiy, Barry Song,
linux-kernel, linuxppc-dev, linux-mtd, uclinux-dist-devel,
Andrew Morton
In-Reply-To: <20100622165545.GA10255@oksana.dev.rtsoft.ru>
spi_write_then_read() may return its own return codes (e.g. -EIO),
so let's propagate the value down to the probe().
Also, remove jedec == 0 check, it isn't needed as nowadays we use
dedicated SPI device IDs for non-JEDEC flashes.
Suggested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
This is for 2.6.36.
drivers/mtd/devices/m25p80.c | 18 ++++++------------
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index a610ca9..7bf5c45 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -16,6 +16,8 @@
*/
#include <linux/init.h>
+#include <linux/err.h>
+#include <linux/errno.h>
#include <linux/module.h>
#include <linux/device.h>
#include <linux/interrupt.h>
@@ -733,7 +735,7 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
if (tmp < 0) {
DEBUG(MTD_DEBUG_LEVEL0, "%s: error %d reading JEDEC ID\n",
dev_name(&spi->dev), tmp);
- return NULL;
+ return ERR_PTR(tmp);
}
jedec = id[0];
jedec = jedec << 8;
@@ -741,14 +743,6 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
jedec = jedec << 8;
jedec |= id[2];
- /*
- * Some chips (like Numonyx M25P80) have JEDEC and non-JEDEC variants,
- * which depend on technology process. Officially RDID command doesn't
- * exist for non-JEDEC chips, but for compatibility they return ID 0.
- */
- if (jedec == 0)
- return NULL;
-
ext_jedec = id[3] << 8 | id[4];
for (tmp = 0; tmp < ARRAY_SIZE(m25p_ids) - 1; tmp++) {
@@ -759,7 +753,7 @@ static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
return &m25p_ids[tmp];
}
}
- return NULL;
+ return ERR_PTR(-ENODEV);
}
@@ -804,8 +798,8 @@ static int __devinit m25p_probe(struct spi_device *spi)
const struct spi_device_id *jid;
jid = jedec_probe(spi);
- if (!jid) {
- return -ENODEV;
+ if (IS_ERR(jid)) {
+ return PTR_ERR(jid);
} else if (jid != id) {
/*
* JEDEC knows better, so overwrite platform ID. We
--
1.7.0.5
^ permalink raw reply related
* [PATCH 1/2] mtd: m25p80: Fix false-positive probing
From: Anton Vorontsov @ 2010-06-22 16:57 UTC (permalink / raw)
To: David Woodhouse
Cc: David Brownell, Mike Frysinger, Artem Bityutskiy, Barry Song,
linux-kernel, linuxppc-dev, linux-mtd, uclinux-dist-devel,
Andrew Morton
In-Reply-To: <20100622165545.GA10255@oksana.dev.rtsoft.ru>
Since commit 18c6182bae0acca220ed6611f741034d563cd19f ("Rework
probing/JEDEC code"), m25p80 driver successfully registers chips
even if JEDEC probing fails.
This was needed to support non-JEDEC flashes. Though, it appears
that some platforms (e.g. blackfin bf533 stamp[1]) used the old
behavior to detect if there's any flash connected, so the driver
have to fail on JEDEC probing errors.
This patch restores the old behavior for JEDEC flashes, and adds
"-nonjedec" SPI device IDs for M25Pxx flashes, so that the kernel
still supports non-JEDEC flashes.
[1] http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=5975
Reported-by: Mingquan Pan
Reported-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
This is for 2.6.35.
drivers/mtd/devices/m25p80.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 81e49a9..a610ca9 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -680,6 +680,16 @@ static const struct spi_device_id m25p_ids[] = {
{ "m25p64", INFO(0x202017, 0, 64 * 1024, 128, 0) },
{ "m25p128", INFO(0x202018, 0, 256 * 1024, 64, 0) },
+ { "m25p05-nonjedec", INFO(0, 0, 32 * 1024, 2, 0) },
+ { "m25p10-nonjedec", INFO(0, 0, 32 * 1024, 4, 0) },
+ { "m25p20-nonjedec", INFO(0, 0, 64 * 1024, 4, 0) },
+ { "m25p40-nonjedec", INFO(0, 0, 64 * 1024, 8, 0) },
+ { "m25p80-nonjedec", INFO(0, 0, 64 * 1024, 16, 0) },
+ { "m25p16-nonjedec", INFO(0, 0, 64 * 1024, 32, 0) },
+ { "m25p32-nonjedec", INFO(0, 0, 64 * 1024, 64, 0) },
+ { "m25p64-nonjedec", INFO(0, 0, 64 * 1024, 128, 0) },
+ { "m25p128-nonjedec", INFO(0, 0, 256 * 1024, 64, 0) },
+
{ "m45pe10", INFO(0x204011, 0, 64 * 1024, 2, 0) },
{ "m45pe80", INFO(0x204014, 0, 64 * 1024, 16, 0) },
{ "m45pe16", INFO(0x204015, 0, 64 * 1024, 32, 0) },
@@ -795,8 +805,7 @@ static int __devinit m25p_probe(struct spi_device *spi)
jid = jedec_probe(spi);
if (!jid) {
- dev_info(&spi->dev, "non-JEDEC variant of %s\n",
- id->name);
+ return -ENODEV;
} else if (jid != id) {
/*
* JEDEC knows better, so overwrite platform ID. We
--
1.7.0.5
^ permalink raw reply related
* Re: [Uclinux-dist-devel] [PATCH 1/2] mtd: m25p80: Reworkprobing/JEDEC code
From: Anton Vorontsov @ 2010-06-22 16:55 UTC (permalink / raw)
To: Barry Song
Cc: David Brownell, Artem Bityutskiy, linux-kernel, Song, Barry,
linuxppc-dev, linux-mtd, uclinux-dist-devel, Andrew Morton,
David Woodhouse
In-Reply-To: <AANLkTikY9pfHsQ6xeVkixKF5kqL2nLyV2kgcR2iJKhG-@mail.gmail.com>
On Tue, Jun 22, 2010 at 02:37:52PM +0800, Barry Song wrote:
[...]
> > jid = jedec_probe(spi);
> > if (!jid) {
> > - dev_info(&spi->dev, "non-JEDEC variant of %s\n",
> > - id->name);
> > + return -ENODEV;
> The patch looks good to me. Only problem is NULL is also returned by
> spi_write_then_read() fail:
[...]
> Here much better for -EIO (return tmp)?
Agreed. Though, this is not a regression, and I guess desires
its own patch.
Here are two patches, one for 2.6.35 (minimal changes to fix
the JEDEC problem), another for 2.6.36.
^ permalink raw reply
* Re: UCC UART
From: Chuck Meade @ 2010-06-22 15:53 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4C20DABA.5030301@mlbassoc.com>
>> Sure. Go to opensource.freescale.com/firmware and download (for your
>> MPC8358)
>> the 8360 soft UART mode microcode patch. You will need to know if
>> your CPU
>> is a 2.0 or 2.1 silicon, since there is a different microcode patch
>> for each.
>>
>> Then in the kernel config I believe I included CONFIG_FW_LOADER and
>> CONFIG_HOTPLUG
>> (one of those may have autoselected the other).
>>
>> Make sure in your ucc_uart.c driver that soft uart mode is enabled.
>>
>> At boot time, the driver will kick off a 10 second timer that will expect
>> the microcode patch to be loaded before the end of that 10 secs.
>>
>> Very early in my boot sequence, I have a startup script send the
>> microcode patch
>> file to the driver through the firmware-loading sysfs entry. But you
>> need to
>> be aware that the UCC number in the sysfs path will be offset by one.
>> Since you
>> are using UCC3, you should use a '2' in the path as shown below. This
>> sequence
>> worked for me (I changed the number for you to '2' in my command
>> sequence, since
>> I use a different UCC):
>>
>> echo 1> /sys/class/firmware/fsl-ucc-uart2/loading
>> cat /root/fsl_qe_ucode_uart_8360_21.bin>
>> /sys/class/firmware/fsl-ucc-uart2/data
>> echo 0> /sys/class/firmware/fsl-ucc-uart2/loading
>>
>> Note that the above presupposes you are using the file for silicon 2.1.
>> Also presupposes that you have put the microcode under your rootfs
>> /root directory.
>
> Thanks, I'll give this a try. When I download the firmware this way,
> do I need to follow the directions in
> Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt
I did not do that, and I have it running here. I will say though that I
hardcoded the driver to run in soft UART mode. You will need to at least
add the appropriate line to your dts to get the driver to operate in
Soft UART mode.
I hardcoded mine because I had to backport this UCC UART driver to an older
Linux kernel, and that kernel was from before dts existed.
Add whatever you need to your dts to make it run in soft UART mode and get
the firmware loaded. Use two different BRGs for tx and rx. Make sure your
BRG choice is valid for your UCC3.
I believe that the UCC UART support has not had too much use so far, but
I do have it working (in that older kernel after backporting).
Chuck Meade
chuck@ThePTRGroup.com
^ permalink raw reply
* Re: UCC UART
From: Gary Thomas @ 2010-06-22 15:46 UTC (permalink / raw)
To: Chuck Meade; +Cc: linuxppc-dev
In-Reply-To: <4C20D699.1080404@ThePTRGroup.com>
On 06/22/2010 09:28 AM, Chuck Meade wrote:
>>> Hi Gary,
>>>
>>> According to the errata, it looks like the MPC8358 is subject to
>>> erratum QE_UART6. You'll need to use soft UART mode and load the
>>> microcode patch. Once that is done you will also need to use two
>>> different BRG's, one for tx and one for rx, since the soft UART mode
>>> microcode patch requires them to be set to different rates (I believe
>>> Rx is 16*baud under soft UART mode, and Tx is 1*baud).
>>
>> As I feared! Can you tell me where/how to get the microcode patch?
>>
>>> Also, I don't know if it matters or not, but you should change your
>>> dts entry "serial@4000" to "serial@2200", just like you recently changed
>>> your "reg =" to 0x2200.
>>
>> I did that as soon as I sent this and saw the glaring inconsistency :-)
>>
>> Thanks
>
> Sure. Go to opensource.freescale.com/firmware and download (for your MPC8358)
> the 8360 soft UART mode microcode patch. You will need to know if your CPU
> is a 2.0 or 2.1 silicon, since there is a different microcode patch for each.
>
> Then in the kernel config I believe I included CONFIG_FW_LOADER and CONFIG_HOTPLUG
> (one of those may have autoselected the other).
>
> Make sure in your ucc_uart.c driver that soft uart mode is enabled.
>
> At boot time, the driver will kick off a 10 second timer that will expect
> the microcode patch to be loaded before the end of that 10 secs.
>
> Very early in my boot sequence, I have a startup script send the microcode patch
> file to the driver through the firmware-loading sysfs entry. But you need to
> be aware that the UCC number in the sysfs path will be offset by one. Since you
> are using UCC3, you should use a '2' in the path as shown below. This sequence
> worked for me (I changed the number for you to '2' in my command sequence, since
> I use a different UCC):
>
> echo 1> /sys/class/firmware/fsl-ucc-uart2/loading
> cat /root/fsl_qe_ucode_uart_8360_21.bin> /sys/class/firmware/fsl-ucc-uart2/data
> echo 0> /sys/class/firmware/fsl-ucc-uart2/loading
>
> Note that the above presupposes you are using the file for silicon 2.1.
> Also presupposes that you have put the microcode under your rootfs /root directory.
Thanks, I'll give this a try. When I download the firmware this way,
do I need to follow the directions in
Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: UCC UART
From: Chuck Meade @ 2010-06-22 15:28 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4C20D34A.80202@mlbassoc.com>
>> Hi Gary,
>>
>> According to the errata, it looks like the MPC8358 is subject to
>> erratum QE_UART6. You'll need to use soft UART mode and load the
>> microcode patch. Once that is done you will also need to use two
>> different BRG's, one for tx and one for rx, since the soft UART mode
>> microcode patch requires them to be set to different rates (I believe
>> Rx is 16*baud under soft UART mode, and Tx is 1*baud).
>
> As I feared! Can you tell me where/how to get the microcode patch?
>
>> Also, I don't know if it matters or not, but you should change your
>> dts entry "serial@4000" to "serial@2200", just like you recently changed
>> your "reg =" to 0x2200.
>
> I did that as soon as I sent this and saw the glaring inconsistency :-)
>
> Thanks
Sure. Go to opensource.freescale.com/firmware and download (for your MPC8358)
the 8360 soft UART mode microcode patch. You will need to know if your CPU
is a 2.0 or 2.1 silicon, since there is a different microcode patch for each.
Then in the kernel config I believe I included CONFIG_FW_LOADER and CONFIG_HOTPLUG
(one of those may have autoselected the other).
Make sure in your ucc_uart.c driver that soft uart mode is enabled.
At boot time, the driver will kick off a 10 second timer that will expect
the microcode patch to be loaded before the end of that 10 secs.
Very early in my boot sequence, I have a startup script send the microcode patch
file to the driver through the firmware-loading sysfs entry. But you need to
be aware that the UCC number in the sysfs path will be offset by one. Since you
are using UCC3, you should use a '2' in the path as shown below. This sequence
worked for me (I changed the number for you to '2' in my command sequence, since
I use a different UCC):
echo 1 > /sys/class/firmware/fsl-ucc-uart2/loading
cat /root/fsl_qe_ucode_uart_8360_21.bin > /sys/class/firmware/fsl-ucc-uart2/data
echo 0 > /sys/class/firmware/fsl-ucc-uart2/loading
Note that the above presupposes you are using the file for silicon 2.1.
Also presupposes that you have put the microcode under your rootfs /root directory.
Chuck Meade
chuck@ThePTRGroup.com
^ permalink raw reply
* Re: UCC interactions
From: Chuck Meade @ 2010-06-22 15:15 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <AANLkTinyt8phAgxJk30G0XuA5kJ78Xy1WdTg_yQpTCsS@mail.gmail.com>
On 06/22/2010 10:51 AM, Timur Tabi wrote:
> On Mon, Jun 21, 2010 at 2:00 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>> I'm running 2.6.33.3 on MPC8358. I have UCC1+UCC2 working fine
>> for ethernet, but when I add UCC3 as a UART, the network devices
>> quit working.
>
> Since you're using QE UART, would you mind testing this patch:
>
> http://patchwork.ozlabs.org/patch/56181/
>
> and letting us know if it works for you?
>
Hi Timur,
His UART is not working yet. I am fine with him testing my patch (I hope he does),
just he still is working on getting his UART to work at all. I think since he is
using MPC8358, he needs the soft UART mode microcode patch.
The patch that you mention above is one I wrote that affects how the UART close
operation handles being closed when buffered output is still present. I fixed the
timeout so it closes in the correct amount of time. Gary is not quite ready for
testing this yet.
Thanks,
Chuck
^ permalink raw reply
* Re: UCC UART
From: Gary Thomas @ 2010-06-22 15:14 UTC (permalink / raw)
To: Chuck Meade; +Cc: linuxppc-dev
In-Reply-To: <4C20D27D.5000503@ThePTRGroup.com>
On 06/22/2010 09:10 AM, Chuck Meade wrote:
> On 06/22/2010 10:55 AM, Gary Thomas wrote:
>> I'm still trying to get UCC UART to work on my MPC8358 with
>> the 2.6.33.3 kernel.
>>
>> When I try to send data to the port, there is no output, not
>> even any interrupts on the device. What I see is that the UART
>> driver seems to initialize fine and pushes characters into
>> the output buffers& descriptors. However, there are no
>> interrupts hence it just sits there...
>>
>> My device tree entry for this device now looks like this:
>> /* ttyQE0 (UCC3) */
>> serial_qe0: serial@4000 {
>> device_type = "serial";
>> compatible = "ucc_uart";
>> cell-index =<3>;
>> reg =<0x2200 0x200>;
>> interrupts =<34>;
>> interrupt-parent =<&qeic>;
>> port-number =<0>;
>> rx-clock-name = "brg1";
>> tx-clock-name = "brg1";
>> };
>>
>> * Are there any known issues with this driver?
>> * Is there any way to get a handle on why no data is moving?
>> * Is there some way to tell if the QE even sees the descriptors?
>> * The driver and documentation mention a "soft UART" mode for
>> chips with broken UART hardware. How do I know if my board
>> has functioning UART hardware?
>>
>> Note: I have UCC1+UCC2 working great with ethernet.
>>
>> Thanks for any pointers or ideas
>
> Hi Gary,
>
> According to the errata, it looks like the MPC8358 is subject to
> erratum QE_UART6. You'll need to use soft UART mode and load the
> microcode patch. Once that is done you will also need to use two
> different BRG's, one for tx and one for rx, since the soft UART mode
> microcode patch requires them to be set to different rates (I believe
> Rx is 16*baud under soft UART mode, and Tx is 1*baud).
As I feared! Can you tell me where/how to get the microcode patch?
> Also, I don't know if it matters or not, but you should change your
> dts entry "serial@4000" to "serial@2200", just like you recently changed
> your "reg =" to 0x2200.
I did that as soon as I sent this and saw the glaring inconsistency :-)
Thanks
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: UCC UART
From: Chuck Meade @ 2010-06-22 15:10 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4C20CECB.9050609@mlbassoc.com>
On 06/22/2010 10:55 AM, Gary Thomas wrote:
> I'm still trying to get UCC UART to work on my MPC8358 with
> the 2.6.33.3 kernel.
>
> When I try to send data to the port, there is no output, not
> even any interrupts on the device. What I see is that the UART
> driver seems to initialize fine and pushes characters into
> the output buffers & descriptors. However, there are no
> interrupts hence it just sits there...
>
> My device tree entry for this device now looks like this:
> /* ttyQE0 (UCC3) */
> serial_qe0: serial@4000 {
> device_type = "serial";
> compatible = "ucc_uart";
> cell-index = <3>;
> reg = <0x2200 0x200>;
> interrupts = <34>;
> interrupt-parent = <&qeic>;
> port-number = <0>;
> rx-clock-name = "brg1";
> tx-clock-name = "brg1";
> };
>
> * Are there any known issues with this driver?
> * Is there any way to get a handle on why no data is moving?
> * Is there some way to tell if the QE even sees the descriptors?
> * The driver and documentation mention a "soft UART" mode for
> chips with broken UART hardware. How do I know if my board
> has functioning UART hardware?
>
> Note: I have UCC1+UCC2 working great with ethernet.
>
> Thanks for any pointers or ideas
Hi Gary,
According to the errata, it looks like the MPC8358 is subject to
erratum QE_UART6. You'll need to use soft UART mode and load the
microcode patch. Once that is done you will also need to use two
different BRG's, one for tx and one for rx, since the soft UART mode
microcode patch requires them to be set to different rates (I believe
Rx is 16*baud under soft UART mode, and Tx is 1*baud).
Also, I don't know if it matters or not, but you should change your
dts entry "serial@4000" to "serial@2200", just like you recently changed
your "reg =" to 0x2200.
Chuck Meade
chuck@ThePTRGroup.com
^ permalink raw reply
* Re: UCC UART
From: Tabi Timur-B04825 @ 2010-06-22 15:06 UTC (permalink / raw)
To: Gary Thomas; +Cc: Linux PPC Development
In-Reply-To: <4C20CECB.9050609@mlbassoc.com>
[-- Attachment #1: Type: text/plain, Size: 1980 bytes --]
Gary Thomas wrote:
> I'm still trying to get UCC UART to work on my MPC8358 with
> the 2.6.33.3 kernel.
>
> When I try to send data to the port, there is no output, not
> even any interrupts on the device. What I see is that the UART
> driver seems to initialize fine and pushes characters into
> the output buffers & descriptors. However, there are no
> interrupts hence it just sits there...
>
> My device tree entry for this device now looks like this:
> /* ttyQE0 (UCC3) */
> serial_qe0: serial@4000 {
> device_type = "serial";
> compatible = "ucc_uart";
> cell-index = <3>;
> reg = <0x2200 0x200>;
> interrupts = <34>;
> interrupt-parent = <&qeic>;
> port-number = <0>;
> rx-clock-name = "brg1";
> tx-clock-name = "brg1";
> };
You might try assigning different BRGs to TX and RX.
>
> * Are there any known issues with this driver?
Heh. :-)
I'd say that there are plenty of unknown issues with this driver/hardware.
For some reason, QE UART is just unreliable. I've had several people try to
use the QE for UART, and almost everyone has problems with it.
> * Is there any way to get a handle on why no data is moving?
The QE is a black box. If you're programming it correctly but it doesn't do
what it's supposed to, there's almost no way to debug it.
> * Is there some way to tell if the QE even sees the descriptors?
Not to my knowledge.
> * The driver and documentation mention a "soft UART" mode for
> chips with broken UART hardware. How do I know if my board
> has functioning UART hardware?
I believe only the 8323 and the 8360 have broken UARTs. Those are the only
ones that have the microcode update that enable soft-UART, anyway.
>
> Note: I have UCC1+UCC2 working great with ethernet.
>
> Thanks for any pointers or ideas
You should contact Freescale support and ask them for help. Even though I
wrote the Linux driver, I have no "inside" connection to the QE team here at
Freescale.
[-- Attachment #2: Type: text/html, Size: 2782 bytes --]
^ permalink raw reply
* Re: UCC interactions
From: Timur Tabi @ 2010-06-22 14:51 UTC (permalink / raw)
To: Gary Thomas; +Cc: Linux PPC Development
In-Reply-To: <4C1FB6BB.4040705@mlbassoc.com>
On Mon, Jun 21, 2010 at 2:00 PM, Gary Thomas <gary@mlbassoc.com> wrote:
> I'm running 2.6.33.3 on MPC8358. =A0I have UCC1+UCC2 working fine
> for ethernet, but when I add UCC3 as a UART, the network devices
> quit working.
Since you're using QE UART, would you mind testing this patch:
http://patchwork.ozlabs.org/patch/56181/
and letting us know if it works for you?
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* UCC UART
From: Gary Thomas @ 2010-06-22 14:55 UTC (permalink / raw)
To: Linux PPC Development; +Cc: Timur Tabi
I'm still trying to get UCC UART to work on my MPC8358 with
the 2.6.33.3 kernel.
When I try to send data to the port, there is no output, not
even any interrupts on the device. What I see is that the UART
driver seems to initialize fine and pushes characters into
the output buffers & descriptors. However, there are no
interrupts hence it just sits there...
My device tree entry for this device now looks like this:
/* ttyQE0 (UCC3) */
serial_qe0: serial@4000 {
device_type = "serial";
compatible = "ucc_uart";
cell-index = <3>;
reg = <0x2200 0x200>;
interrupts = <34>;
interrupt-parent = <&qeic>;
port-number = <0>;
rx-clock-name = "brg1";
tx-clock-name = "brg1";
};
* Are there any known issues with this driver?
* Is there any way to get a handle on why no data is moving?
* Is there some way to tell if the QE even sees the descriptors?
* The driver and documentation mention a "soft UART" mode for
chips with broken UART hardware. How do I know if my board
has functioning UART hardware?
Note: I have UCC1+UCC2 working great with ethernet.
Thanks for any pointers or ideas
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 1/2] KVM: PPC: Add generic hpte management functions
From: Avi Kivity @ 2010-06-22 12:20 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <4C20A91A.1080607@suse.de>
On 06/22/2010 03:14 PM, Alexander Graf wrote:
> Avi Kivity wrote:
>
>> On 06/22/2010 03:10 PM, Alexander Graf wrote:
>>
>>> If you have more performance hints, I'll gladly take them :).
>>>
>>>
>> Using a cpu that virtualizes the mmu in hardware helps tremendously.
>>
>>
> PPC never does that. Even with the virtualization extensions the MMU is
> still software managed.
Then mmu intensive loads can expect to be slow.
> I was also more thinking of hints like
> "kmem_cache_zalloc is slow" or so ;).
>
Stuff like that is usually worthless. To give real feedback I need to
understand the hardware, so I'm reduced to coding style and indentation
review.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH 1/2] KVM: PPC: Add generic hpte management functions
From: Alexander Graf @ 2010-06-22 12:14 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <4C20A890.9040806@redhat.com>
Avi Kivity wrote:
> On 06/22/2010 03:10 PM, Alexander Graf wrote:
>> If you have more performance hints, I'll gladly take them :).
>>
>
> Using a cpu that virtualizes the mmu in hardware helps tremendously.
>
PPC never does that. Even with the virtualization extensions the MMU is
still software managed. I was also more thinking of hints like
"kmem_cache_zalloc is slow" or so ;).
Alex
^ permalink raw reply
* Re: [PATCH 1/2] KVM: PPC: Add generic hpte management functions
From: Avi Kivity @ 2010-06-22 12:12 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <4C20A836.2010908@suse.de>
On 06/22/2010 03:10 PM, Alexander Graf wrote:
> If you have more performance hints, I'll gladly take them :).
>
Using a cpu that virtualizes the mmu in hardware helps tremendously.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH 1/2] KVM: PPC: Add generic hpte management functions
From: Alexander Graf @ 2010-06-22 12:10 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <4C20A795.6040607@redhat.com>
Avi Kivity wrote:
> On 06/22/2010 03:04 PM, Alexander Graf wrote:
>> Avi Kivity wrote:
>>
>>> On 06/21/2010 04:44 PM, Alexander Graf wrote:
>>>
>>>> Currently the shadow paging code keeps an array of entries it knows
>>>> about.
>>>> Whenever the guest invalidates an entry, we loop through that entry,
>>>> trying to invalidate matching parts.
>>>>
>>>> While this is a really simple implementation, it is probably the most
>>>> ineffective one possible. So instead, let's keep an array of lists
>>>> around
>>>> that are indexed by a hash. This way each PTE can be added by 4
>>>> list_add,
>>>> removed by 4 list_del invocations and the search only needs to loop
>>>> through
>>>> entries that share the same hash.
>>>>
>>>> This patch implements said lookup and exports generic functions that
>>>> both
>>>> the 32-bit and 64-bit backend can use.
>>>>
>>>>
>>> Mind explaining the all list in there?
>>>
>> The all list is used to flush all entries when we need to get rid of all
>> entries, for example when we write a BAT.
>>
>>
>
> Yes, I more or less gathered that when I saw patch 2. Does it make
> sense to avoid it by looping over all vpte lists in the vpte hash?
> More effort for a full flush, esp. when the mmu is sparse, but less
> for individual pte operations.
Hrm. We could probably make the vpte_long list shorter. Currently all
lists are 1 << 13 entries wide. So we have 8192 lists to loop through.
For vpte_long 1 << 8 = 256 is probably enough. With that it would
probably make sense, yes.
If you have more performance hints, I'll gladly take them :).
Alex
^ permalink raw reply
* Re: [PATCH 1/2] KVM: PPC: Add generic hpte management functions
From: Avi Kivity @ 2010-06-22 12:07 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <4C20A6C8.4070002@suse.de>
On 06/22/2010 03:04 PM, Alexander Graf wrote:
> Avi Kivity wrote:
>
>> On 06/21/2010 04:44 PM, Alexander Graf wrote:
>>
>>> Currently the shadow paging code keeps an array of entries it knows
>>> about.
>>> Whenever the guest invalidates an entry, we loop through that entry,
>>> trying to invalidate matching parts.
>>>
>>> While this is a really simple implementation, it is probably the most
>>> ineffective one possible. So instead, let's keep an array of lists
>>> around
>>> that are indexed by a hash. This way each PTE can be added by 4
>>> list_add,
>>> removed by 4 list_del invocations and the search only needs to loop
>>> through
>>> entries that share the same hash.
>>>
>>> This patch implements said lookup and exports generic functions that
>>> both
>>> the 32-bit and 64-bit backend can use.
>>>
>>>
>> Mind explaining the all list in there?
>>
> The all list is used to flush all entries when we need to get rid of all
> entries, for example when we write a BAT.
>
>
Yes, I more or less gathered that when I saw patch 2. Does it make
sense to avoid it by looping over all vpte lists in the vpte hash? More
effort for a full flush, esp. when the mmu is sparse, but less for
individual pte operations.
--
error compiling committee.c: too many arguments to function
^ 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