* Re: MIPS 4KEc with 2.6.15
From: Mark Lin @ 2008-01-08 22:02 UTC (permalink / raw)
To: Jorgen Lundman; +Cc: linux-mips
In-Reply-To: <47824ACF.7050003@avtrex.com>
Jorgen,
You should not be using the atlas definition. Try the tangox one instead.
With the flush_cache_page changes, FUSE works fine for me using 2.6.15
and Sigma's tango2 board.
Mark Lin
On Jan 7, 2008 10:52 AM, David Daney <ddaney@avtrex.com> wrote:
> Jorgen Lundman wrote:
> >
> > Hello list,
> >
> > I have an embedded device running 2.6.15 kernel on a MIPS 4KEc 300MHz
> > CPU. It was configured for Sigma's tango2 board, which I know nothing
> > about, so I picked a mips-board by random, "atlas", and found I can
> > produce working kernel module compiles.
> >
> > However, when I compiled FUSE kernel module, it behaves erratically in
> > a way making the FUSE developer think I may have come across the cache
> > coherency bug in arm and mips, fixed sometime around 2.6.17.
> >
> > Since I can not change the kernel that is running, I was looking for
> > alternate solutions. FUSE itself has a work around, that calls
> > flush_cache_page(), but I found that mips-board atlas does not have
> > this defined:
> >
> > fuse: Unknown symbol flush_cache_page
>
> There are cache coherency issues on the 8634. You should be using the
> vendor's very most recent kernels. For me they seem to have resolved
> the cache issues.
>
> Also as noted by others, you need the exact kernel sources if you are
> going to build working modules.
>
> David Daney
>
>
^ permalink raw reply
* Re: kseg1 uncache access issue
From: Ralf Baechle @ 2008-01-08 18:59 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: lovecentry, linux-mips
In-Reply-To: <20080108170206.GA8777@alpha.franken.de>
On Tue, Jan 08, 2008 at 06:02:06PM +0100, Thomas Bogendoerfer wrote:
> On Wed, Jan 09, 2008 at 12:35:06AM +0800, lovecentry wrote:
> > As we know in mips achitecture if current pc falls into kseg1 segment, any
> > memory reference will bypass cache and fetch directly from dram. But for
> > some prcoessor such like mips R10K it has off chip L2 cache. I haven't found
>
> why do you think so ? R10k L2 cache controller is inside CPU and any
> access with uncached attribute will go directly to memory. The only
> systems, where this might be different are systems with caches unknown
> to the cpu. But even those usually obey that uncached accesses are
> going directly to memory.
It should also be mentioned that some R10000 machines do odd stuff with
uncached addresses.
IP27 class machines reuse the entire physical address space several times
to map different things. The selection of the four uncached address
spaces id done by the uncached attribute which is specified either in
the TLB or or as as bit 59..60 of a virtual address in XKPHYS.
The memory controller of the Indigo 2 R10000 needs to be switched to a
special slower mode to allow uncached accesses first.
Ralf
^ permalink raw reply
* Re: kseg1 uncache access issue
From: Thomas Bogendoerfer @ 2008-01-08 17:02 UTC (permalink / raw)
To: lovecentry; +Cc: linux-mips
In-Reply-To: <4783a652.1cef600a.2530.fffffe31@mx.google.com>
On Wed, Jan 09, 2008 at 12:35:06AM +0800, lovecentry wrote:
> As we know in mips achitecture if current pc falls into kseg1 segment, any
> memory reference will bypass cache and fetch directly from dram. But for
> some prcoessor such like mips R10K it has off chip L2 cache. I haven't found
why do you think so ? R10k L2 cache controller is inside CPU and any
access with uncached attribute will go directly to memory. The only
systems, where this might be different are systems with caches unknown
to the cpu. But even those usually obey that uncached accesses are
going directly to memory.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* kseg1 uncache access issue
From: lovecentry @ 2008-01-08 16:35 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
Hi
As we know in mips achitecture if current pc falls into kseg1 segment, any
memory reference will bypass cache and fetch directly from dram. But for
some prcoessor such like mips R10K it has off chip L2 cache. I haven't found
any available path which can access dram directly. All memory reference need
pass through L2 cache. Does it mean any memory reference in kseg1 will be
fetch from L2 cache rather than dram for such system? How does such system
design when system software need access kseg1 region? Further more, Kseg2 is
used to do memory map for those peripheral so Is there has a particular
circuit that routes those access to the appropriate destination.
Any suggestion is highly appreciate!!!
Tony
[-- Attachment #2: Type: text/html, Size: 3026 bytes --]
^ permalink raw reply
* kseg1 uncache access issue
From: lovecentry @ 2008-01-08 16:35 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
Hi
As we know in mips achitecture if current pc falls into kseg1 segment, any
memory reference will bypass cache and fetch directly from dram. But for
some prcoessor such like mips R10K it has off chip L2 cache. I haven't found
any available path which can access dram directly. All memory reference need
pass through L2 cache. Does it mean any memory reference in kseg1 will be
fetch from L2 cache rather than dram for such system? How does such system
design when system software need access kseg1 region? Further more, Kseg2 is
used to do memory map for those peripheral so Is there has a particular
circuit that routes those access to the appropriate destination.
Any suggestion is highly appreciate!!!
Tony
[-- Attachment #2: Type: text/html, Size: 3026 bytes --]
^ permalink raw reply
* Re: memory dump on mips
From: Thiemo Seufer @ 2008-01-08 14:54 UTC (permalink / raw)
To: Andi; +Cc: linux-mips
In-Reply-To: <4783754D.8010007@gmx.net>
Andi wrote:
> Hi list,
>
> we are working on an embedded Linux device with a Sigma SMP8634 (MIPS
> 4KEc 300MHz CPU) mounted on it. Unfortunately we don't have access to
> the kernel running on the system.
>
> We figured out, that the bootloader loads the kernel image to 0x90020000
> (physical address).
This sounds like you are confusing physical and virtual addresses.
Typically the kernel is loaded to the direct-mapped KSEG0 segment,
which starts at physical 0x00000000 / virtual 0x80000000.
So the physical address you are looking for would be 0x10020000.
Thiemo
^ permalink raw reply
* memory dump on mips
From: Andi @ 2008-01-08 13:06 UTC (permalink / raw)
To: linux-mips
Hi list,
we are working on an embedded Linux device with a Sigma SMP8634 (MIPS
4KEc 300MHz CPU) mounted on it. Unfortunately we don't have access to
the kernel running on the system.
We figured out, that the bootloader loads the kernel image to 0x90020000
(physical address). So it should be possible to read the image from that
address later on in Linux. We are not sure if our approach does not work
because of the memory protection that the SMP8634 offers, or if we do
something wrong.
This approach for a kernel module works on ARM9 (with MMU):
<code>
memory = ioremap_nocache(0x90020000, 20);
char byte = readb(memory);
</code>
Well, on mips this just throws 0x00.
Is this supposed to work on mips as well? Or do I have to deal with
"remap_pfn_range" or even VMA and "vm_ops->nopage"?
Thank you very much in advance
Regards,
andi
^ permalink raw reply
* [PATCH] Fixes small option parsing bug in au1100fb.c.
From: Freddy Spierenburg @ 2008-01-08 11:39 UTC (permalink / raw)
To: Antonino Daplas, source; +Cc: linux-mips
[-- Attachment #1.1: Type: text/plain, Size: 758 bytes --]
Hi,
I've noticed that drivers/video/au1100fb.c contains a small time
option parsing bug. In the middle of an if...else if...
construction was inserted a lonesome if on it's own. This is
causing an incorrect 'unsupported option' warning, while the
option itself is parsed successfully.
This patch makes the lonesome if part of the whole if...else
if... construction, like it should be. No longer the incorrect
warning message will be displayed.
Signed-off-by: Freddy Spierenburg <freddy@dusktilldawn.nl>
--
$ cat ~/.signature
Freddy Spierenburg <freddy@dusktilldawn.nl> http://freddy.snarl.nl/
GnuPG: 0x7941D1E1=C948 5851 26D2 FA5C 39F1 E588 6F17 FD5D 7941 D1E1
$ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain!
[-- Attachment #1.2: au1100fb.c-patch --]
[-- Type: text/plain, Size: 539 bytes --]
diff -Naur linux-2.6.23-orig/drivers/video/au1100fb.c linux-2.6.23/drivers/video/au1100fb.c
--- linux-2.6.23-orig/drivers/video/au1100fb.c 2008-01-08 11:07:13.000000000 +0000
+++ linux-2.6.23/drivers/video/au1100fb.c 2008-01-08 11:13:37.000000000 +0000
@@ -707,7 +707,8 @@
print_warn("Panel %s not supported!", this_opt);
}
}
- if (!strncmp(this_opt, "nocursor", 8)) {
+ /* No cursor option */
+ else if (!strncmp(this_opt, "nocursor", 8)) {
this_opt += 8;
nocursor = 1;
print_info("Cursor disabled");
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* new bug on 2.6.24-rc6
From: Giuseppe Sacco @ 2008-01-08 9:36 UTC (permalink / raw)
To: linux-mips
I don't know if this is related to mips, but the latest kernel keeps
hanging (at least four times in one day) with this stack trace on both
vfs_read and vfs_write:
800940e4 cache_alloc_refill
80094004 kmem_cache_alloc
801f5fc8 radix_tree_node_alloc
801f6110 radix_tree_insert
8006ba9c add_to_page_cache
8006bcb8 add_to_page_cache_lru
[...]
I am just wondering if anyone if using successfully this kernel version.
bye,
Giuseppe
^ permalink raw reply
* [BUG][PATCH] fix broken software reset for Malta board
From: Dmitri Vorobiev @ 2008-01-08 3:44 UTC (permalink / raw)
To: ralf, linux-mips; +Cc: Linux-kernel
From: Dmitri Vorobiev <dmitri.vorobiev@gmail.com>
I noticed that the commit f197465384bf7ef1af184c2ed1a4e268911a91e3
(MIPS Tech: Get rid of volatile in core code) broke the software
reset functionality for MIPS Malta boards in big-endian mode.
According to the MIPS Malta board user's manual, writing the magic
32-bit GORESET value into the SOFTRES register initiates board soft
reset. My experimentation has shown that the endianness of the GORESET
integer should thereby be the same as the endianness, which has been
set for the CPU itself. The writew() function used to write the magic
value in the code introduced by the commit mentioned above, however,
swaps bytes for big-endian kernels and transfers 16 bits instead of 32.
The patch below replaces the writew() function by the __raw_writel()
routine, which leaves the byte order intact and transfers the whole
MIPS machine word. Trivial code cleanup (replacing spaces by a tab
and cutting oversized lines to make checkpatch.pl happy) is also
included.
The patch was tested using a Malta evaluation board running in both
BE and LE modes. For both modes, software reset was fully functional
after the change.
P.S. I suspect that the same commit broke the "standby" functionality
for MIPS Atlas boards. However, I did not touch the Atlas code as I
don't have such board at my disposal and also because the linux-mips.org
Web site claims that Atlas support is scheduled for removal.
Signed-off-by: Dmitri Vorobiev <dmitri.vorobiev@gmail.com>
---
diff --git a/arch/mips/mips-boards/generic/reset.c b/arch/mips/mips-boards/generic/reset.c
index 7a1bb51..583d468 100644
--- a/arch/mips/mips-boards/generic/reset.c
+++ b/arch/mips/mips-boards/generic/reset.c
@@ -39,16 +39,18 @@ static void atlas_machine_power_off(void);
static void mips_machine_restart(char *command)
{
- unsigned int __iomem *softres_reg = ioremap(SOFTRES_REG, sizeof(unsigned int));
+ unsigned int __iomem *softres_reg =
+ ioremap(SOFTRES_REG, sizeof(unsigned int));
- writew(GORESET, softres_reg);
+ __raw_writel(GORESET, softres_reg);
}
static void mips_machine_halt(void)
{
- unsigned int __iomem *softres_reg = ioremap(SOFTRES_REG, sizeof(unsigned int));
+ unsigned int __iomem *softres_reg =
+ ioremap(SOFTRES_REG, sizeof(unsigned int));
- writew(GORESET, softres_reg);
+ __raw_writel(GORESET, softres_reg);
}
#if defined(CONFIG_MIPS_ATLAS)
^ permalink raw reply related
* [PATCH] Add GPIO system button to MTX-1
From: Florian Fainelli @ 2008-01-07 18:00 UTC (permalink / raw)
To: linux-mips
This patch adds support for the GPIO connected system button on the MTX-1 boards. Default configuration is updated accordingly.
Signed-off-by: Florian Fainelli <florian.fainelli@telecomint.eu>
---
diff --git a/arch/mips/au1000/mtx-1/platform.c b/arch/mips/au1000/mtx-1/platform.c
index 49c0fb4..ce8637b 100644
--- a/arch/mips/au1000/mtx-1/platform.c
+++ b/arch/mips/au1000/mtx-1/platform.c
@@ -22,9 +22,32 @@
#include <linux/types.h>
#include <linux/platform_device.h>
#include <linux/leds.h>
+#include <linux/gpio_keys.h>
+#include <linux/input.h>
#include <asm/gpio.h>
+static struct gpio_keys_button mtx1_gpio_button[] = {
+ {
+ .gpio = 207,
+ .code = BTN_0,
+ .desc = "System button",
+ }
+};
+
+static struct gpio_keys_platform_data mtx1_buttons_data = {
+ .buttons = mtx1_gpio_button,
+ .nbuttons = ARRAY_SIZE(mtx1_gpio_button),
+};
+
+static struct platform_device mtx1_button = {
+ .name = "gpio-keys",
+ .id = -1,
+ .dev = {
+ .platform_data = &mtx1_buttons_data,
+ }
+};
+
static struct resource mtx1_wdt_res[] = {
[0] = {
.start = 15,
@@ -66,11 +89,13 @@ static struct platform_device mtx1_gpio_leds = {
static struct __initdata platform_device * mtx1_devs[] = {
&mtx1_gpio_leds,
- &mtx1_wdt
+ &mtx1_wdt,
+ &mtx1_button
};
static int __init mtx1_register_devices(void)
{
+ gpio_direction_input(207);
return platform_add_devices(mtx1_devs, ARRAY_SIZE(mtx1_devs));
}
diff --git a/arch/mips/configs/mtx1_defconfig b/arch/mips/configs/mtx1_defconfig
index b536d7c..c20b560 100644
--- a/arch/mips/configs/mtx1_defconfig
+++ b/arch/mips/configs/mtx1_defconfig
@@ -1617,6 +1617,7 @@ CONFIG_INPUT_EVBUG=m
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
+CONFIG_KEYBOARD_GPIO=y
CONFIG_KEYBOARD_SUNKBD=m
CONFIG_KEYBOARD_LKKBD=m
CONFIG_KEYBOARD_XTKBD=m
^ permalink raw reply related
* Re: [PATCH] Wrong CONFIG option prevents setup of DMA zone.
From: Ralf Baechle @ 2008-01-07 17:20 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20071230114540.A0ADFC2EEF@solo.franken.de>
On Sun, Dec 30, 2007 at 12:45:40PM +0100, Thomas Bogendoerfer wrote:
> Wrong CONFIG option prevents setup of DMA zone.
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Applied.
Ralf
^ permalink raw reply
* Re: [PATCH] SNI_RM: collected changes
From: Ralf Baechle @ 2008-01-07 17:05 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20080104223107.4D570C2EF2@solo.franken.de>
On Fri, Jan 04, 2008 at 11:31:07PM +0100, Thomas Bogendoerfer wrote:
> - EISA support for non PCI RMs (RM200 and RM400-xxx). The major part
> is the splitting of the EISA and onboard ISA of the RM200, which
> makes the EISA bus on the RM200 look like on other RMs.
> - 64bit kernel support
> - system type detection is now common for big and little endian (thanks
> Ralf)
> - moved sniprom code to arch/mips/fw
> - added call_o32 function to arch/mips/fw/lib, which uses a private
> stack for calling prom functions
> - fix problem with isa interrupts, which makes using pit clockevent
> possible
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> ---
>
> This is 2.6.25 material and replaces [PATCH] SNI_RM: EISA support for
> A20R/RM200
I dropped this into my -queue and -mm trees.
Ralf
^ permalink raw reply
* Re: [MIPS] 64-bit Sibyte kernels need DMA32.
From: Ralf Baechle @ 2008-01-07 16:38 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: linux-mips
In-Reply-To: <20080108.004113.126142686.anemo@mba.ocn.ne.jp>
On Tue, Jan 08, 2008 at 12:41:13AM +0900, Atsushi Nemoto wrote:
> How about this fix?
Seems to do the trick on Malta, maybe people can test this patch applied on
top of the master branch of the lmo kernel on various systems?
Ralf
^ permalink raw reply
* Re: Arch/mips/kernel/vpe.c
From: Ralf Baechle @ 2008-01-07 16:18 UTC (permalink / raw)
To: Thiemo Seufer; +Cc: KokHow.Teh, linux-mips
In-Reply-To: <20080105170546.GG22809@networkno.de>
On Sat, Jan 05, 2008 at 05:05:46PM +0000, Thiemo Seufer wrote:
> > I am working on MIPS34KC with APRP kernel and I use uclibc
> > gccc-3.4.4 to build applications to run on VPE1. The present
> > implementation of VPE loader is limited to a few relocation types which
> > are used when mips_sde compiler is used. However, the relocatable binary
> > churn out from my uclibc-gcc-3.4.4 has more other relocation types than
> > the ones defined in arch/mips/kernel/vpe.c, especially those with GOT
> > relocation types. I have taken a look at the System V ABI Third Edition
> > but if anybody has any code reference and pointers to how each
> > relocation types should be implemented in C-code, it would be very
> > helpful.
>
> The most likely place to look at would be the binutils source code. That
> said, you can probably get away without enhancing the VPE loader by using
> a) fully linked (non-relocatable) executables, or
> b) non-PIC code, like SDE does
>
> Regardless of your choice, you will have to make sure the uclibc toolchain
> doesn't use any libraries which need Linux facilities, as the bare-metal
> environment on VPE1 doesn't provide them. For that reason I believe you
> are better of with SDE or a similiar mips*-elf configured toolchain.
I'm tempted to replace the existing vpe loader with something like the 2.4
version of insmod which does all the relocation handling in userspace and a
device file which make the vpe memory available to userspace for the loader
to write to. Or something like spufs.
Ralf
^ permalink raw reply
* Re: MIPS 4KEc with 2.6.15
From: David Daney @ 2008-01-07 15:52 UTC (permalink / raw)
To: Jorgen Lundman; +Cc: linux-mips
In-Reply-To: <478174C1.2090708@lundman.net>
Jorgen Lundman wrote:
>
> Hello list,
>
> I have an embedded device running 2.6.15 kernel on a MIPS 4KEc 300MHz
> CPU. It was configured for Sigma's tango2 board, which I know nothing
> about, so I picked a mips-board by random, "atlas", and found I can
> produce working kernel module compiles.
>
> However, when I compiled FUSE kernel module, it behaves erratically in
> a way making the FUSE developer think I may have come across the cache
> coherency bug in arm and mips, fixed sometime around 2.6.17.
>
> Since I can not change the kernel that is running, I was looking for
> alternate solutions. FUSE itself has a work around, that calls
> flush_cache_page(), but I found that mips-board atlas does not have
> this defined:
>
> fuse: Unknown symbol flush_cache_page
There are cache coherency issues on the 8634. You should be using the
vendor's very most recent kernels. For me they seem to have resolved
the cache issues.
Also as noted by others, you need the exact kernel sources if you are
going to build working modules.
David Daney
^ permalink raw reply
* Re: [MIPS] 64-bit Sibyte kernels need DMA32.
From: Atsushi Nemoto @ 2008-01-07 15:41 UTC (permalink / raw)
To: linux-mips; +Cc: ralf
In-Reply-To: <20071228.014321.41630007.anemo@mba.ocn.ne.jp>
On Fri, 28 Dec 2007 01:43:21 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
> This commit breaks platforms which have real prom_free_prom_memory().
> ...
> If I reverted the commit, this crash does not happen. How I can fix this?
I see malta disabled prom_free_prom_memory for now, but it seems some
other boards are affected by this problem too.
How about this fix?
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 7f6ddcb..f8a535a 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -269,7 +269,7 @@ static void __init bootmem_init(void)
static void __init bootmem_init(void)
{
- unsigned long init_begin, reserved_end;
+ unsigned long reserved_end;
unsigned long mapstart = ~0UL;
unsigned long bootmap_size;
int i;
@@ -344,7 +344,6 @@ static void __init bootmem_init(void)
min_low_pfn, max_low_pfn);
- init_begin = PFN_UP(__pa_symbol(&__init_begin));
for (i = 0; i < boot_mem_map.nr_map; i++) {
unsigned long start, end;
@@ -352,8 +351,8 @@ static void __init bootmem_init(void)
end = PFN_DOWN(boot_mem_map.map[i].addr
+ boot_mem_map.map[i].size);
- if (start <= init_begin)
- start = init_begin;
+ if (start <= min_low_pfn)
+ start = min_low_pfn;
if (start >= end)
continue;
^ permalink raw reply related
* Re: Toshiba JMR 3927 working setup?
From: Atsushi Nemoto @ 2008-01-07 15:34 UTC (permalink / raw)
To: ralf; +Cc: gregor.waltz, linux-mips
In-Reply-To: <20080107122156.GB24700@linux-mips.org>
On Mon, 7 Jan 2008 12:21:56 +0000, Ralf Baechle <ralf@linux-mips.org> wrote:
> Well, is mmiowb() needed at all on JMR3927 - or R3000 in general? Mmiowb()
> is meant to deal with weak ordering which only matters to a few SMP
> configurations.
Well, serial_txx9 driver (mis)use mmiowb() to flush write buffer.
But I was wrong. TX39H2 core _has_ SYNC instruction. So the patch I
mentioned is not required for JMR3927 platform anyway. Sorry for
confusion.
---
Atsushi Nemoto
^ permalink raw reply
* Re: [MIPS] Fix modpost warning in raw binary builds.
From: Ralf Baechle @ 2008-01-07 14:58 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: linux-mips
In-Reply-To: <20080106.004834.96687248.anemo@mba.ocn.ne.jp>
On Sun, Jan 06, 2008 at 12:48:34AM +0900, Atsushi Nemoto wrote:
> >
> > MODPOST vmlinux.o
> > WARNING: vmlinux.o(.text+0x478): Section mismatch: reference to .init.text:start_kernel (between '_stext' and 'run_init_process')
>
> This commit should break CONFIG_BOOT_RAW. Since I do not have any
> good idea to avoid this warning, reverting this commit would be the
> best for now. The warning is just a false positive anyway.
But a somewhat nervragging one and it'd be easy to fix now that
__INIT_REFOK is in the kernel, something like the below patch should do
the trick.
Ralf
diff --git a/arch/mips/kernel/head.S b/arch/mips/kernel/head.S
index 2367687..50be56c 100644
--- a/arch/mips/kernel/head.S
+++ b/arch/mips/kernel/head.S
@@ -136,7 +136,8 @@ EXPORT(_stext)
* kernel load address. This is needed because this platform does
* not have a ELF loader yet.
*/
- __INIT
+FEXPORT(__kernel_entry)
+ j kernel_entry
#endif
__INIT_REFOK
^ permalink raw reply related
* Re: MIPS 4KEc with 2.6.15
From: Jorgen Lundman @ 2008-01-07 13:25 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <20080107120852.GA24700@linux-mips.org>
Sorry, I should have said, I grabbed 2.6.15.7 to use. And after the
issues, I even tried the exact 2.6.15 tarball off Sigmas FTP with the
same results. It does not define flush_cache_pages for Atlas board, only
SGI IPxx from what I can tell.
Ralf Baechle wrote:
> On Mon, Jan 07, 2008 at 09:39:29AM +0900, Jorgen Lundman wrote:
>
>> I have an embedded device running 2.6.15 kernel on a MIPS 4KEc 300MHz CPU.
>> It was configured for Sigma's tango2 board, which I know nothing about, so
>> I picked a mips-board by random, "atlas", and found I can produce working
>> kernel module compiles.
>>
>> However, when I compiled FUSE kernel module, it behaves erratically in a
>> way making the FUSE developer think I may have come across the cache
>> coherency bug in arm and mips, fixed sometime around 2.6.17.
>>
>> Since I can not change the kernel that is running, I was looking for
>> alternate solutions. FUSE itself has a work around, that calls
>> flush_cache_page(), but I found that mips-board atlas does not have this
>> defined:
>
> While you may not be able to change the kernel running on your board,
> you should be building any modules against kernel headers of the exact
> kernel running and configured for the platform and CPU you're using.
>
> Mixing and matching different versions and configurations may work but
> frequently it will fail silently.
>
> Ralf
>
--
Jorgen Lundman | <lundman@lundman.net>
Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell)
Japan | +81 (0)3 -3375-1767 (home)
^ permalink raw reply
* Re: Toshiba JMR 3927 working setup?
From: Ralf Baechle @ 2008-01-07 12:21 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: gregor.waltz, linux-mips
In-Reply-To: <20080105.234256.25910407.anemo@mba.ocn.ne.jp>
On Sat, Jan 05, 2008 at 11:42:56PM +0900, Atsushi Nemoto wrote:
> > Our 2.4.12 kernel uses -mcpu=r3000 -mips1 to build the kernel. I tried
> > switching the arch to r3000 from r3900 in 2.6.23.9, but that did not
> > help. Perhaps -mips1 or an equivalent could help? I will try on Monday.
>
> I think both mcpu=r3000 and r3900 should work. But I believe at least
> one kernel patch is required for all MIPS I platforms including JMR3927.
>
> http://www.linux-mips.org/archives/linux-mips/2007-02/msg00320.html
Well, is mmiowb() needed at all on JMR3927 - or R3000 in general? Mmiowb()
is meant to deal with weak ordering which only matters to a few SMP
configurations.
Ralf
^ permalink raw reply
* Re: MIPS 4KEc with 2.6.15
From: Ralf Baechle @ 2008-01-07 12:08 UTC (permalink / raw)
To: Jorgen Lundman; +Cc: linux-mips
In-Reply-To: <478174C1.2090708@lundman.net>
On Mon, Jan 07, 2008 at 09:39:29AM +0900, Jorgen Lundman wrote:
> I have an embedded device running 2.6.15 kernel on a MIPS 4KEc 300MHz CPU.
> It was configured for Sigma's tango2 board, which I know nothing about, so
> I picked a mips-board by random, "atlas", and found I can produce working
> kernel module compiles.
>
> However, when I compiled FUSE kernel module, it behaves erratically in a
> way making the FUSE developer think I may have come across the cache
> coherency bug in arm and mips, fixed sometime around 2.6.17.
>
> Since I can not change the kernel that is running, I was looking for
> alternate solutions. FUSE itself has a work around, that calls
> flush_cache_page(), but I found that mips-board atlas does not have this
> defined:
While you may not be able to change the kernel running on your board,
you should be building any modules against kernel headers of the exact
kernel running and configured for the platform and CPU you're using.
Mixing and matching different versions and configurations may work but
frequently it will fail silently.
Ralf
^ permalink raw reply
* Re: [PATCH] METH: fix MAC address handling
From: David Miller @ 2008-01-07 1:20 UTC (permalink / raw)
To: tsbogend; +Cc: netdev, linux-mips, ralf, jgarzik
In-Reply-To: <20080106113815.GA6140@alpha.franken.de>
From: tsbogend@alpha.franken.de (Thomas Bogendoerfer)
Date: Sun, 6 Jan 2008 12:38:16 +0100
> On Sun, Jan 06, 2008 at 12:23:05AM -0800, David Miller wrote:
> > I know that this whole driver is full of assumptions about
> > the endianness of the system this chip is found on, so
> > I'm only interested in if the transformation is equivalent
> > and the driver will keep working properly.
>
> I've tested the driver and it's still working :-)
Great :)
^ permalink raw reply
* MIPS 4KEc with 2.6.15
From: Jorgen Lundman @ 2008-01-07 0:39 UTC (permalink / raw)
To: linux-mips
Hello list,
I have an embedded device running 2.6.15 kernel on a MIPS 4KEc 300MHz
CPU. It was configured for Sigma's tango2 board, which I know nothing
about, so I picked a mips-board by random, "atlas", and found I can
produce working kernel module compiles.
However, when I compiled FUSE kernel module, it behaves erratically in a
way making the FUSE developer think I may have come across the cache
coherency bug in arm and mips, fixed sometime around 2.6.17.
Since I can not change the kernel that is running, I was looking for
alternate solutions. FUSE itself has a work around, that calls
flush_cache_page(), but I found that mips-board atlas does not have this
defined:
fuse: Unknown symbol flush_cache_page
Should I try other mips-boards that may have this function call defined?
Do I have other ways to avoid the cache coherence bug?
The /proc/ksyms is gone, so I do not think I am able to check what
symbols their kernel has.
Lund
--
Jorgen Lundman | <lundman@lundman.net>
Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell)
Japan | +81 (0)3 -3375-1767 (home)
^ permalink raw reply
* Re: [PATCH] Fix IP32 breakage
From: Giuseppe Sacco @ 2008-01-06 21:44 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <20080106185852.GA5530@deprecation.cyrius.com>
I tested the original patch (2.6.24-rc6) and the system finally boot correctly. The second patch (related to meth) also works great on two different O2 systems.
On Sun, 6 Jan 2008 19:58:52 +0100 Martin Michlmayr <tbm@cyrius.com> wrote:
> The same patch is needed for 2.6.23. Here's a version that will apply
> against 2.6.23. Ralf, can you please commit that as well.
[...]
^ 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