* Re: Flash programming using a BDI2000 on a MPC8248 CPU
From: Laurent Pinchart @ 2006-11-06 12:38 UTC (permalink / raw)
To: Adrian Cox; +Cc: linuxppc-embedded
In-Reply-To: <1162815970.20962.3.camel@localhost.localdomain>
> > The workspace is in internal RAM, mapped at address 0x00000000 (the
> > hardware reset configuration register is 0x00000000). I tried setting
> > IMMR to 0xf0000000 and mapping the SDRAM at 0x00000000, without success.
> > The BDI2000 reports successfull flash programming, but the flash is
> > definitely empty.
>
> I've also had problems with 8260 family flash programming caused by the
> processor reading the Hard Reset Configuration Word from flash before
> the BDI takes over. Does your board allow you to change RSTCONF to stop
> the processor reading the HRCW?
Yes it does. The HRCW is set to 0x00000000 by deasserting RSTCONF (logic
high). All tests were made with RSTCONF high (and thus HRCW equal to
0x00000000).
Laurent Pinchart
^ permalink raw reply
* Re: Flash programming using a BDI2000 on a MPC8248 CPU
From: Abdul Rahaman @ 2006-11-06 12:42 UTC (permalink / raw)
To: Adrian Cox, Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <1162815970.20962.3.camel@localhost.localdomain>
You should have RSTCONF pulled UP or LOW.
Use any jumper or something.Only then debugger can take control of target.
But usually once debugger takes control of processor HRCW is not read by
processor(8260).
-Rahaman
----- Original Message -----
From: "Adrian Cox" <adrian@humboldt.co.uk>
To: "Laurent Pinchart" <laurent.pinchart@tbox.biz>
Cc: <linuxppc-embedded@ozlabs.org>
Sent: Monday, November 06, 2006 5:56 PM
Subject: Re: Flash programming using a BDI2000 on a MPC8248 CPU
> On Mon, 2006-11-06 at 13:16 +0100, Laurent Pinchart wrote:
> > The workspace is in internal RAM, mapped at address 0x00000000 (the
hardware
> > reset configuration register is 0x00000000). I tried setting IMMR to
> > 0xf0000000 and mapping the SDRAM at 0x00000000, without success. The
BDI2000
> > reports successfull flash programming, but the flash is definitely
empty.
>
> I've also had problems with 8260 family flash programming caused by the
> processor reading the Hard Reset Configuration Word from flash before
> the BDI takes over. Does your board allow you to change RSTCONF to stop
> the processor reading the HRCW?
>
> --
> Adrian Cox <adrian@humboldt.co.uk>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* [PATCH] CPM_UART: Fixed SMC handling for CPM2 processors
From: Kalle Pokki @ 2006-11-06 13:29 UTC (permalink / raw)
To: linuxppc-embedded, Vitaly Bordug, Paul Mackerras
SMC handling is broken in two places when using then platform device
approach with CPM2 devices.
1. The resources in pq2_devices are not named "regs" and "pram", thus they
are not found in cpm_uart_drv_get_platform_data().
2. The code in cpm_uart_drv_get_platform_data() assumes the parameter RAM
is at "pram". With SMCs of CPM2 devices, "pram" is just a pointer to the
actual parameter RAM, which the code should reserve somewhere in DPRAM.
This patch renames these the two existing resources, and introduces a new one,
"pram_base", which is a pointer to the parameter RAM. The parameter RAM for SMC1
and SMC2 is put in the first 128 bytes of the DPRAM. This memory was already
reserved from the DPRAM memory allocator for this purpose.
Signed-off-by: Kalle Pokki <kalle.pokki@iki.fi>
---
arch/ppc/syslib/pq2_devices.c | 24 ++++++++++++++++++------
drivers/serial/cpm_uart/cpm_uart_core.c | 8 +++++++-
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/arch/ppc/syslib/pq2_devices.c b/arch/ppc/syslib/pq2_devices.c
index fefbc21..e8f7ba2 100644
--- a/arch/ppc/syslib/pq2_devices.c
+++ b/arch/ppc/syslib/pq2_devices.c
@@ -286,16 +286,22 @@ struct platform_device ppc_sys_platform_
[MPC82xx_CPM_SMC1] = {
.name = "fsl-cpm-smc",
.id = 1,
- .num_resources = 3,
+ .num_resources = 4,
.resource = (struct resource[]) {
{
- .name = "smc_mem",
+ .name = "regs",
.start = 0x11A80,
.end = 0x11A8F,
.flags = IORESOURCE_MEM,
},
{
- .name = "smc_pram",
+ .name = "pram",
+ .start = PROFF_SMC1,
+ .end = PROFF_SMC1 + 63,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "pram_base",
.start = 0x87fc,
.end = 0x87fd,
.flags = IORESOURCE_MEM,
@@ -310,16 +316,22 @@ struct platform_device ppc_sys_platform_
[MPC82xx_CPM_SMC2] = {
.name = "fsl-cpm-smc",
.id = 2,
- .num_resources = 3,
+ .num_resources = 4,
.resource = (struct resource[]) {
{
- .name = "smc_mem",
+ .name = "regs",
.start = 0x11A90,
.end = 0x11A9F,
.flags = IORESOURCE_MEM,
},
{
- .name = "smc_pram",
+ .name = "pram",
+ .start = PROFF_SMC2,
+ .end = PROFF_SMC2 + 63,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "pram_base",
.start = 0x88fc,
.end = 0x88fd,
.flags = IORESOURCE_MEM,
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
index 4047530..55419b1 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -1024,7 +1024,7 @@ int cpm_uart_drv_get_platform_data(struc
int idx = pdata->fs_no; /* It is UART_SMCx or UART_SCCx index */
struct uart_cpm_port *pinfo;
int line;
- u32 mem, pram;
+ u32 mem, pram, pram_base;
line = cpm_uart_id2nr(idx);
if(line < 0) {
@@ -1049,6 +1049,12 @@ int cpm_uart_drv_get_platform_data(struc
return -EINVAL;
pram = r->start;
+ r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pram_base");
+ if (r) {
+ pram_base = r->start;
+ out_be16((u16 *)pram_base, pram & 0xffff);
+ }
+
if(idx > fsid_smc2_uart) {
pinfo->sccp = (scc_t *)mem;
pinfo->sccup = (scc_uart_t *)pram;
--
1.4.1.1
^ permalink raw reply related
* Kernel 2.6.18 and JFFS2 Filesystem problem
From: mvw @ 2006-11-06 13:30 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
i dont know what my mistake.
What files do i need for a filesystem?
Is it correct to build the filesystem with these parameters?
--> mkfs.jffs2 -r dir -o jffs2 -e 0x40000 -p
-------------------------------------------------------------------------
Probing MTD map driver for board flash at physical address 0x0(16-bit bank)
MTD map driver for board: Found 1 x16 devices at 0x0 in 16-bit bank
Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
Using default (built-in) partition definition
Creating 4 MTD partitions on "MTD map driver for board":
0x00000000-0x00020000 : "uboot"
0x00020000-0x00040000 : "environment"
0x00040000-0x00140000 : "kernel"
0x00140000-0x00f40000 : "jffs2"
mice: PS/2 mouse device common for all mice
VFS: Mounted root (jffs2 filesystem).
Freeing init memory: 60K
(nothing is displayed)
--------------------------------------------------------------------------
Thank you for your help.
armin
--
GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist!
NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl
^ permalink raw reply
* Ramdisk of ELDK 3.1.1 not run
From: tran vanle @ 2006-11-06 14:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 4136 bytes --]
Hi every one
I had used kernel of ELDK 3.1.1 and Ramdisk of ELDK 4.0 on board MPC8xxL .It run ok but I see it will meet trouble :D
When I use kernel and Ramdisk of ELDK 3.1.1 for MPC8xxL (I only rebuild Kernel use oldconfig and use uRamdisk in source (not rebuild )) but I receive error
////////////////////////////////////////////////////////////////////////////
Bootm 40040000 40400000 ## Booting image at 40040000 ...
Image Name: Linux-2.4.25
Created: 2006-11-06 12:51:51 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 712087 Bytes = 695.4 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 40400000 ...
Image Name: Simple Embedded Linux Framework
Created: 2005-06-07 12:59:15 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1625993 Bytes = 1.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 00e1f000, end 00fabf89 ... OK
Linux version 2.4.25 (root@main) (gcc version 3.3.3 (DENX ELDK 3.1.1 3.3.3-10)) #1 Mon Nov 6 19:50:02 ICT 2006
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line:
Decrementer Frequency = 300000000/60
Calibrating delay loop... 79.66 BogoMIPS
Memory: 12912k available (1212k kernel code, 408k data, 56k init, 0k highmem)
Dentry cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
CPM UART driver version 0.04
ttyS0 at 0x0280 is on SMC1 using BRG1
ttyS1 at 0x0380 is on SMC2 using BRG2
pty: 256 Unix98 ptys configured
Status LED driver $Revision: 1.0 $ initialized
eth0: CPM ENET Version 0.2 on SCC1, 00:d0:93:0e:7b:d2
eth1: FEC ENET Version 0.3, FEC irq 9, with MDIO, MII irq 12, addr 00:d0:93:0e:7b:d3
eth1: no PHY found - interface inoperative
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
PCMCIA slot B: phys mem e0000000...ec000000 (size 0c000000)
No card in slot B: PIPR=ff00ff00
TQM8xxL0: Found 2 x16 devices at 0x0 in 32-bit mode
TQM8xxL0: Found 2 x16 devices at 0x400000 in 32-bit mode
Amd/Fujitsu Extended Query Table at 0x0040
number of CFI chips: 2
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
TQM flash bank 0: Using static image partition definition
Creating 7 MTD partitions on "TQM8xxL0":
0x00000000-0x00040000 : "u-boot"
0x00040000-0x00100000 : "kernel"
0x00100000-0x00200000 : "user"
0x00200000-0x00400000 : "initrd"
0x00400000-0x00600000 : "cramfs"
0x00600000-0x00800000 : "jffs"
0x00400000-0x00800000 : "big_fs"
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 2048)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 1587k freed
VFS: Mounted root (ext2 filesystem).
VFS: Cannot open root device "" or 00:00
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 00:00
<0>Rebooting in 180 seconds..
///////////////////////////////////////////////////////////////////////////
What I miss?May i correct it
I also build kernel Linux 2.6.11.7 use tosati patch and config ,but when I want this kernel support virtual terminal it hang.May I correct it?
Please help me
Thanks
LeVan
Send instant messages to your online friends http://au.messenger.yahoo.com
[-- Attachment #2: Type: text/html, Size: 4914 bytes --]
^ permalink raw reply
* Toolchain to 'use' u-boot (was: Re: Please give your feedback)
From: Clemens Koller @ 2006-11-06 14:43 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <OF6157E3D5.6B060538-ON6525721E.00258EC0-6525721E.00261A01@lntemsys.com>
Hi, Manjunath!
Please add a proper subject to your postings next time.
> 1. I am using toolchain which support u-boot 1.1.1 and i could not get
> toolchain that support u-boot 1.1.3 and above in the net as well as in
> Freescale site,
> Please suggest me where i can download the toolchain to use u-boot1.1.3
http://www.denx.de -> ELDK
but any other properly configured current toolchain should be able to compile
u-boot. For questions regarding u-boot, please see the dedicated mailing list.
Google should be able tell you all that, too.
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
* Re: [PATCH 2.6.19 1/4] ehca: assure 4k alignment for firmware control block in 64k page mode
From: Heiko Carstens @ 2006-11-06 14:58 UTC (permalink / raw)
To: Hoang-Nam Nguyen; +Cc: linuxppc-dev, linux-kernel, openib-general, raisch
In-Reply-To: <200611052140.38445.hnguyen@de.ibm.com>
> +#ifdef CONFIG_PPC_64K_PAGES
> +void *ehca_alloc_fw_ctrlblock(void);
> +void ehca_free_fw_ctrlblock(void *ptr);
> +#else
> +#define ehca_alloc_fw_ctrlblock() get_zeroed_page(GFP_KERNEL)
> +#define ehca_free_fw_ctrlblock(ptr) free_page((unsigned long)(ptr))
> +#endif
Maybe you want to make sure that ehca_alloc_fw_ctrlblock() always returns a
void pointer, so you can avoid all the casts in your code?
static inline void *ehca_alloc_fw_ctrlblock(void)
{
return (void *)get_zeroed_page(GFP_KERNEL);
}
^ permalink raw reply
* Re: APUS and IOs question
From: Simon Richter @ 2006-11-06 15:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1162767333.28571.254.camel@localhost.localdomain>
Hi,
Benjamin Herrenschmidt wrote:
> Somebody who understands APUS around ?
I have one, but I don't understand all of it. :-)
> In include/asm-ppc/io.h, we have a special definition of the PCI IO
> accessors readw,writew,readl and writel for APUS that don't do byteswap
> and also don't do barriers.
APUS PCI is weird, to say the least. The PCI extension is basically
built to accomodate a single PCI device, which happens to be a Permedia2
graphics chip that allows byte-swapped mappings of both register and
framebuffer space and is never told to do DMA because nobody knows what
kind of interesting effects that would have, so the only synchronisation
that is needed is between accesses to the framebuffer and the GPU.
That, and that the 604e+ probably doesn't reorder accesses that much
anyway that the barriers would do any good here. :-)
Simon
^ permalink raw reply
* Re: [PATCH] Xilinx UART Lite 2.6.18 driver
From: Peter Korsgaard @ 2006-11-06 15:44 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <609d5c8e0610301145y30d058afs467d27d344149936@mail.gmail.com>
>>>>> "David" == David Bolcsfoldi <dbolcsfoldi@gmail.com> writes:
Hi,
>> This doesn't help much as you don't use the com_port argument in
>> the other functions.
David> True, it's utterly useless. I was planning on having an array
David> with base addresses which would be used to support the com_port
David> argument. But it didn't make it in this patch although I have
David> version that does this now.
You don't even need an array - you can use use the base address as the
com_port cookie, E.G.:
--- /dev/null
+++ linux-trunk/arch/ppc/boot/simple/uartlite_tty.c
@@ -0,0 +1,86 @@
+/*
+ * Boot support for Xilinx uartlite
+ *
+ * Copyright (C) 2006 David Bolcsfoldi <dbolcsfoldi@gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <asm/io.h>
+#include <linux/serial_uartlite.h>
+#include <platforms/4xx/xparameters/xparameters.h>
+
+unsigned long serial_init(int chan, void *ignored)
+{
+ unsigned long com_port = 0;
+
+ switch (chan) {
+#ifdef XPAR_UARTLITE_0_BASEADDR
+ case 0:
+ com_port = XPAR_UARTLITE_0_BASEADDR + 3;
+ break;
+#endif
+#ifdef XPAR_UARTLITE_1_BASEADDR
+ case 1:
+ com_port = XPAR_UARTLITE_1_BASEADDR + 3;
+ break;
+#endif
+#ifdef XPAR_UARTLITE_2_BASEADDR
+ case 2:
+ com_port = XPAR_UARTLITE_2_BASEADDR + 3;
+ break;
+#endif
+#ifdef XPAR_UARTLITE_3_BASEADDR
+ case 3:
+ com_port = XPAR_UARTLITE_3_BASEADDR + 3;
+ break;
+#endif
+ default:
+ break;
+ }
+
+ if (com_port) {
+ void __iomem *base = (void __iomem*)com_port;
+ writeb(0, base + ULITE_CONTROL);
+ writeb(ULITE_CONTROL_RST_RX | ULITE_CONTROL_RST_TX,
+ base + ULITE_CONTROL);
+ writeb(0, base + ULITE_CONTROL);
+ }
+
+ return com_port;
+}
+
+
+int serial_tstc(unsigned long com_port)
+{
+ void __iomem *base = (void __iomem*)com_port;
+
+ if (base)
+ return readb(base + ULITE_STATUS) & ULITE_STATUS_RXVALID;
+ else
+ return 0;
+}
+
+void serial_putc(unsigned long com_port, unsigned char c)
+{
+ void __iomem *base = (void __iomem*)com_port;
+
+ if (base) {
+ while (readb(base + ULITE_STATUS) & ULITE_STATUS_TXFULL);
+ writeb(c, base + ULITE_TX);
+ }
+}
+
+unsigned char serial_getc(unsigned long com_port)
+{
+ void __iomem *base = (void __iomem*)com_port;
+
+ if (base) {
+ while (!serial_tstc(com_port));
+ return readb(base + ULITE_RX);
+ }
+ else
+ return 0;
+}
>> Where did you get the XPAR_XUL_UART_ defines from? Our
>> xparameters.h seem to contain XPAR_UARTLITE_ defines instead.
David> I think that name is picked up from the name of the device in your
David> design, the defines get names XPAR_NNN_ and mine are called
David> XUL_UART.
Crap - Ok, then people just have to add linux-compatible defines to
the end of their xparameters.h - E.G
#define XPAR_UARTLITE_0_BASEADDR XPAR_XUL_UART_BASEADDR
>> You can always use the ppc_md.progress() stuff for really early
>> debugging if needed. I would prefer to keep this workaround out of
>> uartlite.c if it isn't needed.
David> I am pretty certain probe won't get called until ppc_sys_init has been
David> called which is fairly far into the booting process and even if
David> it did the platform_bus hasn't been initialized before the
David> ppc_sys_init is called, at least not with any of the devices
David> exported by ppc_sys_devices.
True. For really early stuff you'll need to use ppc_md.progress() (or
some additional hacking)
David> Thanks for the review! David
You're welcome.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 2.6.19 1/4] ehca: assure 4k alignment for firmware control block in 64k page mode
From: Hoang-Nam Nguyen @ 2006-11-06 16:13 UTC (permalink / raw)
To: heicars2; +Cc: linuxppc-dev, Christoph Raisch, linux-kernel, openib-general
In-Reply-To: <20061106145839.GA9387@osiris.boeblingen.de.ibm.com>
heicars2@de.ltcfwd.linux.ibm.com wrote on 06.11.2006 15:58:39:
> Maybe you want to make sure that ehca_alloc_fw_ctrlblock() always returns
a
> void pointer, so you can avoid all the casts in your code?
> static inline void *ehca_alloc_fw_ctrlblock(void)
> {
> return (void *)get_zeroed_page(GFP_KERNEL);
> }
Yes, good point. That helps to avoid different warnings between
4k and 64k page modes.
Thx
Nam
^ permalink raw reply
* Re: fixup_bigphys_addr and ioremap64 question
From: Matt Porter @ 2006-11-06 16:45 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev list
In-Reply-To: <1162786580.19697.9.camel@crusty.rchland.ibm.com>
On Sun, Nov 05, 2006 at 10:16:20PM -0600, Josh Boyer wrote:
> On Mon, 2006-11-06 at 15:09 +1100, Benjamin Herrenschmidt wrote:
> > > > So why do we have both ioremap and ioremap64 knowing that the former is
> > > > defined to take a phys_addr_t argument ?
> > > >
> > > > Currently, we have both, with the only difference being that ioremap
> > > > calls ioremap64 but also passes the argument through a
> > > > fixup_bigphys_addr() function first.
> > > >
> > > > It took me a while to find it ... it's not defined in generic code but
> > > > in platform code (ugh !). In fact, the only version of it we have in
> > > > arch/powerpc is in the 85xx support and does:
> > >
> > > It's in arch/ppc/syslib/44x_common.c and it's used to trap the least
> > > significant 32 bits of an address and set the right ERPN for io space on
> > > 44x. Something like that might be needed when 44x merges to
> > > arch/powerpc.
> >
> > Well, my point is that since nowadays we have 64 bits struct resource
> > and 64 bits phys_addr_t passed to ioremap, do we still need that ? In
> > fact, in my upcoming patch merging io.h for 32 and 64 bits in
> > asm-powerpc, I've simply removed that hook and ioremap64 :-) I can add
> > it back still, but so far, I yet have to be convinced there is still a
> > good reason for that hook.
>
> Hm.. that might be ok. I'm hoping to get back to working on something
> soon so I'll be able to tell more later. Maybe Matt knows for sure.
Yes, that's the right way to go. The history on this is that when
the 64-bit resource change came relatively recently, ioremap64 and
friends weren't killed off in arch/ppc. ioremap64 only existed because
a long time ago several people blocked the idea of 64-bit resources
(on 32-bit platforms) and we needed a way around it plus all the
fixup garbage. Going forward, we now can handle everything through
ioremap() with no fixup stuff. There's a related issue with mmap and
64-bits but that's a separate issue yet that should now be addressed.
> It'll probably break out-of-tree drivers though once the merge happens
> for 4xx. Could we leave ioremap64 around for a bit with a deprecation
> warning?
The kernel APIs break all the time. Every out of tree driver has to
have that built into their expectation when moving to a new kernel
so I don't see a good reason for making a special case here.
-Matt
^ permalink raw reply
* Re: APUS and IOs question
From: Segher Boessenkool @ 2006-11-06 16:45 UTC (permalink / raw)
To: Simon Richter; +Cc: linuxppc-dev
In-Reply-To: <454F5259.3020107@hogyros.de>
> That, and that the 604e+ probably doesn't reorder accesses that much
> anyway that the barriers would do any good here. :-)
Is there any reason though to have APUS-specific I/O accessors
instead of using the generic stuff (except for perhaps a minor
performance hit)?
Segher
^ permalink raw reply
* Re: [PATCH 2.6.19 1/4] ehca: assure 4k alignment for firmware control block in 64k page mode
From: Roland Dreier @ 2006-11-06 16:50 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-kernel, openib-general, linuxppc-dev, raisch
In-Reply-To: <200611060045.59074.arnd@arndb.de>
> I'd simply move the memset into the alloc function and get rid of the
> constructor here.
Slightly better still would be to use kmem_cache_zalloc() (save a tiny
bit of text by getting rid of the call to memset).
- R.
^ permalink raw reply
* Re: [PATCH 2.6.19 1/4] ehca: assure 4k alignment for firmware control block in 64k page mode
From: Roland Dreier @ 2006-11-06 16:51 UTC (permalink / raw)
To: Hoang-Nam Nguyen
Cc: Arnd Bergmann, linux-kernel, openib-general, linuxppc-dev,
Christoph Raisch
In-Reply-To: <OF69697CF5.13DC8781-ONC125721E.0039CD42-C125721E.003A3D50@de.ibm.com>
> As Arnd stated I need to fix this ctor issue. Do you prefer me to resend
> all patches in proper format (non-mangled inline) or just this one bug fix?
I have the rest of the patches, so you just need to resend a fixed
version of this one. BTW see my previous response about
kmem_cache_zalloc() -- I think that's the best way to fix this.
In the future though if you can make a patch-sending script or
something that lets you avoid the attachments that would be great.
^ permalink raw reply
* Re: Can't build drivers/infiniband/hw/ipath/ipath_keys.c on arch/powerpc
From: Roland Dreier @ 2006-11-06 16:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: support, openib-general, Andrew Morton, linuxppc-dev list
In-Reply-To: <1162800409.28571.298.camel@localhost.localdomain>
> I'm surprised that something as recent as infiniband requires a
> long-deprecated function bus_to_virt().
>
> What is it trying to do there that needs that call ?
Don't ask -- just enjoy the fact that you don't know about this...
^ permalink raw reply
* Re: Has anyone 2.6 kernel with Xenomai and MPC5200 Lite running?
From: Grant Likely @ 2006-11-06 16:54 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20061105102328.GH79990@server.idefix.loc>
On 11/5/06, Matthias Fechner <idefix@fechner.net> wrote:
> Hello Grant,
>
> * Grant Likely <grant.likely@secretlab.ca> [04-11-06 20:32]:
> > Yup, there exists patches for all the functionality that you're
> > looking for. You can find them if you search the list, but I'll send
> > you a link to a git tree with all those patches in it later tonight.
>
> you maybe mean:
> http://gitbits.246tNt.com/gitbits/linux-2.6-mpc52xx.git
>
> I tried that repository but here I was not able to patch the tree with
> Xenomai.
Yup, that's the tree I was referring to; and yes you would need to do
some work to get all the patches to play nice together. :)
> But if you have another link it would be a pleasure for me to receive
> the link :)
Unfortunately, I've had some technical issues on my end, so I haven't
been able to get a tree together for you yet.
Sorry,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [Fwd: [Bug 7431] New: ohci1394 Oops after a rmmod/modprobe cycle]
From: Olaf Hering @ 2006-11-06 16:58 UTC (permalink / raw)
To: Stefan Richter; +Cc: Gioele Barabucci, linuxppc-dev
In-Reply-To: <454DC985.2020203@s5r6.in-berlin.de>
On Sun, Nov 05, Stefan Richter wrote:
> Yes, PowerBook G3 Pismo seems affected.
> https://bugzilla.novell.com/show_bug.cgi?id=115228
This patch does not help. Doing an ip link set dev eth0 up makes no
difference.
^ permalink raw reply
* Re: [PATCH 2.6.19 1/4] ehca: assure 4k alignment for firmware control block in 64k page mode
From: Hoang-Nam Nguyen @ 2006-11-06 17:45 UTC (permalink / raw)
To: Roland Dreier
Cc: Arnd Bergmann, linux-kernel, openib-general, linuxppc-dev,
Christoph Raisch
In-Reply-To: <adaodrko6vq.fsf@cisco.com>
Hi Roland!
> > As Arnd stated I need to fix this ctor issue. Do you prefer me to
resend
> > all patches in proper format (non-mangled inline) or just this one bug
fix?
> I have the rest of the patches, so you just need to resend a fixed
> version of this one. BTW see my previous response about
> kmem_cache_zalloc() -- I think that's the best way to fix this.
Yes. This makes sense to me. Will send this one patch soon.
> In the future though if you can make a patch-sending script or
> something that lets you avoid the attachments that would be great.
Sure, will do. I just found out that I'm using an old version of
kmail and its editor (all fancy editing is turned off, just plain text)
just manngles leading and trailing tabs and spaces...
Thanks
Nam
^ permalink raw reply
* Linux 2.4 on AMCC Taihu eval board
From: Arvid Staub @ 2006-11-06 17:40 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I'm currently working on a PPC405EP-based Taihu eval board by AMCC, and
I'd like to use a 2.4-series kernel instead of the supplied 2.6.
I don't need any fancy stuff, just ethernet, i2c and serial (although
PCI and mtd would probably fine, too...)
Has anybody done this?
Can I use any of the standard machine types, like "405EP-eval"?
Regards,=20
Arvid Staub
^ permalink raw reply
* Re: [PATCH] CPM_UART: Fixed SMC handling for CPM2 processors
From: Vitaly Bordug @ 2006-11-06 17:55 UTC (permalink / raw)
To: Kalle Pokki; +Cc: Paul Mackerras, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.64.0611061523360.12023@host32.eke.fi>
[-- Attachment #1: Type: text/plain, Size: 3992 bytes --]
On Mon, 6 Nov 2006 15:29:47 +0200 (EET)
Kalle Pokki wrote:
> SMC handling is broken in two places when using then platform device
> approach with CPM2 devices.
>
> 1. The resources in pq2_devices are not named "regs" and "pram", thus
> they are not found in cpm_uart_drv_get_platform_data().
>
> 2. The code in cpm_uart_drv_get_platform_data() assumes the parameter
> RAM is at "pram". With SMCs of CPM2 devices, "pram" is just a pointer
> to the actual parameter RAM, which the code should reserve somewhere
> in DPRAM.
>
Right, since I had nothing to probe with pq2/smc, that part of code remain intact since creation.
Nice to see this stuff tuned finally :)
> This patch renames these the two existing resources, and introduces a
> new one, "pram_base", which is a pointer to the parameter RAM. The
> parameter RAM for SMC1 and SMC2 is put in the first 128 bytes of the
> DPRAM. This memory was already reserved from the DPRAM memory
> allocator for this purpose.
>
Well just one objection. pram_base should not be a device unless it applies to all the stuff of
SoC family which is not the case.
For this aim, I'd put what you need into the platform_data, or follow the same approach 8xx stuff having.
Thanks, Vitaly
> Signed-off-by: Kalle Pokki <kalle.pokki@iki.fi>
> ---
> arch/ppc/syslib/pq2_devices.c | 24
> ++++++++++++++++++------ drivers/serial/cpm_uart/cpm_uart_core.c |
> 8 +++++++- 2 files changed, 25 insertions(+), 7 deletions(-)
>
> diff --git a/arch/ppc/syslib/pq2_devices.c
> b/arch/ppc/syslib/pq2_devices.c index fefbc21..e8f7ba2 100644
> --- a/arch/ppc/syslib/pq2_devices.c
> +++ b/arch/ppc/syslib/pq2_devices.c
> @@ -286,16 +286,22 @@ struct platform_device ppc_sys_platform_
> [MPC82xx_CPM_SMC1] = {
> .name = "fsl-cpm-smc",
> .id = 1,
> - .num_resources = 3,
> + .num_resources = 4,
> .resource = (struct resource[]) {
> {
> - .name = "smc_mem",
> + .name = "regs",
> .start = 0x11A80,
> .end = 0x11A8F,
> .flags = IORESOURCE_MEM,
> },
> {
> - .name = "smc_pram",
> + .name = "pram",
> + .start = PROFF_SMC1,
> + .end = PROFF_SMC1 + 63,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .name = "pram_base",
> .start = 0x87fc,
> .end = 0x87fd,
> .flags = IORESOURCE_MEM,
> @@ -310,16 +316,22 @@ struct platform_device ppc_sys_platform_
> [MPC82xx_CPM_SMC2] = {
> .name = "fsl-cpm-smc",
> .id = 2,
> - .num_resources = 3,
> + .num_resources = 4,
> .resource = (struct resource[]) {
> {
> - .name = "smc_mem",
> + .name = "regs",
> .start = 0x11A90,
> .end = 0x11A9F,
> .flags = IORESOURCE_MEM,
> },
> {
> - .name = "smc_pram",
> + .name = "pram",
> + .start = PROFF_SMC2,
> + .end = PROFF_SMC2 + 63,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .name = "pram_base",
> .start = 0x88fc,
> .end = 0x88fd,
> .flags = IORESOURCE_MEM,
> diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
> b/drivers/serial/cpm_uart/cpm_uart_core.c index 4047530..55419b1
> 100644 --- a/drivers/serial/cpm_uart/cpm_uart_core.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_core.c
> @@ -1024,7 +1024,7 @@ int cpm_uart_drv_get_platform_data(struc
> int idx = pdata->fs_no; /* It is UART_SMCx or
> UART_SCCx index */ struct uart_cpm_port *pinfo;
> int line;
> - u32 mem, pram;
> + u32 mem, pram, pram_base;
>
> line = cpm_uart_id2nr(idx);
> if(line < 0) {
> @@ -1049,6 +1049,12 @@ int cpm_uart_drv_get_platform_data(struc
> return -EINVAL;
> pram = r->start;
>
> + r = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> "pram_base");
> + if (r) {
> + pram_base = r->start;
> + out_be16((u16 *)pram_base, pram & 0xffff);
> + }
> +
> if(idx > fsid_smc2_uart) {
> pinfo->sccp = (scc_t *)mem;
> pinfo->sccup = (scc_uart_t *)pram;
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: System ACE driver - for 2.6 kernel - issue resolved
From: agnel juni @ 2006-11-06 19:00 UTC (permalink / raw)
To: Ameet Patil; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3865 bytes --]
Hi Ameet,
We were able to get over with the unstability in the driver with the following fix in the code
Instead of fixing the number of sectors to be 2 in the loop, we are actually doing a read based on the kernel request like this :
for(i = xsa_cur_req->current_nr_sectors; i > 0; i-=xsa_cur_req->current_nr_sectors ){
xsa_device.req_done = 1;
while ((stat = cur_req(&SysAce, sector,
xsa_cur_req->current_nr_sectors ,
buffer)) == XST_DEVICE_BUSY)
xsa_short_delay();
Now the driver is stable with all the filesystem commands.
Please test this out and if appropriate patch this to the driver code.
Thanks
Junita
----- Original Message ----
From: Ameet Patil <ammubhai@gmail.com>
To: agnel juni <junijoseph@yahoo.co.in>
Cc: linuxppc-embedded@ozlabs.org
Sent: Thursday, 26 October, 2006 1:00:48 AM
Subject: Re: System ACE driver - for 2.6 kernel - need help to understand xsa_thread
Hi Junita,
Its a hack really! When I was developing/porting the SysAce driver
to 2.6 I tried to maintain the code as is from the 2.4 kernel driver. In
doing so I found that there is a slight difference between the two
kernels. i.e. I am not sure why, but the sysace device can only handle
requests for 2 sectors at a time. This was fine in the 2.4 as the kernel
always requested 2 sectors. However, in 2.6 I found that this is
different: the requests are 8 secs. or more. I tried to fix this in vain
by changing several parameters of the driver during initialization.
Anyway, due to several issues I didn't try hard to fix it at that time.
Hence this hack: No matter how many sec. req. I get from the kernel, I
use a loop to req. only 2 secs. at a time. The xsa_device.req_done is
used as a flag and reset in the XSA IRQ IIRC.
If you find a better approach, please do update me. Hope this helps!
cheers,
-Ameet
agnel juni wrote:
>
> Hello all
>
> I am trying to understand the parameters that are sent through "cur_req"
> function used in funtion xsa_thread in System ACE driver.
>
> In xsa_thread function in the System ACE driver ,
>
> In 2.4 kernel:
> --------------------
> while ((stat = cur_req(&SysAce, sector,
> CURRENT->current_nr_sectors,
> CURRENT->buffer)) == XST_DEVICE_BUSY)
> xsa_short_delay();
>
>
> Where as in 2.6 kernel this is changed to
> ---------------------------------------------------------------
>
> for(i = xsa_cur_req->current_nr_sectors; i > 0; i-=2){
> xsa_device.req_done = 1;
> while ((stat = cur_req(&SysAce, sector,
> 2,
> buffer)) == XST_DEVICE_BUSY)
> xsa_short_delay();
> #endif
>
> Ameet , could you help me understand the impact of the parameters,
> especailly the 3rd paramter which is hardcoded in 2.6 kernel.It would be
> great if you could clarify this in regard to 'mount' command.
>
> Thanks in advance
> Junita
>
>
>
> ------------------------------------------------------------------------
> Find out what India is talking about on - Yahoo! Answers India
> <http://us.rd.yahoo.com/mail/in/yanswers/*http://in.answers.yahoo.com/>
> Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8.
> Get it NOW
> <http://us.rd.yahoo.com/mail/in/messengertagline/*http://in.messenger.yahoo.com>
>
__________________________________________________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/
[-- Attachment #2: Type: text/html, Size: 7241 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_platform support for OHCI/Bigendian HC
From: Kumar Gala @ 2006-11-06 19:24 UTC (permalink / raw)
To: Nicolas DET; +Cc: akpm@osdl.org, linuxppc-dev, linuxppc-embedded
In-Reply-To: <200611061035.kA6AZtGZ018329@post.webmailer.de>
On Nov 6, 2006, at 4:35 AM, Nicolas DET wrote:
> This patch use of_platform device to probe and install OHCI big
> endian HC.
>
> PS: I did not success to properly inline the file using thrunderbird.
You really copy the USB maintainers on this. Also, why bother with
the Kconfig for USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE?
- kumar
[snip]
^ permalink raw reply
* Re: fixup_bigphys_addr and ioremap64 question
From: Kumar Gala @ 2006-11-06 19:27 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-dev list
In-Reply-To: <20061106164542.GA30762@gate.crashing.org>
On Nov 6, 2006, at 10:45 AM, Matt Porter wrote:
> On Sun, Nov 05, 2006 at 10:16:20PM -0600, Josh Boyer wrote:
>> On Mon, 2006-11-06 at 15:09 +1100, Benjamin Herrenschmidt wrote:
>>>>> So why do we have both ioremap and ioremap64 knowing that the
>>>>> former is
>>>>> defined to take a phys_addr_t argument ?
>>>>>
>>>>> Currently, we have both, with the only difference being that
>>>>> ioremap
>>>>> calls ioremap64 but also passes the argument through a
>>>>> fixup_bigphys_addr() function first.
>>>>>
>>>>> It took me a while to find it ... it's not defined in generic
>>>>> code but
>>>>> in platform code (ugh !). In fact, the only version of it we
>>>>> have in
>>>>> arch/powerpc is in the 85xx support and does:
>>>>
>>>> It's in arch/ppc/syslib/44x_common.c and it's used to trap the
>>>> least
>>>> significant 32 bits of an address and set the right ERPN for io
>>>> space on
>>>> 44x. Something like that might be needed when 44x merges to
>>>> arch/powerpc.
>>>
>>> Well, my point is that since nowadays we have 64 bits struct
>>> resource
>>> and 64 bits phys_addr_t passed to ioremap, do we still need
>>> that ? In
>>> fact, in my upcoming patch merging io.h for 32 and 64 bits in
>>> asm-powerpc, I've simply removed that hook and ioremap64 :-) I
>>> can add
>>> it back still, but so far, I yet have to be convinced there is
>>> still a
>>> good reason for that hook.
>>
>> Hm.. that might be ok. I'm hoping to get back to working on
>> something
>> soon so I'll be able to tell more later. Maybe Matt knows for sure.
>
> Yes, that's the right way to go. The history on this is that when
> the 64-bit resource change came relatively recently, ioremap64 and
> friends weren't killed off in arch/ppc. ioremap64 only existed
> because
> a long time ago several people blocked the idea of 64-bit resources
> (on 32-bit platforms) and we needed a way around it plus all the
> fixup garbage. Going forward, we now can handle everything through
> ioremap() with no fixup stuff. There's a related issue with mmap and
> 64-bits but that's a separate issue yet that should now be addressed.
>
>> It'll probably break out-of-tree drivers though once the merge
>> happens
>> for 4xx. Could we leave ioremap64 around for a bit with a
>> deprecation
>> warning?
>
> The kernel APIs break all the time. Every out of tree driver has to
> have that built into their expectation when moving to a new kernel
> so I don't see a good reason for making a special case here.
On 85xx I just put the place holder in for handling the larger
address space, but we never did anything real with it. Now that we
have 64-bit resources I'm happy to see ioremap() fixed and ioremap64
go away.
- k
^ permalink raw reply
* Re: [PATCH/RFC (take 2)] linkstation / kurobox support under arch/powerpc
From: Kumar Gala @ 2006-11-06 19:41 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.60.0611051526510.4214@poirot.grange>
On Nov 5, 2006, at 9:22 AM, Guennadi Liakhovetski wrote:
> Here comes the 2nd version of the linkstation / kurobox patch. Changes
> since the last version:
>
> On Wed, 1 Nov 2006, Guennadi Liakhovetski wrote:
>
>> A couple things that I don't like that much in this patch:
>>
>> 1) hardcoded PCI IRQ map - I'll have to put it in dts too;
>
> Done. Taken from the fdt now.
>
> Some more cleanup, (seemingly) unneeded stuff removed.
>
> Even if it is not included so far due to variousother pending patches,
> please DO review.
>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>
> diff --git a/arch/powerpc/boot/dts/kuroboxHG.dts b/arch/powerpc/
> boot/dts/kuroboxHG.dts
> new file mode 100644
> index 0000000..6c76ef6
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/kuroboxHG.dts
> @@ -0,0 +1,183 @@
> +/*
> + * Device Tree Souce for Buffalo KuroboxHG
> + *
> + * Based on sandpoint.dts
> + *
> + * 2006 (c) G. Liakhovetski <g.liakhovetski@gmx.de>
> + *
> + * This file is licensed under
> + * the terms of the GNU General Public License version 2. This
> program
> + * is licensed "as is" without any warranty of any kind, whether
> express
> + * or implied.
> +
> +XXXX add flash parts, rtc, ??
> +
> +build with: "dtc -f -I dts -O dtb -o kuroboxHG.dtb -V 16
> kuroboxHG.dts"
> +
> +
> + */
> +
> +/ {
> + linux,phandle = <1000>;
> + model = "KuroboxHG";
> + compatible = "linkstation";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + linux,phandle = <2000>;
> + #cpus = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,603e { /* Really 8241 */
> + linux,phandle = <2100>;
> + linux,boot-cpu;
> + device_type = "cpu";
> + reg = <0>;
> + clock-frequency = <fdad680>; /* Fixed by bootwrapper */
> + timebase-frequency = <1F04000>; /* Fixed by bootwrapper */
> + bus-frequency = <0>; /* From bootloader */
> + /* Following required by dtc but not used */
> + i-cache-line-size = <0>;
> + d-cache-line-size = <0>;
> + i-cache-size = <4000>;
> + d-cache-size = <4000>;
> + };
> + };
> +
> + memory {
> + linux,phandle = <3000>;
> + device_type = "memory";
> + reg = <00000000 08000000>;
> + };
> +
> + soc10x { /* AFAICT need to make soc for 8245's uarts to be
> defined */
> + linux,phandle = <4000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #interrupt-cells = <2>;
> + device_type = "soc";
> + compatible = "mpc10x";
> + store-gathering = <0>; /* 0 == off, !0 == on */
> + reg = <80000000 00100000>;
> + ranges = <80000000 80000000 70000000 /* pci mem space */
> + fc000000 fc000000 00100000 /* EUMB */
> + fe000000 fe000000 00c00000 /* pci i/o space */
> + fec00000 fec00000 00300000 /* pci cfg regs */
> + fef00000 fef00000 00100000>; /* pci iack */
> +
> + dma@80001100 {
> + linux,phandle = <4100>;
> + #interrupt-cells = <1>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "dma";
> + compatible = "fsl-dma";
> + clock-frequency = <0>;
> + reg = <80001100 24>;
> + interrupts = <6 0>;
> + interrupt-parent = <4400>;
> + };
> +
> + dma@80001200 {
> + linux,phandle = <4200>;
> + #interrupt-cells = <1>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "dma";
> + compatible = "fsl-dma";
> + clock-frequency = <0>;
> + reg = <80001200 24>;
> + interrupts = <7 0>;
> + interrupt-parent = <4400>;
> + };
> +
> + i2c@80003000 {
> + linux,phandle = <4300>;
> + device_type = "i2c";
> + compatible = "fsl-i2c";
> + clock-frequency = <0>;
> + reg = <80003000 1000>;
> + interrupts = <5 2>;
> + interrupt-parent = <4400>;
> + };
> +
> + serial@80004500 {
> + linux,phandle = <4511>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <80004500 8>;
> + clock-frequency = <7c044a8>;
> + current-speed = <2580>;
> + interrupts = <9 2>;
> + interrupt-parent = <4400>;
> + };
> +
> + serial@80004600 {
> + linux,phandle = <4512>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <80004600 8>;
> + clock-frequency = <7c044a8>;
> + current-speed = <e100>;
> + interrupts = <a 0>;
> + interrupt-parent = <4400>;
> + };
> +
> + pic@80040000 {
> + linux,phandle = <4400>;
> + #interrupt-cells = <2>;
> + #address-cells = <0>;
> + device_type = "open-pic";
> + compatible = "chrp,open-pic";
> + interrupt-controller;
> + reg = <80040000 40000>;
> + clock-frequency = <0>; /* ??? */
> + built-in;
> + };
> +
> + pci@fec00000 {
> + linux,phandle = <4500>;
> + #address-cells = <3>;
> + #size-cells = <2>;
> + #interrupt-cells = <1>;
> + device_type = "pci";
> + compatible = "mpc10x-pci";
> + reg = <fec00000 400000>;
> + ranges = <01000000 0 0 fe000000 0 00c00000
> + 02000000 0 80000000 80000000 0 70000000>;
> + bus-range = <0 ff>;
> + clock-frequency = <7f28155>;
> + interrupt-parent = <4400>;
> + interrupt-map-mask = <f800 0 0 7>;
> + interrupt-map = <
> + /* IDSEL 0x11 - IRQ0 ETH */
> + 5800 0 0 1 4400 0 1
> + 5800 0 0 2 4400 1 1
> + 5800 0 0 3 4400 2 1
> + 5800 0 0 4 4400 3 1
> + /* IDSEL 0x12 - IRQ1 IDE0 */
> + 6000 0 0 1 4400 1 1
> + 6000 0 0 2 4400 2 1
> + 6000 0 0 3 4400 3 1
> + 6000 0 0 4 4400 0 1
> + /* IDSEL 0x13 - IRQ4 IDE1 */
> + 6800 0 0 1 4400 3 1
> + 6800 0 0 2 4400 0 1
> + 6800 0 0 3 4400 1 1
> + 6800 0 0 4 4400 2 1
> + /* IDSEL 0x14 - IRQ3 USB2.0 */
> + 7000 0 0 1 4400 3 1
> + 7000 0 0 2 4400 3 1
> + 7000 0 0 3 4400 3 1
> + 7000 0 0 4 4400 3 1
> + /* IDSEL 0x15 - IRQ2 fan ctrl*/
> + 7800 0 0 1 4400 2 1
> + 7800 0 0 2 4400 3 1
> + 7800 0 0 3 4400 0 1
> + 7800 0 0 4 4400 1 1
> + >;
> + };
> + };
> +};
>
[snip]
> diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/
> powerpc/platforms/embedded6xx/Kconfig
> index 234a861..c1c6748 100644
> --- a/arch/powerpc/platforms/embedded6xx/Kconfig
> +++ b/arch/powerpc/platforms/embedded6xx/Kconfig
> @@ -76,6 +76,15 @@ config PRPMC800
> Select SANDPOINT if configuring for a Motorola Sandpoint X3
> (any flavor).
>
> +config LINKSTATION
> + bool "Linkstation / Kurobox(HG) from Buffalo"
> + select MPIC
> + select FSL_SOC
> + select PPC_UDBG_16550 if SERIAL_8250
> + help
> + Select LINKSTATION if configuring for a PPC-based Linkstation
> + (LS-1) or Kurobox(HG) from Buffalo Technologies.
> +
> config MPC7448HPC2
> bool "Freescale MPC7448HPC2(Taiga)"
> select TSI108_BRIDGE
> @@ -164,6 +173,19 @@ config EV64360
> platform.
> endchoice
>
> +choice
> + prompt "Linkstation Type"
> + depends on LINKSTATION
> + default KUROBOXHG
> +
> +config KUROBOX
> + bool "Kurobox"
> +
> +config KUROBOXHG
> + bool "Kurobox HG"
> +
These two config options don't appear to be used anywhere
> +endchoice
> +
> config PQ2ADS
> bool
> depends on ADS8272
> @@ -210,7 +232,7 @@ config PPC_GEN550
> depends on SANDPOINT || SPRUCE || PPLUS || \
> PRPMC750 || PRPMC800 || LOPEC || \
> (EV64260 && !SERIAL_MPSC) || CHESTNUT || RADSTONE_PPC7D || \
> - 83xx
> + 83xx || LINKSTATION
> default y
>
> config FORCE
> @@ -284,13 +306,13 @@ config HARRIER
>
> config MPC10X_BRIDGE
> bool
> - depends on POWERPMC250 || LOPEC || SANDPOINT
> + depends on POWERPMC250 || LOPEC || SANDPOINT || LINKSTATION
> select PPC_INDIRECT_PCI
> default y
>
> config MPC10X_OPENPIC
> bool
> - depends on POWERPMC250 || LOPEC || SANDPOINT
> + depends on POWERPMC250 || LOPEC || SANDPOINT || LINKSTATION
> default y
>
> config MPC10X_STORE_GATHERING
> diff --git a/arch/powerpc/platforms/embedded6xx/Makefile b/arch/
> powerpc/platforms/embedded6xx/Makefile
> index fa499fe..1f3edc7 100644
> --- a/arch/powerpc/platforms/embedded6xx/Makefile
> +++ b/arch/powerpc/platforms/embedded6xx/Makefile
> @@ -3,3 +3,4 @@ #
> #
> obj-$(CONFIG_MPC7448HPC2) += mpc7448_hpc2.o
> obj-$(CONFIG_SANDPOINT) += sandpoint.o
> +obj-$(CONFIG_LINKSTATION) += linkstation.o ls_uart.o
> diff --git a/arch/powerpc/platforms/embedded6xx/linkstation.c b/
> arch/powerpc/platforms/embedded6xx/linkstation.c
> new file mode 100644
> index 0000000..30bcb5b
> --- /dev/null
> +++ b/arch/powerpc/platforms/embedded6xx/linkstation.c
> @@ -0,0 +1,254 @@
> +/*
> + * arch/powerpc/platforms/embedded6xx/linkstation.c
> + *
> + * Board setup routines for the Buffalo Linkstation / Kurobox
> Platform.
> + *
> + * Author: Mark A. Greer
> + * mgreer@mvista.com
> + *
> + * 2000-2003 (c) MontaVista Software, Inc. This file is licensed
> under
> + * the terms of the GNU General Public License version 2. This
> program
> + * is licensed "as is" without any warranty of any kind, whether
> express
> + * or implied.
> + */
> +
> +#include <linux/stddef.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/errno.h>
> +#include <linux/reboot.h>
> +#include <linux/pci.h>
> +#include <linux/kdev_t.h>
> +#include <linux/major.h>
> +#include <linux/initrd.h>
> +#include <linux/console.h>
> +#include <linux/delay.h>
> +#include <linux/ide.h>
> +#include <linux/seq_file.h>
> +#include <linux/root_dev.h>
> +#include <linux/serial.h>
> +#include <linux/tty.h> /* for linux/serial_core.h */
> +#include <linux/serial_core.h>
> +#include <linux/serial_reg.h>
> +#include <linux/serial_8250.h>
> +#include <linux/mtd/physmap.h>
> +
> +#include <asm/system.h>
> +#include <asm/pgtable.h>
> +#include <asm/page.h>
> +#include <asm/time.h>
> +#include <asm/dma.h>
> +#include <asm/io.h>
> +#include <asm/machdep.h>
> +#include <asm/prom.h>
> +#include <asm/smp.h>
> +#include <asm/vga.h>
> +#include <asm/i8259.h>
> +#include <asm/mpic.h>
> +#include <asm/todc.h>
> +#include <asm/bootinfo.h>
> +#include <asm/mpc10x.h>
> +#include <asm/pci-bridge.h>
> +#include <asm/ppc_sys.h>
> +
> +static struct mtd_partition linkstation_physmap_partitions[] = {
> + {
> + .name = "mtd_firmimg",
> + .offset = 0x000000,
> + .size = 0x300000,
> + },
> + {
> + .name = "mtd_bootcode",
> + .offset = 0x300000,
> + .size = 0x70000,
> + },
> + {
> + .name = "mtd_status",
> + .offset = 0x370000,
> + .size = 0x10000,
> + },
> + {
> + .name = "mtd_conf",
> + .offset = 0x380000,
> + .size = 0x80000,
> + },
> + {
> + .name = "mtd_allflash",
> + .offset = 0x000000,
> + .size = 0x400000,
> + },
> + {
> + .name = "mtd_data",
> + .offset = 0x310000,
> + .size = 0xf0000,
> + },
> +};
> +
> +/*
> + * Buffalo linkstation interrupt routing.
> + */
> +
> +void __init linkstation_pcibios_fixup(void)
> +{
> + struct pci_dev *dev = NULL;
> +
> + for_each_pci_dev(dev)
> + pci_read_irq_line(dev);
> +}
> +
You don't need this fixup going forward.
> +static int __init add_bridge(struct device_node *dev)
> +{
> + int len;
> + struct pci_controller *hose;
> + int *bus_range;
> +
> + printk("Adding PCI host bridge %s\n", dev->full_name);
> +
> + bus_range = (int *) get_property(dev, "bus-range", &len);
> + if (bus_range == NULL || len < 2 * sizeof(int))
> + printk(KERN_WARNING "Can't get bus-range for %s, assume"
> + " bus 0\n", dev->full_name);
> +
> + hose = pcibios_alloc_controller();
> + if (hose == NULL)
> + return -ENOMEM;
> + hose->first_busno = bus_range ? bus_range[0] : 0;
> + hose->last_busno = bus_range ? bus_range[1] : 0xff;
> + hose->arch_data = dev;
> + setup_indirect_pci(hose, 0xfec00000, 0xfee00000);
> +
> + /* Interpret the "ranges" property */
> + /* This also maps the I/O region and sets isa_io/mem_base */
> + pci_process_bridge_OF_ranges(hose, dev, 1);
> +
> + return 0;
> +}
> +
> +static void __init linkstation_setup_arch(void)
> +{
> + struct device_node *np;
> +#ifdef CONFIG_MTD_PHYSMAP
> + physmap_set_partitions(linkstation_physmap_partitions,
> + ARRAY_SIZE(linkstation_physmap_partitions));
> +#endif
> +
> +#ifdef CONFIG_BLK_DEV_INITRD
> + if (initrd_start)
> + ROOT_DEV = Root_RAM0;
> + else
> +#endif
> +#ifdef CONFIG_ROOT_NFS
> + ROOT_DEV = Root_NFS;
> +#else
> + ROOT_DEV = Root_HDA1;
> +#endif
> +
> + /* Lookup PCI host bridges */
> + for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
> + add_bridge(np);
> +
> + ppc_md.pci_swizzle = common_swizzle;
> +
> + printk(KERN_INFO "BUFFALO Network Attached Storage Series\n");
> + printk(KERN_INFO "(C) 2002-2005 BUFFALO INC.\n");
> +}
> +
> +/*
> + * Interrupt setup and service. Interrrupts on the linkstation come
> + * from the four PCI slots plus onboard 8241 devices: I2C, DUART.
> + */
> +static void __init linkstation_init_IRQ(void)
> +{
> + struct mpic *mpic;
> + struct device_node *dnp;
> + void *prop;
> + int size;
> + phys_addr_t paddr;
> +
> + dnp = of_find_node_by_type(NULL, "open-pic");
> + if (dnp == NULL)
> + return;
> +
> + prop = (struct device_node *)get_property(dnp, "reg", &size);
> + paddr = (phys_addr_t)of_translate_address(dnp, prop);
> +
> + mpic = mpic_alloc(dnp, paddr, MPIC_PRIMARY | MPIC_WANTS_RESET, 4,
> 32, " EPIC ");
> + BUG_ON(mpic == NULL);
> +
> + /* PCI IRQs */
> + mpic_assign_isu(mpic, 0, paddr + 0x10200);
> +
> + /* I2C */
> + mpic_assign_isu(mpic, 1, paddr + 0x11000);
> +
> + /* ttyS0, ttyS1 */
> + mpic_assign_isu(mpic, 2, paddr + 0x11100);
> +
> + mpic_init(mpic);
> +}
> +
> +extern void avr_uart_configure(void);
> +extern void avr_uart_send(const char);
> +
> +static void linkstation_restart(char *cmd)
> +{
> + local_irq_disable();
> +
> + /* Reset system via AVR */
> + avr_uart_configure();
> + /* Send reboot command */
> + avr_uart_send('C');
> +
> + for(;;) /* Spin until reset happens */
> + avr_uart_send('G'); /* "kick" */
> +}
> +
> +static void linkstation_power_off(void)
> +{
> + local_irq_disable();
> +
> + avr_uart_configure();
> + /* send shutdown command */
> + avr_uart_send('E');
> +
> + for(;;) /* Spin until power-off happens */
> + avr_uart_send('G'); /* "kick" */
> + /* NOTREACHED */
> +}
> +
> +static void linkstation_halt(void)
> +{
> + linkstation_power_off();
> + /* NOTREACHED */
> +}
> +
> +static void linkstation_show_cpuinfo(struct seq_file *m)
> +{
> + seq_printf(m, "vendor\t\t: Buffalo Technology\n");
> + seq_printf(m, "machine\t\t: Linkstation I/Kurobox(HG)\n");
> +}
> +
> +static int __init linkstation_probe(void)
> +{
> + unsigned long root;
> +
> + root = of_get_flat_dt_root();
> +
> + if (!of_flat_dt_is_compatible(root, "linkstation"))
> + return 0;
> + return 1;
> +}
> +
> +define_machine(linkstation){
> + .name = "Buffalo Linkstation",
> + .probe = linkstation_probe,
> + .setup_arch = linkstation_setup_arch,
> + .init_IRQ = linkstation_init_IRQ,
> + .show_cpuinfo = linkstation_show_cpuinfo,
> + .pcibios_fixup = linkstation_pcibios_fixup,
> + .get_irq = mpic_get_irq,
> + .restart = linkstation_restart,
> + .power_off = linkstation_power_off,
> + .halt = linkstation_halt,
> + .calibrate_decr = generic_calibrate_decr,
> +};
> diff --git a/arch/powerpc/platforms/embedded6xx/ls_uart.c b/arch/
> powerpc/platforms/embedded6xx/ls_uart.c
> new file mode 100644
> index 0000000..b640115
> --- /dev/null
> +++ b/arch/powerpc/platforms/embedded6xx/ls_uart.c
> @@ -0,0 +1,131 @@
> +#include <linux/workqueue.h>
> +#include <linux/string.h>
> +#include <linux/delay.h>
> +#include <linux/serial_reg.h>
> +#include <linux/serial_8250.h>
> +#include <asm/io.h>
> +#include <asm/mpc10x.h>
> +#include <asm/ppc_sys.h>
> +#include <asm/prom.h>
> +#include <asm/termbits.h>
> +
Can this code not be reworked to use the standard 8250 driver?
> +static void __iomem *avr_addr;
> +static unsigned long avr_clock;
> +
> +static struct work_struct wd_work;
> +
> +static void wd_stop(void *unused)
> +{
> + const char string[] = "AAAAFFFFJJJJ>>>>VVVV>>>>ZZZZVVVVKKKK";
> + int i = 0, rescue = 8;
> + int len = strlen(string);
> +
> + while (rescue--) {
> + int j;
> + char lsr = in_8(avr_addr + UART_LSR);
> +
> + if (lsr & (UART_LSR_THRE | UART_LSR_TEMT)) {
> + for (j = 0; j < 16 && i < len; j++, i++)
> + out_8(avr_addr + UART_TX, string[i]);
> + if (i == len) {
> + /* Read "OK" back: 4ms for the last "KKKK"
> + plus a couple bytes back */
> + msleep(7);
> + printk("linkstation: disarming the AVR watchdog: ");
> + while (in_8(avr_addr + UART_LSR) & UART_LSR_DR)
> + printk("%c", in_8(avr_addr + UART_RX));
> + break;
> + }
> + }
> + msleep(17);
> + }
> + printk("\n");
> +}
> +
> +#define AVR_QUOT(clock) ((clock) + 8 * 9600) / (16 * 9600)
> +
> +void avr_uart_configure(void)
> +{
> + unsigned char cval = UART_LCR_WLEN8;
> + unsigned int quot = AVR_QUOT(avr_clock);
> +
> + if (!avr_addr || !avr_clock)
> + return;
> +
> + out_8(avr_addr + UART_LCR, cval); /* initialise UART */
> + out_8(avr_addr + UART_MCR, 0);
> + out_8(avr_addr + UART_IER, 0);
> +
> + cval |= UART_LCR_STOP | UART_LCR_PARITY | UART_LCR_EPAR;
> +
> + out_8(avr_addr + UART_LCR, cval); /* Set character format */
> +
> + out_8(avr_addr + UART_LCR, cval | UART_LCR_DLAB); /* set DLAB */
> + out_8(avr_addr + UART_DLL, quot & 0xff); /* LS of divisor */
> + out_8(avr_addr + UART_DLM, quot >> 8); /* MS of divisor */
> + out_8(avr_addr + UART_LCR, cval); /* reset DLAB */
> + out_8(avr_addr + UART_FCR, UART_FCR_ENABLE_FIFO); /* enable FIFO */
> +}
> +
> +void avr_uart_send(const char c)
> +{
> + if (!avr_addr || !avr_clock)
> + return;
> +
> + out_8(avr_addr + UART_TX, c);
> + out_8(avr_addr + UART_TX, c);
> + out_8(avr_addr + UART_TX, c);
> + out_8(avr_addr + UART_TX, c);
> +}
> +
> +static void __init ls_uart_init(void)
> +{
> + local_irq_disable();
> +
> +#ifndef CONFIG_SERIAL_8250
> + out_8(avr_addr + UART_FCR, UART_FCR_ENABLE_FIFO); /* enable FIFO */
> + out_8(avr_addr + UART_FCR, UART_FCR_ENABLE_FIFO |
> + UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT); /* clear FIFOs */
> + out_8(avr_addr + UART_FCR, 0);
> + out_8(avr_addr + UART_IER, 0);
> +
> + /* Clear up interrupts */
> + (void) in_8(avr_addr + UART_LSR);
> + (void) in_8(avr_addr + UART_RX);
> + (void) in_8(avr_addr + UART_IIR);
> + (void) in_8(avr_addr + UART_MSR);
> +#endif
> + avr_uart_configure();
> +
> + local_irq_enable();
> +}
> +
> +static int __init ls_uarts_init(void)
> +{
> + struct device_node *avr;
> + phys_addr_t phys_addr;
> + int len;
> +
> + avr = of_find_node_by_path("/soc10x/serial@80004500");
> + if (!avr)
> + return -EINVAL;
> +
> + avr_clock = *(u32*)get_property(avr, "clock-frequency", &len);
> + phys_addr = ((u32*)get_property(avr, "reg", &len))[0];
> +
> + if (!avr_clock || !phys_addr)
> + return -EINVAL;
> +
> + avr_addr = ioremap(phys_addr, 32);
> + if (!avr_addr)
> + return -EFAULT;
> +
> + ls_uart_init();
> +
> + INIT_WORK(&wd_work, wd_stop, NULL);
> + schedule_work(&wd_work);
> +
> + return 0;
> +}
> +
> +late_initcall(ls_uarts_init);
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index f1c7575..25cd8de 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -1396,41 +1396,6 @@ static void rtl8169_netpoll(struct net_d
> }
> #endif
Pull this into a separate patch since it effects a driver. Also, any
reason this code is being removed?
>
> -static void __rtl8169_set_mac_addr(struct net_device *dev, void
> __iomem *ioaddr)
> -{
> - unsigned int i, j;
> -
> - RTL_W8(Cfg9346, Cfg9346_Unlock);
> - for (i = 0; i < 2; i++) {
> - __le32 l = 0;
> -
> - for (j = 0; j < 4; j++) {
> - l <<= 8;
> - l |= dev->dev_addr[4*i + j];
> - }
> - RTL_W32(MAC0 + 4*i, cpu_to_be32(l));
> - }
> - RTL_W8(Cfg9346, Cfg9346_Lock);
> -}
> -
> -static int rtl8169_set_mac_addr(struct net_device *dev, void *p)
> -{
> - struct rtl8169_private *tp = netdev_priv(dev);
> - struct sockaddr *addr = p;
> -
> - if (!is_valid_ether_addr(addr->sa_data))
> - return -EINVAL;
> -
> - memcpy(dev->dev_addr, addr->sa_data, dev->addr_len);
> -
> - if (netif_running(dev)) {
> - spin_lock_irq(&tp->lock);
> - __rtl8169_set_mac_addr(dev, tp->mmio_addr);
> - spin_unlock_irq(&tp->lock);
> - }
> - return 0;
> -}
> -
> static void rtl8169_release_board(struct pci_dev *pdev, struct
> net_device *dev,
> void __iomem *ioaddr)
> {
> @@ -1680,7 +1645,6 @@ rtl8169_init_one(struct pci_dev *pdev, c
> dev->stop = rtl8169_close;
> dev->tx_timeout = rtl8169_tx_timeout;
> dev->set_multicast_list = rtl8169_set_rx_mode;
> - dev->set_mac_address = rtl8169_set_mac_addr;
> dev->watchdog_timeo = RTL8169_TX_TIMEOUT;
> dev->irq = pdev->irq;
> dev->base_addr = (unsigned long) ioaddr;
> @@ -1928,8 +1892,6 @@ rtl8169_hw_start(struct net_device *dev)
> /* Enable all known interrupts by setting the interrupt mask. */
> RTL_W16(IntrMask, rtl8169_intr_mask);
>
> - __rtl8169_set_mac_addr(dev, ioaddr);
> -
> netif_start_queue(dev);
> }
^ permalink raw reply
* Re: [PATCH/RFC (take 2)] linkstation / kurobox support under arch/powerpc
From: Guennadi Liakhovetski @ 2006-11-06 20:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <4EC85F22-99A9-4B0F-987C-25B715235320@kernel.crashing.org>
On Mon, 6 Nov 2006, Kumar Gala wrote:
> > +config KUROBOX
> > + bool "Kurobox"
> > +
> > +config KUROBOXHG
> > + bool "Kurobox HG"
> > +
>
> These two config options don't appear to be used anywhere
Yep, right, left-overs. Forgot I switched to fdt properties.
> > +void __init linkstation_pcibios_fixup(void)
> > +{
> > + struct pci_dev *dev = NULL;
> > +
> > + for_each_pci_dev(dev)
> > + pci_read_irq_line(dev);
> > +}
> > +
>
> You don't need this fixup going forward.
You mean this patch:
http://ozlabs.org/pipermail/linuxppc-dev/2006-October/027287.html? Yes, I
knew about it, just that my local tree didn't have it yet:-)
> > +#include <linux/serial_reg.h>
> > +#include <linux/serial_8250.h>
> > +#include <asm/io.h>
> > +#include <asm/mpc10x.h>
> > +#include <asm/ppc_sys.h>
> > +#include <asm/prom.h>
> > +#include <asm/termbits.h>
> > +
>
> Can this code not be reworked to use the standard 8250 driver?
I would gladly do, but I don't know how. There's no standard API to serial
drivers from the kernel. There's linedisc, serio, but I don't think any of
them directly fits my needs? I think, there was a patch recently on LKML
exactly for this, but I didn't look at it too closely, haven't seen many
replies either.
> > diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> > index f1c7575..25cd8de 100644
> > --- a/drivers/net/r8169.c
> > +++ b/drivers/net/r8169.c
> > @@ -1396,41 +1396,6 @@ static void rtl8169_netpoll(struct net_d
> > }
> > #endif
>
> Pull this into a separate patch since it effects a driver. Also, any reason
> this code is being removed?
I explained in version 1 of the patch, sorry, didn't repeat: This is a
recent patch to this driver, which I proved to break my system, so it has
been now reverted as of 19-rc4. Just included it here for completeness in
case anybody wants to boot this kernel:-) Of course, it doesn't actually
belong here.
Thanks for ther review! I'll remove the superfluous config options, will
be glad to see any ideas as to how to interface to the serial driver.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ 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