* Re: [PATCH 1/4] powerpc: mv64x60 - Use early_* PCI accessors for hotswap reg
From: Mark A. Greer @ 2008-01-15 17:20 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080115101936.d186329d.sfr@canb.auug.org.au>
On Tue, Jan 15, 2008 at 10:19:36AM +1100, Stephen Rothwell wrote:
> Hi Mark,
Hi Stephen. Thanks for taking the time to review these patches.
> On Mon, 14 Jan 2008 15:51:50 -0700 "Mark A. Greer" <mgreer@mvista.com> wrote:
> >
> > +static inline struct pci_controller *mv64x60_find_hose(u32 idx)
> > +{
> > + struct device_node *phb;
> > + struct pci_controller *hose;
> > + const u32 *prop;
> > + int len;
> > +
> > + for_each_compatible_node(phb, "pci", "marvell,mv64360-pci") {
> > + prop = of_get_property(phb, "cell-index", &len);
> > + if (prop && (len == sizeof(prop)) && (*prop == idx)) {
> > + hose = pci_find_hose_for_OF_device(phb);
> > + of_node_put(phb);
> > + return hose;
> > + }
> > + }
> > +
> > + return NULL;
> > +}
>
> I would think that this is way to big to inline ...
Yeah, I suppose. I'm not sure why I made it an inline, TBH. I'll make
it a "real" routine.
Mark
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Sean MacLennan @ 2008-01-15 18:22 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, Sean MacLennan
In-Reply-To: <200801150739.39095.sr@denx.de>
Stefan Roese wrote:
> Bummer! Was worth a try though. I still don't see why this should fail on your
> platform. What error/exception do you get upon 32bit access btw?
>
Ask and Ye Shall RX! Here is a complete trace of the crash including the
NAND debug outputs.
Cheers,
Sean
NDFC NAND Driver initialized. Chip-Rev: 0x00000109
NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bi)
Scanning device for bad blocks
Data machine check in kernel mode.
Oops: Machine check, sig: 7 [#1]
Warp
Modules linked in:
NIP: 00000000 LR: c01559b8 CTR: c0159f64
REGS: c02c2f50 TRAP: 0202 Not tainted (2.6.24-rc6-pika)
MSR: 00000000 <> CR: 42000024 XER: 2000005f
TASK = cf81bba0[1] 'swapper' THREAD: cf81e000
GPR00: 70000000 cf81fd30 cf81bba0 c02daac4 cf9a5280 0000000c 00000240 00000000
GPR08: 122deea8 d1064000 000f4240 c02e0000 121f0cf6 00000000 0ffabe00 c02b0d14
GPR16: 0040044c 0000001f cf9a5080 00000000 00000000 00000010 00000002 00000000
GPR24: 00000010 00000000 00000001 c02daac4 cf81fda8 00000000 c02daac4 c0159f64
NIP [00000000] _start+0x40000000/0x30
LR [c01559b8] nand_read_oob_std+0x54/0x6c
Call Trace:
[cf81fd30] [c01559a0] nand_read_oob_std+0x3c/0x6c (unreliable)
[cf81fd50] [c0155fb4] nand_read_oob+0x204/0x334
[cf81fda0] [c01589c8] create_bbt+0x210/0x2f0
[cf81fe00] [c0159abc] nand_scan_bbt+0x464/0x4c4
[cf81fe50] [c0157a1c] nand_scan_tail+0x4b0/0x4f4
[cf81fe70] [c015a214] ndfc_chip_probe+0x168/0x1d4
[cf81fe90] [c012e014] platform_drv_probe+0x20/0x30
[cf81fea0] [c012bee8] driver_probe_device+0xb8/0x1cc
[cf81fec0] [c012c1d4] __driver_attach+0xcc/0xf8
[cf81fee0] [c012af8c] bus_for_each_dev+0x54/0x90
[cf81ff10] [c012bc14] driver_attach+0x24/0x34
[cf81ff20] [c012b64c] bus_add_driver+0x98/0x1b8
[cf81ff40] [c012c65c] driver_register+0x58/0xa0
[cf81ff50] [c012e190] platform_driver_register+0x98/0xa8
[cf81ff60] [c028c014] ndfc_nand_init+0x38/0x50
[cf81ff70] [c027486c] kernel_init+0xa4/0x290
[cf81fff0] [c000c320] kernel_thread+0x48/0x64
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
---[ end trace 99adfcc136bb75fe ]---
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: mv64x60 - Use early_* PCI accessors for hotswap reg
From: Mark A. Greer @ 2008-01-15 17:31 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080115102129.a4666143.sfr@canb.auug.org.au>
On Tue, Jan 15, 2008 at 10:21:29AM +1100, Stephen Rothwell wrote:
> Hi Mark,
>
> On Mon, 14 Jan 2008 15:51:50 -0700 "Mark A. Greer" <mgreer@mvista.com> wrote:
> >
> > +++ b/arch/powerpc/sysdev/mv64x60.h
> > @@ -3,10 +3,32 @@
> >
> > #include <linux/init.h>
> >
> > +#include <asm/prom.h>
>
> You probably meant to include linux/of.h here
Umm, apparently... :)
Mark
^ permalink raw reply
* Re: [PATCH] net: EMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Eugene Surovegin @ 2008-01-15 17:32 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <1200400809-19720-1-git-send-email-sr@denx.de>
On Tue, Jan 15, 2008 at 01:40:09PM +0100, Stefan Roese wrote:
> Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
> xmit. This routine doesn't check if the frame length exceeds the max.
> MAL buffer size.
>
> This patch now changes the driver to call emac_start_xmit_sg() on all
> platforms and not only the TAH equipped ones (440GX). This enables an
> MTU of 9000 instead 4080.
>
> Tested on Kilauea (405EX) with gbit link -> jumbo frames enabled.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
> Eugene & Ben, do you see any problems with this patch? If not, then I'll
> send another version for the newemac driver too.
Hmm, so why not make GigE support a condition to hook SG version of
xmit then? I don't like when you change behaviour for chips where it
perefectly legal not to do this check because you cannot change MTU
anyways.
--
Eugene
^ permalink raw reply
* Re: [PATCH 4/4] powerpc: Katana750i - Add platform support
From: Mark A. Greer @ 2008-01-15 17:36 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080115103346.30cc3d54.sfr@canb.auug.org.au>
On Tue, Jan 15, 2008 at 10:33:46AM +1100, Stephen Rothwell wrote:
> Hi Mark,
>
> On Mon, 14 Jan 2008 16:00:57 -0700 "Mark A. Greer" <mgreer@mvista.com> wrote:
> >
> > +++ b/arch/powerpc/platforms/embedded6xx/katana750i.c
> > @@ -0,0 +1,314 @@
> > +/*
> > + * Board setup routines for the Emerson Katana-750i/752i
> > + *
> > + * Author: Mark A. Greer <mgreer@mvista.com>
> > + *
> > + * Based on code prpmc2800.c by Dale Farnsworth <dale@farnsworth.org>
> > + * and original katana port by Tim Montgomery <timm@artesyncp.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify it
> > + * under the terms of the GNU General Public License as published by the
> > + * Free Software Foundation; either version 2 of the License, or (at your
> > + * option) any later version.
>
> A Copyright notice would be nice.
Okay.
> > +static void __init katana750i_setup_arch(void)
> > +{
> > + struct device_node *np;
> > + phys_addr_t paddr;
> > + const unsigned int *reg;
> > +
> > + /*
> > + * ioremap mpp and gpp registers in case they are later
> > + * needed by katana750i_reset_board().
> > + */
> > + np = of_find_compatible_node(NULL, NULL, "marvell,mv64360-mpp");
> > + reg = of_get_property(np, "reg", NULL);
>
> What happens if np == NULL?
It'll explode. :D I'll fix.
> > + paddr = of_translate_address(np, reg);
> > + of_node_put(np);
> > + mv64x60_mpp_reg_base = ioremap(paddr, reg[1]);
> > +
> > + np = of_find_compatible_node(NULL, NULL, "marvell,mv64360-gpp");
> > + reg = of_get_property(np, "reg", NULL);
>
> Ditto.
>
> > + paddr = of_translate_address(np, reg);
> > + of_node_put(np);
> > + mv64x60_gpp_reg_base = ioremap(paddr, reg[1]);
> > +
> > +#ifdef CONFIG_PCI
> > + mv64x60_pci_init();
> > +#endif
>
> Maybe there should be a stub of mv64x60_pci_init for the non PCI case -
> that would save the ifdefs in C code.
Good idea.
> > + np = of_find_compatible_node(NULL, NULL, "katana750i,cpld");
> > + reg = of_get_property(np, "reg", NULL);
>
> What if np == NULL?
Thanks again, Stephen.
Mark
^ permalink raw reply
* Re: PPC vs POWERPC
From: Matias Sundman @ 2008-01-15 17:47 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <1200416484.14540.5.camel@ld0161-tx32>
Jon Loeliger skrev:
> On Tue, 2008-01-15 at 04:38, Matias Sundman wrote:
>
>> >>Documentation/powerpc/booting-without-of.txt to find out what is
>> >>expected in the device tree.
>>
>> Is there any more information on how the "of_*" ( e.g. of_node_put ,
>> of_find_node_by_type ) functions should be implemented in the
>> "arch/powerpc/platforms/myplatform/myboard_setup.c" file
>> or is the documentation the existing "*.c" c files under
>> arch/powerpc/platforms ?
>>
>> Since I have a 82xx board I assume that "myboard_setup.c" file shall be
>> put under arch/powerpc/platforms/82xx.
>>
>
> Maybe. Which 82xx is it? There is a notable difference
> between, say, the 824x boards and the 827x boards. If it
> is the latter, perhaps the existing 82xx/ pq2 or mpc8272
> parts are already sufficient?
>
> If it is the former group, 824x, perhaps some of the parts
> in embedded6xx/ are usable? Also note that I am working on
> publishing an 824x StorCenter port under embedded6xx/ at
> this time as well. First patches were posted to linuxppc-dev
> list at ozlabs.org.
>
> HTH,
> jdl
>
>
>
The board is based on PPC8265.
Cheers // Matias
^ permalink raw reply
* RE: MPC5200B SPI codec error when there is a heavy ethernet
From: Albrecht Moll @ 2008-01-15 17:37 UTC (permalink / raw)
To: linuxppc-embedded
> Txema wrote on 15 Jan 2008
> We have a MPC5200B based custom board running a 2.4.25 Denx linux
> kernel. We use the PSC6 in SPI-codec mode to exchange some bytes
> periodically in full-duplex with a peripheral.
>
> In 'normal' conditions this communication runs fine. But when we start
> sending packets over the Ethernet as a background activity, we see on
> the oscilloscope that one of the SPI transfers is interrupted.
Also just a shot in the dark:
I remember someone having similar problems with UART in AC97 mode.
(http://marc.info/?l=linuxppc-embedded&m=117932912618680&w=2)
I associated this with other FEC problems which boiled down to an issue
with
MPC52xx_XLB_CFG_BSDIS.
^ permalink raw reply
* Re: Please pull pasemi.git for-2.6.25 branch
From: Olof Johansson @ 2008-01-15 18:27 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20080115170152.GA25749@lixom.net>
On Tue, Jan 15, 2008 at 11:01:52AM -0600, Olof Johansson wrote:
> Paul,
>
> Please pull from 'for-2.6.25' branch of
>
> master.kernel.org:/pub/scm/linux/kernel/git/olof/k.org.git for-2.6.25
Sorry, new script and I botched it. The link is:
master.kernel.org:/pub/scm/linux/kernel/git/olof/pasemi.git for-2.6.25
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] 4xx: Add 405EXr to cputable
From: Scott Wood @ 2008-01-15 18:19 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1200380955-10217-1-git-send-email-sr@denx.de>
On Tue, Jan 15, 2008 at 08:09:15AM +0100, Stefan Roese wrote:
> This patch adds the 405EXr to the powerpc cuptable. Basically the 405EXr
> is a 405EX with only one EMAC and only one PCIe interface.
Sounds like they have the same core... why do they need separate cputable
entries?
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] 4xx: Add 405EXr to cputable
From: Olof Johansson @ 2008-01-15 18:32 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20080115181924.GA3848@loki.buserror.net>
On Tue, Jan 15, 2008 at 12:19:24PM -0600, Scott Wood wrote:
> On Tue, Jan 15, 2008 at 08:09:15AM +0100, Stefan Roese wrote:
> > This patch adds the 405EXr to the powerpc cuptable. Basically the 405EXr
> > is a 405EX with only one EMAC and only one PCIe interface.
>
> Sounds like they have the same core... why do they need separate cputable
> entries?
AMCC has always indicated SoC products by new PVRs. This isn't news,
even though it isn't exactly a clean solution. :)
-Olof
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] 4xx: Add 405EXr to cputable
From: Scott Wood @ 2008-01-15 18:25 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20080115183240.GC25749@lixom.net>
Olof Johansson wrote:
> On Tue, Jan 15, 2008 at 12:19:24PM -0600, Scott Wood wrote:
>> On Tue, Jan 15, 2008 at 08:09:15AM +0100, Stefan Roese wrote:
>>> This patch adds the 405EXr to the powerpc cuptable. Basically the 405EXr
>>> is a 405EX with only one EMAC and only one PCIe interface.
>> Sounds like they have the same core... why do they need separate cputable
>> entries?
>
> AMCC has always indicated SoC products by new PVRs. This isn't news,
> even though it isn't exactly a clean solution. :)
But the old 405EX entry would have matched both chips. Why add a new
significant bit to pvr_mask? For the name in /proc/cpuinfo?
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] 4xx: Add 405EXr to cputable
From: Olof Johansson @ 2008-01-15 18:38 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <478CFA96.90009@freescale.com>
On Tue, Jan 15, 2008 at 12:25:26PM -0600, Scott Wood wrote:
> Olof Johansson wrote:
> > On Tue, Jan 15, 2008 at 12:19:24PM -0600, Scott Wood wrote:
> >> On Tue, Jan 15, 2008 at 08:09:15AM +0100, Stefan Roese wrote:
> >>> This patch adds the 405EXr to the powerpc cuptable. Basically the 405EXr
> >>> is a 405EX with only one EMAC and only one PCIe interface.
> >> Sounds like they have the same core... why do they need separate cputable
> >> entries?
> >
> > AMCC has always indicated SoC products by new PVRs. This isn't news,
> > even though it isn't exactly a clean solution. :)
>
> But the old 405EX entry would have matched both chips. Why add a new
> significant bit to pvr_mask? For the name in /proc/cpuinfo?
Presumably, yes.
Again, this is nothing new. Other 405/440 products are doing the same
thing.
-Olof
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] 4xx: Add 405EXr to cputable
From: Josh Boyer @ 2008-01-15 18:47 UTC (permalink / raw)
To: Olof Johansson; +Cc: Scott Wood, linuxppc-dev, Stefan, Roese
In-Reply-To: <20080115183809.GD25749@lixom.net>
On Tue, 15 Jan 2008 12:38:09 -0600
Olof Johansson <olof@lixom.net> wrote:
> On Tue, Jan 15, 2008 at 12:25:26PM -0600, Scott Wood wrote:
> > Olof Johansson wrote:
> > > On Tue, Jan 15, 2008 at 12:19:24PM -0600, Scott Wood wrote:
> > >> On Tue, Jan 15, 2008 at 08:09:15AM +0100, Stefan Roese wrote:
> > >>> This patch adds the 405EXr to the powerpc cuptable. Basically the 405EXr
> > >>> is a 405EX with only one EMAC and only one PCIe interface.
> > >> Sounds like they have the same core... why do they need separate cputable
> > >> entries?
> > >
> > > AMCC has always indicated SoC products by new PVRs. This isn't news,
> > > even though it isn't exactly a clean solution. :)
> >
> > But the old 405EX entry would have matched both chips. Why add a new
> > significant bit to pvr_mask? For the name in /proc/cpuinfo?
>
> Presumably, yes.
>
> Again, this is nothing new. Other 405/440 products are doing the same
> thing.
Does anyone have an actual problem with this patch? I'm inclined to
take it as it doesn't really cause any problems and may eventually be
needed anyway if there is a chip errata or something.
josh
^ permalink raw reply
* Re: [PATCH 3/4] powerpc: Katana750i - Add DTS file
From: Mark A. Greer @ 2008-01-15 19:08 UTC (permalink / raw)
To: Mark A. Greer, linuxppc-dev
In-Reply-To: <20080114233406.GB20649@localhost.localdomain>
On Tue, Jan 15, 2008 at 10:34:06AM +1100, David Gibson wrote:
> On Mon, Jan 14, 2008 at 03:59:26PM -0700, Mark A. Greer wrote:
> > From: Mark A. Greer <mgreer@mvista.com>
Hi David. Thanks for the review.
> > Add DTS file for the Emerson Katana 750i & 752i platforms.
>
> [snip]
> > +/dts-v1/;
> > +
> > +/ {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + model = "Katana-75xi"; /* Default */
> > + compatible = "emerson,katana-750i";
> > + coherency-off;
>
> Where is this flag used from?
Its used in the bootwrapper if & when you use the mv64x60 code to setup
some of the windows to the I/O ctlrs. This port does use that code
(because firmware doesn't do it properly) so I need the flag.
<snip>
> > + mv64x60@f8100000 { /* Marvell Discovery */
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + model = "mv64360"; /* Default */
> > + compatible = "marvell,mv64360";
> > + clock-frequency = <133333333>;
> > + hs_reg_valid;
> > + reg = <0xf8100000 0x00010000>;
> > + virtual-reg = <0xf8100000>;
>
> You seem to have virtual-reg properties on a *lot* of nodes, are they
> really necessary?
Actually, not all of them for this board. I copied them from prpmc2800
which does need all the ones that are there. I'l remove the ones that
aren't used.
> virtual-reg should be used *only* for things which
> you need to access very early in the bootwrapper. Usually that's only
> the serial port for the console. Come to that, the CPU is a 750 which
> has a real mode, so it seems dubious that you would need any
> virtual-reg values at all.
Well, this came from a discussion about a year ago when we agreed that
this is how it should be done. Just because MSR[IR,DR] can be cleared
doesn't mean that they are cleared when the firmware jumps to the
bootwraper (for all possible firmwares that are out there).
To be able to eliminate virtual-reg, we'd have to add "mmu_off" code to
the bootwrapper which isn't hard but its already in the kernel (for
32-bit anyway). So why duplicate?
I'm not that attached to virtual-reg. In fact, I'd be happy to get rid
of it but only if we can be sure it doesn't cause more mess down the
road.
> [snip]
> > + flash@e8000000 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "cfi-flash";
> > + bank-width = <4>;
> > + device-width = <2>;
> > + reg = <0xe8000000 0x04000000>;
> > + monitor@0 {
> > + label = "Monitor";
>
> If you're using the "label" property, it would be normal to name the
> nodes simply "partition@address".
I'm using the partition names that were used in the equivalent code
under arch/ppc. I'm trying to keep things looking the same as they used
to as much as possible. Besides, I don't see any others doing it that
way.
<snip>
> > + mdio {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "mdio";
>
> This device_type value should not be here.
Yep. Will fix.
<snip>
> > + multiethernet@2000 {
>
> This needs some sort of "compatible" value.
Okay.
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x2000 0x2000>;
> > + ethernet@0 {
>
> [snip]
> > + CUNIT: cunit@f200 {
>
> What is this device? It needs some sort of "compatible" value.
Does it? Its a separate block of regs but its only used in the mpsc
node--its never looked up on its own by kernel code. Do all nodes need
"compatible" even when it'll never be used? (Just want to know.)
> > + reg = <0xf200 0x200>;
> > + };
> > +
> > + MPSCROUTING: mpscrouting@b400 {
>
> Ditto.
Ditto.
> > + reg = <0xb400 0xc>;
> > + };
> > +
> > + MPSCINTR: mpscintr@b800 {
>
> Ditto.
Ditto.
> > + reg = <0xb800 0x100>;
> > + virtual-reg = <0xf810b800>;
> > + };
>
> [snip]
> > + i2c@c000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "i2c";
>
> This device_type value shouldn't be here either.
Oops, good catch.
<snip>
> > + mpp@f000 {
> > + compatible = "marvell,mv64360-mpp";
> > + reg = <0xf000 0x10>;
> > + };
> > +
> > + gpp@f100 {
> > + compatible = "marvell,mv64360-gpp";
> > + reg = <0xf100 0x20>;
> > + };
>
> What are these two devices?
mpp == multi-purpose pins
gpp == general purpose pins
They're really 2 separate reg blocks and are used for any number of
things including incoming PCI interrupts. I'm not accessing them
currently so I can eliminate them in this dts.
> > + pci@80000000 {
> > + #address-cells = <3>;
> > + #size-cells = <2>;
> > + #interrupt-cells = <1>;
> > + device_type = "pci";
> > + compatible = "marvell,mv64360-pci";
> > + cell-index = <1>;
> > + reg = <0x0c78 0x8>;
> > + ranges = <0x01000000 0x0 0x0
> > + 0xb0000000 0x0 0x04000000
> > + 0x02000000 0x0 0x80000000
> > + 0x80000000 0x0 0x30000000>;
> > + bus-range = <0x0 0xff>;
<snip>
> > + };
> > +
> > + pci@f8080000 { /* Required to acces Hotswap register */
> > + #address-cells = <3>;
> > + #size-cells = <2>;
> > + #interrupt-cells = <1>;
> > + device_type = "pci";
> > + compatible = "marvell,mv64360-pci";
> > + cell-index = <0>;
> > + reg = <0x0cf8 0x8>;
> > + ranges = <0x01000000 0x0 0x0
> > + 0xf8080000 0x0 0x00010000
> > + 0x02000000 0x0 0xf8090000
> > + 0xf8090000 0x0 0x00010000>;
> > + bus-range = <0x0 0xff>;
>
> Two PCI bridges with identical bus-range values seems potentially
> problematic...
Will fix.
> > + };
>
> [snip]
> > + chosen {
> > + bootargs = "ip=on";
>
> The dts file should not include a "bootargs" value. The wrapper will
> fill that in from the kernel config.
Actually, the kernel .config CONFIG_CMDLINE is only used by the kernel
when nothing is passed in from the bootwrapper. The bootwrapper gets
the cmdline from either bootargs or from the __builtin_cmdline section.
I prefer to not rely on CONFIG_CMDLINE because it doesn't afford the
user a chance to edit or add to the cmdline when booting. You can always
type in the whole thing at the "Linux/PowerPC load: " prompt but I'd rather
see what is going to be used and then edit it if I want to. With
CONFIG_CMDLINE, it just gets used if nothing was passed in from the
bootwrapper.
That raises an issue that I've for time time (I've tried to get rid of
__builtin_cmdline before but was unsuccessful).
We currently have 3 possible sources for a default cmdline--seems like
at least one too many.
IMHO we need a way to change the default cmdline in the field so
sysadmins can change it per board and not have to type it in every time
they boot. /chosen/bootargs and __builtin_cmdline can both do that.
We don't need both, though. And, since bootargs is specified by OF
and documented in booting-without-of.txt, can we finally get rid of
__builtin_cmdline? I'd sure like to.
We can probably get rid of CONFIG_CMDLINE too since everyone uses DTs
now and they can have a /chosen/bootargs. Anyone have a reason to keep
CONFIG_CMDLINE around?
Would you mind elaborating on why you are opposed to /chosen/bootargs?
Mark
^ permalink raw reply
* Re: [PATCH] fsl_soc: Fix get_immrbase() to use ranges, rather than reg.
From: Scott Wood @ 2008-01-15 18:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <17A215CC-EFAE-41B9-8DB7-C6CDB4E708F2@kernel.crashing.org>
Kumar Gala wrote:
>> Why go out of our way to fail on a childless soc node?
>
> do we see any case in which we'd have a childless soc node?
It's possible that it could be used to communicate immrbase and soc
type, but nothing else. Not overly likely, but possible.
> I'm just concerned about make sure this works for all the various cases
> of #address-cells and #size-cells.
It should. We check the soc's #address-cells to skip the child bus
address, and of_translate_address should take care of looking up the
parent #address-cells. The size portion of the ranges is ignored.
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] pasemi: Move electra-ide to pata_of_platform
From: Jeff Garzik @ 2008-01-15 19:42 UTC (permalink / raw)
To: Olof Johansson; +Cc: Paul Mundt, linuxppc-dev, linux-ide
In-Reply-To: <20080115164033.GA25328@lixom.net>
Olof Johansson wrote:
> Move electra-ide glue over to the new pata_of_platform framework, and
> add the quirks needed to that driver.
>
> ---
>
> Applied with the rest of the patches to pasemi.git for-2.6.25
>
> arch/powerpc/platforms/pasemi/electra_ide.c | 96 ----------------------------
> b/arch/powerpc/configs/pasemi_defconfig | 4 -
> b/arch/powerpc/platforms/pasemi/Kconfig | 9 --
> b/arch/powerpc/platforms/pasemi/Makefile | 1
> b/drivers/ata/pata_of_platform.c | 20 ++++-
> 5 files changed, 17 insertions(+), 113 deletions(-)
ACK
^ permalink raw reply
* Re: [PATCH] net: EMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Stefan Roese @ 2008-01-15 19:46 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev, netdev
In-Reply-To: <20080115173202.GA1268@gate.ebshome.net>
On Tuesday 15 January 2008, Eugene Surovegin wrote:
> On Tue, Jan 15, 2008 at 01:40:09PM +0100, Stefan Roese wrote:
> > Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
> > xmit. This routine doesn't check if the frame length exceeds the max.
> > MAL buffer size.
> >
> > This patch now changes the driver to call emac_start_xmit_sg() on all
> > platforms and not only the TAH equipped ones (440GX). This enables an
> > MTU of 9000 instead 4080.
> >
> > Tested on Kilauea (405EX) with gbit link -> jumbo frames enabled.
> >
> > Signed-off-by: Stefan Roese <sr@denx.de>
> > ---
> > Eugene & Ben, do you see any problems with this patch? If not, then I'll
> > send another version for the newemac driver too.
>
> Hmm, so why not make GigE support a condition to hook SG version of
> xmit then? I don't like when you change behaviour for chips where it
> perefectly legal not to do this check because you cannot change MTU
> anyways.
OK. But how do we detect GigE support? Seems like GigE enabled devices have
CONFIG_IBM_EMAC4 defined. If nobody objects I'll fix up another version
tomorrow.
Thanks.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] net: EMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Eugene Surovegin @ 2008-01-15 20:00 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <200801152046.01881.sr@denx.de>
On Tue, Jan 15, 2008 at 08:46:01PM +0100, Stefan Roese wrote:
> On Tuesday 15 January 2008, Eugene Surovegin wrote:
> > On Tue, Jan 15, 2008 at 01:40:09PM +0100, Stefan Roese wrote:
> > > Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
> > > xmit. This routine doesn't check if the frame length exceeds the max.
> > > MAL buffer size.
> > >
> > > This patch now changes the driver to call emac_start_xmit_sg() on all
> > > platforms and not only the TAH equipped ones (440GX). This enables an
> > > MTU of 9000 instead 4080.
> > >
> > > Tested on Kilauea (405EX) with gbit link -> jumbo frames enabled.
> > >
> > > Signed-off-by: Stefan Roese <sr@denx.de>
> > > ---
> > > Eugene & Ben, do you see any problems with this patch? If not, then I'll
> > > send another version for the newemac driver too.
> >
> > Hmm, so why not make GigE support a condition to hook SG version of
> > xmit then? I don't like when you change behaviour for chips where it
> > perefectly legal not to do this check because you cannot change MTU
> > anyways.
>
> OK. But how do we detect GigE support? Seems like GigE enabled devices have
> CONFIG_IBM_EMAC4 defined. If nobody objects I'll fix up another version
> tomorrow.
Look couple of lines down where I set MTU changing hook. If you cannot
change MTU you cannot get big frames.
--
Eugene
^ permalink raw reply
* Driver - HDLC 83xx QUICC Engine??
From: Russell McGuire @ 2008-01-15 19:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.1.1200358805.3196.linuxppc-embedded@ozlabs.org>
All,
Does anyone know of a project or existing driver for supporting HDLC for the
MPC83xx or MPC82XX Freescale CPUs?
Looking to run raw HDLC over various Ethernet or T1 links.
-Russ
^ permalink raw reply
* Re: Problems with serial and DHCP when booting from NFS
From: Josh Boyer @ 2008-01-15 20:04 UTC (permalink / raw)
To: lipeng; +Cc: Linuxppc-embedded
In-Reply-To: <1233217.1191761200384592967.JavaMail.nabble@isper.nabble.com>
On Tue, 15 Jan 2008 00:09:52 -0800
lipeng@ict.ac.cn wrote:
> Hi all,
>
> I am porting a MontaVista Linux for PPC405 and encountering some problems. I hope someone can help me find it out.
You didn't say what kernel you're using, or what you're porting to
(arch/ppc or arch/powerpc).
> 1. About the serial port. I have solved this problem, but I don't know why. If I set "Initial Kernel Command String" as "console=ttyS0,19200 ip=on nfsroot=[my_nfsroot] rw", after outputing "Now booting the kernel" in the booting process, the booting kernel seems hanging there. In fact, when I checked the log of DHCP server, I found the PPC had already sent DHCP requests. It can be infered that the kernel had been booted but serial had something wrong, so no other information was output after "Now booting the kernel". If I set "Initial Kernel Command String" as "ip=on nfsroot=[my_nfsroot] rw", the booting information will appear on the terminal window correctly after "Now booting the kernel". I don't know why. I use Uart Lite and the baud rate is 19200.
uartlite doesn't show up as ttyS0 IIRC, so your initial console setting
was wrong.
> 2. About the DHCP. The kernel is boot from NFS, so I enabled the DHCP. From the information on terminal window, I knew that DHCP requests were always time out and the client kept retrying. But when I checked the log of DHCP server, I found the server had already offered IP to the client kernel. It seems the client kernel has some problem to receive the DHCP offer, has anyone encountered similar problems? How to solve this problem?
I've seen that on a board I have. Haven't debugged it yet
because I had to unhook everything to paint the room it was in. I
think it's something to do with an initialization race in the EMAC
driver or some other place.
josh
^ permalink raw reply
* Linux with e500 v2 core, can we support Ram base address starting at 0x1_0000_0000
From: Subbu Linux @ 2008-01-15 20:16 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 474 bytes --]
Hi
I am currently working on MPC8548 core, would like to know wheather current
Linux with e500v2 core supporting Physical Address of RAM at 0x1_0000_0000,
I know in current linux with large Page table support we can access devices
at 0x1_0000_0000 for e500v2, but I wanted to move RAM base address to
0x1_0000_0000, so that I can support larger RAM. Can any body suggest me if
their is any patch available for this or is it possible to implement from
scratch.
Thanks
Subbu
[-- Attachment #2: Type: text/html, Size: 551 bytes --]
^ permalink raw reply
* kernel 2.4 for virtex 2
From: Joachim Meyer @ 2008-01-15 20:59 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
Hi
I need to have a network connection, so I have 2 options, I think.
1. use an XUP Board with kernel 2.6
2. use the ml310 with the kernel 2.4 to use the PCI Bridge -> Network
For special reasons I'd prefer the 2. one.
So can you (anybody) tell me, how I get the 2.4.21 Kernel sources (for the ppc)?
Bitkeeper doesn't support rollbacks with the free client.
Greez & Thanks for help
Joachim
______________________________________________________________________
XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club!
Jetzt testen! http://produkte.web.de/club/?mc=021130
^ permalink raw reply
* [PATCH] change where the kernel loads
From: Mike Wolf @ 2008-01-15 21:06 UTC (permalink / raw)
To: linuxppc-dev
When netbooting a kernel with an initrd or initramfs that makes
the image larger than 8 meg the firmware will kick out the kernel
and go to the second boot device. However when the mkzimage
script is used to create the image instead of 'make zImage' then
the kernel/initrd will netboot. So this patch changes boot/zImage.lds
to load the kernel at the same location that the mkzimage would set.
This has been boot tested on POWER5, POWER5+, blades and POWER6
systems successfully.
signed off by: Mike Wolf (mjw@us.ibm.com)
------
--- linux-2.6.16.46-0.12.orig/arch/powerpc/boot/zImage.lds 2008-01-07 14:51:05.000000000 -0600
+++ linux-2.6.16.46-0.12/arch/powerpc/boot/zImage.lds 2008-01-07 14:31:14.000000000 -0600
@@ -2,7 +2,7 @@
ENTRY(_zimage_start)
SECTIONS
{
- . = (4*1024*1024);
+ . = (64*1024);
_start = .;
.text :
{
^ permalink raw reply
* Re: [PATCH] change where the kernel loads
From: Scott Wood @ 2008-01-15 21:09 UTC (permalink / raw)
To: mjw; +Cc: linuxppc-dev
In-Reply-To: <478D2038.4090205@linux.vnet.ibm.com>
Mike Wolf wrote:
> When netbooting a kernel with an initrd or initramfs that makes
> the image larger than 8 meg the firmware will kick out the kernel
> and go to the second boot device. However when the mkzimage
> script is used to create the image instead of 'make zImage' then
> the kernel/initrd will netboot. So this patch changes boot/zImage.lds
> to load the kernel at the same location that the mkzimage would set.
>
> This has been boot tested on POWER5, POWER5+, blades and POWER6
> systems successfully.
This will fail on any platform without a vmlinux_alloc(), as there will
be insufficient room for the kernel at address zero.
-Scott
^ permalink raw reply
* Re: [PATCH 1/3] 8xx: Analogue & Micro Adder875 board support.
From: Bryan O'Donoghue @ 2008-01-15 23:25 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <478BE6F2.4020207@freescale.com>
Greetings Scott.
I've tried both of the procedures you've outlined on the Adder875 with
the patches supplied against the paulus git tree to no avail.
Pass #1 :
Doing it safe with cuImage.8xx
Build system : Debian lenny, ELDK 4.1 uClibc
Kernel : Linux-2.6.24-rc6-g4f43143f-dirty - about two days old
Bootloader : U-Boot 1.3.1-g5c740711-dirty (Jan 15 2008 - 21:50)
#define CONFIG_OF_LIBFDT 1
#undef CONFIG_OF_FLAT_TREE
- So that U-Boot will understand the three parameter bootm.
dtc : DTC 1.1.0-rc1
I do
1. source /opt/eldk/eldk_init ppc_8xx
2. export ARCH=powerpc
3. cd linux-2.6-paulus
4. git branch adder875-patchset master
5. git checkout adder875-patchset
6. cat ../adder875_patches/adder875.patch | patch -p1
The patch applies almost perfectly - except for a minor conflict in
arch/powerpc/boot/Makefile - where I add redboot-8xx.c right after
cuboot-rainer.c manually.
7. make distclean && mrproper && clean
8. make adder875-uboot_defconfig
9. make zImage
That runs just fine - and just to prove to you I haven't done anything
funny here the last few lines of output are
HOSTLD arch/powerpc/boot/dtc
WRAP arch/powerpc/boot/cuImage.8xx
DTC: dts->dtb on file
"/home/deckard/Development/linux/linux-2.6-paulus/arch/powerpc/boot/dts/adder875-uboot.dts"
Image Name: Linux-2.6.24-rc6-g4f43143f-dirty
Created: Tue Jan 15 23:02:52 2008
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1032266 Bytes = 1008.07 kB = 0.98 MB
Load Address: 0x00400000
Entry Point: 0x00400554
WRAP arch/powerpc/boot/zImage.redboot-8xx
DTC: dts->dtb on file
"/home/deckard/Development/linux/linux-2.6-paulus/arch/powerpc/boot/dts/adder875-uboot.dts"
cp arch/powerpc/boot/ucImage.8xx /tftpboot
The U-Boot output is :
=> tftpboot 0x400000 cuImage.8xx
Using FEC ETHERNET device
TFTP from server 192.168.0.101; our IP address is 192.168.0.202
Filename 'cuImage.8xx'.
Load address: 0x400000
Loading:
#################################################################
#################################################################
#################################################################
#######
done
Bytes transferred = 1032330 (fc08a hex)
=> bootm 0x400000
## Booting image at 00400000 ...
Image Name: Linux-2.6.24-rc6-g4f43143f-dirty
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1032266 Bytes = 1008.1 kB
Load Address: 00400000
Entry Point: 00400554
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
I haven't as yet tried to single step through the bootup process - but,
just to say that assuming the above procedure isn't _too_ far wrong -
the stuff posted to the list agains the tree you've recommended doesn't
seem to work..
If you can point out a flaw in my usage of it - that'd help alot. I have
some code I'd love to be able to use with the Adder875+powerpc layer -
which is why I'm interested in this patchset...
Pass #2 :
Replace step 9 with.
9. make uImage
10 dtc -o ../adder875-uboot.dtb -O dtb
arch/powerpc/boot/dts/adder875-uboot.dts
cp arch/powerpc/boot/uImage /tftpboot
cp ../adder875-uboot.dtb /tftpboot
Finally in u-boot
=> tftpboot 0x400000 uImage
Using FEC ETHERNET device
TFTP from server 192.168.0.101; our IP address is 192.168.0.202
Filename 'uImage'.
Load address: 0x400000
Loading:
#################################################################
#################################################################
#################################################################
###
done
Bytes transferred = 1009496 (f6758 hex)
=> tftpboot 0x500000 adder875-uboot.dtb
Using FEC ETHERNET device
TFTP from server 192.168.0.101; our IP address is 192.168.0.202
Filename 'adder875-uboot.dtb'.
Load address: 0x500000
Loading: #
done
Bytes transferred = 3147 (c4b hex)
=> bootm 0x400000 - 0x500000
## Booting image at 00400000 ...
Image Name: Linux-2.6.24-rc6-g4f43143f-dirty
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1009432 Bytes = 985.8 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using the fdt at 0x500000
Aside from the u-boot modification of including
#define CONFIG_OF_LIBFDT 1
The rest is a pristine version of Yuli Barchoen's original U-Boot Adder
stuff.
The uImage + dtb seems to get a good bit further in that it seems to get
stuck somewhere inside of some trampoline code in time.c
(gdb) bt
#0 0xc000ee30 in __div64_32 ()
#1 0xc01d71f4 in time_init () at arch/powerpc/kernel/time.c:940
I might have a go at some proper debugging tomorrow after work.
If you have any suggestions as to what's going wrong or what I've not
done right I'd appreciate the help.
Best Regards,
BOD
^ 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