Jon Loeliger wrote:
nanda wrote:
Hi Stuart,
Thanks for the information. gpp access was resolved.
I was successful in building the linux 2.6.11 using the ltib and
able to bring up the MPC8360 EMDS.
But, I still face the problem for linux kernel 2.6.19 and 2.6.20.
When I tried using lt
On Tue, Nov 25, 2008 at 13:34, Grant Erickson wrote:
> This merges support for the previously DENX-only kernel feature of
> specifying an alternative, "external" buffer for kernel printk
> messages and their associated metadata. In addition, this ports
> architecture support for this feature from a
It turns out that on Cell, on a kernel with CONFIG_VIRT_CPU_ACCOUNTING
= y, if a program sets the SO (summary overflow) bit in the XER and
then does a system call, the SO bit in CR0 will be set on return
regardless of whether the system call detected an error. Since CR0.SO
is used as the error ind
On Tue, 2008-11-25 at 15:53 -0600, Hollis Blanchard wrote:
> On Tue, 2008-11-25 at 11:10 +1100, Michael Ellerman wrote:
> >
> > Still, I think it would be better to only set memory_limit when the mem
> > size is not a multiple of the PAGE_SIZE - so that memory_limit retains
> > it's function as bo
On Tue, 2008-11-25 at 16:58 +0100, Arnd Bergmann wrote:
> > struct pmc_cntrl_data {
> > unsigned long vcntr;
> > @@ -111,6 +126,8 @@ struct pm_cntrl {
> > u16 trace_mode;
> > u16 freeze;
> > u16 count_mode;
> > + u16 spu_addr_trace;
> > + u8 trace_buf_ovflw;
> > };
> >
> The error message printed when the eHCA driver prevents memory hotplug is
> misleading -- the user might think that hot-removing the lhca, hotplugging
> memory, then hot-adding the lhca again will work, but it doesn't.
That's too bad... I applied this patch but out of curiousity, why
doesn't
On Tue, 2008-11-25 at 11:10 +1100, Michael Ellerman wrote:
>
> Still, I think it would be better to only set memory_limit when the mem
> size is not a multiple of the PAGE_SIZE - so that memory_limit retains
> it's function as both the value of the limit and a boolean.
OK, how's this?
ppc: force
No comment from me on $SUBJECT beyond "it seems plausible", but ...
On Tuesday 25 November 2008, David VomLehn wrote:
> The important point, though, is that device tree is the only
> thing approaching a standard on any non-x86-based platform for passing
> structured information from the bootloader
On Tue, 2008-11-25 at 14:19 -0600, Bill Gatliff wrote:
> Just trying to figure out where the walls of this "sandbox" are. I've
> been aware of the concept of Open Firmware for a while, but haven't
> really looked into it before now--- mostly because my impression until
> now was that the availab
On Tue, 2008-11-25 at 11:10 -0600, Milton Miller wrote:
> On Nov 24, 2008, at 6:10 PM, Michael Ellerman wrote:
> > On Mon, 2008-11-24 at 14:07 -0600, Hollis Blanchard wrote:
> >> On Fri, 2008-11-14 at 16:09 -0600, Hollis Blanchard wrote:
> >>>
> >>> If this is all too much, then I'm close to giving
On Tue, Nov 25, 2008 at 3:05 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> Dear Matt,
>
> In message <[EMAIL PROTECTED]>
> you wrote:
> >
> > There is also no reason you can't hard-code the locations into the device
> > tree, to support older U-Boots that don't know about
> > /chosen/linux,log-me
Dear Matt,
In message <[EMAIL PROTECTED]> you wrote:
>
> There is also no reason you can't hard-code the locations into the device
> tree, to support older U-Boots that don't know about
> /chosen/linux,log-metadata and /chosen/linux,log-buffer*.
Actually there is such reason - U-Boot traditionall
On Tue, Nov 25, 2008 at 2:17 PM, Grant Likely <[EMAIL PROTECTED]>wrote:
> On Tue, Nov 25, 2008 at 1:07 PM, Matt Sealey <[EMAIL PROTECTED]> wrote:
>
> > But here's the real question; why do you need an opensource
> implementation?
> > Curiosity?
>
> Umm, so that it can be ported to new boards perha
On Tue, Nov 25, 2008 at 1:07 PM, Matt Sealey <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, Nov 25, 2008 at 1:51 PM, Bill Gatliff <[EMAIL PROTECTED]> wrote:
>>
>> Matt Sealey wrote:
>>
>> > I can think of a bunch of reasons why it's a good idea..
>>
>> Can you point to a GPL/LGPL/BSD/etc. source code for
. F
On Tue, Nov 25, 2008 at 12:51 PM, Bill Gatliff <[EMAIL PROTECTED]> wrote:
> Matt Sealey wrote:
>
>> I can think of a bunch of reasons why it's a good idea..
>
> Can you point to a GPL/LGPL/BSD/etc. source code for an OpenFirmware
> implementation?
In powerpc land using the Open Firmware devi
Matt Sealey wrote:
> Yes, there's FirmWorks, CodeGen SmartFirmware, IBM SLOF and OpenBIOS..
> they're all linked from the OpenBIOS website (along with a bunch of the
> documentation from http://www.openfirmware.org in more-readable formats
> like PDF)
>
> http://www.openbios.org/
>
>
> But here'
Matt Sealey wrote:
> I can think of a bunch of reasons why it's a good idea..
Can you point to a GPL/LGPL/BSD/etc. source code for an OpenFirmware
implementation?
b.g.
--
Bill Gatliff
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozla
On Tue, Nov 25, 2008 at 1:51 PM, Bill Gatliff <[EMAIL PROTECTED]> wrote:
> Matt Sealey wrote:
>
> > I can think of a bunch of reasons why it's a good idea..
>
> Can you point to a GPL/LGPL/BSD/etc. source code for an OpenFirmware
> implementation?
>
Yes, there's FirmWorks, CodeGen SmartFirmware,
Actually there is an ARM board out there with an Open Firmware (Toshiba
TOPAS910 -
http://www.toshiba-components.com/microcontroller/BMSKTOPAS910.html) so,
yes, device trees do appear on those platforms. QEMU is looking to go that
way too, seems for every architecture it would be a pretty awesome i
On Tue, 2008-11-25 at 17:00 +0100, Arnd Bergmann wrote:
> On Tuesday 25 November 2008, Carl Love wrote:
> > This patch set consists of two kernel patches and one user level patch
> > to add SPU event based profiling support to OProfile for the IBM Cell
> > processor. The first patch in the series
On 11/25/08 10:55 AM, Josh Boyer wrote:
> On Tue, 25 Nov 2008 12:53:12 -0600
> "Matt Sealey" <[EMAIL PROTECTED]> wrote:
>> Nitpick, really.. shouldn't the logbuffer location(s) be some device tree
>> property(ies), perhaps something in the
>> /chosen node that U-Boot etc. can then fill out?
>
> I
On Tue, Nov 25, 2008 at 12:55 PM, Josh Boyer <[EMAIL PROTECTED]>wrote:
> On Tue, 25 Nov 2008 12:53:12 -0600
> "Matt Sealey" <[EMAIL PROTECTED]> wrote:
>
> > Nitpick, really.. shouldn't the logbuffer location(s) be some device tree
> > property(ies), perhaps something in the
> > /chosen node that U
On Tue, 25 Nov 2008 12:53:12 -0600
"Matt Sealey" <[EMAIL PROTECTED]> wrote:
> Nitpick, really.. shouldn't the logbuffer location(s) be some device tree
> property(ies), perhaps something in the
> /chosen node that U-Boot etc. can then fill out?
I don't think that's a nitpick. It's a fundamental
Nitpick, really.. shouldn't the logbuffer location(s) be some device tree
property(ies), perhaps something in the
/chosen node that U-Boot etc. can then fill out?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
On Tue, Nov 25, 2008 at 12:34 PM, Grant Erickson
<[EMAIL PROT
This merges support for the previously DENX-only kernel feature of
specifying an alternative, "external" buffer for kernel printk
messages and their associated metadata. In addition, this ports
architecture support for this feature from arch/ppc to arch/powerpc.
Signed-off-by: Grant Erickson <[EMA
On Nov 24, 2008, at 6:10 PM, Michael Ellerman wrote:
On Mon, 2008-11-24 at 14:07 -0600, Hollis Blanchard wrote:
On Fri, 2008-11-14 at 16:09 -0600, Hollis Blanchard wrote:
If this is all too much, then I'm close to giving up and burning a
64KB page, which requires only ALIGN_DOWN() in the kerne
On Nov 23, 2008, at 11:01 PM, Kumar Gala wrote:
On Nov 22, 2008, at 10:01 PM, Trent Piepho wrote:
On Sat, 22 Nov 2008, Milton Miller wrote:
On Thu Nov 20 at 06:14:30 EST in 2008, Trent Piepho wrote:
- li r7,0
- lis r6,PAGE_OFFSET at h
- ori r6,r6,PAGE_OFFSET at l
The cuboot-acadia.c wrapper can cause assembler errors on some
toolchains due to the lack of the proper BOOTCFLAGS. This adds
the proper flags for the file.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 8fc6d72..3d3d
On Nov 22, 2008, at 6:26 PM, Nathan Lynch wrote:
Milton Miller wrote:
On Sat Nov 22 at 14:06:53 EST in 2008, Nathan Lynch wrote:
With 2.6.28-rc5 the WARN_ON in xics_set_cpu_giq is triggering on a
JS20. I changed it to a WARN to get the actual status returned:
b4963255ad5a426f04a0bb15c4315fa
On Tuesday 25 November 2008, Carl Love wrote:
> This patch set consists of two kernel patches and one user level patch
> to add SPU event based profiling support to OProfile for the IBM Cell
> processor. The first patch in the series is the user level patch that
> adds the needed events and event
On Tuesday 25 November 2008, Carl Love wrote:
>
> This is the second of the two kernel patches for adding SPU profiling
> for the IBM Cell processor. This patch contains the spu event profiling
> setup, start and stop routines.
>
> Signed-off-by: Carl Love <[EMAIL PROTECTED]>
Maybe a little m
On Tuesday 25 November 2008, Carl Love wrote:
>
> This patch basically rearranges the code a bit to make it easier to
> just add the needed SPU event based profiling routines. The second
> kernel patch contains the new spu event based profiling code.
The cleanup looks fine, but should get a un
This adds a SPI driver for the SPI controller found in the IBM/AMCC
4xx PowerPC's.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Wolfgang Ocker <[EMAIL PROTECTED]>
Acked-by: Josh Boyer <[EMAIL PROTECTED]>
---
Changes in v5:
- Don't call setupxfer() from setup() so that the baudrat
Tim, Grant
here are some more information.
I think there is a also a problem with memory after FEC crasched.
[EMAIL PROTECTED]:~ free
total used free shared buffers
Mem: 12710026424 1006760 432
Swap:
On Tue, Nov 25, 2008 at 8:45 AM, Lehmann, Hans (Ritter Elektronik) <
[EMAIL PROTECTED]> wrote:
> Tim, Grant,
>
> just an info.
>
> Very often the Bestcomm-FEC crashed without any error logs if I initiate a
> transaction over FEC and save the file to disk (I rememeber I have read
> something like t
Tim, Grant,
just an info.
Very often the Bestcomm-FEC crashed without any error logs if I initiate a
transaction over FEC and save the file to disk (I rememeber I have read
something like that). A restart of FEC don't work.
But no I figured out, if I connect to the other ethernet port of our
I wrote:
>> I have an external watchdog timer that is going off - and pulsing
into
>> the MCP0 of the 8572E. I get the printk indicating that the MCP0 went
>> off - the problem is - how do I clear the condition that caused this
>> because my hardware engineer swears that the pulse is ONLY 250ms -
The error message printed when the eHCA driver prevents memory hotplug is
misleading -- the user might think that hot-removing the lhca, hotplugging
memory, then hot-adding the lhca again will work, but it doesn't.
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/e
38 matches
Mail list logo
