* 2.6.24-rc2 crash in kmap_coherent
From: Florian Lohoff @ 2007-12-11 22:13 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 2683 bytes --]
Hi,
i just discovered that my native gcc build on one of my Indys stopped. I
found this in the dmesg ;)
Its a 2.6.24-rc2 on an R5k Indy 64M:
Kernel bug detected[#1]:
Cpu 0
$ 0 : 0000000000000000 ffffffff9000cce0 0000000000000001 ffffffff80000000
$ 4 : ffffffff8921f910 000000007fda0f05 000000007fda0f05 ffffffff8b8ea000
$ 8 : ffffffff89b4ef05 000000000000000e ffffffff8921f910 0000000000000f05
$12 : 0000000000000000 ffffffff80000008 ffffffff88090010 00000000004038b4
$16 : ffffffff8921f910 000000007fda0f05 ffffffff8b8ea000 000000000000000e
$20 : ffffffff8bdfb920 0000000000000000 ffffffff8bd88cc0 ffffffff8893fd58
$24 : 0000000000000006 ffffffff8801df00
$28 : ffffffff8893c000 ffffffff8893fd20 ffffffff88430000 ffffffff8801c010
Hi : 000000000001d1ea
Lo : 0000000000009b4e
epc : ffffffff8801bcf0 kmap_coherent+0x10/0x130 Not tainted
ra : ffffffff8801c010 copy_from_user_page+0x40/0xb0
Status: 9000cce3 KX SX UX KERNEL EXL IE
Cause : 00000034
PrId : 00002321 (R5000)
Modules linked in: dm_snapshot dm_mirror dm_mod ipv6
Process cat (pid: 14553, threadinfo=ffffffff8893c000, task=ffffffff88a52660)
Stack : 000000000000000e 000000007fda0f05 ffffffff8b8ea000 0000000000000000
ffffffff88079d10 ffffffff88079cc4 ffffffff8bfbd528 ffffffff8921f910
ffffffff8bdfb980 ffffffff8b8ea000 ffffffff8bdfb920 0000000000000000
ffffffff8b8ea000 000000000000000e ffffffff8bd88cc0 ffffffff8893fe78
0000000000447000 000000000052c7d8 0000000000000000 ffffffff880d9014
ffffffff8bd88cc0 ffffffff8b8ea000 fffffffffffffff4 ffffffff8b863248
0000000000000400 ffffffff8893fe78 0000000000447000 ffffffff880db188
ffffffff8be6f6e0 0000000000000400 0000000000447000 ffffffff8893fe78
0000000000447000 0000000000000003 0000000000000016 ffffffff8808fbdc
ffffffff8be6f6e0 0000000000000400 0000000000447000 fffffffffffffff7
...
Call Trace:
[<ffffffff8801bcf0>] kmap_coherent+0x10/0x130
[<ffffffff8801c010>] copy_from_user_page+0x40/0xb0
[<ffffffff88079d10>] access_process_vm+0x168/0x1d8
[<ffffffff880d9014>] proc_pid_cmdline+0xac/0x140
[<ffffffff880db188>] proc_info_read+0x108/0x150
[<ffffffff8808fbdc>] vfs_read+0xec/0x178
[<ffffffff88090060>] sys_read+0x50/0x98
[<ffffffff88019718>] handle_sys+0x118/0x134
Code: 0002127a 00021000 30420001 <00028036> 8f820024 3c038843 24420001 af820024 dc62f390
Flo
--
Florian Lohoff flo@rfc822.org +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Still no 2.6.24 on ip32 [was: Re: 2.6.24-rc1 does not boot on SGI]
From: Ricardo Mendoza @ 2007-12-11 17:18 UTC (permalink / raw)
To: Giuseppe Sacco; +Cc: linux-mips
In-Reply-To: <20071211204437.GA14243@eppesuigoccas.homedns.org>
Giuseppe Sacco wrote:
> On Tue, Dec 11, 2007 at 09:26:42AM -0400, Ricardo Mendoza wrote:
>> Giuseppe Sacco wrote:
>>
>>> I just checked that my repository is up to date, so my problem is still
>>> there (thus I don't know if it is the same problem you fixed).
>>>
>>> BTW, what was the problem you fixed? I would like to have a look to it,
>>> to better understand what's going on there.
>> Well I just updated to see if anything had broken in the past few days,
>> but I don't seem to be hitting that error of yours. Could you send your
>> config to see if I can reproduce it?
>
> Yes, sure: http://eppesuigoccas.homedns.org/~giuseppe/debian/config-2.6.24-rc4-ip32.bz2
> but please note that the problem is present in every kernel since 2.6.24-rc1
>
> my boot stanza in arcboot is:
>
> label=test
> image=/boot/vmlinux-2.6.24-rc4-gs1
> append="root=/dev/sda1 ro video=gbefb:1024x768-16@60 debug initcall_debug console=tty0 console=ttyS1,115200"
Ran it without problems, can't get into much detail right now but I the
problem you are seeing is more than likely caused by your other patch to
serial_core.c.
Ricardo
^ permalink raw reply
* Re: Still no 2.6.24 on ip32 [was: Re: 2.6.24-rc1 does not boot on SGI]
From: Giuseppe Sacco @ 2007-12-11 20:44 UTC (permalink / raw)
To: Ricardo Mendoza; +Cc: linux-mips
In-Reply-To: <475E9012.1010504@kanux.com>
On Tue, Dec 11, 2007 at 09:26:42AM -0400, Ricardo Mendoza wrote:
> Giuseppe Sacco wrote:
>
> > I just checked that my repository is up to date, so my problem is still
> > there (thus I don't know if it is the same problem you fixed).
> >
> > BTW, what was the problem you fixed? I would like to have a look to it,
> > to better understand what's going on there.
>
> Well I just updated to see if anything had broken in the past few days,
> but I don't seem to be hitting that error of yours. Could you send your
> config to see if I can reproduce it?
Yes, sure: http://eppesuigoccas.homedns.org/~giuseppe/debian/config-2.6.24-rc4-ip32.bz2
but please note that the problem is present in every kernel since 2.6.24-rc1
my boot stanza in arcboot is:
label=test
image=/boot/vmlinux-2.6.24-rc4-gs1
append="root=/dev/sda1 ro video=gbefb:1024x768-16@60 debug initcall_debug console=tty0 console=ttyS1,115200"
bye,
Giuseppe
^ permalink raw reply
* CFP for embedded room at FOSDEM
From: Philippe De Swert @ 2007-12-11 18:40 UTC (permalink / raw)
To: philippedeswert
Hi,
This might be of interest to developers in the Free Software/Open Source
world. FOSDEM is looking for speakers for the embedded track again.
Anyone who thinks he/she has somebody interesting to share with other
embedded developers please take a look at the call for papers.
Cheers,
Philippe
CALL FOR PAPERS for the 6th EMBEDDED track at FOSDEM 2008
=========================================================
sat 23 - sun 24 February 2008, Brussels
Call for papers
----------------
The 2008 edition of FOSDEM (Free and Open Source Developers' European
Meeting; http://www.fosdem.org) will take place in Brussels, Belgium
on 23 and 24 February 2008. For the sixth time, a track on Embedded
Systems and Operating Systems will be organized. The fourth edition
was quite succesful and attracted up to 150 attendants for certain
topics.
For last year's program see:
http://archive.fosdem.org/2007/schedule/tracks/embedded
The use of Free Software in the infrastructure of Embedded Systems
is booming, e.g. by the use of Linux, uClinux, eCos, RedBoot, RTEMS
and many other Free Software components. More companies are supporting
Embedded Free Software every day because of the reliability and cheap
licensing. This can be confirmed from looking at some high profile
releases of embedded GNU/Linux systems. Some examples are the Nokia 770
& N800,some models of Motorola's smartphones and Archos media players.
Not to forget the popular TomTom navigation system, the numerous SOHO
routers and NAS devices based on linux.
Operating System development has always been a very important topic in
Free Software.
As embedded and real-time systems typically have special OS
requirements, we organise this Free Embedded and OS development track at
FOSDEM to give people the opportunity to present their (or their teams)
achievements.
This track at FOSDEM provides a remarkable opportunity to present and
discuss the ongoing work in these areas, and we invite developers to
present their current projects. Technical topics of the conference
include but are not limited to :
* OS Development : kernel architecture and implementation, libraries,
power
management, TIPC, boot time and memory usage optimizations
(e.g. Linux, BSD, uClinux, uClibc, newlib, slob allocator,...)
* Practical experiences in implementing Free Software in embedded
systems (e.g. reverse engineering, porting to (and adapting of)
commercial devices like the Ipaq, linksys WRT54G, nlsu2 .... )
* Toolchain, performance testing and build environment
(e.g. crosstool, emdebian, openembedded, PTX dist, packaging,
scratchbox, Eclipse, Valgrind,...)
* GUIs for embedded systems
(Gtk, Qt-(embedded), GPE, Qtopia, UI design with touchscreen,
Hildon GUI extensions, OpenMoko, OpenGL ES, ...)
* Multimedia applications for embedded systems
(e.g. integer only decoders, Opieplayer, gstreamer... )
* Real-time extensions, nanokernels and hardware virtualization software
(e.g. RTAI, Adeos, KURT, L4, Qemu, User Mode Linux, VirtualLogix,
high resolution timers, ...)
* Hard real-time OS's
(eCos, RTEMS, Real Time Linux,...)
* Open hardware, DSP, softcores and general hardware management
(e.g opencores.org, OpenRISC, leonSparc, FPGA's, specific design
restrictions for free systems, DSP, Power management...)
* Safety and security certifications applied to Free software
(e.g. security measures in Embedded systems, TPM, SELinux
for embedded, TrustZone, ...)
* Tools and techniques for programming multicore systems
* Free software licenses and embedded systems
Authors that wish to present a topic are requested to submit their
abstracts online to embedded@fosdem.org before 23/01/2008. Notification
of receipt will be sent within 48 hours. Authors wishing to submit a
full paper (between 6 and 12 A4 pages), can do so in PS or PDF format.
The Program Committee will evaluate the abstracts and consists of:
* Geert Uytterhoeven, Sony NSCE, Belgium
* Peter De Schrijver (p2), Nokia (OSSO), Finland
* Philippe De Swert, Nokia (OSSO), Finland
* Klaas van Gend, MontaVista Software, The Netherlands
* Michael Opdenacker, Free Electrons, France
^ permalink raw reply
* [PATCH] RBTX4927: linux-2.6.24-rc4 hang on boot
From: Frank Rowand @ 2007-12-11 15:16 UTC (permalink / raw)
To: linux-mips; +Cc: frank.rowand
In linux-2.6.24-rc4 the Toshiba RBTX4927 hangs on boot.
The cause is that plat_time_init() from arch/mips/tx4927/common/tx4927_setup.c
does not override the __weak plat_time_init() from arch/mips/kernel/time.c.
This is due to a compiler bug in gcc 4.1.1. The bug is reported to not exist
in earlier versions of gcc, and to be fixed in 4.1.2. The problem is that
the __weak plat_time_init() is empty and thus gets optimized out of
existence (thus the linker is never given the option to replace the
__weak function).
For more info on the gcc bug see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27781
The attached patch is one workaround. Another possible workaround
would be to change the __weak plat_time_init() to be a non-empty
function.
Signed-off-by: Frank Rowand <frank.rowand@am.sony.com>
---
arch/mips/kernel/Makefile | 4 4 + 0 - 0 !
1 files changed, 4 insertions(+)
Index: linux-2.6.24-rc4/arch/mips/kernel/Makefile
===================================================================
--- linux-2.6.24-rc4.orig/arch/mips/kernel/Makefile
+++ linux-2.6.24-rc4/arch/mips/kernel/Makefile
@@ -83,6 +83,10 @@ obj-$(CONFIG_EARLY_PRINTK) += early_prin
CFLAGS_cpu-bugs64.o = $(shell if $(CC) $(KBUILD_CFLAGS) -Wa,-mdaddi -c -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-DHAVE_AS_SET_DADDI"; fi)
+# workaround for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27781,
+# which impacts plat_time_init() for tx4927, gcc 4.1.1
+CFLAGS_time.o += -fno-unit-at-a-time
+
obj-$(CONFIG_HAVE_STD_PC_SERIAL_PORT) += 8250-platform.o
EXTRA_CFLAGS += -Werror
^ permalink raw reply
* Re: Still no 2.6.24 on ip32 [was: Re: 2.6.24-rc1 does not boot on SGI]
From: Ricardo Mendoza @ 2007-12-11 13:26 UTC (permalink / raw)
To: Giuseppe Sacco; +Cc: linux-mips
In-Reply-To: <1197371095.7889.24.camel@scarafaggio>
Giuseppe Sacco wrote:
> I just checked that my repository is up to date, so my problem is still
> there (thus I don't know if it is the same problem you fixed).
>
> BTW, what was the problem you fixed? I would like to have a look to it,
> to better understand what's going on there.
Well I just updated to see if anything had broken in the past few days,
but I don't seem to be hitting that error of yours. Could you send your
config to see if I can reproduce it?
Ricardo
^ permalink raw reply
* Re: Cobalt fixes
From: Ralf Baechle @ 2007-12-11 15:35 UTC (permalink / raw)
To: Yoichi Yuasa; +Cc: linux-mips
In-Reply-To: <20071211235001.8621bdb9.yoichi_yuasa@tripeaks.co.jp>
On Tue, Dec 11, 2007 at 11:50:01PM +0900, Yoichi Yuasa wrote:
> > for non-subscribers. Linus has reverted the offending patch
> > fd6e732186ab522c812ab19c2c5e5befb8ec8115 in question so now the PCI and
> > I/O port code needs to be fixed up to be able to handle such a setup.
>
> It can be fixed my fix PCI resource patch.
>
> http://www.linux-mips.org/archives/linux-mips/2007-01/msg00049.html
Modulo a codying style issue that one is the same as the pci.c segment of
the patch I've just posted.
Ralf
^ permalink raw reply
* Re: Cobalt fixes
From: Yoichi Yuasa @ 2007-12-11 14:50 UTC (permalink / raw)
To: Ralf Baechle; +Cc: yoichi_yuasa, linux-mips
In-Reply-To: <20071211121220.GA10870@linux-mips.org>
On Tue, 11 Dec 2007 12:12:20 +0000
Ralf Baechle <ralf@linux-mips.org> wrote:
> Some may have been following the beginning of this thread on linux-kernel,
> see for example
>
> http://www.opensubscriber.com/message/linux-kernel@vger.kernel.org/8161812.html
>
> for non-subscribers. Linus has reverted the offending patch
> fd6e732186ab522c812ab19c2c5e5befb8ec8115 in question so now the PCI and
> I/O port code needs to be fixed up to be able to handle such a setup.
It can be fixed my fix PCI resource patch.
http://www.linux-mips.org/archives/linux-mips/2007-01/msg00049.html
Yoichi
^ permalink raw reply
* Re: Cobalt fixes
From: Ralf Baechle @ 2007-12-11 14:43 UTC (permalink / raw)
To: Yoichi Yuasa; +Cc: linux-mips
In-Reply-To: <20071211234026.f3de7e7f.yoichi_yuasa@tripeaks.co.jp>
On Tue, Dec 11, 2007 at 11:40:26PM +0900, Yoichi Yuasa wrote:
> > Some may have been following the beginning of this thread on linux-kernel,
> > see for example
> >
> > http://www.opensubscriber.com/message/linux-kernel@vger.kernel.org/8161812.html
> >
> > for non-subscribers. Linus has reverted the offending patch
> > fd6e732186ab522c812ab19c2c5e5befb8ec8115 in question so now the PCI and
> > I/O port code needs to be fixed up to be able to handle such a setup.
> >
> > A test report of this patch which is meant to be applied on top of
> > today's lmo git kernel on a Cobalt would be appreciated.
>
> It breaks all I/O port device(LCD, tulip, VIA ata) drivers.
Thanks, I'll try to sort this out tonight when I'm hopefully going to have
access to an actual machine.
The bootup messages of the failing kernel might be interesting, if you have
them at hand.
Ralf
^ permalink raw reply
* Re: Cobalt fixes
From: Yoichi Yuasa @ 2007-12-11 14:40 UTC (permalink / raw)
To: Ralf Baechle; +Cc: yoichi_yuasa, linux-mips
In-Reply-To: <20071211121220.GA10870@linux-mips.org>
On Tue, 11 Dec 2007 12:12:20 +0000
Ralf Baechle <ralf@linux-mips.org> wrote:
> Some may have been following the beginning of this thread on linux-kernel,
> see for example
>
> http://www.opensubscriber.com/message/linux-kernel@vger.kernel.org/8161812.html
>
> for non-subscribers. Linus has reverted the offending patch
> fd6e732186ab522c812ab19c2c5e5befb8ec8115 in question so now the PCI and
> I/O port code needs to be fixed up to be able to handle such a setup.
>
> A test report of this patch which is meant to be applied on top of
> today's lmo git kernel on a Cobalt would be appreciated.
It breaks all I/O port device(LCD, tulip, VIA ata) drivers.
Yoichi
^ permalink raw reply
* Re: [PATCH] Alchemy: fix off by two error in __fixup_bigphys_addr()
From: Ralf Baechle @ 2007-12-11 12:19 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-mips
In-Reply-To: <200712102036.50247.sshtylyov@ru.mvista.com>
On Mon, Dec 10, 2007 at 08:36:50PM +0300, Sergei Shtylyov wrote:
> he PCI specific code in this function doesn't check for the address range being
> under the upper bound of the PCI memory window correctly -- fix this, somewhat
> beautifying the code around the check, while at it...
>
> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Applied, too.
Thanks,
Ralf
^ permalink raw reply
* Re: [PATCH] Alchemy: fix PCI resource conflict (take 2)
From: Ralf Baechle @ 2007-12-11 12:19 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-mips
In-Reply-To: <200712102028.51448.sshtylyov@ru.mvista.com>
On Mon, Dec 10, 2007 at 08:28:51PM +0300, Sergei Shtylyov wrote:
> ... by getting the PCI resources back into the 32-bit range -- there's no need
> therefore for CONFIG_RESOURCES_64BIT either. This makes Alchemy PCI work again
> while currently the kernel skips the bus scan.
>
> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Thanks, applied.
Which -stable branches do these two fixes need to be applied to?
Ralf
^ permalink raw reply
* Cobalt fixes
From: Ralf Baechle @ 2007-12-11 12:12 UTC (permalink / raw)
To: linux-mips, Yoichi Yuasa
Some may have been following the beginning of this thread on linux-kernel,
see for example
http://www.opensubscriber.com/message/linux-kernel@vger.kernel.org/8161812.html
for non-subscribers. Linus has reverted the offending patch
fd6e732186ab522c812ab19c2c5e5befb8ec8115 in question so now the PCI and
I/O port code needs to be fixed up to be able to handle such a setup.
A test report of this patch which is meant to be applied on top of
today's lmo git kernel on a Cobalt would be appreciated.
Ralf
[MIPS] Cobalt: Sort out legacy I/O port addressing.
Thanks to the brainfucked GT-64111 which passes CPU addresses in the PCI I/O
window to the PCI bus without any translation a Cobalt cannot generate
a low I/O port address that is below < 0x10000000 in the GT-64111 default
configuration. Fortunately the VIA VT82C586 southbridge used in Cobalts
only decodes the low 16 bits of the I/O port address for its legacy devices.
This can be exploited to generate equivalent addresses but need to use
an address different from mips_io_port_base as the base to work. In
addition PCI fixups need to be prevented from tinkering with legacy
addresses.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
diff --git a/arch/mips/cobalt/pci.c b/arch/mips/cobalt/pci.c
index cfce7af..b1fc6bd 100644
--- a/arch/mips/cobalt/pci.c
+++ b/arch/mips/cobalt/pci.c
@@ -24,8 +24,8 @@ static struct resource cobalt_mem_resource = {
};
static struct resource cobalt_io_resource = {
- .start = 0x1000,
- .end = GT_DEF_PCI0_IO_SIZE - 1,
+ .start = GT_DEF_PCI0_IO_BASE + 0x1000,
+ .end = GT_DEF_PCI0_IO_BASE + GT_DEF_PCI0_IO_SIZE - 1,
.name = "PCI I/O",
.flags = IORESOURCE_IO,
};
@@ -34,7 +34,7 @@ static struct pci_controller cobalt_pci_controller = {
.pci_ops = >64xxx_pci0_ops,
.mem_resource = &cobalt_mem_resource,
.io_resource = &cobalt_io_resource,
- .io_offset = 0 - GT_DEF_PCI0_IO_BASE,
+ .io_offset = 0,
.io_map_base = CKSEG1ADDR(GT_DEF_PCI0_IO_BASE),
};
diff --git a/arch/mips/cobalt/setup.c b/arch/mips/cobalt/setup.c
index dd23beb..f99eaa9 100644
--- a/arch/mips/cobalt/setup.c
+++ b/arch/mips/cobalt/setup.c
@@ -79,10 +79,11 @@ void __init plat_mem_setup(void)
_machine_halt = cobalt_machine_halt;
pm_power_off = cobalt_machine_halt;
- set_io_port_base(CKSEG1ADDR(GT_DEF_PCI0_IO_BASE));
+ set_io_port_base(IO_BASE);
+ set_legacy_io_port_base(CKSEG1ADDR(GT_DEF_PCI0_IO_BASE));
/* I/O port resource must include LCD/buttons */
- ioport_resource.end = 0x0fffffff;
+ ioport_resource.end = GT_DEF_PCI0_IO_BASE + GT_DEF_PCI0_IO_SIZE - 1;
/* These resources have been reserved by VIA SuperI/O chip. */
for (i = 0; i < ARRAY_SIZE(cobalt_reserved_resources); i++)
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 7f6ddcb..f8b3f5a 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -60,11 +60,14 @@ static char command_line[CL_SIZE];
char arcs_cmdline[CL_SIZE]=CONFIG_CMDLINE;
/*
- * mips_io_port_base is the begin of the address space to which x86 style
- * I/O ports are mapped.
+ * mips_io_port_base is the base of the address range into which the I/O ports
+ * are mapped. mips_legacy_io_port_base is the same but used only for legacy
+ * addresses below legacy_io_port_top.
*/
const unsigned long mips_io_port_base __read_mostly = -1;
EXPORT_SYMBOL(mips_io_port_base);
+const unsigned long mips_legacy_io_port_base __read_mostly = -1;
+EXPORT_SYMBOL(mips_legacy_io_port_base);
/*
* isa_slot_offset is the address where E(ISA) busaddress 0 is mapped
diff --git a/arch/mips/pci/fixup-cobalt.c b/arch/mips/pci/fixup-cobalt.c
index f7df114..7da133b 100644
--- a/arch/mips/pci/fixup-cobalt.c
+++ b/arch/mips/pci/fixup-cobalt.c
@@ -51,6 +51,18 @@ static void qube_raq_galileo_early_fixup(struct pci_dev *dev)
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_GT64111,
qube_raq_galileo_early_fixup);
+static void __devinit cobalt_via_ide_native_mode_fixup(struct pci_dev *dev)
+{
+ unsigned char pif;
+
+ pci_read_config_byte(dev, PCI_CLASS_PROG, &pif);
+ pif |= 4;
+ pci_write_config_byte(dev, PCI_CLASS_PROG, pif);
+}
+
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1,
+ cobalt_via_ide_native_mode_fixup);
+
static void qube_raq_via_bmIDE_fixup(struct pci_dev *dev)
{
unsigned short cfgword;
diff --git a/arch/mips/pci/pci.c b/arch/mips/pci/pci.c
index 589b745..6e6981f 100644
--- a/arch/mips/pci/pci.c
+++ b/arch/mips/pci/pci.c
@@ -242,6 +242,8 @@ static void pcibios_fixup_device_resources(struct pci_dev *dev,
for (i = 0; i < PCI_NUM_RESOURCES; i++) {
if (!dev->resource[i].start)
continue;
+ if (dev->resource[i].flags & IORESOURCE_PCI_FIXED)
+ continue;
if (dev->resource[i].flags & IORESOURCE_IO)
offset = hose->io_offset;
else if (dev->resource[i].flags & IORESOURCE_MEM)
diff --git a/include/asm-mips/io.h b/include/asm-mips/io.h
index e62058b..953be3b 100644
--- a/include/asm-mips/io.h
+++ b/include/asm-mips/io.h
@@ -53,11 +53,16 @@
/*
* On MIPS I/O ports are memory mapped, so we access them using normal
* load/store instructions. mips_io_port_base is the virtual address to
- * which all ports are being mapped. For sake of efficiency some code
- * assumes that this is an address that can be loaded with a single lui
- * instruction, so the lower 16 bits must be zero. Should be true on
- * on any sane architecture; generic code does not use this assumption.
+ * which all ports are being mapped. mips_legacy_io_port_base the same
+ * but used for ports below legacy_io_port_top. This special treatment
+ * of legacy addresses is used for example on Cobalt systems where the
+ * GT-64111 system controller doesn't allow access to low ports but aliasing
+ * can be exploited to access them anyway. So on a GT-64111 system
+ * mips_legacy_io_port_base would point to the base of the address range
+ * to which I/O ports are aliased. Having the legacy_io_port_top default of
+ * zero leaves this special treatment disabled by default.
*/
+extern const unsigned long mips_legacy_io_port_base;
extern const unsigned long mips_io_port_base;
/*
@@ -75,6 +80,12 @@ static inline void set_io_port_base(unsigned long base)
barrier();
}
+static inline void set_legacy_io_port_base(unsigned long base)
+{
+ * (unsigned long *) &mips_legacy_io_port_base = base;
+ barrier();
+}
+
/*
* Thanks to James van Artsdalen for a better timing-fix than
* the two short jumps: using outb's to a nonexistent port seems
@@ -375,9 +386,14 @@ static inline type pfx##read##bwlq(const volatile void __iomem *mem) \
static inline void pfx##out##bwlq##p(type val, unsigned long port) \
{ \
volatile type *__addr; \
+ unsigned long __vaddr; \
type __val; \
\
- __addr = (void *)__swizzle_addr_##bwlq(mips_io_port_base + port); \
+ if (port < legacy_io_port_top) \
+ __vaddr = mips_legacy_io_port_base + port; \
+ else \
+ __vaddr = mips_io_port_base + port; \
+ __addr = (void *)__swizzle_addr_##bwlq(__vaddr); \
\
__val = pfx##ioswab##bwlq(__addr, val); \
\
@@ -391,9 +407,14 @@ static inline void pfx##out##bwlq##p(type val, unsigned long port) \
static inline type pfx##in##bwlq##p(unsigned long port) \
{ \
volatile type *__addr; \
+ unsigned long __vaddr; \
type __val; \
\
- __addr = (void *)__swizzle_addr_##bwlq(mips_io_port_base + port); \
+ if (port < legacy_io_port_top) \
+ __vaddr = mips_legacy_io_port_base + port; \
+ else \
+ __vaddr = mips_io_port_base + port; \
+ __addr = (void *)__swizzle_addr_##bwlq(__vaddr); \
\
BUILD_BUG_ON(sizeof(type) > sizeof(unsigned long)); \
\
diff --git a/include/asm-mips/mach-cobalt/mangle-port.h b/include/asm-mips/mach-cobalt/mangle-port.h
new file mode 100644
index 0000000..bdf5450
--- /dev/null
+++ b/include/asm-mips/mach-cobalt/mangle-port.h
@@ -0,0 +1,27 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2003, 2004, 2007 Ralf Baechle (ralf@linux-mips.org)
+ */
+#ifndef __ASM_MACH_COBALT_MANGLE_PORT_H
+#define __ASM_MACH_COBALT_MANGLE_PORT_H
+
+#define __swizzle_addr_b(port) (port)
+#define __swizzle_addr_w(port) (port)
+#define __swizzle_addr_l(port) (port)
+#define __swizzle_addr_q(port) (port)
+
+# define ioswabb(a, x) (x)
+# define __mem_ioswabb(a, x) (x)
+# define ioswabw(a, x) (x)
+# define __mem_ioswabw(a, x) cpu_to_le16(x)
+# define ioswabl(a, x) (x)
+# define __mem_ioswabl(a, x) cpu_to_le32(x)
+# define ioswabq(a, x) (x)
+# define __mem_ioswabq(a, x) cpu_to_le32(x)
+
+#define legacy_io_port_top 0
+
+#endif /* __ASM_MACH_COBALT_MANGLE_PORT_H */
diff --git a/include/asm-mips/mach-generic/mangle-port.h b/include/asm-mips/mach-generic/mangle-port.h
index f49dc99..7f59bff 100644
--- a/include/asm-mips/mach-generic/mangle-port.h
+++ b/include/asm-mips/mach-generic/mangle-port.h
@@ -49,4 +49,6 @@
#endif
+#define legacy_io_port_top 0
+
#endif /* __ASM_MACH_GENERIC_MANGLE_PORT_H */
^ permalink raw reply related
* Still no 2.6.24 on ip32 [was: Re: 2.6.24-rc1 does not boot on SGI]
From: Giuseppe Sacco @ 2007-12-11 11:04 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <475D7FE2.7080703@kanux.com>
Il giorno lun, 10/12/2007 alle 14.05 -0400, Ricardo Mendoza ha scritto:
[...]
> > Calling initcall 0xffffffff80497028: psmouse_init+0x0/0x90()
> > maceisa enable: 49
> > crime_int 00000020 enabled
> > *irq 13, crime_int=00002000, crime_mask=003003a0, mace_int=00000000*
> > irq 13, desc: ffffffff80448390, depth: 1, count: 0, unhandled: 0
> > ->handle_irq(): ffffffff80065eb0, handle_bad_irq+0x0/0x2c0
> > ->chip(): ffffffff8043e320, 0xffffffff8043e320
> > ->action(): 0000000000000000
> > IRQ_DISABLED set
>
> I recommend you pull latest git. Looks like some issue that Ralf and I
> fixed a few weeks ago.
I just checked that my repository is up to date, so my problem is still
there (thus I don't know if it is the same problem you fixed).
BTW, what was the problem you fixed? I would like to have a look to it,
to better understand what's going on there.
Thanks,
Giuseppe
^ permalink raw reply
* [PATCH][MIPS] Kconfig fixes for BCM47XX platform
From: Aurelien Jarno @ 2007-12-11 10:30 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20071210102232.GA10145@hall.aurel32.net>
Hi,
The patch below fixes two problems for Kconfig on the BCM47xx platform:
- arch/mips/bcm47xx/gpio.c uses ssb_extif_* functions. Selecting
SSB_DRIVER_EXTIF makes sure those functions are available.
- arch/mips/pci/pci.c needs, when enabled, platform specific functions,
which are defined when SSB_PCICORE_HOSTMODE is enabled.
This patch replaces the one called "Enable SSB_DRIVER_EXTIF on BCM47XX
platform" posted yesterday.
Aurelien
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index c6fc405..b4ffcae 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -59,6 +59,8 @@ config BCM47XX
select SYS_SUPPORTS_LITTLE_ENDIAN
select SSB
select SSB_DRIVER_MIPS
+ select SSB_DRIVER_EXTIF
+ select SSB_PCICORE_HOSTMODE if PCI
select GENERIC_GPIO
select SYS_HAS_EARLY_PRINTK
select CFE
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
^ permalink raw reply related
* Re: 2.6.24-rc1 does not boot on SGI
From: Giuseppe Sacco @ 2007-12-11 5:35 UTC (permalink / raw)
To: Ricardo Mendoza; +Cc: linux-mips
In-Reply-To: <475D7FE2.7080703@kanux.com>
Hi Ricardo,
Il giorno lun, 10/12/2007 alle 14.05 -0400, Ricardo Mendoza ha scritto:
[...]
> > maceisa enable: 49
> > crime_int 00000020 enabled
> > *irq 13, crime_int=00002000, crime_mask=003003a0, mace_int=00000000*
> > irq 13, desc: ffffffff80448390, depth: 1, count: 0, unhandled: 0
> > ->handle_irq(): ffffffff80065eb0, handle_bad_irq+0x0/0x2c0
> > ->chip(): ffffffff8043e320, 0xffffffff8043e320
> > ->action(): 0000000000000000
> > IRQ_DISABLED set
>
> I recommend you pull latest git. Looks like some issue that Ralf and I
> fixed a few weeks ago.
I am using git (from linux-mips.org) of two or three days ago, but I
will try if anything is changed in the meantime.
Thanks,
Giuseppe
^ permalink raw reply
* Re: 2.6.24-rc1 does not boot on SGI
From: Ricardo Mendoza @ 2007-12-10 18:05 UTC (permalink / raw)
To: Giuseppe Sacco; +Cc: linux-mips
In-Reply-To: <1197287929.17265.6.camel@scarafaggio>
Giuseppe Sacco wrote:
> I reply to my own message, providing more details, hoping that anyone
> here could give a hint or the solution.
>
> During bootup on ip32, since 2.4.24-rc1, the system loop printing a
> message about unexpected interrupt #13. (see transcript below.)
>
> I enabled more debug in the kernel, and studied the code. What I
> understood is that interrupt #13 from CRIME means that the system should
> check on MACEISA for the real interrupt.
>
> The interrupt start appearing just after executing the code
> psmouse_init() that enable ps2 drivers for keyboard and mouse. Keyboard
> interrupt #49 is enabled first and mouse interrupt #51 is enabled later.
>
> When initialising the keyboard interrupt (it is a MACEISA interrupt),
> the interrupt start appearing, so I am pretty sure that interrupt #13 is
> related to the keyboard interrupt.
>
> When the system receive interrupt #13, it correctly detect it is a
> MACEISA interrupt, and check for mace->perif.ctrl.istat value. The
> problem seems to be that this value is zero instead of having bit #9 on
> (that would mean, interrupt #49, keyboard).
>
> So, either the interrupt #49 is not correctly enabled, or maceisa
> interrupt aren't correctly checked.
>
> Does this description ring a bell to anyone?
>
> Bye,
> Giuseppe
>
> Calling initcall 0xffffffff80496ca0: serport_init+0x0/0x48()
> initcall 0xffffffff80496ca0: serport_init+0x0/0x48() returned 0.
> initcall 0xffffffff80496ca0 ran for 0 msecs: serport_init+0x0/0x48()
> Calling initcall 0xffffffff80496ce8: maceps2_init+0x0/0xe0()
> initcall 0xffffffff80496ce8: maceps2_init+0x0/0xe0() returned 0.
> initcall 0xffffffff80496ce8 ran for 1 msecs: maceps2_init+0x0/0xe0()
> Calling initcall 0xffffffff80496dc8: serio_raw_init+0x0/0x18()
> initcall 0xffffffff80496dc8: serio_raw_init+0x0/0x18() returned 0.
> initcall 0xffffffff80496dc8 ran for 1 msecs: serio_raw_init+0x0/0x18()
> Calling initcall 0xffffffff80496f40: mousedev_init+0x0/0xd0()
> mice: PS/2 mouse device common for all mice
> initcall 0xffffffff80496f40: mousedev_init+0x0/0xd0() returned 0.
> initcall 0xffffffff80496f40 ran for 16 msecs: mousedev_init+0x0/0xd0()
> Calling initcall 0xffffffff80497010: atkbd_init+0x0/0x18()
> initcall 0xffffffff80497010: atkbd_init+0x0/0x18() returned 0.
> initcall 0xffffffff80497010 ran for 0 msecs: atkbd_init+0x0/0x18()
> Calling initcall 0xffffffff80497028: psmouse_init+0x0/0x90()
> maceisa enable: 49
> crime_int 00000020 enabled
> *irq 13, crime_int=00002000, crime_mask=003003a0, mace_int=00000000*
> irq 13, desc: ffffffff80448390, depth: 1, count: 0, unhandled: 0
> ->handle_irq(): ffffffff80065eb0, handle_bad_irq+0x0/0x2c0
> ->chip(): ffffffff8043e320, 0xffffffff8043e320
> ->action(): 0000000000000000
> IRQ_DISABLED set
I recommend you pull latest git. Looks like some issue that Ralf and I
fixed a few weeks ago.
Ricardo
^ permalink raw reply
* Re: [PATCH] Alchemy: fix PCI resource conflict (take 2)
From: Sergei Shtylyov @ 2007-12-10 17:48 UTC (permalink / raw)
To: Nathan Eggan; +Cc: linux-mips mailing list
In-Reply-To: <BLU127-W1655DCD5A946AF12DE533E8A6B0@phx.gbl>
Nathan Eggan wrote:
> Any chance this will help fix my Au1x00 serial + USB issues?
I don't think so.
> I know the old PCI bus code used to not work with the USB - at least the two could not run together.
There are some chip errata connected with USB and PCI...
WBR, Sergei
^ permalink raw reply
* RE: [PATCH] Alchemy: fix PCI resource conflict (take 2)
From: Nathan Eggan @ 2007-12-10 17:43 UTC (permalink / raw)
To: linux-mips mailing list
In-Reply-To: <200712102028.51448.sshtylyov@ru.mvista.com>
Any chance this will help fix my Au1x00 serial + USB issues? I know the old PCI bus code used to not work with the USB - at least the two could not run together. It's been a while since I looked at those issues, so that may have been resolved long ago.
Just curious,
Thanks!
Nate
----------------------------------------
> From: sshtylyov@ru.mvista.com
> To: ralf@linux-mips.org
> Subject: [PATCH] Alchemy: fix PCI resource conflict (take 2)
> Date: Mon, 10 Dec 2007 20:28:51 +0300
> CC: linux-mips@linux-mips.org
>
> ... by getting the PCI resources back into the 32-bit range -- there's no need
> therefore for CONFIG_RESOURCES_64BIT either. This makes Alchemy PCI work again
> while currently the kernel skips the bus scan.
>
> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
>
> ---
> arch/mips/au1000/Kconfig | 9 ---------
> arch/mips/au1000/common/pci.c | 8 ++++----
> include/asm-mips/mach-au1x00/au1000.h | 9 +++++----
> 3 files changed, 9 insertions(+), 17 deletions(-)
>
> Index: linux-2.6/arch/mips/au1000/Kconfig
> ===================================================================
> --- linux-2.6.orig/arch/mips/au1000/Kconfig
> +++ linux-2.6/arch/mips/au1000/Kconfig
> @@ -7,7 +7,6 @@ config MIPS_MTX1
> bool "4G Systems MTX-1 board"
> select DMA_NONCOHERENT
> select HW_HAS_PCI
> - select RESOURCES_64BIT if PCI
> select SOC_AU1500
> select SYS_SUPPORTS_LITTLE_ENDIAN
>
> @@ -22,7 +21,6 @@ config MIPS_DB1000
> select SOC_AU1000
> select DMA_NONCOHERENT
> select HW_HAS_PCI
> - select RESOURCES_64BIT if PCI
> select SYS_SUPPORTS_LITTLE_ENDIAN
>
> config MIPS_DB1100
> @@ -44,7 +42,6 @@ config MIPS_DB1500
> select DMA_NONCOHERENT
> select HW_HAS_PCI
> select MIPS_DISABLE_OBSOLETE_IDE
> - select RESOURCES_64BIT if PCI
> select SYS_SUPPORTS_BIG_ENDIAN
> select SYS_SUPPORTS_LITTLE_ENDIAN
>
> @@ -54,7 +51,6 @@ config MIPS_DB1550
> select HW_HAS_PCI
> select DMA_NONCOHERENT
> select MIPS_DISABLE_OBSOLETE_IDE
> - select RESOURCES_64BIT if PCI
> select SYS_SUPPORTS_LITTLE_ENDIAN
>
> config MIPS_MIRAGE
> @@ -68,7 +64,6 @@ config MIPS_PB1000
> select SOC_AU1000
> select DMA_NONCOHERENT
> select HW_HAS_PCI
> - select RESOURCES_64BIT if PCI
> select SWAP_IO_SPACE
> select SYS_SUPPORTS_LITTLE_ENDIAN
>
> @@ -77,7 +72,6 @@ config MIPS_PB1100
> select SOC_AU1100
> select DMA_NONCOHERENT
> select HW_HAS_PCI
> - select RESOURCES_64BIT if PCI
> select SWAP_IO_SPACE
> select SYS_SUPPORTS_LITTLE_ENDIAN
>
> @@ -86,7 +80,6 @@ config MIPS_PB1200
> select SOC_AU1200
> select DMA_NONCOHERENT
> select MIPS_DISABLE_OBSOLETE_IDE
> - select RESOURCES_64BIT if PCI
> select SYS_SUPPORTS_LITTLE_ENDIAN
>
> config MIPS_PB1500
> @@ -94,7 +87,6 @@ config MIPS_PB1500
> select SOC_AU1500
> select DMA_NONCOHERENT
> select HW_HAS_PCI
> - select RESOURCES_64BIT if PCI
> select SYS_SUPPORTS_LITTLE_ENDIAN
>
> config MIPS_PB1550
> @@ -103,7 +95,6 @@ config MIPS_PB1550
> select DMA_NONCOHERENT
> select HW_HAS_PCI
> select MIPS_DISABLE_OBSOLETE_IDE
> - select RESOURCES_64BIT if PCI
> select SYS_SUPPORTS_LITTLE_ENDIAN
>
> config MIPS_XXS1500
> Index: linux-2.6/arch/mips/au1000/common/pci.c
> ===================================================================
> --- linux-2.6.orig/arch/mips/au1000/common/pci.c
> +++ linux-2.6/arch/mips/au1000/common/pci.c
> @@ -39,15 +39,15 @@
>
> /* TBD */
> static struct resource pci_io_resource = {
> - .start = (resource_size_t)PCI_IO_START,
> - .end = (resource_size_t)PCI_IO_END,
> + .start = PCI_IO_START,
> + .end = PCI_IO_END,
> .name = "PCI IO space",
> .flags = IORESOURCE_IO
> };
>
> static struct resource pci_mem_resource = {
> - .start = (resource_size_t)PCI_MEM_START,
> - .end = (resource_size_t)PCI_MEM_END,
> + .start = PCI_MEM_START,
> + .end = PCI_MEM_END,
> .name = "PCI memory space",
> .flags = IORESOURCE_MEM
> };
> Index: linux-2.6/include/asm-mips/mach-au1x00/au1000.h
> ===================================================================
> --- linux-2.6.orig/include/asm-mips/mach-au1x00/au1000.h
> +++ linux-2.6/include/asm-mips/mach-au1x00/au1000.h
> @@ -1680,10 +1680,11 @@ enum soc_au1200_ints {
> #define Au1500_PCI_MEM_START 0x440000000ULL
> #define Au1500_PCI_MEM_END 0x44FFFFFFFULL
>
> -#define PCI_IO_START (Au1500_PCI_IO_START + 0x1000)
> -#define PCI_IO_END (Au1500_PCI_IO_END)
> -#define PCI_MEM_START (Au1500_PCI_MEM_START)
> -#define PCI_MEM_END (Au1500_PCI_MEM_END)
> +#define PCI_IO_START 0x00001000
> +#define PCI_IO_END 0x000FFFFF
> +#define PCI_MEM_START 0x40000000
> +#define PCI_MEM_END 0x4FFFFFFF
> +
> #define PCI_FIRST_DEVFN (0<<3)
> #define PCI_LAST_DEVFN (19<<3)
>
>
>
_________________________________________________________________
Connect and share in new ways with Windows Live.
http://www.windowslive.com/connect.html?ocid=TXT_TAGLM_Wave2_newways_112007
From sshtylyov@ru.mvista.com Mon Dec 10 17:47:46 2007
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 Dec 2007 17:47:55 +0000 (GMT)
Received: from h155.mvista.com ([63.81.120.155]:61635 "EHLO imap.sh.mvista.com")
by ftp.linux-mips.org with ESMTP id S20025092AbXLJRrq (ORCPT
<rfc822;linux-mips@linux-mips.org>); Mon, 10 Dec 2007 17:47:46 +0000
Received: from [192.168.1.234] (unknown [10.150.0.9])
by imap.sh.mvista.com (Postfix) with ESMTP
id 7C24D3ECD; Mon, 10 Dec 2007 09:47:43 -0800 (PST)
Message-ID: <475D7BD4.1050505@ru.mvista.com>
Date: Mon, 10 Dec 2007 20:48:04 +0300
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Organization: MontaVista Software Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803
X-Accept-Language: ru, en-us, en-gb
MIME-Version: 1.0
To: Nathan Eggan <nathan_eggan@live.com>
Cc: linux-mips mailing list <linux-mips@linux-mips.org>
Subject: Re: [PATCH] Alchemy: fix PCI resource conflict (take 2)
References: <200712102028.51448.sshtylyov@ru.mvista.com> <BLU127-W1655DCD5A946AF12DE533E8A6B0@phx.gbl>
In-Reply-To: <BLU127-W1655DCD5A946AF12DE533E8A6B0@phx.gbl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <sshtylyov@ru.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 17763
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sshtylyov@ru.mvista.com
Precedence: bulk
X-list: linux-mips
Nathan Eggan wrote:
> Any chance this will help fix my Au1x00 serial + USB issues?
I don't think so.
> I know the old PCI bus code used to not work with the USB - at least the two could not run together.
There are some chip errata connected with USB and PCI...
WBR, Sergei
^ permalink raw reply
* RE: [PATCH] Alchemy: fix PCI resource conflict (take 2)
From: Nathan Eggan @ 2007-12-10 17:43 UTC (permalink / raw)
To: linux-mips mailing list
In-Reply-To: <200712102028.51448.sshtylyov@ru.mvista.com>
Any chance this will help fix my Au1x00 serial + USB issues? I know the old PCI bus code used to not work with the USB - at least the two could not run together. It's been a while since I looked at those issues, so that may have been resolved long ago.
Just curious,
Thanks!
Nate
----------------------------------------
> From: sshtylyov@ru.mvista.com
> To: ralf@linux-mips.org
> Subject: [PATCH] Alchemy: fix PCI resource conflict (take 2)
> Date: Mon, 10 Dec 2007 20:28:51 +0300
> CC: linux-mips@linux-mips.org
>
> ... by getting the PCI resources back into the 32-bit range -- there's no need
> therefore for CONFIG_RESOURCES_64BIT either. This makes Alchemy PCI work again
> while currently the kernel skips the bus scan.
>
> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
>
> ---
> arch/mips/au1000/Kconfig | 9 ---------
> arch/mips/au1000/common/pci.c | 8 ++++----
> include/asm-mips/mach-au1x00/au1000.h | 9 +++++----
> 3 files changed, 9 insertions(+), 17 deletions(-)
>
> Index: linux-2.6/arch/mips/au1000/Kconfig
> ===================================================================
> --- linux-2.6.orig/arch/mips/au1000/Kconfig
> +++ linux-2.6/arch/mips/au1000/Kconfig
> @@ -7,7 +7,6 @@ config MIPS_MTX1
> bool "4G Systems MTX-1 board"
> select DMA_NONCOHERENT
> select HW_HAS_PCI
> - select RESOURCES_64BIT if PCI
> select SOC_AU1500
> select SYS_SUPPORTS_LITTLE_ENDIAN
>
> @@ -22,7 +21,6 @@ config MIPS_DB1000
> select SOC_AU1000
> select DMA_NONCOHERENT
> select HW_HAS_PCI
> - select RESOURCES_64BIT if PCI
> select SYS_SUPPORTS_LITTLE_ENDIAN
>
> config MIPS_DB1100
> @@ -44,7 +42,6 @@ config MIPS_DB1500
> select DMA_NONCOHERENT
> select HW_HAS_PCI
> select MIPS_DISABLE_OBSOLETE_IDE
> - select RESOURCES_64BIT if PCI
> select SYS_SUPPORTS_BIG_ENDIAN
> select SYS_SUPPORTS_LITTLE_ENDIAN
>
> @@ -54,7 +51,6 @@ config MIPS_DB1550
> select HW_HAS_PCI
> select DMA_NONCOHERENT
> select MIPS_DISABLE_OBSOLETE_IDE
> - select RESOURCES_64BIT if PCI
> select SYS_SUPPORTS_LITTLE_ENDIAN
>
> config MIPS_MIRAGE
> @@ -68,7 +64,6 @@ config MIPS_PB1000
> select SOC_AU1000
> select DMA_NONCOHERENT
> select HW_HAS_PCI
> - select RESOURCES_64BIT if PCI
> select SWAP_IO_SPACE
> select SYS_SUPPORTS_LITTLE_ENDIAN
>
> @@ -77,7 +72,6 @@ config MIPS_PB1100
> select SOC_AU1100
> select DMA_NONCOHERENT
> select HW_HAS_PCI
> - select RESOURCES_64BIT if PCI
> select SWAP_IO_SPACE
> select SYS_SUPPORTS_LITTLE_ENDIAN
>
> @@ -86,7 +80,6 @@ config MIPS_PB1200
> select SOC_AU1200
> select DMA_NONCOHERENT
> select MIPS_DISABLE_OBSOLETE_IDE
> - select RESOURCES_64BIT if PCI
> select SYS_SUPPORTS_LITTLE_ENDIAN
>
> config MIPS_PB1500
> @@ -94,7 +87,6 @@ config MIPS_PB1500
> select SOC_AU1500
> select DMA_NONCOHERENT
> select HW_HAS_PCI
> - select RESOURCES_64BIT if PCI
> select SYS_SUPPORTS_LITTLE_ENDIAN
>
> config MIPS_PB1550
> @@ -103,7 +95,6 @@ config MIPS_PB1550
> select DMA_NONCOHERENT
> select HW_HAS_PCI
> select MIPS_DISABLE_OBSOLETE_IDE
> - select RESOURCES_64BIT if PCI
> select SYS_SUPPORTS_LITTLE_ENDIAN
>
> config MIPS_XXS1500
> Index: linux-2.6/arch/mips/au1000/common/pci.c
> ===================================================================
> --- linux-2.6.orig/arch/mips/au1000/common/pci.c
> +++ linux-2.6/arch/mips/au1000/common/pci.c
> @@ -39,15 +39,15 @@
>
> /* TBD */
> static struct resource pci_io_resource = {
> - .start = (resource_size_t)PCI_IO_START,
> - .end = (resource_size_t)PCI_IO_END,
> + .start = PCI_IO_START,
> + .end = PCI_IO_END,
> .name = "PCI IO space",
> .flags = IORESOURCE_IO
> };
>
> static struct resource pci_mem_resource = {
> - .start = (resource_size_t)PCI_MEM_START,
> - .end = (resource_size_t)PCI_MEM_END,
> + .start = PCI_MEM_START,
> + .end = PCI_MEM_END,
> .name = "PCI memory space",
> .flags = IORESOURCE_MEM
> };
> Index: linux-2.6/include/asm-mips/mach-au1x00/au1000.h
> ===================================================================
> --- linux-2.6.orig/include/asm-mips/mach-au1x00/au1000.h
> +++ linux-2.6/include/asm-mips/mach-au1x00/au1000.h
> @@ -1680,10 +1680,11 @@ enum soc_au1200_ints {
> #define Au1500_PCI_MEM_START 0x440000000ULL
> #define Au1500_PCI_MEM_END 0x44FFFFFFFULL
>
> -#define PCI_IO_START (Au1500_PCI_IO_START + 0x1000)
> -#define PCI_IO_END (Au1500_PCI_IO_END)
> -#define PCI_MEM_START (Au1500_PCI_MEM_START)
> -#define PCI_MEM_END (Au1500_PCI_MEM_END)
> +#define PCI_IO_START 0x00001000
> +#define PCI_IO_END 0x000FFFFF
> +#define PCI_MEM_START 0x40000000
> +#define PCI_MEM_END 0x4FFFFFFF
> +
> #define PCI_FIRST_DEVFN (0<<3)
> #define PCI_LAST_DEVFN (19<<3)
>
>
>
_________________________________________________________________
Connect and share in new ways with Windows Live.
http://www.windowslive.com/connect.html?ocid=TXT_TAGLM_Wave2_newways_112007
^ permalink raw reply
* [PATCH] Alchemy: fix off by two error in __fixup_bigphys_addr()
From: Sergei Shtylyov @ 2007-12-10 17:36 UTC (permalink / raw)
To: ralf; +Cc: linux-mips
he PCI specific code in this function doesn't check for the address range being
under the upper bound of the PCI memory window correctly -- fix this, somewhat
beautifying the code around the check, while at it...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
---
arch/mips/au1000/common/setup.c | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
Index: linux-2.6/arch/mips/au1000/common/setup.c
===================================================================
--- linux-2.6.orig/arch/mips/au1000/common/setup.c
+++ linux-2.6/arch/mips/au1000/common/setup.c
@@ -137,12 +137,11 @@ phys_t __fixup_bigphys_addr(phys_t phys_
#ifdef CONFIG_PCI
{
- u32 start, end;
+ u32 start = (u32)Au1500_PCI_MEM_START;
+ u32 end = (u32)Au1500_PCI_MEM_END;
- start = (u32)Au1500_PCI_MEM_START;
- end = (u32)Au1500_PCI_MEM_END;
- /* check for pci memory window */
- if ((phys_addr >= start) && ((phys_addr + size) < end))
+ /* Check for PCI memory window */
+ if (phys_addr >= start && (phys_addr + size - 1) <= end)
return (phys_t)
((phys_addr - start) + Au1500_PCI_MEM_START);
}
^ permalink raw reply
* [PATCH] Alchemy: fix PCI resource conflict (take 2)
From: Sergei Shtylyov @ 2007-12-10 17:28 UTC (permalink / raw)
To: ralf; +Cc: linux-mips
... by getting the PCI resources back into the 32-bit range -- there's no need
therefore for CONFIG_RESOURCES_64BIT either. This makes Alchemy PCI work again
while currently the kernel skips the bus scan.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
---
arch/mips/au1000/Kconfig | 9 ---------
arch/mips/au1000/common/pci.c | 8 ++++----
include/asm-mips/mach-au1x00/au1000.h | 9 +++++----
3 files changed, 9 insertions(+), 17 deletions(-)
Index: linux-2.6/arch/mips/au1000/Kconfig
===================================================================
--- linux-2.6.orig/arch/mips/au1000/Kconfig
+++ linux-2.6/arch/mips/au1000/Kconfig
@@ -7,7 +7,6 @@ config MIPS_MTX1
bool "4G Systems MTX-1 board"
select DMA_NONCOHERENT
select HW_HAS_PCI
- select RESOURCES_64BIT if PCI
select SOC_AU1500
select SYS_SUPPORTS_LITTLE_ENDIAN
@@ -22,7 +21,6 @@ config MIPS_DB1000
select SOC_AU1000
select DMA_NONCOHERENT
select HW_HAS_PCI
- select RESOURCES_64BIT if PCI
select SYS_SUPPORTS_LITTLE_ENDIAN
config MIPS_DB1100
@@ -44,7 +42,6 @@ config MIPS_DB1500
select DMA_NONCOHERENT
select HW_HAS_PCI
select MIPS_DISABLE_OBSOLETE_IDE
- select RESOURCES_64BIT if PCI
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_LITTLE_ENDIAN
@@ -54,7 +51,6 @@ config MIPS_DB1550
select HW_HAS_PCI
select DMA_NONCOHERENT
select MIPS_DISABLE_OBSOLETE_IDE
- select RESOURCES_64BIT if PCI
select SYS_SUPPORTS_LITTLE_ENDIAN
config MIPS_MIRAGE
@@ -68,7 +64,6 @@ config MIPS_PB1000
select SOC_AU1000
select DMA_NONCOHERENT
select HW_HAS_PCI
- select RESOURCES_64BIT if PCI
select SWAP_IO_SPACE
select SYS_SUPPORTS_LITTLE_ENDIAN
@@ -77,7 +72,6 @@ config MIPS_PB1100
select SOC_AU1100
select DMA_NONCOHERENT
select HW_HAS_PCI
- select RESOURCES_64BIT if PCI
select SWAP_IO_SPACE
select SYS_SUPPORTS_LITTLE_ENDIAN
@@ -86,7 +80,6 @@ config MIPS_PB1200
select SOC_AU1200
select DMA_NONCOHERENT
select MIPS_DISABLE_OBSOLETE_IDE
- select RESOURCES_64BIT if PCI
select SYS_SUPPORTS_LITTLE_ENDIAN
config MIPS_PB1500
@@ -94,7 +87,6 @@ config MIPS_PB1500
select SOC_AU1500
select DMA_NONCOHERENT
select HW_HAS_PCI
- select RESOURCES_64BIT if PCI
select SYS_SUPPORTS_LITTLE_ENDIAN
config MIPS_PB1550
@@ -103,7 +95,6 @@ config MIPS_PB1550
select DMA_NONCOHERENT
select HW_HAS_PCI
select MIPS_DISABLE_OBSOLETE_IDE
- select RESOURCES_64BIT if PCI
select SYS_SUPPORTS_LITTLE_ENDIAN
config MIPS_XXS1500
Index: linux-2.6/arch/mips/au1000/common/pci.c
===================================================================
--- linux-2.6.orig/arch/mips/au1000/common/pci.c
+++ linux-2.6/arch/mips/au1000/common/pci.c
@@ -39,15 +39,15 @@
/* TBD */
static struct resource pci_io_resource = {
- .start = (resource_size_t)PCI_IO_START,
- .end = (resource_size_t)PCI_IO_END,
+ .start = PCI_IO_START,
+ .end = PCI_IO_END,
.name = "PCI IO space",
.flags = IORESOURCE_IO
};
static struct resource pci_mem_resource = {
- .start = (resource_size_t)PCI_MEM_START,
- .end = (resource_size_t)PCI_MEM_END,
+ .start = PCI_MEM_START,
+ .end = PCI_MEM_END,
.name = "PCI memory space",
.flags = IORESOURCE_MEM
};
Index: linux-2.6/include/asm-mips/mach-au1x00/au1000.h
===================================================================
--- linux-2.6.orig/include/asm-mips/mach-au1x00/au1000.h
+++ linux-2.6/include/asm-mips/mach-au1x00/au1000.h
@@ -1680,10 +1680,11 @@ enum soc_au1200_ints {
#define Au1500_PCI_MEM_START 0x440000000ULL
#define Au1500_PCI_MEM_END 0x44FFFFFFFULL
-#define PCI_IO_START (Au1500_PCI_IO_START + 0x1000)
-#define PCI_IO_END (Au1500_PCI_IO_END)
-#define PCI_MEM_START (Au1500_PCI_MEM_START)
-#define PCI_MEM_END (Au1500_PCI_MEM_END)
+#define PCI_IO_START 0x00001000
+#define PCI_IO_END 0x000FFFFF
+#define PCI_MEM_START 0x40000000
+#define PCI_MEM_END 0x4FFFFFFF
+
#define PCI_FIRST_DEVFN (0<<3)
#define PCI_LAST_DEVFN (19<<3)
^ permalink raw reply
* Re: SiByte 1480 & Branch Likely instructions?
From: Maciej W. Rozycki @ 2007-12-10 16:20 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Kaz Kylheku, linux-mips
In-Reply-To: <20071210153523.GA19384@linux-mips.org>
On Mon, 10 Dec 2007, Ralf Baechle wrote:
> It would devastate the performance of some binaries.
I think this is what the deprecation is about. ;-)
> As an intellectual challenge, how far can you strip down a MIPS
> implementation and emulate removed instructions in the kernel ;-)
Well, going back to MIPS I is certainly achievable (OK, we could keep
ll/sc for the sake of sanity) and then perhaps a little bit further.
After all, all of the ALU ops can be done with the NOR op only. ;-)
Maciej
^ permalink raw reply
* Re: SiByte 1480 & Branch Likely instructions?
From: Ralf Baechle @ 2007-12-10 15:35 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Kaz Kylheku, linux-mips
In-Reply-To: <Pine.LNX.4.64N.0712101522100.1177@blysk.ds.pg.gda.pl>
On Mon, Dec 10, 2007 at 03:28:52PM +0000, Maciej W. Rozycki wrote:
> > > Not really a kernel-related question. I've discovered that GCC 4.1.1
> > > (which I'm not using for kernel compiling, but user space) generates
> > > branch likely instructions by default, even though the documentation
> > > says that their use is off by default for MIPS32 and MIPS64, because
> > > they are considered deprecated. They are documented as obsolete for the
> > > Broadcom chips I am working with.
> >
> > Microarchitecture guys love to hate branch likely. But the deprecation is
> > a dream. Binary compatibility will always require those instructions to
> > continue to exist so the genie is out of the bottle and so I feel very
> > certain to predict that a future MIPS 3 specification will contain branch
> > likely.
>
> We have been there before -- binary compatibility does not preclude
> emulation. And I do not mean keeping the MIPS I toys (as they might be
> seen these days) running, but serious products deployed commercially, like
> newer VAX implementations that kept full binary compatibility with their
> predecessors in the area of the some of the more arcane instructions only
> by means of emulating them in the OS.
It would devastate the performance of some binaries.
As an intellectual challenge, how far can you strip down a MIPS
implementation and emulate removed instructions in the kernel ;-)
Ralf
^ permalink raw reply
* Re: SiByte 1480 & Branch Likely instructions?
From: Maciej W. Rozycki @ 2007-12-10 15:28 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Kaz Kylheku, linux-mips
In-Reply-To: <20071209051450.GA18181@linux-mips.org>
On Sun, 9 Dec 2007, Ralf Baechle wrote:
> > Not really a kernel-related question. I've discovered that GCC 4.1.1
> > (which I'm not using for kernel compiling, but user space) generates
> > branch likely instructions by default, even though the documentation
> > says that their use is off by default for MIPS32 and MIPS64, because
> > they are considered deprecated. They are documented as obsolete for the
> > Broadcom chips I am working with.
>
> Microarchitecture guys love to hate branch likely. But the deprecation is
> a dream. Binary compatibility will always require those instructions to
> continue to exist so the genie is out of the bottle and so I feel very
> certain to predict that a future MIPS 3 specification will contain branch
> likely.
We have been there before -- binary compatibility does not preclude
emulation. And I do not mean keeping the MIPS I toys (as they might be
seen these days) running, but serious products deployed commercially, like
newer VAX implementations that kept full binary compatibility with their
predecessors in the area of the some of the more arcane instructions only
by means of emulating them in the OS.
Maciej
^ 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