Re: SCSI errors on powerpc with 2.6.24-rc6-mm1
FUJITA Tomonori wrote: > On Thu, 27 Dec 2007 10:08:25 +0530 > Balbir Singh <[EMAIL PROTECTED]> wrote: > >> FUJITA Tomonori wrote: >>> On Mon, 24 Dec 2007 10:18:50 +0530 >>> Balbir Singh <[EMAIL PROTECTED]> wrote: >>> >> [snip] >> >>> I might break the IOMMU code. Can you reproduce it easily? If so, >>> reverting my IOMMU patches (I've attached a patch to revert them) fix >>> the problem? >> [snip] >> >> >> Yes, this patch fixes the problem for me. > > Thanks, so you can reproduce it easily, right? > Yes, quite easily > The problem is that I don't want to revert these changes. I'll see > how these changes cause the problem shortly. I'll try and find some bandwidth to review/test the patches and help you figure out the right solution. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: SCSI errors on powerpc with 2.6.24-rc6-mm1
On Thu, 27 Dec 2007 10:08:25 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > FUJITA Tomonori wrote: > > On Mon, 24 Dec 2007 10:18:50 +0530 > > Balbir Singh <[EMAIL PROTECTED]> wrote: > > > [snip] > > > > > I might break the IOMMU code. Can you reproduce it easily? If so, > > reverting my IOMMU patches (I've attached a patch to revert them) fix > > the problem? > > [snip] > > > Yes, this patch fixes the problem for me. Thanks, so you can reproduce it easily, right? The problem is that I don't want to revert these changes. I'll see how these changes cause the problem shortly. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: SCSI errors on powerpc with 2.6.24-rc6-mm1
FUJITA Tomonori wrote: > On Mon, 24 Dec 2007 10:18:50 +0530 > Balbir Singh <[EMAIL PROTECTED]> wrote: > [snip] > > I might break the IOMMU code. Can you reproduce it easily? If so, > reverting my IOMMU patches (I've attached a patch to revert them) fix > the problem? [snip] Yes, this patch fixes the problem for me. Tested-by: Balbir Singh <[EMAIL PROTECTED]> -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: SCSI errors on powerpc with 2.6.24-rc6-mm1
On Mon, 24 Dec 2007 10:18:50 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've just seen this on my dmesg, this is new, never seen this before on
> this box and it happens only with this version of the kernel.
>
> In this configuration, the page size is set to 64K and I've enabled fake
> NUMA nodes on PowerPC.
>
> tce_buildmulti_pSeriesLP: plpar_tce_put failed. rc=-4
> index = 0x402
> npages = 0x0
> tce[0] val = 0x15ad0001
> Call Trace:
> [cffe74f0] [c00491a4]
> .tce_buildmulti_pSeriesLP+0x26c/0x2ac (unreliable)
> [cffe75c0] [c00295e4] .iommu_map_sg+0x1d4/0x418
> [cffe76d0] [c0028664] .dma_iommu_map_sg+0x3c/0x50
> [cffe7750] [c03b6c30] .scsi_dma_map+0x70/0x94
> [cffe77d0] [c03dedbc] .ipr_queuecommand+0x300/0x500
> [cffe7880] [c03ae964] .scsi_dispatch_cmd+0x21c/0x2b8
> [cffe7920] [c03b67a0] .scsi_request_fn+0x310/0x460
> [cffe79d0] [c024ab90] .blk_run_queue+0x94/0xec
> [cffe7a70] [c03b3b08] .scsi_run_queue+0x24c/0x27c
> [cffe7b20] [c03b4424] .scsi_next_command+0x48/0x70
> [cffe7bc0] [c03b4b48] .scsi_end_request+0xbc/0xe4
> [cffe7c60] [c03b5294] .scsi_io_completion+0x170/0x3e8
> [cffe7d40] [c03ae0e4] .scsi_finish_command+0xb4/0xd4
> [cffe7dd0] [c03b584c] .scsi_softirq_done+0x114/0x138
> [cffe7e60] [c024af70] .blk_done_softirq+0xa0/0xd0
> [cffe7ef0] [c007a2a0] .__do_softirq+0xa8/0x164
> [cffe7f90] [c0027edc] .call_do_softirq+0x14/0x24
> [c0003e183950] [c000bdcc] .do_softirq+0x74/0xc0
> [c0003e1839e0] [c007a450] .irq_exit+0x5c/0xac
> [c0003e183a60] [c000c414] .do_IRQ+0x17c/0x1f4
> [c0003e183b00] [c0004c24] hardware_interrupt_entry+0x24/0x28
> --- Exception: 501 at .ppc64_runlatch_off+0x28/0x60
> LR = .pseries_dedicated_idle_sleep+0xd8/0x1a4
> [c0003e183df0] [c0048494]
> .pseries_dedicated_idle_sleep+0x78/0x1a4 (unreliable)
> [c0003e183e80] [c001110c] .cpu_idle+0x10c/0x1e8
> [c0003e183f00] [c002b5b0] .start_secondary+0x1b4/0x1d8
> [c0003e183f90] [c00083c4] .start_secondary_prolog+0xc/0x10
I might break the IOMMU code. Can you reproduce it easily? If so,
reverting my IOMMU patches (I've attached a patch to revert them) fix
the problem?
Thanks,
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index ff2a62d..59899b2 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -244,9 +244,6 @@ config IOMMU_VMERGE
Most drivers don't have this problem; it is safe to say Y here.
-config IOMMU_HELPER
- def_bool PPC64
-
config HOTPLUG_CPU
bool "Support for enabling/disabling CPUs"
depends on SMP && HOTPLUG && EXPERIMENTAL && (PPC_PSERIES || PPC_PMAC)
diff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c
index 6fcb7cb..1806d96 100644
--- a/arch/powerpc/kernel/dma_64.c
+++ b/arch/powerpc/kernel/dma_64.c
@@ -31,8 +31,8 @@ static inline unsigned long device_to_mask(struct device *dev)
static void *dma_iommu_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
{
- return iommu_alloc_coherent(dev, dev->archdata.dma_data, size,
- dma_handle, device_to_mask(dev), flag,
+ return iommu_alloc_coherent(dev->archdata.dma_data, size, dma_handle,
+ device_to_mask(dev), flag,
dev->archdata.numa_node);
}
@@ -52,7 +52,7 @@ static dma_addr_t dma_iommu_map_single(struct device *dev,
void *vaddr,
size_t size,
enum dma_data_direction direction)
{
- return iommu_map_single(dev, dev->archdata.dma_data, vaddr, size,
+ return iommu_map_single(dev->archdata.dma_data, vaddr, size,
device_to_mask(dev), direction);
}
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 18e8860..050e9ac 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -31,7 +31,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -82,19 +81,17 @@ static int __init setup_iommu(char *str)
__setup("protect4gb=", setup_protect4gb);
__setup("iommu=", setup_iommu);
-static unsigned long iommu_range_alloc(struct device *dev,
- struct iommu_table *tbl,
+static unsigned long iommu_range_alloc(struct iommu_table *tbl,
unsigned long npages,
unsigned long *handle,
unsigned long mask,
unsigned int align_order)
{
- unsi
Re: Device node - How does kernel know about it
On 12/26/07, Siva Prasad <[EMAIL PROTECTED]> wrote: > Hi, > > I am really interested in finding out how kernel knows about device > nodes and how the whole thing work. This is as part of my debugging > effort on 8641D based PowerPC board. > > * It all started with the problem of "not printing" any thing that comes > from ramdisk (echo and printf statements), while kernel printk's work > perfectly fine. > * Ramdisk is also executing fine, just that prints are not coming out of > serial. I can see the execution of various user programs with a printk > in sys_execve() routine. Ramdisk has all the required files like > /dev/console, /dev/ttyS0, etc. Does adding console=ttyS0,baud to the kernel boot command line fix it? -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Device node - How does kernel know about it
Hi, I am really interested in finding out how kernel knows about device nodes and how the whole thing work. This is as part of my debugging effort on 8641D based PowerPC board. * It all started with the problem of "not printing" any thing that comes from ramdisk (echo and printf statements), while kernel printk's work perfectly fine. * Ramdisk is also executing fine, just that prints are not coming out of serial. I can see the execution of various user programs with a printk in sys_execve() routine. Ramdisk has all the required files like /dev/console, /dev/ttyS0, etc. * Looking further into tty driver, I noticed that call to tty_write() or do_tty_write() is not happening at all. So, somewhere the interface between kernel and user program is lost. * Just to check it out, I tried to write a small kernel module and a test program. - Attached memtest.c module (not really testing memory there. :-)) - Attached testmemtest.c user program, that just open's it and reads the information - Created a device node using "mknod /dev/memtest c 168 0" - When I do "insmod memtest.ko" inside the ramdisk bootup scripts, I could see all the printk's on the console - When I execute "testmemtest" next in the same script, it does not display the printk inside of memtest.c module. This only indicates that read call did not really go to the kernel side. - Just to check my program's validity, I checked on a similar machine and all the code works fine. - "uname -r" also matches with what I built. So, chances of exiting from open call because of mismatch is remote. Since userland cannot print, I have no idea what exactly is happening there. Now going back to the original question... How does a kernel know about device nodes and how to link with it. Basically I believe interface between user programs and kernel is lost at device nodes. Appreciate any help in continuing my debugging efforts. Thanks Siva memtest.c Description: memtest.c testmemtest.c Description: testmemtest.c ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Time for cell code reshuffle?
On Wednesday 26 December 2007, Ishizaki Kou wrote: > Celleb-native needs own machine definition and setup code due to HW > and FW deferences between CellBlade and Celleb. Of course, because > Celleb-native and Celleb-Beat use some codes commonly, we need a place > to put Celleb common codes. > > But I don't know your idea is better or not. The two more sensible options I can see are * leave everything where it is, live with the problem that the separation between celleb-native, celleb-beat and ibm-native is unclear. * put both celleb and the ibm blades into the cell subdirectory, now with three different machine descriptions in there and only make sure that platforms/cell doesn't share any code with ps3, which is more clearly separated already (once we move spufs out). I'm fine either way, and will accept patches from Toshiba to merge the two directories if you prefer that, but I won't do it myself. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] MPC8360E-RDK: Device tree and board file
On Wed, Dec 26, 2007 at 07:29:44PM +0300, Anton Vorontsov wrote: > On Tue, Dec 25, 2007 at 02:44:46PM -0600, Timur Tabi wrote: > > Anton Vorontsov wrote: > > > > >Yup. I've seen it, thanks. I'm going to test it as well. ;-) > > > > If they work for you, please let Kumar know. > > Unfortunately they don't. > > [EMAIL PROTECTED]:~# echo abc > /dev/ttyQE0 > > And hang. No interrupts. I've just tried to set CD and CTS to GPIO functions (for loopbacking), as suggested in the ref manual.. and still it doesn't work. Hm.. -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2] powerpc: DBox2 Board Support
On Wednesday 26 December 2007, Jochen Friedrich wrote:
> >> + memory {
> >> + device_type = "memory";
> >> + reg = <0 200>;
> >> + };
> >
> > I thought there are both models with 32MB and 16MB available.
> > If that's true, shouldn't this be filled out by the boot loader?
>
> IIRC, the cuImage wrapper overwrites this with the boot loader
> parameters.
Then maybe set it to zero size in the dts file, and add a comment.
> OTOH, the memory is part of the localbus (CS1). Should it be a child
> of localbus in this case?
No, memory nodes are required to be at the root of the device tree
for historic reasons.
> I didn't check FB_OF. On Dbox2, the avia driver creates a
> framebuffer device.
fb_of needs some properties in the device tree set up correctly,
but is very simple otherwise. If it does all you need, it's
probably a good idea to use that and get rid of the avia framebuffer
driver
> There are two mods available using the block layer, although currently i don't
> support any of them:
>
> 1. using the GPIO lines of the modem port, it's possible to connect a SD card.
>It might be possible to use it using the GPIO SPI driver (but it would need
>some glue code to create a platform device).
>
> 2. using the memory expansion port and CS2, there is an IDE interface
> available
>with a CPLD acting as localbus/IDE bridge. There is a device driver for
>ARCH=ppc.
>
> Unfortunately, i don't own any of these modifications.
If neither of these is in the mainline kernel, it doesn't make sense to
have support for the block layer in defconfig, so just try how much
memory you can free up with this.
> >> +static void __init dbox2_setup_arch(void)
> >> +{
> >> + struct device_node *np;
> >> + static u8 __iomem *config;
> >> +
> >> + cpm_reset();
> >> + init_ioports();
> >> +
> >> + /* Enable external IRQs for AVIA chips */
> >> + clrbits32(&mpc8xx_immr->im_siu_conf.sc_siumcr, 0x0c00);
> >
> > This smells like a hack. What are AVIA chips, and shouldn't
> > their driver enable the IRQs?
>
> No. This just configures the Pin as IRQ input. Maybe, the new GPIO
> functions could be used for this, instead. Then it could be done
> in the driver (the driver should't directly mess with SIU internals).
Maybe it should then be done in the boot wrapper. If the device
tree lists this line as an interrupt, I'd say that is what it should
be.
> >> +static struct of_device_id __initdata of_bus_ids[] = {
> >> + { .name = "soc", },
> >> + { .name = "cpm", },
> >> + { .name = "localbus", },
> >> + {},
> >> +};
> >
> > Shouldn't this check for 'compatible' properties instead of 'name'?
>
> I copied this from mpc885ads_setup.c.
Right, I noticed before that we're rather inconsistent with this.
It would really be good to have more common standards on this.
> > I also once did a patch that let you have a default 'of_bus_ids'
> > member in the ppc_md. I never got around to submitting that, but
> > if there is interest, I can dig it out again.
>
> That would be nice :)
The reason I haven't submitted it yet is that I'm not sure whether
there are cases where we actually _need_ to test for 'name' instead
of 'compatible' because of existing device trees in firmware.
I might just do a patch and see if someone complains about the
idea.
Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] ucc_uart: add support for Freescale QUICCEngine UART
On Fri, Dec 07, 2007 at 10:44:30AM -0600, Timur Tabi wrote:
> Add support for UART serial ports using a Freescale QUICC Engine
> (found on some MPC83xx and MPC85xx SOCs).
>
> Updated booting-without-of.txt to define new properties for a QE UART node,
> and a new node definition that describes uploaded QE firmware.
>
> Because of a silicon bug in some QE-enabled SOCs (e.g. 8323 and 8360), a new
> microcode is required. This microcode implements UART via a work-around,
> hence it's called "Soft-UART". This driver can use the QE firmware upload
> feature to upload the correct microcode to the QE.
>
> Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
> ---
> @@ -250,6 +279,26 @@
> pio-handle = < &pio4 >;
> };
>
> + [EMAIL PROTECTED] {
> + device_type = "serial";
> + compatible = "ucc_uart";
> + model = "UCC";
model isn't used, is it needed at all?
> + device-id = <5>;/* The UCC number, 1-7*/
> + port-number = <0>; /* Which ttyQEx device */
> + soft-uart; /* We need Soft-UART */
> + reg = <2400 200>;
> + interrupts = <28>; /* From Table 18-12 */
> + interrupt-parent = < &qeic >;
> + /*
> + * For Soft-UART, we need to set TX to 1X, which
> + * means specifying separate clock sources.
> + */
> + rx-clock-name = "brg5";
> + tx-clock-name = "brg6";
> + pio-handle = < &pio5 >;
[...]
> + if (soft_uart) {
> + struct qe_firmware_info *qe_fw_info;
> +
> + qe_fw_info = qe_get_firmware_info();
> +
> + /* Check if the firmware has been uploaded. */
> + if (strstr(qe_fw_info->id, "Soft-UART")) {
qe_fw_info used w/o NULL checking.
> + firmware_loaded = 1;
> + } else {
> + char filename[32];
> + unsigned int soc;
> + unsigned int rev_h;
> + unsigned int rev_l;
> +
> + soc = soc_info(&rev_h, &rev_l);
> + if (!soc) {
> + dev_err(&ofdev->dev, "unknown CPU model\n");
> + return -ENXIO;
> + }
> + sprintf(filename, "fsl_qe_ucode_uart_%u_%u%u.bin",
> + soc, rev_h, rev_l);
> +
> + dev_info(&ofdev->dev, "waiting for firmware %s\n",
> + filename);
> +
> + /*
> + * We call request_firmware_nowait instead of
> + * request_firmware so that the driver can load and
> + * initialize the ports without holding up the rest of
> + * the kernel. If hotplug support is enabled in the
[...]
> +
> + qe_port->port.irq = irq_of_parse_and_map(np, 0);
> + if (qe_port->port.irq == NO_IRQ) {
> + dev_err(&ofdev->dev, "could not map IRQ for UCC%u\n",
> +qe_port->ucc_num + 1);
> + kfree(qe_port);
> + return -EINVAL;
> + }
> +
> + np = of_find_node_by_type(NULL, "qe");
Please, add "fsl,qe" compatible matching.
> + if (!np) {
> + dev_err(&ofdev->dev, "could not find parent 'qe' node\n");
> + kfree(qe_port);
> + return -EINVAL;
> + }
> +
[...]
> +static struct of_platform_driver ucc_uart_of_driver = {
> + .owner = THIS_MODULE,
> + .name = "ucc_uart",
Maybe better fsl,ucc_uart?
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v5] qe: add ability to upload QE firmware
On Fri, Dec 07, 2007 at 09:43:53AM -0600, Timur Tabi wrote:
> Define the layout of a binary blob that contains a QE firmware and
> instructions
> on how to upload it. Add function qe_upload_firmware() to parse the blob
> and perform the actual upload. Fully define 'struct rsp' in immap_qe.h to
> include the actual RISC Special Registers. Added description of a new
> QE firmware node to booting-without-of.txt.
> Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
> ---
>
> Argh, another booting-without-of.txt fix. There are 8 virtual traps, not 16.
>
> This patch is for Kumar's for-2.6.25 branch. This code is necessary for
> my QE UART driver.
>
> Documentation/powerpc/00-INDEX |3 +
> Documentation/powerpc/booting-without-of.txt | 33 +++-
> Documentation/powerpc/qe_firmware.txt| 295
> ++
> arch/powerpc/platforms/Kconfig |1 +
> arch/powerpc/sysdev/qe_lib/qe.c | 240 +
> include/asm-powerpc/immap_qe.h | 34 +++-
> include/asm-powerpc/qe.h | 61 ++
> 7 files changed, 663 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/powerpc/qe_firmware.txt
>
> diff --git a/Documentation/powerpc/booting-without-of.txt
> b/Documentation/powerpc/booting-without-of.txt
> index e9a3cb1..8b27711 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
...
> +
> + Example:
> +
> + firmware {
> + id = "Soft-UART";
> + extended_modes = <0 0>;
> + virtual_traps = <0 0 0 0 0 0 0 0>;
I believe using underscores for the property name is discouraged.
> + }
> +
...
> +VI - Sample Code for Creating Firmware Files
> +
> +
> +A Python program that creates firmware binaries from the header files
> normally
> +distributed by Freescale can be found on http://opensource.freescale.com.
Hm... I didn't find it there. Could you provide more specific pointer?
...
> index 1df3b4a..497eb88 100644
> --- a/arch/powerpc/sysdev/qe_lib/qe.c
> +++ b/arch/powerpc/sysdev/qe_lib/qe.c
...
> +struct qe_firmware_info *qe_get_firmware_info(void)
> +{
> + static int initialized;
> +
> + /*
> + * If we haven't checked yet, and a driver hasn't uploaded a firmware
> + * yet, then check the device tree for information.
> + */
> + do {
This is very unusual method of error handling. You could stick
to gotos and lower the indentation level.
> + struct device_node *qe;
> + struct device_node *fw = NULL;
> + const char *sprop;
> + const u32 *iprop;
> +
> + if (initialized || qe_firmware_uploaded)
> + break;
> +
> + initialized = 1;
> +
> + qe = of_find_node_by_type(NULL, "qe");
Please, add compatible "fsl,qe" matching, so this code could
work with new device trees.
> + if (!qe)
> + break;
> +
> + /* Find the 'firmware' child node */
> + while ((fw = of_get_next_child(qe, fw)))
> + if (strcmp(fw->name, "firmware") == 0)
> + break;
Hmm. Maybe of_find_node_by_name? Or better by compatible.
> +
> + /* Did we find the 'firmware' node? */
> + if (!fw) {
> + of_node_put(qe);
> + break;
> + }
> +
> + qe_firmware_uploaded = 1;
> +
> + /* Copy the data into qe_firmware_info*/
> + sprop = of_get_property(fw, "id", NULL);
> + if (sprop)
> + strncpy(qe_firmware_info.id, sprop,
> + sizeof(qe_firmware_info.id) - 1);
> +
> + iprop = of_get_property(fw, "extended_modes", NULL);
Checking for size?
> + if (iprop)
> + qe_firmware_info.extended_modes =
> + (u64) iprop[0] << 32 | iprop[1];
> +
> + iprop = of_get_property(fw, "virtual_traps", NULL);
size?
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] MPC8360E-RDK: Device tree and board file
On Tue, Dec 25, 2007 at 02:44:46PM -0600, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
> >Yup. I've seen it, thanks. I'm going to test it as well. ;-)
>
> If they work for you, please let Kumar know.
Unfortunately they don't.
[EMAIL PROTECTED]:~# echo abc > /dev/ttyQE0
And hang. No interrupts.
After ^C:
ucc_uart e0102400.ucc: shutdown timeout
The same for ttyQE1 (just for testing I set it up to not use
Soft-UART).
The same for loopback mode.
I wonder what are the symptoms if microcode is at fault? According
to errata description, hang isn't something I should get on the
transmit attempt.
> >MPC8360E, Rev: 21. Are you aware of any known issues on this chip
> >regarding UCC serials?
>
> Yep. You need a microcode upload. My patches describe everything.
Well. All I've found is: QERAMPTCH.zip ("RAM Microcode Patches for
PowerQUICC II Pro Family QE Errata"), which should fix QE_UART5 errata
for MPC8323 Rev 1.1. Can I assume it works for MPC8360 too? I've tried
it. No luck.
Here are dts entries I use:
firmware {
id = "Soft-UART";
extended_modes = <0 0>;
virtual_traps = <0 0 0 0 0 0 0 0>;
};
[EMAIL PROTECTED] {
device_type = "serial";
compatible = "ucc_uart";
reg = <0x2400 0x200>;
device-id = <5>;
port-number = <0>;
rx-clock-name = "brg7";
tx-clock-name = "brg8";
interrupts = <40>;
interrupt-parent = <&qeic>;
soft-uart;
};
[EMAIL PROTECTED] {
device_type = "serial";
compatible = "ucc_uart";
reg = <0x3400 0x200>;
device-id = <6>;
port-number = <1>;
rx-clock-name = "brg14";
tx-clock-name = "brg14";
interrupts = <41>;
interrupt-parent = <&qeic>;
};
Any ideas?
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Do not fail build if mkimage is not available
Michael Buesch <[EMAIL PROTECTED]> writes: > On Wednesday 26 December 2007 17:03:43 Andreas Schwab wrote: >> Michael Buesch <[EMAIL PROTECTED]> writes: >> >> > +set +e >> > mkimage -A ppc -O linux -T kernel -C gzip -a -e \ >> >$uboot_version -d "$vmz" "$ofile" >> > +[ $? -eq 0 ] || exit 0 >> > +set -e >> >> mkimage ... || exit 0 > > Could you PLEASE increase your verbosity? > Why is mkimage || exit 0 any better than my test? Many roads lead to Rome. Take the one you like most. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Do not fail build if mkimage is not available
Michael Buesch <[EMAIL PROTECTED]> writes: > On Wednesday 26 December 2007 17:08:55 Andreas Schwab wrote: >> > I even posted it for review on this list and nobody complained, >> > including you. >> >> ??? I did point out an error in your patch just now. > > I posted it for review a few days ago and the only response > I got was "This is probably OK for now..." from Josh. And what does this have to do with me? I didn't see your mail at all. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Do not fail build if mkimage is not available
On Wednesday 26 December 2007 17:08:55 Andreas Schwab wrote: > > I even posted it for review on this list and nobody complained, > > including you. > > ??? I did point out an error in your patch just now. I posted it for review a few days ago and the only response I got was "This is probably OK for now..." from Josh. -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Do not fail build if mkimage is not available
On Wednesday 26 December 2007 17:03:43 Andreas Schwab wrote: > Michael Buesch <[EMAIL PROTECTED]> writes: > > > +set +e > > mkimage -A ppc -O linux -T kernel -C gzip -a -e \ > > $uboot_version -d "$vmz" "$ofile" > > +[ $? -eq 0 ] || exit 0 > > +set -e > > mkimage ... || exit 0 Could you PLEASE increase your verbosity? Why is mkimage || exit 0 any better than my test? -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Do not fail build if mkimage is not available
Michael Buesch <[EMAIL PROTECTED]> writes: > I tested this and it obviously works very well for me. Obviously your tests were incomplete. > I even posted it for review on this list and nobody complained, > including you. ??? I did point out an error in your patch just now. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Do not fail build if mkimage is not available
Michael Buesch <[EMAIL PROTECTED]> writes: > +set +e > mkimage -A ppc -O linux -T kernel -C gzip -a -e \ > $uboot_version -d "$vmz" "$ofile" > +[ $? -eq 0 ] || exit 0 > +set -e mkimage ... || exit 0 Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Do not fail build if mkimage is not available
On Wednesday 26 December 2007 16:56:57 Andreas Schwab wrote: > > That would help a lot not wasting my time. > > How about testing your changes first? Stop the bullshit, please. I tested this and it obviously works very well for me. I even posted it for review on this list and nobody complained, including you. But I see what you are complaining about, now. It would also error out, if mkimage was installed (which is not the case for me. That's the whole reason for me making this patch!). Are you OK with the new version I just sent? -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: Do not fail build if mkimage is not available
This fixes the boot image wrapper script to not fail the kernel build if mkimage is not available. As some distributions don't ship the mkimage program and some people are not interested in uboot images anyway, we don't want to fail the whole kernel build process because of this unneeded dependency. Simply drop an error message, but don't fail the build. Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> --- Josh Boyer is working on merging mkimage into the kernel tree. Until that happened, please merge the patch below into the mainline kernel to avoid build breakage for people without installed uboot tools. Index: wireless-2.6/arch/powerpc/boot/wrapper === --- wireless-2.6.orig/arch/powerpc/boot/wrapper 2007-12-26 16:48:47.0 +0100 +++ wireless-2.6/arch/powerpc/boot/wrapper 2007-12-26 16:52:58.0 +0100 @@ -197,8 +197,11 @@ fi case "$platform" in uboot) rm -f "$ofile" +set +e mkimage -A ppc -O linux -T kernel -C gzip -a -e \ $uboot_version -d "$vmz" "$ofile" +[ $? -eq 0 ] || exit 0 +set -e if [ -z "$cacheit" ]; then rm -f "$vmz" fi @@ -254,8 +257,11 @@ coff) ;; cuboot*) gzip -f -9 "$ofile" +set +e mkimage -A ppc -O linux -T kernel -C gzip -a "$base" -e "$entry" \ $uboot_version -d "$ofile".gz "$ofile" +[ $? -eq 0 ] || exit 0 +set -e ;; treeboot*) mv "$ofile" "$ofile.elf" ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Do not fail build if mkimage is not available
Michael Buesch <[EMAIL PROTECTED]> writes: > On Wednesday 26 December 2007 16:33:57 Andreas Schwab wrote: >> Michael Buesch <[EMAIL PROTECTED]> writes: >> >> > On Wednesday 26 December 2007 15:47:05 Andreas Schwab wrote: >> >> Michael Buesch <[EMAIL PROTECTED]> writes: >> >> >> >> > +if ! [ -x mkimage ]; then >> >> >> >> What is this supposed to test? >> > >> > from man test: >> >> You didn't answer my question. > > I'm not sure how I can make the manual text any clearer I know very well what it *does*, thank you. But that does mean that is does what it is *supposed* to do. >-x FILE > FILE exists and execute (or search) permission is granted > It tests if the program exists and is executable. ^^^ Observe the fine difference in the choice of words. > That would help a lot not wasting my time. How about testing your changes first? Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Do not fail build if mkimage is not available
On Wednesday 26 December 2007 16:33:57 Andreas Schwab wrote: > Michael Buesch <[EMAIL PROTECTED]> writes: > > > On Wednesday 26 December 2007 15:47:05 Andreas Schwab wrote: > >> Michael Buesch <[EMAIL PROTECTED]> writes: > >> > >> > +if ! [ -x mkimage ]; then > >> > >> What is this supposed to test? > > > > from man test: > > You didn't answer my question. I'm not sure how I can make the manual text any clearer -x FILE FILE exists and execute (or search) permission is granted It tests if the program exists and is executable. Could you please be more specific about what you don't understand? That would help a lot not wasting my time. -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Do not fail build if mkimage is not available
Michael Buesch <[EMAIL PROTECTED]> writes: > On Wednesday 26 December 2007 15:47:05 Andreas Schwab wrote: >> Michael Buesch <[EMAIL PROTECTED]> writes: >> >> > +if ! [ -x mkimage ]; then >> >> What is this supposed to test? > > from man test: You didn't answer my question. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] powerpc: DBox2 Board Support
Hi David,
+ // Port D is LCD exclusive. Don't export as GPIO
+ CPM1_PIO: [EMAIL PROTECTED] {
+ compatible = "fsl,cpm1-pario";
+ reg = <970 180>;
+ num-ports = <3>;
+ #gpio-cells = <2>;
+ };
+
+ [EMAIL PROTECTED] {
+ reg = <970 10>;
+ compatible = "samsung,ks0713";
>>> Is this representing an LCD controller, or the display itself. Either
>>> way I'm surprised there's something here in the SoC that has a
>>> compatible string that's not "fsl,something"
>> It's a LCD controller wired to PortD. PortD is used for four 1bit lines
>> and one 8bit bus.
>
> I'm still kind of confused here. Does the [EMAIL PROTECTED] node above
> represent the PortD controller? If the LCD controller is accessed
> solely through PortD, then it should be a child of the PortD node.
>
> At present, pio and lcd have overlapping reg resources which is
> certainly wrong.
>
[EMAIL PROTECTED] represent 4 ports (A-D). Ports A-C are used as GPIO lines.
Port D
is exclusively used for the LCD, but it needs an 8bit accessor. Unfortunately,
the GPIO API doesn't have such an accessor, so the LCD driver needs to access
Port D itself and needs to make sure no other driver can access Port D via the
GPIO API. The representation as child of pio seems reasonable.
Thanks,
Jochen
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Do not fail build if mkimage is not available
On Wednesday 26 December 2007 15:47:05 Andreas Schwab wrote: > Michael Buesch <[EMAIL PROTECTED]> writes: > > > +if ! [ -x mkimage ]; then > > What is this supposed to test? from man test: -x FILE FILE exists and execute (or search) permission is granted -- Greetings Michael. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2] powerpc: DBox2 Board Support
Hi Arnd,
>> This patch adds device tree source, default config and setup code for
>> DBox2 devices.
>
ia > Cool stuff. I used to have one of these boxes myself, maybe I should
> get one again when it's hitting mainline.
>
> Is this already a complete port, or do you also need some device
> drivers or boot wrapper code to go along with it?
Currently, it needs the u-boot patches from cvs.tuxbox.org and some
external device drivers (however, they can all be loaded as modules).
The port is complete enough to get a console on the serial port and
a rootfs either on flash or on nfs.
>> +memory {
>> +device_type = "memory";
>> +reg = <0 200>;
>> +};
>
> I thought there are both models with 32MB and 16MB available.
> If that's true, shouldn't this be filled out by the boot loader?
IIRC, the cuImage wrapper overwrites this with the boot loader
parameters.
OTOH, the memory is part of the localbus (CS1). Should it be a child
of localbus in this case?
>> +#
>> +# Frame buffer hardware drivers
>> +#
>> +# CONFIG_FB_OF is not set
>> +# CONFIG_FB_VGA16 is not set
>> +# CONFIG_FB_S1D13XXX is not set
>> +# CONFIG_FB_IBM_GXT4500 is not set
>> +# CONFIG_FB_VIRTUAL is not set
>> +# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
>
> No hardware framebuffer driver? Can't you use
> the FB_OF driver by default? I'd guess that a
> set-top box without output is rather pointless ;-)
I didn't check FB_OF. On Dbox2, the avia driver creates a
framebuffer device.
>> +# DOS/FAT/NT Filesystems
>> +#
>> +CONFIG_FAT_FS=y
>> +CONFIG_MSDOS_FS=y
>> +CONFIG_VFAT_FS=y
>> +CONFIG_FAT_DEFAULT_CODEPAGE=437
>> +CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
>> +# CONFIG_NTFS_FS is not set
>
> What media can you connect that use the FAT file system?
>
> I'd guess that if you can get rid of these, you can also
> disable the entire block layer, which should free up
> some kernel memory.
There are two mods available using the block layer, although currently i don't
support any of them:
1. using the GPIO lines of the modem port, it's possible to connect a SD card.
It might be possible to use it using the GPIO SPI driver (but it would need
some glue code to create a platform device).
2. using the memory expansion port and CS2, there is an IDE interface available
with a CPLD acting as localbus/IDE bridge. There is a device driver for
ARCH=ppc.
Unfortunately, i don't own any of these modifications.
>> +
>> +/* Vendor information in BR Bootloader
>> + */
>> +
>> +#define DBOX2_VENDOR_OFFSET (0x1ffe0)
>> +
>> +enum dbox2_mid {
>> +DBOX2_MID_NOKIA = 1,
>> +DBOX2_MID_PHILIPS = 2,
>> +DBOX2_MID_SAGEM = 3,
>> +};
>> +
>> +enum dbox2_mid dbox2_get_mid(void);
>
> Can you move this functionality from the kernel to the boot wrapper?
> It looks like this is something that really belongs into the device
> tree.
OK.
>> +if (dbox2_manuf_id == DBOX2_MID_NOKIA)
>> +np = of_find_node_by_path("/[EMAIL PROTECTED]/[EMAIL
>> PROTECTED]");
>> +else
>> +np = of_find_node_by_path("/[EMAIL PROTECTED]/[EMAIL
>> PROTECTED]");
>> +
>> +if (np) {
>> +of_detach_node(np);
>> +of_node_put(np);
>> +}
>> +
>> +if (dbox2_manuf_id == DBOX2_MID_PHILIPS)
>> +np = of_find_node_by_path("/[EMAIL PROTECTED]/[EMAIL
>> PROTECTED]");
>> +else
>> +np = of_find_node_by_path("/[EMAIL PROTECTED]/[EMAIL
>> PROTECTED]");
>> +
>> +if (np) {
>> +of_detach_node(np);
>> +of_node_put(np);
>> +}
>> +}
>
> What is this code for? Why do you want to detach nodes from the device
> tree that have been put in there by the boot loader?
There are small differences between the 3 manufacturers. I guess this
should go to the boot wrapper, as well.
This is even more important if the localbus uses #address-cells = <2>, as
the differen manufacturers set up the address mapping for CS3, CS5 and CS7
differently.
>> +static void __init dbox2_setup_arch(void)
>> +{
>> +struct device_node *np;
>> +static u8 __iomem *config;
>> +
>> +cpm_reset();
>> +init_ioports();
>> +
>> +/* Enable external IRQs for AVIA chips */
>> +clrbits32(&mpc8xx_immr->im_siu_conf.sc_siumcr, 0x0c00);
>
> This smells like a hack. What are AVIA chips, and shouldn't
> their driver enable the IRQs?
No. This just configures the Pin as IRQ input. Maybe, the new GPIO
functions could be used for this, instead. Then it could be done
in the driver (the driver should't directly mess with SIU internals).
>> +static struct of_device_id __initdata of_bus_ids[] = {
>> +{ .name = "soc", },
>> +{ .name = "cpm", },
>> +{ .name = "localbus", },
>> +{},
>> +};
>
> Shouldn't this check for 'compatible' properties instead of 'name'?
I copied this from mpc885ads_setup.c.
>> +static int __init declare_of_platform_devices(void)
>> +{
>> +/* Publish the QE devices */
>> +if (machine_is(dbox2))
>> +o
Re: [PATCH] powerpc: Do not fail build if mkimage is not available
Michael Buesch <[EMAIL PROTECTED]> writes: > +if ! [ -x mkimage ]; then What is this supposed to test? Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Do not fail build if mkimage is not available
This fixes the boot image wrapper script to not fail the kernel build if mkimage is not available. As some distributions don't ship the mkimage program and some people are not interested in uboot images anyway, we don't want to fail the whole kernel build process because of this unneeded dependency. Simply drop an error message, but don't fail the build. Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> --- Josh Boyer is working on merging mkimage into the kernel tree. Until that happened, please merge the patch below into the mainline kernel to avoid build breakage for people without installed uboot tools. Index: wireless-2.6/arch/powerpc/boot/wrapper === --- wireless-2.6.orig/arch/powerpc/boot/wrapper 2007-12-23 20:10:07.0 +0100 +++ wireless-2.6/arch/powerpc/boot/wrapper 2007-12-23 20:22:41.0 +0100 @@ -195,6 +195,14 @@ if [ -n "$version" ]; then fi case "$platform" in +cuboot* | uboot) +if ! [ -x mkimage ]; then +echo "mkimage not available. Can not create $platform image." +exit 0 +fi +esac + +case "$platform" in uboot) rm -f "$ofile" mkimage -A ppc -O linux -T kernel -C gzip -a -e \ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Time for cell code reshuffle?
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > On Fri, 2007-12-21 at 20:15 +0100, Arnd Bergmann wrote: > > > It seems platforms/cell should have the shared and/or generic code, > > and the other > > > stuff moved into a new platform directory, but is it worth the > > effort? > > > > There is very little code in platforms/cell that can not be generic, > > so I think > > it's not worth splitting it. The only IBM blade specific files are > > cbe_cpufreq_pmi.c and parts of setup.c and pervasive.c. Everything > > else could > > be shared by about any generic implementation without a hypervisor. > > Another option is to have: > > platforms/celleb -> platforms/beat > > and withing platforms/cell, rename blade specific files to > something (can't find what, works on CAB too) and add celleb > "bare metal" files. > > A platform directly doesn't have to deal with one platform. For example, > platforms/44x contains a lot of board support. > > Now, one question is how far can we merge celleb support with the common > blade/CAB code... Celleb-native needs own machine definition and setup code due to HW and FW deferences between CellBlade and Celleb. Of course, because Celleb-native and Celleb-Beat use some codes commonly, we need a place to put Celleb common codes. But I don't know your idea is better or not. Best regards, Kou Ishizaki ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
