* Re: [PATCH 2/2] bootwrapper: Bail from script if any command fails
From: David Gibson @ 2007-10-17 0:33 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071016213107.14117.3858.stgit@trillian.cg.shawcable.net>
On Tue, Oct 16, 2007 at 03:31:07PM -0600, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Add the 'set -e' command to the wrapper script so that if any command
> fails then the script will automatically exit
Ah.. this will conflict with my patch to merge dtc (because that
touches the line invoking dtc to change the path to it).
--
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: ioctl32: Unknown cmd
From: Andi Kleen @ 2007-10-17 0:25 UTC (permalink / raw)
To: David Miller
Cc: Geert.Uytterhoeven, linuxppc-dev, linux-kernel, arnd, jens.axboe
In-Reply-To: <20071016.152404.35664335.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Tue, 16 Oct 2007 21:50:35 +0200
>
> > The one point where it is expected to have changed now is when you
> > try to do these ioctls on something that is not a block device. Are
> > you sure that the files you tried them on were created correctly?
>
> Many many many programs do this exact sort of thing.
>
> It is one of the bad aspects of moving the compat handling
> down into the file ops for a specific device.
When this happens one should add respective IGNORE_IOCTL()s to
compat_ioctl.c
-Andi
^ permalink raw reply
* RE: [PATCH v2] Device tree bindings for Xilinx devices
From: Stephen Neuendorffer @ 2007-10-17 0:21 UTC (permalink / raw)
To: Grant Likely
Cc: linuxppc-dev, microblaze-uclinux, Wolfgang Reissnegger, Leonid
In-Reply-To: <fa686aa40710161236h4cc82edbqfee328bbcb21c752@mail.gmail.com>
=20
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On=20
> Behalf Of Grant Likely
> Sent: Tuesday, October 16, 2007 12:36 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org; Wolfgang Reissnegger; Leonid;=20
> microblaze-uclinux@itee.uq.edu.au
> Subject: Re: [PATCH v2] Device tree bindings for Xilinx devices
>=20
> On 10/16/07, Stephen Neuendorffer=20
> <stephen.neuendorffer@xilinx.com> wrote:
> >
> > > + n) Xilinx EMAC and Xilinx TEMAC
> > > +
> > > + Xilinx Ethernet devices. Uses common properties from
> > > other Ethernet
> > > + devices with the following constraints:
> > > +
> > > + Required properties:
> > > + - compatible : Must include one of: "xilinx,plb-temac",
> > > + "xilinx,plb-emac", "xilinx-opb-emac"
> > > + - dma-mode : Must be one of "none", "simple", "sg" (sg
> > > =3D=3D scatter gather)
> >
> > I think it's going to be a significant headache to remap=20
> things like the
> > dma-mode from the xilinx configurations to something else, and then
> > interpret them correctly in the drivers.
> >
> > Although it lacks a bit in style, perhaps, I'd greatly prefer having
> > something like:
> >
> > Ethernet_MAC {
> > xilinx,C_DMA_PRESENT =3D <1>;
> > ...
> > }
> >
> > (which happens to correspond to "none" above)
>=20
> Ugh. Can't say I'm thrilled about this....
>=20
> But in this case is might be a necessity. The IP core is already
> parameterized and the best way to describe the device is to use the
> existing parameter names.
I don't really like it either, expecially after thinking about it more.
The problem is that a single IP core might correspond to multiple
logical devices. The parameters actually need to be from the point of
view of the drivers. That is, they need to be names like in the
xparameters:
xilinx,DMA_PRESENT =3D <1>;
In this case, the translation looks simple, but it is currently
implemented by a bunch of gnarly .tcl code. (Don't ask... :) In the
future, this *could* be simple code, but in the short term, it won't be
any simpler than having pretty names. Furthermore, the best driver code
that I can come up with for using this essentially looks like:
static int __devinit xenet_of_probe(struct of_device *ofdev, const
struct of_device_id *match)
{
struct xemac_platform_data pdata_struct;
struct resource r_irq_struct;
struct resource r_mem_struct;
struct resource *r_irq =3D &r_irq_struct; /* Interrupt resources
*/
struct resource *r_mem =3D &r_mem_struct; /* IO mem resources */
struct xemac_platform_data *pdata =3D &pdata_struct;
int rc =3D 0;
printk(KERN_ERR "Device Tree Probing \'%s\'\n",
ofdev->node->name);
/* Get iospace for the device */
rc =3D of_address_to_resource(ofdev->node, 0, r_mem);
if(rc) {
dev_warn(&ofdev->dev, "invalid address\n");
return rc;
}
/* Get IRQ for the device */
rc =3D of_irq_to_resource(ofdev->node, 0, r_irq);
if(rc =3D=3D NO_IRQ) {
dev_warn(&ofdev->dev, "no IRQ found.\n");
return rc;
}
pdata_struct.dma_mode =3D get_u32(ofdev,
"C_DMA_PRESENT");
pdata_struct.has_mii =3D get_u32(ofdev, "C_MII_EXIST");
pdata_struct.has_cam =3D get_u32(ofdev, "C_CAM_EXIST");
pdata_struct.has_err_cnt =3D get_u32(ofdev,
"C_ERR_COUNT_EXIST");
pdata_struct.has_jumbo =3D get_u32(ofdev,
"C_JUMBO_EXIST");
pdata_struct.tx_dre =3D get_u32(ofdev,
"C_TX_DRE_TYPE");
pdata_struct.rx_dre =3D get_u32(ofdev,
"C_RX_DRE_TYPE");
pdata_struct.tx_hw_csum =3D get_u32(ofdev,
"C_TX_INCLUDE_CSUM");
pdata_struct.rx_hw_csum =3D get_u32(ofdev,
"C_RX_INCLUDE_CSUM");
memcpy(pdata_struct.mac_addr, of_get_mac_address(ofdev->node),
6);
return probe_initialization(&ofdev->dev, r_mem, r_irq, pdata);
}
Where probe_initialization contains shares code with the platform_device
version of probe. This means that the string is still translated into
another name anyway. Anybody have any better ideas for doing this?
>=20
> I want to be careful though. Parameters can change from one version
> of an IP core to another. The driver needs to be able to determine
> what version of the IP core is used so that the parameters make sense.
> I'm also nervous about adding every possible C_ value to the device
> node for each xilinx IP-core; that could make the device tree quite
> large. (on the other hand; maybe that doesn't matter... It is
> probably a bigger deal for microblaze than powerpc too.).
Using the xparameters set of values could solve this problem, since only
things that make sense to the driver are actually set.
Steve
>=20
> Cheers,
> g.
>=20
> --=20
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>=20
>=20
^ permalink raw reply
* RE: [PATCH v2] Device tree bindings for Xilinx devices
From: Stephen Neuendorffer @ 2007-10-16 23:23 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, Wolfgang Reissnegger, Leonid,
microblaze-uclinux
In-Reply-To: <20071015155223.7403.39615.stgit@trillian.cg.shawcable.net>
It occurs to me that the 'compatible' bindings should probably be the
name of the preferred driver for the device.=20
> + l) Xilinx ML300 Framebuffer
> + - compatible : Must include "xilinx,ml300-fb"
Should probably be 'xilinxfb', and probably shouldn't reference ML300 at
all.
> + n) Xilinx EMAC and Xilinx TEMAC
> +
> + Xilinx Ethernet devices. Uses common properties from=20
> other Ethernet
> + devices with the following constraints:
> + =20
> + Required properties:
> + - compatible : Must include one of: "xilinx,plb-temac",
> + "xilinx,plb-emac", "xilinx-opb-emac"
Should probably be just 'emac' and 'temac'.
This should be possible to extract using Michel Simek's EDK-integrated
device tree generator. The compatibility information is stored in the
EDK driver's .mdd file (although this is somewhat backwards from what
one might expect).
Steve
^ permalink raw reply
* Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2007-10-16 23:22 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
Paul,
Here is the addition of the bestcomm driver. I think this is ready to go in.
There are remaining outstanding comments; but my opinion is that they
should be addressed in subsequent patches (performance optimization
for mp5200b boards and making the sram management code a generic
interface usable by other SoC support code).
If you agree; please pull into your tree.
The following changes since commit 65a6ec0d72a07f16719e9b7a96e1c4bae044b591:
Linus Torvalds (1):
Merge branch 'devel' of master.kernel.org:/home/rmk/linux-2.6-arm
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.24
Domen Puncer (1):
[POWERPC] mpc52xx: device tree changes for FEC and MDIO
Sylvain Munaut (7):
[POWERPC] exports rheap symbol to modules
[POWERPC] rheap: Changes config mechanism
[POWERPC] mpc52xx: Update mpc52xx_psc structure with B revision changes
[POWERPC] bestcomm: core bestcomm support for Freescale MPC5200
[POWERPC] bestcomm: ATA task support
[POWERPC] bestcomm: FEC task support
[POWERPC] bestcomm: GenBD task support
arch/powerpc/Kconfig | 4 +
arch/powerpc/boot/dts/lite5200b.dts | 18 +-
arch/powerpc/lib/Makefile | 5 +-
arch/powerpc/lib/rheap.c | 15 +
arch/powerpc/platforms/Kconfig | 4 +
arch/powerpc/platforms/Kconfig.cputype | 1 +
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/bestcomm/Kconfig | 39 ++
arch/powerpc/sysdev/bestcomm/Makefile | 14 +
arch/powerpc/sysdev/bestcomm/ata.c | 154 ++++++
arch/powerpc/sysdev/bestcomm/ata.h | 37 ++
arch/powerpc/sysdev/bestcomm/bcom_ata_task.c | 67 +++
arch/powerpc/sysdev/bestcomm/bcom_fec_rx_task.c | 78 +++
arch/powerpc/sysdev/bestcomm/bcom_fec_tx_task.c | 91 ++++
arch/powerpc/sysdev/bestcomm/bcom_gen_bd_rx_task.c | 63 +++
arch/powerpc/sysdev/bestcomm/bcom_gen_bd_tx_task.c | 69 +++
arch/powerpc/sysdev/bestcomm/bestcomm.c | 528 ++++++++++++++++++++
arch/powerpc/sysdev/bestcomm/bestcomm.h | 190 +++++++
arch/powerpc/sysdev/bestcomm/bestcomm_priv.h | 334 +++++++++++++
arch/powerpc/sysdev/bestcomm/fec.c | 270 ++++++++++
arch/powerpc/sysdev/bestcomm/fec.h | 61 +++
arch/powerpc/sysdev/bestcomm/gen_bd.c | 260 ++++++++++
arch/powerpc/sysdev/bestcomm/gen_bd.h | 48 ++
arch/powerpc/sysdev/bestcomm/sram.c | 177 +++++++
arch/powerpc/sysdev/bestcomm/sram.h | 54 ++
arch/ppc/Kconfig | 6 +
include/asm-ppc/mpc52xx_psc.h | 10 +-
27 files changed, 2591 insertions(+), 7 deletions(-)
create mode 100644 arch/powerpc/sysdev/bestcomm/Kconfig
create mode 100644 arch/powerpc/sysdev/bestcomm/Makefile
create mode 100644 arch/powerpc/sysdev/bestcomm/ata.c
create mode 100644 arch/powerpc/sysdev/bestcomm/ata.h
create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_ata_task.c
create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_fec_rx_task.c
create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_fec_tx_task.c
create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_gen_bd_rx_task.c
create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_gen_bd_tx_task.c
create mode 100644 arch/powerpc/sysdev/bestcomm/bestcomm.c
create mode 100644 arch/powerpc/sysdev/bestcomm/bestcomm.h
create mode 100644 arch/powerpc/sysdev/bestcomm/bestcomm_priv.h
create mode 100644 arch/powerpc/sysdev/bestcomm/fec.c
create mode 100644 arch/powerpc/sysdev/bestcomm/fec.h
create mode 100644 arch/powerpc/sysdev/bestcomm/gen_bd.c
create mode 100644 arch/powerpc/sysdev/bestcomm/gen_bd.h
create mode 100644 arch/powerpc/sysdev/bestcomm/sram.c
create mode 100644 arch/powerpc/sysdev/bestcomm/sram.h
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 1/2] bootwrapper: Allow wrapper script to execute verbosely
From: Grant Likely @ 2007-10-16 23:08 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, paulus, David Gibson
In-Reply-To: <jeejfuae27.fsf@sykes.suse.de>
On 10/16/07, Andreas Schwab <schwab@suse.de> wrote:
> Grant Likely <grant.likely@secretlab.ca> writes:
>
> > +# Allow for verbose output
> > +if [ "$V" == "1" ]; then
>
> The correct syntax is [ a = b ] (and the quotes around 1 are not needed,
> btw.).
heh; I guess I'm not much of a shell programmer. :-)
I'll respin this patch.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 1/2] bootwrapper: Allow wrapper script to execute verbosely
From: Andreas Schwab @ 2007-10-16 22:29 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus, David Gibson
In-Reply-To: <20071016213101.14117.43657.stgit@trillian.cg.shawcable.net>
Grant Likely <grant.likely@secretlab.ca> writes:
> +# Allow for verbose output
> +if [ "$V" == "1" ]; then
The correct syntax is [ a = b ] (and the quotes around 1 are not needed,
btw.).
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: ioctl32: Unknown cmd
From: David Miller @ 2007-10-16 22:24 UTC (permalink / raw)
To: arnd; +Cc: Geert.Uytterhoeven, linuxppc-dev, linux-kernel, jens.axboe
In-Reply-To: <200710162150.37636.arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 16 Oct 2007 21:50:35 +0200
> The one point where it is expected to have changed now is when you
> try to do these ioctls on something that is not a block device. Are
> you sure that the files you tried them on were created correctly?
Many many many programs do this exact sort of thing.
It is one of the bad aspects of moving the compat handling
down into the file ops for a specific device.
^ permalink raw reply
* Re: Serial init / BRG
From: Alan Bennett @ 2007-10-16 21:38 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47152065.9070403@freescale.com>
The lockup is only the shell. I echo from ttyCPM0 console and it
"locks" then I echo from an ssh session and the kernel messages still
output from the ttyCPM0 console.
NOTE: I found a severe issue that seems to have unlocked ttyCPM2. BUT
ttyCPM1 still hangs. (a while back, we commented out the out_be in
cpm_setbrg - oops (console debug left over))
with address / value in cpm_setbrg
echo test > /dev/ttyCPM1 # * note still hang *
CPM uart[1]:startup - port->irq 00000028
CPM uart[1]:startup - port->irq 40
cpm_setbrg:107 - brg:0 baud:9600
cpm_setbrg:108 - addr:e00119f0 value:00010140
echo test > /dev/ttyCPM2 * note doesn't hang *
CPM uart[2]:startup - port->irq 0000002b
CPM uart[2]:startup - port->irq 43
cpm_setbrg:107 - brg:3 baud:9600
cpm_setbrg:108 - addr:e00119fc value:00010140
On 10/16/07, Scott Wood <scottwood@freescale.com> wrote:
> Alan Bennett wrote:
> > I also verified that when I attempt to echo to the ports that I reach
> > the appropriate driver
> > i.e.
> > echo "hello" > /dev/ttyCPM1
> > CPM uart[1]:startup - port->irq 40
> > echo "hello" > /dev/ttyCPM2
> > CPM uart[2]:startup - port->irq 43
> > but brg's stay 0x0 and my shell's lock up something fierce.
>
> Hmm... try putting a debugging printk in cpm_setbrg with the address
> and value it's writing.
>
> Is it just the shell that locks up, or the console (i.e. can you still
> get kernel messages)?
>
> > (note: my tree is still based off of one you provided a few weeks
> > back. have the 82xx / ep8248e changes we went through been pushed
> > into linus' git tree?)
>
> It should all be in Linus's tree except the actual ep8248e file, which
> didn't make it this time around due to interdependencies on netdev.
> Note that there are some small device tree changes from the tree you're
> currently using (in particular, muram is now in a node of its own).
>
> -Scott
>
^ permalink raw reply
* [PATCH 1/2] bootwrapper: Allow wrapper script to execute verbosely
From: Grant Likely @ 2007-10-16 21:31 UTC (permalink / raw)
To: linuxppc-dev, paulus, David Gibson, Scott Wood
From: Grant Likely <grant.likely@secretlab.ca>
Allow wrapper script to print verbose progress when the V is set in the
environment.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/boot/wrapper | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 39b27e5..8323ea4 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -21,6 +21,11 @@
# (default ./arch/powerpc/boot)
# -W dir specify working directory for temporary files (default .)
+# Allow for verbose output
+if [ "$V" == "1" ]; then
+ set -x
+fi
+
# defaults
kernel=
ofile=zImage
^ permalink raw reply related
* [PATCH 2/2] bootwrapper: Bail from script if any command fails
From: Grant Likely @ 2007-10-16 21:31 UTC (permalink / raw)
To: linuxppc-dev, paulus, David Gibson, Scott Wood
In-Reply-To: <20071016213101.14117.43657.stgit@trillian.cg.shawcable.net>
From: Grant Likely <grant.likely@secretlab.ca>
Add the 'set -e' command to the wrapper script so that if any command
fails then the script will automatically exit
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/boot/wrapper | 27 ++++++++++-----------------
1 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 8323ea4..da5fcfa 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -21,6 +21,9 @@
# (default ./arch/powerpc/boot)
# -W dir specify working directory for temporary files (default .)
+# Stop execution if any command fails
+set -e
+
# Allow for verbose output
if [ "$V" == "1" ]; then
set -x
@@ -116,7 +119,7 @@ if [ -n "$dts" ]; then
if [ -z "$dtb" ]; then
dtb="$platform.dtb"
fi
- dtc -O dtb -o "$dtb" -b 0 -V 16 "$dts" || exit 1
+ dtc -O dtb -o "$dtb" -b 0 -V 16 "$dts"
fi
if [ -z "$kernel" ]; then
@@ -287,23 +290,13 @@ ps3)
rm -f "$object/otheros.bld"
- msg=$(dd if="$ofile.bin" of="$ofile.bin" conv=notrunc \
- skip=$overlay_dest seek=$system_reset_kernel \
- count=$overlay_size bs=1 2>&1)
-
- if [ $? -ne "0" ]; then
- echo $msg
- exit 1
- fi
+ dd if="$ofile.bin" of="$ofile.bin" conv=notrunc \
+ skip=$overlay_dest seek=$system_reset_kernel \
+ count=$overlay_size bs=1
- msg=$(dd if="$ofile.bin" of="$ofile.bin" conv=notrunc \
- skip=$system_reset_overlay seek=$overlay_dest \
- count=$overlay_size bs=1 2>&1)
-
- if [ $? -ne "0" ]; then
- echo $msg
- exit 2
- fi
+ dd if="$ofile.bin" of="$ofile.bin" conv=notrunc \
+ skip=$system_reset_overlay seek=$overlay_dest \
+ count=$overlay_size bs=1
gzip --force -9 --stdout "$ofile.bin" > "$object/otheros.bld"
;;
^ permalink raw reply related
* Re: [Linux-fbdev-devel] vga16fb doesn't build on powerpc (vgacon_remap_base)
From: Antonino A. Daplas @ 2007-10-16 21:31 UTC (permalink / raw)
To: linux-fbdev-devel; +Cc: linuxppc-dev list
In-Reply-To: <20071016191403.GA5962@nineveh.local>
On Tue, 2007-10-16 at 15:14 -0400, Joseph Fannin wrote:
> vga16fb is an available config option on powerpc, but it won't link
> with my .config:
>
> ERROR: "vgacon_remap_base" [drivers/video/vga16fb.ko] undefined!
>
>
> I'm guessing this is because include/asm-powerpc/vga.h declares
> vgacon_remap_base:
>
> extern unsigned long vgacon_remap_base;
>
>
> ...but arch/powerpc/kernel/setup_32.c wraps the definition in an #ifdef:
>
> #ifdef CONFIG_VGA_CONSOLE
Perhaps #if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_FB_VGA16) ?
or
bool VGA_HARDWARE
#if CONFIG_VGA_HARDWARE
unsigned long vgacon_remap_base;
EXPORT_SYMBOL(vgacon_remap_base);
#endif
and for the Kconfig entry of vgacon and vga16fb
select VGA_HARDWARE if PPC32
(or depends on (VGA_HARDWARE && PPC32))
Tony
^ permalink raw reply
* Re: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Benjamin Herrenschmidt @ 2007-10-16 21:14 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, Roland Dreier, David S. Miller, linuxppc-dev list
In-Reply-To: <20071016115318.0fc36af3@freepuppy.rosehill>
> So this is really just like synchronize_irq()? Using msleep is bogus
> because you want to spin, you are only waiting for a softirq on the other
> cpu to finish. If you wait for a whole millisecond and sleep that
> is far longer than the napi routine should take.
>
> You could even optimize it like synchronize_irq() for the non-SMP case.
It's just like synchronize_irq() indeed. I used the mlseep() just like
napi_disable() mostly because I use it in a very similar context, for
disabling my sub-channels on things like link change etc... where I need
to reconfigure parts of the chip.
I prefer sleeping in my case but I agree that if somebody else was going
to use for something else more performance critical, it might be an
issue. On the other hand, spinning will not be nice for my usage
scenario :-)
I agree about the SMP optimisation though again, in my usage pattern,
it's very unimportant (similar code path as napi_disable)
I'll respin later today though.
Cheers,
Ben.
^ permalink raw reply
* New time code miscalculates cpu usage
From: Olof Johansson @ 2007-10-16 20:25 UTC (permalink / raw)
To: paulus, benh; +Cc: linuxppc-dev
Hi,
Not sure when this started happening, but I wanted to report it. I'll
start bisecting in a day or two if noone else has gotten around to
looking at it:
$ echo "int main(void) { while(1); }" > test.c ; gcc test.c
$ time ./a.out & sleep 2 ; killall a.out
real 0m2.008s
user 0m4.014s
sys 0m0.002s
Seen on POWER5 and PA6T, haven't tried anything else yet.
-Olof
^ permalink raw reply
* Re: Linux booting problem on Xilinx ppc
From: Grant Likely @ 2007-10-16 20:14 UTC (permalink / raw)
To: T Ziomek; +Cc: aauer1, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.64.0710161511280.22843@gauley.ddna.labs.mot.com>
On 10/16/07, T Ziomek <ctz001@email.mot.com> wrote:
> On Tue, 16 Oct 2007, Grant Likely wrote:
> >
> > There are two common reasons for this behaviour:
> > 1. kernel crashes before the console is configured
> > 2. the console is not configured correctly.
> >
> > In both cases; finding a way to look at __log_buf is the fastest way
> > to figure out what is going on.
>
> Woah. Grant's [good] advise notwithstanding, I'm confused
In what way?
>
> --
> /"\ ASCII Ribbon Campaign |
> \ / | Email to user 'CTZ001'
> X Against HTML | at 'email.mot.com'
> / \ in e-mail & news |
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Ack, sorry! [was Re: Linux booting problem on Xilinx ppc]
From: T Ziomek @ 2007-10-16 20:13 UTC (permalink / raw)
To: aauer1, linuxppc-embedded
In-Reply-To: <fa686aa40710161237t54688b71g9c7cf9acdac2b744@mail.gmail.com>
Please ignore my previous msg; I wanted to <cancel> rather than <send>...
Sorry.
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* Re: Linux booting problem on Xilinx ppc
From: T Ziomek @ 2007-10-16 20:12 UTC (permalink / raw)
To: aauer1; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40710161237t54688b71g9c7cf9acdac2b744@mail.gmail.com>
On Tue, 16 Oct 2007, Grant Likely wrote:
>
> On 10/16/07, aauer1 <aauer1@gmx.at> wrote:
>>
>> The on-chip memories are disabled. Only the BRAM is enabled. Now, we also use
>> the ELDK 4.1 from Denx and the included cross compiler. The result is the
>> same... the Kernel stops at "Now booting the kernel". Now, we also have an
>> USB JTAG cable. So, we can debug the memory.
>> Probably, anyone has another idea.
>
> There are two common reasons for this behaviour:
> 1. kernel crashes before the console is configured
> 2. the console is not configured correctly.
>
> In both cases; finding a way to look at __log_buf is the fastest way
> to figure out what is going on.
Woah. Grant's [good] advise notwithstanding, I'm confused
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* Re: Describing devices in the device tree
From: Grant Likely @ 2007-10-16 20:06 UTC (permalink / raw)
To: Alan Bennett; +Cc: linuxppc-dev
In-Reply-To: <bfa0697f0710161136y7d28ccd6w828f16d30f85ce19@mail.gmail.com>
On 10/16/07, Alan Bennett <embedded@akb.net> wrote:
> I'm using a modified ep8248e.dts to describe my hardware and I want to
> enable the use of 3 standard interrupts.
>
> 1. irq5
> 2. timer1
> 3. timer2
>
> How bad does this look?
> soc --> cpm -->
> timer {
> device_type = "timer";
> compatible = "fsl,mpc8248-timer";
> interrupts = <c 8 d 8>;
> interrupt-parent = <&PIC>;
> };
> irq5 {
> device_type = "irq5";
> compatible = "fsl,mpc8248-irq5";
> interrupts = <17 8>;
> interrupt-parent = <&PIC>;
> };
Don't do this. Instead, describe the device that generates the
interrupt. You don't need the device_type property either unless it
is a common device. The compatible property should also describe your
device; not the irq line.
Just creating a device node to describe an irq line doesn't buy you
anything because your device driver still needs to have the knowledge
built into it to use IRQ5. You may as well have just hard coded the
value into your driver instead of traversing through the device tree
to get it.
You get an advantage when you create a node for you *device* that your
device driver can bind, and embed into that node the IRQ line that it
uses.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: ioctl32: Unknown cmd
From: Arnd Bergmann @ 2007-10-16 19:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Linux Kernel Development, Jens Axboe
In-Reply-To: <Pine.LNX.4.62.0710161642200.20196@pademelon.sonytel.be>
On Tuesday 16 October 2007, Geert Uytterhoeven wrote:
> The recent (post 2.6.23) changes to compat_ioctl made the reporting of
> unsupported ioctls more verbose. E.g. on the PS3 I get:
>
> | ioctl32(cdrom_id:608): Unknown cmd fd(3) cmd(00005331){t:'S';sz:0} arg(00000000) on /dev/.tmp-11-0
> | ioctl32(hdparm:1427): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(00000000) on /dev/ps3da
> | ioctl32(hdparm:1427): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(00000000) on /dev/ps3da
>
> The first one is triggered by the detection of the CD/DVD/BD-ROM driver,
> The others are triggered by me running hdparm.
>
> Was this intentional?
>
No, it was certainly not intentional, and I can't figure out why it happens.
The ioctl numbers from your example are HDIO_DRIVE_CMD and CDROM_GET_CAPABILITY,
both of which should be handled through compat_blkdev_driver_ioctl by calling
the native ioctl method of the driver, and return -ENOTTY otherwise.
The one point where it is expected to have changed now is when you try
to do these ioctls on something that is not a block device. Are you sure that
the files you tried them on were created correctly?
Arnd <><
^ permalink raw reply
* Re: Refactor booting-without-of.txt
From: Grant Likely @ 2007-10-16 19:39 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: Olof Johansson, linuxppc-dev, microblaze-uclinux, David Gibson
In-Reply-To: <20071016172509.08B73FE0077@mail38-dub.bigfish.com>
On 10/16/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
> How about just 'device-tree', referring to any source, and then
> of-device-tree and flat-device-tree to document how the device tree is
> constructed.
> The fact that the API is poorly named is something that can always be
> fixed (and perhaps should be earlier rather than later).
It's not so much that it's poorly named; it's just historically named. :-)
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Linux booting problem on Xilinx ppc
From: Grant Likely @ 2007-10-16 19:37 UTC (permalink / raw)
To: aauer1; +Cc: linuxppc-embedded
In-Reply-To: <13239003.post@talk.nabble.com>
On 10/16/07, aauer1 <aauer1@gmx.at> wrote:
>
> The on-chip memories are disabled. Only the BRAM is enabled. Now, we also use
> the ELDK 4.1 from Denx and the included cross compiler. The result is the
> same... the Kernel stops at "Now booting the kernel". Now, we also have an
> USB JTAG cable. So, we can debug the memory.
> Probably, anyone has another idea.
There are two common reasons for this behaviour:
1. kernel crashes before the console is configured
2. the console is not configured correctly.
In both cases; finding a way to look at __log_buf is the fastest way
to figure out what is going on.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH v2] Device tree bindings for Xilinx devices
From: Grant Likely @ 2007-10-16 19:36 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: linuxppc-dev, microblaze-uclinux, Wolfgang Reissnegger, Leonid
In-Reply-To: <20071016182425.DCBF0BA804F@mail41-fra.bigfish.com>
On 10/16/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
> > + n) Xilinx EMAC and Xilinx TEMAC
> > +
> > + Xilinx Ethernet devices. Uses common properties from
> > other Ethernet
> > + devices with the following constraints:
> > +
> > + Required properties:
> > + - compatible : Must include one of: "xilinx,plb-temac",
> > + "xilinx,plb-emac", "xilinx-opb-emac"
> > + - dma-mode : Must be one of "none", "simple", "sg" (sg
> > == scatter gather)
>
> I think it's going to be a significant headache to remap things like the
> dma-mode from the xilinx configurations to something else, and then
> interpret them correctly in the drivers.
>
> Although it lacks a bit in style, perhaps, I'd greatly prefer having
> something like:
>
> Ethernet_MAC {
> xilinx,C_DMA_PRESENT = <1>;
> ...
> }
>
> (which happens to correspond to "none" above)
Ugh. Can't say I'm thrilled about this....
But in this case is might be a necessity. The IP core is already
parameterized and the best way to describe the device is to use the
existing parameter names.
I want to be careful though. Parameters can change from one version
of an IP core to another. The driver needs to be able to determine
what version of the IP core is used so that the parameters make sense.
I'm also nervous about adding every possible C_ value to the device
node for each xilinx IP-core; that could make the device tree quite
large. (on the other hand; maybe that doesn't matter... It is
probably a bigger deal for microblaze than powerpc too.).
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* RE: cross compilation issue
From: Leisner, Martin @ 2007-10-16 19:34 UTC (permalink / raw)
To: Wolfgang Denk
Cc: linuxppc-embedded,
linuxppc-embedded-bounces+ravi.rao=rflelect.com
In-Reply-To: <20071016190750.224A3242E9@gemini.denx.de>
Wolfgang,
I disagree vehemently with "modifying" you session to suit the platform.
This becomes a problem when cross-platforms > 1. When I "set the PATH =
and
environment variables" I have the same problem -- I go to a different=20
platform, type make and get bad results. =20
Why is modifying the makefile a "bad thing?" hardhat did it, and =
afterwards
the cross-compile/arch becomes painless and transparent. Building ways =
to=20
construct software with fewer chances of human error is IMHO a "good =
thing".
I tend to lock down my source tree, and have a link tree for each =
platform.
So I'm not changing my build parameters, hard coding these things in the =
makefile
becomes a "set and forget" operation.
I agree with "problems" running from command lines...I often link in=20
special tools into ~/bin so I can find them (instead of modifying my =
path).
But I can go weeks without having to run a tool from the command line, =
make's I run daily.
Having to "source" a script is another thing you can "forget" to do.
I often "forget" to run my 'make-line' script, and when I quickly hit =
<cntl>-C I don't
have problems (but sometimes I do).
marty
PS:
To cross developers, its VERY handy to build a copy of binutils which =
support multiple=20
architectures -- so the
only thing which is really platform dependent is gas...so my host =
nm/objcopy/objdump/ld
supports all the platforms I'm working on...
-----Original Message-----
From: Wolfgang Denk [mailto:wd@denx.de]
Sent: Tue 10/16/2007 3:07 PM
To: Leisner, Martin
Cc: ravi.rao@rflelect.com; avenkatesh@hcl.in; =
linuxppc-embedded-bounces+ravi.rao=3Drflelect.com@ozlabs.org; =
linuxppc-embedded@ozlabs.org
Subject: Re: cross compilation issue
=20
Dear Martin,
in message =
<556445368AFA1C438794ABDA8901891C0750DDF0@USA0300MS03.na.xerox.net> you =
wrote:
>=20
> #! /bin/bash
>=20
> exec make ARCH=3Dpowerpc =
CROSS_COMPILE=3D/opt/denx/eldk4.1/usr/bin/ppc_74xx- =
INSTALL_MOD_PATH=3D${PWD}/root $*
Note that this is *NOT* a suppoted value for CROSS_COMPILE. Please set
your PATH to include the /opt/denx/eldk4.1/usr/bin directory, and set
CROSS_COMPILE=3Dppc_74xx-=20
> I know hardhat linux had a strategy to make . files hiding the names =
of ARCH/CROSS_COMPILE -- so typing make
> would work once configured...
>=20
> IMHO it should be hardcoded in the Makefile after configuration -- it =
causes a lot of grief if you FORGET
> to specify one of these and just type "make".
I disagree. Such an approach will hit you as soon as you run a command
not from "make", but from the command line.
Instead, please set and export thse variables in your shell
environment, where each tool can pick it up.
If you have to switch environments frequently you can use some shell
functions to do so. For example, ELDK 4.1 which you use comes with
the "eldk_init" script ("/opt/denx/eldk4.1/eldk_init" in your
installation) which can be "sourced" from the shell like this:
$ source /opt/denx/eldk4.1/eldk_init 74xx
ARCH=3Dppc
CROSS_COMPILE=3Dppc_74xx-
DEPMOD=3D/opt/denx/eldk4.1/usr/bin/depmod.pl
PATH=3D/opt/denx/eldk4.1/usr/bin:/opt/denx/eldk4.1/bin: ...
$
ELDK 4.2 will use a much cleverer script "eldk-switch" which allows
to select versions and board like this:
-> eldk-switch -r4.1 sequoia
[ sequoia is using PPC440EPx ]
Setup for ppc_4xxFP (using ELDK 4.1)
-> eldk-switch -r4.2 TQM8540
[ TQM8540 is using MPC8540 ]
Setup for ppc_85xx (using ELDK 4.2)
-> eldk-switch -r4.0 MPC860
Setup for ppc_8xx (using ELDK 4.0)
-> eldk-switch MPC7448
Setup for ppc_74xx (using ELDK 4.2)
> One of the things I want to do is look at how the linux make system =
works now (I recall at times I edit the Makefile
> to hardcode these things).
Never edit the Makefile - this is always a Bad Thing (TM) to do.
Make sure to either set the ARCH and CROSS_COMPILE ariables in your
environment (this is IMHO the more convenient way) or pass them on
the make command line.
Best regards,
Wolfgang Denk
--=20
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Wenn Du ein' weise Antwort verlangst, Mu=DFt Du vern=FCnftig fragen.
-- Goethe, Invektiven
^ permalink raw reply
* Re: [PATCH v2] pasemi: process i2c device tree entries at boot
From: Scott Wood @ 2007-10-16 16:21 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071016001701.GA25444@lixom.net>
Olof Johansson wrote:
> On Mon, Oct 15, 2007 at 05:54:51PM -0500, Scott Wood wrote:
>> Olof Johansson wrote:
>>> Setup i2c_board_info based on device tree contents. This has to be
>>> a device_initcall since we need PCI to be probed by the time we
>>> run it, but before the actual driver is initialized.
>> Can we factor at least some of this stuff out into common code?
>
> I didn't really feel strong motivations to do so, given that the amount
> of shared code is quite small, and the official bindings are not yet
> determined.
Enh... I'm just irked because I originally did it in a generic manner,
and whoever it was that did further work on my patch shoved in into
fsl_soc. :-P
> Chances are whenever the bindings are done they might be incompatible
> with what we already have in our firmware, so the code would need to be
> separated out again.
Well, then it'd be better to just have one bit of code to fix, right? :-)
It'd suck to see different i2c controllers end up implementing the
binding differently due to the forking, though. Already with this
patch, we have a different set of i2c devices that will be recognized
depending on the adapter.
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: Jean Delvare @ 2007-10-16 19:19 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Stefan Roese, i2c, David Gibson
In-Reply-To: <fa686aa40710152121o2fe0d7c9m156170901fd3bf98@mail.gmail.com>
On Mon, 15 Oct 2007 22:21:38 -0600, Grant Likely wrote:
> On 10/15/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> > In fact I think it may be acceptle to do the idx++ thing in this
> > situation. Bus numbers are ugly, but it's not the worst ugliness in
> > the horrible mess that is the Linux i2c subsystem. It means that bus
> > numbers are theoretically unstable, but that's increasingly true of
> > devices of all sorts - it's up to udev to assign meaningful labels at
> > the user level.
David, after such a rant against the Linux i2c subsystem, I sure hope
that you're going to contribute patches to make it better (whatever you
think needs to be improved, as you didn't say.)
> I think the real problem here comes into play when there are 2 types
> of i2c busses in the system. If they both maintain their own idx++
> values; then they will conflict. If an auto assigned bus number is
> used; then it needs to be assigned by the i2c infrastructure; not by
> the driver.
Very true. If you aren't going to define the i2c bus numbers at
platform data level, then you shouldn't be defining them _at all_.
Don't use i2c_add_numbered_adapter, use i2c_add_adapter and let
i2c-core choose an appropriate a bus number.
--
Jean Delvare
^ 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