* Re: Watchdog on MPC82xx
From: Bastos Fernandez Alexandre @ 2006-04-19 14:59 UTC (permalink / raw)
To: Mark Chambers; +Cc: linuxppc-embedded list
In-Reply-To: <005401c663a9$e1fd8930$6401a8c0@CHUCK2>
Mark,
>
> I haven't been following this closely, but are you sure it's a WDT
> reset? You can tell from the Reset Status Register (RSR).
> u-boot prints out a decode of this register, which also clears the
> bits, so you have to go by the printout when u-boot starts to see
> why the last reset occurred.
U-boot is reporting the Watchdog reset. You can see:
U-Boot 1.1.4 (Apr 11 2006 - 14:39:01)
MPC8272 Reset Status: Software Watchdog, External Soft, External Hard
MPC8272 Clock Configuration
- Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq 25-75 , Core Freq 100-300
- dfbrg 1, corecnf 0x1a, busdf 3, cpmdf 1, plldf 0, pllmf 3
- vco_out 400000000, scc_clk 100000000, brg_clk 25000000
- cpu_clk 400000000, cpm_clk 200000000, bus_clk 100000000
- pci_clk 66666666
CPU: MPC8272 (HiP7 Rev 14, Mask 1.0 1K50M) at 400 MHz
Board: Televes XXX8248
Watchdog enabled
>
> Just trying to help brainstorm...
>
> Mark Chambers
>
Thanks,
Alex Bastos
^ permalink raw reply
* kernel access of bad area, sig: 11 ( mpc852t)
From: Kenneth Poole @ 2006-04-19 12:58 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2573 bytes --]
>>> Hi,
>>> Im having problem porting linux kernel 2.4.21 to our mpc852T custom
>>> board.The kernel
>>> panics randomly with sig 11.
>>> The board boots up fine and we also get to the prompt.When we open
3-4
>>> telnet sessions
>>> and try to run some command the kernel panics.This is completely
>>> random.Sometimes it
>>> even panics before opening the telnet session.
>>>
>>> <oops dump snipped>
>>>
>>You almost certainly have SDRAM problems. If you have thoroughly
checked
>>out the
>>complete address range statically, remember that burst accesses will
not
>>occur until the
>>cache is turned on, so your problem may be with bursting. But you can
also
>>have severe
>>problems like a missing address line and linux still run for a few
seconds.
>>
>>Mark Chambers
>We've checked the SDRAM. The timings (UPM) look fine. The problem
>however is that linux does not hang until after a few processes are
>started.
>If we boot to linux and leave it as it is, everything is fine and the
>board remains working. However each time a few processes (4-5 telnet
>sessions for eg.) are started the system either panics or hangs (goes
>dead).
>Thanks in advance,
>Akshay
We have been experiencing this same issue with random boards in
production. The exact same version of software will run for months on
other instances of the exact same board design, but a few percent get
'random' trap 300s. When they do occur, it's only after Linux has booted
and address translation and caching are turned on. Examining the oops-es
and memory shows that some location in SDRAM has a bogus value, but I
don't have the tools to trace back how it got that way.
I have ported a rigorous moving-inversions memory test into our
firmware, and have run it extensively across the entire SDRAM address
space (the test code executes from flash). I have let this test run
continuously for hours and hours, but never found a memory problem.
Unfortunately, I do not have test software that enables the MMU address
translation or caching, so as Mark said, I can't test memory using
bursting. Our hardware engineers have reviewed the designs very
carefully and are quite confident that there is plenty of margin in the
memory timing. Signal quality has also been carefully checked.
Our manufacturing people have replaced the CPU on some of these boards,
and the problem went away.
If anyone else on the mailing list has experienced this issue, or has
developed a virtual address memory test, please let us know.
Ken Poole
[-- Attachment #2: Type: text/html, Size: 7533 bytes --]
^ permalink raw reply
* Re: kernel access of bad area, sig: 11 ( mpc852t)
From: Mark Chambers @ 2006-04-19 13:45 UTC (permalink / raw)
To: Kenneth Poole, linuxppc-embedded
In-Reply-To: <4D8794260B62C940BBA7150CC5EB3BD432D423@bosmail.BOS.int.mrv.com>
kernel access of bad area, sig: 11 ( mpc852t)>>> board.The kernel
>>> panics randomly with sig 11.
>We have been experiencing this same issue with random boards in production.
>The exact same version of software will run for months on other >instances
>of the exact same board design, but a few percent get 'random' trap 300s.
>When they do occur, it's only after Linux has booted and >address
>translation and caching are turned on. Examining the oops-es and memory
>shows that some location in SDRAM has a bogus value, >but I don't have the
>tools to trace back how it got that way.
>I have ported a rigorous moving-inversions memory test into our firmware,
>and have run it extensively across the entire SDRAM address >space (the
>test code executes from flash). I have let this test run continuously for
>hours and hours, but never found a memory problem. >Unfortunately, I do not
>have test software that enables the MMU address translation or caching, so
>as Mark said, I can't test memory using >bursting. Our hardware engineers
>have reviewed the designs very carefully and are quite confident that there
>is plenty of margin in the memory >timing. Signal quality has also been
>carefully checked.
Ouch! Yeah, these are the tough ones, the intermittent ones. You can, btw,
force a burst cycle using the RUN
command in the MCR, similar to what you do to generate a few refreshes when
configuring the DRAM. And
you can easily enable the cache for testing and then you'll get bursts (I
don't think MMU will have any effect).
A burst is not so much different from other cycles, so I don't think
bursting per se is what causes problems when
the kernel starts. I think it has more to do with the increased randomness
of accesses with multitasking and
cacheing and all that.
>Our manufacturing people have replaced the CPU on some of these boards, and
>the problem went away.
It also seems to me that the cache is the most delicate bit of logic in the
852. So if you have ground noise or
problems on the 1.8V rail it will likely show up in the cache - I had
hardware problems where I could
track it down to a mismatch between the cache line and memory (and the scope
showed the read burst to
be fine). Also look closely at the PLL circuit - it can work both ways, the
PLL can inject noise back into
the unfiltered supply (I use a ferrite instead of the inductor that
Freescale recommends).
That's my $.02 :-)
Mark C.
^ permalink raw reply
* RE: kernel access of bad area, sig: 11 ( mpc852t)
From: Rune Torgersen @ 2006-04-19 14:33 UTC (permalink / raw)
To: Kenneth Poole, linuxppc-embedded
When I was tracking down a timing problem on our SDRAM I found that
doing a native compile of glibc over NFS seems to be a very good memory
test.
> -----Original Message-----
> From: linuxppc-embedded-bounces+runet=3Dinnovsys.com@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces+runet=3Dinnovsys.com@ozlabs.or
> g] On Behalf Of Kenneth Poole
> Sent: Wednesday, April 19, 2006 07:59
> To: linuxppc-embedded@ozlabs.org
> Subject: kernel access of bad area, sig: 11 ( mpc852t)
>=20
>=20
> >>> Hi,
>=20
> >>> Im having problem porting linux kernel 2.4.21 to our=20
> mpc852T custom
>=20
> >>> board.The kernel
>=20
> >>> panics randomly with sig 11.
>=20
> >>> The board boots up fine and we also get to the=20
> prompt.When we open 3-4
>=20
> >>> telnet sessions
>=20
> >>> and try to run some command the kernel panics.This is completely
>=20
> >>> random.Sometimes it
>=20
> >>> even panics before opening the telnet session.
>=20
> >>>
>=20
>=20
> >>> <oops dump snipped>
>=20
> >>>
>=20
> >>You almost certainly have SDRAM problems. If you have=20
> thoroughly checked
>=20
> >>out the
>=20
> >>complete address range statically, remember that burst=20
> accesses will not
>=20
> >>occur until the
>=20
> >>cache is turned on, so your problem may be with bursting. =20
> But you can also
>=20
> >>have severe
>=20
> >>problems like a missing address line and linux still run=20
> for a few seconds.
>=20
> >>
>=20
> >>Mark Chambers
>=20
> >We've checked the SDRAM. The timings (UPM) look fine. The problem
>=20
> >however is that linux does not hang until after a few processes are
>=20
> >started.
>=20
> >If we boot to linux and leave it as it is, everything is fine and the
>=20
> >board remains working. However each time a few processes (4-5 telnet
>=20
> >sessions for eg.) are started the system either panics or hangs (goes
>=20
> >dead).
>=20
> >Thanks in advance,
>=20
> >Akshay
>=20
> We have been experiencing this same issue with random boards=20
> in production. The exact same version of software will run=20
> for months on other instances of the exact same board design,=20
> but a few percent get 'random' trap 300s. When they do occur,=20
> it's only after Linux has booted and address translation and=20
> caching are turned on. Examining the oops-es and memory shows=20
> that some location in SDRAM has a bogus value, but I don't=20
> have the tools to trace back how it got that way.
>=20
> I have ported a rigorous moving-inversions memory test into=20
> our firmware, and have run it extensively across the entire=20
> SDRAM address space (the test code executes from flash). I=20
> have let this test run continuously for hours and hours, but=20
> never found a memory problem. Unfortunately, I do not have=20
> test software that enables the MMU address translation or=20
> caching, so as Mark said, I can't test memory using bursting.=20
> Our hardware engineers have reviewed the designs very=20
> carefully and are quite confident that there is plenty of=20
> margin in the memory timing. Signal quality has also been=20
> carefully checked.
>=20
> Our manufacturing people have replaced the CPU on some of=20
> these boards, and the problem went away.
>=20
> If anyone else on the mailing list has experienced this=20
> issue, or has developed a virtual address memory test, please=20
> let us know.
>=20
> Ken Poole
>=20
> =20
>=20
> =20
>=20
>=20
^ permalink raw reply
* RE: Watchdog on MPC82xx
From: Rune Torgersen @ 2006-04-19 14:29 UTC (permalink / raw)
To: Bastos Fernandez Alexandre, linuxppc-embedded list
On our 8265/8280 board, the max timeout of the watchdog timer was ~1.3
seconds, so it kept resetting before the heartbeat function got called
on boot.
I had to add a watchdog reset to time_init() because it woud pause there
for about 2 secondfs trying to see if there was a realtime clock.=20
> -----Original Message-----
> From: linuxppc-embedded-bounces+runet=3Dinnovsys.com@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces+runet=3Dinnovsys.com@ozlabs.or
> g] On Behalf Of Bastos Fernandez Alexandre
> Sent: Wednesday, April 19, 2006 06:14
> To: linuxppc-embedded list
> Subject: Re: Watchdog on MPC82xx
>=20
> Well,
>=20
> I have tested two different approaches which has been confirmed
> to be already working on MPC82xx boards.
>=20
> One, from Paul Bilke, is based on modifiying printk to service
> the WDT and reload the counter during boot time.
> So I have modified kernel/printk.c and tested with this:
>=20
> asmlinkage int printk(const char *fmt, ...)
> {
> va_list args;
> int r;
>=20
> force_wdt_reload();
> [...]
> }
>=20
> #define SWSR_ADDR (CPM_MAP_ADDR + 0x1000E)
>=20
> void force_wdt_reload(void)
> {
> unsigned short *swsr_ptr =3D (unsigned short=20
> *)ioremap(SWSR_ADDR,0x2);
>=20
> (*swsr_ptr) =3D (unsigned short) 0x556c;
> (*swsr_ptr) =3D (unsigned short) 0xaa39;
> }
>=20
> Paul has reported changing printk works for him on several=20
> MPC82xx boards.
>=20
> Second one is from Mike Rapoport from Compulab. Is the heartbeat
> method. I have added and additional call in m82xx_board_setup()
> which should reset the WDT for the first time in setup_arch():
>=20
> static __inline__ void reset_8260_watchdog(void)
> {
> cpm2_immr->im_siu_conf.siu_82xx.sc_swsr =3D 0x556c;
> cpm2_immr->im_siu_conf.siu_82xx.sc_swsr =3D 0xaa39;
> }
>=20
> void __init
> m82xx_board_setup(void)
> {
> volatile cpm2_map_t *immap =3D cpm2_immr;
>=20
> reset_8260_watchdog();
>=20
> ppc_md.heartbeat =3D m82xx_heartbeat;
> ppc_md.heartbeat_reset =3D HZ/2;
> ppc_md.heartbeat_count =3D 1;
>=20
> }
>=20
> Mike has reported the heartbeat method is working for him
> on MPC8247 and MPC8271 boards with kernel 2.6.12.3.
>=20
>=20
> I have tested both in a MCP8248 based board, with kernel
> 2.6.15 and u-boot 1.1.4 and I have no success. I can see
> the __log_buf after the reset caused by de WDT and there
> are several printk's done. I have put printk's to the
> reset_8260_watchdog(), and I can see them also, so I
> should suppose it is executed, but the board keeps reseting.
> Furthermore, u-boot is doing OK the WDT job (with changes done
> from Compulab).
>=20
> I have dissasambled that, and for example:
>=20
> c01c93b8 <m82xx_board_setup>:
> c01c93b8: 3d 40 c0 1e lis r10,-16354
> c01c93bc: 38 00 55 6c li r0,21868
> c01c93c0: 81 2a 81 8c lwz r9,-32372(r10)
> c01c93c4: 3d 09 00 01 addis r8,r9,1
> c01c93c8: b0 08 00 0e sth r0,14(r8)
> c01c93cc: 81 68 0d 50 lwz r11,3408(r8)
> c01c93d0: 81 2a 81 8c lwz r9,-32372(r10)
> c01c93d4: 75 60 08 00 andis. r0,r11,2048
> c01c93d8: 38 00 aa 39 li r0,-21959
> c01c93dc: 3d 29 00 01 addis r9,r9,1
> c01c93e0: b0 09 00 0e sth r0,14(r9)
> c01c93e4: 41 82 00 44 beq- c01c9428 <m82xx_board_setup+0x70>
>=20
> [...]
>=20
> which looks OK for me (but I am not an expert).
>=20
> So, could someone give me some guideline about what could
> be happening?. Should I downgrade to 2.6.12.3 and test?
> Is the WDT being reloaded at least one time and then
> failing to reset? Some idea on how to debug that?
>=20
> Thanks
>=20
>=20
> Alex BASTOS
>=20
> P.S. The __log_buf
> 3c353e4c 696e7578 20766572 73696f6e <5>Linux version
> 20322e36 2e313520 28616c65 62617340 2.6.15 (alebas@
> 54523339 32292028 67636320 76657273 xxxx) (gcc vers
> 696f6e20 332e332e 32292023 33392050 ion 3.3.2) #39 P
> 5245454d 50542054 75652041 70722031 REEMPT Tue Apr 1
> 38203135 3a32353a 33392043 45535420 8 15:25:39 CEST
> 32303036 0a3c363e 54656c65 76657320 2006.<6>Televes
> 446f4338 32343820 436f6d70 75746572 XXX8248 Computer
> 2d6f6e2d 4d6f6475 6c652070 6f72740a -on-Module port.
> 3c373e4f 6e206e6f 64652030 20746f74 <7>On node 0 tot
> 616c7061 6765733a 20313633 38340a3c alpages: 16384.<
> 373e2020 444d4120 7a6f6e65 3a203136 7> DMA zone: 16
> 33383420 70616765 732c204c 49464f20 384 pages, LIFO
> 62617463 683a330a 3c373e20 20444d41 batch:3.<7> DMA
> 3332207a 6f6e653a 20302070 61676573 32 zone: 0 pages
> 2c204c49 464f2062 61746368 3a300a3c , LIFO batch:0.<
> 373e2020 4e6f726d 616c207a 6f6e653a 7> Normal zone:
> 20302070 61676573 2c204c49 464f2062 0 pages, LIFO b
> 61746368 3a300a3c 373e2020 48696768 atch:0.<7> High
> 4d656d20 7a6f6e65 3a203020 70616765 Mem zone: 0 page
> 732c204c 49464f20 62617463 683a300a s, LIFO batch:0.
> 3c343e42 75696c74 2031207a 6f6e656c <4>Built 1 zonel
> 69737473 0a3c353e 4b65726e 656c2063 ists.<5>Kernel c
> 6f6d6d61 6e64206c 696e653a 20726f6f ommand line: roo
> 743d2f64 65762f72 616d3020 72772063 t=3D/dev/ram0 rw c
> 6f6e736f 6c653d74 74794350 4d0a3c35 onsole=3DttyCPM.<5
> 3e596f75 20617265 20617420 4f6e650a >You are at One.
> 3c343e50 49442068 61736820 7461626c <4>PID hash tabl
> 6520656e 74726965 733a2035 31322028 e entries: 512 (
> 6f726465 723a2039 2c203831 00000000 order: 9, 81....
> 00000000 00000000 00000000 00000000 ................
>=20
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
^ permalink raw reply
* RE: Watchdog on MPC82xx
From: Pelton, Dave @ 2006-04-19 15:23 UTC (permalink / raw)
To: linuxppc-embedded list; +Cc: Bastos Fernandez Alexandre
Alex,
I have recently been trying to get the internal watchdog timer working
with 2.6.15 on a MPC8247 custom board (@ 266MHz), and hence I have been
following this thread with great interest.
I tried the heartbeat method (setting ppc_md.heartbeat to kick the
watchdog) and I was unable to get it to work correctly. To help things
I tried sprinkling a few kicks of the watchdog through the early layers
of init code but this seemed to make no difference.
I also tried porting the mpc8xx watchdog driver to the mpc82xx
architecture (i.e. kicking the watchdog using the PIT interrupt). This
seemed to fail in the same way. I would see about 8 or 10 characters of
the initial start-up message (where it dumps the Linux version and the
build time) and then the watchdog would kick the card back to u-boot.
As a last resort I tried kicking the watchdog in the printk call (in
essentially the same way that you do below), and I found that this
worked correctly when used in conjunction with the ported version of the
mpc8xx watchdog driver. I suspect it would work equally well with the
heartbeat method.
I don't understand why kicking the watchdog from printk fixes things,
and it really seems like an ugly way to fix this problem. I did the
quick math to figure out how long it will take the watchdog to trigger,
and at my clock rate of 266MHz, the watchdog fires in about 0.5 seconds,
which means that anything that runs for longer than 0.25 seconds could
cause a watchdog trigger. My best guess is that within printk there is
something that exceeds this margin, but looking in the code I can not
see what that would be (unless draining the printk console output over
the ttyCPM0 serial port somehow takes a long time).
Perhaps some of the wise ones on the list could provide some suggestions
on why printk seems to be the sticking point for the watchdog.
- David Pelton.
-----Original Message-----
Sent: Wednesday, April 19, 2006 7:14 AM
To: linuxppc-embedded list
Subject: Re: Watchdog on MPC82xx
Well,
I have tested two different approaches which has been confirmed to be
already working on MPC82xx boards.
One, from Paul Bilke, is based on modifiying printk to service the WDT
and reload the counter during boot time.
So I have modified kernel/printk.c and tested with this:
asmlinkage int printk(const char *fmt, ...) {
va_list args;
int r;
force_wdt_reload();
[...]
}
<< snip >>
^ permalink raw reply
* RE: kernel 2.6.15: cpm_uart driver broken?
From: Kenneth Poole @ 2006-04-19 19:24 UTC (permalink / raw)
To: Vitaly Bordug, David Jander; +Cc: linuxppc-embedded
>If there is any code to reference, I'd appreciate it (and merge to the
>driver).=20
Ok, here's a patch, below. It includes changes for DMA buffer allocation
as discussed. This is untested, because the CPM uart driver for our
platforms has many other modifications that don't apply.
It also includes a fix for sending x_char in cpm_uart_tx_pump(). This
allows the actual x_char to be sent, instead of the next regular
character.
-------------------------------------------------------------
--- cpm_uart_core.c.orig 2006-04-19 10:24:47.000000000 -0400
+++ cpm_uart_core.c 2006-04-19 10:51:43.000000000 -0400
@@ -71,20 +71,6 @@
=20
/**************************************************************/
=20
-static inline unsigned long cpu2cpm_addr(void *addr)
-{
- if ((unsigned long)addr >=3D CPM_ADDR)
- return (unsigned long)addr;
- return virt_to_bus(addr);
-}
-
-static inline void *cpm2cpu_addr(unsigned long addr)
-{
- if (addr >=3D CPM_ADDR)
- return (void *)addr;
- return bus_to_virt(addr);
-}
-
/*
* Check, if transmit buffers are processed
*/
@@ -261,7 +247,7 @@
}
=20
/* get pointer */
- cp =3D cpm2cpu_addr(bdp->cbd_bufaddr);
+ cp =3D (unsigned char *)pinfo->mem_addr +
(bdp->cbd_bufaddr - pinfo->dma_addr);
=20
/* loop through the buffer */
while (i-- > 0) {
@@ -606,11 +592,12 @@
/* Pick next descriptor and fill from buffer */
bdp =3D pinfo->tx_cur;
=20
- p =3D cpm2cpu_addr(bdp->cbd_bufaddr);
+ p =3D (unsigned char *)pinfo->mem_addr + (bdp->cbd_bufaddr
- pinfo->dma_addr);
=20
- *p++ =3D xmit->buf[xmit->tail];
+ *p =3D port->x_char;
bdp->cbd_datlen =3D 1;
bdp->cbd_sc |=3D BD_SC_READY;
+ __asm__("eieio");
/* Get next BD. */
if (bdp->cbd_sc & BD_SC_WRAP)
bdp =3D pinfo->tx_bd_base;
@@ -633,7 +620,7 @@
=20
while (!(bdp->cbd_sc & BD_SC_READY) && (xmit->tail !=3D
xmit->head)) {
count =3D 0;
- p =3D cpm2cpu_addr(bdp->cbd_bufaddr);
+ p =3D (unsigned char *)pinfo->mem_addr + (bdp->cbd_bufaddr
- pinfo->dma_addr);
while (count < pinfo->tx_fifosize) {
*p++ =3D xmit->buf[xmit->tail];
xmit->tail =3D (xmit->tail + 1) & (UART_XMIT_SIZE
- 1);
@@ -670,39 +657,37 @@
static void cpm_uart_initbd(struct uart_cpm_port *pinfo)
{
int i;
- u8 *mem_addr;
+ dma_addr_t dma_addr;
volatile cbd_t *bdp;
=20
pr_debug("CPM uart[%d]:initbd\n", pinfo->port.line);
=20
/* Set the physical address of the host memory
- * buffers in the buffer descriptors, and the
- * virtual address for us to work with.
+ * buffers in the buffer descriptors.
*/
- mem_addr =3D pinfo->mem_addr;
+ dma_addr =3D pinfo->dma_addr;
bdp =3D pinfo->rx_cur =3D pinfo->rx_bd_base;
for (i =3D 0; i < (pinfo->rx_nrfifos - 1); i++, bdp++) {
- bdp->cbd_bufaddr =3D cpu2cpm_addr(mem_addr);
+ bdp->cbd_bufaddr =3D dma_addr;
bdp->cbd_sc =3D BD_SC_EMPTY | BD_SC_INTRPT;
- mem_addr +=3D pinfo->rx_fifosize;
+ dma_addr +=3D pinfo->rx_fifosize;
}
-
- bdp->cbd_bufaddr =3D cpu2cpm_addr(mem_addr);
+=09
+ bdp->cbd_bufaddr =3D dma_addr;
bdp->cbd_sc =3D BD_SC_WRAP | BD_SC_EMPTY | BD_SC_INTRPT;
=20
/* Set the physical address of the host memory
- * buffers in the buffer descriptors, and the
- * virtual address for us to work with.
+ * buffers in the buffer descriptors.
*/
- mem_addr =3D pinfo->mem_addr + L1_CACHE_ALIGN(pinfo->rx_nrfifos *
pinfo->rx_fifosize);
+ dma_addr =3D pinfo->dma_addr + L1_CACHE_ALIGN(pinfo->rx_nrfifos *
pinfo->rx_fifosize);
bdp =3D pinfo->tx_cur =3D pinfo->tx_bd_base;
for (i =3D 0; i < (pinfo->tx_nrfifos - 1); i++, bdp++) {
- bdp->cbd_bufaddr =3D cpu2cpm_addr(mem_addr);
+ bdp->cbd_bufaddr =3D dma_addr;
bdp->cbd_sc =3D BD_SC_INTRPT;
- mem_addr +=3D pinfo->tx_fifosize;
+ dma_addr +=3D pinfo->tx_fifosize;
}
-
- bdp->cbd_bufaddr =3D cpu2cpm_addr(mem_addr);
+=09
+ bdp->cbd_bufaddr =3D dma_addr;
bdp->cbd_sc =3D BD_SC_WRAP | BD_SC_INTRPT;
}
=20
@@ -1032,7 +1017,7 @@
* If the buffer address is in the CPM DPRAM, don't
* convert it.
*/
- cp =3D cpm2cpu_addr(bdp->cbd_bufaddr);
+ cp =3D (unsigned char *)pinfo->mem_addr +
(bdp->cbd_bufaddr - pinfo->dma_addr);
=20
*cp =3D *s;
=20
@@ -1049,7 +1034,7 @@
while ((bdp->cbd_sc & BD_SC_READY) !=3D 0)
;
=20
- cp =3D cpm2cpu_addr(bdp->cbd_bufaddr);
+ cp =3D (unsigned char *)pinfo->mem_addr +
(bdp->cbd_bufaddr - pinfo->dma_addr);
=20
*cp =3D 13;
bdp->cbd_datlen =3D 1;
--- cpm_uart_cpm1.c.orig 2006-04-19 10:26:46.000000000 -0400
+++ cpm_uart_cpm1.c 2006-04-19 10:32:05.000000000 -0400
@@ -191,7 +191,7 @@
/* was hostalloc but changed cause it blows away the */
/* large tlb mapping when pinning the kernel area */
mem_addr =3D (u8 *) cpm_dpram_addr(cpm_dpalloc(memsz, 8));
- dma_addr =3D 0;
+ dma_addr =3D (dma_addr_t)mem_addr;
} else
mem_addr =3D dma_alloc_coherent(NULL, memsz, &dma_addr,
GFP_KERNEL);
----------------------------------------------------------
Ken Poole
kpoole@bos.mrv.com
=20
^ permalink raw reply
* Re: kernel 2.6.15: cpm_uart driver broken?
From: Dan Malek @ 2006-04-19 19:42 UTC (permalink / raw)
To: Kenneth Poole; +Cc: David Jander, linuxppc-embedded
In-Reply-To: <4D8794260B62C940BBA7150CC5EB3BD432D4F4@bosmail.BOS.int.mrv.com>
On Apr 19, 2006, at 3:24 PM, Kenneth Poole wrote:
>
> /* get pointer */
> - cp = cpm2cpu_addr(bdp->cbd_bufaddr);
> + cp = (unsigned char *)pinfo->mem_addr +
> (bdp->cbd_bufaddr - pinfo->dma_addr);
Ummm, no. Keep the cpm2cpu_addr() and pass it
some driver data structure pointer so it does the computes,
or better, keep the phys/virt addresses in a handy data
structure you can easily access and work with offsets within
the different address spaces. The test of addr >= CPM_ADDR
is critically important to early boot and kgdb support
and can't be removed.
> - bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr);
> + bdp->cbd_bufaddr = dma_addr;
This kind of initialization is broken, too. You have to test
that memory address and return the proper space.
Thanks.
-- Dan
^ permalink raw reply
* RE: kernel 2.6.15: cpm_uart driver broken?
From: Kenneth Poole @ 2006-04-19 20:40 UTC (permalink / raw)
To: Dan Malek; +Cc: David Jander, linuxppc-embedded
Hello Dan:
>
>From: Dan Malek [mailto:dan@embeddedalley.com]=20
>Sent: Wednesday, April 19, 2006 3:42 PM
>To: Kenneth Poole
>Cc: Vitaly Bordug; David Jander; linuxppc-embedded@ozlabs.org
>Subject: Re: kernel 2.6.15: cpm_uart driver broken?
>On Apr 19, 2006, at 3:24 PM, Kenneth Poole wrote:
>>
>> /* get pointer */
>> - cp =3D cpm2cpu_addr(bdp->cbd_bufaddr);
>> + cp =3D (unsigned char *)pinfo->mem_addr +
>> (bdp->cbd_bufaddr - pinfo->dma_addr);
>Ummm, no. Keep the cpm2cpu_addr() and pass it
>some driver data structure pointer so it does the computes,
>
We did this to solve the problem mentioned earlier in this thread which
is that bus_to_virt() and virt_to_bus() don't work for memory allocated
with dma_alloc_coherent(). By saving the return value from
dma_alloc_coherent() in dma_addr, we avoid having to do those
conversions all of the time.
>or better, keep the phys/virt addresses in a handy data
>structure you can easily access and work with offsets within
>the different address spaces.
That's what we're doing by using dma_addr. We just compute the offset in
the physical address space and apply that offset in the virtual address
space. Some drivers keep both sets of pointers around for each buffer
allocated, and that would work as well.
> The test of addr >=3D CPM_ADDR
>is critically important to early boot and kgdb support
>and can't be removed.
I assumed that this test was simply to exclude console ports from
conversion. But in cpm_uart_allocbuf() there already is a test (is_con).
For the console, we simply save the unconverted dma_addr in the port
structure once and use it normally. Our console port works just fine.
Testing addr >=3D CPM_ADDR forces very specific ordering onto the IMMR =
and
DMA address spaces, and I thought our approach was more general.=20
>> - bdp->cbd_bufaddr =3D cpu2cpm_addr(mem_addr);
>> + bdp->cbd_bufaddr =3D dma_addr;
>This kind of initialization is broken, too. You have to test
>that memory address and return the proper space.
>Thanks.
> -- Dan
^ permalink raw reply
* Re: kernel 2.6.15: cpm_uart driver broken?
From: Dan Malek @ 2006-04-19 21:14 UTC (permalink / raw)
To: Kenneth Poole; +Cc: David Jander, linuxppc-embedded
In-Reply-To: <4D8794260B62C940BBA7150CC5EB3BD432D512@bosmail.BOS.int.mrv.com>
On Apr 19, 2006, at 4:40 PM, Kenneth Poole wrote:
> ..... we avoid having to do those
> conversions all of the time.
You are still doing a very similar conversion, only with
different addresses and offsets, and more compute
operations.
> I assumed that this test was simply to exclude console ports from
> conversion.
Bad assumption. It's done to be able to use buffers allocated out
of the CPM memory or before the VM is sufficiently configured to
relocate the buffers. This is needed for early debug prints, xmon,
and kgdb.
These modifications further remove features that have been
part of past kernels, and it has to stop.
Thanks.
-- Dan
^ permalink raw reply
* [PATCH] update {g5,iseries,pseries}_defconfigs
From: Will Schmidt @ 2006-04-19 21:26 UTC (permalink / raw)
To: linuxppc-dev, paulus
Hi,
This patch is cosmetic, makes a handful of "nonexistent symbol" warnings
go away. Systems I have access to are clearly pseries or g5. I am
not sure if ppc64_defconfig is redundant or meant for a subset, so I
didnt touch that one.
Default choices for all.
Signed-off-by: Will Schmidt <willschm@us.ibm.com>
diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig
index 2c3fd20..a456275 100644
--- a/arch/powerpc/configs/g5_defconfig
+++ b/arch/powerpc/configs/g5_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.16-rc2
-# Fri Feb 10 17:33:08 2006
+# Linux kernel version: 2.6.17-rc1
+# Wed Apr 19 13:24:37 2006
#
CONFIG_PPC64=y
CONFIG_64BIT=y
@@ -9,6 +9,7 @@ CONFIG_PPC_MERGE=y
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
@@ -29,6 +30,7 @@ CONFIG_POWER4=y
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
CONFIG_PPC_STD_MMU=y
+CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_SMP=y
CONFIG_NR_CPUS=4
@@ -53,6 +55,7 @@ CONFIG_SYSCTL=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_CPUSETS is not set
+# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
# CONFIG_EMBEDDED is not set
@@ -67,10 +70,6 @@ CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
-CONFIG_CC_ALIGN_FUNCTIONS=0
-CONFIG_CC_ALIGN_LABELS=0
-CONFIG_CC_ALIGN_LOOPS=0
-CONFIG_CC_ALIGN_JUMPS=0
CONFIG_SLAB=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
@@ -82,7 +81,6 @@ CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
-CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
@@ -91,6 +89,7 @@ CONFIG_STOP_MACHINE=y
#
# Block layer
#
+# CONFIG_BLK_DEV_IO_TRACE is not set
#
# IO Schedulers
@@ -185,7 +184,6 @@ CONFIG_GENERIC_ISA_DMA=y
# CONFIG_PPC_INDIRECT_PCI is not set
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
-CONFIG_PCI_LEGACY_PROC=y
# CONFIG_PCI_DEBUG is not set
#
@@ -227,6 +225,7 @@ CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
+CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
@@ -238,6 +237,8 @@ CONFIG_TCP_CONG_BIC=y
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
+# CONFIG_INET6_XFRM_TUNNEL is not set
+# CONFIG_INET6_TUNNEL is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
@@ -261,6 +262,7 @@ CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
# CONFIG_IP_NF_PPTP is not set
+# CONFIG_IP_NF_H323 is not set
CONFIG_IP_NF_QUEUE=m
#
@@ -513,6 +515,7 @@ CONFIG_MD_RAID0=y
CONFIG_MD_RAID1=y
CONFIG_MD_RAID10=m
CONFIG_MD_RAID5=y
+# CONFIG_MD_RAID5_RESHAPE is not set
CONFIG_MD_RAID6=m
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
@@ -761,7 +764,6 @@ CONFIG_LEGACY_PTY_COUNT=256
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
-# CONFIG_RTC is not set
CONFIG_GEN_RTC=y
# CONFIG_GEN_RTC_X is not set
# CONFIG_DTLK is not set
@@ -772,6 +774,7 @@ CONFIG_GEN_RTC=y
# Ftape, the floppy tape device driver
#
CONFIG_AGP=m
+# CONFIG_AGP_VIA is not set
CONFIG_AGP_UNINORTH=m
# CONFIG_DRM is not set
CONFIG_RAW_DRIVER=y
@@ -813,7 +816,6 @@ CONFIG_I2C_POWERMAC=y
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
-# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
@@ -832,9 +834,7 @@ CONFIG_I2C_POWERMAC=y
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
-# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_SENSORS_MAX6875 is not set
-# CONFIG_RTC_X1205_I2C is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
@@ -862,10 +862,6 @@ CONFIG_I2C_POWERMAC=y
#
#
-# Multimedia Capabilities Port drivers
-#
-
-#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
@@ -874,6 +870,7 @@ CONFIG_I2C_POWERMAC=y
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
+# CONFIG_USB_DABUSB is not set
#
# Graphics support
@@ -883,6 +880,7 @@ CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_MACMODES=y
+CONFIG_FB_FIRMWARE_EDID=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
# CONFIG_FB_CIRRUS is not set
@@ -901,7 +899,6 @@ CONFIG_FB_NVIDIA=y
CONFIG_FB_NVIDIA_I2C=y
# CONFIG_FB_RIVA is not set
# CONFIG_FB_MATROX is not set
-# CONFIG_FB_RADEON_OLD is not set
CONFIG_FB_RADEON=y
CONFIG_FB_RADEON_I2C=y
# CONFIG_FB_RADEON_DEBUG is not set
@@ -958,9 +955,11 @@ CONFIG_SND_SEQUENCER=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
+CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
+CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
@@ -977,6 +976,7 @@ CONFIG_SND_SUPPORT_OLD_API=y
# PCI devices
#
# CONFIG_SND_AD1889 is not set
+# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
@@ -1009,6 +1009,7 @@ CONFIG_SND_SUPPORT_OLD_API=y
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
+# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
@@ -1041,6 +1042,7 @@ CONFIG_SND_USB_AUDIO=m
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
+CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
@@ -1068,7 +1070,6 @@ CONFIG_USB_OHCI_LITTLE_ENDIAN=y
#
# USB Device Class drivers
#
-# CONFIG_OBSOLETE_OSS_USB_DRIVER is not set
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=y
@@ -1126,15 +1127,6 @@ CONFIG_USB_HIDDEV=y
# CONFIG_USB_MICROTEK is not set
#
-# USB Multimedia devices
-#
-# CONFIG_USB_DABUSB is not set
-
-#
-# Video4Linux support is needed for USB Multimedia device support
-#
-
-#
# USB Network Adapters
#
CONFIG_USB_CATC=m
@@ -1194,6 +1186,7 @@ CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
CONFIG_USB_SERIAL_MCT_U232=m
+# CONFIG_USB_SERIAL_NAVMAN is not set
CONFIG_USB_SERIAL_PL2303=m
# CONFIG_USB_SERIAL_HP4X is not set
CONFIG_USB_SERIAL_SAFE=m
@@ -1237,17 +1230,23 @@ CONFIG_USB_EZUSB=y
# CONFIG_MMC is not set
#
+# LED devices
+#
+# CONFIG_NEW_LEDS is not set
+
+#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set
#
-# SN Devices
+# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
#
-# EDAC - error detection and reporting (RAS)
+# Real Time Clock
#
+# CONFIG_RTC_CLASS is not set
#
# File systems
@@ -1319,7 +1318,6 @@ CONFIG_TMPFS=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y
-# CONFIG_RELAYFS_FS is not set
# CONFIG_CONFIGFS_FS is not set
#
diff --git a/arch/powerpc/configs/iseries_defconfig b/arch/powerpc/configs/iseries_defconfig
index 1816a46..a95e455 100644
--- a/arch/powerpc/configs/iseries_defconfig
+++ b/arch/powerpc/configs/iseries_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.16-rc6
-# Wed Mar 15 16:19:52 2006
+# Linux kernel version: 2.6.17-rc1
+# Wed Apr 19 11:46:44 2006
#
CONFIG_PPC64=y
CONFIG_64BIT=y
@@ -9,6 +9,7 @@ CONFIG_PPC_MERGE=y
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
@@ -30,6 +31,7 @@ CONFIG_POWER4=y
CONFIG_PPC_FPU=y
# CONFIG_ALTIVEC is not set
CONFIG_PPC_STD_MMU=y
+CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_SMP=y
CONFIG_NR_CPUS=32
@@ -55,6 +57,7 @@ CONFIG_AUDITSYSCALL=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_CPUSETS is not set
+# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
# CONFIG_EMBEDDED is not set
@@ -69,10 +72,6 @@ CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
-CONFIG_CC_ALIGN_FUNCTIONS=0
-CONFIG_CC_ALIGN_LABELS=0
-CONFIG_CC_ALIGN_LOOPS=0
-CONFIG_CC_ALIGN_JUMPS=0
CONFIG_SLAB=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
@@ -84,7 +83,6 @@ CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
-CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
@@ -93,6 +91,7 @@ CONFIG_STOP_MACHINE=y
#
# Block layer
#
+# CONFIG_BLK_DEV_IO_TRACE is not set
#
# IO Schedulers
@@ -165,7 +164,6 @@ CONFIG_GENERIC_ISA_DMA=y
# CONFIG_PPC_INDIRECT_PCI is not set
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
-CONFIG_PCI_LEGACY_PROC=y
# CONFIG_PCI_DEBUG is not set
#
@@ -207,6 +205,7 @@ CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
+CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
@@ -218,6 +217,8 @@ CONFIG_TCP_CONG_BIC=y
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
+# CONFIG_INET6_XFRM_TUNNEL is not set
+# CONFIG_INET6_TUNNEL is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
@@ -236,11 +237,14 @@ CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m
CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
+# CONFIG_NETFILTER_XT_MATCH_ESP is not set
CONFIG_NETFILTER_XT_MATCH_HELPER=m
CONFIG_NETFILTER_XT_MATCH_LENGTH=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
+# CONFIG_NETFILTER_XT_MATCH_POLICY is not set
+# CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_SCTP=m
@@ -262,20 +266,19 @@ CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
# CONFIG_IP_NF_PPTP is not set
+# CONFIG_IP_NF_H323 is not set
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_IPRANGE=m
-CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
-CONFIG_IP_NF_MATCH_AH_ESP=m
+# CONFIG_IP_NF_MATCH_AH is not set
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_HASHLIMIT=m
-CONFIG_IP_NF_MATCH_POLICY=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
@@ -479,6 +482,7 @@ CONFIG_MD_RAID0=y
CONFIG_MD_RAID1=y
CONFIG_MD_RAID10=m
CONFIG_MD_RAID5=y
+# CONFIG_MD_RAID5_RESHAPE is not set
CONFIG_MD_RAID6=m
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
@@ -702,7 +706,6 @@ CONFIG_LEGACY_PTY_COUNT=256
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
-# CONFIG_RTC is not set
CONFIG_GEN_RTC=y
# CONFIG_GEN_RTC_X is not set
# CONFIG_DTLK is not set
@@ -751,10 +754,6 @@ CONFIG_MAX_RAW_DEVS=256
#
#
-# Multimedia Capabilities Port drivers
-#
-
-#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
@@ -779,6 +778,7 @@ CONFIG_MAX_RAW_DEVS=256
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
+CONFIG_USB_ARCH_HAS_EHCI=y
# CONFIG_USB is not set
#
@@ -796,6 +796,11 @@ CONFIG_USB_ARCH_HAS_OHCI=y
# CONFIG_MMC is not set
#
+# LED devices
+#
+# CONFIG_NEW_LEDS is not set
+
+#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set
@@ -805,6 +810,11 @@ CONFIG_USB_ARCH_HAS_OHCI=y
#
#
+# Real Time Clock
+#
+# CONFIG_RTC_CLASS is not set
+
+#
# File systems
#
CONFIG_EXT2_FS=y
@@ -878,7 +888,6 @@ CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
-# CONFIG_RELAYFS_FS is not set
# CONFIG_CONFIGFS_FS is not set
#
diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig
index daaf038..58e68ce 100644
--- a/arch/powerpc/configs/pseries_defconfig
+++ b/arch/powerpc/configs/pseries_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.16-rc2
-# Fri Feb 10 17:33:32 2006
+# Linux kernel version: 2.6.17-rc1
+# Wed Apr 19 11:48:00 2006
#
CONFIG_PPC64=y
CONFIG_64BIT=y
@@ -9,6 +9,7 @@ CONFIG_PPC_MERGE=y
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
@@ -30,6 +31,7 @@ CONFIG_POWER4=y
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
CONFIG_PPC_STD_MMU=y
+CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_SMP=y
CONFIG_NR_CPUS=128
@@ -55,6 +57,7 @@ CONFIG_AUDITSYSCALL=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_CPUSETS=y
+# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
# CONFIG_EMBEDDED is not set
@@ -69,10 +72,6 @@ CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
-CONFIG_CC_ALIGN_FUNCTIONS=0
-CONFIG_CC_ALIGN_LABELS=0
-CONFIG_CC_ALIGN_LOOPS=0
-CONFIG_CC_ALIGN_JUMPS=0
CONFIG_SLAB=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
@@ -84,7 +83,6 @@ CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
-CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
@@ -93,6 +91,7 @@ CONFIG_STOP_MACHINE=y
#
# Block layer
#
+# CONFIG_BLK_DEV_IO_TRACE is not set
#
# IO Schedulers
@@ -188,7 +187,6 @@ CONFIG_PPC_I8259=y
# CONFIG_PPC_INDIRECT_PCI is not set
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
-CONFIG_PCI_LEGACY_PROC=y
# CONFIG_PCI_DEBUG is not set
#
@@ -235,6 +233,7 @@ CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
+CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
@@ -246,6 +245,8 @@ CONFIG_TCP_CONG_BIC=y
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
+# CONFIG_INET6_XFRM_TUNNEL is not set
+# CONFIG_INET6_TUNNEL is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
@@ -272,6 +273,7 @@ CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
# CONFIG_IP_NF_PPTP is not set
+# CONFIG_IP_NF_H323 is not set
CONFIG_IP_NF_QUEUE=m
#
@@ -519,6 +521,7 @@ CONFIG_MD_RAID0=y
CONFIG_MD_RAID1=y
CONFIG_MD_RAID10=m
CONFIG_MD_RAID5=y
+# CONFIG_MD_RAID5_RESHAPE is not set
CONFIG_MD_RAID6=m
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
@@ -750,6 +753,7 @@ CONFIG_HW_CONSOLE=y
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
@@ -767,7 +771,9 @@ CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_PRINTER is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set
+CONFIG_HVC_DRIVER=y
CONFIG_HVC_CONSOLE=y
+# CONFIG_HVC_RTAS is not set
CONFIG_HVCS=m
#
@@ -779,7 +785,6 @@ CONFIG_HVCS=m
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
-# CONFIG_RTC is not set
CONFIG_GEN_RTC=y
# CONFIG_GEN_RTC_X is not set
# CONFIG_DTLK is not set
@@ -830,7 +835,6 @@ CONFIG_I2C_ALGOBIT=y
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
-# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
@@ -849,9 +853,7 @@ CONFIG_I2C_ALGOBIT=y
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
-# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_SENSORS_MAX6875 is not set
-# CONFIG_RTC_X1205_I2C is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
@@ -879,10 +881,6 @@ CONFIG_I2C_ALGOBIT=y
#
#
-# Multimedia Capabilities Port drivers
-#
-
-#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
@@ -891,6 +889,7 @@ CONFIG_I2C_ALGOBIT=y
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
+# CONFIG_USB_DABUSB is not set
#
# Graphics support
@@ -900,6 +899,7 @@ CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_MACMODES=y
+CONFIG_FB_FIRMWARE_EDID=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
# CONFIG_FB_CIRRUS is not set
@@ -919,7 +919,6 @@ CONFIG_FB_MATROX_MYSTIQUE=y
CONFIG_FB_MATROX_G=y
# CONFIG_FB_MATROX_I2C is not set
CONFIG_FB_MATROX_MULTIHEAD=y
-# CONFIG_FB_RADEON_OLD is not set
CONFIG_FB_RADEON=y
CONFIG_FB_RADEON_I2C=y
# CONFIG_FB_RADEON_DEBUG is not set
@@ -968,6 +967,7 @@ CONFIG_LCD_DEVICE=y
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
+CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
@@ -1048,15 +1048,6 @@ CONFIG_USB_HIDDEV=y
# CONFIG_USB_MICROTEK is not set
#
-# USB Multimedia devices
-#
-# CONFIG_USB_DABUSB is not set
-
-#
-# Video4Linux support is needed for USB Multimedia device support
-#
-
-#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
@@ -1109,6 +1100,11 @@ CONFIG_USB_MON=y
# CONFIG_MMC is not set
#
+# LED devices
+#
+# CONFIG_NEW_LEDS is not set
+
+#
# InfiniBand support
#
CONFIG_INFINIBAND=m
@@ -1121,12 +1117,13 @@ CONFIG_INFINIBAND_IPOIB=m
# CONFIG_INFINIBAND_SRP is not set
#
-# SN Devices
+# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
#
-# EDAC - error detection and reporting (RAS)
+# Real Time Clock
#
+# CONFIG_RTC_CLASS is not set
#
# File systems
@@ -1202,7 +1199,6 @@ CONFIG_TMPFS=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y
-# CONFIG_RELAYFS_FS is not set
# CONFIG_CONFIGFS_FS is not set
#
^ permalink raw reply related
* modules without a .toc section not loading
From: Robin H. Johnson @ 2006-04-20 0:02 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]
Hi,
I recently got myself a quad G5, and I'm working on a few things, and
I've run into what is either a ppc-specific GCC bug, or a module loader
bug. While the bug shows up in my custom module, it also shows up in two
other places in the current tree.
This was mentioned on the list in February, and Paulus asked for some
off-list input from the reporter, but I find nothing else.
Output in dmesg after insmod:
windfarm_pid: doesn't contain .toc or .stubs.
- My current tree is Paulus's powerpc.git tree.
- Tested with gcc 3.4.4 and 3.4.6 - both show the problem.
- in-tree modules that show it: windfarm_pid, ide-generic
Checking:
# objdump -h windfarm_pid.ko | grep toc
(not found)
# objdump -h windfarm_pid.o | grep toc
(not found)
Similarities in affected code:
All of the affected code seems to be very simple, and does not reference
very many external symbols, or any significant external symbols.
If I add some dud code with an external symbol (I added kalloc/kfree to
windfarm_pid), a .toc section does get generated correctly.
Hypothesis:
GCC isn't generating a .toc section because the source file doesn't
need one by it's consideration.
Ideas for Solutions:
1. Either the kernel needs to realize that it does not need a .toc
section (I'm uncertain about this, being new to PPC).
2. GCC is at fault, and it should be generating a .toc.
--
Robin Hugh Johnson
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]
^ permalink raw reply
* Re: modules without a .toc section not loading
From: Robin H. Johnson @ 2006-04-20 0:54 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060420002829.GD27430@bubble.grove.modra.org>
[-- Attachment #1: Type: text/plain, Size: 925 bytes --]
On Thu, Apr 20, 2006 at 09:58:30AM +0930, Alan Modra wrote:
> > Ideas for Solutions:
> > 1. Either the kernel needs to realize that it does not need a .toc
> > section (I'm uncertain about this, being new to PPC).
> > 2. GCC is at fault, and it should be generating a .toc.
> The former.
Ok, so in module_64.c, under what cases is .toc NOT needed?
I dug at the code, and the R_PPC_REL24 blocks need the contents of the
.toc (via stub_for_addr -> create_stub -> my_r2), and I'm not certain
about it.
The R_PPC64_TOC/R_PPC64_TOC16/R_PPC64_TOC16_DS blocks shouldn't be hit
when there isn't a .toc* from what I figure.
If the R_PPC_REL24 block won't be hit when there isn't a .toc, the check
in module_frob_arch_sections, lines 194-197 can just be shortened as a
fix to the problem.
--
Robin Hugh Johnson
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]
^ permalink raw reply
* Re: kernel 2.6.15: cpm_uart driver broken?
From: David Jander @ 2006-04-20 7:41 UTC (permalink / raw)
To: Dan Malek; +Cc: Kenneth Poole, linuxppc-embedded
In-Reply-To: <C8993021-BD00-4418-BF26-4BC8961BB53D@embeddedalley.com>
Hi,
On Wednesday 19 April 2006 23:14, Dan Malek wrote:
> > I assumed that this test was simply to exclude console ports from
> > conversion.
>
> Bad assumption. It's done to be able to use buffers allocated out
> of the CPM memory or before the VM is sufficiently configured to
> relocate the buffers. This is needed for early debug prints, xmon,
> and kgdb.
Yes, but it's broken. In order to work as expected it had to be something
like:
if((addr >= CPM_ADDR) && (addr <= CPM_ADDR_END))....
Otherwise you are also, in some configurations, excluding dma allocated memory
from mapping, since in those cases (my case for instance)
CONFIG_CONSISTENT_START > CPM_ADDR_END. (Assuming CPM_ADDR_END is something
like CPM_ADDR+sizeof(DPRAM)).
What about the following patch?
This patch adds another member to "struct uart_cpm_port" to store a
dma_offset. That offset is computed in cpm_uart_cpm?.c and passed to the
cpu2cpm_addr() and cpm2cpu_addr() functions as a second argument.
One thing that still smells IMHO, is the check in cpm2cpu_addr() to see if we
originally come from a dma-type address, although it should work under all
situations I can think of. Any ideas?
=======================================
--- drivers/serial/cpm_uart/cpm_uart.h (revision 513)
+++ drivers/serial/cpm_uart/cpm_uart.h (working copy)
@@ -64,6 +64,7 @@
uint dp_addr;
void *mem_addr;
dma_addr_t dma_addr;
+ unsigned long dma_offset;
/* helpers */
int baud;
int bits;
--- drivers/serial/cpm_uart/cpm_uart_cpm1.c (revision 513)
+++ drivers/serial/cpm_uart/cpm_uart_cpm1.c (working copy)
@@ -191,11 +191,11 @@
/* was hostalloc but changed cause it blows away the */
/* large tlb mapping when pinning the kernel area */
mem_addr = (u8 *) cpm_dpram_addr(cpm_dpalloc(memsz, 8));
- dma_addr = 0;
+ dma_addr = (dma_addr_t)mem_addr;
} else
mem_addr = dma_alloc_coherent(NULL, memsz, &dma_addr,
GFP_KERNEL);
@@ -206,6 +206,7 @@
pinfo->dp_addr = dp_offset;
pinfo->mem_addr = mem_addr;
pinfo->dma_addr = dma_addr;
+ pinfo->dma_offset = (dma_addr_t)((unsigned long)dma_addr - (unsigned
long)mem_addr);
pinfo->rx_buf = mem_addr;
pinfo->tx_buf = pinfo->rx_buf + L1_CACHE_ALIGN(pinfo->rx_nrfifos
--- drivers/serial/cpm_uart/cpm_uart_core.c (revision 518)
+++ drivers/serial/cpm_uart/cpm_uart_core.c (working copy)
@@ -71,17 +71,19 @@
/**************************************************************/
-static inline unsigned long cpu2cpm_addr(void *addr)
+static inline unsigned long cpu2cpm_addr(void *addr, unsigned long offset)
{
- if ((unsigned long)addr >= CPM_ADDR)
- return (unsigned long)addr;
+ if (((unsigned long)addr >= CPM_ADDR)
+ || ((unsigned long)addr >= CONFIG_CONSISTENT_START))
+ return (unsigned long)addr + offset;
return virt_to_bus(addr);
}
-static inline void *cpm2cpu_addr(unsigned long addr)
+static inline void *cpm2cpu_addr(unsigned long addr, unsigned long offset)
{
- if (addr >= CPM_ADDR)
- return (void *)addr;
+ if (((unsigned long)(addr - offset) >= CPM_ADDR)
+ || ((unsigned long)(addr - offset) >=
CONFIG_CONSISTENT_START))
+ return (void *)(addr - offset);
return bus_to_virt(addr);
}
@@ -261,7 +262,7 @@
}
/* get pointer */
- cp = cpm2cpu_addr(bdp->cbd_bufaddr);
+ cp = cpm2cpu_addr(bdp->cbd_bufaddr, pinfo->dma_offset);
/* loop through the buffer */
while (i-- > 0) {
@@ -615,7 +605,7 @@
/* Pick next descriptor and fill from buffer */
bdp = pinfo->tx_cur;
- p = cpm2cpu_addr(bdp->cbd_bufaddr);
+ p = cpm2cpu_addr(bdp->cbd_bufaddr, pinfo->dma_offset);
*p++ = xmit->buf[xmit->tail];
bdp->cbd_datlen = 1;
@@ -642,7 +632,7 @@
while (!(bdp->cbd_sc & BD_SC_READY) && (xmit->tail != xmit->head)) {
count = 0;
- p = cpm2cpu_addr(bdp->cbd_bufaddr);
+ p = cpm2cpu_addr(bdp->cbd_bufaddr, pinfo->dma_offset);
while (count < pinfo->tx_fifosize) {
*p++ = xmit->buf[xmit->tail];
xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
@@ -680,6 +670,7 @@
{
int i;
u8 *mem_addr;
+ unsigned long dma_offset;
volatile cbd_t *bdp;
pr_debug("CPM uart[%d]:initbd\n", pinfo->port.line);
@@ -689,14 +680,15 @@
* virtual address for us to work with.
*/
mem_addr = pinfo->mem_addr;
+ dma_offset = pinfo->dma_offset;
bdp = pinfo->rx_cur = pinfo->rx_bd_base;
for (i = 0; i < (pinfo->rx_nrfifos - 1); i++, bdp++) {
- bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr);
+ bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr, dma_offset);
bdp->cbd_sc = BD_SC_EMPTY | BD_SC_INTRPT;
mem_addr += pinfo->rx_fifosize;
}
- bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr);
+ bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr, dma_offset);
bdp->cbd_sc = BD_SC_WRAP | BD_SC_EMPTY | BD_SC_INTRPT;
/* Set the physical address of the host memory
@@ -706,12 +698,12 @@
mem_addr = pinfo->mem_addr + L1_CACHE_ALIGN(pinfo->rx_nrfifos *
pinfo->rx_fifosize);
bdp = pinfo->tx_cur = pinfo->tx_bd_base;
for (i = 0; i < (pinfo->tx_nrfifos - 1); i++, bdp++) {
- bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr);
+ bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr, dma_offset);
bdp->cbd_sc = BD_SC_INTRPT;
mem_addr += pinfo->tx_fifosize;
}
- bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr);
+ bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr, dma_offset);
bdp->cbd_sc = BD_SC_WRAP | BD_SC_INTRPT;
}
@@ -1041,7 +1033,7 @@
* If the buffer address is in the CPM DPRAM, don't
* convert it.
*/
- cp = cpm2cpu_addr(bdp->cbd_bufaddr);
+ cp = cpm2cpu_addr(bdp->cbd_bufaddr, pinfo->dma_offset);
*cp = *s;
@@ -1058,7 +1050,7 @@
while ((bdp->cbd_sc & BD_SC_READY) != 0)
;
- cp = cpm2cpu_addr(bdp->cbd_bufaddr);
+ cp = cpm2cpu_addr(bdp->cbd_bufaddr,
pinfo->dma_offset);
*cp = 13;
bdp->cbd_datlen = 1;
======================================================
cpm_uart_cpm2.c may need the same changes as cpm_uart_cpm1.c.
> These modifications further remove features that have been
> part of past kernels, and it has to stop.
Hmmm. What do you mean? The driver is broken, we want to fix it.
Greetings,
--
David Jander
Protonic Holland.
tel.: +31 (0) 229 212928
fax.: +31 (0) 229 210930
Factorij 36 / 1689 AL Zwaag
^ permalink raw reply
* RE: Watchdog on MPC82xx
From: Bastos Fernandez Alexandre @ 2006-04-20 10:26 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded list
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B85964A@ismail.innsys.innovsys.com>
Rune,
> On our 8265/8280 board, the max timeout of the watchdog timer was ~1.3
> seconds, so it kept resetting before the heartbeat function got called
> on boot.
>
> I had to add a watchdog reset to time_init() because it woud pause there
> for about 2 secondfs trying to see if there was a realtime clock.
>
I think that you are OK. Using the while(1) test suggested by Paul Bilke,
I could verify that time_init() is the cause for the reset. In fact, I have
no RTC on my board (so I suppose the delay looking for it will be maximum).
Thanks
Alex Bastos
^ permalink raw reply
* Re: modules without a .toc section not loading
From: Alan Modra @ 2006-04-20 8:54 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: linuxppc-dev
In-Reply-To: <20060420005445.GA24721@curie-int.vc.shawcable.net>
On Wed, Apr 19, 2006 at 05:54:45PM -0700, Robin H. Johnson wrote:
> On Thu, Apr 20, 2006 at 09:58:30AM +0930, Alan Modra wrote:
> > > Ideas for Solutions:
> > > 1. Either the kernel needs to realize that it does not need a .toc
> > > section (I'm uncertain about this, being new to PPC).
> > > 2. GCC is at fault, and it should be generating a .toc.
> > The former.
> Ok, so in module_64.c, under what cases is .toc NOT needed?
>
> I dug at the code, and the R_PPC_REL24 blocks need the contents of the
> .toc (via stub_for_addr -> create_stub -> my_r2), and I'm not certain
> about it.
Yes, the stubs need some reasonable r2 value.
> The R_PPC64_TOC/R_PPC64_TOC16/R_PPC64_TOC16_DS blocks shouldn't be hit
> when there isn't a .toc* from what I figure.
Yes, and finding such a reloc should trigger an error.
> If the R_PPC_REL24 block won't be hit when there isn't a .toc, the check
> in module_frob_arch_sections, lines 194-197 can just be shortened as a
> fix to the problem.
You could have an R_PPC_REL24 in a module (a function call into another
module or the kernel) without a .toc. A module without a .toc section
won't itself use r2 for anything, but the any stubs added do need r2.
I'm surprised no one has fixed this. Here's a totally untested patch
that ought to do the trick (or if it doesn't, should put you on the
right path).
--- linux-2.6.16/arch/powerpc/kernel/module_64.c~ 2006-01-18 14:17:29.000000000 +1030
+++ linux-2.6.16/arch/powerpc/kernel/module_64.c 2006-04-20 18:22:42.000000000 +0930
@@ -191,8 +191,15 @@ int module_frob_arch_sections(Elf64_Ehdr
(void *)hdr
+ sechdrs[sechdrs[i].sh_link].sh_offset);
}
- if (!me->arch.stubs_section || !me->arch.toc_section) {
- printk("%s: doesn't contain .toc or .stubs.\n", me->name);
+
+ /* If we don't have a .toc, just use .stubs. Nothing in the
+ module itself should use r2, but we need to set r2 in case
+ the module calls out to other functions. */
+ if (!me->arch.toc_section)
+ me->arch.toc_section = me->arch.stubs_section;
+
+ if (!me->arch.stubs_section) {
+ printk("%s: doesn't contain .stubs.\n", me->name);
return -ENOEXEC;
}
@@ -338,11 +345,21 @@ int apply_relocate_add(Elf64_Shdr *sechd
break;
case R_PPC64_TOC:
+ if (me->arch.toc_section == me->arch.stubs_section) {
+ printk("%s: TOC reloc without .toc\n",
+ me->name);
+ return -ENOEXEC;
+ }
*(unsigned long *)location = my_r2(sechdrs, me);
break;
case R_PPC64_TOC16:
- /* Subtact TOC pointer */
+ if (me->arch.toc_section == me->arch.stubs_section) {
+ printk("%s: TOC16 reloc without .toc\n",
+ me->name);
+ return -ENOEXEC;
+ }
+ /* Subtract TOC pointer */
value -= my_r2(sechdrs, me);
if (value + 0x8000 > 0xffff) {
printk("%s: bad TOC16 relocation (%lu)\n",
@@ -355,7 +372,12 @@ int apply_relocate_add(Elf64_Shdr *sechd
break;
case R_PPC64_TOC16_DS:
- /* Subtact TOC pointer */
+ if (me->arch.toc_section == me->arch.stubs_section) {
+ printk("%s: TOC16_DS reloc without .toc\n",
+ me->name);
+ return -ENOEXEC;
+ }
+ /* Subtract TOC pointer */
value -= my_r2(sechdrs, me);
if ((value & 3) != 0 || value + 0x8000 > 0xffff) {
printk("%s: bad TOC16_DS relocation (%lu)\n",
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply
* problem with watchdog/reboot MPC5200
From: Arno Geissel @ 2006-04-20 9:46 UTC (permalink / raw)
To: linuxppc-embedded
Hello all,
I have a custom board based on MPC5200 processor running
the latest linuxppc_2_4_devel.
Everything is working fine until a flash write access is performed
using MTD. After this a (soft) reboot stucks in mpc5xxx_restart()
where the watchdog timer is charged and linux waits with closed
interrupts until the MPC performs the reset. Only power off helps
in this situation.
It seems to me like a hardware problem, because the freescale
MPC5200lite reference board does not run into this.
The main difference of the custom board to the reference board
is, that it is using 16MB Intel Strada Flash instead of AMD flash,
which has an erase block size of 128kB.
Has anybody else experienced such behaviour?
Arno Geissel
^ permalink raw reply
* Re: problem with watchdog/reboot MPC5200
From: Jaap-Jan Boor @ 2006-04-20 10:21 UTC (permalink / raw)
To: jgeissel; +Cc: linuxppc-embedded
In-Reply-To: <200604201146.01342.jgeissel@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]
Arno,
I think your problem is related to Intel Strataflash specifics.
After a write to strataflash, it remains in status mode until another
read (or reset) command is issued. This means you don't get the flash
contents when reading it, but a status bit (e.g. 0x8080 at every spot).
So when the processor start executing after a reset, it's not reading
proper instructions.
You first need to e.g. write a reset cmd (0x5050) to it or connect
the processor's hardreset line to the flash device.
Jaap-Jan
On Thu, 2006-04-20 at 11:46 +0200, Arno Geissel wrote:
> Hello all,
>
> I have a custom board based on MPC5200 processor running
> the latest linuxppc_2_4_devel.
> Everything is working fine until a flash write access is performed
> using MTD. After this a (soft) reboot stucks in mpc5xxx_restart()
> where the watchdog timer is charged and linux waits with closed
> interrupts until the MPC performs the reset. Only power off helps
> in this situation.
> It seems to me like a hardware problem, because the freescale
> MPC5200lite reference board does not run into this.
> The main difference of the custom board to the reference board
> is, that it is using 16MB Intel Strada Flash instead of AMD flash,
> which has an erase block size of 128kB.
> Has anybody else experienced such behaviour?
>
> Arno Geissel
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 1513 bytes --]
^ permalink raw reply
* Re: problem with watchdog/reboot MPC5200
From: Arno Geissel @ 2006-04-20 11:34 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1145528473.13114.6.camel@linpc041.aimsys.nl>
Jaap-Jan,
I'm not booting from flash. The kernel is loaded using bootp and
the rootfs is mounted over NFS. Flash is not needed for the boot
process at all. Fact is, that the mpc5200 watchdog timer
does not work, if I have written something to flash while runtime of
the system. If I have not, the reboot, which uses the watchdog,
performs OK.
On the other hand I would expect that the MTD package should
know how to handle an Intel Strataflash.
Arno
> Arno,
>
> I think your problem is related to Intel Strataflash specifics.
> After a write to strataflash, it remains in status mode until another
> read (or reset) command is issued. This means you don't get the flash
> contents when reading it, but a status bit (e.g. 0x8080 at every spot).
> So when the processor start executing after a reset, it's not reading
> proper instructions.
>
> You first need to e.g. write a reset cmd (0x5050) to it or connect
> the processor's hardreset line to the flash device.
>
> Jaap-Jan
>
> On Thu, 2006-04-20 at 11:46 +0200, Arno Geissel wrote:
> > Hello all,
> >
> > I have a custom board based on MPC5200 processor running
> > the latest linuxppc_2_4_devel.
> > Everything is working fine until a flash write access is performed
> > using MTD. After this a (soft) reboot stucks in mpc5xxx_restart()
> > where the watchdog timer is charged and linux waits with closed
> > interrupts until the MPC performs the reset. Only power off helps
> > in this situation.
> > It seems to me like a hardware problem, because the freescale
> > MPC5200lite reference board does not run into this.
> > The main difference of the custom board to the reference board
> > is, that it is using 16MB Intel Strada Flash instead of AMD flash,
> > which has an erase block size of 128kB.
> > Has anybody else experienced such behaviour?
> >
> > Arno Geissel
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: problem with watchdog/reboot MPC5200
From: Joakim Tjernlund @ 2006-04-20 12:06 UTC (permalink / raw)
To: jgeissel, linuxppc-embedded
=20
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+joakim.tjernlund=3Dlumentis.se@ozlabs.
> org=20
> [mailto:linuxppc-embedded-bounces+joakim.tjernlund=3Dlumentis.se
> @ozlabs.org] On Behalf Of Arno Geissel
> Sent: 20 April 2006 13:35
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: problem with watchdog/reboot MPC5200
>=20
> Jaap-Jan,
>=20
> I'm not booting from flash. The kernel is loaded using bootp and
> the rootfs is mounted over NFS. Flash is not needed for the boot
> process at all. Fact is, that the mpc5200 watchdog timer
> does not work, if I have written something to flash while runtime of
> the system. If I have not, the reboot, which uses the watchdog,
> performs OK.
> On the other hand I would expect that the MTD package should
> know how to handle an Intel Strataflash.
>=20
> Arno
I think you need to connect your flash reset pin to the MPC reset pin so
that
the CPU reset will reset the flash as well.
Jocke
^ permalink raw reply
* Re: problem with watchdog/reboot MPC5200
From: Arno Geissel @ 2006-04-20 13:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <F6AD7E21CDF4E145A44F61F43EE6D9396B20F9@tmnt04.transmode.se>
Confirmed! Using the MPC reset pin (instead of PORESET)
solves it.
Thank you all
Arno
> You first need to e.g. write a reset cmd (0x5050) to it or connect
> the processor's hardreset line to the flash device.
> Jaap-Jan
>
> I think you need to connect your flash reset pin to the MPC reset pin so
> that
> the CPU reset will reset the flash as well.
>
> Jocke
^ permalink raw reply
* Re: 2.6.16 backtrace at boot (Ibook G4) (related to "PowerBook5,4 -- no sound?")
From: Michael Schmitz @ 2006-04-20 13:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: [ATR]Dj-Death, linuxppc-dev, debian-powerpc, Paul Mackerras
In-Reply-To: <1145423962.9924.40.camel@localhost.localdomain>
> > arch/powerpc/platforms/powermac/setup.c:721: error: 'mach_powermac' undeclared here (not in a function)
> > arch/powerpc/platforms/powermac/setup.c:721: warning: type defaults to 'int' in declaration of 'mach_powermac'
> > make[2]: *** [arch/powerpc/platforms/powermac/setup.o] Error 1
> > make[1]: *** [arch/powerpc/platforms/powermac] Error 2
> > make: *** [arch/powerpc/platforms] Error 2
That's how far I got on my own (didn't try Bens patch yet but machine_id
is in fact still OK in the module, so exporting the necessary bits should
fix it.
Commenting out the -ENODEV return gives me working sound; didn't I mention
that?
> > However, I tried adding "EXPORT_SYMBOL(mach_powermac);" after the
> > define_machine(powermac) and now sound works for me with my original
> > I2C_POWERMAC=y SND_POWERMAC=m configuration.
>
> Yup, Paul has a working patch already, will be in 2.6.17 soonish.
I'll pull the current tree as soon as I'm back at the lab.
Michael
^ permalink raw reply
* powermac S900 6 slot PCI broken in 2.6.16
From: Robert Brose @ 2006-04-20 15:22 UTC (permalink / raw)
To: linuxppc-dev
The s900 has a 6 slot PCI bus. It works fine in 2.6.15. In 2.6.16 it
appears the interrupts are being assigned in an incorrect way, I get
an interrupt assignment failure on the device on the 21052 bridge.
(notice in the interrupt assignment at the end that the stuff on the
bridge is on irq 25 when it works in 2.6.15 and irq 1 when it doesn't
work in 2.6.16).
2.6.16 relevant dmesg
irq: Found primary Apple PIC /bandit/gc for 32 irqs
irq: System has 32 possible interrupts
.
.
ohci_hcd 0000:01:03.0: Unlink after no-IRQ? Controller is probably using the wrong IRQ.
lspci
0000:00:0b.0 Host bridge: Apple Computer Inc. Bandit PowerPC host bridge (rev 03)
0000:00:0f.0 PCI bridge: Digital Equipment Corporation DECchip 21052 (rev 01)
0000:00:10.0 ff00: Apple Computer Inc. Grand Central I/O (rev 02)
2.6.16 /proc/interrupts
CPU0
1: 0 PMAC-PIC Edge ohci1394, ohci_hcd:usb1
2: 0 PMAC-PIC Edge MACE-txdma
3: 302 PMAC-PIC Edge MACE-rxdma
8: 0 PMAC-PIC Edge Built-in Sound out
9: 0 PMAC-PIC Edge Built-in Sound in
13: 37 PMAC-PIC Edge MESH
14: 640 PMAC-PIC Edge MACE
17: 0 PMAC-PIC Edge Built-in Sound misc
18: 18917 PMAC-PIC Edge ADB
19: 0 PMAC-PIC Edge SWIM3
23: 452 PMAC-PIC Level eth0
24: 1159 PMAC-PIC Level ide0
BAD: 0
2.6.15 /proc/interrupts
CPU0
2: 0 PMAC-PIC Edge MACE-txdma
3: 3233732 PMAC-PIC Edge MACE-rxdma
8: 0 PMAC-PIC Edge Built-in Sound out
9: 0 PMAC-PIC Edge Built-in Sound in
13: 109 PMAC-PIC Edge MESH
14: 3148467 PMAC-PIC Edge MACE
15: 4 PMAC-PIC Edge PowerMac Zilog
17: 0 PMAC-PIC Edge Built-in Sound misc
18: 18746 PMAC-PIC Edge ADB
19: 0 PMAC-PIC Edge SWIM3
23: 1123909 PMAC-PIC Level eth0
24: 403989 PMAC-PIC Level ide0
25: 9440212 PMAC-PIC Level ohci1394, ohci_hcd:usb1, r128@PCI:1:0:0
Bob
^ permalink raw reply
* Re: [PATCH] DTC - validation by device_type
From: Jon Loeliger @ 2006-04-20 15:35 UTC (permalink / raw)
To: Paul Nasrat; +Cc: linuxppc-dev@ozlabs.org, Jon Loeliger
In-Reply-To: <1143599612.2704.14.camel@enki.eridu>
On Tue, 2006-03-28 at 20:33, Paul Nasrat wrote:
> Signed-off-by: Paul Nasrat <pnasrat@redhat.com>
Paul,
Sorry about the hang-time here. Couple questions.
> +static int check_network(struct node *net)
> +{
> +
> + int ok = 1;
> + struct property *prop;
> +
> + CHECK_HAVE(net, "reg");
> + CHECK_HAVE(net, "local-mac-address");
> + CHECK_HAVE(net, "mac-address");
> + CHECK_HAVE(net, "address-bits");
> +
> + return ok;
> +}
This says that all network nodes have to have all four
of those properties. It's not clear to me that they all
need to have both local-mac-address and mac-address.
Specifically, 1275 seems to indicate to me that the
mac-address property, being introduced by the open
operation, might be dynamically set at run time, rather
than passed as a config parameter from, say, U-Boot to
the kernel. Thus, it might not be necessary here.
Should this check be more like "has at least one of
local-mac-address and mac-address" instead?
> +static struct {
> + char *devtype;
> + int (*check_fn)(struct node *node);
> +} devtype_checker_table[] = {
> + {"network", check_network},
> +};
> +
> +static int check_devtypes(struct node *root)
> +{
> +
> + struct node *child;
> + struct property *prop;
> + int ok = 1;
> + int i;
> +
> + for_each_child(root, child) {
> + /* check this node */
> + if ((prop = get_property((child), ("device_type"))))
> + for (i = 0; i < ARRAY_SIZE(devtype_checker_table); i++) {
> + if (streq(prop->val.val, devtype_checker_table[i].devtype))
> + if (! devtype_checker_table[i].check_fn(child)) {
> + ok = 0;
> + break;
> + }
> + }
> + ok = check_devtypes(child);
> + }
> +
> + return ok;
> +}
> +
> static int check_root(struct node *root)
> {
> struct property *prop;
> @@ -716,6 +761,7 @@ int check_device_tree(struct node *dt)
> ok = ok && check_cpus(dt);
> ok = ok && check_memory(dt);
> ok = ok && check_chosen(dt);
> + ok = ok && check_devtypes(dt);
> if (! ok)
> return 0;
I buy the rest of this.
Thanks,
jdl
^ permalink raw reply
* Re: [patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.
From: Jon Loeliger @ 2006-04-20 15:42 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
In-Reply-To: <1145383451.20176.9.camel@localhost.localdomain>
On Tue, 2006-04-18 at 13:04, Michael Ellerman wrote:
> > OK, I'm back to reading the list and beginning to catch
> > up some here...
> >
> > Let me see if I understand the consensus and direction:
> >
> > 1) DTC should NOT reserve its own blob space in the
> > memory map, as it does for generated ASM code now,
> > In all of this, I'm on deck for step 1) above.
I have updated the DTC to have several bug fixes:
- asm_emit_cell() little endian bug fix
- use two .long and not .quad directives
- Eliminate emitting memreserve for blob in ASM output
These updates are available here:
www.jdl.com/git_repos
and
git://ozlabs.org/srv/projects/dtc/dtc.git
Please verify and let me know of any problems!
> Nice summary :)
Thanks.
> I'm up for 3a, we should make redundant/overlapping reserves "harmless",
> by which I mean "not an error", but there should definitely be a warning
> in the dmesg - as it will _usually_ indicate a bug.
Please feel free to patch these into existence as needed! :-)
Thanks,
jdl
^ 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