Josh Boyer writes:
> I've not heard any objections. I'll be pushing my commit to my next
> branch tomorrow morning.
I don't have any objections. I wonder if Sam Ravnborg responded to
Segher's patch to extend make help?
Paul.
___
Linuxppc-dev mailing
In message <[EMAIL PROTECTED]> you wrote:
>
> This is why I've always had mixed feelings about merging device trees
> into u-boot, rather than having them supplied by the wrapper.
On the other hand, we can now use the device tree to dynamically
configure U-Boot, thus allowing to run the
Paul Mackerras wrote:
> Kamalesh Babulal writes:
>
>> The kernel oops after applying the patch. Some time it takes more than
>> one run to reproduce it, it was reproducible in the second run this
>> time.
>>
>> Unrecoverable exception 4100 at c0008c8c
>> Oops: Unrecoverable exception, sig
On Tue, 2008-04-08 at 19:19 -0700, Trent Piepho wrote:
> Why? Because:
> A) It's not modified and so it can be made const. const is good.
> B) If one has a function that was given a const pci_bus pointer and you
> want to get a pointer to its pci_controller, you'll get a warning from gcc
> when
On Mon, 2008-04-07 at 16:36 -0500, Kumar Gala wrote:
> On Apr 6, 2008, at 8:06 AM, Josh Boyer wrote:
> > Hi All,
> >
> > Unless someone screams loudly and has reasons why this shouldn't go
> > in,
> > the following commit should hit the 4xx next branch in the next day or
> > so.
> >
> > josh
>
>
Why? Because:
A) It's not modified and so it can be made const. const is good.
B) If one has a function that was given a const pci_bus pointer and you
want to get a pointer to its pci_controller, you'll get a warning from gcc
when you use pci_bus_to_host(). This is the right way to stop that
war
On Tuesday 08 April 2008, Carl Love wrote:
> On Fri, 2008-04-04 at 08:38 +0200, Arnd Bergmann wrote:
> Our first thought to fix the bug was to just grab the mutex lock when
> adding the switch notification data to the queue. The kernel gives us
> an oops message saying something along the line of
On Tue, 8 Apr 2008 17:15:44 -0600
"Grant Likely" <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 8, 2008 at 4:56 PM, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, 2008-04-08 at 15:53 -0700, John Bonesio wrote:
> > > I was thinking it might be good to have the kernel initialize the
On Tue, Apr 08, 2008 at 03:07:58PM -0500, Scott Wood wrote:
> Robert Schwebel wrote:
>> Well observed; isn't this the prove of the assumption that the whole
>> device tree idea is not working? It is *always* inconsistent and it is
>> *maintenance hell* because out-of-tree ports do *always* breakt b
Kamalesh Babulal writes:
> The kernel oops after applying the patch. Some time it takes more than
> one run to reproduce it, it was reproducible in the second run this
> time.
>
> Unrecoverable exception 4100 at c0008c8c
> Oops: Unrecoverable exception, sig: 6 [#1]
> SMP NR_CPUS=128 NUMA
On Tue, Apr 8, 2008 at 4:56 PM, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
>
> On Tue, 2008-04-08 at 15:53 -0700, John Bonesio wrote:
> > I was thinking it might be good to have the kernel initialize these
> > cache control registers in it's own start up code. Or perhaps this
> > could b
On Tue, 2008-04-08 at 15:53 -0700, John Bonesio wrote:
> I was thinking it might be good to have the kernel initialize these
> cache control registers in it's own start up code. Or perhaps this
> could be done in the kernel's simple bootloader. We could probably put
> this change in a Xilinx speci
Hi all,
We've discovered something interesting when not using a bootloader such as
uboot to start Linux.
The Linux kernel seems to be depending on the bootloader to set up the ppc440
cache control registers, ivlim and dvlim, to set up the Normal and Transient
areas in the caches. When a separa
Commit 0f436eff54f90419ac1b8accfb3e6e17c4b49a4e breaks build on
arch/ppc as it doesn't implement the machine_is() macro.
This fixes it by using CONFIG_PPC_MERGE instead which represents
arch/powerpc only, while CONFIG_PPC is set for both.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
I disagree and that is not my point. My point is that perfection is
neither obtainable or necessary.
It's a nice goal though.
Many of the recently established
embedded guidelines are not "perfect" because they are counter to a
few of the OF recommended practices. However, they are consistent
On Tue, Apr 8, 2008 at 6:30 AM, Guillaume Dargaud <[EMAIL PROTECTED]> wrote:
> I'm making progress, thanks in no small part to this list, but I still need
> coaching, if you don't mind. The current boot is currently going as such:
>
>
> loaded at: 0040 005A819C
> board data at: 005A6120 0
On Tue, Apr 8, 2008 at 1:45 PM, Robert Schwebel
<[EMAIL PROTECTED]> wrote:
> On Tue, Apr 08, 2008 at 08:52:55AM -0600, Grant Likely wrote:
> > It may be ideal, but I don't think it is realistic. I'm now of the
> > firm opinion that device trees and firmware are *never* perfect.
> > Especially w
On Fri, 2008-04-04 at 08:38 +0200, Arnd Bergmann wrote:
> On Wednesday 02 April 2008, Carl Love wrote:
> > On Wed, 2008-04-02 at 07:21 +0200, Arnd Bergmann wrote:
> > > On Tuesday 25 March 2008, Carl Love wrote:
> > > > This patch fixes a bug in the code that records the SPU data and
> > > > cont
Robert Schwebel wrote:
> The ARM method of using just a device number is so much easier ...
And I was going to suggest that the ARM guys should use device trees, too.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linu
Robert Schwebel wrote:
Well observed; isn't this the prove of the assumption that the whole
device tree idea is not working? It is *always* inconsistent and it is
*maintenance hell* because out-of-tree ports do *always* breakt because
of string inconsistencies. We have just ported a 8260 board fr
On Tue, Apr 08, 2008 at 08:52:55AM -0600, Grant Likely wrote:
> It may be ideal, but I don't think it is realistic. I'm now of the
> firm opinion that device trees and firmware are *never* perfect.
> Especially when the definition of perfect is a moving target.
Well observed; isn't this the prove
Scott Wood wrote:
On Tue, Apr 08, 2008 at 03:50:26PM +0200, Andre Schwarz wrote:
after building a debug kernel and attaching the bdi2000 it looks like
the crash occurs during "console_init()" ...
Does your device tree have a /chosen node after u-boot is done with it?
find_legacy_seri
On Tuesday 08 April 2008 11:49:14 Jerone Young wrote:
> 2 files changed, 77 insertions(+), 1 deletion(-)
> arch/powerpc/platforms/44x/Makefile |2
> arch/powerpc/platforms/44x/idle.c | 76
> +++
>
>
> Updates: Now setting MSR_WE is now default
> Tested
The driver stores the the PCI resource addresses into 'unsigned long' variable
before calling ioremap() on them. This warrants kernel oops when the registers
are accesse on PPC 44x platforms which (being 32-bit) have PCI memory space
mapped beyond 4 GB.
The arch/ppc/ kernel has a fixup in ioremap(
The driver stores the the PCI resource address into 'unsigned long' variable
before calling ioremap() on it. This warrants kernel oops when the registers
are accessed on PPC 44x platforms which (being 32-bit) have PCI memory space
mapped beyond 4 GB.
The arch/ppc/ kernel has a fixup in ioremap() t
Paul Mackerras wrote:
> Kamalesh Babulal writes:
>
>> The kernel oops after applying the patch. Some time it takes more than
>> one run to reproduce it, it was reproducible in the second run this
>> time.
>>
>> Unrecoverable exception 4100 at c0008c8c
>> Oops: Unrecoverable exception, sig
2 files changed, 77 insertions(+), 1 deletion(-)
arch/powerpc/platforms/44x/Makefile |2
arch/powerpc/platforms/44x/idle.c | 76 +++
Updates: Now setting MSR_WE is now default
Tested on hardware platforms bamboo & sequioa and appears
things
On Tue, Apr 08, 2008 at 03:50:26PM +0200, Andre Schwarz wrote:
> after building a debug kernel and attaching the bdi2000 it looks like
> the crash occurs during "console_init()" ...
Does your device tree have a /chosen node after u-boot is done with it?
find_legacy_serial_ports() can crash othe
On Tue, Apr 08, 2008 at 10:51:18AM +0200, Andre Schwarz wrote:
> Call Trace:
> [c01f9ef0] [c001c190] (unreliable)
> [c01f9f10] [c0140c84]
> [c01f9f20] [c0140ccc]
> [c01f9f40] [c014145c]
> [c01f9f60] [c0014014]
> [c01f9fa0] [c01d1a40]
> [c01f9fb0] [c01ce64c]
> [c01f9fc0] [c01c55ac]
> [c01f9ff0] [00
On Tue, Apr 08, 2008 at 09:28:12AM -0500, Kumar Gala wrote:
> On Apr 7, 2008, at 6:51 PM, Benjamin Herrenschmidt wrote:
>> As far as the above is concerned, I'm not too fan of fixed virtual
>> addresses. I'd rather dynamically assign it. But we can do it.
>
> I'm in agreement with Ben here. On Fre
On Mon, 2008-04-07 at 10:14 -0700, Dale Farnsworth wrote:
> Add the low level irq tracing hooks for 32-bit powerpc needed
> to enable full lockdep functionality.
>
> Dale Farnsworth <[EMAIL PROTECTED]>
> ---
> This version fixes the clobbering of r12 by the call to
> trace_hardirqs_off() that was
Sergei Shtylyov wrote:
Yeah, right please go ahead. But I wonder whether any BIOS was
actually crazy enough to map mmio region above 4G on 32bit machine.
This is a *hardware* mapping on some non-x86 platforms (like PPC 44x
or MIPS Alchemy). The arch/ppc/ and arch/mips/ kernels have special
Tejun Heo wrote:
A very late comment but nevertheless... :-)
Better late than never.
:-)
Those functions are going to break on 32-bit platforms with
extended physical address (well, that's starting with Pentiums which
had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g. Power
On Tue, Apr 8, 2008 at 3:37 AM, Matt Sealey <[EMAIL PROTECTED]> wrote:
> I'd not thank Grant.
>
> I think the prom_init fixes are bordering on disgusting.. it would
> make it's way into commercial code for sure, but only because nobody
> would see what a hideous mess it is :)
>
> The best solut
Sergei Shtylyov wrote:
A very late comment but nevertheless... :-)
Better late than never.
Those functions are going to break on 32-bit platforms with extended
physical address (well, that's starting with Pentiums which had 36-bit
PAE :-) AND devices mapped beyond 4 GB (e.g. PowerPC 44
On Apr 7, 2008, at 6:51 PM, Benjamin Herrenschmidt wrote:
On Mon, 2008-04-07 at 11:20 -0500, Scott Wood wrote:
Another possible use is a BAT/TLB1 mapping for SoC registers (or
anything
else on the board which is frequently accessed), which can be reused
by
ioremap() to avoid wasting normal TL
Paul,
Here's my take on the current status of the patchset:
[POWERPC] bootwrapper: Allow specifying of image physical offset
reworked to look at PHDR (needs linker script update patch). Still
open question on how best to do that (objdump, readelf, C program,
suggestions)
[POWERPC] Remove
Scott Wood schrieb:
On Sat, Apr 05, 2008 at 10:19:49AM +0200, André Schwarz wrote:
Kernel starts and crashes with "unable to handle kernel paging request @
".
After turning debug on in some files I can see that the initrd memory
gets reserved and the dtb is parsed correctly.
PCI
Bartlomiej Zolnierkiewicz wrote:
Fix kernel oops due to machine check occuring in init_chipset_siimage() on PPC
44x platforms. These 32-bit CPUs have 36-bit physical address and PCI I/O and
memory spaces are mapped beyond 4 GB; arch/ppc/ code has a fixup in ioremap()
that creates an illusion of
Kamalesh Babulal writes:
> The kernel oops after applying the patch. Some time it takes more than
> one run to reproduce it, it was reproducible in the second run this
> time.
>
> Unrecoverable exception 4100 at c0008c8c
> Oops: Unrecoverable exception, sig: 6 [#1]
> SMP NR_CPUS=128 NUMA
Hi, I just wrote:
This function didn't actually check if a given BAR is in I/O space
because of
using the bogus PCI_BASE_ADDRESS_IO_MASK (which equals ~3) to test
the resource
flags instead of IORESOURCE_IO -- fix this, make ide_hwif_configure()
check the
results failing if necessary, and move
I'm making progress, thanks in no small part to this list, but I still need
coaching, if you don't mind. The current boot is currently going as such:
loaded at: 0040 005A819C
board data at: 005A6120 005A619C
relocated to: 00404054 004040D0
zimage at: 00404E40 00515AD1
initrd at:
On Mon, Apr 07, 2008 at 06:11:15PM +0200, Laurent Pinchart wrote:
[...]
> I had a first go at hacking the FHCI driver to make it run on a CPM2
> platform.
> Results so far are quite good. After getting rid of qe-specific APIs as
> explained above, and adding SOF token generation support, I've be
Paul Mackerras wrote:
> Kamalesh Babulal writes:
>
>> The Kernel oopses is seen while running the kernbench followed by tbench
>> with 2.6.25-rc2-git4
>> kernel on powerpc, this oops was reported for the 2.6.24-rc8-mm1 kernel
>> (http://lkml.org/lkml/2008/1/18/71)
>> and is visible with almost
On Tue, Apr 08, 2008 at 11:01:53AM +0200, Laurent Pinchart wrote:
> On Tuesday 11 March 2008 18:24, Anton Vorontsov wrote:
> > GTM stands for General-purpose Timers Module and able to generate
> > timer{1,2,3,4} interrupts.
> >
> > There are several limitations in this support:
> > 1. Cascaded (32
sorry - forgot Kim + List
Original-Nachricht
Betreff:Re: MPC8343 - "unable to handle paging request @ 0"
Datum: Tue, 08 Apr 2008 13:29:20 +0200
Von:Andre Schwarz <[EMAIL PROTECTED]>
An: Scott Wood <[EMAIL PROTECTED]>
Referenzen: <[EMAIL PROTECTED]>
<[EMAIL PRO
Are you using uartlite? Try console=ttyUL0.
Thanks, I didn't know that.
But Stephen is right, the first thing you should do is look at
__log_buf. You can find its address in the System.map file.
Unfortunately, the installation of the cable driver failed for some reason.
I'll have to work
On Tuesday 11 March 2008 18:24, Anton Vorontsov wrote:
> GTM stands for General-purpose Timers Module and able to generate
> timer{1,2,3,4} interrupts.
>
> There are several limitations in this support:
> 1. Cascaded (32 bit) timers unimplemented (1-2, 3-4).
>This is straightforward to impleme
Scott Wood schrieb:
On Sat, Apr 05, 2008 at 10:19:49AM +0200, André Schwarz wrote:
Kernel starts and crashes with "unable to handle kernel paging request @
".
After turning debug on in some files I can see that the initrd memory
gets reserved and the dtb is parsed correctly.
PCI
Kamalesh Babulal writes:
> The Kernel oopses is seen while running the kernbench followed by tbench with
> 2.6.25-rc2-git4
> kernel on powerpc, this oops was reported for the 2.6.24-rc8-mm1 kernel
> (http://lkml.org/lkml/2008/1/18/71)
> and is visible with almost all of the main line ,rc(s) and
On Tue, Apr 08, 2008 at 04:14:42AM +0200, Arnd Bergmann wrote:
> On Tuesday 08 April 2008, Matt Sealey wrote:
> > Grant Likely wrote:
> > >
> > > Sure, why not? If the firmware has already set it up correctly and no
> > > devices using it are in use, then the kernel should be okay. :-)
> > > Tha
> You need to be sure to load the device tree blob in U-Boot, ...
>
> josh
>
Thank you very much. This was just the missing piece of info I needed.
Bernhard
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/l
52 matches
Mail list logo
