* [patch 2.6.14 (take #2)] fec_8xx: make CONFIG_FEC_8XX depend on CONFIG_8xx
From: John W. Linville @ 2005-11-07 18:24 UTC (permalink / raw)
To: Pantelis Antoniou, linuxppc-embedded, netdev, linux-kernel
In-Reply-To: <20051107182031.GC13797@tuxdriver.com>
Change CONFIG_FEC_8XX to depend on CONFIG_8xx instead of CONFIG_FEC.
CONFIG_FEC depends on ColdFire CPUs, which does not apply for the
PPC 8xx processors.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/fec_8xx/Kconfig | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/fec_8xx/Kconfig b/drivers/net/fec_8xx/Kconfig
index 94e7a9a..a84c232 100644
--- a/drivers/net/fec_8xx/Kconfig
+++ b/drivers/net/fec_8xx/Kconfig
@@ -1,6 +1,6 @@
config FEC_8XX
tristate "Motorola 8xx FEC driver"
- depends on NET_ETHERNET && FEC
+ depends on NET_ETHERNET && 8xx
select MII
config FEC_8XX_GENERIC_PHY
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply related
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Tom Rini @ 2005-11-07 18:22 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Dan Malek, linuxppc-embedded, gtolstolytkin
In-Reply-To: <F6AD7E21CDF4E145A44F61F43EE6D9393FD5C5@tmnt04.transmode.se>
On Mon, Nov 07, 2005 at 07:14:15PM +0100, Joakim Tjernlund wrote:
> > -----Original Message-----
> > From: Tom Rini [mailto:trini@kernel.crashing.org]
> > Sent: 07 November 2005 16:52
> > To: Marcelo Tosatti
> > Cc: Joakim Tjernlund; Pantelis Antoniou; Dan Malek;
> > linuxppc-embedded@ozlabs.org; gtolstolytkin@ru.mvista.com
> > Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
> >
> > On Mon, Nov 07, 2005 at 08:16:18AM -0200, Marcelo Tosatti wrote:
> > > Joakim!
> > >
> > > On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim Tjernlund wrote:
> > > > Hi Marcelo
> > > >
> > > > [SNIP]
> > > > > The root of the problem are the changes against the 8xx TLB
> > > > > handlers introduced
> > > > > during v2.6. What happens is the TLBMiss handlers load the
> > > > > zeroed pte into
> > > > > the TLB, causing the TLBError handler to be invoked (thats
> > > > > two TLB faults per
> > > > > pagefault), which then jumps to the generic MM code to
> > setup the pte.
> > > > >
> > > > > The bug is that the zeroed TLB is not invalidated (the
> > same reason
> > > > > for the "dcbst" misbehaviour), resulting in infinite
> > TLBError faults.
> > > > >
> > > > > Dan, I wonder why we just don't go back to v2.4 behaviour.
> > > >
> > > > This is one reason why it is the way it is:
> > > >
> > http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016382.html
> > > > This details are little fuzzy ATM, but I think the reason for the
> > > > current
> > > > impl. was only that it was less intrusive to impl.
> > >
> > > Ah, I see. I wonder if the bug is processor specific: we
> > don't have such
> > > changes in our v2.4 tree and never experienced such problem.
> > >
> > > It should be pretty easy to hit it right? (instruction
> > pagefaults should
> > > fail).
> > >
> > > Grigori, Tom, can you enlight us about the issue on the URL
> > above. How
> > > can it be triggered?
> >
> > So after looking at the code in 2.6.14 and current git, I think the
> > above URL isn't relevant, unless there was a change I missed (which
> > could totally be possible) that reverted the patch there and
> > fixed that
> > issue in a different manner. But since I didn't figure that
> > out until I
> > had finished researching it again:
>
> I wasn't clear enough. What I meant was that the above patch made me
> think and
> the result was that I came up with a simpler fix, the "two exception"
> fix that
> is in current kernels. See
> http://linux.bkbits.net:8080/linux-2.6/diffs/arch/ppc/kernel/head_8xx.S@
> 1.19?nav=index.html|src/.|src/arch|src/arch/ppc|src/arch/ppc/kernel|hist
> /arch/ppc/kernel/head_8xx.S
> It appears this fix has some other issues :(
>
> How do the other ppc arches do? I am guessing that they don't double
> fault, but bails
> out to do_page_fault from the TLB Miss handler, like 8xx used to do.
Assuming Dan doesn't come up with a more simple & better fix, maybe we
should go back to the original patch I made?
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [patch 2.6.14] fec_8xx: make CONFIG_FEC_8XX depend on CONFIG_8xx
From: John W. Linville @ 2005-11-07 18:20 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: netdev, linux-kernel, linuxppc-embedded
In-Reply-To: <436F07F5.1030206@intracom.gr>
On Mon, Nov 07, 2005 at 09:53:25AM +0200, Pantelis Antoniou wrote:
> John W. Linville wrote:
> >@@ -1,6 +1,6 @@
> > config FEC_8XX
> > tristate "Motorola 8xx FEC driver"
> >- depends on NET_ETHERNET
> >+ depends on NET_ETHERNET && 8xx
> > select MII
> >
> > config FEC_8XX_GENERIC_PHY
>
> Yes, this is the correct approach. Please disregard the other
> patches floating about.
Pretty sure you are right. However, a broken version already got
committed. It added FEC as a dependency. That keeps it from breaking
everyone else, but it make the driver available for Coldfire rather
than for PPC 8xx...
I'll reform that patch and repost.
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* RE: [PATCH 2.6.14] mm: 8xx MM fix for
From: Joakim Tjernlund @ 2005-11-07 18:14 UTC (permalink / raw)
To: Tom Rini, Marcelo Tosatti; +Cc: linuxppc-embedded, Dan Malek, gtolstolytkin
> -----Original Message-----
> From: Tom Rini [mailto:trini@kernel.crashing.org]=20
> Sent: 07 November 2005 16:52
> To: Marcelo Tosatti
> Cc: Joakim Tjernlund; Pantelis Antoniou; Dan Malek;=20
> linuxppc-embedded@ozlabs.org; gtolstolytkin@ru.mvista.com
> Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
>=20
> On Mon, Nov 07, 2005 at 08:16:18AM -0200, Marcelo Tosatti wrote:
> > Joakim!
> >=20
> > On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim Tjernlund wrote:
> > > Hi Marcelo
> > >=20
> > > [SNIP]=20
> > > > The root of the problem are the changes against the 8xx TLB=20
> > > > handlers introduced
> > > > during v2.6. What happens is the TLBMiss handlers load the=20
> > > > zeroed pte into
> > > > the TLB, causing the TLBError handler to be invoked (thats=20
> > > > two TLB faults per=20
> > > > pagefault), which then jumps to the generic MM code to=20
> setup the pte.
> > > >=20
> > > > The bug is that the zeroed TLB is not invalidated (the=20
> same reason
> > > > for the "dcbst" misbehaviour), resulting in infinite=20
> TLBError faults.
> > > >=20
> > > > Dan, I wonder why we just don't go back to v2.4 behaviour.
> > >=20
> > > This is one reason why it is the way it is:
> > >=20
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016382.html
> > > This details are little fuzzy ATM, but I think the reason for the
> > > current
> > > impl. was only that it was less intrusive to impl.
> >=20
> > Ah, I see. I wonder if the bug is processor specific: we=20
> don't have such
> > changes in our v2.4 tree and never experienced such problem.
> >=20
> > It should be pretty easy to hit it right? (instruction=20
> pagefaults should
> > fail).
> >=20
> > Grigori, Tom, can you enlight us about the issue on the URL=20
> above. How
> > can it be triggered?
>=20
> So after looking at the code in 2.6.14 and current git, I think the
> above URL isn't relevant, unless there was a change I missed (which
> could totally be possible) that reverted the patch there and=20
> fixed that
> issue in a different manner. But since I didn't figure that=20
> out until I
> had finished researching it again:
I wasn't clear enough. What I meant was that the above patch made me
think and
the result was that I came up with a simpler fix, the "two exception"
fix that
is in current kernels. See
http://linux.bkbits.net:8080/linux-2.6/diffs/arch/ppc/kernel/head_8xx.S@
1.19?nav=3Dindex.html|src/.|src/arch|src/arch/ppc|src/arch/ppc/kernel|his=
t
/arch/ppc/kernel/head_8xx.S
It appears this fix has some other issues :(
How do the other ppc arches do? I am guessing that they don't double
fault, but bails
out to do_page_fault from the TLB Miss handler, like 8xx used to do.
>=20
> Switching hats for a minute, this came from a bug a customer of
> MontaVista found, so I can't give out the testcase :(
>=20
> To repeat what Joakim said back then:
> "I think I have figured this out. The first TLB misses that happen at
> app startup is Data TLB misses. These will then hit the NULL L1 entry
> and end up in do_page_fault() which will populate the L1=20
> entry. But when
> you have a very large app that spans more than one L1 entry (16 MB I
> think) it may happen that you will have I-TLB Miss first one of the L1
> entrys which will make the I-TLB handler bail out to=20
> do_page_fault() and
> the app craches(SEGV)."
This still stands I think.
>=20
> Looking at the patch again, what I don't see is why I talk=20
> about fudging
> I-TLB Miss at 0x400 when it's I-TLB Error we fudge at being there, but
> then get hung up that there can be a slight diff between the=20
> two ("This
> is because we check bit 4 of SRR1 in both cases, but in the case of an
> I-TLB Miss, this bit is always set, and it only indicates a protection
> fault on an I-TLB Error.") so instead of 0x1300 jumping to the handler
> at 0x400, we treat it like a regular exception so we know=20
> where we came
> from, and perhaps missed fixing a case somewhere?
Didn't look into this part of your patch, sorry.
Jocke
^ permalink raw reply
* Re: [PATCH] Fix 8250 probe on ppc32
From: Dan Malek @ 2005-11-07 17:25 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev, David Woodhouse
In-Reply-To: <20051107163144.GF3839@smtp.west.cox.net>
On Nov 7, 2005, at 11:31 AM, Tom Rini wrote:
> ..... If everything going forward ships from the hw
> vendor with U-Boot,
You can't make that assumption. Very few production
systems ship with U-Boot, whether we like it or not.
For those of us that developed all of this "boot wrapper"
code and remember why it was done, all of those reasons
still exist. More people are using U-Boot, but it's mostly
during development. The other embedded software we
are trying to displace with Linux sometimes doesn't have
the rom space, and there is the "we didn't have it before"
mentality that is hard to change.
Don't cast this old boot code too far away, people still use it.
Thanks.
-- Dan
^ permalink raw reply
* BDI2000 and Linux 2.6 kernel
From: Marcelo Tosatti @ 2005-11-07 12:11 UTC (permalink / raw)
To: linux-ppc-embedded, support
Hi,
Currently gdb over BDI (and I've seen other reports on this list) fails to
translate virtual->physical addresses on PPC 8xx:
*** MMU: address translation for 0xC000C66C failed
*** MMU: address translation for 0xC000C66C failed
Thats because the v2.6 kernel was changed to use physical addresses on the
first level page.
Dan informed me there might be a firmware update available to address
this problem. Is this true?
With the following the kernel stores the virtual address on the PMD
getting the BDI "to work".
A newer firmware would be much better though.
--- linux-2.6.14-rc4.orig/arch/ppc/kernel/head_8xx.S 2005-10-18 16:59:34.000000000 -0500
+++ linux-2.6.14-rc4/arch/ppc/kernel/head_8xx.S 2005-11-01 05:45:00.000000000 -0600
@@ -320,11 +320,12 @@ InstructionTLBMiss:
lwz r11, 0(r10) /* Get the level 1 entry */
rlwinm. r10, r11,0,0,19 /* Extract page descriptor page address */
beq 2f /* If zero, don't try to find a pte */
+ tophys(r11,r11)
/* We have a pte table, so load the MI_TWC with the attributes
* for this "segment."
*/
- ori r11,r11,1 /* Set valid bit */
+ /*ori r11,r11,1 Set valid bit */
DO_8xx_CPU6(0x2b80, r3)
mtspr SPRN_MI_TWC, r11 /* Set segment attributes */
DO_8xx_CPU6(0x3b80, r3)
@@ -379,6 +380,7 @@ DataStoreTLBMiss:
lwz r11, 0(r10) /* Get the level 1 entry */
rlwinm. r10, r11,0,0,19 /* Extract page descriptor page address */
beq 2f /* If zero, don't try to find a pte */
+ tophys(r11,r11)
/* We have a pte table, so load fetch the pte from the table.
*/
@@ -493,6 +495,7 @@ DataTLBError:
lwz r11, 0(r10) /* Get the level 1 entry */
rlwinm. r10, r11,0,0,19 /* Extract page descriptor page address */
beq 2f /* If zero, bail */
+ tophys(r11,r11)
/* We have a pte table, so fetch the pte from the table.
*/
diff -Nur -p --exclude-from=linux-2.6.14-rc4/Documentation/dontdiff linux-2.6.14-rc4.orig/include/asm-ppc/pgalloc.h linux-2.6.14-rc4/include/asm-ppc/pgalloc.h
--- linux-2.6.14-rc4.orig/include/asm-ppc/pgalloc.h 2005-10-18 17:00:09.000000000 -0500
+++ linux-2.6.14-rc4/include/asm-ppc/pgalloc.h 2005-11-01 08:02:08.000000000 -0600
@@ -19,16 +19,16 @@ extern void pgd_free(pgd_t *pgd);
#define __pmd_free_tlb(tlb,x) do { } while (0)
#define pgd_populate(mm, pmd, pte) BUG()
-#ifndef CONFIG_BOOKE
+#if defined(CONFIG_BOOKE) || defined(CONFIG_8xx)
#define pmd_populate_kernel(mm, pmd, pte) \
- (pmd_val(*(pmd)) = __pa(pte) | _PMD_PRESENT)
+ (pmd_val(*(pmd)) = (unsigned long)pte | _PMD_PRESENT)
#define pmd_populate(mm, pmd, pte) \
- (pmd_val(*(pmd)) = (page_to_pfn(pte) << PAGE_SHIFT) | _PMD_PRESENT)
+ (pmd_val(*(pmd)) = (unsigned long)page_to_virt(pte) | _PMD_PRESENT)
#else
#define pmd_populate_kernel(mm, pmd, pte) \
- (pmd_val(*(pmd)) = (unsigned long)pte | _PMD_PRESENT)
+ (pmd_val(*(pmd)) = __pa(pte) | _PMD_PRESENT)
#define pmd_populate(mm, pmd, pte) \
- (pmd_val(*(pmd)) = (unsigned long)page_to_virt(pte) | _PMD_PRESENT)
+ (pmd_val(*(pmd)) = (page_to_pfn(pte) << PAGE_SHIFT) | _PMD_PRESENT)
#endif
extern pte_t *pte_alloc_one_kernel(struct mm_struct *mm, unsigned long addr);
diff -Nur -p --exclude-from=linux-2.6.14-rc4/Documentation/dontdiff linux-2.6.14-rc4.orig/include/asm-ppc/pgtable.h linux-2.6.14-rc4/include/asm-ppc/pgtable.h
--- linux-2.6.14-rc4.orig/include/asm-ppc/pgtable.h 2005-10-18 17:00:09.000000000 -0500
+++ linux-2.6.14-rc4/include/asm-ppc/pgtable.h 2005-11-01 08:01:34.000000000 -0600
@@ -719,16 +719,16 @@ extern pgprot_t phys_mem_access_prot(str
* handler). On everything else the pmd contains the physical address
* of the pte page. -- paulus
*/
-#ifndef CONFIG_BOOKE
+#if defined (CONFIG_BOOKE) || defined CONFIG_8xx
#define pmd_page_kernel(pmd) \
- ((unsigned long) __va(pmd_val(pmd) & PAGE_MASK))
+ ((unsigned long) (pmd_val(pmd) & PAGE_MASK))
#define pmd_page(pmd) \
- (mem_map + (pmd_val(pmd) >> PAGE_SHIFT))
+ (mem_map + (__pa(pmd_val(pmd)) >> PAGE_SHIFT))
#else
#define pmd_page_kernel(pmd) \
- ((unsigned long) (pmd_val(pmd) & PAGE_MASK))
+ ((unsigned long) __va(pmd_val(pmd) & PAGE_MASK))
#define pmd_page(pmd) \
- (mem_map + (__pa(pmd_val(pmd)) >> PAGE_SHIFT))
+ (mem_map + (pmd_val(pmd) >> PAGE_SHIFT))
#endif
/* to find an entry in a kernel page-table-directory */
^ permalink raw reply
* Re: BDI and 85xx
From: Dan Malek @ 2005-11-07 17:17 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Edson Seabra, linux-ppc-embedded
In-Reply-To: <20051107112424.GE15522@logos.cnet>
On Nov 7, 2005, at 6:24 AM, Marcelo Tosatti wrote:
> Edson had to patch this in to get BDI to work on 85xx with 2.6.14.
How about we just change MSR_KERNEL and MSR_USER
in the include file #define instead of all of this run-time code?
Or, change the code so it preserves DE in general, so we don't
need a special kernel configuration just for the BDI?
The original reason I did the BDI_SWITCH was due to the
overhead of tracking user PTE switches in the context switch
code. I don't like the way this has been overloaded to mean
"BDI general operation." We should be able to attach a BDI2000
to any kernel configuration and always get kernel debugging
capability. The BDI_SWITCH was to enable the extra feature
(with some overhead) of debugging into user applications,
it never should have affected any kernel debug operation.
It's unfortunate that Book-E is such a PITA for debuggers,
but let's please find a better way of using these features.
Separate kernel configurations to enable hardware
debugging isn't acceptable.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] Fix 8250 probe on ppc32
From: David Woodhouse @ 2005-11-07 17:02 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Tom Rini, linuxppc-dev
In-Reply-To: <20051107165453.GA29111@lst.de>
On Mon, 2005-11-07 at 17:54 +0100, Christoph Hellwig wrote:
> What about putting that into the kernel tree so it can be built as
> part of make boot.
The mkzimage script? That doesn't make a lot of sense. The whole point
in that is to build the zImage _separately_ from the kernel. The kernel
is already capable of making the zImage by itself as part of the build
process.
Or do you just mean the trivial patch to make arch/ppc64/boot/ capable
of loading a 32-bit kernel? That'll make sense if that code gets moved
to arch/powerpc/boot, and I'll do so then.
--
dwmw2
^ permalink raw reply
* PPCBoot 2.0.0 Errors
From: Sette Agostino @ 2005-11-07 14:34 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I have the following problem at the PPCBoot startup:
PPCBoot 2.0.0 (Oct 20 2005 - 12:28:22)
CPU: unknown MPC859 (0x08010004) at 133 MHz: 16 kB I-Cache 8 kB D-Cache
FEC present
*** Warning: CPU Core has Silicon Bugs -- Check the Errata ***
Board: Siemens CCM
Watchdog enabled
DRAM: Restart Reason: 0xc0000000
32 MB
FLASH: 8 MB
In: serial
Out: serial
Err: serial
Restart Reason: 0xc0000000
PUMA: env. variable puma_addr undefined
Net: FEC ETHERNET
Furthermore, at the kernel startup I have:
## Booting image at 40180000 ...
Image Name: Linux-2.4.20-rthal5
Created: 2004-10-04 10:14:39 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 614355 Bytes = 599.10 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
IP-Config: Gateway not on directly connected network.
init started: BusyBox v0.60.5 (2003.11.19-14:32+0000) multi-callmount:
Mounting devpts on /dev/pts failed: No su
ch file or directory
/opt/rc.project: /opt/bin/sinfo: No such file or directory
export USER='root'
export HOME='/'
export wdt_8xx='timeout:120'
export TERM='linux'
export PATH='/usr/bin:/bin:/usr/sbin:/sbin'
export SHELL='/bin/sh'
export PWD='/'
export mem='32512k'
/opt/rc.project: /opt/bin/sinfo: No such file or directory
export USER='root'
export HOME='/'
export wdt_8xx='timeout:120'
export TERM='linux'
export PATH='/usr/bin:/bin:/usr/sbin:/sbin'
export SHELL='/bin/sh'
export PWD='/'
export mem='32512k'
Anybody experienced the same problem? Any suggestions about how to solve it?
Thanks in advance,
Agostino
^ permalink raw reply
* Re: [PATCH] Fix 8250 probe on ppc32
From: Christoph Hellwig @ 2005-11-07 16:54 UTC (permalink / raw)
To: David Woodhouse; +Cc: Tom Rini, linuxppc-dev
In-Reply-To: <1131380422.27347.72.camel@baythorne.infradead.org>
On Mon, Nov 07, 2005 at 04:20:22PM +0000, David Woodhouse wrote:
> Fedora's ppc64-utils package currently has a 'mkzimage' script and a
> bootloader stub based on what's in arch/ppc64/kernel, but modified to be
> capable of loading 32-bit kernels too. We can quite happily put together
> the stub, the vmlinux and the initrd after the fact.
What about putting that into the kernel tree so it can be built as part
of make boot.
^ permalink raw reply
* Re: Required functions for relocating not part of relocate section
From: Marcelo Tosatti @ 2005-11-07 11:48 UTC (permalink / raw)
To: Tom Rini; +Cc: Paul Mackerras, linux-ppc-embedded
In-Reply-To: <20051107162215.GE3839@smtp.west.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1819 bytes --]
On Mon, Nov 07, 2005 at 09:22:15AM -0700, Tom Rini wrote:
> On Fri, Nov 04, 2005 at 04:06:05PM -0200, Marcelo Tosatti wrote:
>
> > Hi Paul,
> >
> > Recent 2.6-git (from Wednesday) tree fails to boot on 8xx due to:
> [snip]
> > Problem is that flush_instruction_cache (and flush_data_cache)
> > from boot/common/util.S are not being copied to the relocate section,
> > even though the file contains the proper entry:
> >
> > .section ".relocate_code","xa"
> [snip]
> > The problem does not exist on v2.6.14.
>
> What version of binutils / etc? I recall a change in that area of code,
> but I thought it went in for 2.6.14..
marcelo@pegasos:~$ ld -v
GNU ld version 2.16.1 Debian GNU/Linux
marcelo@pegasos:~$ gcc -v
Reading specs from /usr/lib/gcc-lib/powerpc-linux/3.3.3/specs
Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc --disable-multilib powerpc-linux
Thread model: posix
gcc version 3.3.3 (Debian 20040401)
.config attached
To support an older bootloader the boards require (should not have
anything todo with the relocate section bug):
--- linux-2.6.14-rc4.orig/arch/ppc/boot/simple/head.S 2005-10-18 16:59:34.000000000 -0500
+++ linux-2.6.14-rc4/arch/ppc/boot/simple/head.S 2005-10-24 12:39:28.000000000 -0500
@@ -32,6 +32,17 @@
*
*/
+#ifdef CONFIG_PRxK
+ .globl start1
+start1: .long 0x00002120
+ .ascii "Entry Point\x00"
+ .long 0x00000000
+ .long 0x00000000
+ .long 0x00000000
+ .long 0x00000000
+#endif
+
+
.globl start
start:
bl start_
[-- Attachment #2: config-8xx --]
[-- Type: text/plain, Size: 16313 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.14
# Sat Nov 5 15:36:05 2005
#
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODULE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Processor
#
# CONFIG_6xx is not set
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
CONFIG_8xx=y
# CONFIG_E200 is not set
# CONFIG_E500 is not set
# CONFIG_MATH_EMULATION is not set
# CONFIG_KEXEC is not set
# CONFIG_CPU_FREQ is not set
# CONFIG_WANT_EARLY_SERIAL is not set
CONFIG_EMBEDDEDBOOT=y
CONFIG_NOT_COHERENT_CACHE=y
#
# Platform options
#
# CONFIG_RPXLITE is not set
# CONFIG_RPXCLASSIC is not set
# CONFIG_BSEIP is not set
# CONFIG_MPC8XXFADS is not set
# CONFIG_MPC86XADS is not set
# CONFIG_MPC885ADS is not set
# CONFIG_TQM823L is not set
# CONFIG_TQM850L is not set
# CONFIG_TQM855L is not set
# CONFIG_TQM860L is not set
CONFIG_PRxK=y
# CONFIG_FPS850L is not set
# CONFIG_IVMS8 is not set
# CONFIG_IVML24 is not set
# CONFIG_HERMES_PRO is not set
# CONFIG_IP860 is not set
# CONFIG_LWMON is not set
# CONFIG_PCU_E is not set
# CONFIG_CCM is not set
# CONFIG_LANTEC is not set
# CONFIG_MBX is not set
# CONFIG_WINCEPT is not set
# CONFIG_HIGHMEM is not set
CONFIG_HZ_100=y
# CONFIG_HZ_250 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=100
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_CMDLINE_BOOL is not set
# CONFIG_PM is not set
# CONFIG_SOFTWARE_SUSPEND is not set
# CONFIG_SECCOMP is not set
CONFIG_ISA_DMA_API=y
#
# Bus options
#
# CONFIG_PPC_I8259 is not set
# CONFIG_PCI is not set
# CONFIG_PCI_DOMAINS is not set
# CONFIG_PCI_QSPAN is not set
#
# PCCARD (PCMCIA/CardBus) support
#
CONFIG_PCCARD=m
# CONFIG_PCMCIA_DEBUG is not set
# CONFIG_PCMCIA is not set
#
# PC-card bridges
#
#
# Advanced setup
#
CONFIG_ADVANCED_OPTIONS=y
CONFIG_HIGHMEM_START=0xfe000000
# CONFIG_LOWMEM_SIZE_BOOL is not set
CONFIG_LOWMEM_SIZE=0x30000000
# CONFIG_KERNEL_START_BOOL is not set
CONFIG_KERNEL_START=0xc0000000
# CONFIG_TASK_SIZE_BOOL is not set
CONFIG_TASK_SIZE=0x80000000
CONFIG_CONSISTENT_START_BOOL=y
CONFIG_CONSISTENT_START=0xa0000000
# CONFIG_CONSISTENT_SIZE_BOOL is not set
CONFIG_CONSISTENT_SIZE=0x00200000
# CONFIG_BOOT_LOAD_BOOL is not set
CONFIG_BOOT_LOAD=0x00400000
# CONFIG_PIN_TLB is not set
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
CONFIG_IP_PNP=y
# CONFIG_IP_PNP_DHCP is not set
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y
#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
# CONFIG_NETFILTER_NETLINK is not set
#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
# CONFIG_IP_NF_CT_ACCT is not set
# CONFIG_IP_NF_CONNTRACK_MARK is not set
# CONFIG_IP_NF_CONNTRACK_EVENTS is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
CONFIG_IP_NF_FTP=y
# CONFIG_IP_NF_IRC is not set
# CONFIG_IP_NF_NETBIOS_NS is not set
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_PPTP is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
# CONFIG_IP_NF_MATCH_IPRANGE is not set
CONFIG_IP_NF_MATCH_MAC=y
# CONFIG_IP_NF_MATCH_PKTTYPE is not set
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
# CONFIG_IP_NF_MATCH_RECENT is not set
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_DSCP is not set
# CONFIG_IP_NF_MATCH_AH_ESP is not set
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
# CONFIG_IP_NF_MATCH_HELPER is not set
CONFIG_IP_NF_MATCH_STATE=y
# CONFIG_IP_NF_MATCH_CONNTRACK is not set
CONFIG_IP_NF_MATCH_OWNER=y
# CONFIG_IP_NF_MATCH_ADDRTYPE is not set
# CONFIG_IP_NF_MATCH_REALM is not set
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_DCCP is not set
# CONFIG_IP_NF_MATCH_COMMENT is not set
# CONFIG_IP_NF_MATCH_HASHLIMIT is not set
# CONFIG_IP_NF_MATCH_STRING is not set
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
# CONFIG_IP_NF_TARGET_ULOG is not set
CONFIG_IP_NF_TARGET_TCPMSS=y
# CONFIG_IP_NF_TARGET_NFQUEUE is not set
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
# CONFIG_IP_NF_TARGET_NETMAP is not set
# CONFIG_IP_NF_TARGET_SAME is not set
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
# CONFIG_IP_NF_TARGET_ECN is not set
# CONFIG_IP_NF_TARGET_DSCP is not set
CONFIG_IP_NF_TARGET_MARK=y
# CONFIG_IP_NF_TARGET_CLASSIFY is not set
# CONFIG_IP_NF_TARGET_TTL is not set
# CONFIG_IP_NF_RAW is not set
# CONFIG_IP_NF_ARPTABLES is not set
#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set
#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_SCHED is not set
# CONFIG_NET_CLS_ROUTE is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Plug and Play support
#
#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=126976
CONFIG_BLK_DEV_INITRD=y
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"
# CONFIG_ATA_OVER_ETH is not set
#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
#
# I2O device support
#
#
# Macintosh device drivers
#
#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
#
# PHY device support
#
# CONFIG_PHYLIB is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_FEC_8XX=y
CONFIG_FEC_8XX_GENERIC_PHY=y
# CONFIG_FEC_8XX_DM9161_PHY is not set
CONFIG_FEC_8XX_LXT971_PHY=y
#
# Ethernet (1000 Mbit)
#
#
# Ethernet (10000 Mbit)
#
#
# Token Ring devices
#
#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y
#
# Obsolete Wireless cards support (pre-802.11)
#
# CONFIG_STRIP is not set
# CONFIG_ATMEL is not set
# CONFIG_HOSTAP is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
# CONFIG_PPP_FILTER is not set
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
# CONFIG_PPP_DEFLATE is not set
# CONFIG_PPP_BSDCOMP is not set
# CONFIG_PPPOE is not set
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
# CONFIG_SLIP_SMART is not set
# CONFIG_SLIP_MODE_SLIP6 is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
#
# ISDN subsystem
#
CONFIG_ISDN=m
#
# Old ISDN4Linux
#
# CONFIG_ISDN_I4L is not set
#
# CAPI subsystem
#
# CONFIG_ISDN_CAPI is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
# CONFIG_INPUT is not set
#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
# CONFIG_VT is not set
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_CPM=y
CONFIG_SERIAL_CPM_CONSOLE=y
CONFIG_SERIAL_CPM_SCC1=y
# CONFIG_SERIAL_CPM_SCC2 is not set
# CONFIG_SERIAL_CPM_SCC3 is not set
# CONFIG_SERIAL_CPM_SCC4 is not set
CONFIG_SERIAL_CPM_SMC1=y
CONFIG_SERIAL_CPM_SMC2=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
CONFIG_8xx_WDT=y
# CONFIG_NVRAM is not set
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_AGP is not set
# CONFIG_RAW_DRIVER is not set
#
# TPM devices
#
# CONFIG_TELCLOCK is not set
#
# I2C support
#
# CONFIG_I2C is not set
#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
#
# Hardware Monitoring support
#
# CONFIG_HWMON is not set
# CONFIG_HWMON_VID is not set
#
# Misc devices
#
#
# Multimedia Capabilities Port drivers
#
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
#
# Graphics support
#
# CONFIG_FB is not set
#
# Sound
#
# CONFIG_SOUND is not set
#
# USB support
#
# CONFIG_USB_ARCH_HAS_HCD is not set
# CONFIG_USB_ARCH_HAS_OHCI is not set
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# MMC/SD Card support
#
# CONFIG_MMC is not set
#
# InfiniBand support
#
#
# SN Devices
#
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=m
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_TMPFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_RELAYFS_FS is not set
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
#
# MPC8xx CPM Options
#
# CONFIG_SCC_ENET is not set
# CONFIG_FEC_ENET is not set
#
# Generic MPC8xx Options
#
CONFIG_8xx_COPYBACK=y
CONFIG_8xx_CPU6=y
# CONFIG_NO_UCODE_PATCH is not set
# CONFIG_USB_SOF_UCODE_PATCH is not set
CONFIG_I2C_SPI_UCODE_PATCH=y
# CONFIG_I2C_SPI_SMC1_UCODE_PATCH is not set
CONFIG_UCODE_PATCH=y
#
# Library routines
#
CONFIG_CRC_CCITT=m
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
#
# Profiling support
#
# CONFIG_PROFILING is not set
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_DEBUG_KERNEL is not set
CONFIG_LOG_BUF_SHIFT=14
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
# CONFIG_CRYPTO is not set
#
# Hardware crypto devices
#
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Tom Rini @ 2005-11-07 15:51 UTC (permalink / raw)
To: Marcelo Tosatti
Cc: linuxppc-embedded, Dan Malek, Joakim Tjernlund, gtolstolytkin
In-Reply-To: <20051107101618.GA15522@logos.cnet>
On Mon, Nov 07, 2005 at 08:16:18AM -0200, Marcelo Tosatti wrote:
> Joakim!
>
> On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim Tjernlund wrote:
> > Hi Marcelo
> >
> > [SNIP]
> > > The root of the problem are the changes against the 8xx TLB
> > > handlers introduced
> > > during v2.6. What happens is the TLBMiss handlers load the
> > > zeroed pte into
> > > the TLB, causing the TLBError handler to be invoked (thats
> > > two TLB faults per
> > > pagefault), which then jumps to the generic MM code to setup the pte.
> > >
> > > The bug is that the zeroed TLB is not invalidated (the same reason
> > > for the "dcbst" misbehaviour), resulting in infinite TLBError faults.
> > >
> > > Dan, I wonder why we just don't go back to v2.4 behaviour.
> >
> > This is one reason why it is the way it is:
> > http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016382.html
> > This details are little fuzzy ATM, but I think the reason for the
> > current
> > impl. was only that it was less intrusive to impl.
>
> Ah, I see. I wonder if the bug is processor specific: we don't have such
> changes in our v2.4 tree and never experienced such problem.
>
> It should be pretty easy to hit it right? (instruction pagefaults should
> fail).
>
> Grigori, Tom, can you enlight us about the issue on the URL above. How
> can it be triggered?
So after looking at the code in 2.6.14 and current git, I think the
above URL isn't relevant, unless there was a change I missed (which
could totally be possible) that reverted the patch there and fixed that
issue in a different manner. But since I didn't figure that out until I
had finished researching it again:
Switching hats for a minute, this came from a bug a customer of
MontaVista found, so I can't give out the testcase :(
To repeat what Joakim said back then:
"I think I have figured this out. The first TLB misses that happen at
app startup is Data TLB misses. These will then hit the NULL L1 entry
and end up in do_page_fault() which will populate the L1 entry. But when
you have a very large app that spans more than one L1 entry (16 MB I
think) it may happen that you will have I-TLB Miss first one of the L1
entrys which will make the I-TLB handler bail out to do_page_fault() and
the app craches(SEGV)."
Looking at the patch again, what I don't see is why I talk about fudging
I-TLB Miss at 0x400 when it's I-TLB Error we fudge at being there, but
then get hung up that there can be a slight diff between the two ("This
is because we check bit 4 of SRR1 in both cases, but in the case of an
I-TLB Miss, this bit is always set, and it only indicates a protection
fault on an I-TLB Error.") so instead of 0x1300 jumping to the handler
at 0x400, we treat it like a regular exception so we know where we came
from, and perhaps missed fixing a case somewhere?
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] Fix 8250 probe on ppc32
From: Tom Rini @ 2005-11-07 16:31 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1131380422.27347.72.camel@baythorne.infradead.org>
On Mon, Nov 07, 2005 at 04:20:22PM +0000, David Woodhouse wrote:
> On Mon, 2005-11-07 at 09:09 -0700, Tom Rini wrote:
> > That depends on what we're going to expect out of arch/powerpc/boot,
> > which I'm talking with Paul about.
>
> I'd be quite happy to see the bootloader code kept separate from the
> kernel in future.
>
> Fedora's ppc64-utils package currently has a 'mkzimage' script and a
> bootloader stub based on what's in arch/ppc64/kernel, but modified to be
> capable of loading 32-bit kernels too. We can quite happily put together
> the stub, the vmlinux and the initrd after the fact.
I've always found it quite handy, and thought it was a good new user
experiance that they could just build and boot the kernel with just the
kernel tarball around. If everything going forward ships from the hw
vendor with U-Boot, that's less of an issue, but I don't know how likely
!Freescale is to change.
> I don't really see why any of the other stubs necessarily need to live
> with the kernel either.
Avoiding duplication of hardware defines (serial, whack-a-device, etc)
has been part of it.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* BDI and 85xx
From: Marcelo Tosatti @ 2005-11-07 11:24 UTC (permalink / raw)
To: linux-ppc-embedded; +Cc: Edson Seabra
FYI
Edson had to patch this in to get BDI to work on 85xx with 2.6.14.
--- /home/edson/linux-2.6.14/Makefile 2005-10-27 17:02:08.000000000 -0700
+++ Makefile 2005-11-02 10:32:00.000000000 -0800
@@ -524,7 +524,7 @@
endif
ifdef CONFIG_DEBUG_INFO
-CFLAGS += -g
+CFLAGS += -g -ggdb
endif
include $(srctree)/arch/$(ARCH)/Makefile
--- /home/edson/linux-2.6.14/arch/ppc/kernel/head_fsl_booke.S 2005-10-27 17:02:08.000000000 -0700
+++ arch/ppc/kernel/head_fsl_booke.S 2005-11-02 19:59:21.000000000 -0800
@@ -187,6 +187,10 @@
xori r6,r4,1
slwi r6,r6,5 /* setup new context with other address space */
+#if defined(CONFIG_BDI_SWITCH)
+ mfmsr r9
+ rlwimi r6,r9,0,22,22 /* preserve MSR[DE] */
+#endif
bl 1f /* Find our address */
1: mflr r9
rlwimi r7,r9,0,20,31
@@ -238,6 +242,10 @@
/* 7. Jump to KERNELBASE mapping */
lis r7,MSR_KERNEL@h
ori r7,r7,MSR_KERNEL@l
+#if defined(CONFIG_BDI_SWITCH)
+ mfmsr r9
+ rlwimi r7,r9,0,22,22 /* preserve MSR[DE] */
+#endif
bl 1f /* Find our address */
1: mflr r9
rlwimi r6,r9,0,20,31
@@ -371,6 +379,10 @@
ori r4,r4,start_kernel@l
lis r3,MSR_KERNEL@h
ori r3,r3,MSR_KERNEL@l
+#if defined(CONFIG_BDI_SWITCH)
+ mfmsr r5
+ rlwimi r3,r5,0,22,22 /* preserve MSR[DE] */
+#endif
mtspr SPRN_SRR0,r4
mtspr SPRN_SRR1,r3
rfi /* change context and jump to start_kernel */
--- /home/edson/linux-2.6.14/arch/ppc/kernel/process.c 2005-10-27 17:02:08.000000000 -0700
+++ arch/ppc/kernel/process.c 2005-11-02 19:33:12.000000000 -0800
@@ -473,6 +473,10 @@
regs->nip = nip;
regs->gpr[1] = sp;
regs->msr = MSR_USER;
+#if (defined(CONFIG_BOOKE) && defined(CONFIG_BDI_SWITCH))
+ /* propagate the debug enable bit for BDI support */
+ regs->msr |= (mfmsr() & MSR_DE);
+#endif
if (last_task_used_math == current)
last_task_used_math = NULL;
if (last_task_used_altivec == current)
^ permalink raw reply
* Re: Required functions for relocating not part of relocate section
From: Tom Rini @ 2005-11-07 16:22 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Paul Mackerras, linux-ppc-embedded
In-Reply-To: <20051104180605.GA3271@logos.cnet>
On Fri, Nov 04, 2005 at 04:06:05PM -0200, Marcelo Tosatti wrote:
> Hi Paul,
>
> Recent 2.6-git (from Wednesday) tree fails to boot on 8xx due to:
[snip]
> Problem is that flush_instruction_cache (and flush_data_cache)
> from boot/common/util.S are not being copied to the relocate section,
> even though the file contains the proper entry:
>
> .section ".relocate_code","xa"
[snip]
> The problem does not exist on v2.6.14.
What version of binutils / etc? I recall a change in that area of code,
but I thought it went in for 2.6.14..
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] Fix 8250 probe on ppc32
From: David Woodhouse @ 2005-11-07 16:20 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20051107160939.GD3839@smtp.west.cox.net>
On Mon, 2005-11-07 at 09:09 -0700, Tom Rini wrote:
> That depends on what we're going to expect out of arch/powerpc/boot,
> which I'm talking with Paul about.
I'd be quite happy to see the bootloader code kept separate from the
kernel in future.
Fedora's ppc64-utils package currently has a 'mkzimage' script and a
bootloader stub based on what's in arch/ppc64/kernel, but modified to be
capable of loading 32-bit kernels too. We can quite happily put together
the stub, the vmlinux and the initrd after the fact.
I don't really see why any of the other stubs necessarily need to live
with the kernel either.
--
dwmw2
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Marcelo Tosatti @ 2005-11-07 11:12 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Tom Rini, linuxppc-embedded, Dan Malek, gtolstolytkin
In-Reply-To: <F6AD7E21CDF4E145A44F61F43EE6D9393FD5B5@tmnt04.transmode.se>
On Mon, Nov 07, 2005 at 04:44:32PM +0100, Joakim Tjernlund wrote:
>
> > Joakim!
> >
> > On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim Tjernlund wrote:
> > > Hi Marcelo
> > >
> > > [SNIP]
> > > > The root of the problem are the changes against the 8xx TLB
> > > > handlers introduced
> > > > during v2.6. What happens is the TLBMiss handlers load the
> > > > zeroed pte into
> > > > the TLB, causing the TLBError handler to be invoked (thats
> > > > two TLB faults per
> > > > pagefault), which then jumps to the generic MM code to
> > setup the pte.
> > > >
> > > > The bug is that the zeroed TLB is not invalidated (the same reason
> > > > for the "dcbst" misbehaviour), resulting in infinite
> > TLBError faults.
> > > >
> > > > Dan, I wonder why we just don't go back to v2.4 behaviour.
> > >
> > > This is one reason why it is the way it is:
> > >
> > http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016382.html
> > > This details are little fuzzy ATM, but I think the reason for the
> > > current
> > > impl. was only that it was less intrusive to impl.
> >
> > Ah, I see. I wonder if the bug is processor specific: we
> > don't have such
> > changes in our v2.4 tree and never experienced such problem.
> >
> > It should be pretty easy to hit it right? (instruction
> > pagefaults should
> > fail).
>
> No, its pretty hard to trigger it. Read the all mails on the subject to
> see why.
> The one or two exception approach doesn't matter performancewise(at
> least for ITLB exceptions)
> I think.
Fine, let it continue the way it is then.
^ permalink raw reply
* Re: [PATCH] Fix 8250 probe on ppc32
From: Tom Rini @ 2005-11-07 16:09 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1131357857.27347.28.camel@baythorne.infradead.org>
On Mon, Nov 07, 2005 at 10:04:17AM +0000, David Woodhouse wrote:
> This fairly much obsoletes include/asm-ppc/pc_serial.h -- other machines
> with 8250 ports which are currently responsible for the mess in
> include/asm-ppc/serial.h itself should be converted to a platform_device
> of their own before they become supported in arch/powerpc.
That depends on what we're going to expect out of arch/powerpc/boot,
which I'm talking with Paul about. But..
> --- /dev/null 2005-10-08 11:44:47.528646500 +0100
> +++ b/drivers/serial/8250_of.c 2005-11-07 09:51:22.000000000 +0000
> @@ -0,0 +1,197 @@
> +#include <linux/kernel.h>
[snip]
> +#if 0
> +#define DBG(fmt...) printk(KERN_DEBUG fmt)
> +#else
> +#define DBG(fmt...) do { } while (0)
> +#endif
pr_debug(), line wrap and a legal boilerplate
(arch/ppc/platforms/lopec.c has the smallest one our laywers could come
up with) ? :)
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Dan Malek @ 2005-11-07 16:02 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-embedded
In-Reply-To: <F6AD7E21CDF4E145A44F61F43EE6D9393FD5A2@tmnt04.transmode.se>
On Nov 7, 2005, at 9:32 AM, Joakim Tjernlund wrote:
> This is one reason why it is the way it is:
Oh geeze, what a hack! :-) This could have been fixed
with a line of assembler code in the TLB miss exception.
I'll take a look at all of this and fix it up.
Thanks.
-- Dan
^ permalink raw reply
* RE: [PATCH 2.6.14] mm: 8xx MM fix for
From: Joakim Tjernlund @ 2005-11-07 15:44 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Tom Rini, linuxppc-embedded, Dan Malek, gtolstolytkin
=20
> Joakim!
>=20
> On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim Tjernlund wrote:
> > Hi Marcelo
> >=20
> > [SNIP]=20
> > > The root of the problem are the changes against the 8xx TLB=20
> > > handlers introduced
> > > during v2.6. What happens is the TLBMiss handlers load the=20
> > > zeroed pte into
> > > the TLB, causing the TLBError handler to be invoked (thats=20
> > > two TLB faults per=20
> > > pagefault), which then jumps to the generic MM code to=20
> setup the pte.
> > >=20
> > > The bug is that the zeroed TLB is not invalidated (the same reason
> > > for the "dcbst" misbehaviour), resulting in infinite=20
> TLBError faults.
> > >=20
> > > Dan, I wonder why we just don't go back to v2.4 behaviour.
> >=20
> > This is one reason why it is the way it is:
> >=20
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016382.html
> > This details are little fuzzy ATM, but I think the reason for the
> > current
> > impl. was only that it was less intrusive to impl.
>=20
> Ah, I see. I wonder if the bug is processor specific: we=20
> don't have such
> changes in our v2.4 tree and never experienced such problem.
>=20
> It should be pretty easy to hit it right? (instruction=20
> pagefaults should
> fail).
No, its pretty hard to trigger it. Read the all mails on the subject to
see why.
The one or two exception approach doesn't matter performancewise(at
least for ITLB exceptions)
I think.
>=20
> Grigori, Tom, can you enlight us about the issue on the URL above. How
> can it be triggered?
>=20
>=20
>=20
>=20
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Marcelo Tosatti @ 2005-11-07 10:27 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <6564e160d322329703e5ab866d98618b@embeddedalley.com>
On Mon, Nov 07, 2005 at 09:35:59AM -0500, Dan Malek wrote:
>
> On Nov 7, 2005, at 3:44 AM, Marcelo Tosatti wrote:
>
> >Dan, I wonder why we just don't go back to v2.4 behaviour. It is not
> >very
> >clear to me that "two exception" speedup offsets the additional code
> >required
> >for "one exception" version. Have you actually done any measurements?
>
> No, and I didn't actually make these changes, either :-)
Ahh, ok. sorry. I remember you arguing that it was faster this way (less
code).
> I'm working on some 8xx debugging right now, so let's experiment
> with some changes. I don't understand why other processors, especially
> G2 cores like 82xx, aren't finding the same problems we are having
> with 8xx. Logically, we are all doing the same thing, unless there are
> some tlb invalidates on these other processors that I'm forgetting
> about.
I really dont know how the 82xx TLB works, so...
> We just seem to be running into stale entries, and we have to fix it.
Right - the issue Joakim noted would be one reason for the "two exception"
approach.
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Marcelo Tosatti @ 2005-11-07 10:16 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Tom Rini, linuxppc-embedded, Dan Malek, gtolstolytkin
In-Reply-To: <F6AD7E21CDF4E145A44F61F43EE6D9393FD5A2@tmnt04.transmode.se>
Joakim!
On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim Tjernlund wrote:
> Hi Marcelo
>
> [SNIP]
> > The root of the problem are the changes against the 8xx TLB
> > handlers introduced
> > during v2.6. What happens is the TLBMiss handlers load the
> > zeroed pte into
> > the TLB, causing the TLBError handler to be invoked (thats
> > two TLB faults per
> > pagefault), which then jumps to the generic MM code to setup the pte.
> >
> > The bug is that the zeroed TLB is not invalidated (the same reason
> > for the "dcbst" misbehaviour), resulting in infinite TLBError faults.
> >
> > Dan, I wonder why we just don't go back to v2.4 behaviour.
>
> This is one reason why it is the way it is:
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016382.html
> This details are little fuzzy ATM, but I think the reason for the
> current
> impl. was only that it was less intrusive to impl.
Ah, I see. I wonder if the bug is processor specific: we don't have such
changes in our v2.4 tree and never experienced such problem.
It should be pretty easy to hit it right? (instruction pagefaults should
fail).
Grigori, Tom, can you enlight us about the issue on the URL above. How
can it be triggered?
^ permalink raw reply
* Re: 2.6.14 USB vs. sleep issues
From: Wolfram Quester @ 2005-11-07 14:54 UTC (permalink / raw)
To: Charles-Edouard Ruault; +Cc: debian-powerpc@lists.debian.org, linuxppc-dev list
In-Reply-To: <436F1A9E.80105@idtect.com>
[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]
Hi Charles-Edouard,
On Mon, Nov 07, 2005 at 10:13:02AM +0100, Charles-Edouard Ruault wrote:
[...snip...]
> Hi Ben,
> i've applied your patch and it seems that when i put my powerbook to
> sleep ( by closing the lid ) the kernel just crashes since everytime i
> come back, the machine is turned off. I had a look at the logs and i see
> that i'm having a reboot almost immediateley after the lid is closed.
> However i've got no trace of a kernel panic .....
> my conf:
>
> Linux kaluha 2.6.14 #1 PREEMPT Mon Oct 31 10:28:22 CET 2005 ppc GNU/Linux
> processor : 0
> cpu : 7447/7457, altivec supported
> clock : 612MHz
> revision : 0.1 (pvr 8002 0101)
> bogomips : 406.52
> machine : PowerBook5,2
> motherboard : PowerBook5,2 MacRISC3 Power Macintosh
> detected as : 287 (PowerBook G4 15")
> pmac flags : 0000001b
> L2 cache : 512K unified
> memory : 768MB
> pmac-generation : NewWorld
>
> I have a usb mouse that i unplug before closing the lid.
> Anything else that can be usefull ?
> Thanks for your time.
> Regards.
In a recent email to this list, Benjamin Herrenschmidt wrote:
> > >
> > > I would say your first mistake is to use PREEMPT :) There are
> > > various
> > > issues with PREEMPT on ppc32 that have not really been addressed so
> > > far,
> > > and the USB code has some "holes" that I wouldn't trust in a PREEMPT
> > > environment.
> > >
> >
> > What do you mean exactly? Should CONFIG_PREEMPT not be used?
> > And what about CONFIG_PREEMPT_VOLUNTARY?
>
> I would avoid both for now.
>
> Ben.
If I interpret your version string correctly, you also havre preemption
enabled. Please try without and report back success and/or problems.
With best regards,
Wolfi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: David Jander @ 2005-11-07 14:58 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051107084431.GA15180@logos.cnet>
On Monday 07 November 2005 09:44, Marcelo Tosatti wrote:
> Seems the bug is exposed by the change which avoids flushing the
> TLB when not necessary (in case the pte has not changed), introduced
> recently:
>[...]
Brilliant!
I just checked, and now it boots again.
Btw, it did boot before this patch, but taking about 2 or 3 hours to get
halfway through the init scripts ;-)
Thanks for the good work!
--
David Jander
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Pantelis Antoniou @ 2005-11-07 14:39 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded, Dan Malek
In-Reply-To: <20051107084431.GA15180@logos.cnet>
Marcelo Tosatti wrote:
> Hi folks,
>
> Seems the bug is exposed by the change which avoids flushing the
> TLB when not necessary (in case the pte has not changed), introduced
> recently:
>
[snip]
>
>
Good job Marcelo! :)
FWIW I'd rather have the single exception version if at all possible.
Regards
Pantelis
^ 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