* [PATCH] ppc annotations: i2c-mpc
From: Al Viro @ 2005-04-26 1:10 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Usual iomem annotations and NULL noise removal.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
----
diff -urN RC12-rc3-mpsc/drivers/i2c/busses/i2c-mpc.c RC12-rc3-i2c-mpc/drivers/i2c/busses/i2c-mpc.c
--- RC12-rc3-mpsc/drivers/i2c/busses/i2c-mpc.c Wed Apr 20 21:25:33 2005
+++ RC12-rc3-i2c-mpc/drivers/i2c/busses/i2c-mpc.c Mon Apr 25 19:53:08 2005
@@ -55,7 +55,7 @@
#define CSR_RXAK 0x01
struct mpc_i2c {
- char *base;
+ void __iomem *base;
u32 interrupt;
wait_queue_head_t queue;
struct i2c_adapter adap;
@@ -444,7 +444,7 @@
fail_add:
if (i2c->irq != 0)
- free_irq(i2c->irq, 0);
+ free_irq(i2c->irq, NULL);
fail_irq:
iounmap(i2c->base);
fail_map:
^ permalink raw reply
* [PATCH] ppc annotations: mpsc
From: Al Viro @ 2005-04-26 1:10 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Usual iomem annotations + NULL noise removal.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
----
diff -urN RC12-rc3-sent/drivers/serial/mpsc.c RC12-rc3-mpsc/drivers/serial/mpsc.c
--- RC12-rc3-sent/drivers/serial/mpsc.c Fri Mar 11 15:54:53 2005
+++ RC12-rc3-mpsc/drivers/serial/mpsc.c Mon Apr 25 19:53:06 2005
@@ -329,8 +329,8 @@
mpsc_sdma_cmd(pi, SDMA_SDCM_AR | SDMA_SDCM_AT);
/* Clear the SDMA current and first TX and RX pointers */
- mpsc_sdma_set_tx_ring(pi, 0);
- mpsc_sdma_set_rx_ring(pi, 0);
+ mpsc_sdma_set_tx_ring(pi, NULL);
+ mpsc_sdma_set_rx_ring(pi, NULL);
/* Disable interrupts */
mpsc_sdma_intr_mask(pi, 0xf);
@@ -1540,8 +1540,8 @@
MPSC_SDMA_INTR_REG_BLOCK_SIZE);
}
- mpsc_shared_regs.mpsc_routing_base = 0;
- mpsc_shared_regs.sdma_intr_base = 0;
+ mpsc_shared_regs.mpsc_routing_base = NULL;
+ mpsc_shared_regs.sdma_intr_base = NULL;
mpsc_shared_regs.mpsc_routing_base_p = 0;
mpsc_shared_regs.sdma_intr_base_p = 0;
@@ -1678,9 +1678,9 @@
release_mem_region(pi->brg_base_p, MPSC_BRG_REG_BLOCK_SIZE);
}
- pi->mpsc_base = 0;
- pi->sdma_base = 0;
- pi->brg_base = 0;
+ pi->mpsc_base = NULL;
+ pi->sdma_base = NULL;
+ pi->brg_base = NULL;
pi->mpsc_base_p = 0;
pi->sdma_base_p = 0;
diff -urN RC12-rc3-sent/drivers/serial/mpsc.h RC12-rc3-mpsc/drivers/serial/mpsc.h
--- RC12-rc3-sent/drivers/serial/mpsc.h Fri Mar 11 15:54:53 2005
+++ RC12-rc3-mpsc/drivers/serial/mpsc.h Mon Apr 25 19:53:06 2005
@@ -83,8 +83,8 @@
phys_addr_t mpsc_routing_base_p;
phys_addr_t sdma_intr_base_p;
- void *mpsc_routing_base;
- void *sdma_intr_base;
+ void __iomem *mpsc_routing_base;
+ void __iomem *sdma_intr_base;
u32 MPSC_MRR_m;
u32 MPSC_RCRR_m;
@@ -120,9 +120,9 @@
phys_addr_t brg_base_p;
/* Virtual addresses of various blocks of registers (from platform) */
- void *mpsc_base;
- void *sdma_base;
- void *brg_base;
+ void __iomem *mpsc_base;
+ void __iomem *sdma_base;
+ void __iomem *brg_base;
/* Descriptor ring and buffer allocations */
void *dma_region;
^ permalink raw reply
* 8xx SMC break handling
From: Robin Gilks @ 2005-04-26 2:57 UTC (permalink / raw)
To: ppc embedded list
Greeting
Can anyone tell me if the break handling of an async SMC port will
report a break immediately or whether it only reports it on the receipt
of a valid character (which is what I'm seeing at present). As usual the
UM is a bit dry in this area!!
Maybe I've not enabled all that I need to in the SMC setup (based on
2.4.22 Denx kernel UART driver).
Thanks...
--
Robin Gilks
Senior Design Engineer Phone: (+64)(3) 357 1569
Tait Electronics Fax : (+64)(3) 359 4632
PO Box 1645 Christchurch Email : robin.gilks@tait.co.nz
New Zealand
=======================================================================
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================
^ permalink raw reply
* Re: PowerPC + SMP
From: Benjamin Herrenschmidt @ 2005-04-26 3:36 UTC (permalink / raw)
To: Stuart Yoder; +Cc: linuxppc-dev list
In-Reply-To: <052701c549db$4fb20760$2f010a0a@foundation.com>
On Mon, 2005-04-25 at 16:11 -0500, Stuart Yoder wrote:
> Hi.
>
> I am trying to figure out where in the PowerPC kernel the HID1
> register is updated to enable bits dealing with cache coherency in an
> SMP system. Grepping through the arch/ppc source does not reveal
> much.
>
> I have two 7447A processors and somewhere the ABE and SYNCBE bits need
> to be turned on to enable cache coherency. Is supposed to happen in
> the bootloader prior to the kernel running??
It's usually expected to happen in the firmware yes, though the kernel
does some of it's own 'fixups' (look at setup_cpu_6xx.S)
Ben.
^ permalink raw reply
* kernel BUG at page_alloc.c:225 on PPC440GP
From: Glenn Burkhardt @ 2005-04-26 12:28 UTC (permalink / raw)
To: mlei30; +Cc: linuxppc-embedded
I know it's been a year and a half since you submitted this report to the
mailing list, but was this problem ever resolved? I think I'm seeing
something similar in the 2.4.23 kernel.
Thanks!
^ permalink raw reply
* gdbserver problem on powerpc.
From: Surendra Yadav @ 2005-04-26 13:05 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I downloaded gdb-6.0 and cross compiled gdbserver for powerpc platform.
When gdbserver I tried to run gdbserver it gives "No such file or
directory".
But I can see this file is present in the bin directory. Even I tried
precompiled binary from ELDK but that also does not work and gives the same
message. Can any one suggest what is the wrong?
I gave the command #gdbserver 192.168.10.243:2345 hello .
Alternatively I tried following command from the bin directory. hello
program is also in the bin the dir. But it won't work.
#./gdbserver 192.168.10.243:2345 ./hello
Regards,
Surendra
^ permalink raw reply
* Booting linux for 405EP --> mem_pieces_find( ) nightmare
From: Garcia Jérémie @ 2005-04-26 13:27 UTC (permalink / raw)
To: linuxppc-dev
Hi everybody,
I'm tryin to adapt a linux LSP deom Montavista (the one for the 405EP =
evaluation board) to a proprietary hardware using a 405EP.
Unfortunately, it is not as easy as I thought. Here is my problem:
To load our linux image (zImage.treeboot), we use the "VxWorks bootrom" =
bootloader which download the image via tftp.
That works well except the fact that in the LSP, linux tried to get a =
board info structure in flash memory at an address where we have =
nothing. So we replace this behavior in "embed_config.c" with the =
following lines (note: I had to re-code the strcpy although there is the =
#include<string.h> because it cannot find the reference at the link =
level... why???):
/* We use VxWorks bootrom, so we have to create ourselves the boot info =
structure */
bd_t my_bd_t;
=20
char * my_strcpy(char * dest,const char *src)
{
char *tmp =3D dest;
while ((*dest++ =3D *src++) !=3D '\0')
/* nothing */;
return tmp;
}
bd_t * get_board_info(void)
{
my_strcpy(my_bd_t.bi_s_version,"v1"); /* Version of =
this structure */
my_strcpy(my_bd_t.bi_r_version,"bootrom linux 1.0") ; /* Version of =
the IBM ROM */
my_bd_t.bi_memsize =3D 16000000 ; /* DRAM =
installed, in bytes */
my_strcpy(my_bd_t.bi_enetaddr[0],"00:01:73:01:C1:3B"); /* Local =
Ethernet MAC address */
my_strcpy(my_bd_t.bi_enetaddr[1],"00:01:73:01:C1:3C"); /* Local =
Ethernet MAC address */
my_bd_t.bi_intfreq =3D 200000000 ; /* Processor speed, in Hz =
*/
my_bd_t.bi_busfreq =3D 100000000 ; /* PLB Bus speed, in Hz =
*/
my_bd_t.bi_pllouta_freq =3D 800000000 ; /* PLL OUTA speed, in Hz =
*/
my_bd_t.bi_opb_busfreq =3D 50000000 ; /* OPB Bus speed, in Hz =
*/
my_bd_t.bi_iic_fast[0] =3D 0 ; /* Use fast i2c mode =
*/
/* We return the address of our global structure */
return &my_bd_t;
}
void embed_config(bd_t **bdp)
{
u_char *cp;
int i;
bd_t *bd, *treeboot_bd;
bd =3D &bdinfo;
*bdp =3D bd;
if ((treeboot_bd =3D get_board_info()) !=3D NULL)
memcpy(bd, treeboot_bd, sizeof(bd_t));
else
{
/* Give default values for our board info structure */
bd->bi_memsize =3D 16 * 1024 * 1024;
cp =3D (u_char *)def_enet_addr;
for (i=3D0; i<6; i++)
{
/* I should probably put different ones here,
* hopefully only one is used.
*/
bd->BD_EMAC_ADDR(0,i) =3D *cp;
}
bd->bi_intfreq =3D 200000000;
bd->bi_busfreq =3D 500000000;
}
/* Yeah, this look weird, but on Redwood 4 they are
* different object in the structure. Sincr Redwwood 5
* and Redwood 6 use OpenBIOS, it requires a special value.
*/
timebase_period_ns =3D 1000000000 / bd->bi_tbfreq;
}
That done, the linux booting process continues till the "MMU_init()" =
function, that drives me to the panic() function when it tries to do the =
mem_pieces_find() (see below).
/*
* Scan a region for a piece of a given size with the required =
alignment.
*/
void __init *
mem_pieces_find(unsigned int size, unsigned int align)
{
int i;
unsigned a, e;
struct mem_pieces *mp =3D &phys_avail;
for (i =3D 0; i < mp->n_regions; ++i) {
a =3D mp->regions[i].address;
e =3D a + mp->regions[i].size;
a =3D (a + align - 1) & -align;
if (a + size <=3D e) {
mem_pieces_remove(mp, a, size, 1);
return (void *) __va(a);
}
}
panic("Couldn't find %u bytes at %u alignment\n", size, align); =
/* <-- HERE WE GO !!.... */
=09
return NULL;
}
I have no clue on what's happening (I'm a newbie in kernel sources =
dev...). Could you give me a tip please cause I really need help on =
that.
Tks a lot
J=E9r=E9mie \\ (=B0.=B0) //~ ~ ~ HELP ~ ~ ~ \\ (=B0.=B0) //
^ permalink raw reply
* Re: gdbserver problem on powerpc.
From: Jaap-Jan Boor @ 2005-04-26 13:31 UTC (permalink / raw)
To: surendra.yadav; +Cc: linuxppc-dev
In-Reply-To: <BPEMKMADCCCPHPEDDKOOCEDLCEAA.surendra.yadav@softdel.com>
Hi surendra,
You might miss one or all libraries on your target? what is:
ldd gdbserver
saying when you try this on your target?
Jaap-Jan
On 26-apr-05, at 15:05, Surendra Yadav wrote:
> Hi,
>
> I downloaded gdb-6.0 and cross compiled gdbserver for powerpc platform.
>
> When gdbserver I tried to run gdbserver it gives "No such file or
> directory".
> But I can see this file is present in the bin directory. Even I tried
> precompiled binary from ELDK but that also does not work and gives the
> same
> message. Can any one suggest what is the wrong?
>
> I gave the command #gdbserver 192.168.10.243:2345 hello .
>
> Alternatively I tried following command from the bin directory. hello
> program is also in the bin the dir. But it won't work.
>
> #./gdbserver 192.168.10.243:2345 ./hello
>
> Regards,
> Surendra
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: gdbserver problem on powerpc.
From: Wolfgang Denk @ 2005-04-26 14:38 UTC (permalink / raw)
To: surendra.yadav; +Cc: linuxppc-dev
In-Reply-To: <BPEMKMADCCCPHPEDDKOOCEDLCEAA.surendra.yadav@softdel.com>
In message <BPEMKMADCCCPHPEDDKOOCEDLCEAA.surendra.yadav@softdel.com> you wrote:
>
> I downloaded gdb-6.0 and cross compiled gdbserver for powerpc platform.
>
> When gdbserver I tried to run gdbserver it gives "No such file or
> directory".
Did you link gdbserver statically, or are you using shared libraries?
Is any other application using the same libraries working on your
target?
> But I can see this file is present in the bin directory. Even I tried
> precompiled binary from ELDK but that also does not work and gives the same
> message. Can any one suggest what is the wrong?
The ELDK's gdbserver is dynamically linked:
-> ppc_8xx-ldd /opt/eldk/ppc_8xx/usr/bin/gdbserver
libthread_db.so.1 => /opt/eldk-3.1/ppc_8xx/lib/libthread_db.so.1
libc.so.6 => /opt/eldk-3.1/ppc_8xx/lib/libc.so.6
ld.so.1 => /opt/eldk-3.1/ppc_8xx/lib/ld.so.1
Make sure to include the required libraries and /lib/ld.so.1 in your
target filesystem.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
CONSUMER NOTICE: Because of the "Uncertainty Principle," It Is
Impossible for the Consumer to Find Out at the Same Time Both
Precisely Where This Product Is and How Fast It Is Moving.
^ permalink raw reply
* RE: PowerPC + SMP
From: Stuart Yoder @ 2005-04-26 14:54 UTC (permalink / raw)
To: 'linuxppc-dev list'
In-Reply-To: <1114486594.7183.12.camel@gaston>
Thanks Ben.
That raises a question though-- how can I know what assumptions the
kernel makes about the state of the CPU/system when it begins execution?
Is this clearly documented anywhere?
I am using U-boot on my SMP system and U-boot is not SMP aware. Do you
know of other open source bootloaders for Linux that would set up the
CPUs as the kernel expects.
Thanks,
Stuart Yoder
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> Sent: Monday, April 25, 2005 10:37 PM
> To: Stuart Yoder
> Cc: linuxppc-dev list
> Subject: Re: PowerPC + SMP
>
>
> On Mon, 2005-04-25 at 16:11 -0500, Stuart Yoder wrote:
> > Hi.
> >
> > I am trying to figure out where in the PowerPC kernel the HID1
> > register is updated to enable bits dealing with cache
> coherency in an
> > SMP system. Grepping through the arch/ppc source does not reveal
> > much.
> >
> > I have two 7447A processors and somewhere the ABE and
> SYNCBE bits need
> > to be turned on to enable cache coherency. Is supposed to
> happen in
> > the bootloader prior to the kernel running??
>
> It's usually expected to happen in the firmware yes, though
> the kernel does some of it's own 'fixups' (look at setup_cpu_6xx.S)
>
> Ben.
>
>
>
>
>
^ permalink raw reply
* Re: kernel BUG at page_alloc.c:225 on PPC440GP
From: Matt Porter @ 2005-04-26 16:47 UTC (permalink / raw)
To: Glenn Burkhardt; +Cc: mlei30, linuxppc-embedded
In-Reply-To: <200504260828.03985.glenn@aoi-industries.com>
On Tue, Apr 26, 2005 at 08:28:03AM -0400, Glenn Burkhardt wrote:
> I know it's been a year and a half since you submitted this report to the
> mailing list, but was this problem ever resolved? I think I'm seeing
> something similar in the 2.4.23 kernel.
Hi Glenn,
If you are seeing an oops with PPC440 on 2.4, please post the details.
-Matt
^ permalink raw reply
* Re: PowerPC + SMP
From: Wolfgang Denk @ 2005-04-26 17:35 UTC (permalink / raw)
To: Stuart Yoder; +Cc: 'linuxppc-dev list'
In-Reply-To: <054301c54a6f$d1cf82b0$2f010a0a@foundation.com>
In message <054301c54a6f$d1cf82b0$2f010a0a@foundation.com> you wrote:
>
> I am using U-boot on my SMP system and U-boot is not SMP aware. Do you
Strictly speaking this statement is wrong.
So far I am not aware of a port of U-Boot to a SMP system. If there
was such a port, and if it was properly done, then U-Boot probably
_were_ SMP aware.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Every program has at least one bug and can be shortened by at least
one instruction -- from which, by induction, one can deduce that
every program can be reduced to one instruction which doesn't work.
^ permalink raw reply
* [PATCH] ppc32: backport Book-E decrementer handling fix from 2.6
From: Eugene Surovegin @ 2005-04-26 18:48 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Paul Mackerras, linuxppc-embedded
Marcelo,
this is backport of Matt Porter's patch for Book-E decrementer
handling in timer_interrupt.
The fix has been in 2.6 from August but never made it to 2.4, and I
re-discovered this fix last week :)
Original Matt's post to linuxppc-dev with explanation can be found at:
http://ozlabs.org/pipermail/linuxppc-dev/2004-August/017458.html
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
===== arch/ppc/kernel/time.c 1.16 vs edited =====
--- 1.16/arch/ppc/kernel/time.c 2003-07-03 09:56:34 -07:00
+++ edited/arch/ppc/kernel/time.c 2005-04-26 11:37:58 -07:00
@@ -150,7 +150,7 @@
hardirq_enter(cpu);
- while ((next_dec = tb_ticks_per_jiffy - tb_delta(&jiffy_stamp)) < 0) {
+ while ((next_dec = tb_ticks_per_jiffy - tb_delta(&jiffy_stamp)) <= 0) {
jiffy_stamp += tb_ticks_per_jiffy;
if (!user_mode(regs))
ppc_do_profile(instruction_pointer(regs));
^ permalink raw reply
* RE: PowerPC + SMP
From: Stuart Yoder @ 2005-04-26 19:07 UTC (permalink / raw)
To: 'Wolfgang Denk'; +Cc: 'linuxppc-dev list'
In-Reply-To: <20050426173513.23FD1C1510@atlas.denx.de>
We've run into a few issues with U-boot, but they are not unsolveable--
-it doesn't provide an alternate execution path for the 2nd CPU when it
is started by the kernel
-U-boot needs to detect which CPU is executing
-U-boot on the 2nd CPU should not execute any platform/board specific
setup code-- this is stuff you only want to do once
-U-boot on the 2nd CPU cannot relocate itself to SDRAM because Linux is
already running there and assumes it owns all of memory
-it needs some way of getting to the Linux kernel entry point for
secondary CPUs
-it also appears that it should set up HID1 (other stuff??) for SMP
systems
Stuart
> -----Original Message-----
> From: Wolfgang Denk [mailto:wd@denx.de]
> Sent: Tuesday, April 26, 2005 12:35 PM
> To: Stuart Yoder
> Cc: 'linuxppc-dev list'
> Subject: Re: PowerPC + SMP
>
>
> In message <054301c54a6f$d1cf82b0$2f010a0a@foundation.com> you wrote:
> >
> > I am using U-boot on my SMP system and U-boot is not SMP aware. Do
> > you
>
> Strictly speaking this statement is wrong.
>
> So far I am not aware of a port of U-Boot to a SMP system.
> If there was such a port, and if it was properly done,
> then U-Boot probably _were_ SMP aware.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> wd@denx.de Every program has at least one bug and can be
> shortened by at least one instruction -- from which,
> by induction, one can deduce that every program can be
> reduced to one instruction which doesn't work.
>
>
>
^ permalink raw reply
* RE: PowerPC + SMP
From: Stuart Yoder @ 2005-04-26 19:16 UTC (permalink / raw)
To: 'Kumar Gala'; +Cc: linuxppc-embedded
In-Reply-To: <9380e411aa15fa62ab142301af963314@freescale.com>
Thanks Kumar.
How can I know what assumptions the kernel makes about the state of the
CPU/system when it begins execution? Is this clearly documented
anywhere?
Do you know of open source bootloaders for Linux that would demonstrate
how to set up the CPUs as the Linux kernel expects.
Thanks,
Stuart
> -----Original Message-----
> From: Kumar Gala [mailto:kumar.gala@freescale.com]=20
> Sent: Monday, April 25, 2005 4:40 PM
> To: Stuart Yoder
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: PowerPC + SMP
>=20
>=20
> On Apr 25, 2005, at 4:10 PM, Stuart Yoder wrote:
>=20
> > Hi.
> > =A0
> > I am trying to figure out where in the PowerPC kernel the HID1
> > register is updated to enable bits dealing with cache=20
> coherency in an=20
> > SMP system.=A0=A0 Grepping through the arch/ppc source does not =
reveal=20
> > much.
> > =A0
> > I have=A0two 7447A processors and somewhere the ABE and SYNCBE bits =
in
> > HID1=A0need to be turned on to enable cache coherency.=A0=A0 Is=20
> supposed to=20
> > happen in the bootloader prior to the kernel running??
>=20
> The expectation is that the bootloader normally handles such things.
>=20
> - kumar
>=20
>=20
>=20
>=20
^ permalink raw reply
* [RFC] [PATCH] ppc32: workaround for spurious IRQs on PQ2
From: Eugene Surovegin @ 2005-04-26 19:21 UTC (permalink / raw)
To: linuxppc-embedded
Hi!
There is a problem with big amount of spurious IRQs on 8248-based
design I'm working on.
I observed this problem with 2.4.30 kernel, but it was reported to be
still present on 2.6 as well.
Traces show that spurious IRQ happens right after handle_IRQ_events()
enables external interrupts and _before_ even calling real IRQ
handler.
I fixed this problem by adding sync at the end of cpm2_mask_and_ack.
Using out_XXX macros for accessing SIU register doesn't seem to help.
Dan thinks there are some pipeline-related issues here, although I
failed to found any mentions of them in 8272 user manual.
Also, there is a possibility, that we need more explicit sync's in
cpm2_pic code.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
===== arch/ppc/syslib/cpm2_pic.c 1.11 vs edited =====
--- 1.11/arch/ppc/syslib/cpm2_pic.c 2005-03-31 02:59:05 -08:00
+++ edited/arch/ppc/syslib/cpm2_pic.c 2005-04-26 11:55:51 -07:00
@@ -90,6 +90,7 @@
ppc_cached_irq_mask[word] &= ~(1 << bit);
simr[word] = ppc_cached_irq_mask[word];
sipnr[word] = 1 << bit;
+ mb();
}
static void cpm2_end_irq(unsigned int irq_nr)
^ permalink raw reply
* Re: PowerPC + SMP
From: Kumar Gala @ 2005-04-26 19:23 UTC (permalink / raw)
To: Stuart Yoder; +Cc: linuxppc-embedded
In-Reply-To: <056601c54a94$6d0cae50$2f010a0a@foundation.com>
On Apr 26, 2005, at 2:16 PM, Stuart Yoder wrote:
> Thanks Kumar.
>
> How can I know what assumptions the kernel makes about the state of the
> CPU/system when it begins execution? Is this clearly documented
> anywhere?
Unfortunately this is something we dont have clearly documented today.
As they say the code is the documentation.
> Do you know of open source bootloaders for Linux that would demonstrate
> how to set up the CPUs as the Linux kernel expects.
No, maybe take a look at linuxbios, not sure if it does SMP or not.
However, I'm not aware of any open source PPC SMP bootloaders.
- kumar
^ permalink raw reply
* [PATCH] make gcc -O1 in fs/reiserfs optional
From: Olaf Hering @ 2005-04-26 21:10 UTC (permalink / raw)
To: Jeff Mahoney; +Cc: linuxppc-dev, reiserfs-dev
Jeff,
you added this EXTRA_CFLAGS= during 2.4 development, I think the broken
compiler was gcc 3.2 on SLES8. Can we turn this -O1 into a .config
option?
Signed-off-by: Olaf Hering <olh@suse.de>
Index: linux-2.6.12-rc3-olh/fs/reiserfs/Makefile
===================================================================
--- linux-2.6.12-rc3-olh.orig/fs/reiserfs/Makefile
+++ linux-2.6.12-rc3-olh/fs/reiserfs/Makefile
@@ -21,13 +21,7 @@ ifeq ($(CONFIG_REISERFS_FS_POSIX_ACL),y)
reiserfs-objs += xattr_acl.o
endif
-# gcc -O2 (the kernel default) is overaggressive on ppc32 when many inline
-# functions are used. This causes the compiler to advance the stack
-# pointer out of the available stack space, corrupting kernel space,
-# and causing a panic. Since this behavior only affects ppc32, this ifeq
-# will work around it. If any other architecture displays this behavior,
-# add it here.
-ifeq ($(CONFIG_PPC32),y)
+ifeq ($(CONFIG_REISERFS_CC_REDUCE_OPTIMZE),y)
EXTRA_CFLAGS := -O1
endif
Index: linux-2.6.12-rc3-olh/fs/Kconfig
===================================================================
--- linux-2.6.12-rc3-olh.orig/fs/Kconfig
+++ linux-2.6.12-rc3-olh/fs/Kconfig
@@ -186,6 +186,18 @@ config REISERFS_FS
If you like it, you can pay us to add new features to it that you
need, buy a support contract, or pay us to port it to another OS.
+config REISERFS_CC_REDUCE_OPTIMZE
+ bool "Reduce CC optimization level to workaround compiler bugs"
+ depends on PPC32
+ default n
+ help
+ gcc -O2 (the kernel default) is overaggressive on ppc32 when many inline
+ functions are used. This causes the compiler to advance the stack
+ pointer out of the available stack space, corrupting kernel space,
+ and causing a panic. Since this behavior only affects ppc32, this ifeq
+ will work around it. If any other architecture displays this behavior,
+ add it here.
+
config REISERFS_CHECK
bool "Enable reiserfs debug mode"
depends on REISERFS_FS
^ permalink raw reply
* Re: [PATCH] make gcc -O1 in fs/reiserfs optional
From: Jeff Mahoney @ 2005-04-26 21:46 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, reiserfs-dev
In-Reply-To: <20050426211019.GA11579@suse.de>
Olaf Hering wrote:
> Jeff,
>
> you added this EXTRA_CFLAGS= during 2.4 development, I think the broken
> compiler was gcc 3.2 on SLES8. Can we turn this -O1 into a .config
> option?
Hi Olaf -
Yeah, the initial problem was that the anti aliasing[*] code when -O2
was enabled was being way too cautious and ended up allocating something
like 6k on the stack in do_balance(). It was observable elsewhere, but
not so problematic.
My ppc box isn't booting right now. If you've verified that newer
versions of the compiler don't blow the stack in do_balance(), I'm not
opposed to it.
-Jeff
[*]: I think that's the right term - I'm not a compiler developer :)
--
Jeff Mahoney
SuSE Labs
^ permalink raw reply
* RE: PowerPC + SMP
From: Benjamin Herrenschmidt @ 2005-04-26 22:27 UTC (permalink / raw)
To: Stuart Yoder; +Cc: 'linuxppc-dev list'
In-Reply-To: <054301c54a6f$d1cf82b0$2f010a0a@foundation.com>
On Tue, 2005-04-26 at 09:54 -0500, Stuart Yoder wrote:
> Thanks Ben.
>
> That raises a question though-- how can I know what assumptions the
> kernel makes about the state of the CPU/system when it begins execution?
> Is this clearly documented anywhere?
>
> I am using U-boot on my SMP system and U-boot is not SMP aware. Do you
> know of other open source bootloaders for Linux that would set up the
> CPUs as the kernel expects.
No, it's up to you to configure the CPU properly. I'm surprised that
uBoot doesn't set it up properly though, but then, when you bringup a
board, you rarely use a bootloader like that "as-is" :)
In general, the kernel except the CPU to be in working condition, which
I consider meanings having necessary HID bits set for proper coherency
etc... on an SMP system :)
Ben.
^ permalink raw reply
* RE: PowerPC + SMP
From: Paul Mackerras @ 2005-04-26 23:04 UTC (permalink / raw)
To: Stuart Yoder; +Cc: 'linuxppc-dev list'
In-Reply-To: <054301c54a6f$d1cf82b0$2f010a0a@foundation.com>
Stuart Yoder writes:
> That raises a question though-- how can I know what assumptions the
> kernel makes about the state of the CPU/system when it begins execution?
> Is this clearly documented anywhere?
In general the kernel assumes that firmware has set up the HID
registers, caches, northbridge, memory controller, memory, etc., in a
suitable state for the machine to run at full speed. There is code to
set and clear various HID bits, depending on the specific cpu model -
look for the __setup_cpu_* functions in arch/ppc/kernel/*.S. I guess
we could add code to set ABE and SYNCBE on 7447A processors on SMP
systems; I can't imagine that any SMP system would require them to be
clear.
Paul.
^ permalink raw reply
* NET-SNMP(snmpd) in PPC
From: 秦宇伟 @ 2005-04-27 1:37 UTC (permalink / raw)
To: linuxppc-embedded
RGVhciB1c3JlcnOjoQ0KICAgICANCiAgICBJIGFtIHRyeWluZyB0byBydW4gc25tcGQgaW4gcG93
ZXJwYyA4NTIgIHRocm91Z2ggY3Jvc3MtIGNvbXBpbGUuIFRoZSB2ZXJzaW9uIG9mIG5ldC1zbm1w
IEkgdXNlZCBpcyA1LjIuMS4gdGhlIG9wZXJhdGUgc3lzdGVtIG9mIGhvc3QgSSB1c2VkIGlzIEZl
ZG9yYSAzLg0KDQogVGhlIHN0ZXBzIEkgZm9sbG93ZWQgaXMgOg0KICAgKDEgKSBzZXQgdGhlIGVu
dmlyb25tZW50IHZhcmlhYmxlDQogICAgICAgICQgQ0M9cG93ZXJwYy1saW51eC1nY2MNCiAgICAg
ICAgJCBleHBvcnQgQ0MNCiAgICAgICAgJCBBUj1wb3dlcnBjLWxpbnV4LWFyDQogICAgICAgICQg
ZXhwb3J0IEFSDQooMiApIGNvbmZpZ3VyZSBhbmQgaW5zdGFsbCB0aGUgTkVULVNOTVA6DQogICAg
ICAgJCAuL2NvbmZpZ3VyZSCoQ2hvc3QgPXBvd2VycGMtbGludXggqEN3aXRoLWVuZGlhbm5lc3M9
bGl0dGxlIKhDcHJlZml4PS90ZXN0ICAgIKhDZXhlYy1wcmVmaXg9L3Rlc3QgICAgDQogICAgICAg
JCBtYWtlDQogICAgICAgJCBtYWtlIGluc3RhbGwNCiAgICgzKSB0aGVuIGFsbCBvZiB0aGUgZmls
ZXMgYXJlIGluc3RhbGxlZCBpbiB0aGUgL3Rlc3QgZGlyZWN0b3J5DQogICAgICAgJCBjZCAvdGVz
dA0KICAgICAgICQgbHMNCiAgICAgICBiaW4gbGliIHNiaW4gaW5jbHVkZSBtYW4gc2hhcmUNCiAg
ICAoNCkgb3BlbmluZyB1cCB0aGUgdGFyZ2V0IG1hY2hpbmUocG93ZXJwYyA4NTIpIHRocm91Z2gg
dGhlIKGwbWluaWNvbaGxDQogICAgICAgaW4gdGhlIG1pbmljb20gSSB0eXBlZCANCiAgICAgICAj
IG1vdW50IKhDdCBuZnMgKioqLioqKi4qKi4qKjovdGVzdCAvdGVzdA0KICAgICg1ICkgdGhlbiBJ
IHRyeSB0byBydW4gdGhlIHNubXBkIGluIHRoZSB0YXJnZXQgbWFjaGluZSwgaW4gdGhlIKGwbWlu
aWNvbaGxIEkgdHlwZWQgOg0KICAgICAgICMgY2QgIC90ZXN0L3NiaW4NCiAgICAgICAjIC4vc25t
cGQgDQogICAgICANCiAgICBJIGdvdCA6DQogICAgICAgIKGwbmZzOiAqKiouKioqLioqLioqIHNl
cnZlciBub3QgcmVzcG9uZGluZyAgc3RpbGwgdHJ5aW5nobENCg0KICAgICBJIHdhbnQgdG8ga25v
dyBob3cgY2FuIEkgcnVuIHRoZSBzbm1wZCBpbiB0aGUgdGFyZ2V0IG1hY2hpbmUocHBjIDg1Mikg
dGhyb3VnaHQgY3Jvc3MtY29tcGlsZS4gDQogICAgICAgDQoNCgkNCg0KoaGhoaGhoaFZb3VycyBT
aW5jZXJlbHkNCiAgICAgICAgICAgICAgICAgIFl1d2VpIFFpbg0KoaGhoaGhoaGhoaGhoaGhoXl1
d2VpX3FpbkBwaG90b250ZWMuY29tDQqhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDUtMDQtMjYNCg==
^ permalink raw reply
* Re: 8xx SMC break handling - SOLVED
From: Robin Gilks @ 2005-04-27 2:26 UTC (permalink / raw)
To: ppc embedded list
In-Reply-To: <426DAE1F.7000404@tait.co.nz>
Robin Gilks wrote:
> Greeting
>
> Can anyone tell me if the break handling of an async SMC port will
> report a break immediately or whether it only reports it on the receipt
> of a valid character (which is what I'm seeing at present). As usual the
> UM is a bit dry in this area!!
>
> Maybe I've not enabled all that I need to in the SMC setup (based on
> 2.4.22 Denx kernel UART driver).
>
> Thanks...
>
Turns out that although the standard UART driver traps 'break', its
never unmasked in the SMCM register - missed this as the manual lumps
the SMCM register with the SMCE reg!!
--
Robin Gilks
Senior Design Engineer Phone: (+64)(3) 357 1569
Tait Electronics Fax : (+64)(3) 359 4632
PO Box 1645 Christchurch Email : robin.gilks@tait.co.nz
New Zealand
=======================================================================
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================
^ permalink raw reply
* RE: PowerPC + SMP
From: Frank @ 2005-04-27 4:37 UTC (permalink / raw)
To: Stuart Yoder, 'Wolfgang Denk'; +Cc: 'linuxppc-dev list'
--- Stuart YoYoderststuartoyoderoconformativeom> wrote:
>
> We've run into a few issues with U-boot, but they are not
> ununsolveable
>
> -it doesn't provide an alternate execution path for the 2nd
> CPU when it
> is started by the kernel
You have to set a flag or something to sync. the booting process
of the other cpu's
> -U-boot needs to detect which CPU is executing
> -U-boot on the 2nd CPU should not execute any platform/board
> specific
We did this by having the cpcpuead a register that is updated as
each cpcpuomes up.
> setup code-- this is stuff you only want to do once
> -U-boot on the 2nd CPU cannot relocate itself to SDSDRAMecause
> Linux is
> already running there and assumes it owns all of memory
You have to carve the memory up by dividing the total memory by
the number of cpus. This can be done at complie time with a
#define. I did this in board_init_f I believe. We had a quad
7450 board with each one booting in sequence and orchestrated by
the master CPU (cpu 0). The master held each one in reset until
the previous cpu reported in. Unfortunately, I don't work for
the company anymore and don't have access to the source.
BTW, it was done right because it worked.:-)
> -it needs some way of getting to the Linux kernel entry point
> for
> secondary CPUs
> -it also appears that it should set up HID1 (other stuff??)
> for SMSMP> systems
>
> Stuart
>
> > -----Original Message-----
> > From: Wolfgang DeDenkmamailtodwdedenxede
> > Sent: Tuesday, April 26, 2005 12:35 PM
> > To: Stuart YoYoder> > Cc: 'lilinuxppcedevist'
> > Subject: Re: PoPowerPC SMSMP
> >
> >
> > In message <054301c54a6f$d1cf82b0$2f010a0a@foundation.com>
> you wrote:
> > >
> > > I am using U-boot on my SMSMPystem and U-boot is not
SMSMP> aware. Do
> > > you
> >
> > Strictly speaking this statement is wrong.
> >
> > So far I am not aware of a port of U-Boot to a SMSMPystem.
> > If there was such a port, and if it was properly done,
> > then U-Boot probably _were_ SMSMPware.
> >
> > Best regards,
> >
> > Wolfgang DeDenk> >
> > --
> > Software Engineering: Embedded and ReRealtimeystems,
> Embedded Linux
> > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> > wdwdedenxedevery program has at least one bug and can be
> > shortened by at least one instruction -- from which,
> > by induction, one can deduce that every program can be
> > reduced to one instruction which doesn't work.
> >
> >
> >
>
>
> _______________________________________________
> LiLinuxppcedevailing list
> LiLinuxppcedevzozlabsrorg>
hthttps/ozozlabsrorgailman/lilistinfoilinuxppcedev>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: Booting linux for 405EP --> mem_pieces_find( ) nightmare
From: Frank @ 2005-04-27 4:54 UTC (permalink / raw)
To: Garcia Jérémie, linuxppc-dev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 704 bytes --]
--- Garcia Jérémie <GARCIAJ@3il.fr> wrote:
> Hi everybody,
> I'm tryin to adapt a linux LSP deom Montavista (the one for
> the 405EP evaluation board) to a proprietary hardware using a
> 405EP.
> Unfortunately, it is not as easy as I thought. Here is my
> problem:
> To load our linux image (zImage.treeboot), we use the "VxWorks
> bootrom" bootloader which download the image via tftp.
Why don't you do it the other way( use u-boot). I just replaced
a vxWorks rom with u-boot and now I can happily boot vxWorks or
Linux on an 8260 based board...
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox