Re: use of BAT before taking over the MMU

The PowerPC OF binding requires the firmware to save and restore the BATs on entry to / exit from the firmware. This sucks, because using the BAT is **much** easier for the firmware. In my case, it also means I don't need to worry about Linux stomping on anything -- I have nothing in RAM.

Re: use of BAT before taking over the MMU

On Sat, 2010-10-02 at 14:32 -0400, Albert Cahalan wrote: On the prom boot path, with the firmware supposed to be managing the MMU, there is a case where: 1. Linux changes some BAT registers. 2. Bits 0x0070 are/become set in the MSR. 3. Linux takes an MMU fault. Meeep ! Linux should

Re: Serial RapidIO Maintaintance read causes lock up

Hi Alex, Thanks for your advice. We are trying to make a board-to-board connection without any additional hardware (eg. a switch). The boards use a 50-pin, right-angle MEC8-125-02-L-D-RA1 connector from SAMTEC and are connected trough a EEDP-016-12.00-RA1-RA2-2 cross cable from SAMTEC. I hope

[PATCH] Move ams driver to macintosh

The ams driver isn't a hardware monitoring driver, so it shouldn't live under driver/hwmon. drivers/macintosh seems much more appropriate, as the driver is only useful on PowerBooks and iBooks. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: Stelian

Re: use of BAT before taking over the MMU

On Tue, Oct 5, 2010 at 4:10 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Mon, 2010-10-04 at 06:25 +0200, Segher Boessenkool wrote: On the prom boot path, with the firmware supposed to be managing the MMU, there is a case where: 1. Linux changes some BAT registers. 2.

Re: use of BAT before taking over the MMU

The PowerPC OF binding requires the firmware to save and restore the BATs on entry to / exit from the firmware. That would defeat the purpose of setting them. They are used to provide Linux with mappings. How so ? As long as they are present when executing Linux code, I don't see the

RE: Serial RapidIO Maintaintance read causes lock up

Hi Bastiaan, Bastiaan Nijkamp bastiaan.nijk...@gmail.com wrote: fsl-of-rio e00c.rapidio: LAW start 0xc000, RIO Maintainance Window Size 0x40,New Main Start: 0xd108 RIO: enumerate master port 0, RIO0 mport fsl_rio_config_read: index 0 destid 255 hopcount 0 offset

Re: Serial RapidIO Maintaintance read causes lock up

Bastiaan, On 05/10/10 15:28, Bastiaan Nijkamp wrote: Hi John, 1. Yes, they are both running the exact same kernel and both are configured in the same way. With the exception that one is set as host and the other as a agent. 2. Accept All is set for both boards. 3. As i understand, the agent

Re: use of BAT before taking over the MMU

The PowerPC OF binding requires the firmware to save and restore the BATs on entry to / exit from the firmware. I'm not sure he was talking about OF here... Yeah, I thought I was on a different mailing list. It's still sort-of relevant though. In any case, we don't muck around with BATs

RE: Serial RapidIO Maintaintance read causes lock up

Bastiaan Nijkamp bastiaan.nijk...@gmail.com wrote:   A interesting thing that i found out is that when the agent is reset while the host is locked up (eg. it cannot be stopped nor can i read the registers and memory trough a JTAG Interface), the host comes back online and just continues

Re: Serial RapidIO Maintaintance read causes lock up

Hi Alex, Yes, Sorry, that was a typo. The correct address that is printed is 0xd1080068. And i did not disable the error handler, CONFIG_E500 is set at compile time. Regards, Bastiaan 2010/10/5 Bounine, Alexandre alexandre.boun...@idt.com Hi Bastiaan, Bastiaan Nijkamp

MSI-X vector allocation failure in upstream kernel

Hi All, I am trying to test qlcnic driver (for 10Gb QLogic network adapter) on a Power 6 system (IBM P 520, System type 8203) with upstream kernel and I do see that the kernel is not able to allocate any MSI-X vectors. The driver requests for 4 vectors in pci_enable_msix, which returns 2.

[PATCH] powerpc/module: Remove unused variable err

Commit 5336377d6225959624146629ce3fc88ee8ecda3d removed the need for err, remove the variable Signed-off-by: Matthew McClintock m...@freescale.com --- arch/powerpc/kernel/module.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/module.c

linux-next: build failure in Linus' tree

Hi Linus, Today's linux-next initial build (powerpc ppc64_defconfig) failed like this: cc1: warnings being treated as errors arch/powerpc/kernel/module.c: In function 'module_finalize': arch/powerpc/kernel/module.c:66: error: unused variable 'err' Caused by commit

Re: Introduce support for little endian PowerPC

Hi Josh, Excerpts from Josh Boyer's message of Fri Oct 01 21:36:35 +1000 2010: Aside from my general uh, why? stance, I'm very very hesitant to integrate anything in the kernel that doesn'.t have released patches on the toolchain side. As I said the kernel can be built today with an unpatched

Re: [PATCH 05/18] powerpc: Wire up 44x little endian boot for remaining 44x targets

Excerpts from Josh Boyer's message of Fri Oct 01 21:27:37 +1000 2010: From: Ian Munsie imun...@au1.ibm.com I haven't tested booting a little endian kernel on any of these targets, but they all claim to be 44x so my little endian trampoline should work on all of them, so wire it up on:

Re: [PATCH 05/18] powerpc: Wire up 44x little endian boot for remaining 44x targets

On Tue, Oct 5, 2010 at 9:28 PM, Ian Munsie imun...@au1.ibm.com wrote: Excerpts from Josh Boyer's message of Fri Oct 01 21:27:37 +1000 2010: From: Ian Munsie imun...@au1.ibm.com I haven't tested booting a little endian kernel on any of these targets, but they all claim to be 44x so my

Re: [PATCH 05/18] powerpc: Wire up 44x little endian boot for remaining 44x targets

On Tue, 5 Oct 2010 21:55:35 -0400 Josh Boyer jwbo...@gmail.com wrote: Well, Warp and Sam440EP are production boards for actual companies. The rest are all just eval boards. I don't know if the board maintainers care either way, I was just using them as examples of cases where someone might.