* Re: [MIPS] irq_cpu: use handle_percpu_irq handler to avoid dropping interrupts.
From: Atsushi Nemoto @ 2007-11-22 15:41 UTC (permalink / raw)
To: linux-mips; +Cc: ralf
In-Reply-To: <S20032632AbXKOURg/20071115201736Z+24020@ftp.linux-mips.org>
On Thu, 15 Nov 2007 20:17:31 +0000, linux-mips@linux-mips.org wrote:
> Subject: [MIPS] irq_cpu: use handle_percpu_irq handler to avoid dropping interrupts.
> Author: Ralf Baechle <ralf@linux-mips.org> Thu Nov 15 19:37:15 2007 +0000
> Commit: eebc88e5d2cffc07b969c8f426552a44e5ce51f8
> Gitweb: http://www.linux-mips.org/g/linux/eebc88e5
> Branch: master
This might broke probe_irq_on()/probe_irq_off(), since
handle_percpu_irq() does not check IRQ_WAITING bit.
This is a quick fix. But I'm not sure where is the right place to fix...
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
---
diff --git a/arch/mips/kernel/irq_cpu.c b/arch/mips/kernel/irq_cpu.c
index 0ee2567..9d97d4b 100644
--- a/arch/mips/kernel/irq_cpu.c
+++ b/arch/mips/kernel/irq_cpu.c
@@ -114,7 +114,9 @@ void __init mips_cpu_irq_init(void)
for (i = irq_base; i < irq_base + 2; i++)
set_irq_chip(i, &mips_mt_cpu_irq_controller);
- for (i = irq_base + 2; i < irq_base + 8; i++)
+ for (i = irq_base + 2; i < irq_base + 8; i++) {
set_irq_chip_and_handler(i, &mips_cpu_irq_controller,
handle_percpu_irq);
+ irq_desc[i].status |= IRQ_NOPROBE;
+ }
}
^ permalink raw reply related
* Re: [PATCH 02/59] arch/mips: Add missing "space"
From: Ralf Baechle @ 2007-11-21 22:34 UTC (permalink / raw)
To: Joe Perches; +Cc: linux-kernel, linux-mips
In-Reply-To: <23f0badf8dab73294c2aa142fafb9301ca843e88.1195454434.git.joe@perches.com>
On Mon, Nov 19, 2007 at 05:47:54PM -0800, Joe Perches wrote:
Queued for 2.6.25.
Thanks,
Ralf
^ permalink raw reply
* Bud
From: Lusia R., Chicago @ 2007-11-22 11:41 UTC (permalink / raw)
To: Lusia R., Chicago
All your pharma needs.
shallthere.com.
Remove the dot from the end of the link to use it.
^ permalink raw reply
* Re: smp8634 add memory at dram1
From: David Kuk @ 2007-11-22 7:35 UTC (permalink / raw)
To: YH Lin; +Cc: linux-mips
In-Reply-To: <5DF100B598199744B111FCEA5222E78A02D52DCE@sigma-exch1.sdesigns.com>
[-- Attachment #1: Type: text/plain, Size: 4870 bytes --]
Dear all,
thank you very much Lin, for your kindly reply. May I ask you some more
questions ?
1. about your answer 2, it's true that 0x10000000 to 0x10020000 are
reserved,
so what's the way i can sure no one use this area of memory ? because
em86xx_kmem_start is still the dram controller0's.
2. about your answer 3, if i need to enable the PCI host, you mean i will
have no chance to have greater than 112 MB DMA memory start from the
em86xx_kmem_start ? it's seems a dilemma here, I may describe it more
clearly. I have one ram size of 128 at dram0 controller and as well as
another 128 at dram1 controller. previously it's work very well, the
controller0's ram is for linux and controller1's memory is for video decode.
But recently because the grow of code size of grow of both linux as well as
middle ware, we really need more memory for for kernel run, so if in this
situation , what should i do ?
thx a lot for your help
David
On 11/21/07, YH Lin <YH_Lin@sdesigns.com> wrote:
>
>
>
> Hi David,
>
>
>
> We have not done so for SMP8634. But I think it is possible to do this:
>
>
>
> 1. Using remap register 4 instead, there you will have
> 0x0c000000-0x16fe0000 contiguous space, where 0x0c000000-0x0fffffff is
> mapped to DRAM1 and 0x10000000-0x16fe0000 is in DRAM0.
> 2. You'd probably reserve the memory 0x10000000-0x10020000 since
> this area is used by other things so it'd be better if no one else is using
> this portion of memory.
> 3. As for DMA zone or normal zone, that depends. Do you have the
> need to enable PCI host? If so, the max. size of DMA zone is 112MB, or else
> it can all be DMA memory (provide that the address translation routines are
> modified accordingly).
>
>
>
> Regards,
>
> YH
>
>
> ------------------------------
>
> *From:* linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org]
> *On Behalf Of *David Kuk
> *Sent:* Monday, November 19, 2007 8:23 PM
> *To:* David Daney
> *Cc:* linux-mips@linux-mips.org
> *Subject:* Re: smp8634 add memory at dram1
>
>
>
> Thanks you all for helping.
>
> AS Daney suggested, I have map the dram1's first 64 MB memory (total 128)
> to remap register 3,
> and add the remap register 3 into the BOOT_MEMROY_RAM use the method
> add_memory_region.
> When i bootup the linux kernel print out that it have totally 176MB ram ,
> which is 06fe0000@10020000(dram0) and 04000000@08000000(64mb dram1 at
> remap register3). How ever, This mapping shows that the total memory in the
> linux kernel is not contiguous. the OS can run, but as i see the source
> code, when the kernel divided these memory into pages, it did not consider
> if the memory is contiguous or not, is it ok ? and how should i allocate
> the memories into ZONE[DMA] and ZONE[NORMAL], is it possible if I wish all
> the 176MB memory can be allocate as ZONE[DMA]?
>
>
> Best wishes
> David
>
>
>
> On 11/15/07, *David Daney* <ddaney@avtrex.com> wrote:
>
> David Kuk wrote:
> > After study about the memory configuration of sigma smp8634, i found
> > some difficult to accomplish the task.
> >
> > so my question is if have two 128MB ram separately under dram0 and
> > dram1 controller, where dram0 for linux and dram1 for video decoding.
> > Now the situation is the memory for linux is not enough and video
> > decoding can not use all of it's 128MB at dram1, what we plan to do is
> > to share 64MB at dram1 to the linux kernel as high memory, and only
> > reserved 64MB at dram1 for the video decoding.
> >
> > first, in MIPS architecture, we found that the kseg0 and kseg1 are
> > mapped to 0x00000000-0x20000000, which include only dram0 controller,
> > so we wish to add the dram1 memory manually to the kernel using
> > function add_memory_region at setup.c , after booting up result the
> > warning that the memory larger than 512 need to configured the kernel
> > support high memory.
> >
> > then when we configure the kernel to support high memory at menu
> > configure, the kernel when booting up will remind us our CPU do not
> > support high memory due to cache aliases.
> >
> > Both way will lead the linux can not boot up normally, so what should
> > we do, is there any mis-understanding about the hardware
> > implementation or MIPS design?
>
> I think your understanding of the 8634 is at least close to correct.
>
> It may be possible (but I have not tried it yet) to use the remapping
> registers to move dram1 into the first 512MB of the memory space. If it
> is possible, you would then have to modify the gbus access functions
> accordingly. Also the 8634 media drivers would probably have to be
> changed as well. I am not sure about the microcode for the media DSPs,
> but if it is dependent on the mapping of the DRAM, then you would
> probably have to get the vendor's help.
>
> Let me know if you are successful.
>
> Thanks,
> David Daney
>
>
>
[-- Attachment #2: Type: text/html, Size: 8934 bytes --]
^ permalink raw reply
* Re: how to use memory before kernel load address?
From: zhuzhenhua @ 2007-11-21 3:58 UTC (permalink / raw)
To: Thiemo Seufer; +Cc: linux-mips
In-Reply-To: <20071120130451.GI11996@networkno.de>
On 11/20/07, Thiemo Seufer <ths@networkno.de> wrote:
> zhuzhenhua wrote:
> > hello,all
> > i want to place my kernel loadaddr=0x81008000 and set
> > EBASE=0x81000000, it workes.
> > but there is still some memory usable before 0x81000000, for
> > example from 0x80100000 ~ 0x80200000
>
> The obvious thing to do seems to set LOARADDR to 0x80208000.
>
> > i have try to pass param as mem=1M@1M mem=16M@16M to the kernel,
> > it seems only take the 0x8000000 ~ kernel_end as reserved.
> > is there any other options to set the memory useable? ( my kernel
> > version is 2.6.14)
> > thanks for any hints
>
> AFAIR the kernel assumes to occupy the lowest addresses of the usable RAM.
>
>
> Thiemo
>
i have resolve it, by modify as follow:
in arch/mips/kernel/setup.c
static inline void bootmem_init(void)
.....
if (curr_pfn < start_pfn) // just change the judgement
curr_pfn = start_pfn;
....
/* Register lowmem ranges */
free_bootmem(PFN_PHYS(curr_pfn), PFN_PHYS(size));
thanks all.
zzh
^ permalink raw reply
* Re: futex_wake_op deadlock?
From: Ralf Baechle @ 2007-11-20 19:00 UTC (permalink / raw)
To: David Daney; +Cc: Kaz Kylheku, linux-mips
In-Reply-To: <4743279B.7070402@avtrex.com>
On Tue, Nov 20, 2007 at 10:29:47AM -0800, David Daney wrote:
>> Notice the branch at the end of the fixup code, it goes back to the
>> SC instruction. The SC instruction took an exception so it will not have
>> changed $1 so the loop will continue endless unless by coincidence the
>> value to be stored from $1 happened to be zero.
>>
>> Obviously this one was MIPS specific and may hit all supported ABIs. So
>> my initial suspicion this might be the issue David Miller recently
>> discovered in the binary compat code isn't true. And it's a local DoS
>> probably for all of 2.6.16 and up.
>>
>
> I mostly similar code is in 2.6.15, so I think it is effected as well.
> 2.6.12 on the other hand doesn't seem to have futex.h
It originally appeared in the lmo kernel for 2.6.14-rc1 and a little
after the 2.6.14 release in kernel.org.
If I say 2.6.16 then it's simply that I don't ever look at anything that
doesn't have a -stable branch.
Ralf
^ permalink raw reply
* Re: futex_wake_op deadlock?
From: David Daney @ 2007-11-20 18:29 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Kaz Kylheku, linux-mips
In-Reply-To: <20071120112051.GB30675@linux-mips.org>
Ralf Baechle wrote:
>
> Notice the branch at the end of the fixup code, it goes back to the
> SC instruction. The SC instruction took an exception so it will not have
> changed $1 so the loop will continue endless unless by coincidence the
> value to be stored from $1 happened to be zero.
>
> Obviously this one was MIPS specific and may hit all supported ABIs. So
> my initial suspicion this might be the issue David Miller recently
> discovered in the binary compat code isn't true. And it's a local DoS
> probably for all of 2.6.16 and up.
>
I mostly similar code is in 2.6.15, so I think it is effected as well.
2.6.12 on the other hand doesn't seem to have futex.h
David Daney
^ permalink raw reply
* RE: futex_wake_op deadlock?
From: Kaz Kylheku @ 2007-11-20 18:24 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20071120112051.GB30675@linux-mips.org>
Ralf Baechle wrote:
> Patch below. It fixes your test case on a 32-bit kernel for me.
I'm running it now on 64 bit. The test case isn't causing any ill
effects.
Thanks a lot, Ralf!
^ permalink raw reply
* RE: futex_wake_op deadlock?
From: Kaz Kylheku @ 2007-11-20 18:24 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20071120112051.GB30675@linux-mips.org>
Ralf Baechle wrote:
> Patch below. It fixes your test case on a 32-bit kernel for me.
I'm running it now on 64 bit. The test case isn't causing any ill
effects.
Thanks a lot, Ralf!
^ permalink raw reply
* Re: futex_wake_op deadlock?
From: Ralf Baechle @ 2007-11-20 18:16 UTC (permalink / raw)
To: Kaz Kylheku; +Cc: linux-mips
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C54DCF9F@exchange.ZeugmaSystems.local>
On Tue, Nov 20, 2007 at 10:06:44AM -0800, Kaz Kylheku wrote:
> The problem is I didn't pay enough attention because I didn't suspect it
> enough.
>
> I was misled by the backtrace address in the soft lockup dump, which
> points to one instruction /before/ the ll instruction. So I thought that
> the lockup is somewhere outside of that loop, right?
>
> Does the backward branch on MIPS set up the instruction pointer in such
> a way that if an interrupt goes off, it can be pointing to the previous
> instruction? I thought about that possibility.
The EPC will always point to the instruction which caused the exception
with the one special case where an instruction in a branch delay slot
was causing the exception. If that's the case the EPC will point at the
branch and the BD bit in the cause register (bit 31) will be set to
indicate this special case.
Ralf
^ permalink raw reply
* RE: futex_wake_op deadlock?
From: Kaz Kylheku @ 2007-11-20 18:06 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20071120112051.GB30675@linux-mips.org>
Ralf Baechle wrote:
> __asm__ __volatile__(
> " .set push \n"
> " .set noat \n"
> " .set mips3 \n"
> "1: ll %1, %4 # __futex_atomic_op \n"
> " .set mips0 \n"
> " " insn " \n"
> " .set mips3 \n"
> "2: sc $1, %2 \n"
> " beqz $1, 1b \n"
> __WEAK_LLSC_MB "3:
> \n" " .set pop \n"
> " .set mips0 \n"
> " .section .fixup,\"ax\" \n"
> "4: li %0, %6 \n"
> " j 2b \n" <-----
> " .previous \n"
> " .section __ex_table,\"a\" \n"
> " "__UA_ADDR "\t1b, 4b \n"
> " "__UA_ADDR "\t2b, 4b \n"
> " .previous \n"
> : "=r" (ret), "=&r" (oldval), "=R" (*uaddr)
> : "0" (0), "R" (*uaddr), "Jr" (oparg), "i" (-EFAULT)
> : "memory");
>
> Notice the branch at the end of the fixup code, it goes back to the
> SC instruction.
Hi Ralf,
I had gone through all that code, but didn't see it!
The problem is I didn't pay enough attention because I didn't suspect it
enough.
I was misled by the backtrace address in the soft lockup dump, which
points to one instruction /before/ the ll instruction. So I thought that
the lockup is somewhere outside of that loop, right?
Does the backward branch on MIPS set up the instruction pointer in such
a way that if an interrupt goes off, it can be pointing to the previous
instruction? I thought about that possibility.
^ permalink raw reply
* RE: futex_wake_op deadlock?
From: Kaz Kylheku @ 2007-11-20 18:06 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20071120112051.GB30675@linux-mips.org>
Ralf Baechle wrote:
> __asm__ __volatile__(
> " .set push \n"
> " .set noat \n"
> " .set mips3 \n"
> "1: ll %1, %4 # __futex_atomic_op \n"
> " .set mips0 \n"
> " " insn " \n"
> " .set mips3 \n"
> "2: sc $1, %2 \n"
> " beqz $1, 1b \n"
> __WEAK_LLSC_MB "3:
> \n" " .set pop \n"
> " .set mips0 \n"
> " .section .fixup,\"ax\" \n"
> "4: li %0, %6 \n"
> " j 2b \n" <-----
> " .previous \n"
> " .section __ex_table,\"a\" \n"
> " "__UA_ADDR "\t1b, 4b \n"
> " "__UA_ADDR "\t2b, 4b \n"
> " .previous \n"
> : "=r" (ret), "=&r" (oldval), "=R" (*uaddr)
> : "0" (0), "R" (*uaddr), "Jr" (oparg), "i" (-EFAULT)
> : "memory");
>
> Notice the branch at the end of the fixup code, it goes back to the
> SC instruction.
Hi Ralf,
I had gone through all that code, but didn't see it!
The problem is I didn't pay enough attention because I didn't suspect it
enough.
I was misled by the backtrace address in the soft lockup dump, which
points to one instruction /before/ the ll instruction. So I thought that
the lockup is somewhere outside of that loop, right?
Does the backward branch on MIPS set up the instruction pointer in such
a way that if an interrupt goes off, it can be pointing to the previous
instruction? I thought about that possibility.
^ permalink raw reply
* Re: how to use memory before kernel load address?
From: Atsushi Nemoto @ 2007-11-20 13:44 UTC (permalink / raw)
To: ths; +Cc: zzh.hust, linux-mips
In-Reply-To: <20071120130451.GI11996@networkno.de>
On Tue, 20 Nov 2007 13:04:51 +0000, Thiemo Seufer <ths@networkno.de> wrote:
> > i have try to pass param as mem=1M@1M mem=16M@16M to the kernel,
> > it seems only take the 0x8000000 ~ kernel_end as reserved.
> > is there any other options to set the memory useable? ( my kernel
> > version is 2.6.14)
> > thanks for any hints
>
> AFAIR the kernel assumes to occupy the lowest addresses of the usable RAM.
You can use prom_free_prom_memory() to give some low pages back to kernel.
---
Atsushi Nemoto
^ permalink raw reply
* Re: how to use memory before kernel load address?
From: Thiemo Seufer @ 2007-11-20 13:04 UTC (permalink / raw)
To: zhuzhenhua; +Cc: linux-mips
In-Reply-To: <50c9a2250711191706g40744ab2w2027124c4bc8dbbb@mail.gmail.com>
zhuzhenhua wrote:
> hello,all
> i want to place my kernel loadaddr=0x81008000 and set
> EBASE=0x81000000, it workes.
> but there is still some memory usable before 0x81000000, for
> example from 0x80100000 ~ 0x80200000
The obvious thing to do seems to set LOARADDR to 0x80208000.
> i have try to pass param as mem=1M@1M mem=16M@16M to the kernel,
> it seems only take the 0x8000000 ~ kernel_end as reserved.
> is there any other options to set the memory useable? ( my kernel
> version is 2.6.14)
> thanks for any hints
AFAIR the kernel assumes to occupy the lowest addresses of the usable RAM.
Thiemo
^ permalink raw reply
* Re: [SPAM] Re: IP22 64Bit arcboot - current git crashes on 3 machines at different points
From: Ralf Baechle @ 2007-11-20 11:39 UTC (permalink / raw)
To: Markus Gothe; +Cc: Florian Lohoff, linux-mips
In-Reply-To: <775F4404-2D0A-4E65-9401-E2193B96DBDC@27m.se>
On Tue, Nov 20, 2007 at 03:49:07AM +0100, Markus Gothe wrote:
> Afaik R4x00 is just semi-64bit in contrast to the R5K, which derives from
> the R10K.
Total rubbish. The R4x00 family hardly is a family but just happens to
have similar type numbers.
o R4000/R4400 are very close related, 64-bit databus
o R4100, R4200, R4300 series only have 32-bit databus and are low end
embedded stuff. All these have 32-bit external busses only.
o R4600 was designed by Qed shortly after the R4000 was developed by
MIPS. It has a much shorted pipeline, consumes less power and performs
better except for the most heavy FP apps. The R4700 is a slightly
improved version of the R4600 and catches up on FP too but was rarely
used.
o R5000 has alot of similarities to the R4600/R4700 and was also designed
by QED. Not sure if it really should be considered a derivate of these.
The RM7000 and RM9000 family eventually continued this line of evolution.
o R10000 is a no-prisoners-taken from scratch OOO CPU design released in
'94 and to become SGI's highend processor. The architecture is
aggressive to the point where it even today looks complex - but that
also means that the R10000 implementation have hardly any similarity
with their predecessors. The R12000 is a slightly beefed up shrink of
the R10000, the R14000 is the same to the R12000 and the R16000 is one
more shrink. Conventional wisdom is that the 2nd shrink already going
to return diminishing returns but it seems to have worked for SGI.
And of course all these are are MIPS III/MIPS IV processors, so modulo
bugs and sanity fully 64-bit software capable.
Ralf
^ permalink raw reply
* Re: futex_wake_op deadlock?
From: Ralf Baechle @ 2007-11-20 11:21 UTC (permalink / raw)
To: Kaz Kylheku; +Cc: linux-mips
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C54DCDE2@exchange.ZeugmaSystems.local>
On Mon, Nov 19, 2007 at 01:27:37PM -0800, Kaz Kylheku wrote:
> >> From time to time, on 2.6.17.7, I see a deadlock situation go off.
> >> The soft lockup tick occurs in the middle of do_futex, which is
> >> heavily inlined. The system is actually hosed; it's not one of those
> >> recoverable CPU busy situations that can sometimes trigger the lockup
> >> detector.
> >
> > Can you reproduce thing hang also if you're not running in a
> > binary compat
> > mode, that is either running o32 binaries on a 32-bit kernel or
> > 64-bit binaries on a 64-bit kernel?
>
> I have hacked up little a test program which hosed my board within
> seconds.
> The system is not completely hung. However:
Cute. So looking again at the futex code this morning it was quite
obvious what happened. The ll/sc loops in __futex_atomic_op() had the
usual fixups necessary for memory acccesses to userspace from kernel
space installed:
__asm__ __volatile__(
" .set push \n"
" .set noat \n"
" .set mips3 \n"
"1: ll %1, %4 # __futex_atomic_op \n"
" .set mips0 \n"
" " insn " \n"
" .set mips3 \n"
"2: sc $1, %2 \n"
" beqz $1, 1b \n"
__WEAK_LLSC_MB
"3: \n"
" .set pop \n"
" .set mips0 \n"
" .section .fixup,\"ax\" \n"
"4: li %0, %6 \n"
" j 2b \n" <-----
" .previous \n"
" .section __ex_table,\"a\" \n"
" "__UA_ADDR "\t1b, 4b \n"
" "__UA_ADDR "\t2b, 4b \n"
" .previous \n"
: "=r" (ret), "=&r" (oldval), "=R" (*uaddr)
: "0" (0), "R" (*uaddr), "Jr" (oparg), "i" (-EFAULT)
: "memory");
Notice the branch at the end of the fixup code, it goes back to the
SC instruction. The SC instruction took an exception so it will not have
changed $1 so the loop will continue endless unless by coincidence the
value to be stored from $1 happened to be zero.
Obviously this one was MIPS specific and may hit all supported ABIs. So
my initial suspicion this might be the issue David Miller recently
discovered in the binary compat code isn't true. And it's a local DoS
probably for all of 2.6.16 and up.
Patch below. It fixes your test case on a 32-bit kernel for me.
Ralf
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
diff --git a/include/asm-mips/futex.h b/include/asm-mips/futex.h
index 3e7e30d..17f082c 100644
--- a/include/asm-mips/futex.h
+++ b/include/asm-mips/futex.h
@@ -35,7 +35,7 @@
" .set mips0 \n" \
" .section .fixup,\"ax\" \n" \
"4: li %0, %6 \n" \
- " j 2b \n" \
+ " j 3b \n" \
" .previous \n" \
" .section __ex_table,\"a\" \n" \
" "__UA_ADDR "\t1b, 4b \n" \
@@ -61,7 +61,7 @@
" .set mips0 \n" \
" .section .fixup,\"ax\" \n" \
"4: li %0, %6 \n" \
- " j 2b \n" \
+ " j 3b \n" \
" .previous \n" \
" .section __ex_table,\"a\" \n" \
" "__UA_ADDR "\t1b, 4b \n" \
^ permalink raw reply related
* Re: Usage of mmap command
From: Denis Oliver Kropp @ 2007-11-20 10:42 UTC (permalink / raw)
To: kaka
Cc: linux-mips, uclinux-dev, celinux-dev, linux-fbdev-users,
directfb-users, directfb-dev
In-Reply-To: <eea8a9c90711200140w46bda8cek6ee1a1817db9ae0d@mail.gmail.com>
kaka wrote:
> Hi Denis,
>
> Thanks for the reply.
> I am writing gfxdriver for directFB library for broadcom chip.
> I have also written a frambuffer driver for broadcom chip.
Directly for broadcom or at another company?
> In directFB code,
>
> static volatile void *
> system_map_mmio( unsigned int offset,
> int length )
> {
> void *addr;
>
> if (length <= 0)
> length = dfb_fbdev->shared->fix.mmio_len;
>
> addr = mmap( NULL, length, PROT_READ | PROT_WRITE, MAP_SHARED,
> dfb_fbdev->fd, dfb_fbdev->shared->fix.smem_len + offset );
> if ((int)(addr) == -1) {
> D_PERROR( "DirectFB/FBDev: Could not mmap MMIO region "
> "(offset %d, length %d)!\n", offset, length );
> return NULL;
> }
>
> return(volatile void*) ((u8*) addr + (dfb_fbdev->shared->fix.mmio_start&
> dfb_fbdev->shared->page_mask));
> }
Can you add printfs to show dfb_fbdev->shared->fix.mmio_start, mmio_len,
smem_start and smem_len?
> the length and offset i am providing as 0 and -1.
You mean offset 0 and length -1?
> It is throwing me error as Could not mmap MMIO region.
> length coming from dfb_fbdev->shared->fix.smem_len is 16,00,000.
1600000 = 1.6MB?
> When i change the code to addr = mmap( NULL, 900000, PROT_READ |
> PROT_WRITE, MAP_SHARED, dfb_fbdev->fd, dfb_fbdev->shared->fix.smem_len +
> offset );
You changed the length to 900000, but you need to use this to map offset
900000:
addr = mmap( NULL, length, PROT_READ | PROT_WRITE, MAP_SHARED,
dfb_fbdev->fd, 900000 );
But it should work if you set smem_len to 900000 in the fb driver.
> Then it works fine but it is not allowing me to write to addresses with
> offset greater than 900000.
Segfault?
> My requirement is to write in to the MMIO registers with offset between
> 900000 and 16 00 000.
What exactly is your frame buffer size and physical MMIO address?
You need to put the frame buffer size into smem_len and the physical
MMIO address into mmio_start, the length into mmio_len.
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
^ permalink raw reply
* Usage of mmap command
From: kaka @ 2007-11-20 9:40 UTC (permalink / raw)
To: Denis Oliver Kropp
Cc: linux-mips, uclinux-dev, celinux-dev, linux-fbdev-users,
directfb-users, directfb-dev
In-Reply-To: <47429AEF.3010403@directfb.org>
[-- Attachment #1: Type: text/plain, Size: 2467 bytes --]
Hi Denis,
Thanks for the reply.
I am writing gfxdriver for directFB library for broadcom chip.
I have also written a frambuffer driver for broadcom chip.
In directFB code,
static volatile void *
system_map_mmio( unsigned int offset,
int length )
{
void *addr;
if (length <= 0)
length = dfb_fbdev->shared->fix.mmio_len;
addr = mmap( NULL, length, PROT_READ | PROT_WRITE, MAP_SHARED,
dfb_fbdev->fd, dfb_fbdev->shared->fix.smem_len + offset );
if ((int)(addr) == -1) {
D_PERROR( "DirectFB/FBDev: Could not mmap MMIO region "
"(offset %d, length %d)!\n", offset, length );
return NULL;
}
return(volatile void*) ((u8*) addr + (dfb_fbdev->shared->fix.mmio_start&
dfb_fbdev->shared->page_mask));
}
the length and offset i am providing as 0 and -1.
It is throwing me error as Could not mmap MMIO region.
length coming from dfb_fbdev->shared->fix.smem_len is 16,00,000.
When i change the code to addr = mmap( NULL, 900000, PROT_READ |
PROT_WRITE, MAP_SHARED, dfb_fbdev->fd, dfb_fbdev->shared->fix.smem_len +
offset );
Then it works fine but it is not allowing me to write to addresses with
offset greater than 900000.
My requirement is to write in to the MMIO registers with offset between
900000 and 16 00 000.
Could you please help me in htis regard?
Thanks in Advance.
On 11/20/07, Denis Oliver Kropp <dok@directfb.org> wrote:
>
> kaka wrote:
> > Hi All,
> >
> > void *mmap(void *start, size_t length, int prot, int flags,
> int
> > fd, off_t offset);
> >
> > I am providing 16,00,000 as length parameter in mmap command.
> > It is giving me error as Can't mmap region. on the other hand when i am
> > providing 9,00,000 as length parameter in mmap command.
> > It is successful.
> > This mmap command is being issued from User space.
> >
> > On the other hand in the framebuffer driver in the kernel spce i have
> > specified the length of mmio in the ioremap as 16,00,000.
>
> The ioremap() is independent of the values propagated to user space
> and fbmem.c via fix.mmio_start and fix.mmio_len, please check these.
>
> --
> Best regards,
> Denis Oliver Kropp
>
> .------------------------------------------.
> | DirectFB - Hardware accelerated graphics |
> | http://www.directfb.org/ |
> "------------------------------------------"
>
--
Thanks & Regards,
kaka
[-- Attachment #2: Type: text/html, Size: 4219 bytes --]
^ permalink raw reply
* Re: [directfb-dev] Usage of mmap command
From: Denis Oliver Kropp @ 2007-11-20 8:29 UTC (permalink / raw)
To: kaka
Cc: linux-mips, uclinux-dev, celinux-dev, linux-fbdev-users,
directfb-users, directfb-dev
In-Reply-To: <eea8a9c90711192239q6009cbb8y76790fa73bc4a5b7@mail.gmail.com>
kaka wrote:
> Hi All,
>
> void *mmap(void *start, size_t length, int prot, int flags, int
> fd, off_t offset);
>
> I am providing 16,00,000 as length parameter in mmap command.
> It is giving me error as Can't mmap region. on the other hand when i am
> providing 9,00,000 as length parameter in mmap command.
> It is successful.
> This mmap command is being issued from User space.
>
> On the other hand in the framebuffer driver in the kernel spce i have
> specified the length of mmio in the ioremap as 16,00,000.
The ioremap() is independent of the values propagated to user space
and fbmem.c via fix.mmio_start and fix.mmio_len, please check these.
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
^ permalink raw reply
* Re: [SPAM] Re: IP22 64Bit arcboot - current git crashes on 3 machines at different points
From: Thomas Bogendoerfer @ 2007-11-20 8:18 UTC (permalink / raw)
To: Markus Gothe; +Cc: Ralf Baechle, Florian Lohoff, linux-mips
In-Reply-To: <775F4404-2D0A-4E65-9401-E2193B96DBDC@27m.se>
On Tue, Nov 20, 2007 at 03:49:07AM +0100, Markus Gothe wrote:
> Afaik R4x00 is just semi-64bit in contrast to the R5K, which derives
> from the R10K.
how about reading documents ? Early R4k have ugly bugs in 64bit mode,
but starting with rev5 they run 64bit code pretty well. And R5k does
in no way derive from R10k.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Usage of mmap command
From: kaka @ 2007-11-20 6:39 UTC (permalink / raw)
To: linux-mips, uclinux-dev, celinux-dev, linux-fbdev-users
Cc: directfb-users, directfb-dev
[-- Attachment #1: Type: text/plain, Size: 617 bytes --]
Hi All,
void *mmap(void *start, size_t length, int prot, int flags, int
fd, off_t offset);
I am providing 16,00,000 as length parameter in mmap command.
It is giving me error as Can't mmap region. on the other hand when i am
providing 9,00,000 as length parameter in mmap command.
It is successful.
This mmap command is being issued from User space.
On the other hand in the framebuffer driver in the kernel spce i have
specified the length of mmio in the ioremap as 16,00,000.
Can anybody provide any clue on it?
I want to access the mmio regs at offset ( 0 to 16,00,000).
--
Thanks & Regards,
kaka
[-- Attachment #2: Type: text/html, Size: 872 bytes --]
^ permalink raw reply
* Re: smp8634 add memory at dram1
From: David Kuk @ 2007-11-20 4:22 UTC (permalink / raw)
To: David Daney; +Cc: linux-mips
In-Reply-To: <473B1DD0.2090903@avtrex.com>
[-- Attachment #1: Type: text/plain, Size: 2776 bytes --]
Thanks you all for helping.
AS Daney suggested, I have map the dram1's first 64 MB memory (total 128) to
remap register 3,
and add the remap register 3 into the BOOT_MEMROY_RAM use the method
add_memory_region.
When i bootup the linux kernel print out that it have totally 176MB ram ,
which is 06fe0000@10020000(dram0) and 04000000@08000000(64mb dram1 at remap
register3). How ever, This mapping shows that the total memory in the linux
kernel is not contiguous. the OS can run, but as i see the source code, when
the kernel divided these memory into pages, it did not consider if the
memory is contiguous or not, is it ok ? and how should i allocate the
memories into ZONE[DMA] and ZONE[NORMAL], is it possible if I wish all the
176MB memory can be allocate as ZONE[DMA]?
Best wishes
David
On 11/15/07, David Daney <ddaney@avtrex.com> wrote:
>
> David Kuk wrote:
> > After study about the memory configuration of sigma smp8634, i found
> > some difficult to accomplish the task.
> >
> > so my question is if have two 128MB ram separately under dram0 and
> > dram1 controller, where dram0 for linux and dram1 for video decoding.
> > Now the situation is the memory for linux is not enough and video
> > decoding can not use all of it's 128MB at dram1, what we plan to do is
> > to share 64MB at dram1 to the linux kernel as high memory, and only
> > reserved 64MB at dram1 for the video decoding.
> >
> > first, in MIPS architecture, we found that the kseg0 and kseg1 are
> > mapped to 0x00000000-0x20000000, which include only dram0 controller,
> > so we wish to add the dram1 memory manually to the kernel using
> > function add_memory_region at setup.c , after booting up result the
> > warning that the memory larger than 512 need to configured the kernel
> > support high memory.
> >
> > then when we configure the kernel to support high memory at menu
> > configure, the kernel when booting up will remind us our CPU do not
> > support high memory due to cache aliases.
> >
> > Both way will lead the linux can not boot up normally, so what should
> > we do, is there any mis-understanding about the hardware
> > implementation or MIPS design?
>
> I think your understanding of the 8634 is at least close to correct.
>
> It may be possible (but I have not tried it yet) to use the remapping
> registers to move dram1 into the first 512MB of the memory space. If it
> is possible, you would then have to modify the gbus access functions
> accordingly. Also the 8634 media drivers would probably have to be
> changed as well. I am not sure about the microcode for the media DSPs,
> but if it is dependent on the mapping of the DRAM, then you would
> probably have to get the vendor's help.
>
> Let me know if you are successful.
>
> Thanks,
> David Daney
>
>
[-- Attachment #2: Type: text/html, Size: 3266 bytes --]
^ permalink raw reply
* Re: [SPAM] how to use memory before kernel load address?
From: Markus Gothe @ 2007-11-20 2:51 UTC (permalink / raw)
To: zhuzhenhua; +Cc: linux-mips
In-Reply-To: <50c9a2250711191706g40744ab2w2027124c4bc8dbbb@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 622 bytes --]
Are you using a MTD, if so just create a partition there.
//Markus
On 20 Nov 2007, at 02:06, zhuzhenhua wrote:
> hello,all
> i want to place my kernel loadaddr=0x81008000 and set
> EBASE=0x81000000, it workes.
> but there is still some memory usable before 0x81000000,
> for example from 0x80100000 ~ 0x80200000
> i have try to pass param as mem=1M@1M mem=16M@16M to the
> kernel, it seems only take the 0x8000000 ~ kernel_end as reserved.
> is there any other options to set the memory useable? ( my
> kernel version is 2.6.14)
> thanks for any hints
>
>
> zzh
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [SPAM] Re: IP22 64Bit arcboot - current git crashes on 3 machines at different points
From: Markus Gothe @ 2007-11-20 2:49 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Florian Lohoff, linux-mips
In-Reply-To: <20071119193137.GA27317@linux-mips.org>
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
Afaik R4x00 is just semi-64bit in contrast to the R5K, which derives
from the R10K.
//Markus
On 19 Nov 2007, at 20:31, Ralf Baechle wrote:
> On Mon, Nov 19, 2007 at 05:09:54PM +0100, Florian Lohoff wrote:
>
>> i am seeing strange issues with 64 Bit kernels IP22 on different
>> machines. This came up when i tried the debian distribution kernel
>> which fails for me on 2 machines.
>
> I still haven't sorted out all the workarounds for the read-from-
> compare
> bug in early R4000 / R4400 with the new time code. It may not be the
> issue that's hitting you but the new time code definately has the
> potencial
> to trigger the issue.
>
> Ralf
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* [PATCH 02/59] arch/mips: Add missing "space"
From: Joe Perches @ 2007-11-20 1:47 UTC (permalink / raw)
To: linux-kernel; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <ee1678e1bc8b80b7ae420059fffc7241486ea91a.1195454434.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
arch/mips/kernel/vpe.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/kernel/vpe.c b/arch/mips/kernel/vpe.c
index 38bd33f..c06eb81 100644
--- a/arch/mips/kernel/vpe.c
+++ b/arch/mips/kernel/vpe.c
@@ -470,7 +470,7 @@ static int apply_r_mips_lo16(struct module *me, uint32_t *location,
*/
if (v != l->value) {
printk(KERN_DEBUG "VPE loader: "
- "apply_r_mips_lo16/hi16: "
+ "apply_r_mips_lo16/hi16: \t"
"inconsistent value information\n");
return -ENOEXEC;
}
@@ -629,7 +629,7 @@ static void simplify_symbols(Elf_Shdr * sechdrs,
break;
case SHN_MIPS_SCOMMON:
- printk(KERN_DEBUG "simplify_symbols: ignoring SHN_MIPS_SCOMMON"
+ printk(KERN_DEBUG "simplify_symbols: ignoring SHN_MIPS_SCOMMON "
"symbol <%s> st_shndx %d\n", strtab + sym[i].st_name,
sym[i].st_shndx);
// .sbss section
--
1.5.3.5.652.gf192c
^ permalink raw reply related
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