Hello,
Heiko Schocher wrote:
making a powerpc target with PCI support, shows the
following warning:
MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x10430): Section mismatch in reference from the
function pcibios_allocate_bus_resources() to the function
.init.text:reparent_resources()
Benjamin Herrenschmidt wrote:
On Fri, 2009-09-25 at 18:01 +0900, Tejun Heo wrote:
With this patch applied the machine boots OK :-)
Ah... so, the problem really is too high address. If you've got some
time, it might be interesting to find out how far high is safe.
Might give
Hollis Blanchard holl...@us.ibm.com 02.10.09 17:48
On Wed, 2009-09-30 at 07:35 +0100, Jan Beulich wrote:
The one Rusty suggested the other day may help here. I don't like it
as a drop-in replacement for BUILD_BUG_ON() though (due to it
deferring the error generated to the linking stage), I'd
- serial Console on PSC1
- 64MB SDRAM
- MTD CFI Flash
- Ethernet FEC
- IDE support
Signed-off-by: Heiko Schocher h...@denx.de
---
- based on:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next
- checked with:
$ ./scripts/checkpatch.pl
- serial Console on PSC1
- 64MB SDRAM
- MTD CFI Flash
- Ethernet FEC
- IDE support
Signed-off-by: Heiko Schocher h...@denx.de
---
- based on:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next
- checked with:
$ ./scripts/checkpatch.pl
Hello,
I am newbie in embeded linux on PowerPC,
and in few last weeks i fight with PCI device.
On MPC8323E-RDB lspci -vv return:
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6105 [Rhine-III]
(rev 86)
Subsystem: VIA Technologies, Inc. Unknown device 0105
Control: I/O+
From: Gala Kumar-B11780
Sent: Friday, September 25, 2009 12:08 AM
+ mbar(1);
why isn't eieio() sufficient here?
When I initially added / tested cache SRAM for P2020RDB, its RM talked
about using mbar() though mbar(1) is identical to eieio() opcode-wise.
Also as cache-sram works only for
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 04/10/2009 22:28:38:
I have managed to update the TLB code to make proper use of dirty and
accessed states.
Advantages are:
- I/D TLB Miss never needs to write to the linux pte, saving a few cycles
That's good, that leaves us
On Mon, Oct 05, 2009 at 09:46:43AM +0200, Heiko Schocher wrote:
- serial Console on PSC1
- 64MB SDRAM
- MTD CFI Flash
- Ethernet FEC
- IDE support
Signed-off-by: Heiko Schocher h...@denx.de
---
- based on:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next
-
Hello Wolfram,
Wolfram Sang wrote:
On Mon, Oct 05, 2009 at 09:46:43AM +0200, Heiko Schocher wrote:
- serial Console on PSC1
- 64MB SDRAM
- MTD CFI Flash
- Ethernet FEC
- IDE support
Signed-off-by: Heiko Schocher h...@denx.de
[...]
[...]
+wdt {
+
Here are my latest code to fixup 8xx's TLB code.
This code needs some serious testing before it
can be commited.
The 8xx, fault: Add some debug code to do_page_fault() is
purely a debug check and will be removed/disabled when
this series appear stable.
Scott and Rex, please disregard other
DataTLBError currently does:
if ((err 0x0200) == 0)
DSI();
This won't handle a store with no valid translation.
Change this to
if ((err 0x4800) != 0)
DSI();
that is, branch to DSI if either !permission or
!translation.
---
arch/powerpc/kernel/head_8xx.S |4 ++--
1 files
This is an assembler version to fixup DAR not being set
by dcbX, icbi instructions. There are two versions, one
uses selfmodifing code(default), the other uses
jump table but is much bigger.
---
arch/powerpc/kernel/head_8xx.S | 146 +++-
1 files changed, 145
---
arch/powerpc/mm/fault.c | 82 +++
1 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 7699394..c33c6de 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -139,6
dcbz, dcbf, dcbi, dcbst and icbi do not set DAR when they
cause a DTLB Error. Dectect this by tagging DAR with 0x00f0
at every exception exit that modifies DAR.
Test for DAR=0x00f0 in DataTLBError and bail
to handle_page_fault().
---
arch/powerpc/kernel/head_8xx.S | 19 ---
1
Now that 8xx can fixup dcbX instructions, start using them
where possible like every other PowerPc arch do.
---
arch/powerpc/kernel/misc_32.S | 18 --
arch/powerpc/lib/copy_32.S| 24
2 files changed, 0 insertions(+), 42 deletions(-)
diff --git
Resending pasemi_mac ethtool patches...
Valentine Barshak wrote:
Not all pasemi mac interfaces can have a phy attached.
For example, XAUI has no phy and phydev is NULL for it.
In this case ethtool get settings causes kernel crash.
Fix it by returning -EOPNOTSUPP if there's no PHY attached.
Not all pasemi mac interfaces can have a phy attached.
For example, XAUI has no phy and phydev is NULL for it.
In this case ethtool get settings causes kernel crash.
Fix it by returning -EOPNOTSUPP if there's no PHY attached.
Signed-off-by: Valentine Barshak vbars...@ru.mvista.com
---
Add ethtool set settings to pasemi_mac_ethtool.
Signed-off-by: Valentine Barshak vbars...@ru.mvista.com
---
drivers/net/pasemi_mac_ethtool.c | 14 ++
1 file changed, 14 insertions(+)
diff -pruN linux-2.6.orig/drivers/net/pasemi_mac_ethtool.c
On Mon, Oct 5, 2009 at 4:12 AM, Heiko Schocher h...@denx.de wrote:
Wolfram Sang wrote:
Is this an official binding? I also did an gpio-watchdog a while ago and
there
were some issues with the binding, IIRC. Would be nice if this has been
solved
meanwhile.
Oh, sorry, no. I remove it.
You
On Thu, Oct 1, 2009 at 10:19 AM, Joe Shmo spamrecep...@yahoo.com wrote:
I'm attempting to get SPI to work on my embedded design
that is based on the mpc8313erbd reference board wiht a
2.6.27 kernel. I cannot open the SPI device.
Tracing through the kernel code, it looks like the device
Prior to the arch/ppc - arch/powerpc transition, xmon had support for single
stepping on 4xx boards. The functionality was lost when arch/ppc was removed.
This patch restores single step support for 44x boards, and Book-E in general.
Signed-off-by: Josh Boyer jwbo...@linux.vnet.ibm.com
---
On Oct 5, 2009, at 2:15 AM, Mahajan Vivek-B08308 wrote:
From: Gala Kumar-B11780
Sent: Friday, September 25, 2009 12:08 AM
+ mbar(1);
why isn't eieio() sufficient here?
When I initially added / tested cache SRAM for P2020RDB, its RM talked
about using mbar() though mbar(1) is
There was a fix a while back called Correct memory size calculation for
Denali based boards that corrected the data width detection in the 4xx
bootwrapper.
This seems to have had the unintended consequence of exposing another
bug in the same code. I have a board very similar to Sequoia, except
Hi Mike,
Address width calculation is based on the DDR-controller configuration
set by the bootloader. It would be helpful for further discussion if you
could send DDR0_00..DDR0_44 register values and memory configuration
used (no of banks, bank size, I/O width) to check calculations. Thanks.
(top-posting corrected)
Mikhail Zolotaryov wrote:
Mike Nuss wrote:
There was a fix a while back called Correct memory size calculation
for Denali based boards that corrected the data width detection in
the 4xx bootwrapper.
This seems to have had the unintended consequence of exposing
Valentine wrote:
AFAIK, u-boot just writes pre-defined values to the memory controller
registers. It doesn't do any chiptype/memsize detection. These values
are set for Sequoia and may not suite your board. So you probably need
to adjust the u-boot to make linux detect the memory size
Hi Mike,
you wrote:
Row address bits : 13
DDR0_02 = 0x020C0E01
DDR0_42 = 0x0006
Register values above define that memory has 14 row address bits. The
correct setting is (for CAS Latency = 3):
DDR0_42 = 0x0106
Best regards,
Mikhail Zolotaryov
Mike Nuss wrote:
(top-posting
Mikhail Zolotaryov wrote:
Hi Mike,
you wrote:
Row address bits : 13
DDR0_02 = 0x020C0E01
DDR0_42 = 0x0006
Register values above define that memory has 14 row address bits. The
correct setting is (for CAS Latency = 3):
DDR0_42 = 0x0106
Best regards,
Mikhail Zolotaryov
This patch adds a method for defining different microcodes than the pe-defined
ones for the MPC52xx's BestComm General Buffer Descriptor (gen_db) tasks. The
default microcode is still the one from bcom_gen_bd_[rt]x_task, but it can be
replaced by calling bcom_gen_bd_set_microcode() which is
Just as with kexec, hibernation may fail even on well-tested platforms:
some PCI device, a driver of which doesn't play well with hibernation,
is enough to break resuming.
Hibernation code is not much platform dependent, and hiding features only
because these were not verified on a particular
On Mon, Oct 05, 2009 at 02:16:33PM +0200, Joakim Tjernlund wrote:
Here are my latest code to fixup 8xx's TLB code.
This code needs some serious testing before it
can be commited.
The 8xx, fault: Add some debug code to do_page_fault() is
purely a debug check and will be removed/disabled when
Scott Wood scottw...@freescale.com wrote on 05/10/2009 20:12:34:
On Mon, Oct 05, 2009 at 02:16:33PM +0200, Joakim Tjernlund wrote:
Here are my latest code to fixup 8xx's TLB code.
This code needs some serious testing before it
can be commited.
The 8xx, fault: Add some debug code to
Scott Wood scottw...@freescale.com wrote on 05/10/2009 20:24:29:
On Sat, Oct 03, 2009 at 10:05:46AM +0200, Joakim Tjernlund wrote:
Scott Wood scottw...@freescale.com wrote on 02/10/2009 23:49:49:
Adding a tlbil_va to do_page_fault makes the problem go away for me (on
top of your merge
On Sat, Oct 03, 2009 at 08:04:33AM +1000, Benjamin Herrenschmidt wrote:
On Fri, 2009-10-02 at 16:49 -0500, Scott Wood wrote:
Adding a tlbil_va to do_page_fault makes the problem go away for me (on
top of your merge branch) -- none of the other changes in this thread
do (assuming I didn't
Am 05.10.09 20:16 schrieb(en) Grant Likely:
Hmmm. I've not been comfortable with this change, but it took me a while to
put my finger on exactly why. In principle, I think it is a good idea.
However, I don't want to merge it without any in-tree users.
I could provide my modified microcode
On Mon, Oct 05, 2009 at 08:27:39PM +0200, Joakim Tjernlund wrote:
After resolving the conflict, without adding tlbil_va in do_page_fault(), I
get the same stuck behavior as before.
Expected, I havn't not tried to fix the missing tlbil_va(). That is
different problem that you and Ben needs
On Mon, 2009-10-05 at 14:16 +0200, Joakim Tjernlund wrote:
Update the TLB asm to make proper use of _PAGE_DIRY and _PAGE_ACCESSED.
Pros:
- I/D TLB Miss never needs to write to the linux pte.
- _PAGE_ACCESSED is only set on I/D TLB Error fixing accounting
- _PAGE_DIRTY is mapped to 0x100,
On Mon, 2009-10-05 at 09:25 -0400, Steven Rostedt wrote:
Sachin, can you give me more details on how you built that kernel ? (or
give them again in case I missed them the first time around :-), ie,
what toolchain, options, etc... or even better, give me remote access to
the build host
On Mon, 2009-10-05 at 21:16 +0200, Joakim Tjernlund wrote:
Ben, for my understanding: It seems to that the TLB Miss routines in
head_32.S are less than optimal as it too touches the pte every time
it hits. Would it not be better to test if ACCESSED and friends are
already set
and skip storing
On Mon, 2009-10-05 at 14:28 -0500, Scott Wood wrote:
Yes, it hits ptep_set_access_flags() and adding _tlbil_va there helps (I
didn't put it in the filter function, because that doesn't take address as a
parameter). I'd misread your suggestion as referring to the various changes
to
On Tue, 2009-10-06 at 07:20 +1100, Benjamin Herrenschmidt wrote:
On Mon, 2009-10-05 at 09:25 -0400, Steven Rostedt wrote:
Sachin, can you give me more details on how you built that kernel ? (or
give them again in case I missed them the first time around :-), ie,
what toolchain,
Benjamin Herrenschmidt wrote:
On Mon, 2009-10-05 at 14:28 -0500, Scott Wood wrote:
Yes, it hits ptep_set_access_flags() and adding _tlbil_va there helps (I
didn't put it in the filter function, because that doesn't take address as a
parameter). I'd misread your suggestion as referring to the
Scott Wood scottw...@freescale.com wrote on 05/10/2009 22:09:41:
On Mon, Oct 05, 2009 at 08:27:39PM +0200, Joakim Tjernlund wrote:
After resolving the conflict, without adding tlbil_va in do_page_fault(),
I
get the same stuck behavior as before.
Expected, I havn't not tried to fix
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 05/10/2009 22:17:04:
On Mon, 2009-10-05 at 14:16 +0200, Joakim Tjernlund wrote:
Update the TLB asm to make proper use of _PAGE_DIRY and _PAGE_ACCESSED.
Pros:
- I/D TLB Miss never needs to write to the linux pte.
-
Joakim Tjernlund wrote:
Yes, every ld.so uses dcbX and icbi insn when relocatin code.
Maybe you see some version of the dcbX bug, but my fault.c should
fix them up. My bet would be the 32 byte cache line, it will miss
out every second line and so the results are unreliable.
I found the 32-byte
On Mon, 2009-10-05 at 23:04 +0200, Joakim Tjernlund wrote:
Yes, every ld.so uses dcbX and icbi insn when relocatin code.
Even with -msecure-plt ?
Maybe you see some version of the dcbX bug, but my fault.c should
fix them up. My bet would be the 32 byte cache line, it will miss
out every
On Mon, 2009-10-05 at 23:25 +0200, Joakim Tjernlund wrote:
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 05/10/2009
22:17:04:
On Mon, 2009-10-05 at 14:16 +0200, Joakim Tjernlund wrote:
Update the TLB asm to make proper use of _PAGE_DIRY and _PAGE_ACCESSED.
Pros:
- I/D
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 05/10/2009 23:31:39:
Yes, every ld.so uses dcbX and icbi insn when relocatin code.
Even with -msecure-plt ?
hmm, maybe not. Can't remember now. But perhaps LAZY relocs still
need dcbX? Easiest is to check in uClibc. I impl. it, but
Joakim Tjernlund wrote:
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 05/10/2009 23:31:39:
Yes, every ld.so uses dcbX and icbi insn when relocatin code.
Even with -msecure-plt ?
hmm, maybe not. Can't remember now. But perhaps LAZY relocs still
need dcbX? Easiest is to check in
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 05/10/2009 23:37:23:
On Mon, 2009-10-05 at 23:25 +0200, Joakim Tjernlund wrote:
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 05/10/2009
22:17:04:
On Mon, 2009-10-05 at 14:16 +0200, Joakim Tjernlund wrote:
Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
Scott and Rex, please disregard other patches from me and
try these out instead.
I have results similar to Scott's. I tried both with and without patch
5 6, and I also need the tlbia_va in ptep_set_access_flags().
I got this oops:
On Tue, 2009-10-06 at 00:00 +0200, Joakim Tjernlund wrote:
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 05/10/2009
23:37:23:
On Mon, 2009-10-05 at 23:25 +0200, Joakim Tjernlund wrote:
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 05/10/2009
22:17:04:
Rex Feany rfe...@mrv.com wrote on 06/10/2009 00:04:20:
Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
Scott and Rex, please disregard other patches from me and
try these out instead.
I have results similar to Scott's. I tried both with and without patch
5 6, and I also
On Tue, 2009-10-06 at 00:31 +0200, Joakim Tjernlund wrote:
regs or regs-nip is NULL? Either one does not make sense
In any case it might be a secondary problem as DAR is NULL already
when you
enter the page fault.
insn = *((unsigned long *)regs-nip);
c000e110: 80
Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
I got this oops:
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc000e110
Oops: Kernel access of bad area, sig: 11 [#1]
MRV NM2
NIP: c000e110 LR: c000d520 CTR: 1006bf40
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 06/10/2009 00:09:16:
On Tue, 2009-10-06 at 00:00 +0200, Joakim Tjernlund wrote:
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 05/10/2009
23:37:23:
On Mon, 2009-10-05 at 23:25 +0200, Joakim Tjernlund wrote:
Rex Feany rfe...@mrv.com wrote on 06/10/2009 00:42:18:
Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
I got this oops:
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc000e110
Oops: Kernel access of bad area,
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 06/10/2009 00:37:28:
On Tue, 2009-10-06 at 00:31 +0200, Joakim Tjernlund wrote:
regs or regs-nip is NULL? Either one does not make sense
In any case it might be a secondary problem as DAR is NULL already
when you
enter the page
On Tue, 2009-10-06 at 00:55 +0200, Joakim Tjernlund wrote:
Sure but if dirty is cleared by the kernel, then you also need to
remove
write permission in the TLB or it will miss setting dirty on the
next
store to the page.
Dirty map to HW changed bit so if kernel clears it, the next
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 06/10/2009 01:15:39:
On Tue, 2009-10-06 at 00:55 +0200, Joakim Tjernlund wrote:
Sure but if dirty is cleared by the kernel, then you also need to
remove
write permission in the TLB or it will miss setting dirty on the
next
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 06/10/2009 00:37:28:
On Tue, 2009-10-06 at 00:31 +0200, Joakim Tjernlund wrote:
regs or regs-nip is NULL? Either one does not make sense
In any case it might be a secondary problem as DAR is NULL already
when you
enter the page
Dear all,
I'm new to this list. I'm installing the Embedded Linux on a Xilinx FPGA
PPC405. The first question is that I have 1GB memory, and passed the
standalone memory test. But when installing linux, I have to setup only to
use 512MB memory in the device tree in order to boot the linux
On Tue, 2009-10-06 at 01:35 +0200, Joakim Tjernlund wrote:
Well, if the HW has the ability to enforce trap when store with !
DIRTY,
Yes, provided that the kernel invalidates the TLB too so the next
access
will provoke a TLB Miss, which will then provoke a TLB error. The TLB
error
\
So how does this look? Does it change anything?
It should as the previous way was way off :(
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index c33c6de..08a392f 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -153,7 +153,7 @@ int __kprobes
This patch adds powerpc specific tracepoints for interrupt entry and exit.
While we already have generic irq_handler_entry and irq_handler_exit
tracepoints there are cases on our virtualised powerpc machines where an
interrupt is presented to the OS, but subsequently handled by the hypervisor.
On Tue, 2009-10-06 at 13:19 +1100, Anton Blanchard wrote:
This patch adds powerpc specific tracepoints for interrupt entry and exit.
While we already have generic irq_handler_entry and irq_handler_exit
tracepoints there are cases on our virtualised powerpc machines where an
interrupt is
Hello Grant,
Grant Likely wrote:
On Mon, Oct 5, 2009 at 4:12 AM, Heiko Schocher h...@denx.de wrote:
Wolfram Sang wrote:
Is this an official binding? I also did an gpio-watchdog a while ago and
there
were some issues with the binding, IIRC. Would be nice if this has been
solved
meanwhile.
68 matches
Mail list logo
