* Re: Open Firmware - dts file
From: David Gibson @ 2007-08-03 5:22 UTC (permalink / raw)
To: Siva Prasad; +Cc: linuxppc-dev
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D79AE206@corpexc01.corp.networkrobots.com>
On Thu, Aug 02, 2007 at 12:21:21PM -0700, Siva Prasad wrote:
> Hi,
>
> I am trying to understand ..
>
> 1) How a given dts file is embedded into the zImage (how about vmlinux?)
The arch/powerpc/boot/wrapper script builds the dts into a device tree
blob using dtc (the Device Tree Compiler), it then folds the binary
device tree into a special section in the zImage.
> 2) Where does it get stored for later access during booting?
The zImage, possibly after adjusting the device tree based on
information from the firmware, passes the address of the tree to the
kernel as it invokes it. The kernel adds the device tree address (as
well as any further ranges specified in the device tree blob) to its
internal list of reserved addresses so it won't clobber it with other
allocations.
> 3) How a specific dts file out of the available in /boot/dts directory
> is chosen?
Depending on the Kconfig, different Makefile targets will be
selected. Those targets then invoke the wrapper script with different
options, including different dts files into the zImage.
> I am a newbie to this open firmware thing and looking for the right
> pointer to get started.
Ok.. do understand that on systems with a full open firmware
implementation a dts won't generally be used at all. Instead the
kernel will read the device tree information from open firmware itself
and convert it directly into a device tree blob (which will later be
unpacked into the run-time device tree structure).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [ PATCH ] PowerPC cascade UIC IRQ handler fix.
From: David Gibson @ 2007-08-03 6:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev, Valentine Barshak
In-Reply-To: <20070803045705.GA2392@localhost.localdomain>
On Fri, Aug 03, 2007 at 02:57:05PM +1000, David Gibson wrote:
> On Fri, Aug 03, 2007 at 11:18:09AM +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2007-08-02 at 13:48 +1000, David Gibson wrote:
> > > On Mon, Jul 30, 2007 at 08:35:17PM +0400, Valentine Barshak wrote:
> > > > PPC44x cascade UIC irq handler fix.
> > > >
> > > > According to PPC44x UM, if an interrupt is configured as level-sensitive,
> > > > and a clear is attempted on the UIC_SR, the UIC_SR field is not
> > > > cleared if the incoming interrupt signal is at the asserted polarity.
> > > > This causes us to enter a cascade handler twice, since we first ack
> > > > parent UIC interrupt and ack child UIC one after that.
> > > > The patch checks child UIC msr value and returns IRQ_HANDLED
> > > > if there're no pending interrupts. Otherwise we get a kernel panic
> > > > with a "Fatal exception in interrupt" (illegal vector).
> > > > The patch also fixes status flags.
> > > >
> > > > Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> > >
> > > Hrm... This doesn't seem like the right fix to me. Instead, I think
> > > the cascaded IRQ handler should ack the interrupt on the child first.
> > > I'm a little surprised it doesn't at the moment.
> >
> > Well, we certainly do also need to make the code more solid vs.
> > spurrious interrupts.
>
> Actually that's true. The suggested patch is a good improvement for
> general robustness, but doesn't actually address the real problem.
>
> > The main thing is, if the cascade is a level interrupt, it should
> > probably use a smarter cascade handler that masks it, handle the child
> > interrupts, then unmasks it.
>
> We already have that, since I just use setup_irq() to set up a cascade
> handler, rather than a custom flow handler.
>
> The problem is that the standard handle_level_irq() flow handler acks
> before the ISR is called, whereas because of this UIC behaviour, we
> need to ack after the ISR has cleared the interrupt in the source.
> This is not specific to cascades, but is a problem for all
> level-triggered interrupts (i.e. basically everything).
>
> I think it means we must currently be getting a whole lot of spurious
> interrupts - will do some investigation in a moment.
>
> To fix this either we'll need a custom flow handler for UIC, or we can
> use the standard one, but clear the UIC_SR bits from the ->unmask()
> callback for level interrupts. I'm not entirely sure if the latter
> approach is safe - I *think* it is, but I could do with more
> convincing.
Ok, here's a patch which fixes up the flow handling on the UIC. It
needs some polish yet, but should be ok to test. Valentine, can you
test this on your setup, *without* your original proposed patch.
Eventually, for robustness, we'll want something like your original
patch as well for robustness, but in the meantime leaving it out
should tell us if my patch is actually having the intended effect.
Index: working-2.6/arch/powerpc/sysdev/uic.c
===================================================================
--- working-2.6.orig/arch/powerpc/sysdev/uic.c 2007-08-03 16:09:48.000000000 +1000
+++ working-2.6/arch/powerpc/sysdev/uic.c 2007-08-03 16:09:49.000000000 +1000
@@ -24,6 +24,7 @@
#include <linux/spinlock.h>
#include <linux/irq.h>
#include <linux/interrupt.h>
+#include <linux/kernel_stat.h>
#include <asm/irq.h>
#include <asm/io.h>
#include <asm/prom.h>
@@ -159,6 +160,56 @@ static struct irq_chip uic_irq_chip = {
.set_type = uic_set_irq_type,
};
+/**
+ * handle_uic_irq - Level type irq handler
+ * @irq: the interrupt number
+ * @desc: the interrupt description structure for this irq
+ *
+ * Level type interrupts are active as long as the hardware line has
+ * the active level. This may require to mask the interrupt and unmask
+ * it after the associated handler has acknowledged the device, so the
+ * interrupt line is back to inactive.
+ */
+void fastcall
+handle_uic_irq(unsigned int irq, struct irq_desc *desc)
+{
+ unsigned int cpu = smp_processor_id();
+ struct irqaction *action;
+ irqreturn_t action_ret;
+
+ spin_lock(&desc->lock);
+ desc->chip->mask(irq);
+
+ if (unlikely(desc->status & IRQ_INPROGRESS))
+ goto out_unlock;
+ desc->status &= ~(IRQ_REPLAY | IRQ_WAITING);
+ kstat_cpu(cpu).irqs[irq]++;
+
+ /*
+ * If its disabled or no action available
+ * keep it masked and get out of here
+ */
+ action = desc->action;
+ if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
+ desc->status |= IRQ_PENDING;
+ goto out_unlock;
+ }
+
+ desc->status |= IRQ_INPROGRESS;
+ desc->status &= ~IRQ_PENDING;
+ spin_unlock(&desc->lock);
+
+ action_ret = handle_IRQ_event(irq, action);
+
+ spin_lock(&desc->lock);
+ desc->status &= ~IRQ_INPROGRESS;
+ desc->chip->ack(irq);
+ if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
+ desc->chip->unmask(irq);
+out_unlock:
+ spin_unlock(&desc->lock);
+}
+
static int uic_host_match(struct irq_host *h, struct device_node *node)
{
struct uic *uic = h->host_data;
@@ -173,7 +224,7 @@ static int uic_host_map(struct irq_host
set_irq_chip_data(virq, uic);
/* Despite the name, handle_level_irq() works for both level
* and edge irqs on UIC. FIXME: check this is correct */
- set_irq_chip_and_handler(virq, &uic_irq_chip, handle_level_irq);
+ set_irq_chip_and_handler(virq, &uic_irq_chip, handle_uic_irq);
/* Set default irq type */
set_irq_type(virq, IRQ_TYPE_NONE);
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 1/2] Add sysdev/pci_quirks.c file into PowerPCarchitecture with ULI chip quirk functions.
From: Zang Roy-r61911 @ 2007-08-03 6:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Paul Mackerras, Zhang Wei-r63237
In-Reply-To: <05E0FF5A-03DB-441E-81E8-54BD4A215D32@kernel.crashing.org>
On Thu, 2007-08-02 at 12:29, Kumar Gala wrote:
> On Aug 1, 2007, at 8:23 PM, Benjamin Herrenschmidt wrote:
>
> > On Thu, 2007-08-02 at 09:17 +0800, Zhang Wei-r63237 wrote:
> >> Hi, Ben,
> >>
> >>>
> >>> Are we sure that any powerpc machine that uses that ULI chip will
> >>> need
> >>> the same quirk setting ?
> >>>
> >>
> >> We can ensure current platforms (as far as we know, MPC8544DS and
> >> MPC8641HPCN) using ULI chips in powerpc of kernel need the same
> quirk
> >> setting.
> >> And we hope to make them more generic. And if there are some
> >> different
> >> setting in the future, we can add special codes.
> >
> > All right.
>
> My feeling is this code is pretty specific to how the ULI M1575 is
> used on those boards and should only be built for those boards.
Until now, it is right.
Roy
^ permalink raw reply
* Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
From: David Gibson @ 2007-08-03 6:35 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070628100020.GA24215@iram.es>
On Thu, Jun 28, 2007 at 12:00:20PM +0200, Gabriel Paubert wrote:
> On Thu, Jun 28, 2007 at 10:59:35AM +0200, Segher Boessenkool wrote:
> > > Here is an implementation to allow PReP systems to boot under the
> > > arch/powerpc codebase, one of the few remaining platforms supported in
> > > arch/ppc but not so far in arch/powerpc.
> >
> > > Too big for the list, the patch is at:
> > > http://ozlabs.org/~dgibson/home/prep-support
> >
> > Too lazy to split the patch into bite-size chunks, you mean ;-)
> >
> > Anyway, here goes the DTS bits:
> >
> > +/*
> > + * PReP skeleton device tree
> > + *
> > + * Paul Mackerras <paulus@samba.org>
> > + */
> > +
> > +/ {
> > + device_type = "prep";
> > + model = "IBM,PReP";
> >
> > Not specific enough, leave it out or fill it in in the bootwrapper.
>
> Motorola also provided PreP boards (MTX and MVME at least).
>
> >
> > + compatible = "prep";
> >
> > Maybe fill this in, too.
> >
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu@0 {
> >
> > Do all (supported) PReP boards have one CPU only?
>
> Not sure, but I don't have any. I believe that there were
> dual processors MTX boards, and dual 604 MVME boards were
> offered (but probably not very popular).
>
> >
> > + device_type = "cpu";
> > + reg = <0>;
> > + clock-frequency = <0>; // filled in by bootwrapper
> > + bus-frequency = <0>; // filled in by bootwrapper
> > + timebase-frequency = <0>; // filled in by bootwrapper
> > + i-cache-line-size = <0>; // filled in by bootwrapper
> > + d-cache-line-size = <0>; // filled in by bootwrapper
> > + d-cache-size = <0>; // filled in by bootwrapper
> > + i-cache-size = <0>; // filled in by bootwrapper
> > + external-control;
> >
> > Really?
>
> Well, is anybody actually using eciwx/ecowx?
Eh, I've removed those properties anyway, the kernel never looks at
them anyway.
> > + graphics;
> > + performance-monitor;
> > +
> > + l2-cache {
> > + device_type = "cache";
> > + i-cache-size = <00100000>;
> > + d-cache-size = <00100000>;
> > + i-cache-sets = <00008000>;
> > + d-cache-sets = <00008000>;
> > + i-cache-line-size = <00000020>;
> > + d-cache-line-size = <00000020>;
> >
> > Drop the leading zeroes, they make my head spin :-)
>
> It's also wrong, my boards have 256kB of L2 cache.
Yeah, I need to fill in the L2 cache information from the residual as
well.
> > + cache-unified;
> > + };
> > + };
> > + };
> > +
> > + memory {
> > + device_type = "memory";
> > + // dummy range here, zImage wrapper will fill in the actual
> > + // amount of memory from the residual data
> > + reg = <00000000 00000000>;
> > + };
> > +
> > + pci@80000000 {
> > + device_type = "pci";
> > + compatible = "prep";
> >
> > Is that specific enough?
>
> On the MVME5100, actually the mapping is more CHRP like, and PCI I/O
> space is smaller and at a higher address. Actually for
> MVME2400/2600/2700, I wrote a bootloader that reprograms the bridge
> in a CHRP like mode since nobody needs almost 1GB of PCI I/O space
> but having 1.5GB of PCI memory space is very useful.
Hrm... ok. Now I'm a bit confused, because I thought what I'd put in
the device tree for PCI was all based on what was already hardcoded /
assumed in prep_pci.c anyway.
> > + clock-frequency = <01fca055>;
> > + reg = <80000000 7effffff>;
> > + 8259-interrupt-acknowledge = <bffffff0>;
>
> Not always. It is at feff0030 on Raven/Falcon/Hawk boards (given
> by a system address assigned to the 8259 PIC in the residual data).
>
> > + #address-cells = <3>;
> > + #size-cells = <2>;
> > + ranges=<01000000 00000000 00000000 80000000 00000000 00800000
> > + 01000000 00000000 00800000 81000000 00000000 3e800000
> > + 02000000 00000000 00000000 c0000000 00000000 01000000
> > + 02000000 00000000 01000000 c1000000 00000000 3e000000>;
> > + interrupt-map-mask = <f800 0 0 7>;
> > + interrupt-map = <6000 0 0 1 &MPIC 6 0
> > + 8000 0 0 1 &MPIC 7 0
> > + 9000 0 0 1 &MPIC 2 0
> > + b000 0 0 1 &MPIC 1 0>;
> >
> > I can't believe this "ranges" and interrupt mapping will
> > work on all PReP systems...
>
> Neither do I.
>
> > + isa {
> > + device_type = "isa";
> > + #address-cells = <2>;
> > + #size-cells = <1>;
> > + #interrupt-cells = <2>;
> > + ranges = <00000001 00000000
> > + 01005800 00000000 00000000 00010000
> > + 00000000 00000000
> > + 02005800 00000000 00000000 01000000>;
> > +
> > + parallel {
> > + device_type = "parallel";
> > + compatible = "ecp", "pnpPNP,400";
> >
> > "pnpPNP,401", "pnpPNP,400"
Adjusted.
> > + reg = <00000001 000003bc 00000008
> > + 00000001 000007bc 00000006>;
> > + interrupts = <00000007 00000003>;
> > + interrupt-parent = <&PIC8259>;
> > + };
> > +
> > + serial@3f8 {
> > + device_type = "serial";
> > + compatible = "pnpPNP,501";
> >
> > "pnpPNP,501", "pnpPNP,500" I'd say. Many/some device
> > tree users will only care it is _some_ 8250 family thing.
Ok.
> > + clock-frequency = <001c2000>;
> > + reg = <00000001 000003f8 00000008>;
> > + interrupts = <00000004 00000003>;
> > + interrupt-parent = <&PIC8259>;
> > + };
> > + serial@2f8 {
> > + device_type = "serial";
> > + compatible = "pnpPNP,501";
> > + clock-frequency = <001c2000>;
> > + reg = <00000001 000002f8 00000008>;
> > + interrupts = <00000003 00000003>;
> > + interrupt-parent = <&PIC8259>;
> > + };
>
> Some of my boards have only one serial port (and also only 1 in the residual data).
Ok, I'll have to think about how to implement that. Probably wants to
wait until we've integrated libfdt for more flexible manipulation of
the device tree.
> > + PIC8259: interrupt-controller {
> > + device_type = "i8259";
> >
> > device_type = "interrupt-controller".
Is that really right? The MPIC binding, at least, has device_type =
"open-pic" rather than "interrupt-controller".
> > + compatible = "prep,iic";
> > + reg = < 00000001 00000020 00000002
> > + 00000001 000000a0 00000002
> > + 00000001 000004d0 00000002>;
> > + interrupts = <00000000 00000003
> > + 00000002 00000003>;
> > + interrupt-parent = <&MPIC>;
> > + };
> > + };
> > +
> > + MPIC: interrupt-controller@d {
> > + device_type = "open-pic";
> >
> > device_type = "interrupt-controller".
Not according to the binding in booting-without-of.txt
> > + compatible = "mpic";
> > + reg = < 00006800 00000000 00000000 00000000 00000000
> > + 02006810 00000000 00000000 00000000 00040000>;
> > + assigned-addresses = <
> > + 82006810 00000000 3afc0000 00000000 00040000>;
> > + };
> > + };
> > +
> > + chosen {
> > + linux,stdout-path = "/pci/isa/serial@3f8";
> > + };
> > +};
> >
> > What is the plan here -- have the bootwrapper build the
> > device tree / fill in the details from the residual data?
>
> I think so. I might have some time to try a more recent kernel
> on MVME2400/2600 boards next week.
>
> Regards,
> Gabriel
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 4/6] PowerPC 440EPx: Sequoia bootwrapper
From: Stefan Roese @ 2007-08-03 6:38 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070802152941.579a55fa@weaponx.rchland.ibm.com>
On Thursday 02 August 2007, Josh Boyer wrote:
> On Mon, 30 Jul 2007 19:14:45 +0400
> > +#define SPRN_CCR1 0x378
> > +void ibm440ep_fixup_clocks(unsigned int sysclk, unsigned int ser_clk)
> > +{
> > + u32 cpu, plb, opb, ebc, tb, uart0, m, vco;
> > + u32 reg;
> > + u32 fwdva, fwdvb, fbdv, lfbdv, opbdv0, perdv0, spcid0, prbdv0, tmp;
> > +
> > + mtdcr(DCRN_CPR0_ADDR, CPR0_PLLD0);
> > + reg = mfdcr(DCRN_CPR0_DATA);
> > + tmp = (reg & 0x000F0000) >> 16;
> > + fwdva = tmp ? tmp : 16;
> > + tmp = (reg & 0x00000700) >> 8;
> > + fwdvb = tmp ? tmp : 8;
> > + tmp = (reg & 0x1F000000) >> 24;
> > + fbdv = tmp ? tmp : 32;
> > + lfbdv = (reg & 0x0000007F);
> > +
> > + mtdcr(DCRN_CPR0_ADDR, CPR0_OPBD0);
> > + reg = mfdcr(DCRN_CPR0_DATA);
> > + tmp = (reg & 0x03000000) >> 24;
> > + opbdv0 = tmp ? tmp : 4;
> > +
> > + mtdcr(DCRN_CPR0_ADDR, CPR0_PERD0);
> > + reg = mfdcr(DCRN_CPR0_DATA);
> > + tmp = (reg & 0x07000000) >> 24;
> > + perdv0 = tmp ? tmp : 8;
> > +
> > + mtdcr(DCRN_CPR0_ADDR, CPR0_PRIMBD0);
> > + reg = mfdcr(DCRN_CPR0_DATA);
> > + tmp = (reg & 0x07000000) >> 24;
> > + prbdv0 = tmp ? tmp : 8;
> > +
> > + mtdcr(DCRN_CPR0_ADDR, CPR0_SCPID);
> > + reg = mfdcr(DCRN_CPR0_DATA);
> > + tmp = (reg & 0x03000000) >> 24;
> > + spcid0 = tmp ? tmp : 4;
> > +
> > + /* Calculate M */
> > + mtdcr(DCRN_CPR0_ADDR, CPR0_PLLC0);
> > + reg = mfdcr(DCRN_CPR0_DATA);
> > + tmp = (reg & 0x03000000) >> 24;
> > + if (tmp == 0) { /* PLL output */
> > + tmp = (reg & 0x20000000) >> 29;
> > + if (!tmp) /* PLLOUTA */
> > + m = fbdv * lfbdv * fwdva;
> > + else
> > + m = fbdv * lfbdv * fwdvb;
> > + }
> > + else if (tmp == 1) /* CPU output */
> > + m = fbdv * fwdva;
> > + else
> > + m = perdv0 * opbdv0 * fwdvb;
> > +
> > + vco = (m * sysclk) + (m >> 1);
> > + cpu = vco / fwdva;
> > + plb = vco / fwdvb / prbdv0;
> > + opb = plb / opbdv0;
> > + ebc = plb / perdv0;
> > +
> > + /* FIXME */
> > + uart0 = ser_clk;
> > +
> > + /* Figure out timebase. Either CPU or default TmrClk */
> > + asm volatile (
> > + "mfspr %0,%1\n"
> > + :
> > + "=&r"(reg) : "i"(SPRN_CCR1));
> > + if (reg & 0x0080)
> > + tb = 25000000; /* TmrClk is 25MHz */
> > + else
> > + tb = cpu;
> > +
> > + dt_fixup_cpu_clocks(cpu, tb, 0);
> > + dt_fixup_clock("/plb", plb);
> > + dt_fixup_clock("/plb/opb", opb);
> > + dt_fixup_clock("/plb/opb/ebc", ebc);
> > + dt_fixup_clock("/plb/opb/serial@ef600300", uart0);
> > + dt_fixup_clock("/plb/opb/serial@ef600400", uart0);
> > + dt_fixup_clock("/plb/opb/serial@ef600500", uart0);
> > + dt_fixup_clock("/plb/opb/serial@ef600600", uart0);
> > +}
>
> We don't need to duplicate this function in two different wrappers.
> I'll move it into 4xx.c in my next round of patches, so that bamboo and
> sequoia can just call a common function.
Good idea.
> > +/*
> > + * 440EPx DDR1/2 memory controller code
> > + * TODO: move to generic 44x code
> > + */
> > +
> > +/* DDR0_02 */
> > +#define DDR_START 0x1
> > +#define DDR_START_SHIFT 0
> > +#define DDR_MAX_CS_REG 0x3
> > +#define DDR_MAX_CS_REG_SHIFT 24
> > +#define DDR_MAX_COL_REG 0xf
> > +#define DDR_MAX_COL_REG_SHIFT 16
> > +#define DDR_MAX_ROW_REG 0xf
> > +#define DDR_MAX_ROW_REG_SHIFT 8
> > +/* DDR0_08 */
> > +#define DDR_DDR2_MODE 0x1
> > +#define DDR_DDR2_MODE_SHIFT 0
> > +/* DDR0_10 */
> > +#define DDR_CS_MAP 0x3
> > +#define DDR_CS_MAP_SHIFT 8
> > +/* DDR0_14 */
> > +#define DDR_REDUC 0x1
> > +#define DDR_REDUC_SHIFT 16
> > +/* DDR0_42 */
> > +#define DDR_APIN 0x7
> > +#define DDR_APIN_SHIFT 24
> > +/* DDR0_43 */
> > +#define DDR_COL_SZ 0x7
> > +#define DDR_COL_SZ_SHIFT 8
> > +#define DDR_BANK8 0x1
> > +#define DDR_BANK8_SHIFT 0
> > +
> > +#define DDR_GET_VAL(val, mask, shift) (((val) >> (shift)) & (mask))
> > +
> > +static void ibm440epx_fixup_memsize(void)
>
> And we should move this at the same time. Isn't denali used by another
> CPU as well?
Right now the Denali DDR(2) core is only used by the 440EPx/440GRx. But other
AMCC PPC's using it will follow soon.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
From: David Gibson @ 2007-08-03 6:43 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <505C0D97-FF0D-4E7F-B988-88894F629FD2@kernel.crashing.org>
On Wed, Jul 18, 2007 at 05:55:16PM +0200, Segher Boessenkool wrote:
> >>> Too big for the list, the patch is at:
> >>> http://ozlabs.org/~dgibson/home/prep-support
> >>
> >> Too lazy to split the patch into bite-size chunks, you mean ;-)
> >
> > Well... much as I like small patches, I don't really like having a big
> > string of patches, each of which does basically nothing on its own,
> > i.e. split up just for the sake of making smaller, rather than into
> > separate logically separate changes.
>
> Yeah I understand. It's just that I had to dig out the DTS
> part :-)
Diddums :-p.
> >> + external-control;
> >>
> >> Really?
> >
> > No idea, just copied that from earlier work of Paulus'. Don't even
> > know what the property means.
>
> It seems to me a flat device tree could leave out all those
> properties that can be derived from the PVR (except for the
> few that are really useful for bootloaders and such -- cache
> line size, 64-bit-or-not, what kind of MMU). Linux doesn't
> use it anyway. Existing DTSs already leave away most.
I agree, ditched them from my dts.
> >> + pci@80000000 {
> >> + device_type = "pci";
> >> + compatible = "prep";
> >>
> >> Is that specific enough?
> >
> > Well, AFAICT, the prep PCI code doesn't need any more info.
>
> If PReP requires a specific programming model for the PCI
> host bridge, that would be fine. But then compatible =
> "prep-pci-bridge" or such, not just "prep"; everything on
> your board is "prep", it would make matching a bit hard ;-)
Well... I'm rather unclear on how much PReP requires of the PCI
bridge. I thought what I'd coded was based on what appeared to be
hard assumptions in prep_pci.c, but now I'm hearing that this won't
cover all PReP machines, so I'm really not sure.
> >> I can't believe this "ranges" and interrupt mapping will
> >> work on all PReP systems...
> >
> > Probably not, but it should work on a chunk of them. Like I say,
> > there's still a good deal more that needs to be filled in from
> > residual data or wherever.
>
> Sure, I'm just pointing out things that seem problematic, I'm
> not saying your code can't be merged because of that -- esp.
> since it is a new port anyway (for arch/powerpc, that is).
>
> >> What is the plan here -- have the bootwrapper build the
> >> device tree / fill in the details from the residual data?
> >
> > Not sure at this stage if it will be best for the bootwrapper to build
> > a complete tree from residual, or to have a dts skeleton with
> > substantial chunks filled in by bootwrapper from residual.
>
> Conceptually those two options are pretty much the same thing;
> just try them out, see what is nicer for the implementation.
>
> > I was
> > intending to merge libfdt into the kernel for more flexible device
> > tree manipulation before investigating that further.
>
> Into the kernel wrapper, I think you mean?
Yes, of course.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 5/6] PowerPC 440EPx: Sequoia board support
From: Stefan Roese @ 2007-08-03 6:44 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070802153451.5a92947b@weaponx.rchland.ibm.com>
On Thursday 02 August 2007, Josh Boyer wrote:
> On Mon, 30 Jul 2007 19:16:28 +0400
> > +0400 +++ linux/arch/powerpc/kernel/cputable.c 2007-07-27
> > 20:44:26.000000000 +0400 @@ -1132,6 +1132,42 @@
> > .dcache_bsize = 32,
> > .platform = "ppc440",
> > },
> > + { /* 440EPX - with Security/Kasumi */
> > + .pvr_mask = 0xf0000fff,
> > + .pvr_value = 0x200008D0,
> > + .cpu_name = "440EPX - with Security/Kasumi",
> > + .cpu_features = CPU_FTRS_44X,
> > + .cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /*
> > 440EPX has an FPU */ + .icache_bsize = 32,
> > + .dcache_bsize = 32,
> > + },
> > + { /* 440EPX - without Security/Kasumi */
> > + .pvr_mask = 0xf0000fff,
> > + .pvr_value = 0x200008D4,
> > + .cpu_name = "440EPX - no Security/Kasumi",
> > + .cpu_features = CPU_FTRS_44X,
> > + .cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /*
> > 440EPX has an FPU */ + .icache_bsize = 32,
> > + .dcache_bsize = 32,
> > + },
> > + { /* 440GRX - with Security/Kasumi */
> > + .pvr_mask = 0xf0000fff,
> > + .pvr_value = 0x200008D8,
> > + .cpu_name = "440GRX - with Security/Kasumi",
> > + .cpu_features = CPU_FTRS_44X,
> > + .cpu_user_features = COMMON_USER_BOOKE, /* 440GRX has no FPU */
> > + .icache_bsize = 32,
> > + .dcache_bsize = 32,
> > + },
> > + { /* 440GRX - without Security/Kasumi */
> > + .pvr_mask = 0xf0000fff,
> > + .pvr_value = 0x200008DC,
> > + .cpu_name = "440GRX - no Security/Kasumi",
> > + .cpu_features = CPU_FTRS_44X,
> > + .cpu_user_features = COMMON_USER_BOOKE, /* 440GRX has no FPU */
> > + .icache_bsize = 32,
> > + .dcache_bsize = 32,
> > + },
>
> Should the 440GRX PVR additions be done in a separate patch? Or is the
> PVR and cpu features truly the only difference between 440EPx and
> 440GRx?
I think it makes sense to add the 440GRx with this patchset too. The 440GRx is
a subset of the 440EPx, missing some stuff like USB, FPU. And the AMCC
Rainier 440GRx eval board is a subset of the Sequoia eval board. So no new
board specific sources should be necessary to support the Rainier, just a
different defconfig file.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] ehca: map 4k firmware context of cq, qp to user space
From: Hoang-Nam Nguyen @ 2007-08-03 8:36 UTC (permalink / raw)
To: Roland Dreier
Cc: Arnd Bergmann, linux-kernel, linuxppc-dev, raisch, paulus,
general
In-Reply-To: <adawswd3ayo.fsf@cisco.com>
From: Hoang-Nam Nguyen <hnguyen at de.ibm.com>
Date: Fri, 3 Aug 2007 09:44:56 +0200
Subject: [PATCH] ehca: map 4k firmware context of cq, qp to user space
This patch utilizes remap_4k_pfn() as introduced by Paul M.,
for details see http://patchwork.ozlabs.org/linuxppc/patch?id=10281,
to map ehca cq, qp firmware context (4k) to user space if kernel page
size is 64k. For reason, why this is required, see also Paul's patch.
In addition to that the kernel page offset of firmware context needs
to be set in cq and qp response block so that user space can assemble
the proper virtual address to use.
An appropriate patch for libehca will follow for ofed-1.3.
Signed-off-by: Hoang-Nam Nguyen <hnguyen@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_classes.h | 4 +++-
drivers/infiniband/hw/ehca/ehca_cq.c | 2 ++
drivers/infiniband/hw/ehca/ehca_qp.c | 2 ++
drivers/infiniband/hw/ehca/ehca_uverbs.c | 6 +++---
4 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h b/drivers/infiniband/hw/ehca/ehca_classes.h
index b5e9603..206d4eb 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -337,6 +337,8 @@ struct ehca_create_cq_resp {
u32 cq_number;
u32 token;
struct ipzu_queue_resp ipz_queue;
+ u32 fw_handle_ofs;
+ u32 dummy;
};
struct ehca_create_qp_resp {
@@ -347,7 +349,7 @@ struct ehca_create_qp_resp {
u32 qkey;
/* qp_num assigned by ehca: sqp0/1 may have got different numbers */
u32 real_qp_num;
- u32 dummy; /* padding for 8 byte alignment */
+ u32 fw_handle_ofs;
struct ipzu_queue_resp ipz_squeue;
struct ipzu_queue_resp ipz_rqueue;
};
diff --git a/drivers/infiniband/hw/ehca/ehca_cq.c b/drivers/infiniband/hw/ehca/ehca_cq.c
index 81aff36..ed5d67f 100644
--- a/drivers/infiniband/hw/ehca/ehca_cq.c
+++ b/drivers/infiniband/hw/ehca/ehca_cq.c
@@ -276,6 +276,8 @@ struct ib_cq *ehca_create_cq(struct ib_device *device, int cqe, int comp_vector,
resp.ipz_queue.queue_length = ipz_queue->queue_length;
resp.ipz_queue.pagesize = ipz_queue->pagesize;
resp.ipz_queue.toggle_state = ipz_queue->toggle_state;
+ resp.fw_handle_ofs = (u32)
+ (my_cq->galpas.user.fw_handle & (PAGE_SIZE - 1));
if (ib_copy_to_udata(udata, &resp, sizeof(resp))) {
ehca_err(device, "Copy to udata failed.");
goto create_cq_exit4;
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c b/drivers/infiniband/hw/ehca/ehca_qp.c
index b178cba..66f632c 100644
--- a/drivers/infiniband/hw/ehca/ehca_qp.c
+++ b/drivers/infiniband/hw/ehca/ehca_qp.c
@@ -745,6 +745,8 @@ static struct ehca_qp *internal_create_qp(
queue2resp(&resp.ipz_squeue, &my_qp->ipz_squeue);
if (HAS_RQ(my_qp))
queue2resp(&resp.ipz_rqueue, &my_qp->ipz_rqueue);
+ resp.fw_handle_ofs = (u32)
+ (my_qp->galpas.user.fw_handle & (PAGE_SIZE - 1));
if (ib_copy_to_udata(udata, &resp, sizeof resp)) {
ehca_err(pd->device, "Copy to udata failed");
diff --git a/drivers/infiniband/hw/ehca/ehca_uverbs.c b/drivers/infiniband/hw/ehca/ehca_uverbs.c
index 4bc687f..be062f1 100644
--- a/drivers/infiniband/hw/ehca/ehca_uverbs.c
+++ b/drivers/infiniband/hw/ehca/ehca_uverbs.c
@@ -109,7 +109,7 @@ static int ehca_mmap_fw(struct vm_area_struct *vma, struct h_galpas *galpas,
u64 vsize, physical;
vsize = vma->vm_end - vma->vm_start;
- if (vsize != EHCA_PAGESIZE) {
+ if (vsize >= EHCA_PAGESIZE) {
ehca_gen_err("invalid vsize=%lx", vma->vm_end - vma->vm_start);
return -EINVAL;
}
@@ -118,8 +118,8 @@ static int ehca_mmap_fw(struct vm_area_struct *vma, struct h_galpas *galpas,
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
ehca_gen_dbg("vsize=%lx physical=%lx", vsize, physical);
/* VM_IO | VM_RESERVED are set by remap_pfn_range() */
- ret = remap_pfn_range(vma, vma->vm_start, physical >> PAGE_SHIFT,
- vsize, vma->vm_page_prot);
+ ret = remap_4k_pfn(vma, vma->vm_start, physical >> EHCA_PAGESHIFT,
+ vma->vm_page_prot);
if (unlikely(ret)) {
ehca_gen_err("remap_pfn_range() failed ret=%x", ret);
return -ENOMEM;
--
1.5.2
^ permalink raw reply related
* Re: [PATCH 5/6] PowerPC 440EPx: Sequoia board support
From: Kumar Gala @ 2007-08-03 8:39 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20070802153222.6482ae85@weaponx.rchland.ibm.com>
On Aug 2, 2007, at 3:32 PM, Josh Boyer wrote:
> On Wed, 1 Aug 2007 15:05:42 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
>> On Wed, Aug 01, 2007 at 07:01:17AM +0200, Segher Boessenkool wrote:
>>>>> + { /* 440EPX - without Security/Kasumi */
>>>>> + .pvr_mask = 0xf0000fff,
>>>>> + .pvr_value = 0x200008D4,
>>>>> + .cpu_name = "440EPX - no Security/Kasumi",
>>>>> + .cpu_features = CPU_FTRS_44X,
>>>>> + .cpu_user_features = COMMON_USER_BOOKE |
>>>>> PPC_FEATURE_HAS_FPU, /*
>>>>> 440EPX has an FPU */
>>>>> + .icache_bsize = 32,
>>>>> + .dcache_bsize = 32,
>>>>> + },
>>>>
>>>> Since the with/without Security/Kasumi versions have no
>>>> differences in
>>>> their cputable entry other than the PVR, couldn't you just
>>>> remove the
>>>> relevant PVR bit from the mask and use a single entry?
>>>
>>> And get rid of the stupid "has an FPU" comment at the same time
>>> please :-)
>>
>> Actually that comment may be worthwhile if expanded a little. I
>> think
>> the point is that 440EPx *unlike most other 4xx chips* has an
>> FPU. So
>> the point of the comment is not explaining the feature bit, which is
>> obvious, but as a "no, really, it does".
>
> Right. 440EP(x) are the only currently available 44x chips that
> contain an FPU, so I also think the comment can stay.
I agree w/Segher the comment is redundant. Just make a note of the
fact that we really have FPU in the commit message.
- k
^ permalink raw reply
* [PATCH] Expand RPN field to 34 bits when using 64k pages
From: Paul Mackerras @ 2007-08-03 8:44 UTC (permalink / raw)
To: linuxppc-dev
The real page number field in our PTEs when configured for 64kB pages
is currently 32 bits, which turns out to be not quite enough for the
resources that the eHCA driver wants to map. This expands the RPN
field to include 2 adjacent, previously-unused bits.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
diff --git a/include/asm-powerpc/pgtable-64k.h b/include/asm-powerpc/pgtable-64k.h
index 31cbd3d..33ae901 100644
--- a/include/asm-powerpc/pgtable-64k.h
+++ b/include/asm-powerpc/pgtable-64k.h
@@ -49,12 +49,10 @@
/* Shift to put page number into pte.
*
- * That gives us a max RPN of 32 bits, which means a max of 48 bits
- * of addressable physical space.
- * We could get 3 more bits here by setting PTE_RPN_SHIFT to 29 but
- * 32 makes PTEs more readable for debugging for now :)
+ * That gives us a max RPN of 34 bits, which means a max of 50 bits
+ * of addressable physical space, or 46 bits for the special 4k PFNs.
*/
-#define PTE_RPN_SHIFT (32)
+#define PTE_RPN_SHIFT (30)
#define PTE_RPN_MAX (1UL << (64 - PTE_RPN_SHIFT))
#define PTE_RPN_MASK (~((1UL<<PTE_RPN_SHIFT)-1))
^ permalink raw reply related
* [GIT PATCH] ucc_geth fixes for 2.6.22-rc1
From: Li Yang @ 2007-08-03 9:07 UTC (permalink / raw)
To: jeff; +Cc: netdev, linuxppc-embedded
Please pull from 'ucc_geth' branch of
master.kernel.org:/pub/scm/linux/kernel/git/leo/fsl-soc.git ucc_geth
to receive the following fixes:
drivers/net/ucc_geth_ethtool.c | 1 -
drivers/net/ucc_geth_mii.c | 3 ++-
2 files changed, 2 insertions(+), 2 deletions(-)
Domen Puncer (1):
ucc_geth: fix section mismatch
Jan Altenberg (1):
ucc_geth: remove get_perm_addr from ucc_geth_ethtool.c
diff --git a/drivers/net/ucc_geth_ethtool.c
b/drivers/net/ucc_geth_ethtool.c
index a8994c7..64bef7c 100644
--- a/drivers/net/ucc_geth_ethtool.c
+++ b/drivers/net/ucc_geth_ethtool.c
@@ -379,7 +379,6 @@ static const struct ethtool_ops uec_ethtool_ops = {
.get_stats_count = uec_get_stats_count,
.get_strings = uec_get_strings,
.get_ethtool_stats = uec_get_ethtool_stats,
- .get_perm_addr = ethtool_op_get_perm_addr,
};
void uec_set_ethtool_ops(struct net_device *netdev)
diff --git a/drivers/net/ucc_geth_mii.c b/drivers/net/ucc_geth_mii.c
index 5f8c2d3..6c257b8 100644
--- a/drivers/net/ucc_geth_mii.c
+++ b/drivers/net/ucc_geth_mii.c
@@ -272,7 +272,8 @@ int __init uec_mdio_init(void)
return of_register_platform_driver(&uec_mdio_driver);
}
-void __exit uec_mdio_exit(void)
+/* called from __init ucc_geth_init, therefore can not be __exit */
+void uec_mdio_exit(void)
{
of_unregister_platform_driver(&uec_mdio_driver);
}
^ permalink raw reply related
* [PATCH] Fix special PTE code for secondary hash bucket
From: Paul Mackerras @ 2007-08-03 8:58 UTC (permalink / raw)
To: linuxppc-dev
The code for mapping special 4k pages on kernels using a 64kB base
page size was missing the code for doing the RPN (real page number)
manipulation when inserting the hardware PTE in the secondary hash
bucket. It needs the same code as has already been added to the
code that inserts the HPTE in the primary hash bucket. This adds it.
Spotted by Ben Herrenschmidt.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/arch/powerpc/mm/hash_low_64.S b/arch/powerpc/mm/hash_low_64.S
index 4762ff7..35eabfb 100644
--- a/arch/powerpc/mm/hash_low_64.S
+++ b/arch/powerpc/mm/hash_low_64.S
@@ -472,10 +472,12 @@ _GLOBAL(htab_call_hpte_insert1)
/* Now try secondary slot */
/* real page number in r5, PTE RPN value + index */
- rldicl r5,r31,64-PTE_RPN_SHIFT,PTE_RPN_SHIFT
+ andis. r0,r31,_PAGE_4K_PFN@h
+ srdi r5,r31,PTE_RPN_SHIFT
+ bne- 3f
sldi r5,r5,PAGE_SHIFT-HW_PAGE_SHIFT
add r5,r5,r25
- sldi r5,r5,HW_PAGE_SHIFT
+3: sldi r5,r5,HW_PAGE_SHIFT
/* Calculate secondary group hash */
andc r0,r27,r28
^ permalink raw reply related
* Re: Generic clk.h wrappers? [Was: Re: [PATCH 1/3] powerpc clk.h interface for platforms]
From: Russell King @ 2007-08-03 8:36 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, linux-mips, Christoph Hellwig, Domen Puncer
In-Reply-To: <200708021632.13982.david-b@pacbell.net>
On Thu, Aug 02, 2007 at 04:32:13PM -0700, David Brownell wrote:
> On Wednesday 01 August 2007, Christoph Hellwig wrote:
> > On Wed, Aug 01, 2007 at 09:28:07AM +0200, Domen Puncer wrote:
> > > > It doesn't make any assumption on struct clk, it's just a
> > > > wrapper around functions from clk.h.
> > > > Point of this patch was to abstract exported functions, since
> > > > arch/powerpc/ can support multiple platfroms in one binary.
> > >
> > > So... the thread just ended without any consensus, ACK or whatever.
> > >
> > > Choices I see:
> > > - have EXPORT_SYMBOL for clk.h functions in ie. lib/clock.c and have
> > > every implemenation fill some global struct.
> > > - leave this patch as it is, abstraction only for arch/powerpc/.
>
> That seems the best solution for now, I agree.
I've not been avoiding replying further to this thread in spite, it's
just that I've not had any time what so ever to look at this further.
It's very low priority for me at the moment, so it's getting zero time,
and will continue to be in that state for at least the next month and
a bit. Sorry.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: [PATCH] Fix FSL BookE machine check reporting
From: Paul Mackerras @ 2007-08-03 9:18 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev
In-Reply-To: <11860870353423-git-send-email-becky.bruce@freescale.com>
Becky Bruce writes:
> Reserved MCSR bits on FSL BookE parts may have spurious values
> when mcheck occurs. Mask these off when printing the MCSR to
> avoid confusion. Also, get rid of the MCSR_GL_CI bit defined
> for e500 - this bit doesn't actually have any meaning.
Is this needed for 2.6.23?
Paul.
^ permalink raw reply
* Re: [PATCH] Fix FSL BookE machine check reporting
From: Kumar Gala @ 2007-08-03 9:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18098.62189.596336.471217@cargo.ozlabs.ibm.com>
On Aug 3, 2007, at 4:18 AM, Paul Mackerras wrote:
> Becky Bruce writes:
>
>> Reserved MCSR bits on FSL BookE parts may have spurious values
>> when mcheck occurs. Mask these off when printing the MCSR to
>> avoid confusion. Also, get rid of the MCSR_GL_CI bit defined
>> for e500 - this bit doesn't actually have any meaning.
>
> Is this needed for 2.6.23?
It would be nice. I'll queue it up with some other fixes for 2.6.23.
- k
^ permalink raw reply
* Re: [spi-devel-general] [PATCH] [SPI][POWERPC] spi_mpc83xx: in "QE mode" spiclk is sysclk/2
From: Kumar Gala @ 2007-08-03 9:29 UTC (permalink / raw)
To: David Brownell; +Cc: spi-devel-general, linuxppc-dev
In-Reply-To: <200708021447.22028.david-b@pacbell.net>
On Aug 2, 2007, at 4:47 PM, David Brownell wrote:
> On Thursday 02 August 2007, Anton Vorontsov wrote:
>> Probably someday mpc83xx_spi->sysclk should be renamed to
>> mpc83xx_spi->spiclk to be less confusing.
>
> Why not "today", with this patch? That would fix some of
> the root cause of this bug...
I'm fine with this as well. I just called it sysclk to start with
since when I wrote the driver it was just for the MPC834x.
- k
^ permalink raw reply
* Re: 2.6.23-rc1-mm2
From: Kumar Gala @ 2007-08-03 9:39 UTC (permalink / raw)
To: Mariusz Kozlowski
Cc: linux-usb-devel, gregkh, linux-kernel, linuxppc-dev,
Paul Mackerras, Andrew Morton
In-Reply-To: <200708021214.51705.m.kozlowski@tuxland.pl>
On Aug 2, 2007, at 5:14 AM, Mariusz Kozlowski wrote:
>>> Second issue as reported earilier allmodconfig fails to build on
>>> imac g3.
>>
>> Do you really mean g3? If so it's a 32-bit kernel and it
>> shouldn't be
>> building lparmap.s. Or do you mean G5?
>
> Yes it is iMac G3. More or less sth like this:
> http://upload.wikimedia.org/wikipedia/commons/c/c0/IMac_Bondi_Blue.jpg
>
> processor : 0
> cpu : 740/750
> temperature : 47-49 C (uncalibrated)
> clock : 400MHz
> revision : 2.2 (pvr 0008 0202)
> bogomips : 796.67
> machine : PowerMac2,1
> motherboard : PowerMac2,1 MacRISC2 MacRISC Power Macintosh
> detected as : 66 (iMac FireWire)
> pmac flags : 00000005
> L2 cache : 512K unified
> memory : 256MB
> pmac-generation : NewWorld
>
>>> CC arch/powerpc/kernel/lparmap.s
>>> AS arch/powerpc/kernel/head_64.o
>>> lparmap.c: Assembler messages:
>>> lparmap.c:84: Error: file number 1 already allocated
>>> make[1]: *** [arch/powerpc/kernel/head_64.o] Blad 1
>>> make: *** [arch/powerpc/kernel] Blad 2
>>
>> Weird. Could you do make V=1 and send me the output?
>
> Ok. Here it goes. The last screen. If you need all / more feel free
> to mail
> me. Config is attached - please note that this is default
> allmodconfig.
>
>
>
> gcc -m64 -Wp,-MD,arch/powerpc/kernel/.machine_kexec.o.d -nostdinc -
> isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -D__KERNEL__ -
> Iinclude -include
> include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-
> trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-
> function-declaration -Os -msoft-float -pipe -mminimal-toc -
> mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec -funit-at-
> a-time -mno-string -Wa,-maltivec -fomit-frame-pointer -g -fno-
> stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -
> mno-minimal-toc -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR
> (machine_kexec)" -D"KBUILD_MODNAME=KBUILD_STR(machine_kexec)" -c -o
> arch/powerpc/kernel/.tmp_machine_kexec.o arch/powerpc/kernel/
> machine_kexec.c
>
> gcc -m64 -Wp,-MD,arch/powerpc/kernel/.crash.o.d -nostdinc -
> isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -D__KERNEL__ -
> Iinclude -include
> include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-
> trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-
> function-declaration -Os -msoft-float -pipe -mminimal-toc -
> mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec -funit-at-
> a-time -mno-string -Wa,-maltivec -fomit-frame-pointer -g -fno-
> stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -
> mno-minimal-toc -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR
> (crash)" -D"KBUILD_MODNAME=KBUILD_STR(crash)" -c -o
> arch/powerpc/kernel/.tmp_crash.o arch/powerpc/kernel/crash.c
>
> gcc -m64 -Wp,-MD,arch/powerpc/kernel/.machine_kexec_64.o.d -
> nostdinc -isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -
> D__KERNEL__ -Iinclude -include
> include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-
> trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-
> function-declaration -Os -msoft-float -pipe -mminimal-toc -
> mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec -funit-at-
> a-time -mno-string -Wa,-maltivec -fomit-frame-pointer -g -fno-
> stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -
> mno-minimal-toc -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR
> (machine_kexec_64)" -D"KBUILD_MODNAME=KBUILD_STR
> (machine_kexec_64)" -c -o
> arch/powerpc/kernel/.tmp_machine_kexec_64.o
> arch/powerpc/kernel/machine_kexec_64.c
>
> gcc -m64 -Wp,-MD,arch/powerpc/kernel/.audit.o.d -nostdinc -
> isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -D__KERNEL__ -
> Iinclude -include
> include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-
> trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-
> function-declaration -Os -msoft-float -pipe -mminimal-toc -
> mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec -funit-at-
> a-time -mno-string -Wa,-maltivec -fomit-frame-pointer -g -fno-
> stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -
> mno-minimal-toc -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR
> (audit)" -D"KBUILD_MODNAME=KBUILD_STR(audit)" -c -o
> arch/powerpc/kernel/.tmp_audit.o arch/powerpc/kernel/audit.c
>
> gcc -m64 -Wp,-MD,arch/powerpc/kernel/.swsusp_64.o.d -nostdinc -
> isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -D__KERNEL__ -
> Iinclude -include
> include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-
> trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-
> function-declaration -Os -msoft-float -pipe -mminimal-toc -
> mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec -funit-at-
> a-time -mno-string -Wa,-maltivec -fomit-frame-pointer -g -fno-
> stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -
> mno-minimal-toc -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR
> (swsusp_64)" -D"KBUILD_MODNAME=KBUILD_STR(swsusp_64)" -c -o
> arch/powerpc/kernel/.tmp_swsusp_64.o arch/powerpc/kernel/swsusp_64.c
>
> gcc -m64 -Wp,-MD,arch/powerpc/kernel/.swsusp_asm64.o.d -nostdinc -
> isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -D__KERNEL__ -
> Iinclude -include
> include/linux/autoconf.h -D__ASSEMBLY__ -Wa,-maltivec -
> gdwarf2 -c -o
> arch/powerpc/kernel/swsusp_asm64.o arch/powerpc/kernel/swsusp_asm64.S
>
> gcc -m64 -Wp,-MD,arch/powerpc/kernel/.compat_audit.o.d -nostdinc -
> isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -D__KERNEL__ -
> Iinclude -include
> include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-
> trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-
> function-declaration -Os -msoft-float -pipe -mminimal-toc -
> mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec -funit-at-
> a-time -mno-string -Wa,-maltivec -fomit-frame-pointer -g -fno-
> stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -
> mno-minimal-toc -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR
> (compat_audit)" -D"KBUILD_MODNAME=KBUILD_STR(compat_audit)" -c -o
> arch/powerpc/kernel/.tmp_compat_audit.o arch/powerpc/kernel/
> compat_audit.c
> ld -m elf64ppc -r -o arch/powerpc/kernel/built-in.o
> arch/powerpc/kernel/semaphore.o arch/powerpc/kernel/cputable.o
> arch/powerpc/kernel/ptrace.o arch/powerpc/kernel/syscalls.o
> arch/powerpc/kernel/irq.o arch/powerpc/kernel/align.o
> arch/powerpc/kernel/signal_32.o arch/powerpc/kernel/pmc.o
> arch/powerpc/kernel/vdso.o arch/powerpc/kernel/init_task.o
> arch/powerpc/kernel/process.o arch/powerpc/kernel/systbl.o
> arch/powerpc/kernel/idle.o arch/powerpc/kernel/signal.o
> arch/powerpc/kernel/vdso32/built-in.o arch/powerpc/kernel/setup_64.o
> arch/powerpc/kernel/binfmt_elf32.o arch/powerpc/kernel/sys_ppc32.o
> arch/powerpc/kernel/signal_64.o arch/powerpc/kernel/ptrace32.o
> arch/powerpc/kernel/paca.o arch/powerpc/kernel/cpu_setup_ppc970.o
> arch/powerpc/kernel/cpu_setup_pa6t.o arch/powerpc/kernel/firmware.o
> arch/powerpc/kernel/sysfs.o arch/powerpc/kernel/nvram_64.o
> arch/powerpc/kernel/vdso64/built-in.o arch/powerpc/kernel/vecemu.o
> arch/powerpc/kernel/vector.o arch/powerpc/kernel/idle_power4.o
> arch/powerpc/kernel/of_device.o arch/powerpc/kernel/of_platform.o
> arch/powerpc/kernel/prom_parse.o arch/powerpc/kernel/proc_ppc64.o
> arch/powerpc/kernel/rtas.o arch/powerpc/kernel/rtas-rtc.o
> arch/powerpc/kernel/rtas_pci.o arch/powerpc/kernel/rtas-proc.o
> arch/powerpc/kernel/lparcfg.o arch/powerpc/kernel/vio.o
> arch/powerpc/kernel/ibmebus.o arch/powerpc/kernel/smp-tbsync.o
> arch/powerpc/kernel/crash_dump.o arch/powerpc/kernel/swsusp.o
> arch/powerpc/kernel/suspend.o arch/powerpc/kernel/time.o
> arch/powerpc/kernel/prom.o arch/powerpc/kernel/traps.o
> arch/powerpc/kernel/setup-common.o arch/powerpc/kernel/udbg.o
> arch/powerpc/kernel/misc.o arch/powerpc/kernel/io.o
> arch/powerpc/kernel/misc_64.o arch/powerpc/kernel/dma_64.o
> arch/powerpc/kernel/iommu.o arch/powerpc/kernel/prom_init.o
> arch/powerpc/kernel/ppc_ksyms.o arch/powerpc/kernel/btext.o
> arch/powerpc/kernel/smp.o arch/powerpc/kernel/kprobes.o
> arch/powerpc/kernel/legacy_serial.o arch/powerpc/kernel/udbg_16550.o
> arch/powerpc/kernel/kgdb.o arch/powerpc/kernel/kgdb_setjmp64.o
> arch/powerpc/kernel/module_64.o arch/powerpc/kernel/pci_64.o
> arch/powerpc/kernel/pci_dn.o arch/powerpc/kernel/isa-bridge.o
> arch/powerpc/kernel/pci-common.o arch/powerpc/kernel/msi.o
> arch/powerpc/kernel/machine_kexec.o arch/powerpc/kernel/crash.o
> arch/powerpc/kernel/machine_kexec_64.o arch/powerpc/kernel/audit.o
> arch/powerpc/kernel/swsusp_64.o arch/powerpc/kernel/swsusp_asm64.o
> arch/powerpc/kernel/compat_audit.o
>
> gcc -m64 -Wp,-MD,arch/powerpc/kernel/.lparmap.s.d -nostdinc -
> isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -D__KERNEL__ -
> Iinclude -include
> include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-
> trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-
> function-declaration -Os -msoft-float -pipe -mminimal-toc -
> mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec -funit-at-
> a-time -mno-string -Wa,-maltivec -fomit-frame-pointer -g -fno-
> stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -
> mno-minimal-toc -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR
> (lparmap)" -D"KBUILD_MODNAME=KBUILD_STR(lparmap)" -fverbose-asm -S -o
> arch/powerpc/kernel/lparmap.s arch/powerpc/kernel/lparmap.c
>
> gcc -m64 -Wp,-MD,arch/powerpc/kernel/.head_64.o.d -nostdinc -
> isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -D__KERNEL__ -
> Iinclude -include
> include/linux/autoconf.h -D__ASSEMBLY__ -Wa,-maltivec -gdwarf2 -
> Iarch/powerpc/kernel -c -o
> arch/powerpc/kernel/head_64.o arch/powerpc/kernel/head_64.S
> lparmap.c: Assembler messages:
> lparmap.c:84: Error: file number 1 already allocated
> make[1]: *** [arch/powerpc/kernel/head_64.o] Blad 1
> make: *** [arch/powerpc/kernel] Blad 2
Some how your defconfig is targeting a PPC64 box:
CONFIG_PPC64=y
shouldn't be set if you want to build a kernel for a G3 imac.
- k
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-08-03 10:32 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get another batch of bug-fixes for powerpc.
Thanks,
Paul.
arch/powerpc/kernel/entry_64.S | 3 +++
arch/powerpc/kernel/pci_32.c | 5 ++++-
arch/powerpc/kernel/smp.c | 9 +++------
arch/powerpc/mm/hash_low_64.S | 6 ++++--
arch/powerpc/mm/hash_utils_64.c | 2 +-
arch/powerpc/mm/numa.c | 4 ++--
arch/powerpc/mm/slb.c | 28 ++++++++++++++++++----------
arch/powerpc/platforms/cell/spufs/sched.c | 3 ++-
arch/powerpc/platforms/powermac/feature.c | 6 ++++--
arch/powerpc/platforms/ps3/setup.c | 2 +-
include/asm-powerpc/mmu-hash64.h | 1 +
include/asm-powerpc/pgtable-64k.h | 8 +++-----
12 files changed, 46 insertions(+), 31 deletions(-)
Andre Detsch (1):
[POWERPC] spufs: Fix affinity after introduction of node_allowed() calls
Kevin Corry (1):
[POWERPC] Fix num_cpus calculation in smp_call_function_map()
Michael Ellerman (1):
[POWERPC] Fix parse_drconf_memory() for 64-bit start addresses
Michael Neuling (1):
[POWERPC] Fixes for the SLB shadow buffer code
Paul Mackerras (2):
[POWERPC] Expand RPN field to 34 bits when using 64k pages
[POWERPC] Fix special PTE code for secondary hash bucket
Segher Boessenkool (2):
[POWERPC] Fix a compile warning in pci_32.c
[POWERPC] Fix a compile warning in powermac/feature.c
Stephen Rothwell (1):
[POWERPC] ps3: Fix section mismatch in ps3/setup.c
^ permalink raw reply
* Re: [ PATCH ] PowerPC cascade UIC IRQ handler fix.
From: Valentine Barshak @ 2007-08-03 11:09 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20070802150852.39701576@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Thu, 2 Aug 2007 13:48:48 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
>> On Mon, Jul 30, 2007 at 08:35:17PM +0400, Valentine Barshak wrote:
>>> PPC44x cascade UIC irq handler fix.
>>>
>>> According to PPC44x UM, if an interrupt is configured as
>>> level-sensitive, and a clear is attempted on the UIC_SR, the UIC_SR
>>> field is not cleared if the incoming interrupt signal is at the
>>> asserted polarity. This causes us to enter a cascade handler twice,
>>> since we first ack parent UIC interrupt and ack child UIC one after
>>> that. The patch checks child UIC msr value and returns IRQ_HANDLED
>>> if there're no pending interrupts. Otherwise we get a kernel panic
>>> with a "Fatal exception in interrupt" (illegal vector).
>>> The patch also fixes status flags.
>>>
>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>> Hrm... This doesn't seem like the right fix to me. Instead, I think
>> the cascaded IRQ handler should ack the interrupt on the child first.
>> I'm a little surprised it doesn't at the moment.
>
> Agreed. Anyone going to hack up a patch for that?
>
> josh
Anyways, I don't see why kernel should panic if we get a spurious interrupt.
^ permalink raw reply
* reg : SM722 Linux driver
From: mahendra varman @ 2007-08-03 11:21 UTC (permalink / raw)
To: linuxppc-embedded
Hi Members
Iam in need of SM722 Linux driver source code for Linux 2.6 or for Linux 2.4
Help me to find the source code
Thanks
Mahendra
^ permalink raw reply
* Re: [PATCH 5/6] PowerPC 440EPx: Sequoia board support
From: Valentine Barshak @ 2007-08-03 11:20 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070802153451.5a92947b@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Mon, 30 Jul 2007 19:16:28 +0400
> Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
>> diff -ruN linux.orig/arch/powerpc/kernel/cputable.c linux/arch/powerpc/kernel/cputable.c
>> --- linux.orig/arch/powerpc/kernel/cputable.c 2007-07-27 20:37:10.000000000 +0400
>> +++ linux/arch/powerpc/kernel/cputable.c 2007-07-27 20:44:26.000000000 +0400
>> @@ -1132,6 +1132,42 @@
>> .dcache_bsize = 32,
>> .platform = "ppc440",
>> },
>> + { /* 440EPX - with Security/Kasumi */
>> + .pvr_mask = 0xf0000fff,
>> + .pvr_value = 0x200008D0,
>> + .cpu_name = "440EPX - with Security/Kasumi",
>> + .cpu_features = CPU_FTRS_44X,
>> + .cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /* 440EPX has an FPU */
>> + .icache_bsize = 32,
>> + .dcache_bsize = 32,
>> + },
>> + { /* 440EPX - without Security/Kasumi */
>> + .pvr_mask = 0xf0000fff,
>> + .pvr_value = 0x200008D4,
>> + .cpu_name = "440EPX - no Security/Kasumi",
>> + .cpu_features = CPU_FTRS_44X,
>> + .cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /* 440EPX has an FPU */
>> + .icache_bsize = 32,
>> + .dcache_bsize = 32,
>> + },
>> + { /* 440GRX - with Security/Kasumi */
>> + .pvr_mask = 0xf0000fff,
>> + .pvr_value = 0x200008D8,
>> + .cpu_name = "440GRX - with Security/Kasumi",
>> + .cpu_features = CPU_FTRS_44X,
>> + .cpu_user_features = COMMON_USER_BOOKE, /* 440GRX has no FPU */
>> + .icache_bsize = 32,
>> + .dcache_bsize = 32,
>> + },
>> + { /* 440GRX - without Security/Kasumi */
>> + .pvr_mask = 0xf0000fff,
>> + .pvr_value = 0x200008DC,
>> + .cpu_name = "440GRX - no Security/Kasumi",
>> + .cpu_features = CPU_FTRS_44X,
>> + .cpu_user_features = COMMON_USER_BOOKE, /* 440GRX has no FPU */
>> + .icache_bsize = 32,
>> + .dcache_bsize = 32,
>> + },
>
> Should the 440GRX PVR additions be done in a separate patch? Or is the
> PVR and cpu features truly the only difference between 440EPx and
> 440GRx?
440GRx Doesn't have USB (host/device) controllers and and FPU.
Actually, I have a 440GRx board with the same PVR valus as 440EPx has.
HW bug may be?
I think I'll remove 440GRx for now.
>
>> diff -ruN linux.orig/arch/powerpc/platforms/44x/sequoia.c linux/arch/powerpc/platforms/44x/sequoia.c
>> --- linux.orig/arch/powerpc/platforms/44x/sequoia.c 1970-01-01 03:00:00.000000000 +0300
>> +++ linux/arch/powerpc/platforms/44x/sequoia.c 2007-07-27 20:44:26.000000000 +0400
>> @@ -0,0 +1,66 @@
>> +/*
>> + * Sequoia board specific routines
>> + *
>> + * Wade Farnsworth <wfarnsworth@mvista.com>
>> + * Copyright 2004-2007 MontaVista Software Inc.
>> + *
>> + * Rewritten and ported to the merged powerpc tree:
>> + * Josh Boyer <jwboyer@linux.vnet.ibm.com>
>> + * Copyright 2007 IBM Corporation
>
> I didn't really do this. Might want to give yourself credit instead :).
>
> josh
I'll change it to "base on Bamboo code by Josh" :)
^ permalink raw reply
* Re: [PATCH 6/6] PowerPC 440EPx: Sequoia new EMAC support
From: Valentine Barshak @ 2007-08-03 11:25 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070802153551.2a8ad14d@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Mon, 30 Jul 2007 19:23:39 +0400
> Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
>> The patch adds PHY support for the Sequoia board to the new EMAC driver and
>> enables NEW_EMAC for 440EPx Kconfig.
>> The phy code has been written by Stefan Roese.
>> This has been tested with the following version of the EMAC dirver:
>>
>> http://ozlabs.org/~dgibson/home/emac/powerpc-emac-new-20070516.patch
>>
>> Signed-off-by: Stefan Roese <sr@denx.de>
>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>> ---
>> arch/powerpc/platforms/44x/Kconfig | 5 +---
>> drivers/net/ibm_newemac/phy.c | 39 +++++++++++++++++++++++++++++++++++++
>> 2 files changed, 41 insertions(+), 3 deletions(-)
>>
>> --- linux.orig/arch/powerpc/platforms/44x/Kconfig 2007-07-30 15:05:50.000000000 +0400
>> +++ linux/arch/powerpc/platforms/44x/Kconfig 2007-07-30 17:59:05.000000000 +0400
>> @@ -47,9 +47,8 @@
>> config 440EPX
>> bool
>> select PPC_FPU
>> -# Disabled until the new EMAC Driver is merged.
>> -# select IBM_NEW_EMAC_EMAC4
>> -# select IBM_NEW_EMAC_ZMII
>> + select IBM_NEW_EMAC_EMAC4
>> + select IBM_NEW_EMAC_ZMII
>
> Probably don't want this bit yet. The EMAC driver isn't really merged
> yet.
>
> josh
Actually, this one is intended for use as a separate Sequoia emac
support patch until new emac is merged. May be I should submit it
separately, not with the whole Sequoia bundle.
^ permalink raw reply
* Re: [PATCH 5/6] PowerPC 440EPx: Sequoia board support
From: Valentine Barshak @ 2007-08-03 11:36 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200708030844.13895.sr@denx.de>
Stefan Roese wrote:
> On Thursday 02 August 2007, Josh Boyer wrote:
>> On Mon, 30 Jul 2007 19:16:28 +0400
>>> +0400 +++ linux/arch/powerpc/kernel/cputable.c 2007-07-27
>>> 20:44:26.000000000 +0400 @@ -1132,6 +1132,42 @@
>>> .dcache_bsize = 32,
>>> .platform = "ppc440",
>>> },
>>> + { /* 440EPX - with Security/Kasumi */
>>> + .pvr_mask = 0xf0000fff,
>>> + .pvr_value = 0x200008D0,
>>> + .cpu_name = "440EPX - with Security/Kasumi",
>>> + .cpu_features = CPU_FTRS_44X,
>>> + .cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /*
>>> 440EPX has an FPU */ + .icache_bsize = 32,
>>> + .dcache_bsize = 32,
>>> + },
>>> + { /* 440EPX - without Security/Kasumi */
>>> + .pvr_mask = 0xf0000fff,
>>> + .pvr_value = 0x200008D4,
>>> + .cpu_name = "440EPX - no Security/Kasumi",
>>> + .cpu_features = CPU_FTRS_44X,
>>> + .cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /*
>>> 440EPX has an FPU */ + .icache_bsize = 32,
>>> + .dcache_bsize = 32,
>>> + },
>>> + { /* 440GRX - with Security/Kasumi */
>>> + .pvr_mask = 0xf0000fff,
>>> + .pvr_value = 0x200008D8,
>>> + .cpu_name = "440GRX - with Security/Kasumi",
>>> + .cpu_features = CPU_FTRS_44X,
>>> + .cpu_user_features = COMMON_USER_BOOKE, /* 440GRX has no FPU */
>>> + .icache_bsize = 32,
>>> + .dcache_bsize = 32,
>>> + },
>>> + { /* 440GRX - without Security/Kasumi */
>>> + .pvr_mask = 0xf0000fff,
>>> + .pvr_value = 0x200008DC,
>>> + .cpu_name = "440GRX - no Security/Kasumi",
>>> + .cpu_features = CPU_FTRS_44X,
>>> + .cpu_user_features = COMMON_USER_BOOKE, /* 440GRX has no FPU */
>>> + .icache_bsize = 32,
>>> + .dcache_bsize = 32,
>>> + },
>> Should the 440GRX PVR additions be done in a separate patch? Or is the
>> PVR and cpu features truly the only difference between 440EPx and
>> 440GRx?
>
> I think it makes sense to add the 440GRx with this patchset too. The 440GRx is
> a subset of the 440EPx, missing some stuff like USB, FPU. And the AMCC
> Rainier 440GRx eval board is a subset of the Sequoia eval board. So no new
> board specific sources should be necessary to support the Rainier, just a
> different defconfig file.
>
> Best regards,
> Stefan
I have a Rainier 440GRx board and the PVR is equal to the 440EPx one
(0x200008D0). This has to be handled somehow, since the
PPC_FEATURE_HAS_FPU flag should *not* be set for 440GRx.
I'm really not sure how though. Any ideas are greatly appreciated :)
Is it a h/w bug?
Thanks,
Valentine.
^ permalink raw reply
* Re: reg : SM722 Linux driver
From: Clemens Koller @ 2007-08-03 11:41 UTC (permalink / raw)
To: mahendra varman; +Cc: linuxppc-embedded
In-Reply-To: <4ac2955e0708030421r3b6d6b0at179e86fb6ff461a6@mail.gmail.com>
mahendra varman schrieb:
> Hi Members
>
> Iam in need of SM722 Linux driver source code for Linux 2.6 or for Linux 2.4
>
> Help me to find the source code
You will find Xfree86 drivers from Siliconmotion here:
http://www.siliconmotion.com.tw/en/en2/download2c.htm
And the siliconmotion driver of Xorg in it's git repository:
http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-siliconmotion.git;a=summary
I don't think there are in-kernel framebuffer drivers (tried the vesa ones?)
for the SM722 (==Lynx3DM+), read the code. ;-)
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* 22.1-rt8 : BUG: scheduling while atomic: stress/0x00000002/739, CPU#0
From: Pradyumna Sampath @ 2007-08-03 11:50 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I am running linux-2.6.22.1-rt8 on mpc5200 and on running stress
#./stress --cpu 8 --io 4 --vm 2 --vm-bytes 2M --timeout 300s
I get the following stack.But this does not happen with non -rt kernel.
LR = 0xff51fcc
BUG: scheduling while atomic: stress/0x00000002/739, CPU#0
Call Trace:
[c04fbb80] [c0008650] show_stack+0x50/0x190 (unreliable)
[c04fbbb0] [c0016fc0] __schedule_bug+0x38/0x48
[c04fbbc0] [c01d4f7c] __schedule+0x3dc/0x450
[c04fbbf0] [c01d56c8] schedule+0x54/0xf0
[c04fbc00] [c01d6390] rt_spin_lock_slowlock+0x100/0x224
[c04fbc60] [c0052198] get_zone_pcp+0x30/0x58
[c04fbc80] [c0053078] free_hot_cold_page+0x114/0x1fc
[c04fbcb0] [c0056424] put_page+0x50/0x15c
[c04fbcd0] [c0069854] free_page_and_swap_cache+0x44/0x80
[c04fbce0] [c005d760] unmap_vmas+0x2e0/0x788
[c04fbd70] [c006292c] exit_mmap+0x74/0x108
[c04fbda0] [c001adc0] mmput+0x54/0xf0
[c04fbdc0] [c001ecfc] exit_mm+0xc0/0x124
[c04fbde0] [c001ffd0] do_exit+0x164/0x8bc
[c04fbe20] [c0020760] do_group_exit+0x38/0x90
[c04fbe40] [c002ba48] get_signal_to_deliver+0x2ac/0x3c0
[c04fbe70] [c000739c] do_signal+0x50/0x60c
[c04fbf40] [c000fec0] do_user_signal+0x74/0xc4
--- Exception: c00 at 0xfeab1dc
LR = 0xff51fcc
I have also tested the same case on x86 and that does not throw up
anything. Another observation is the fact is that this happens when
--vm is > 1. So I am guessing its a very PowerPC specific problem.
Maybe some part of the vm code for powerpc. This happens for all
powerpc -rt kernels I have used.
Link to stress is : http://weather.ou.edu/~apw/projects/stress/
A friend of mine has already posted this problem to the rt-preempt
mailing list. Any pointers suggestions as to where the problem could
be is most welcome.
Thanks in advance
regards
/prady
--
htp://prady.livejournal.com
^ 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