* Flash on ep8248e standard motherboards
From: Alan Bennett @ 2007-09-04 18:08 UTC (permalink / raw)
To: linuxppc-embedded
Please accept my apologies for sending the last email and accept this
email address and question. without the disclaimer.
---------------------------------------------------
Hello;
We have a custom board based on the ep8248e design from Embedded
Planet and I'm trying to use something other than codewarrior to flash
u-boot srec's
I'm not sure where the problem is, but I'm unable to flash the
u-boot.srec onto the Embedded Planet board (using the BDI2000), let
alone our custom board.
1. Embedded Planet ep8248E
64 MB SDRAM
64 MB Flash (x2 Am29LV256M)
2. Custom
128 MB SDRAM
128 MB Flash (X2 Spansion S29GL512N)
NOTE: CW successfully flashes both parts, but then again, it's CW.
BDI 2000 Config File:
; initialize - FLASH BR0 & OR0 (64 Mbyte)
;*******************************************
WM32 0xf0010100 0xfc001801
WM32 0xf0010104 0xfc0008c2
[FLASH]
CHIPTYPE MIRRORX16
CHIPSIZE 0x2000000
BUSWIDTH 16
I then attempt to unlock/erase/program
Check for Sanity (NOTE: using BDI 2000 PROMPT)
md 0xf0010100 2
f0010100 : 0xf8001801 - 134211583 ....
f0010104 : 0xf80008b2 - 134215502 ....
md 0xfff00000 2
fff00000 : 0x10101010 269488144 ....
fff00004 : 0x10101010 269488144 ....
All looks good. (10101010 is the existing planet core header)
TRY TO UNLOCK
unlock 0xfff00000 1000
Unlocking flash at 0xfff00000
# Invalid parameter for flash programming
TRY TO ERASE
erase 0xfff00000 UNLOCK 1000
Erasing flash at 0xfff00000
# Erasing flash memory failed
BUT
erase 0xffff0000 UNLOCK 1000
Erasing flash at 0xffff0000
Erasing flash passed
HOWEVER
mm 0xffff0000 0xdeadbeef
md 0xffff0000 1
ffff0000 : 0xffffffff
SO it doesn't seem to allow write access afterall...
Is there anyone that has a BDI 2000 config file for flashing the
ep8248e motherboard the 8MB Flash Version (64 MB flash version)
Thanks
-Alan
^ permalink raw reply
* Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: Scott Wood @ 2007-09-04 18:20 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20070904104750.GA32451@localhost.localdomain>
On Tue, Sep 04, 2007 at 02:47:50PM +0400, Anton Vorontsov wrote:
> > _and system GPIOs_ :-)
>
> Yup, firmware should set up gpios, to make initial kernel boot.
No, it should set all pins and similar setup-once type initialization
that is board-specific rather than device-specific -- there's no reason
for the kernel to need to care about that sort of thing.
> After that, kernel can and should manage GPIOs. Few examples.
>
> Say units (like USB or SPI) can work in very different modes. And
> it's okay if user want to change device mode in the runtime.
This is a special case that warrants kernel involvement. It should not
be used as justification for the bootloader leaving pins unconfigured in
the majority of cases where it does not make sense to change them at
runtime.
> Another example, power management - if some unit temporarily unused,
> to save power GPIOs should be set up differently. Say if SPI unit
> turned off (unused just now), it's wise to bring their dedicated
> GPIOs to "power saving" state (be it output0/1 or input, it
> depends).
The kernel is of course welcome to do so -- and this may be a valid
reason to attach pin information to specific device nodes, if it actually
saves a non-negligible amount of power -- but it's not a reason to force
the kernel to have to care by not setting things up in the firmware.
-Scott
^ permalink raw reply
* Re: disable interrput under ppc?
From: Scott Wood @ 2007-09-04 18:24 UTC (permalink / raw)
To: Wang, Baojun; +Cc: linuxppc-embedded
In-Reply-To: <200709041044.16525.wangbj@lzu.edu.cn>
On Tue, Sep 04, 2007 at 10:44:14AM +0800, Wang, Baojun wrote:
> hi, list
>
> How can I disable interrput like `cli' in x86?
local_irq_disable().
> I want the following code freeze the box but it doesn't, $MSR is
> altered however the box is still alive, how can I freeze the box like
> `cli' in x86? Thanks very much!
Disabling interrupts doesn't freeze the machine by itself -- it depends
on what you do afterwards, which you didn't show.
-Scott
^ permalink raw reply
* Re: disable interrput under ppc?
From: Josh Boyer @ 2007-09-04 18:37 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <20070904182433.GD18280@ld0162-tx32.am.freescale.net>
On Tue, 4 Sep 2007 13:24:33 -0500
Scott Wood <scottwood@freescale.com> wrote:
> On Tue, Sep 04, 2007 at 10:44:14AM +0800, Wang, Baojun wrote:
> > hi, list
> >
> > How can I disable interrput like `cli' in x86?
>
> local_irq_disable().
>
> > I want the following code freeze the box but it doesn't, $MSR is
> > altered however the box is still alive, how can I freeze the box like
> > `cli' in x86? Thanks very much!
>
> Disabling interrupts doesn't freeze the machine by itself -- it depends
> on what you do afterwards, which you didn't show.
If you're using a BOOKE variant, there is a way to use the DBCR0
register to set debug wait enable or something to basically hang the
CPU until something external clears that bit. But why you would want
to do that, I have no idea.
josh
^ permalink raw reply
* Re: "atomic" 64-bit math on 32-bit ppc's?
From: Scott Wood @ 2007-09-04 18:48 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: ppc-dev
In-Reply-To: <20070904113937.GA3994@iram.es>
On Tue, Sep 04, 2007 at 01:39:37PM +0200, Gabriel Paubert wrote:
> That's wrong if lock is assigned to r0, you should use
> a "b" constraint to avoid this. Same for atomic_dec below.
GCC should really have removed r0 from the "r" class (it isn't truly a
general-purpose register), and had a different class meaning "r"-plus-r0.
-Scott
^ permalink raw reply
* Problems with MPC8272ADS
From: Manil Gaouar @ 2007-09-04 19:53 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 396 bytes --]
Hi,
I am a bit newbie in this. I tried compiling Linux 2.4 using
ADS8272_deconfig from the kernel 2.6 and I have many compilation errors.
Are the deconfig files from 2.4 to 2.6 that different, or can I use the
2.6 file with little changes???
I don't understand why there is support for this board in 2.6 and not in
2.4, since Denx recommend 2.4.
Thx for your help!
[-- Attachment #2: Type: text/html, Size: 2241 bytes --]
^ permalink raw reply
* Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: Vitaly Bordug @ 2007-09-04 20:15 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20070904182028.GC18280@ld0162-tx32.am.freescale.net>
On Tue, 4 Sep 2007 13:20:28 -0500
Scott Wood wrote:
> > > _and system GPIOs_ :-)
> >
> > Yup, firmware should set up gpios, to make initial kernel boot.
>
> No, it should set all pins and similar setup-once type initialization
> that is board-specific rather than device-specific -- there's no
> reason for the kernel to need to care about that sort of thing.
>
> > After that, kernel can and should manage GPIOs. Few examples.
> >
> > Say units (like USB or SPI) can work in very different modes. And
> > it's okay if user want to change device mode in the runtime.
>
> This is a special case that warrants kernel involvement. It should
> not be used as justification for the bootloader leaving pins
> unconfigured in the majority of cases where it does not make sense to
> change them at runtime.
>
This argue is useless: both opinions have same weight. Firmware is able to provide meaningful default gpio setup, and nobody
will object. The point is, that blindly assume all the low-level stuff is fine, you are able only in case you've developed respective bits in the firmware.
More usual case is additional overhead of checking if the firmware not attempting to do something not really wanted, so we'll
always have a tradeoff.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 3/9] cpm2: Add SCCs to cpm2_clk_setup(), and cpm2_smc_clk_setup().
From: Vitaly Bordug @ 2007-09-04 20:43 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070830201500.GB5144@ld0162-tx32.am.freescale.net>
On Thu, 30 Aug 2007 15:15:00 -0500
Scott Wood wrote:
> On Thu, Aug 30, 2007 at 02:25:48AM +0400, Vitaly Bordug wrote:
> > I would have it in the same patch, that adds clocking stuff to 8xx.
>
> I was trying to keep the 8xx and 82xx patchsets reasonably separate.
>
> > And maybe in the same, segregate source rather then having it in the
> > foo_common.c, to ease fix/update/rework.
>
> I'm not sure I understand what you mean -- where do you want the code
> to go?
>
Thinking once again about this, It looks good the way it is, another way is prolly overkill so nm.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 4/9] cpm2: Add cpm2_set_pin().
From: Vitaly Bordug @ 2007-09-04 20:51 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070828201924.GD24329@ld0162-tx32.am.freescale.net>
On Tue, 28 Aug 2007 15:19:24 -0500
Scott Wood wrote:
> This provides a generic way for board code to set up CPM pins, rather
> than directly poking magic values into registers.
>
Please provide more info either here or somewhere in Documentation/, or inside the code at least.
We're adding new utility function here, and need to describe in a nutshell now the thing works.
This is completely self-explanatory for limited amount of people, I mean.
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/sysdev/cpm2_common.c | 33
> +++++++++++++++++++++++++++++++++ include/asm-powerpc/cpm2.h
> | 9 +++++++++ 2 files changed, 42 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/cpm2_common.c
> b/arch/powerpc/sysdev/cpm2_common.c index 549da4b..b8460c0 100644
> --- a/arch/powerpc/sysdev/cpm2_common.c
> +++ b/arch/powerpc/sysdev/cpm2_common.c
> @@ -418,3 +418,36 @@ void *cpm_dpram_addr(unsigned long offset)
> return (void __force *)(im_dprambase + offset);
> }
> EXPORT_SYMBOL(cpm_dpram_addr);
> +
> +struct cpm2_ioports {
> + u32 dir, par, sor, odr, dat;
> + u32 res[3];
> +};
> +
> +void cpm2_set_pin(int port, int pin, int flags)
> +{
> + struct cpm2_ioports __iomem *iop =
> + (struct cpm2_ioports __iomem *)&cpm2_immr->im_ioport;
> +
> + pin = 1 << (31 - pin);
> +
> + if (flags & CPM_PIN_OUTPUT)
> + setbits32(&iop[port].dir, pin);
> + else
> + clrbits32(&iop[port].dir, pin);
> +
> + if (!(flags & CPM_PIN_GPIO))
> + setbits32(&iop[port].par, pin);
> + else
> + clrbits32(&iop[port].par, pin);
> +
> + if (flags & CPM_PIN_SECONDARY)
> + setbits32(&iop[port].sor, pin);
> + else
> + clrbits32(&iop[port].sor, pin);
> +
> + if (flags & CPM_PIN_OPENDRAIN)
> + setbits32(&iop[port].odr, pin);
> + else
> + clrbits32(&iop[port].odr, pin);
> +}
> diff --git a/include/asm-powerpc/cpm2.h b/include/asm-powerpc/cpm2.h
> index 41a45db..d7b57ac 100644
> --- a/include/asm-powerpc/cpm2.h
> +++ b/include/asm-powerpc/cpm2.h
> @@ -1247,5 +1247,14 @@ enum cpm_clk {
> extern int cpm2_clk_setup(enum cpm_clk_target target, int clock, int
> mode); extern int cpm2_smc_clk_setup(enum cpm_clk_target target, int
> clock);
> +#define CPM_PIN_INPUT 0
> +#define CPM_PIN_OUTPUT 1
> +#define CPM_PIN_PRIMARY 0
> +#define CPM_PIN_SECONDARY 2
> +#define CPM_PIN_GPIO 4
> +#define CPM_PIN_OPENDRAIN 8
> +
> +void cpm2_set_pin(int port, int pin, int flags);
> +
> #endif /* __CPM2__ */
> #endif /* __KERNEL__ */
--
Sincerely, Vitaly
^ permalink raw reply
* Re: Newbie on embedded linux on PPC: error: cannot find boot.o
From: Wolfgang Reissnegger @ 2007-09-04 21:33 UTC (permalink / raw)
To: Thomas Gerlach; +Cc: linuxppc-embedded
In-Reply-To: <46DD65BF.5090304@kip.uni-heidelberg.de>
Hi Thomas,
Xilinx is building the tools in the EDK to work with VxWorks and for Standalone systems. In order to compile a Linux kernel you need to get a toolchain from one of the Third Party vendors, such as MontaVista. They have the correct linker scripts for building a kernel.
Cheers,
Wolfgang
Thomas Gerlach wrote:
> hi folks,
>
>
> my name is thomas trying to make embedded linux run on a powerpc, but
> we've got special boards here, although we use a xilinx virtex4
> fpga...
>
> as you said in the nabble-thread (see subject), i set up edk9.1
> software platform settings und ran libgen to get the xparameters*
> files. i copied those bsp files into the kernel tree (i use your
> kernel linux-2.6-virtex from git.secretlabs.ca/git). after
> configuring the kernel settigs, i try
>
> $ make ARCH=ppc CROSS_COMPILE=powerpc-eabi-
>
> what i get is the following output:
>
>> CHK include/linux/version.h
>> CHK include/linux/utsrelease.h
>> CALL scripts/checksyscalls.sh
>> CHK include/linux/compile.h
>> LD init/mounts.o
>> powerpc-eabi-ld: cannot find boot.o
>> make[1]: *** [init/mounts.o] Error 1
>> make: *** [init] Error 2
>
> so, i searched for boot.o (it exists) and even copied it into several
> dirs of the linux kernel tree (where i thought i would make sense),
> but the problem still remains.
>
> googling results in
>
> http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&getPagePath=17462&BV_SessionID=@@@@1197140711.1188909240@@@@&BV_EngineID=cccgaddllgmfkflcefeceihdffhdfkf.0
>
>
> and this, too, doesn't take me further in solving the problem.
>
> i hope you can help me.
>
> many thanks in advance,
>
> kind regards
> thomas gerlach
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: [patch 2/2] Cell: Wrap master run control bit
From: Arnd Bergmann @ 2007-09-04 22:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Masato Noguchi, Paul Mackerras, Jeremy Kerr
In-Reply-To: <200709050042.13926.arnd@arndb.de>
On Wednesday 05 September 2007, Arnd Bergmann wrote:
> On Tuesday 04 September 2007, Geoff Levand wrote:
> >=20
> > From: Masato Noguchi <Masato.Noguchi@jp.sony.com>
> >=20
> > Add platform specific SPU run control routines.
> >=20
> > The current spufs_run_spu() implementation uses the SPU master
> > run control bit (MFC_SR1[S]) to control SPE execution, but the
> > PS3 hypervisor does not support the use of this feature. =A0This
> > change adds run control wrapper routines. =A0The =A0bare metal
> > routines use the master run control bit, and the PS3 specific
> > routines use the priv2 run control register.
> >=20
> > Signed-off-by: Masato Noguchi <Masato.Noguchi@jp.sony.com>
> > Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
One more thing, please send spufs related patches to Jeremy instead
of to me. I'm happy to give advice on the patch contents, but
since Jeremy has taken over maintainership of spufs, merging a
patch is his decision in the end.
Arnd <><
^ permalink raw reply
* Re: [patch 2/2] Cell: Wrap master run control bit
From: Arnd Bergmann @ 2007-09-04 22:42 UTC (permalink / raw)
To: Geoff Levand; +Cc: Masato Noguchi, linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <46DD4783.9040103@am.sony.com>
On Tuesday 04 September 2007, Geoff Levand wrote:
>
> From: Masato Noguchi <Masato.Noguchi@jp.sony.com>
>
> Add platform specific SPU run control routines.
>
> The current spufs_run_spu() implementation uses the SPU master
> run control bit (MFC_SR1[S]) to control SPE execution, but the
> PS3 hypervisor does not support the use of this feature. This
> change adds run control wrapper routines. The bare metal
> routines use the master run control bit, and the PS3 specific
> routines use the priv2 run control register.
>
> Signed-off-by: Masato Noguchi <Masato.Noguchi@jp.sony.com>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Hmm, ok. Since I don't think we'll get to do the right solution
(unmapping the ps registers on the ps3) that soon, doing this
patch is at least better than the current situation where we
end up with an oops every time we leave spu_run.
It would probably be good to mention the remaining problem
with the current approach in the changelog and as a comment
in the ps3 specific functions.
> @@ -178,6 +179,8 @@ struct spu_management_ops {
> int (*enumerate_spus)(int (*fn)(void *data));
> int (*create_spu)(struct spu *spu, void *data);
> int (*destroy_spu)(struct spu *spu);
> + int (*enable_spu)(struct spu_context *ctx);
> + int (*disable_spu)(struct spu_context *ctx);
> int (*init_affinity)(void);
> };
Also, I think you should make the return type of the callback
'void' since the result is not used anywhere.
Arnd <><
^ permalink raw reply
* Re: [patch 1/2] PS3: Clear SPU Class 0 interrupts in handler
From: Arnd Bergmann @ 2007-09-04 22:50 UTC (permalink / raw)
To: Geoff Levand
Cc: Noguchi, Masato, linuxppc-dev@ozlabs.org, Paul Mackerras,
Jeremy Kerr
In-Reply-To: <46DD4777.8050402@am.sony.com>
On Tuesday 04 September 2007, Geoff Levand wrote:
> From: Masato Noguchi <Masato.Noguchi@jp.sony.com>
>=20
> Fix a bug that causes the PS3 to hang on the SPU Class 0 interrupt.
>=20
> The Cell BE Architecture spec states that the SPU MFC Class 0 interrupt
> is delivered as a pulse. =C2=A0The current spu interrupt handler assumes =
this
> behavior and does not clear the interrupt status.
>=20
> The PS3 hypervisor visualizes all SPU interrupts as level, and on return
> from the interrupt handler the hypervisor will deliver a new virtual
> interrupt for any unmasked interrupts which for which the status has not
> been cleared. =C2=A0This fix clears the interrupt status in the interrupt
> handler.
Right, we have this one in the sdk3.0/2.6.22-arnd2 kernel since I pulled
in all of the ps3-linux tree, so it was already part of our testing,
and the explanation makes sense, so we should certainly have it
upstream.
Jeremy, please add this to your patch queue.
> Signed-off-by: Masato Noguchi <Masato.Noguchi@jp.sony.com>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
^ permalink raw reply
* [POWERPC] flags as passed to spin_*_irqsave() should be unsigned long.
From: Tony Breeds @ 2007-09-05 0:23 UTC (permalink / raw)
To: LinuxPPC-dev, Olof Johansson
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
Found trying to build a -rt kernel, which has a BUILD_BUG_ON(), in this
caswe.
drivers/net/pasemi_mac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: working/drivers/net/pasemi_mac.c
===================================================================
--- working.orig/drivers/net/pasemi_mac.c 2007-09-04 16:46:40.000000000 +1000
+++ working/drivers/net/pasemi_mac.c 2007-09-04 16:47:01.000000000 +1000
@@ -524,7 +524,7 @@ static int pasemi_mac_clean_tx(struct pa
struct pasemi_mac_buffer *info;
struct pas_dma_xct_descr *dp;
int start, count;
- int flags;
+ unsigned long flags;
spin_lock_irqsave(&mac->tx->lock, flags);
@@ -950,7 +950,7 @@ static int pasemi_mac_start_tx(struct sk
struct pas_dma_xct_descr *dp;
u64 dflags;
dma_addr_t map;
- int flags;
+ unsigned long flags;
dflags = XCT_MACTX_O | XCT_MACTX_ST | XCT_MACTX_SS | XCT_MACTX_CRC_PAD;
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [POWERPC] flags as passed to spin_*_irqsave() should be unsigned long.
From: Olof Johansson @ 2007-09-04 23:39 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev
In-Reply-To: <20070905002314.GT10345@bakeyournoodle.com>
On Wed, Sep 05, 2007 at 10:23:14AM +1000, Tony Breeds wrote:
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
>
> ---
> Found trying to build a -rt kernel, which has a BUILD_BUG_ON(), in this
> caswe.
Thanks, applied. I'll batch it up with the next set of updates to jgarzik.
-Olof
^ permalink raw reply
* Re: "atomic" 64-bit math on 32-bit ppc's?
From: David Gibson @ 2007-09-05 1:04 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev
In-Reply-To: <46DD500B.4020207@genesi-usa.com>
On Tue, Sep 04, 2007 at 01:31:07PM +0100, Matt Sealey wrote:
>
> Gabriel Paubert wrote:
> > On Tue, Sep 04, 2007 at 12:09:22PM +0100, Matt Sealey wrote:
> >> Hi guys,
> >>
> >> The Solaris PPC code drop included most of these functions for 32-bit ops on
> >> 32-bit PPC architectures but the 64-bit operations are not present. What I
> >> a not clear on is the operation of lwarx and stwcx. and if they will work if
> >> you are doing operations on two words at a time.
> >
> > No. There is a single reservation for a single word.
>
> This is what I gathered from the programming environments manual at least.
>
> > the 64 bit operations inside a spinlock on PPC32, and then select the
> > number /location of spinlock(s) based on your needs, from one global
> > per machine to one per 64 bit variable if you find excessive contention.
>
> Okay that makes sense, but it would have to be a super global big lock,
> I don't think the code is there in ZFS to give every 64-bit variable it's
> own dedicated spinlock (kind of an overhaul) and I'm trying to be fast..
These aren't the only two options. You could use a hashed array of
locks, based on the address where you're doing the atomic operation.
--
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] Walnut board support
From: David Gibson @ 2007-09-05 1:09 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070904073741.1adab0ba@weaponx.rchland.ibm.com>
On Tue, Sep 04, 2007 at 07:37:41AM -0500, Josh Boyer wrote:
> On Sun, 02 Sep 2007 08:59:06 -0500
> Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
>
> > On Mon, 2007-09-03 at 11:11 +1000, David Gibson wrote:
> > > On Fri, Aug 31, 2007 at 03:04:54PM -0500, Josh Boyer wrote:
> > > > Board support for the PPC405 Walnut evaluation board
> > > >
> > > > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> > >
> > > [snip]
> > > > --- linux-2.6.orig/arch/powerpc/platforms/40x/Kconfig
> > > > +++ linux-2.6/arch/powerpc/platforms/40x/Kconfig
> > > > @@ -53,13 +53,13 @@
> > > > # help
> > > > # This option enables support for the IBM PPC405GPr evaluation board.
> > > >
> > > > -#config WALNUT
> > > > -# bool "Walnut"
> > > > -# depends on 40x
> > > > -# default y
> > > > -# select 405GP
> > > > -# help
> > > > -# This option enables support for the IBM PPC405GP evaluation board.
> > > > +config WALNUT
> > > > + bool "Walnut"
> > > > + depends on 40x
> > > > + default y
> > > > + select 405GP
> > > > + help
> > > > + This option enables support for the IBM PPC405GP evaluation board.
> > >
> > > Surely this needs WANT_DEVICE_TREE, too.
> >
> > Yes, will be fixed.
>
> Er, actually no it won't. It doesn't need to be selected here, as 40x
> in arch/powerpc/platforms/Kconfig.cputype already selects
> WANT_DEVICE_TREE. Same thing that ebony and bamboo do for 44x.
Oh, yes, so it does, sorry. Though we may need to change that if
anyone goes and puts a real OF implementation on some 44x board.
--
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 2/6] cuimage for Bamboo board
From: David Gibson @ 2007-09-05 1:10 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1188826931.3772.11.camel@localhost.localdomain>
On Mon, Sep 03, 2007 at 08:42:11AM -0500, Josh Boyer wrote:
> On Mon, 2007-09-03 at 11:01 +1000, David Gibson wrote:
> > On Fri, Aug 31, 2007 at 03:04:51PM -0500, Josh Boyer wrote:
> > > Add a cuboot wrapper for the Bamboo board. This also removes some obsoleted
> > > linker declarations that have been moved into ops.h
> > >
> > > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> >
> > [snip]
> > > --- linux-2.6.orig/arch/powerpc/boot/bamboo.c
> > > +++ linux-2.6/arch/powerpc/boot/bamboo.c
> > > @@ -24,8 +24,7 @@
> > > #include "4xx.h"
> > > #include "44x.h"
> > >
> > > -extern char _dtb_start[];
> > > -extern char _dtb_end[];
> > > +static u8 *bamboo_mac0, *bamboo_mac1;
> > >
> > > static void bamboo_fixups(void)
> > > {
> > > @@ -34,12 +33,16 @@ static void bamboo_fixups(void)
> > > ibm440ep_fixup_clocks(sysclk, 11059200);
> > > ibm4xx_fixup_memsize();
> > > ibm4xx_quiesce_eth((u32 *)0xef600e00, (u32 *)0xef600f00);
> > > + if (bamboo_mac0 && bamboo_mac1)
> > > + dt_fixup_mac_addresses(bamboo_mac0, bamboo_mac1);
> >
> > Bit ugly that you only set the MAC address for any ethernet if they're
> > supplied for every ethernet.
>
> Good point. Will fix.
>
> > > simple_alloc_init(_end, avail_ram, 32, 64);
> > > - bamboo_init();
> > > + bamboo_init(NULL, NULL);
> >
> > There must surely be a way to get the MAC addresses out of OpenBIOS...
>
> Probably. I just need to find out where they are stored.
It's not buried somewhere in the arch/ppc/boot code?
--
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: disable interrput under ppc?
From: Wang, Baojun @ 2007-09-05 2:00 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <388931546.05165@lzu.edu.cn>
[-- Attachment #1: Type: text/plain, Size: 3778 bytes --]
On Wednesday 05 September 2007, you wrote:
> On Tue, 4 Sep 2007 13:24:33 -0500
>
> Scott Wood <scottwood@freescale.com> wrote:
> > On Tue, Sep 04, 2007 at 10:44:14AM +0800, Wang, Baojun wrote:
> > > hi, list
> > >
> > > How can I disable interrput like `cli' in x86?
> >
> > local_irq_disable().
> >
> > > I want the following code freeze the box but it doesn't, $MSR is
> > > altered however the box is still alive, how can I freeze the box like
> > > `cli' in x86? Thanks very much!
> >
> > Disabling interrupts doesn't freeze the machine by itself -- it depends
> > on what you do afterwards, which you didn't show.
I need to check whether the interrupt have been disabled already, so I'm
expected after local_irq_disable() ( __asm__ __volatile__ ("wrteei
0": : :"memory) ), the machine is dead but it doesn't.
> If you're using a BOOKE variant, there is a way to use the DBCR0
> register to set debug wait enable or something to basically hang the
> CPU until something external clears that bit. But why you would want
> to do that, I have no idea.
Sorry, I just want to check whether disable_irq/enable_irq is functioning.
> josh
I'm not really getting confused about the following code:
// Executing all pending events
while ((event = get_next_set_bit_and_clear
(pending, xm_root_domain -> events -> masked_events)) != -1) {
// An event pending when there is not any handler installed
// catching it??? it must be an error
//assert (xm_root_domain -> event_handler [event]);
if (!xm_root_domain -> events -> event_handler [event]) continue;
// Before executing an event handler, events' flag is disabled
// and the event is masked
printk(KERN_EMERG"sync_root_events: looping!\n");
set_bit (xm_root_domain -> events -> masked_events, event);
printk(KERN_EMERG"sync_root_events: looping 2!\n");
disable_events_flag (xm_root_domain);
printk(KERN_EMERG"sync_root_events: looping 3!\n");
printk(KERN_EMERG"hw_irq_disabled?: %d\n", hw_irq_disabled());
hw_enable_irq ();
printk(KERN_EMERG"sync_root_events: looping 4!\n");
// Here, the event handler is executed always
// with the same conditions, that is, event flag disabled
// and the executed event masked as well
(*xm_root_domain -> events -> event_handler[event])
(event, regs);
printk(KERN_EMERG"sync_root_events: looping 5!\n");
hw_disable_irq();
printk(KERN_EMERG"sync_root_events: looping 6!\n");
// Events flag is automatically enabled (iret emulation)
enable_events_flag (xm_root_domain);
}
hw_enable_irq() and hw_disable_irq() is exactly the same as
local_irq_enable()/local_irq_disable(), but the output shows while running
hw_eable_irq() (at that point irq is disabled), the rest of the code is
blocked, and I don't know why:
output:
[ 172.049381] sync_root_events: looping!
[ 172.053159] sync_root_events: looping 2!
[ 172.057094] sync_root_events: looping 3!
[ 172.061027] hw_irq_disabled?: 1
[ 172.997338] sync_root_events: looping!
[ 173.001095] sync_root_events: looping 2!
[ 173.005028] sync_root_events: looping 3!
[ 173.008961] hw_irq_disabled?: 1
I'm sorry If I'm asking a bad question, I'm not familiar with ppc/kernel
programming at this moment. Great thanks to Scott and josh for your reply.
Regards,
Wang
--
Wang, Baojun Lanzhou University
Distributed & Embedded System Lab http://dslab.lzu.edu.cn
School of Information Science and Engeneering wangbj@lzu.edu.cn
Tianshui South Road 222. Lanzhou 730000 .P.R.China
Tel:+86-931-8912025 Fax:+86-931-8912022
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch 3/6] Walnut DTS
From: David Gibson @ 2007-09-05 2:36 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070904074203.748030c7@weaponx.rchland.ibm.com>
On Tue, Sep 04, 2007 at 07:42:03AM -0500, Josh Boyer wrote:
> On Sun, 02 Sep 2007 08:59:44 -0500
> Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
[snip]
> > > > + POB0: opb {
> > > > + compatible = "ibm,opb";
> > >
> > > Need an opb-405gp here, too.
> >
> > Yep.
>
> Fixed.
>
> > > > + #address-cells = <1>;
> > > > + #size-cells = <1>;
> > > > + ranges = <0 ef600000 a00000>;
> > >
> > > Hrm... something we ought to clarify is the interpretation of the
> > > POB0_BEAR register with respect to the bridge's ranges property. For
> > > 440 I think the BEAR will need to be interpreted as an OPB address,
> > > rather than a PLB address, but I'm not sure if that will work here
> > > with the limited ranges property you have.
> >
> > Ok, I'll look at this.
>
> The BEAR will still be interpreted as a PLB address here as far as I
> can see. The ranges spans the entire OPB space. Am I missing
> something?
Ah, sorry, my mistake. I thought the BEAR register would encode an
OPB address rather than a PLB address (and thus, be only 32-bits wide
on 440). In fact it appears it does encode a PLB address (and is
split into BEARH and BEARL registers on 440).
Hrm.. I'm still slightly uneasy though. In my Ebony device tree, the
POB's ranges exists to embed the 32-bit OPB space into the 64-bit PLB
space by tacking on a 0x1 in bits 32:35. In your 405gp ranges, you're
describing just the address range used by OPB peripherals
(0xef600000-0xf0000000) as residing at address 0 in OPB-space.
Since the ranges will still generate the right physical addresses, I
guess it doesn't matter. But I'm not sure it meets the principle of
least surprise - since I think the documentation generally talks as
though addresses on the 405 OPB bus are identical to addreses on the
PLB.
--
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: [RFC] AmigaOne device tree source v2
From: David Gibson @ 2007-09-05 2:48 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070904114945.303440@gmx.net>
On Tue, Sep 04, 2007 at 01:49:45PM +0200, Gerhard Pircher wrote:
>
> -------- Original-Nachricht --------
> > Datum: Tue, 4 Sep 2007 00:32:57 +0200
> > Von: Segher Boessenkool <segher@kernel.crashing.org>
> > An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
> > CC: linuxppc-dev@ozlabs.org, David Gibson <david@gibson.dropbear.id.au>
> > Betreff: Re: [RFC] AmigaOne device tree source v2
>
> > PCI memory space sits on the PCI bus, not on the PCI host bridge,
> > so is not part of "reg" but is part of "ranges" here, since it is
> > direct mapped into the host's address space.
> That's right, but what about this example here (from a Pegasos II):
>
> /proc/device-tree/pci@80000000:
> name "pci"
> linux,phandle 0fc59260 (264606304)
> bus-range 00000000 00000000
> pci-bridge-number 00000000
> reg 80000000 40000000
> 8259-interrupt-acknowledge f1000cb4
> ranges 01000000 00000000 00000000 fe000000 00000000 00010000
> 02000000 00000000 80000000 80000000 00000000 40000000
> clock-frequency 01fca055 (33333333)
> #size-cells 00000002
> #address-cells 00000003
> device_type "pci"
>
> AFAIU the reg property overlaps the ranges property for the PCI memory
> space from 0x80000000 to 0xC0000000 or the CPU address space at the
> same location!? Would be good to know, why it was defined like this.
That looks totally bogus. Unlike Segher, I think there are a few
cases where overlapping reg and ranges can make sense (PCI bridges
where config space is accessed indirectly via MMIO registers which lie
in the legacy ISA IO space is an example). But this doesn't look like
such a case - it just looks like whoever did the device tree
misunderstood the distinction between reg and ranges.
> > PCI legacy I/O is not direct mapped: there is no legacy I/O on a
> > PowerPC system bus. So, it can not be mentioned in the "ranges"
> > property, but the PHB registers used to access it should be shown
> > in the "reg" property. It could be a simple linear window (it
> > sounds like it is here?), but it could for example also be implemented
> > via an address/data register pair.
Err... huh? The legacy IO space is assigned a block of addresses in
3-word "OF-PCI-space by the PCI binding. When that is translated into
an MMIO range by the bridge, there's no reason that can't be encoded
into the ranges property.
> Yes, it is a simple linear address window. I'll remove its address range
> from the reg property.
>
> > The order of the "reg" entries depends on the exact model of PCI
> > bridge, so a device binding for it has to be written.
> Only the Pegasos I and the AmigaOne use this PCI bridge. I guess it should
> be enough to check for the board type, but a compatible property doesn't
> hurt.
The whole damn point of the device tree is to avoid using this kind of
non-local information "I know what the board type is over there, so it
must be this PCI bridge over here". The node should have a compatible
property which is sufficient to select the right bridge driver.
I think this is typically badly done at the moment, simply because PCI
has historically been set up by the platform code, rather than by a
"host bridge driver" in the mould of other drivers. I don't see that
changing real soon, but that doesn't mean we shouldn't at least put
enough information in the device tree to make it possible.
--
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
* Keep On Debugging You
From: Timur Tabi @ 2007-09-05 2:53 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 901 bytes --]
I wrote this last year in frustration with an out-of-order execution bug
I was trying to fix.
Keep On Debugging You
Sung to the tune of REO Speedwagon's "Keep on Loving' You"
You should've seen by the opcodes in the queue, baby
There was something missin'
You should known by the registers, too, maybe
But you were too busy bitchin'
You stalled ahead
But you never fed
Instead my instructions
All ended up switchin'
And though I know all flushes
Still I don't remember
Cause it was stwu way before lwzu
And they're still together
And I meant every line I wrote
When I wrote them in order I meant
That I wanted them in order
And I'm gonna keep on debugging you
Cause it's the only thing I'm paid to do
I don't have time to sleep
I just want to keep on debugging you
(solo)
And I meant every line I wrote
When I wrote them in order I meant
That I wanted them in order
(chorus)
--
Timur Tabi
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3225 bytes --]
^ permalink raw reply
* Re: Document and implement an improved flash device binding
From: David Gibson @ 2007-09-05 2:59 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <143067874eed1b4ee9c75d5272bb5958@kernel.crashing.org>
On Mon, Sep 03, 2007 at 12:23:34PM +0200, Segher Boessenkool wrote:
> >+ j) CFI or JEDEC memory-mapped NOR flash
> >
> > Flash chips (Memory Technology Devices) are often used for solid
> >state
> > file systems on embedded devices.
>
> Well, almost everything has a NOR flash on it, not just
> embedded boards ;-)
Well, true.
> >+ - bank-width : Width (in bytes) of the flash bank. Equal to the
> >+ device width times the number of interleaved chips.
> >+ - device-width : (optional) Width of a single flash chip. If
> >+ omitted, assumed to be equal to 'bank-width'.
>
> Let's have bank-width optional instead, it's more natural
> that way for the common case of just one chip. Or, you can
> say that either is optional.
No, I'm disinclined to do that since bank-width is the primary bit of
information that the driver needs.
> >+ flash@ff000000 {
> >+ compatible = "amd,am29lv128ml", "cfi-flash";
> >+ reg = <ff000000 01000000>;
> >+ bank-width = <4>;
>
> This is an 8/16-bit part, you need a device-width ;-)
Oops - that comes from grabbing a random flash name, combining it with
other example fragments without checking the details. Added a
device-width.
> Need #address-cells here for the child nodes:
Oops. Added #a and #s.
> >+ fs@0 {
> >+ reg = <0 f80000>;
> >+ };
>
> [big snip]
>
> >+ OpenBIOS@0 {
>
> This show immediately why node name = partition name won't
> work out. You're not supposed to start a node name with a
> capital like this.
According to which?
Nonetheless, I've added a label property, and used it for the ebony
tree.
--
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
* Please pull from 'for-2.6.24' branch
From: Olof Johansson @ 2007-09-05 2:07 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Paul,
Please pull from 'for-2.6.24' branch of
master.kernel.org:/pub/scm/linux/kernel/git/olof/pasemi.git for-2.6.24
to receive the following updates:
arch/powerpc/kernel/sysfs.c | 60 +++++++++++++++++
arch/powerpc/platforms/pasemi/idle.c | 8 ++
arch/powerpc/platforms/pasemi/pasemi.h | 4 -
arch/powerpc/platforms/pasemi/pci.c | 71 ++++++++++++++++++++
arch/powerpc/platforms/pasemi/setup.c | 112 +++++++++++++++++++++++++++++++--
include/asm-powerpc/reg.h | 48 ++++++++++----
6 files changed, 281 insertions(+), 22 deletions(-)
Olof Johansson (5):
[POWERPC] pasemi: add pasemi_pci_getcfgaddr()
[POWERPC] pasemi: Add workaround for erratum 5945
[POWERPC] pasemi: Export more SPRs to sysfs when CONFIG_DEBUG_KERNEL=y
[POWERPC] pasemi: Print more information at machine check
[POWERPC] pasemi: Move pasemi_idle_init() to late_initcall()
Patches also posted as replies to this email for general info.
Thanks,
Olof
^ permalink raw reply
* Re: [patch 5/6] Walnut board support
From: David Gibson @ 2007-09-05 3:01 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070831200643.514442000@linux.vnet.ibm.com>
On Fri, Aug 31, 2007 at 03:04:54PM -0500, Josh Boyer wrote:
> Board support for the PPC405 Walnut evaluation board
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
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
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