* [PATCH][MIPS][2/6]: AR7 mtd partition map
From: Matteo Croce @ 2007-12-27 18:22 UTC (permalink / raw)
To: linux-mips
Cc: Felix Fietkau, Eugene Konev, dwmw2, linux-mtd, openwrt-devel,
Andrew Morton
In-Reply-To: <200712271919.23577.technoboy85@gmail.com>
Signed-off-by: Matteo Croce <technoboy85@gmail.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Eugene Konev <ejka@imfi.kspu.ru>
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 8848e8a..e421446 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -150,6 +150,12 @@ config MTD_AFS_PARTS
for your particular device. It won't happen automatically. The
'armflash' map driver (CONFIG_MTD_ARMFLASH) does this, for example.
+config MTD_AR7_PARTS
+ tristate "TI AR7 partitioning support"
+ depends on MTD_PARTITIONS
+ ---help---
+ TI AR7 partitioning support
+
comment "User Modules And Translation Layers"
config MTD_CHAR
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 7f0b04b..95d1ed2 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_MTD_CONCAT) += mtdconcat.o
obj-$(CONFIG_MTD_REDBOOT_PARTS) += redboot.o
obj-$(CONFIG_MTD_CMDLINE_PARTS) += cmdlinepart.o
obj-$(CONFIG_MTD_AFS_PARTS) += afs.o
+obj-$(CONFIG_MTD_AR7_PARTS) += ar7part.o
# 'Users' - code which presents functionality to userspace.
obj-$(CONFIG_MTD_CHAR) += mtdchar.o
diff --git a/drivers/mtd/ar7part.c b/drivers/mtd/ar7part.c
new file mode 100644
index 0000000..3d160d4
--- /dev/null
+++ b/drivers/mtd/ar7part.c
@@ -0,0 +1,146 @@
+/*
+ * Copyright (C) 2007 Eugene Konev <ejka@openwrt.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ * TI AR7 flash partition table.
+ * Based on ar7 map by Felix Fietkau <nbd@openwrt.org>
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/slab.h>
+
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
+#include <linux/bootmem.h>
+#include <linux/magic.h>
+
+#define AR7_PARTS 4
+#define ROOT_OFFSET 0xe0000
+
+#define LOADER_MAGIC1 le32_to_cpu(0xfeedfa42)
+#define LOADER_MAGIC2 le32_to_cpu(0xfeed1281)
+
+struct ar7_bin_rec {
+ unsigned int checksum;
+ unsigned int length;
+ unsigned int address;
+};
+
+static struct mtd_partition ar7_parts[AR7_PARTS];
+
+static int create_mtd_partitions(struct mtd_info *master,
+ struct mtd_partition **pparts,
+ unsigned long origin)
+{
+ struct ar7_bin_rec header;
+ unsigned int offset, len;
+ unsigned int pre_size = master->erasesize, post_size = 0;
+ unsigned int root_offset = ROOT_OFFSET;
+
+ int retries = 10;
+
+ ar7_parts[0].name = "loader";
+ ar7_parts[0].offset = 0;
+ ar7_parts[0].size = master->erasesize;
+ ar7_parts[0].mask_flags = MTD_WRITEABLE;
+
+ ar7_parts[1].name = "config";
+ ar7_parts[1].offset = 0;
+ ar7_parts[1].size = master->erasesize;
+ ar7_parts[1].mask_flags = 0;
+
+ do { /* Try 10 blocks starting from master->erasesize */
+ offset = pre_size;
+ master->read(master, offset,
+ sizeof(header), &len, (u8 *)&header);
+ if (!strncmp((char *)&header, "TIENV0.8", 8))
+ ar7_parts[1].offset = pre_size;
+ if (header.checksum == LOADER_MAGIC1)
+ break;
+ if (header.checksum == LOADER_MAGIC2)
+ break;
+ pre_size += master->erasesize;
+ } while (retries--);
+
+ pre_size = offset;
+
+ if (!ar7_parts[1].offset) {
+ ar7_parts[1].offset = master->size - master->erasesize;
+ post_size = master->erasesize;
+ }
+
+ switch (header.checksum) {
+ case LOADER_MAGIC1:
+ while (header.length) {
+ offset += sizeof(header) + header.length;
+ master->read(master, offset, sizeof(header),
+ &len, (u8 *)&header);
+ }
+ root_offset = offset + sizeof(header) + 4;
+ break;
+ case LOADER_MAGIC2:
+ while (header.length) {
+ offset += sizeof(header) + header.length;
+ master->read(master, offset, sizeof(header),
+ &len, (u8 *)&header);
+ }
+ root_offset = offset + sizeof(header) + 4 + 0xff;
+ root_offset &= ~(u32)0xff;
+ break;
+ default:
+ printk(KERN_WARNING "Unknown magic: %08x\n", header.checksum);
+ break;
+ }
+
+ master->read(master, root_offset,
+ sizeof(header), &len, (u8 *)&header);
+ if (header.checksum != SQUASHFS_MAGIC) {
+ root_offset += master->erasesize - 1;
+ root_offset &= ~(master->erasesize - 1);
+ }
+
+ ar7_parts[2].name = "linux";
+ ar7_parts[2].offset = pre_size;
+ ar7_parts[2].size = master->size - pre_size - post_size;
+ ar7_parts[2].mask_flags = 0;
+
+ ar7_parts[3].name = "rootfs";
+ ar7_parts[3].offset = root_offset;
+ ar7_parts[3].size = master->size - root_offset - post_size;
+ ar7_parts[3].mask_flags = 0;
+
+ *pparts = ar7_parts;
+ return AR7_PARTS;
+}
+
+static struct mtd_part_parser ar7_parser = {
+ .owner = THIS_MODULE,
+ .parse_fn = create_mtd_partitions,
+ .name = "ar7part",
+};
+
+static int __init ar7_parser_init(void)
+{
+ return register_mtd_parser(&ar7_parser);
+}
+
+module_init(ar7_parser_init);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR( "Felix Fietkau <nbd@openwrt.org>, "
+ "Eugene Konev <ejka@openwrt.org>");
+MODULE_DESCRIPTION("MTD partitioning for TI AR7");
^ permalink raw reply related
* [PATCH][MIPS][0/6]: AR7 refresh
From: Matteo Croce @ 2007-12-27 18:19 UTC (permalink / raw)
To: linux-mips; +Cc: nico, nbd, florian, openwrt-devel, Andrew Morton
Here are the AR7 patches refreshed against latest source
^ permalink raw reply
* Re: [MIPS] 64-bit Sibyte kernels need DMA32.
From: Atsushi Nemoto @ 2007-12-27 16:43 UTC (permalink / raw)
To: linux-mips; +Cc: ralf
In-Reply-To: <S20038938AbXKZMRu/20071126121750Z+44508@ftp.linux-mips.org>
On Mon, 26 Nov 2007 12:17:46 +0000, linux-mips@linux-mips.org wrote:
> Author: Ralf Baechle <ralf@linux-mips.org> Sat Nov 3 02:05:43 2007 +0000
> Commit: 75c0de3513644f9868a14f74b0c4dfec1eb4ffd5
> Gitweb: http://www.linux-mips.org/g/linux/75c0de35
> Branch: master
>
> Sibyte SOCs only have 32-bit PCI. Due to the sparse use of the address
> space only the first 1GB of memory is mapped at physical addresses
> below 1GB. If a system has more than 1GB of memory 32-bit DMA will
> not be able to reach all of it.
>
> For now this patch is good enough to keep Sibyte users happy but it seems
> eventually something like swiotlb will be needed for Sibyte.
This commit breaks platforms which have real prom_free_prom_memory().
You can reproduce the problem with this patch.
diff --git a/arch/mips/qemu/q-mem.c b/arch/mips/qemu/q-mem.c
index dae39b5..84cbee2 100644
--- a/arch/mips/qemu/q-mem.c
+++ b/arch/mips/qemu/q-mem.c
@@ -1,5 +1,9 @@
#include <linux/init.h>
+#include <asm/bootinfo.h>
+#include <asm/sections.h>
+#include <asm/page.h>
void __init prom_free_prom_memory(void)
{
+ free_init_pages("prom memory", PAGE_SIZE, __pa_symbol(&_text));
}
With this patch, qemu kernel crashes on boot as this:
Bad page state in process 'swapper'
page:81000020 flags:0x00000000 mapping:00000000 mapcount:1 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Call Trace:
[<8001691c>] dump_stack+0x8/0x34
[<8005a758>] bad_page+0x6c/0xa4
[<8005af7c>] free_hot_cold_page+0x98/0x1d4
[<80019e44>] free_init_pages+0x94/0xf8
[<80164b3c>] free_initmem+0x10/0x40
[<80010428>] init_post+0x10/0xe8
[<801b988c>] kernel_init+0x2f8/0x328
[<80013220>] kernel_thread_helper+0x10/0x18
If I reverted the commit, this crash does not happen. How I can fix this?
---
Atsushi Nemoto
^ permalink raw reply related
* Re: MC Bus Error / tcp_ack_saw_tstamp Was: IP28 Installation Success report
From: Thomas Bogendoerfer @ 2007-12-27 15:10 UTC (permalink / raw)
To: Florian Lohoff; +Cc: linux-mips
In-Reply-To: <20071227090401.GA3393@paradigm.rfc822.org>
On Thu, Dec 27, 2007 at 10:04:01AM +0100, Florian Lohoff wrote:
> On Sun, Dec 23, 2007 at 08:54:42PM +0100, Florian Lohoff wrote:
> > I thought an installation success report is sometimes nice to have:
>
> Linux ip28 2.6.24-rc5-g8b3ba06b-dirty #21 Tue Dec 18 12:48:29 CET 2007 mips64 GNU/Linux
>
> After ~10 days uptime and multiple gcc builds. Logging in via ssh
> and issueing an "ls" in the build directory:
>
> MC Bus Error
looks like
/* GIO errors are fatal */
if (gio_err_stat & GIO_ERRMASK)
goto mips_be_fatal;
in ip28_be_interrupt is too strict. Load speculations to addresses
in the GIO address range where no device responds, will probably always
produce bus timeout. It might be worth to use
check_addr_in_insn(cpu_err_addr, regs)) before killing the machine.
So
if ((gio_err_stat & GIO_ERRMASK) &&
check_addr_in_insn(gio_err_addr, regs))
goto mips_be_fatal;
might be better.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: MC Bus Error / tcp_ack_saw_tstamp Was: IP28 Installation Success report
From: Ralf Baechle @ 2007-12-27 13:28 UTC (permalink / raw)
To: Florian Lohoff; +Cc: linux-mips
In-Reply-To: <20071227090401.GA3393@paradigm.rfc822.org>
On Thu, Dec 27, 2007 at 10:04:01AM +0100, Florian Lohoff wrote:
> On Sun, Dec 23, 2007 at 08:54:42PM +0100, Florian Lohoff wrote:
> > I thought an installation success report is sometimes nice to have:
>
> Linux ip28 2.6.24-rc5-g8b3ba06b-dirty #21 Tue Dec 18 12:48:29 CET 2007 mips64 GNU/Linux
>
> After ~10 days uptime and multiple gcc builds. Logging in via ssh
> and issueing an "ls" in the build directory:
>
> MC Bus Error
> GIO error 0x401:<TIME > @ 0xc8487e50
> CP0: config 6c11ae03, MC: cpuctrl0/1: 3d802412/3d802412, giopar: c623
> MC: cpu/gio_memacc: 31453436/34336, memcfg0/1: 67206728/00005fff
> Cache tags @ c8487e50:
> D: 0: 20000000 0c848708, 1: 20000000 028963ce (VA[13:5] 3e40)
> S: 0: 80000000 0c8481a3, 1: 80000000 02e809df (PA[18:7] 07e00)
> Interrupt, epc == a8000000202b6760, ra == a8000000202b8d00
> Oops[#1]:
> Cpu 0
> $ 0 : 0000000000000000 ffffffff9004cce0 0000000000000001 0000000000000003
> $ 4 : a800000028963900 0000000000000004 0000000000000001 0000000000000000
> $ 8 : 00000000203f0000 0000000000000020 00000000204a0000 00000000204a0000
> $12 : 0000000000000010 a8000000201dca50 0000000020490000 00000000204a0000
> $16 : 0000000000000001 a800000028963900 a80000002041baa8 a800000020ecc6b8
> $20 : 0000000000000000 00000000204a0000 ffffffff987bd2d4 0000000000000000
> $24 : 0000000020420000 a80000002019b000
> $28 : a800000028b94000 a800000028b97930 0000000000000004 a8000000202b8d00
> Hi : 0000000000000000
> Lo : 0000000000000a20
> epc : a8000000202b6760 tcp_ack_saw_tstamp+0x0/0x78 Not tainted
> ra : a8000000202b8d00 tcp_ack+0x880/0x2250
> Status: 9004cce3 KX SX UX KERNEL EXL IE
> Cause : 00004000
> PrId : 00000925 (R10000)
> Modules linked in:
> Process ls (pid: 308, threadinfo=a800000028b94000, task=a80000002fc73980)
> Stack : 0000000000000002 0000000000000002 0000000000000002 a800000020103cc8
> 0000000000000402 000000000a340059 0000000000000001 0000000000000000
> 0000000000000001 0000000000000000 0000000000000000 0000000000000000
> 0000000000000001 0000000000000000 ffffffff987bd2d4 0000000000000001
> 0000000000000000 a8000000289639b8 a800000028963900 a800000020dc1a34
> a80000002bb9d580 a80000002bb9d5b8 0000000000000020 00000000204a0000
> a800000020420000 a8000000204a0000 a8000000204a0000 a8000000202be854
> a800000020dc1a34 a80000002bb9d580 a800000028963900 a800000020dc1a20
> a8000000204a0000 00000000204a0000 a800000020420000 a8000000202c6a24
> a8000000204a0000 a800000020273254 a800000020dc1a34 a800000028963900
> ...
> Call Trace:
> [<a8000000202b6760>] tcp_ack_saw_tstamp+0x0/0x78
> [<a8000000202b8d00>] tcp_ack+0x880/0x2250
> [<a8000000202be854>] tcp_rcv_established+0x574/0x8e0
> [<a8000000202c6a24>] tcp_v4_do_rcv+0x114/0x488
> [<a8000000202c9d38>] tcp_v4_rcv+0xbc0/0xbf8
> [<a8000000202a3978>] ip_local_deliver_finish+0x1a0/0x358
> [<a8000000202a348c>] ip_rcv_finish+0x13c/0x488
> [<a800000020278330>] netif_receive_skb+0x358/0x4f8
> [<a80000002027bf3c>] process_backlog+0xfc/0x1f8
> [<a80000002027b9d4>] net_rx_action+0x18c/0x258
> [<a80000002003c31c>] __do_softirq+0xbc/0x178
> [<a80000002003c460>] do_softirq+0x88/0x90
> [<a800000020007ff4>] ret_from_irq+0x0/0x4
> [<a800000020031148>] __wake_up+0x10/0x50
> [<a8000000201fb61c>] tty_write+0x204/0x260
> [<a80000002009ef54>] vfs_write+0xec/0x178
> [<a80000002009f600>] sys_write+0x50/0xa0
> [<a80000002001c968>] handle_sys+0x128/0x144
>
>
> Code: 03e00008 67bd0010 00000000 <3c02a800> 64420000 67bdfff0 3c0c203f 0002103c ffb00000
> Kernel panic - not syncing: Fatal exception in interrupt
Seems to me that this trace is not useful at all. And that will be
frequently the problem with IP28 bugs, they're extremly hard to trace so
code reviews may be among the most efficient methods to fix these ...
Ralf
^ permalink raw reply
* Re: [PATCH] Alchemy: fix modpost warning
From: Ralf Baechle @ 2007-12-27 13:08 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-mips
In-Reply-To: <200712252100.47365.sshtylyov@ru.mvista.com>
On Tue, Dec 25, 2007 at 09:00:45PM +0300, Sergei Shtylyov wrote:
> WARNING: vmlinux.o(.text+0x1ca608): Section mismatch: reference to .init.text:
> add_wired_entry (between 'config_access' and 'config_read')
>
> by refactoring the code calling add_wired_entry() from config_access() to
> a separate function which is called from aau1x_pci_setup(). While at it:
>
> - make some unnecassarily global variables 'static';
>
> - fix the letter case, whitespace, etc. in the comments...
>
> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Applied. Thanks,
Ralf
^ permalink raw reply
* MC Bus Error / tcp_ack_saw_tstamp Was: IP28 Installation Success report
From: Florian Lohoff @ 2007-12-27 9:04 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 3742 bytes --]
On Sun, Dec 23, 2007 at 08:54:42PM +0100, Florian Lohoff wrote:
> I thought an installation success report is sometimes nice to have:
Linux ip28 2.6.24-rc5-g8b3ba06b-dirty #21 Tue Dec 18 12:48:29 CET 2007 mips64 GNU/Linux
After ~10 days uptime and multiple gcc builds. Logging in via ssh
and issueing an "ls" in the build directory:
MC Bus Error
GIO error 0x401:<TIME > @ 0xc8487e50
CP0: config 6c11ae03, MC: cpuctrl0/1: 3d802412/3d802412, giopar: c623
MC: cpu/gio_memacc: 31453436/34336, memcfg0/1: 67206728/00005fff
Cache tags @ c8487e50:
D: 0: 20000000 0c848708, 1: 20000000 028963ce (VA[13:5] 3e40)
S: 0: 80000000 0c8481a3, 1: 80000000 02e809df (PA[18:7] 07e00)
Interrupt, epc == a8000000202b6760, ra == a8000000202b8d00
Oops[#1]:
Cpu 0
$ 0 : 0000000000000000 ffffffff9004cce0 0000000000000001 0000000000000003
$ 4 : a800000028963900 0000000000000004 0000000000000001 0000000000000000
$ 8 : 00000000203f0000 0000000000000020 00000000204a0000 00000000204a0000
$12 : 0000000000000010 a8000000201dca50 0000000020490000 00000000204a0000
$16 : 0000000000000001 a800000028963900 a80000002041baa8 a800000020ecc6b8
$20 : 0000000000000000 00000000204a0000 ffffffff987bd2d4 0000000000000000
$24 : 0000000020420000 a80000002019b000
$28 : a800000028b94000 a800000028b97930 0000000000000004 a8000000202b8d00
Hi : 0000000000000000
Lo : 0000000000000a20
epc : a8000000202b6760 tcp_ack_saw_tstamp+0x0/0x78 Not tainted
ra : a8000000202b8d00 tcp_ack+0x880/0x2250
Status: 9004cce3 KX SX UX KERNEL EXL IE
Cause : 00004000
PrId : 00000925 (R10000)
Modules linked in:
Process ls (pid: 308, threadinfo=a800000028b94000, task=a80000002fc73980)
Stack : 0000000000000002 0000000000000002 0000000000000002 a800000020103cc8
0000000000000402 000000000a340059 0000000000000001 0000000000000000
0000000000000001 0000000000000000 0000000000000000 0000000000000000
0000000000000001 0000000000000000 ffffffff987bd2d4 0000000000000001
0000000000000000 a8000000289639b8 a800000028963900 a800000020dc1a34
a80000002bb9d580 a80000002bb9d5b8 0000000000000020 00000000204a0000
a800000020420000 a8000000204a0000 a8000000204a0000 a8000000202be854
a800000020dc1a34 a80000002bb9d580 a800000028963900 a800000020dc1a20
a8000000204a0000 00000000204a0000 a800000020420000 a8000000202c6a24
a8000000204a0000 a800000020273254 a800000020dc1a34 a800000028963900
...
Call Trace:
[<a8000000202b6760>] tcp_ack_saw_tstamp+0x0/0x78
[<a8000000202b8d00>] tcp_ack+0x880/0x2250
[<a8000000202be854>] tcp_rcv_established+0x574/0x8e0
[<a8000000202c6a24>] tcp_v4_do_rcv+0x114/0x488
[<a8000000202c9d38>] tcp_v4_rcv+0xbc0/0xbf8
[<a8000000202a3978>] ip_local_deliver_finish+0x1a0/0x358
[<a8000000202a348c>] ip_rcv_finish+0x13c/0x488
[<a800000020278330>] netif_receive_skb+0x358/0x4f8
[<a80000002027bf3c>] process_backlog+0xfc/0x1f8
[<a80000002027b9d4>] net_rx_action+0x18c/0x258
[<a80000002003c31c>] __do_softirq+0xbc/0x178
[<a80000002003c460>] do_softirq+0x88/0x90
[<a800000020007ff4>] ret_from_irq+0x0/0x4
[<a800000020031148>] __wake_up+0x10/0x50
[<a8000000201fb61c>] tty_write+0x204/0x260
[<a80000002009ef54>] vfs_write+0xec/0x178
[<a80000002009f600>] sys_write+0x50/0xa0
[<a80000002001c968>] handle_sys+0x128/0x144
Code: 03e00008 67bd0010 00000000 <3c02a800> 64420000 67bdfff0 3c0c203f 0002103c ffb00000
Kernel panic - not syncing: Fatal exception in interrupt
--
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: question about oprofile support
From: Anirban Sinha @ 2007-12-27 5:44 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C55DDD32@exchange.ZeugmaSystems.local>
If I am not too wrong, I think this is what the picture is like as far as the mips support for oprfile goes:
Oprofile 0.9.2 release version supports mips architecture partially. Their release notes says:
"Support for MIPS 5K, 20K, 25K, and 34K added."
However, support for R10000, R12000, R12000, RM7000, RM9000, SB1 / SB1A, VR5432, VR5500 processors are only available through the CVS checkout:
"The R10000, R12000, R12000, RM7000, RM9000, SB1 / SB1A, VR5432, VR5500 processors are supported by the CVS version of the userspace tools; support for further is in the queue."
If I am wrong in understanding this, please correct me.
Cheers,
Ani
From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Anirban Sinha
Sent: Wednesday, December 26, 2007 6:29 PM
To: linux-mips@linux-mips.org
Subject: question about oprofile support
Hi:
Linux-mips.org states: (http://www.linux-mips.org/wiki/Oprofile)
"Oprofile support is available at the time of this writing only in the Sourceforge Oprofile CVS repository; released versions are either lacking support for MIPS or are unusable due to bugs"
I am wondering if this is still true. If we want to have oprofile support on mips hardware, do we have to checkout the HEAD revision from oprofile cvs repository or is it already available from the standard 0.9.3 release?
Thanks in advance to anyone who can throw any lights on this.
Cheers,
Ani
^ permalink raw reply
* RE: question about oprofile support
From: Anirban Sinha @ 2007-12-27 5:44 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C55DDD32@exchange.ZeugmaSystems.local>
If I am not too wrong, I think this is what the picture is like as far as the mips support for oprfile goes:
Oprofile 0.9.2 release version supports mips architecture partially. Their release notes says:
"Support for MIPS 5K, 20K, 25K, and 34K added."
However, support for R10000, R12000, R12000, RM7000, RM9000, SB1 / SB1A, VR5432, VR5500 processors are only available through the CVS checkout:
"The R10000, R12000, R12000, RM7000, RM9000, SB1 / SB1A, VR5432, VR5500 processors are supported by the CVS version of the userspace tools; support for further is in the queue."
If I am wrong in understanding this, please correct me.
Cheers,
Ani
From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Anirban Sinha
Sent: Wednesday, December 26, 2007 6:29 PM
To: linux-mips@linux-mips.org
Subject: question about oprofile support
Hi:
Linux-mips.org states: (http://www.linux-mips.org/wiki/Oprofile)
"Oprofile support is available at the time of this writing only in the Sourceforge Oprofile CVS repository; released versions are either lacking support for MIPS or are unusable due to bugs"
I am wondering if this is still true. If we want to have oprofile support on mips hardware, do we have to checkout the HEAD revision from oprofile cvs repository or is it already available from the standard 0.9.3 release?
Thanks in advance to anyone who can throw any lights on this.
Cheers,
Ani
^ permalink raw reply
* question about oprofile support
From: Anirban Sinha @ 2007-12-27 2:28 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
Hi:
Linux-mips.org states: (http://www.linux-mips.org/wiki/Oprofile)
"Oprofile support is available at the time of this writing only in the
Sourceforge Oprofile CVS repository; released versions are either
lacking support for MIPS or are unusable due to bugs"
I am wondering if this is still true. If we want to have oprofile
support on mips hardware, do we have to checkout the HEAD revision from
oprofile cvs repository or is it already available from the standard
0.9.3 release?
Thanks in advance to anyone who can throw any lights on this.
Cheers,
Ani
[-- Attachment #2: Type: text/html, Size: 2771 bytes --]
^ permalink raw reply
* question about oprofile support
From: Anirban Sinha @ 2007-12-27 2:28 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
Hi:
Linux-mips.org states: (http://www.linux-mips.org/wiki/Oprofile)
"Oprofile support is available at the time of this writing only in the
Sourceforge Oprofile CVS repository; released versions are either
lacking support for MIPS or are unusable due to bugs"
I am wondering if this is still true. If we want to have oprofile
support on mips hardware, do we have to checkout the HEAD revision from
oprofile cvs repository or is it already available from the standard
0.9.3 release?
Thanks in advance to anyone who can throw any lights on this.
Cheers,
Ani
[-- Attachment #2: Type: text/html, Size: 2771 bytes --]
^ permalink raw reply
* admulator: a simulator of adm5120
From: Zhou YaJin @ 2007-12-26 6:38 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]
Hi everyone, I am glad to release admulator-a simulator of adm5120.
Currently it can run linux 2.6 kernel and openwrt.
website:
http://admulator.sf.net
If you have any question about admulator, please contact me. Thanks :)
Admulator is a full system simulator of adm5120 soc. It simulates a mips32
cpu core and other devices. Currently it can run linux 2.6 kernel and
openwrt for adm5120. The entire source code of admulator is distributed
under GPL.
Some of the features include:
- full system simulation. the ability to run unmodified linux kernel
and openwrt.
- mips32 cpu core without fpu support
- 4Mbytes flash simulation(including CFI Interface)
- duart simulation
- gdb interface
Missing features :
- no switch core simulation in current release
- no binary translation
[-- Attachment #2: Type: text/html, Size: 950 bytes --]
^ permalink raw reply
* [PATCH] Alchemy: fix modpost warning
From: Sergei Shtylyov @ 2007-12-25 18:00 UTC (permalink / raw)
To: ralf; +Cc: linux-mips
WARNING: vmlinux.o(.text+0x1ca608): Section mismatch: reference to .init.text:
add_wired_entry (between 'config_access' and 'config_read')
by refactoring the code calling add_wired_entry() from config_access() to
a separate function which is called from aau1x_pci_setup(). While at it:
- make some unnecassarily global variables 'static';
- fix the letter case, whitespace, etc. in the comments...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
arch/mips/au1000/common/pci.c | 8 ++++--
arch/mips/pci/ops-au1000.c | 53 ++++++++++++++++++++----------------------
2 files changed, 32 insertions(+), 29 deletions(-)
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
@@ -1,8 +1,8 @@
/*
* BRIEF MODULE DESCRIPTION
- * Alchemy/AMD Au1x00 pci support.
+ * Alchemy/AMD Au1x00 PCI support.
*
- * Copyright 2001,2002,2003 MontaVista Software Inc.
+ * Copyright 2001-2003, 2007 MontaVista Software Inc.
* Author: MontaVista Software, Inc.
* ppopov@mvista.com or source@mvista.com
*
@@ -66,6 +66,8 @@ static unsigned long virt_io_addr;
static int __init au1x_pci_setup(void)
{
+ extern void au1x_pci_cfg_init(void);
+
#if defined(CONFIG_SOC_AU1500) || defined(CONFIG_SOC_AU1550)
virt_io_addr = (unsigned long)ioremap(Au1500_PCI_IO_START,
Au1500_PCI_IO_END - Au1500_PCI_IO_START + 1);
@@ -94,6 +96,8 @@ static int __init au1x_pci_setup(void)
set_io_port_base(virt_io_addr);
#endif
+ au1x_pci_cfg_init();
+
register_pci_controller(&au1x_controller);
return 0;
}
Index: linux-2.6/arch/mips/pci/ops-au1000.c
===================================================================
--- linux-2.6.orig/arch/mips/pci/ops-au1000.c
+++ linux-2.6/arch/mips/pci/ops-au1000.c
@@ -1,8 +1,8 @@
/*
* BRIEF MODULE DESCRIPTION
- * Alchemy/AMD Au1x00 pci support.
+ * Alchemy/AMD Au1x00 PCI support.
*
- * Copyright 2001,2002,2003 MontaVista Software Inc.
+ * Copyright 2001-2003, 2007 MontaVista Software Inc.
* Author: MontaVista Software, Inc.
* ppopov@mvista.com or source@mvista.com
*
@@ -69,10 +69,27 @@ void mod_wired_entry(int entry, unsigned
write_c0_pagemask(old_pagemask);
}
-struct vm_struct *pci_cfg_vm;
+static struct vm_struct *pci_cfg_vm;
static int pci_cfg_wired_entry;
-static int first_cfg = 1;
-unsigned long last_entryLo0, last_entryLo1;
+static unsigned long last_entryLo0, last_entryLo1;
+
+/*
+ * We can't ioremap the entire pci config space because it's too large.
+ * Nor can we call ioremap dynamically because some device drivers use
+ * the PCI config routines from within interrupt handlers and that
+ * becomes a problem in get_vm_area(). We use one wired TLB to handle
+ * all config accesses for all busses.
+ */
+void __init au1x_pci_cfg_init(void)
+{
+ /* Reserve a wired entry for PCI config accesses */
+ pci_cfg_vm = get_vm_area(0x2000, VM_IOREMAP);
+ if (!pci_cfg_vm)
+ panic(KERN_ERR "PCI unable to get vm area\n");
+ pci_cfg_wired_entry = read_c0_wired();
+ add_wired_entry(0, 0, (unsigned long)pci_cfg_vm->addr, PM_4K);
+ last_entryLo0 = last_entryLo1 = 0xffffffff;
+}
static int config_access(unsigned char access_type, struct pci_bus *bus,
unsigned int dev_fn, unsigned char where,
@@ -97,27 +114,6 @@ static int config_access(unsigned char a
Au1500_PCI_STATCMD);
au_sync_udelay(1);
- /*
- * We can't ioremap the entire pci config space because it's
- * too large. Nor can we call ioremap dynamically because some
- * device drivers use the pci config routines from within
- * interrupt handlers and that becomes a problem in get_vm_area().
- * We use one wired tlb to handle all config accesses for all
- * busses. To improve performance, if the current device
- * is the same as the last device accessed, we don't touch the
- * tlb.
- */
- if (first_cfg) {
- /* reserve a wired entry for pci config accesses */
- first_cfg = 0;
- pci_cfg_vm = get_vm_area(0x2000, VM_IOREMAP);
- if (!pci_cfg_vm)
- panic(KERN_ERR "PCI unable to get vm area\n");
- pci_cfg_wired_entry = read_c0_wired();
- add_wired_entry(0, 0, (unsigned long)pci_cfg_vm->addr, PM_4K);
- last_entryLo0 = last_entryLo1 = 0xffffffff;
- }
-
/* Allow board vendors to implement their own off-chip idsel.
* If it doesn't succeed, may as well bail out at this point.
*/
@@ -144,9 +140,12 @@ static int config_access(unsigned char a
/* page boundary */
cfg_base = cfg_base & PAGE_MASK;
+ /*
+ * To improve performance, if the current device is the same as
+ * the last device accessed, we don't touch the TLB.
+ */
entryLo0 = (6 << 26) | (cfg_base >> 6) | (2 << 3) | 7;
entryLo1 = (6 << 26) | (cfg_base >> 6) | (0x1000 >> 6) | (2 << 3) | 7;
-
if ((entryLo0 != last_entryLo0) || (entryLo1 != last_entryLo1)) {
mod_wired_entry(pci_cfg_wired_entry, entryLo0, entryLo1,
(unsigned long)pci_cfg_vm->addr, PM_4K);
^ permalink raw reply
* Re: [MIPS] MEM_SDREFCFG is not defined for Alchemy DB1550 (compile fail)
From: Alon Bar-Lev @ 2007-12-25 17:35 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-mips, LKML, Ralf Baechle
In-Reply-To: <47713B7A.9050102@ru.mvista.com>
On 12/25/07, Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:
> > So suspend modes on these boards are not supported?
> > Only "Always On" configuration is supported?
>
> Sleep mode is supported according to the code. But as I've said PM bits
> haven't been maintained -- probably since the submission.
Thanks!
Will it be maintained? Are there any plans?
Is there, a missing features list (TODO)?
Or this is completely unsupported board?
Best Regards,
Alon Bar-Lev.
^ permalink raw reply
* Re: [MIPS] MEM_SDREFCFG is not defined for Alchemy DB1550 (compile fail)
From: Sergei Shtylyov @ 2007-12-25 17:18 UTC (permalink / raw)
To: Alon Bar-Lev; +Cc: linux-mips, LKML, Ralf Baechle
In-Reply-To: <9e0cf0bf0712250904t213d623bp977db54b6be5e3e@mail.gmail.com>
Alon Bar-Lev wrote:
>> PM code is generally broken and unmaintained, so no wonder. I don't
>>remember if anyone has fixed CPU context restoration code (it uses a "skewed"
>>stack frame).
> So suspend modes on these boards are not supported?
> Only "Always On" configuration is supported?
Sleep mode is supported according to the code. But as I've said PM bits
haven't been maintained -- probably since the submission.
> Best Regards,
> Alon Bar-Lev.
WBR, Sergei
^ permalink raw reply
* Re: [MIPS] MEM_SDREFCFG is not defined for Alchemy DB1550 (compile fail)
From: Alon Bar-Lev @ 2007-12-25 17:04 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-mips, LKML, Ralf Baechle
In-Reply-To: <4770DE51.5000205@ru.mvista.com>
Thank you for your reply!
On 12/25/07, Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:
> PM code is generally broken and unmaintained, so no wonder. I don't
> remember if anyone has fixed CPU context restoration code (it uses a "skewed"
> stack frame).
So suspend modes on these boards are not supported?
Only "Always On" configuration is supported?
Or there is another method to preserve power?
Best Regards,
Alon Bar-Lev.
^ permalink raw reply
* Re: [MIPS] MEM_SDREFCFG is not defined for Alchemy DB1550 (compile fail)
From: Ralf Baechle @ 2007-12-25 14:32 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Alon Bar-Lev, linux-mips, LKML
In-Reply-To: <4770DE51.5000205@ru.mvista.com>
On Tue, Dec 25, 2007 at 01:41:21PM +0300, Sergei Shtylyov wrote:
>> When I have:
>> CONFIG_MIPS_DB1550
>> CONFIG_SOC_AU1550
>> CONFIG_SOC_AU1X00
>> CONFIG_PM
>
>> MEM_SDREFCFG is used at:
>> arch/mips/au1000/common/power.c::pm_do_freq()
>
> PM code is generally broken and unmaintained, so no wonder. I don't
> remember if anyone has fixed CPU context restoration code (it uses a
> "skewed" stack frame).
>
>> While the MEM_SDREFCFG constant is declare only for CONFIG_SOC_AU1000,
>> CONFIG_SOC_AU1500, CONFIG_SOC_AU1100 at:
>> include/asm-mips/mach-au1x00/au1000.h
>
>> Maybe MEM_SDREFCFG should be defined for CONFIG_SOC_AU1X00?
>
> I've just looked into the Au1550 datasheet and indeed it doesn't have
> such register; its SDDRAM controller is not compatible with older SoCs.
>
>> Or there should be #ifdef for its usage in power.c?
>
> Looks like you'll have to invent something... ;-)
>
>> Best Regards,
>> Alon Bar-Lev.
So I guess it's time to mark the whole PM stuff as BROKEN?
Ralf
^ permalink raw reply
* Re: [MIPS] MEM_SDREFCFG is not defined for Alchemy DB1550 (compile fail)
From: Sergei Shtylyov @ 2007-12-25 10:41 UTC (permalink / raw)
To: Alon Bar-Lev; +Cc: linux-mips, LKML
In-Reply-To: <9e0cf0bf0712230733o3dfd54fcp4962ebf3f84cdff@mail.gmail.com>
Hello.
Alon Bar-Lev wrote:
> When I have:
> CONFIG_MIPS_DB1550
> CONFIG_SOC_AU1550
> CONFIG_SOC_AU1X00
> CONFIG_PM
> MEM_SDREFCFG is used at:
> arch/mips/au1000/common/power.c::pm_do_freq()
PM code is generally broken and unmaintained, so no wonder. I don't
remember if anyone has fixed CPU context restoration code (it uses a "skewed"
stack frame).
> While the MEM_SDREFCFG constant is declare only for CONFIG_SOC_AU1000,
> CONFIG_SOC_AU1500, CONFIG_SOC_AU1100 at:
> include/asm-mips/mach-au1x00/au1000.h
> Maybe MEM_SDREFCFG should be defined for CONFIG_SOC_AU1X00?
I've just looked into the Au1550 datasheet and indeed it doesn't have such
register; its SDDRAM controller is not compatible with older SoCs.
> Or there should be #ifdef for its usage in power.c?
Looks like you'll have to invent something... ;-)
> Best Regards,
> Alon Bar-Lev.
WBR, Sergei
^ permalink raw reply
* Re: [UPDATED PATCH] IP28 support
From: post @ 2007-12-24 0:39 UTC (permalink / raw)
To: Richard Sandiford; +Cc: Ralf Baechle, Thomas Bogendoerfer, Kumba, linux-mips
In-Reply-To: <871w9d7nsf.fsf@firetop.home>
On Sun, 23 Dec 2007, Richard Sandiford wrote:
> Date: Sun, 23 Dec 2007 09:39:28 +0000
> From: Richard Sandiford <rsandifo@nildram.co.uk>
> To: peter fuerst <post@pfrst.de>
> Cc: Ralf Baechle <ralf@linux-mips.org>,
> Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
> Kumba <kumba@gentoo.org>, linux-mips@linux-mips.org
> Subject: Re: [UPDATED PATCH] IP28 support
>
> ...
> Ah, OK. That's what I was missing, thanks. (I suspect you and Ralf
> have explained that to me before, but it hadn't sunk in. Sorry!)
Missed to explain that in time... Sorry!
> ...
kind regards
peter
^ permalink raw reply
* IP28 Installation Success report Was: [UPDATED PATCH] IP28 support
From: Florian Lohoff @ 2007-12-23 19:54 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <20071202120032.2A477C2EB6@solo.franken.de>
[-- Attachment #1: Type: text/plain, Size: 1920 bytes --]
On Sun, Dec 02, 2007 at 01:00:32PM +0100, Thomas Bogendoerfer wrote:
> Add support for SGI IP28 machines (Indigo 2 with R10k CPUs)
> This work is mainly based on Peter Fuersts work.
I thought an installation success report is sometimes nice to have:
flo@ip28:~$ cat /proc/cpuinfo
system type : SGI Indigo2
processor : 0
cpu model : R10000 V2.5 FPU V0.0
BogoMIPS : 194.04
wait instruction : no
microsecond timers : yes
tlb_entries : 64
extra interrupt vector : no
hardware watchpoint : yes
ASEs implemented :
shadow register sets : 1
VCED exceptions : not available
VCEI exceptions : not available
flo@ip28:~$ uptime
19:49:15 up 4 days, 9:09, 2 users, load average: 0.00, 0.00, 0.00
flo@ip28:~$ uname -a
Linux ip28 2.6.24-rc5-g8b3ba06b-dirty #21 Tue Dec 18 12:48:29 CET 2007 mips64 GNU/Linux
flo@ip28:~$ cat /proc/interrupts
CPU0
0: 1 XT-PIC timer
2: 0 XT-PIC cascade
18: 0 MIPS local0 cascade
19: 0 MIPS local1 cascade
22: 1 MIPS Bus Error
23: 94680570 MIPS timer
25: 3863916 IP22 local 0 SGI WD93
26: 7 IP22 local 0 SGI WD93
27: 677582 IP22 local 0 SGI Seeq8003
31: 0 IP22 local 0 mapable0 cascade
33: 0 IP22 local 1 Front Panel
43: 1 IP22 local 2 EISA
44: 5 IP22 local 2 i8042, i8042
45: 6462546 IP22 local 2 IP22-Zilog
ERR: 0
The maschine successfully compiled multiple gcc version and had no hickups
so far ...
Peter and Thomas did great work ....
Flo
--
Florian Lohoff flo@rfc822.org +49-171-2280134
security shall soon have neither - Benjamin Franklin
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [MIPS] MEM_SDREFCFG is not defined for Alchemy DB1550 (compile fail)
From: Alon Bar-Lev @ 2007-12-23 18:22 UTC (permalink / raw)
To: linux-mips, LKML, ppopov
In-Reply-To: <9e0cf0bf0712230733o3dfd54fcp4962ebf3f84cdff@mail.gmail.com>
Hello,
Forgot to write that I checked mips & linus gits, and the problem still exists.
Best Regards,
Alon Bar-Lev.
On 12/23/07, Alon Bar-Lev <alon.barlev@gmail.com> wrote:
> Hello,
>
> When I have:
> CONFIG_MIPS_DB1550
> CONFIG_SOC_AU1550
> CONFIG_SOC_AU1X00
> CONFIG_PM
>
> MEM_SDREFCFG is used at:
> arch/mips/au1000/common/power.c::pm_do_freq()
>
> While the MEM_SDREFCFG constant is declare only for CONFIG_SOC_AU1000,
> CONFIG_SOC_AU1500, CONFIG_SOC_AU1100 at:
> include/asm-mips/mach-au1x00/au1000.h
>
> Maybe MEM_SDREFCFG should be defined for CONFIG_SOC_AU1X00?
> Or there should be #ifdef for its usage in power.c?
>
> Best Regards,
> Alon Bar-Lev.
>
^ permalink raw reply
* [MIPS] MEM_SDREFCFG is not defined for Alchemy DB1550 (compile fail)
From: Alon Bar-Lev @ 2007-12-23 15:33 UTC (permalink / raw)
To: linux-mips, LKML
Hello,
When I have:
CONFIG_MIPS_DB1550
CONFIG_SOC_AU1550
CONFIG_SOC_AU1X00
CONFIG_PM
MEM_SDREFCFG is used at:
arch/mips/au1000/common/power.c::pm_do_freq()
While the MEM_SDREFCFG constant is declare only for CONFIG_SOC_AU1000,
CONFIG_SOC_AU1500, CONFIG_SOC_AU1100 at:
include/asm-mips/mach-au1x00/au1000.h
Maybe MEM_SDREFCFG should be defined for CONFIG_SOC_AU1X00?
Or there should be #ifdef for its usage in power.c?
Best Regards,
Alon Bar-Lev.
^ permalink raw reply
* Re: [UPDATED PATCH] IP28 support
From: Richard Sandiford @ 2007-12-23 9:39 UTC (permalink / raw)
To: peter fuerst; +Cc: Ralf Baechle, Thomas Bogendoerfer, Kumba, linux-mips
In-Reply-To: <Pine.LNX.4.58.0712230242590.215@Indigo2.Peter>
peter fuerst <post@pfrst.de> writes:
>> compile-time base+offset addresses. And as I said, the compiler is
>> free to make up accesses that aren't in fact valid for cases where
>> the access isn't made. E.g. if you had a loop with a stride of 128,
>> the compiler could unroll the loop as many times as it likes. Some
>> of the unrolled iterations might access areas outside the stack frame.
>
> You mean, the compiler would generate $sp+const_int accesses here, whose
> validity is not known at compile-time - similar to foo() above ?
Right.
>> I think you're missing my point. If you access an I/O-mapped device
>> through KSEG2 or an uncached XKPHYS address, is it not also physically
>> possible (though clearly unwise) to access it through KSEG0 or a cached
>> XKPHYS address too? So can you guarantee that every const_int cached
>> address in a multi-platform kernel is not I/O-mapped on any of the r10k
>> platforms? Or can you guarantee that the compiler will not manufacture
>> such an address from an otherwise harmless address?
> Hmm, it's not quite clear, how it could be manufactured.
Similar to the above really, for combinations of suitably bizarre input
code and compiler behaviour. Again, the problem isn't that such a thing
is _likely_ to happen, just that it wouldn't be wrong for it to happen in
non-r10k situations (and thus not likely to be treated as a "wrong-code"
bug by gcc developers).
>> Again, the key thing
>> is to think about what the compiler can validly do on non-r10k platforms,
>> however silly it might seem, and then make sure the workarounds cope
>> with it.
>
> Do you think of accesses that essentially look like this ?
>
> if (machine_x)
> *uncached(const_addr) = val;
> else
> *cached(const_addr) = val;
Well, more generally, I was thinking of something like:
if (machine_x)
*cached(const_addr1) = ...;
else
...blah...
where const_addr1 might be harmful if !machine_x.
> Fortunately (at least? even?) on IP28 cached access (hence a block read
> request) to an I/O-device address is a non-issue. In this respect the
> hardware design seems to follow the recommendations from the R10000 manual
> (NACK from external agent?):
> - if such an access graduates (i.e. a "real" access), a bus-error will occur.
> - if not (i.e. mis-speculated), nothing happens.
Ah, OK. That's what I was missing, thanks. (I suspect you and Ralf
have explained that to me before, but it hadn't sunk in. Sorry!)
> However, i don't yet know, how O2 behaves, or, if there exists any other
> R10k-machine, which would need the software-workaround.
OK.
In that case, for the IP28 at least, I think the only issue with excluding
cachable const_int addresses is that the compiler might somehow conspire to
create an address that turns out to be, for some runs at least, an address
in a DMA buffer.
> Well, the option spec could be as listed above. With "store" as default
> for an empty option-string ("none" as default if the option isn't given
> at all).
Sounds good.
Thanks, it seems we have a plan ;)
Richard
^ permalink raw reply
* Re: [UPDATED PATCH] IP28 support
From: peter fuerst @ 2007-12-23 1:44 UTC (permalink / raw)
To: Richard Sandiford; +Cc: Ralf Baechle, Thomas Bogendoerfer, Kumba, linux-mips
On Wed, 12 Dec 2007, Richard Sandiford wrote:
> Date: Wed, 12 Dec 2007 18:09:31 +0000
> From: Richard Sandiford <rsandifo@nildram.co.uk>
> To: peter fuerst <pf@pfrst.de>
> Cc: Ralf Baechle <ralf@linux-mips.org>,
> Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
> Kumba <kumba@gentoo.org>, linux-mips@linux-mips.org
> Subject: Re: [UPDATED PATCH] IP28 support
>
> peter fuerst <pf@pfrst.de> writes:
> >> Ralf Baechle <ralf@linux-mips.org> writes:
> >> >> Then there's the language-lawyerly code I gave to Peter on gcc-patches@:
> >> >>
> >> >> void foo (int x)
> >> >> {
> >> >> int array[1];
> >> >> if (x)
> >> >> bar (array[0x1fff]);
> >> >> }
> >> >>
> >
> > A strange method to pass data... Of course, cooking up such an "ABI",
> > where local variables are accessed with a const offset that is not known at
> > compile-time to be valid, would subvert the test for $sp-based accesses...
>
> Well, as I said when I gave that example originally, it's unlikely that
> the example would be written in that form. But hide the constants and
> checks in configurable macros, and the general idea becomes a little
> more feasible.
>
> >> FWIW, my first cut at the option restrictions were based on what
> >> the patch exempts (and doesn't exempt). We could instead get gcc
> >> to only exempt accesses that it can prove are either to the current
> >> function's stack frame or to its stack arguments. I.e. rather than
> >> consider every $sp-based access to be safe, we'd instead do some
> >
> > "every $sp-based access" (set(mem(plus(sp)(const_int)))) is restricted
> > to local variables too, with the constant offset being either
> > - compiler-generated or
> > - deliberately put in the source (however including the above example)
>
> That's not literally true. SP+INT addresses can be used to access
> stack arguments too, and 4.x can optimise some varargs accesses to
"local variables" was meant to include (var-)argument-slots too, which are
allright, so far.
> compile-time base+offset addresses. And as I said, the compiler is
> free to make up accesses that aren't in fact valid for cases where
> the access isn't made. E.g. if you had a loop with a stride of 128,
> the compiler could unroll the loop as many times as it likes. Some
> of the unrolled iterations might access areas outside the stack frame.
You mean, the compiler would generate $sp+const_int accesses here, whose
validity is not known at compile-time - similar to foo() above ?
> (You would hope that the compiler would be intelligent enough to crop
> the iteration count in such cases, because the extra iterations should
> never be used in valid code. But that isn't the point. The compiler
> doesn't _need_ to crop the iteration count for correctness, and we're
> talking about something we _do_ need for correctness.)
>
> >> bounds checking on the value.
> > Fine, if that is possible.
>
> FWIW, the frame info is available in cfun->machine->frame at the time
> your code runs.
>
> >> (We could also use MEM_ATTRS to
> >> pick up cases where a stack variable is acceesed via something
> >> other than the stack or frame pointers, as happens for large frames.)
> >
> > Aren't these always accesses with non-constant offset, where a CB can't be
> > avoided, even if they are recognized as being actually relative to $sp ?
>
> The MEM_ATTRS I meant were MEM_EXPR + MEM_OFFSET, which only apply where
> there is a known constant offset.
>
> >> > In case of a hypothetic multi-platform kernel of which at least one needs
> >> > the R10000 workarounds, all code would be uniformly compiled with the
> >> > magic -mr10k-cache-barrier option and all source level workaround would
> >> > be enabled.
> >>
> >> Hmm. This probably shows I am misunderstanding the problem, but I was
> >> thinking about the IO-mapped case. I thought one of the problems was
> >> that if you had a cached speculative load or store to an access-sensitive
> >> IO-mapped address, the IO-mapped device might "see" that access even if it
> >> doesn't take place. Could you not have a situation where a KSEG0 or
> >> XKSEG0 access is access-sensitive on one machine and not another?
> >> The patch won't insert countermeasures before symbolic and constant
> >> addresses, because it believes all such addresses to be safe.
> >>
> >
> > The threat to IO-addresses comes from the addressing register in the speculated
> > mem-instruction (set(mem(plus(reg)...), containing one of the addresses as
> > "garbage".
> >
> > Symbolic addresses are well defined from link-time on, no matter what history
> > before the access. They either point (set(mem(plus(symbol_ref)...) to
> > - some variable in the cached area, what is harmless (unless DMA-related),
> > or to
> > - IO-devices, accessed uncached, i.e. non-speculative,
> > unless there is a programming-error ;)
> > The same holds for const_int used as address.
>
> I think you're missing my point. If you access an I/O-mapped device
> through KSEG2 or an uncached XKPHYS address, is it not also physically
> possible (though clearly unwise) to access it through KSEG0 or a cached
> XKPHYS address too? So can you guarantee that every const_int cached
> address in a multi-platform kernel is not I/O-mapped on any of the r10k
> platforms? Or can you guarantee that the compiler will not manufacture
> such an address from an otherwise harmless address?
Hmm, it's not quite clear, how it could be manufactured.
> Again, the key thing
> is to think about what the compiler can validly do on non-r10k platforms,
> however silly it might seem, and then make sure the workarounds cope
> with it.
Do you think of accesses that essentially look like this ?
if (machine_x)
*uncached(const_addr) = val;
else
*cached(const_addr) = val;
Fortunately (at least? even?) on IP28 cached access (hence a block read
request) to an I/O-device address is a non-issue. In this respect the
hardware design seems to follow the recommendations from the R10000 manual
(NACK from external agent?):
- if such an access graduates (i.e. a "real" access), a bus-error will occur.
- if not (i.e. mis-speculated), nothing happens.
However, i don't yet know, how O2 behaves, or, if there exists any other
R10k-machine, which would need the software-workaround.
>
> >> I'm also a little worried that the compiler is free to make up accesses
> >> that didn't exist in the original program, provided that those accesses
> > The cache-barrier itself ?
>
> No, in general. Optimisers (particularly loop optimisers) can invent
> accesses that didn't exist in the original source code. Normally they
> would only be executed in correct circumstances, but with this
> speculative execution, that might not be true.
>
> >> are never actually performed in cases where they'd be wrong. So how about:
> >>
> >> -mr10k-cache-barrier=load-store
> >> Insert a cache barrier at the beginning of any sequentially-executed
> >> series of instructions that contains a load or store. For the purposes
> >> of this option, GCC can ignore loads and stores that it can prove
> >> are an in-range access to:
> >>
> >> (a) the current function's stack frame;
> >> (b) an incoming stack argument;
> >> (b) an object with a link-time-constant address; or
> >> (c) a block of uncached memory
> > Can we recognize uncached memory in the instruction ?
>
> Well, I was just thinking about teaching the compiler about KSEG2,
> the always-uncached XKPHYS addresses, etc. (Sorry for messing up
> the bullet letters there!) The idea is that we have a correlation
> between symbolic constants and C objects, so we can check whether
> an offset in a symbolic constant is within the object. We already
No doubt, this would be very helpfull.
> have code to do this in other situations. But there is no correlation
> between const_int addresses and C objects, and we cannot be sure that
> a given const_int address existed in the original source code, so
> I think the only safe thing is to check its uncached properties instead.
>
> I know all this must be frustrating. I'm sure your patches work great
> as they are with current and past kernels, and current and past compilers.
> The problem is that, if it becomes a mainline gcc feature, it needs to be
> defined from first principles.
Agreed, the design of any feature advantageously should be based on a clear
(more or less formal) specification of what the compiler can do.
> And we need to do that without assuming
> that the accesses we're looking at existed in the original source code.
>
> FWIW, I'm happy to help update the patch once we've agreed on an
This would be appreciated (of course :) Many thanks in advance!
> option spec.
Well, the option spec could be as listed above. With "store" as default
for an empty option-string ("none" as default if the option isn't given
at all).
>
> Richard
>
>
kind regards
peter
PS: apologies for delaying the answer, i just couldn't concentrate on
this topic recently.
^ permalink raw reply
* Re: [PATCH] SC26XX: New serial driver for SC2681 uarts
From: Pekka Enberg @ 2007-12-22 9:47 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Andrew Morton, linux-kernel, linux-mips, Andy Whitcroft, Alan Cox
In-Reply-To: <20071205092506.GA6691@alpha.franken.de>
Hi Thomas,
On Dec 5, 2007 11:25 AM, Thomas Bogendoerfer <tsbogend@alpha.franken.de> wrote:
> > These:
> >
> > > +#define READ_SC(p, r) readb((p)->membase + RD_##r)
> > > +#define WRITE_SC(p, r, v) writeb((v), (p)->membase + WR_##r)
> >
> > and these:
> >
> > > +#define READ_SC_PORT(p, r) read_sc_port(p, RD_PORT_##r)
> > > +#define WRITE_SC_PORT(p, r, v) write_sc_port(p, WR_PORT_##r, v)
> >
> > really don't need to exist. All they do is make the code harder to read.
>
> but they make the code safer. The chip has common register and port
> registers, which are randomly splattered over the address range. And
> some of them are read only, some write only. Read only and Write
> only register live at the same register offset and their function
> usually doesn't have anything in common. By using these macros I'll
> get compile errors when doing a READ_SC from a write only register
> and vice versa. I will also get compile errors, if I try to access a
> common register via READ_SC_PORT/WRITE_SC_PORT.
You can use grep to make sure there are no reads to a write-only
register. What you have there is not safety but macro obfuscation at
its best. It makes the code harder to read for anyone not intimately
familiar with the driver.
^ 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