* Re: PPC 32bits and big RAM mapping problem
From: Matt Porter @ 2005-12-01 18:56 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B8594B6@ismail.innsys.innovsys.com>
On Thu, Dec 01, 2005 at 12:43:02PM -0600, Rune Torgersen wrote:
> > -----Original Message-----
> > From: Laurent Lagrange
> > Sent: Thursday, December 01, 2005 11:48
> > To: linuxppc-embedded@ozlabs.org
> > Subject: PPC 32bits and big RAM mapping problem
>
> > So I'm under the impression to be cornered in my shoes.
> > Any idea, book, article, prediction would be welcome.
>
> I have 2GB of ram working on my PPC32 board.
>
> You have to change the following in the kernel config:
> Under Advanced Setup:
> Set Maximum Low memory (Set to 0x40000000)
> Set Custom Kernel config address (Set to 0xA0000000)
>
> I do not remember if I had to change anything else.
If you have 2GB you had to have something else. Right now
you have it set to constrict the max lowmem to 1GB. So,
you must have CONFIG_HIGHMEM on as well to utilize the
other 1GB.
To answer the original poster's question: simply enable
CONFIG_HIGHMEM and UP system will have 768MB in lowmem and
the rest in highmem. If there's some constraint on your
application (like many embedded apps) that requires all
2GB in lowmem then configure:
Set Maximum low memory (Set to 0x80000000)
Set custom kernel base address (Set to 0x40000000)
Set custom user task size (Set to 0x40000000)
Don't do this unless highmem won't work for your app. If you
use this approach each process will be limited to 1GB of virtual
memory which may or may not be an OK tradeoff for your app.
-Matt
^ permalink raw reply
* [PATCH] powerpc: correct the NR_CPUS description text
From: Olaf Hering @ 2005-12-01 20:10 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Update the help text to match the allowed range.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/Kconfig | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.15-rc4-olh/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.15-rc4-olh.orig/arch/powerpc/Kconfig
+++ linux-2.6.15-rc4-olh/arch/powerpc/Kconfig
@@ -227,7 +227,7 @@ config SMP
If you don't know what to do here, say N.
config NR_CPUS
- int "Maximum number of CPUs (2-32)"
+ int "Maximum number of CPUs (2-128)"
range 2 128
depends on SMP
default "32" if PPC64
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: [PATCH] powerpc: correct the NR_CPUS description text
From: Geert Uytterhoeven @ 2005-12-01 20:14 UTC (permalink / raw)
To: Olaf Hering, Roman Zippel; +Cc: Linux/PPC Development, Linux Kernel Development
In-Reply-To: <20051201201010.GA2741@suse.de>
On Thu, 1 Dec 2005, Olaf Hering wrote:
> Update the help text to match the allowed range.
>
> Signed-off-by: Olaf Hering <olh@suse.de>
>
> arch/powerpc/Kconfig | 2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6.15-rc4-olh/arch/powerpc/Kconfig
> ===================================================================
> --- linux-2.6.15-rc4-olh.orig/arch/powerpc/Kconfig
> +++ linux-2.6.15-rc4-olh/arch/powerpc/Kconfig
> @@ -227,7 +227,7 @@ config SMP
> If you don't know what to do here, say N.
>
> config NR_CPUS
> - int "Maximum number of CPUs (2-32)"
> + int "Maximum number of CPUs (2-128)"
> range 2 128
> depends on SMP
> default "32" if PPC64
Shouldn't kconfig (be enhanced to) add the range to the help text
automatically, to avoid problems like this?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* RE: PPC 32bits and big RAM mapping problem
From: Rune Torgersen @ 2005-12-01 20:18 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
> -----Original Message-----
> From: Matt Porter [mailto:mporter@kernel.crashing.org]=20
> Sent: Thursday, December 01, 2005 12:56
> If you have 2GB you had to have something else. Right now
> you have it set to constrict the max lowmem to 1GB. So,
> you must have CONFIG_HIGHMEM on as well to utilize the
> other 1GB.
Ahh.. Yep, have CONFIG_HIGHMEM set.
I only did 1G of kernel low mem, so that there still would be space left
for vmalloc mappings.
I have a 8265 witch uses 0xf0000000 and up for internal stuff and flash,
so with 1G lowmem and kernel baseadr set to 0xa.... I have 0xe0000000 to
0xeffffffff for virtual address space.
I do not remember if I had to patch some other parts of the kernel also.
I do not think I did.
Can't chech right now either, because we used bitkeeper and I cannot
even check the commit logs anymore.
^ permalink raw reply
* [PATCH] powerpc: hide CONFIG_ALTIVEC on iSeries
From: Olaf Hering @ 2005-12-01 20:46 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Do not offer CONFIG_ALTIVEC for legacy iSeries. They predate the 970.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/Kconfig | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.15-rc4-olh/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.15-rc4-olh.orig/arch/powerpc/Kconfig
+++ linux-2.6.15-rc4-olh/arch/powerpc/Kconfig
@@ -169,7 +169,7 @@ config PHYS_64BIT
config ALTIVEC
bool "AltiVec Support"
- depends on 6xx || POWER4
+ depends on (6xx || POWER4) && !PPC_ISERIES
---help---
This option enables kernel support for the Altivec extensions to the
PowerPC processor. The kernel currently supports saving and restoring
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: [PATCH] ppc boot: replace string labels with numbers
From: Tom Rini @ 2005-12-01 21:58 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20051117210902.GB31775@suse.de>
On Thu, Nov 17, 2005 at 10:09:02PM +0100, Olaf Hering wrote:
> Replacing the string labels with numbers saves 117 bytes in the final zImage.
> These local labels are not discared.
>
> Signed-off-by: Olaf Hering <olh@suse.de>
And kicks easy-understanding right in the, somethings...
NAK. If it's not too late, of course (vacation catchup is fun!)
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] powerpc: hide CONFIG_ALTIVEC on iSeries
From: Paul Mackerras @ 2005-12-01 22:25 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20051201204632.GA3764@suse.de>
Olaf Hering writes:
> Do not offer CONFIG_ALTIVEC for legacy iSeries. They predate the 970.
I am still hoping that we will get to the point of being able to build
a single binary kernel for both iSeries and the rest (pSeries, pmac,
etc.). If we put in this patch then we'll undoubtedly forget to take
it back out when we do get to the single binary kernel.
Does it cause any actual problem to have CONFIG_ALTIVEC offered on
legacy iSeries?
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc: hide CONFIG_ALTIVEC on iSeries
From: Olaf Hering @ 2005-12-01 22:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17295.30816.292109.714074@cargo.ozlabs.ibm.com>
On Fri, Dec 02, Paul Mackeras wrote:
> Does it cause any actual problem to have CONFIG_ALTIVEC offered on
> legacy iSeries?
Its just an unneeded question when running oldconfig on an older .config
for iseries. I cant test if it causes any trouble.
CPU_FREQ is similar, but I dont see an easy way to hide it.
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: AmigaOne 2.6.x Linux kernel port
From: Benjamin Herrenschmidt @ 2005-12-01 23:58 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <21714.1133476127@www44.gmx.net>
> As far as I can understand you refer to the non cocherent DMA memory
> allocation functions in arch/ppc/kernel/dma-mapping.c, right? Regarding the
> BAT mapping: can you give me an example for this or a link to a reference
> implementation?, because I'm afraid I can only image for now, what you're
> trying to explane me (as I said, I'm a kernel newbie, but I'll try to do
> what I can). :-)
(I'm moving this to the linuxppc-dev list)
Well, you need consistent alloc functions to really provide you with
non-cached memory. Fushing is not enough. Flushing is fine for dma_map
etc..., not for consistent alloc.
So in theory, you should be able to re-use the existing consistent
allocation functions, except that the current implementation has
"issues":
The main problem I see with the implementation is that it just allocates
pages out of the normal kernel allocator and maps them in the
"consistent" virtual range without ever unmapping them from the kernel
linear mapping. That means that those pages end up being mapped twice:
cacheable and non-cacheable, which is absolutely wrong and will explode
in colorful ways on a number of CPUs. The pages should at least be
unmapped from the kernel linear (& cacheable) mapping.
I understand this is probably done to keep the TLB miss handler for the
kernel mapping as fast as possible. Unfortunately, it's also incorrect
if your processor is capable of any kind of prefetching accross a 4k
boundary.
Then, remains the BAT mapping problem. In order to improve performances,
the kernel uses BATs to map the main memory (to know more about BATs,
look at the proccessor docs). That means that unmapping the memory from
the linear mapping will not work if that memory happens to be covered by
a BAT (there aren't even page tables entries for those pages anyway).
Thus, in order to be able to reliably unmap things from the linear
mapping (or individually change page attributes) you need to disable BAT
mapping of memory, either completely, or by preallocating (and thus
actually reserving) memory outside of the BAT mapping for use in the
consistent allocator.
However, the exception handling of the kernel is designed with the
assumption that it will not take hash faults in some critical locations,
and this assumption is correct thanks to ... the BAT mapping. You are
lucky though that recent kernels have been fixed to be able to recover
from such faults provided the instructions are still BAT mapped, so you
can probably hack the initialisation of the memory on ppc to not use
data BATs but only instruction BATs and still create the page tables for
the entire memory. That will allow you to implement proper unmapping of
pages in the consistent allocator. However, it will also impact your
overall performances ...
Ben.
^ permalink raw reply
* Can I operate i2c device in a tasklet?
From: Sam Song @ 2005-12-02 6:20 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I found that once I operated i2c bus like
read from i2c device in 2.4.31 kernl in a
interrupt handler or tasklet, kernel panic
would happen. Is there any way to make it
in such case? I need to write sth on RTC
alarm register with an interrupt event.
......
Scheduling in interrupt
kernel BUG at sched.c:564!
Oops: Exception in kernel mode, sig: 4
NIP: C0011F98 XER: 00000000 LR: C0011F98
SP: C0236010 REGS: c0235f60 TRAP: 0700
Not tainted
MSR: 00081032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c0234470[0] 'swapper' Last syscall: 120
last math c7e98000 last altivec 00000000
GPR00: C0011F98 C0236010 C0234470 0000001B
00001032 00000001 F0000000 00000000
GPR08: C7A8D060 C0290000 C0269BD7 C0235F20
0000000D 10041C70 08000000 007FFF5E
GPR16: 00000000 00000000 007FFF00 07FFA3AC
00001032 00236340 C0290000 C0270000
GPR24: C0230000 C0230000 F0000100 F0011860
00000000 00000000 C0267F28 C0236010
Call backtrace:
C0011F98 C0012430 C0156970 C0156CA4
C01531E0 C0153F68 C01541CC
C0153BBC C01570B4 C016D7AC C0006D78
C0006E34 C0005CE0 C0007360
C000737C C0003978 C02755B0 000035F0
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
<0>Rebooting in 1 seconds..
TIA,
Sam
___________________________________________________________
雅虎免费G邮箱－中国第一绝无垃圾邮件骚扰超大邮箱
http://cn.mail.yahoo.com
^ permalink raw reply
* SIGSEV in user mode
From: Redondo Garcia, Roberto @ 2005-12-02 7:36 UTC (permalink / raw)
To: linuxppc-embedded
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1435 bytes --]
hello,
I have a program that when it has been several hours executing, it has a
problem and falls and it produces a SIGSEGV. I would like to know to
how debug this error, because I do not have ulimit for generate core
dump
thanks
-------------------------------------------------------------------------------------------------------------------
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, contiene información de carácter confidencial exclusivamente dirigida a su destinatario o destinatarios. Queda prohibida su divulgación, copia o distribución a terceros sin la previa autorización escrita de Indra. En el caso de haber recibido este correo electrónico por error, se ruega notificar inmediatamente esta circunstancia mediante reenvío a la dirección electrónica del remitente. POR FAVOR, ANTES DE IMPRIMIR ESTE CORREO ELECTRÓNICO CONSIDERE SU APORTACIÓN A LA CONSERVACIÓN DEL MEDIO AMBIENTE POR LA REDUCCIÓN DE CONSUMO DE PAPEL.
The information in this e-mail and in any attachments is confidential and solely for the attention and use of the named addressee(s). You are hereby notified that any dissemination, distribution or copy of this communication is prohibited without the prior written consent of Indra. If you have received this communication in error, please, notify the sender by reply e-mail. PLEASE CONSIDER YOUR ENVIRONMENTAL RESPONSIBILITY BEFORE PRINTING THIS E-MAIL.
[-- Attachment #2: Type: text/html, Size: 2097 bytes --]
^ permalink raw reply
* [PATCH 2.6.15-rc4] ppc32: Fixes for non-zero PPC_MEMSTART on PPC440
From: Jason Gunthorpe @ 2005-12-02 8:07 UTC (permalink / raw)
To: linuxppc-embedded
I have a custom embedded system with a 440GP derived CPU that places the
memory starting at 0xc0000000 which requires a non-zero PPC_MEMSTART. There
are a couple of places that assume PPC_MEMSTART is 0. This results in
various tricky crashing during booting. Most of the problems are
not accounting for PPC_MEMSTART during va/pa translations. My fixes
convert these places to use pre-existing macros instead of duplicating
the calculation.
The two items in head_4xx.S are critical, but I can't see a good way
to link them in without an #ifdef, or maybe a CONFIG_* symbol. The
alternate version of the tlb index picker will work for any platform,
but is based on 'random' selection of the tlb index using the timebase
rather than linear increment. I don't know if this is better, but it
is an easy way to skip the problematic memory reference.
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
---
arch/ppc/kernel/head_4xx.S | 7 +++++++
arch/ppc/mm/4xx_mmu.c | 5 +++--
arch/ppc/mm/pgtable.c | 4 +++-
include/asm-ppc/io.h | 4 ++--
include/asm-ppc/pgtable.h | 4 ++--
5 files changed, 17 insertions(+), 7 deletions(-)
applies-to: cec49fea2095ec77123684854ed519f01cf890da
1ffdbeb034cf2ad10105c28b4c9b7588084d8d9d
diff --git a/arch/ppc/kernel/head_4xx.S b/arch/ppc/kernel/head_4xx.S
index 10c261c..4d5ccaf 100644
--- a/arch/ppc/kernel/head_4xx.S
+++ b/arch/ppc/kernel/head_4xx.S
@@ -771,10 +771,15 @@ tlb_4xx_index:
finish_tlb_load:
/* load the next available TLB index.
*/
+#ifdef NON_ZERO_PPC_MEMSTART
+ mftb r9
+ andi. r9, r9, (PPC4XX_TLB_SIZE-1)
+#else
lwz r9, tlb_4xx_index@l(0)
addi r9, r9, 1
andi. r9, r9, (PPC4XX_TLB_SIZE-1)
stw r9, tlb_4xx_index@l(0)
+#endif
6:
/*
@@ -872,6 +877,7 @@ start_here:
tlbia
isync /* Flush shadow TLBs */
+#ifndef NON_ZERO_PPC_MEMSTART
/* set up the PTE pointers for the Abatron bdiGDB.
*/
lis r6, swapper_pg_dir@h
@@ -881,6 +887,7 @@ start_here:
stw r5, 0xf0(r0) /* Must match your Abatron config file */
tophys(r5,r5)
stw r6, 0(r5)
+#endif
/* Now turn on the MMU for real! */
lis r4,MSR_KERNEL@h
diff --git a/arch/ppc/mm/4xx_mmu.c b/arch/ppc/mm/4xx_mmu.c
index 4d006aa..253cf64 100644
--- a/arch/ppc/mm/4xx_mmu.c
+++ b/arch/ppc/mm/4xx_mmu.c
@@ -84,10 +84,11 @@ void __init MMU_init_hw(void)
/*
* Cache instruction and data space where the exception
* vectors and the kernel live in real-mode.
+ * 512MB starting at the base physical address of the kernel.
*/
- mtspr(SPRN_DCCR, 0xF0000000); /* 512 MB of data space at 0x0. */
- mtspr(SPRN_ICCR, 0xF0000000); /* 512 MB of instr. space at 0x0. */
+ mtspr(SPRN_DCCR, 0xF0000000 >> (PPC_MEMSTART/0x8000000));
+ mtspr(SPRN_ICCR, 0xF0000000 >> (PPC_MEMSTART/0x8000000));
}
#define LARGE_PAGE_SIZE_16M (1<<24)
diff --git a/arch/ppc/mm/pgtable.c b/arch/ppc/mm/pgtable.c
index 6ea9185..29909ac 100644
--- a/arch/ppc/mm/pgtable.c
+++ b/arch/ppc/mm/pgtable.c
@@ -190,7 +190,9 @@ __ioremap(phys_addr_t addr, unsigned lon
* Don't allow anybody to remap normal RAM that we're using.
* mem_init() sets high_memory so only do the check after that.
*/
- if ( mem_init_done && (p < virt_to_phys(high_memory)) )
+ if ( mem_init_done &&
+ p < virt_to_phys(high_memory) &&
+ p >= PPC_MEMSTART )
{
printk("__ioremap(): phys addr "PHYS_FMT" is RAM lr %p\n", p,
__builtin_return_address(0));
diff --git a/include/asm-ppc/io.h b/include/asm-ppc/io.h
index 84ac6e2..c43f2f9 100644
--- a/include/asm-ppc/io.h
+++ b/include/asm-ppc/io.h
@@ -422,7 +422,7 @@ extern inline void * bus_to_virt(unsigne
extern inline unsigned long virt_to_phys(volatile void * address)
{
#ifndef CONFIG_APUS
- return (unsigned long) address - KERNELBASE;
+ return __pa(address);
#else
return iopa ((unsigned long) address);
#endif
@@ -431,7 +431,7 @@ extern inline unsigned long virt_to_phys
extern inline void * phys_to_virt(unsigned long address)
{
#ifndef CONFIG_APUS
- return (void *) (address + KERNELBASE);
+ return __va(address);
#else
return (void*) mm_ptov (address);
#endif
diff --git a/include/asm-ppc/pgtable.h b/include/asm-ppc/pgtable.h
index 6d1c39e..488c6e9 100644
--- a/include/asm-ppc/pgtable.h
+++ b/include/asm-ppc/pgtable.h
@@ -724,12 +724,12 @@ extern pgprot_t phys_mem_access_prot(str
#define pmd_page_kernel(pmd) \
((unsigned long) __va(pmd_val(pmd) & PAGE_MASK))
#define pmd_page(pmd) \
- (mem_map + (pmd_val(pmd) >> PAGE_SHIFT))
+ pfn_to_page(pmd_val(pmd) >> PAGE_SHIFT)
#else
#define pmd_page_kernel(pmd) \
((unsigned long) (pmd_val(pmd) & PAGE_MASK))
#define pmd_page(pmd) \
- (mem_map + (__pa(pmd_val(pmd)) >> PAGE_SHIFT))
+ (virt_to_page(pmd_val(pmd)))
#endif
/* to find an entry in a kernel page-table-directory */
---
0.99.9k
^ permalink raw reply related
* Re: Can I operate i2c device in a tasklet?
From: Eugene Surovegin @ 2005-12-02 8:45 UTC (permalink / raw)
To: Sam Song; +Cc: linuxppc-embedded
In-Reply-To: <20051202062007.52513.qmail@web15804.mail.cnb.yahoo.com>
On Fri, Dec 02, 2005 at 02:20:07PM +0800, Sam Song wrote:
> Hi all,
>
> I found that once I operated i2c bus like
> read from i2c device in 2.4.31 kernl in a
> interrupt handler or tasklet, kernel panic
> would happen. Is there any way to make it
> in such case? I need to write sth on RTC
> alarm register with an interrupt event.
>
> ......
> Scheduling in interrupt
> kernel BUG at sched.c:564!
You cannot access i2c layer from non-process context. Please, search
mail list archives, this matter was discussed countless number of
times.
--
Eugene
^ permalink raw reply
* Re: AmigaOne 2.6.x Linux kernel port
From: Gerhard Pircher @ 2005-12-02 8:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1133481536.6100.32.camel@gaston>
> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
> debian-powerpc@lists.debian.org
> Betreff: Re: AmigaOne 2.6.x Linux kernel port
> Datum: Fri, 02 Dec 2005 10:58:55 +1100
>
> (I'm moving this to the linuxppc-dev list)
>
> Well, you need consistent alloc functions to really provide you with
> non-cached memory. Fushing is not enough. Flushing is fine for dma_map
> etc..., not for consistent alloc.
>
> So in theory, you should be able to re-use the existing consistent
> allocation functions, except that the current implementation has
> "issues":
Well, as far as I could understand the code, you need to define a start and
end address for the consistent memory, but as all the memory is managed by
the kernel, it's not possible to do this (I hope that I don't write nonsense
here ;-) ).
> The main problem I see with the implementation is that it just allocates
> pages out of the normal kernel allocator and maps them in the
> "consistent" virtual range without ever unmapping them from the kernel
> linear mapping. That means that those pages end up being mapped twice:
> cacheable and non-cacheable, which is absolutely wrong and will explode
> in colorful ways on a number of CPUs. The pages should at least be
> unmapped from the kernel linear (& cacheable) mapping.
>
> I understand this is probably done to keep the TLB miss handler for the
> kernel mapping as fast as possible. Unfortunately, it's also incorrect
> if your processor is capable of any kind of prefetching accross a 4k
> boundary.
Well, the processor is a normal G3/G4 desktop CPU...
> Then, remains the BAT mapping problem. In order to improve performances,
> the kernel uses BATs to map the main memory (to know more about BATs,
> look at the proccessor docs). That means that unmapping the memory from
> the linear mapping will not work if that memory happens to be covered by
> a BAT (there aren't even page tables entries for those pages anyway).
> Thus, in order to be able to reliably unmap things from the linear
> mapping (or individually change page attributes) you need to disable BAT
> mapping of memory, either completely, or by preallocating (and thus
> actually reserving) memory outside of the BAT mapping for use in the
> consistent allocator.
Okay, I think reserving memory outside of the BAT mapping, is the approach
that is used in the arch/ppc/kernel/dma-mapping.c file. There you should
define a consistent memory area (by it's start and end address), which is
used for non-coherent DMA memory allocations, right? But as that isn't
possible on the AmigaOne, we have to go the hard way.
> However, the exception handling of the kernel is designed with the
> assumption that it will not take hash faults in some critical locations,
> and this assumption is correct thanks to ... the BAT mapping. You are
> lucky though that recent kernels have been fixed to be able to recover
> from such faults provided the instructions are still BAT mapped, so you
> can probably hack the initialisation of the memory on ppc to not use
> data BATs but only instruction BATs and still create the page tables for
> the entire memory. That will allow you to implement proper unmapping of
> pages in the consistent allocator. However, it will also impact your
> overall performances ...
Well, after all the performance of the AmigaOne isn't that good (but
acceptable) due to the ArticiaS northbridge, but I think it's more important
to fix the real problem than doing a lot of workarounds. I'm going to study
now the processor docs, otherwise I won't understand not even a single bit
of the kernel code. :-)
Thanks again!
Gerhard
--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
^ permalink raw reply
* I want to A maillist about ppclinux
From: licongyong @ 2005-12-02 5:29 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 7 bytes --]
thanks!
[-- Attachment #2: Type: text/html, Size: 305 bytes --]
^ permalink raw reply
* [PATCH] ppc32: remove "jumbo" member from ocp_func_emac_data
From: Eugene Surovegin @ 2005-12-02 9:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-embedded
This patch removes not needed anymore "jumbo" member from
ocp_func_emac_data. Jumbo frame support is handled by PPC4xx EMAC
driver internally now.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
arch/ppc/platforms/4xx/ibm440gx.c | 2 --
arch/ppc/platforms/4xx/ibm440sp.c | 1 -
include/asm-ppc/ibm_ocp.h | 1 -
3 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/ppc/platforms/4xx/ibm440gx.c b/arch/ppc/platforms/4xx/ibm440gx.c
index 956f45e..d24c09e 100644
--- a/arch/ppc/platforms/4xx/ibm440gx.c
+++ b/arch/ppc/platforms/4xx/ibm440gx.c
@@ -58,7 +58,6 @@ static struct ocp_func_emac_data ibm440g
.wol_irq = 65, /* WOL interrupt number */
.mdio_idx = -1, /* No shared MDIO */
.tah_idx = 0, /* TAH device index */
- .jumbo = 1, /* Jumbo frames supported */
};
static struct ocp_func_emac_data ibm440gx_emac3_def = {
@@ -72,7 +71,6 @@ static struct ocp_func_emac_data ibm440g
.wol_irq = 67, /* WOL interrupt number */
.mdio_idx = -1, /* No shared MDIO */
.tah_idx = 1, /* TAH device index */
- .jumbo = 1, /* Jumbo frames supported */
};
OCP_SYSFS_EMAC_DATA()
diff --git a/arch/ppc/platforms/4xx/ibm440sp.c b/arch/ppc/platforms/4xx/ibm440sp.c
index feb17e4..71a0117 100644
--- a/arch/ppc/platforms/4xx/ibm440sp.c
+++ b/arch/ppc/platforms/4xx/ibm440sp.c
@@ -31,7 +31,6 @@ static struct ocp_func_emac_data ibm440s
.wol_irq = 61, /* WOL interrupt number */
.mdio_idx = -1, /* No shared MDIO */
.tah_idx = -1, /* No TAH */
- .jumbo = 1, /* Jumbo frames supported */
};
OCP_SYSFS_EMAC_DATA()
diff --git a/include/asm-ppc/ibm_ocp.h b/include/asm-ppc/ibm_ocp.h
index 9c21de1..ddce616 100644
--- a/include/asm-ppc/ibm_ocp.h
+++ b/include/asm-ppc/ibm_ocp.h
@@ -63,7 +63,6 @@ struct ocp_func_emac_data {
int wol_irq; /* WOL interrupt */
int mdio_idx; /* EMAC idx of MDIO master or -1 */
int tah_idx; /* TAH device index or -1 */
- int jumbo; /* Jumbo frames capable flag */
int phy_mode; /* PHY type or configurable mode */
u8 mac_addr[6]; /* EMAC mac address */
u32 phy_map; /* EMAC phy map */
^ permalink raw reply related
* pq2_find_bridges hangs system
From: Alex BASTOS @ 2005-12-02 10:51 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am working on a board with a MPC8248 based on ADS8272.
Until now I was working with ppc kernel 2.6.11. Now, it's
time to go up, so I am trying 2.6.15-rc2.
Unfortunately, kernel hangs at boot-up, and with a BDI2000
I have reached the pq2_find_bridges() call, more precisely,
in indirect_read_config(). Now I am a bit lost, as I have
almos any knowledge about PCI.
The board doesn't need PCI support at all, but I need it
active on kernel as it is required by USB HCD stack.
I have tested this on the ADS8272 and i doesn't happends,
so, any clue.
And, has the indirect_read_config any to do with the PCI9
workaround, which is supposed to be corrected on HIP7
devices?
Thanks in advance.
Alex BASTOS
^ permalink raw reply
* Re: pq2_find_bridges hangs system
From: Vitaly Bordug @ 2005-12-02 10:30 UTC (permalink / raw)
To: Alex BASTOS; +Cc: linuxppc-embedded
In-Reply-To: <1133520697.4390273987a6a@webmail.televes.com:443>
Alex BASTOS wrote:
> Hi,
>
> I am working on a board with a MPC8248 based on ADS8272.
> Until now I was working with ppc kernel 2.6.11. Now, it's
> time to go up, so I am trying 2.6.15-rc2.
>
> Unfortunately, kernel hangs at boot-up, and with a BDI2000
> I have reached the pq2_find_bridges() call, more precisely,
> in indirect_read_config(). Now I am a bit lost, as I have
> almos any knowledge about PCI.
>
> The board doesn't need PCI support at all, but I need it
> active on kernel as it is required by USB HCD stack.
>
> I have tested this on the ADS8272 and i doesn't happends,
> so, any clue.
>
> And, has the indirect_read_config any to do with the PCI9
> workaround, which is supposed to be corrected on HIP7
> devices?
>
There are 2 indirect_read_config(), one for PCI9 case, and one for not.
I guess you should have CONFIG_8260_PCI9 disabled.
If config seems OK, pleas submit backtrace. As long as I can see, "proper" setup_indirect_pci has been moved over to arch/powerpc/sysdev/indirect_pci.c.
Check it it is compiled/used.
> Thanks in advance.
>
> Alex BASTOS
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* back trace when a SIGSEGV
From: Redondo Garcia, Roberto @ 2005-12-02 10:33 UTC (permalink / raw)
To: linuxppc-dev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1457 bytes --]
hello,
I have a program that when it has been several hours running, it has a
problem and falls and it produces a SIGSEGV. I would like to know to
how debug this error, because I do not have ulimit for generate core
dump o examine a back trace.
thanks
-------------------------------------------------------------------------------------------------------------------
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, contiene información de carácter confidencial exclusivamente dirigida a su destinatario o destinatarios. Queda prohibida su divulgación, copia o distribución a terceros sin la previa autorización escrita de Indra. En el caso de haber recibido este correo electrónico por error, se ruega notificar inmediatamente esta circunstancia mediante reenvío a la dirección electrónica del remitente. POR FAVOR, ANTES DE IMPRIMIR ESTE CORREO ELECTRÓNICO CONSIDERE SU APORTACIÓN A LA CONSERVACIÓN DEL MEDIO AMBIENTE POR LA REDUCCIÓN DE CONSUMO DE PAPEL.
The information in this e-mail and in any attachments is confidential and solely for the attention and use of the named addressee(s). You are hereby notified that any dissemination, distribution or copy of this communication is prohibited without the prior written consent of Indra. If you have received this communication in error, please, notify the sender by reply e-mail. PLEASE CONSIDER YOUR ENVIRONMENTAL RESPONSIBILITY BEFORE PRINTING THIS E-MAIL.
[-- Attachment #2: Type: text/html, Size: 2230 bytes --]
^ permalink raw reply
* Re: pq2_find_bridges hangs system
From: Alex BASTOS @ 2005-12-02 13:56 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <4390223C.8060103@ru.mvista.com>
Vitaly,
> >
> There are 2 indirect_read_config(), one for PCI9 case, and one for not.
> I guess you should have CONFIG_8260_PCI9 disabled.
>
> If config seems OK, pleas submit backtrace. As long as I can see, "proper"
> setup_indirect_pci has been moved over to arch/powerpc/sysdev/indirect_pci.c.
> Check it it is compiled/used.
>
Config file seems OK to me:
# CONFIG_CPCI690 is not set
CONFIG_PPC_INDIRECT_PCI=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCI_8260=y
# CONFIG_PCI_LEGACY_PROC is not set
# CONFIG_PCI_DEBUG is not set
# CONFIG_NET_PCI is not set
and indirect_pci from arch/powerpc is compiled and used ...
I have tested a bit more. The call trace would be:
[c01db170] m8260_setup_arch
[c01db87c] pq2_find_bridges
[c01dbfa0] pciauto_bus_scan
[c000a754] early_read_config_byte
[c00c8f54] pci_bus_read_config_byte
[c0011424] indirect_read_config
I have done manually, since GDB only reports last two,
and I couldn't get it from log_buf.
(gdb) bt
#0 indirect_read_config (bus=0x0, devfn=3223241436,
offset=8, len=14, val=0x1032)
at arch/powerpc/sysdev/indirect_pci.c:32
#1 0xc00c8fb4 in pci_bus_read_config_byte (bus=0xc01ec2dc,
devfn=8, pos=14, value=0xc01d1f3a "")
at drivers/pci/access.c:52
Now I have check indirect_read_config, and I have seen
the call ends itself, but after that it returns to
pci_bus_read_config_dword
executes some asm and then hangs.
Any idea?
Thanks,
Alex BASTOS
^ permalink raw reply
* Re: pq2_find_bridges hangs system
From: Alex BASTOS @ 2005-12-02 14:49 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <1133531801.4390529995cfa@webmail.televes.com:443>
Vitally,
Finally, more clever informacion from log_buf.
(...and sorry about previos uncomplete information)
<5>Linux version 2.6.15-rc2 (alebas@xxxx) (gcc version 3.3.2) #1 PREEMPT Fri Dec
2 12:22:09 CET 2005
<6>Televes xxxxxx
<4>arch/ppc/syslib/m82xx_pci.c: The PCI bus is 66666666 Mhz.
<4>Waiting 1 second after deasserting RST...
<4>Machine check in kernel mode.
<4>Caused by (from SRR1=41030): Transfer error ack signal
<4>Oops: machine check, sig: 7 [#1]
<4>PREEMPT
<4>NIP: C001150C LR: C0011530 SP: C01D1EA0 REGS: c01d1df0 TRAP: 0200 Not
tainted
<4>MSR: 00041030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
<4>TASK = c01a2ff8[0] 'swapper' THREAD: c01d0000
<4>Last syscall: 0
<6>GPR00: 000000FF C01D1EA0 C01A2FF8 00000000 00000008 F0010906 00000001
C01D1ED8
<6>GPR08: 00000001 00000002 00000800 F0010904 24008028 FFFFFFFF 03FFE000
00000000
<6>GPR16: 00000001 00000001 FFFFFFFF 007FFF00 03FF8CE8 00000000 00000003
03BCB578
<6>GPR24: 00000000 00000000 00000001 0000000E 00000008 C01D1ED8 C01EC2DC
C01FC000
<4>NIP [c001150c] indirect_read_config+0xe8/0x11c
<4>LR [c0011530] indirect_read_config+0x10c/0x11c
<4>Call trace:
<4> [c00c8fb4] pci_bus_read_config_byte+0x60/0xa8
<4> [c000a784] early_read_config_byte+0x30/0x44
<4> [c01dc04c] pciauto_bus_scan+0xac/0x298
<4> [c01dba00] pq2_find_bridges+0x184/0x1b0
<4> [c01db1a0] m8260_setup_arch+0x30/0x80
<4> [c01d8c2c] setup_arch+0x110/0x18c
<4> [c01d2544] start_kernel+0x34/0x1bc
<4> [000032bc] 0x32bc
<4>Oops: kernel access of bad area, sig: 11 [#2]
<4>PREEMPT
<4>NIP: C001196C LR: C0012940 SP: C01D1C70 REGS: c01d1bc0 TRAP: 0300 Not
tainted
<4>MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
<4>DAR: 00000000, DSISR: 20000000
<4>TASK = c01a2ff8[0] 'swapper' THREAD: c01d0000
<4>Last syscall: 0
<6>GPR00: 00010005 C01D1C70 C01A2FF8 C01A2FF8 00000000 00000001 C01ED8E0
00000000
<6>GPR08: 00000000 00000001 00000078 C01D0000 00000000 FFFFFFFF 03FFE000
00000000
<6>GPR16: 00000001 00000001 FFFFFFFF 007FFF00 03FF8CE8 00000000 00000003
C01F0000
<6>GPR24: C01F0000 00000000 00000001 0000000E C01EB09C 00000000 C01EDD20
C01A2FF8
<4>NIP [c001196c] dequeue_task+0x0/0x78
<4>LR [c0012940] scheduler_tick+0x244/0x3b0
<4>Call trace:
<4> [c002284c] update_process_times+0xa4/0x168
<4> [c0005bb4] timer_interrupt+0x90/0x25c
<4> [c0004a7c] ret_from_except+0x0/0x14
<4> [c0004d9c] die+0xa0/0xc4
<4> [c0004a30] ret_from_except_full+0x0/0x4c
<4> [c001150c] indirect_read_config+0xe8/0x11c
<4> [c00c8fb4] pci_bus_read_config_byte+0x60/0xa8
<4> [c000a784] early_read_config_byte+0x30/0x44
<4> [c01dc04c] pciauto_bus_scan+0xac/0x298
<4> [c01dba00] pq2_find_bridges+0x184/0x1b0
<4> [c01db1a0] m8260_setup_arch+0x30/0x80
<4> [c01d8c2c] setup_arch+0x110/0x18c
<4> [c01d2544] start_kernel+0x34/0x1bc
<4> [000032bc] 0x32bc
<0>Kernel panic - not syncing: Aiee, killing interrupt handler!
<4> <0>Rebooting in 180 seconds..
The Tranfer Error makes not many sense for me, as _TEA is pulled-up.
Maybe the oops after that is caused by the bad call return point?
Thanks,
Alex BASTOS
^ permalink raw reply
* Re: pq2_find_bridges hangs system
From: Kalle Pokki @ 2005-12-02 14:09 UTC (permalink / raw)
To: Alex BASTOS; +Cc: linuxppc-embedded
In-Reply-To: <0IQV004GGIH0UG@mailstore1.hut-mail>
Alex BASTOS wrote:
>The Tranfer Error makes not many sense for me, as _TEA is pulled-up.
>Maybe the oops after that is caused by the bad call return point?
>
>
I remember using this to prevent machine check exceptions during the PCI
scan. This is in the beginning of the pciauto_bus_scan() function.
--- trunk/linux/arch/ppc/syslib/pci_auto.c (revision 127)
+++ trunk/linux/arch/ppc/syslib/pci_auto.c (revision 128)
@@ -382,6 +382,10 @@
unsigned short vid;
unsigned char header_type;
+
+ /* must ignore machine checks during scan */
+ *(volatile unsigned short *) 0xf0010888 &= ~0x0800;
+
/*
* Fetch our I/O and memory space upper boundaries used
* to allocated base addresses on this hose.
^ permalink raw reply
* Re: back trace when a SIGSEGV
From: Dustin Lang @ 2005-12-02 14:27 UTC (permalink / raw)
To: Redondo Garcia, Roberto; +Cc: linuxppc-dev
In-Reply-To: <6A28467355D2AD478D1F51C479415AE77B47E9@MADTORMAIL.indra.es>
Hi,
SIGSEGV (also known as a "segmentation fault" or "segfault") usually means
your program is doing something wrong like trying to dereference a null
pointer. (ie, int* x = NULL; *x = 42;). To track this down, you can use
"gdb" (the gnu debugger) - gnu.org. Another option is "valgrind" -
valgrind.org - there is a PowerPC port (thanks, Paul!).
However, this mailing list is for _development_ of the linux _kernel_ on
PowerPC. Your question is not about kernel development so it doesn't
belong here. (Unless you are sure that your program is correct and
somehow the kernel is unfairly giving you a segfault - which doesn't seem
to be the case, based on your message.) Find a mailing list or message
board about userspace programming and ask your question there.
Also, you should learn how to write a bug report. Go to google.com, type
in "how to write a bug report", and read the first ten results. (For
example: What program are you running? Something you wrote? What OS are
you using? Why do you think the SIGSEGV is something caused by someone
else's code and not your own? Why does it matter how long the program
runs before it crashes? Why didn't you type "debug" into google and see
what came up? (GDB is number 6! Come on, get with it!))
Happy debugging!
dustin.
> hello,
> I have a program that when it has been several hours running, it has a
> problem and falls and it produces a SIGSEGV. I would like to know to
> how debug this error, because I do not have ulimit for generate core
> dump o examine a back trace.
>
> thanks
^ permalink raw reply
* Re: pq2_find_bridges hangs system
From: Vitaly Bordug @ 2005-12-02 14:55 UTC (permalink / raw)
To: Alex BASTOS; +Cc: linuxppc-embedded list
In-Reply-To: <1133534967.43905ef73521a@webmail.televes.com:443>
Alex,
please probe this. If it will not help, pq2ads_setup_pci should be digged for some board specifics.
Also, check if hose->set_cfg_type is 1 as done for ads8272.
-------- Original Message --------
Subject: [patch 01/34] ppc32: Fix incorrect PCI frequency value
Date: Thu, 01 Dec 2005 00:51:15 -0800
From: akpm@osdl.org
To: torvalds@osdl.org
CC: akpm@osdl.org, vbordug@ru.mvista.com, galak@kernel.crashing.org
From: Vitaly Bordug <vbordug@ru.mvista.com>
The time to wait after deasserting PCI_RST has been counted with incorrect
value - this patch fixes the issue.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
arch/ppc/syslib/m82xx_pci.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
diff -puN arch/ppc/syslib/m82xx_pci.c~ppc32-fix-incorrect-pci-frequency-value arch/ppc/syslib/m82xx_pci.c
--- devel/arch/ppc/syslib/m82xx_pci.c~ppc32-fix-incorrect-pci-frequency-value 2005-11-30 23:58:00.000000000 -0800
+++ devel-akpm/arch/ppc/syslib/m82xx_pci.c 2005-11-30 23:58:00.000000000 -0800
@@ -248,7 +248,8 @@ pq2ads_setup_pci(struct pci_controller *
pci_div = ( (sccr & SCCR_PCI_MODCK) ? 2 : 1) *
( ( (sccr & SCCR_PCIDF_MSK) >> SCCR_PCIDF_SHIFT) + 1);
freq = (uint)((2*binfo->bi_cpmfreq)/(pci_div));
- time = (int)666666/freq;
+ time = (int)66666666/freq;
+
/* due to PCI Local Bus spec, some devices needs to wait such a long
time after RST deassertion. More specifically, 0.508s for 66MHz & twice more for 33 */
printk("%s: The PCI bus is %d Mhz.\nWaiting %s after deasserting RST...\n",__FILE__,freq,
_
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Stelian Pop @ 2005-12-02 14:28 UTC (permalink / raw)
To: Michael Hanselmann
Cc: linuxppc-dev, johannes, debian-powerpc, linux-kernel,
Parag Warudkar
In-Reply-To: <20051130234653.GB15102@hansmi.ch>
Le jeudi 01 décembre 2005 à 00:46 +0100, Michael Hanselmann a écrit :
> On Wed, Nov 30, 2005 at 11:39:17PM +0100, Michael Hanselmann wrote:
> > The patch is attached for easier use.
>
> There was a mistake in it due to which the mouse button wouldn't work.
> Fixed in the now attached patch.
Is this version really working well on the new Powerbooks ? From what
I've seen in this thread there are still issues and it's still a work in
progress, so it may be too early to integrate the changes in the kernel.
Also, some other comments on the code itself:
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+#include <linux/relayfs_fs.h>
+#endif
While the relayfs code is ok for debugging, I'm wondering if it should be left in the final version at all.
+ int is0215; /* is the device a 0x0215? */
No need for that, just use udev->descriptor.idProduct == 0x0215 (in a macro perhaps)
+ int overflowwarn; /* overflow warning printed? */
I would use a static variable in the case -OVERFLOW: block here.
+ dev->xy_cur[i++] = dev->data[19];
+ dev->xy_cur[i++] = dev->data[20];
+ dev->xy_cur[i++] = dev->data[22];
+ dev->xy_cur[i++] = dev->data[23];
There is obviously a pattern here:
for (i = 0; i < 15; i++)
dev->xy_cur[i] = dev->data[ 19 + (i * 3) / 2 ]
I'm wondering if the same formula doesn't apply for more X and Y sensors (like 16 X
and 16 Y sensors on the old Powerbooks, 26 for the 17" models)
+#if 0
+ /* Some debug code */
+ for (i = 0; i < dev->urb->actual_length; i++) {
+ printk("%2x,", (unsigned char)dev->data[i]);
+ }
+ printk("\n");
+#endif
Please dump that.
+ /* Prints the read values */
+ if (debug > 1) {
+ printk("appletouch: X=");
+ for (i = 0; i < 15; i++) {
+ printk("%2x,", (unsigned char)dev->xy_cur[i]);
+ }
+ printk(" Y=");
+ for (i = ATP_XSENSORS; i < (ATP_XSENSORS + (9 - 1)); i++) {
+ printk("%2x,", (unsigned char)dev->xy_cur[i]);
+ }
+ printk("\n");
+ }
What is the point in doing this since the dbg_dump is called a few lines
later ? Best is to modify dbg_dump to know about the new number of
sensors...
+ printk(KERN_INFO "appletouch: atp_probe found interrupt "
+ "in endpoint: %d\n", int_in_endpointAddr);
Why is this useful to know ?
+ if (dev->is0215) {
+ dev->datalen = 64;
+ } else {
+ dev->datalen = 81;
+ }
Braces are not needed here.
PS: please inline the patch instead of attaching it to the mail, it's
much more easy to quote it that way.
Stelian.
--
Stelian Pop <stelian@popies.net>
^ 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