LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* RE: XLlTemac  soft lockup BUG
From: Hugo Villeneuve @ 2008-04-21 15:19 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <48076ABA.1030500@conceptxdesign.com>

Brian Silverman wrote:
> Hugo,
> We have a design with the BCM5482, and will be trying it out shortly.
> Any chance you could post a patch of your BCM5466 mods?=20

Hi,
The main issue here is that you need to tell the LLTEMAC interface about =
the speed of your PHY. You can do this by adding this code example in =
the function=20
set_mac_speed():

---
#define BROADCOM_BCM5466_RGMII_AUX_STATUS 0x19

#define BCM5466_SPEED_1000BASE_T_FULL_DUPLEX 7
#define BCM5466_SPEED_1000BASE_T_HALF_DUPLEX 6
#define BCM5466_SPEED_100BASE_T_FULL_DUPLEX  5
#define BCM5466_SPEED_100BASE_T4             4
#define BCM5466_SPEED_100BASE_T_HALF_DUPLEX  3
#define BCM5466_SPEED_10BASE_T_FULL_DUPLEX   2
#define BCM5466_SPEED_10BASE_T_HALF_DUPLEX   1
#define BCM5466_SPEED_AN_NOT_COMPLETE        0

        u16 RegValue;

        _XLlTemac_PhyRead(&lp->Emac, lp->gmii_addr, =
BROADCOM_BCM5466_RGMII_AUX_STATUS, &RegValue);
        phylinkspeed =3D ( RegValue & 0x0700 ) >> 8; /* Keeping only =
bits 10-8 */

        /* Update TEMAC speed accordingly */
        switch (phylinkspeed) {
        case BCM5466_SPEED_1000BASE_T_FULL_DUPLEX:
        case BCM5466_SPEED_1000BASE_T_HALF_DUPLEX:
                lp->cur_speed =3D 1000;
                break;
        case BCM5466_SPEED_100BASE_T_FULL_DUPLEX:
        case BCM5466_SPEED_100BASE_T_HALF_DUPLEX:
        case BCM5466_SPEED_100BASE_T4:
                lp->cur_speed =3D 100;
                break;
        case BCM5466_SPEED_10BASE_T_FULL_DUPLEX:
        case BCM5466_SPEED_10BASE_T_HALF_DUPLEX:
                lp->cur_speed =3D 10;
                break;
        default:
                lp->cur_speed =3D 1000;
                break;
        }

        _XLlTemac_SetOperatingSpeed(&lp->Emac, lp->cur_speed);
---

Hope it helps, Hugo.


> Hugo Villeneuve wrote:
>=20
> 	linuxppc-embedded-bounces+hugo.villeneuve=3Dlyrtech.com@ozlabs.org
> wrote:=20
>=20
>=20
> 		Hi all,
>=20
> 		I am trying to switch my design from the PLB Temac to the local link
> 		temac, and i have a problem when trying to run ifconfig in my init
> 		script.  It gives me a BUG: soft lockup - CPU#0 stuck for 11s!
> 		[ifconfig:208] Here is the rest of the dump, thanks for your help in
> 		advance. [  233.114960] eth0: XLlTemac: Options: 0x3fa
>=20
> 		[  233.118449] eth0: XLlTemac: allocating interrupt 8 for fifo mode.
>=20
> 		[  237.135029] eth0: XLlTemac: We renegotiated the speed to: 100
>=20
> 		[  237.150339] eth0: XLlTemac: speed set to 100Mb/s
>=20
> 		[  244.792140] BUG: soft lockup - CPU#0 stuck for 11s!
> [ifconfig:204]=20
>=20
>=20
>=20
> 	Hi,
> 	we had a similar error message, which was caused by us selecting the
> wrong PHY type in the kernel configuration menu (latest
> linux-2.6-xlnx-git tree). In fact, we had to modify the lltemac
> driver to support our PHY (BCM5466). Once we did that, the error
> message went away.   =20
>=20
> 	Hugo V.
>=20
>=20
> 	Hugo Villeneuve
> 	Hardware developer | Concepteur mat=E9riel
> 	Lyrtech
> 	Phone/T=E9l. : (1) (418) 877-4644 #2395
> 	Toll-free/Sans frais - Canada & USA : (1) (888) 922-4644 #2395
> 	Fax/T=E9l=E9c. : (1) (418) 877-7710
> 	www.lyrtech.com
> 	Infinite possibilities...TM
>=20
> 	THIS MESSAGE AND ALL ATTACHED DOCUMENTS ARE EXCLUSIVELY INTENDED
> 	TO THE INDICATED RECIPIENTS AND ITS CONTENTS MAY BE CONFIDENTIAL.
> 	IT IS STRICTLY FORBIDDEN TO ANYONE TO TAKE COGNIZANCE, USE, OR
> 	DIVULGE THE INFORMATION CONTAINED HEREIN. IF YOU MISTAKENLY
> 	RECEIVE THIS MESSAGE, IMMEDIATELY INFORM LYRTECH AND DESTROY THE
> 	MESSAGE AND ATTACHMENTS FORTHWITH.THANK YOU.
>=20
> 	LE PRESENT MESSAGE ET LES DOCUMENTS QUI Y SONT JOINTS S'ADRESSENT
> 	EXCLUSIVEMENT AU(X)DESTINATAIRE(S) INDIQUE(S) ET LEUR TENEUR PEUT
> 	ETRE CONFIDENTIELLE. IL EST STRICTEMENT INTERDIT A QUICONQUE D'EN
> 	PRENDRE CONNAISSANCE, DE LES UTILISER OU DE LES DIVULGUER. SI
> 	VOUS RECEVEZ LE PRESENT MESSAGE PAR ERREUR, VEUILLEZ EN AVISER
> 	LYRTECH IMMEDIATEMENT ET DETRUIRE LE MESSAGE SEANCE TENANTE,
> 	AINSI QUE LES DOCUMENTS QUI Y SONT JOINTS.
> 	_______________________________________________
> 	Linuxppc-embedded mailing list
> 	Linuxppc-embedded@ozlabs.org
> 	https://ozlabs.org/mailman/listinfo/linuxppc-embedded



Hugo Villeneuve
Hardware developer | Concepteur mat=E9riel
Lyrtech
Phone/T=E9l. : (1) (418) 877-4644 #2395
Toll-free/Sans frais - Canada & USA : (1) (888) 922-4644 #2395
Fax/T=E9l=E9c. : (1) (418) 877-7710
www.lyrtech.com
Infinite possibilities...TM

THIS MESSAGE AND ALL ATTACHED DOCUMENTS ARE EXCLUSIVELY INTENDED
TO THE INDICATED RECIPIENTS AND ITS CONTENTS MAY BE CONFIDENTIAL.
IT IS STRICTLY FORBIDDEN TO ANYONE TO TAKE COGNIZANCE, USE, OR
DIVULGE THE INFORMATION CONTAINED HEREIN. IF YOU MISTAKENLY
RECEIVE THIS MESSAGE, IMMEDIATELY INFORM LYRTECH AND DESTROY THE
MESSAGE AND ATTACHMENTS FORTHWITH.THANK YOU.

LE PRESENT MESSAGE ET LES DOCUMENTS QUI Y SONT JOINTS S'ADRESSENT
EXCLUSIVEMENT AU(X)DESTINATAIRE(S) INDIQUE(S) ET LEUR TENEUR PEUT
ETRE CONFIDENTIELLE. IL EST STRICTEMENT INTERDIT A QUICONQUE D'EN
PRENDRE CONNAISSANCE, DE LES UTILISER OU DE LES DIVULGUER. SI
VOUS RECEVEZ LE PRESENT MESSAGE PAR ERREUR, VEUILLEZ EN AVISER
LYRTECH IMMEDIATEMENT ET DETRUIRE LE MESSAGE SEANCE TENANTE,
AINSI QUE LES DOCUMENTS QUI Y SONT JOINTS.

^ permalink raw reply

* Re: [PATCH] [PPC] Remove mpc8272 ads board from arch/ppc
From: Kumar Gala @ 2008-04-21 15:25 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40804191114i2cef26eegabfe9bc28d8ecc18@mail.gmail.com>


On Apr 19, 2008, at 1:14 PM, Grant Likely wrote:
> On Sat, Apr 19, 2008 at 9:52 AM, Kumar Gala  
> <galak@kernel.crashing.org> wrote:
>> We have a board port in arch/powerpc so we dont need this one  
>> anymore.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> Personally, I'd rather not do the piecemeal removal of board ports
> from arch/ppc.  We've only got one release left anyway.  Removing them
> just generates more churn and has the risk of causing other side
> effects.

I can understand it, but I think removing them makes it obvious to  
anyone that's lurking.  Call in maintainer prerogative :)

- k

^ permalink raw reply

* Re: Xilinx network trouble (mostly solved)
From: Guillaume Dargaud @ 2008-04-21 16:16 UTC (permalink / raw)
  To: Rick Moleres, linuxppc-dev
In-Reply-To: <20080418161454.E9E0C44009E@mail114-dub.bigfish.com>

Hi Rick,

> You might try v1.00a of the xps_ll_temac core.  There are a couple of
> issues with v1.00b (posted previously on this list) that may (or may
> not) be causing the problem you see.

Thanks for the answer... but I can't figure out how to revert to 1.00a. Is 
the option accessible from xps ?

As for the EmacLite, it works rather imperfectly:
ping -s 2952 works
ping -s 2953 doesn't...:
[ 2340.664293] Badness at net/core/skbuff.c:317
[ 2340.668479] NIP: c015bd24 LR: c015b3f4 CTR: 00000000
[ 2340.673410] REGS: c7d0fd20 TRAP: 0700   Not tainted  (2.6.24-rc8-xlnx)
[ 2340.679876] MSR: 00029030 <EE,ME,IR,DR>  CR: 28000048  XER: 20000000
[ 2340.686189] TASK = c7c35810[243] 'ping' THREAD: c7d0e000
[ 2340.691279] GPR00: 00000001 c7d0fdd0 c7c35810 c7d318e0 80000009 00000004 
c027bd38 00000200
[ 2340.699571] GPR08: c7d0fdb8 c7d0e000 c027bd1c c0159910 c7d0fdb8 100b46f4 
ffffffff 00000000
[ 2340.707864] GPR16: 10090000 100bd6e0 100b0000 100b0000 00000c11 7fbcf9a0 
00000000 10004634
[ 2340.716158] GPR24: 1007d370 7fbced90 10003fbc 100adf18 00000000 00000000 
c7c9e000 c7d318e0
[ 2340.724625] NIP [c015bd24] skb_release_all+0x6c/0x94
[ 2340.729551] LR [c015b3f4] __kfree_skb+0x18/0xc0
[ 2340.734042] Call Trace:
[ 2340.736465] [c7d0fdd0] [c0161b6c] netif_rx+0x124/0x158 (unreliable)
[ 2340.742684] [c7d0fde0] [c015b3f4] __kfree_skb+0x18/0xc0
[ 2340.747866] [c7d0fdf0] [c01466a0] SendHandler+0x44/0x94
[ 2340.753050] [c7d0fe10] [c0147284] XEmacLite_InterruptHandler+0x12c/0x140
[ 2340.759702] [c7d0fe20] [c0146078] xemaclite_interrupt+0x20/0x34
[ 2340.765577] [c7d0fe30] [c003c98c] handle_IRQ_event+0x4c/0xa0
[ 2340.771193] [c7d0fe50] [c003ca94] __do_IRQ+0xb4/0x130
[ 2340.776203] [c7d0fe70] [c0006990] do_IRQ+0x6c/0xa4
[ 2340.780954] [c7d0fe80] [c000329c] ret_from_except+0x0/0x18
[ 2340.786397] [c7d0ff40] [c0002c50] ret_from_syscall+0x0/0x3c
[ 2340.791923] Instruction dump:
[ 2340.794865] 3000ffff 7c005a2c 7c00592d 40a2fff0 817f006c 54290024 
2f8b0000 419e0024
[ 2340.802549] 8009000c 5400011e 7c0000d0 54000ffe <0f000000> 7fe3fb78 
7d6903a6 4e800421
 (192.168.1.185): 2953 data bytes
-- 
Guillaume Dargaud
http://www.gdargaud.net/ 

^ permalink raw reply

* RFC: Possible section mismatch problem in ibm_newemac?
From: Steven A. Falco @ 2008-04-21 16:02 UTC (permalink / raw)
  To: linuxppc-dev

I am using a recent DENX git tree.  I want to enable debugging in prom_parse.c.
When I do that, I see link warnings like:

WARNING: drivers/net/ibm_newemac/ibm_newemac.o(.data+0x6e0): Section mismatch in reference from the variable emac_of_bus_notifier to the function .devinit.text:emac_of_bus_notify()
The variable emac_of_bus_notifier references
the function __devinit emac_of_bus_notify()

WARNING: drivers/net/ibm_newemac/built-in.o(.devinit.text+0x14d4): Section mismatch in reference from the function emac_probe() to the function .devexit.text:rgmii_detach()
The function __devinit emac_probe() references
a function __devexit rgmii_detach().

I've made the following changes, which clean up the link warnings, but I'm not
sure this is the right way to fix the problem.  If it is correct, I'd like to
submit the patch.

Signed-off-by: Steve Falco <sfalco@harris.com>
---

diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 5153901..d54393e 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -2241,7 +2241,7 @@ static int __devinit emac_of_bus_notify(struct notifier_block *nb,
 	return 0;
 }
 
-static struct notifier_block emac_of_bus_notifier = {
+static struct notifier_block __devinitdata emac_of_bus_notifier = {
 	.notifier_call = emac_of_bus_notify
 };
 
diff --git a/drivers/net/ibm_newemac/mal.c b/drivers/net/ibm_newemac/mal.c
index fb9c9eb..e9dbd6b 100644
--- a/drivers/net/ibm_newemac/mal.c
+++ b/drivers/net/ibm_newemac/mal.c
@@ -61,7 +61,7 @@ int __devinit mal_register_commac(struct mal_instance	*mal,
 	return 0;
 }
 
-void __devexit mal_unregister_commac(struct mal_instance	*mal,
+void mal_unregister_commac(struct mal_instance	*mal,
 				     struct mal_commac		*commac)
 {
 	unsigned long flags;
diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
index 5757788..e32da3d 100644
--- a/drivers/net/ibm_newemac/rgmii.c
+++ b/drivers/net/ibm_newemac/rgmii.c
@@ -179,7 +179,7 @@ void rgmii_put_mdio(struct of_device *ofdev, int input)
 	mutex_unlock(&dev->lock);
 }
 
-void __devexit rgmii_detach(struct of_device *ofdev, int input)
+void rgmii_detach(struct of_device *ofdev, int input)
 {
 	struct rgmii_instance *dev = dev_get_drvdata(&ofdev->dev);
 	struct rgmii_regs __iomem *p = dev->base;
diff --git a/drivers/net/ibm_newemac/zmii.c b/drivers/net/ibm_newemac/zmii.c
index 2ea472a..17b1541 100644
--- a/drivers/net/ibm_newemac/zmii.c
+++ b/drivers/net/ibm_newemac/zmii.c
@@ -189,7 +189,7 @@ void zmii_set_speed(struct of_device *ofdev, int input, int speed)
 	mutex_unlock(&dev->lock);
 }
 
-void __devexit zmii_detach(struct of_device *ofdev, int input)
+void zmii_detach(struct of_device *ofdev, int input)
 {
 	struct zmii_instance *dev = dev_get_drvdata(&ofdev->dev);
 

^ permalink raw reply related

* Re: pci issue - wrong detection of pci ressources
From: Sergei Shtylyov @ 2008-04-21 16:20 UTC (permalink / raw)
  To: Christian Ehrhardt; +Cc: linuxppc-dev, Hollis Blanchard
In-Reply-To: <480CAFD2.2050108@ru.mvista.com>

Hello, I wrote:

>    Ah, that's what happens -- BAR0 in functions 0/1 takes up the whole 
> 265 MiB of the PCI memory space (128+128), so no place is left for other 
> memory BARs.

    What's interesting, the Sequoia/Rainier board user manual says that PCI 
memory is 0x80000000 thru 0xbfffffff (i.e. 1 GiB), while the Linux code seem 
to always have assumed only 0x[1]800000000 thru 0x[1]8fffffff...

WBR, Sergei

^ permalink raw reply

* Re: [PATCH 1/5] [POWERPC] sysdev: implement FSL GTM support
From: Segher Boessenkool @ 2008-04-21 16:28 UTC (permalink / raw)
  To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080421142826.GA19458@polina.dev.rtsoft.ru>

>>>  +static inline void gtm_ack_timer16(struct gtm_timer *tmr, u16 
>>> events)
>>>  +{
>>>  +       out_be16(tmr->gtevr, events);
>>>  +}
>>
>> Drop 'inline' and expect gcc to do the right thing.
>
> Not sure about newer gccs, but older complained about "defined but not
> used" functions w/o inline keyword. I'm almost sure that this is still
> true.

It is.  So why is it unused?  Because you put the code in the header
file.  Can't you move it to the .c file instead?

> I can surely use __maybe_unused, but "static inline" is pretty
> settled tradition, plus this function is small enough anyway.

All code in header files should be inline.  Code in implementation
files should only be inline if you have a very good reason for
doing so.  Same goes for __maybe_unused.


Segher

^ permalink raw reply

* Re: [PATCH 4/5] [POWERPC] QE: implement support for the GPIO LIB API
From: Segher Boessenkool @ 2008-04-21 16:30 UTC (permalink / raw)
  To: avorontsov; +Cc: linuxppc-dev, David Brownell
In-Reply-To: <20080421143313.GB18008@polina.dev.rtsoft.ru>

>> Also, why is <bank> encoded in compatible?  Do the different banks
>> have different register interfaces?
>
> Yes, they could. For example, interrupt pins are bank-specific.

In what way?  If different banks just have different IRQ #s,
there are easier ways to express this.


Segher

^ permalink raw reply

* Re: [PATCH 4/5] [POWERPC] QE: implement support for the GPIO LIB API
From: Anton Vorontsov @ 2008-04-21 16:41 UTC (permalink / raw)
  To: Grant Likely; +Cc: David Brownell, linuxppc-dev
In-Reply-To: <fa686aa40804210758r70a5906eqb090cd3d8b797317@mail.gmail.com>

On Mon, Apr 21, 2008 at 08:58:09AM -0600, Grant Likely wrote:
> On Mon, Apr 21, 2008 at 8:49 AM, Anton Vorontsov
> <avorontsov@ru.mvista.com> wrote:
> >  > > Should this really be a arch_initcall()?  Would it be better for
> >  > > platforms needing it to call it explicitly from one of the platform's
> >  > > machine_arch_initcall()?  Otherwise it gets called for all platforms
> >  > > in a multiplatform kernel.
> >  >
> >  > Ok, I'll place it into qe_reset().
> >
> >  Ugh, no, I can't. qe_reset() is called too early. And I don't like
> >  having every QE board file to call this through machine_arch_initcall...
> >  Hmm, what to do.. well, is this thaat bad to call this for every
> >  platform?..
> 
> Its not great.  It has a boot time impact for every platform compiled
> into the kernel.  The problem gets worse every time another block of
> code uses this method.  Personally I prefer platform code calling it
> explicitly.
> 
> Making it an of_platform device would also eliminate that problem, but
> you'd need a method to synchronize the driver with its users.
> 
> I'm not going to raise a big stink about it, but the issue should not
> be ignored.

Heh.. how QE GPIO is different from FSL GTM then? Should I call
fsl_gtm_init() from the board file too? For the every board? I do
believe that years later someone will show up with something like this:


 From: J. Random Hacker
 Subject: [POWERPC] cleanup board initialization code

 This patch removes vast amount of machine_arch_initcall()s that were
 used to solely initialize some hardware, like this:

 qe_add_gpio_chips();
 fsl_gtm_init();
 fsl_spi_init();
 ...

 So, instead of calling this stuff from the board files, we implement
 own arch_initcalls for these functions.

 This causes negligible run-time overhead for the boards that aren't
 using that hardware, but this overhead isn't measurable anyway. Also,
 this patch shrinks .text size a bit, and produces nice looking diffstat.

 12 file changed, 6 insertions(+), 140 deletions(-)

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

^ permalink raw reply

* RE: Xilinx network trouble (mostly solved)
From: Stephen Neuendorffer @ 2008-04-21 16:50 UTC (permalink / raw)
  To: Guillaume Dargaud, Rick Moleres, linuxppc-dev
In-Reply-To: <05d401c8a3cb$0b3cc640$ad289e86@LPSC0173W>


The easiest way is to edit the .mhs by hand.

Steve

> -----Original Message-----
> From: =
linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org] On Behalf Of
Guillaume Dargaud
> Sent: Monday, April 21, 2008 9:16 AM
> To: Rick Moleres; linuxppc-dev@ozlabs.org
> Subject: Re: Xilinx network trouble (mostly solved)
>=20
> Hi Rick,
>=20
> > You might try v1.00a of the xps_ll_temac core.  There are a couple
of
> > issues with v1.00b (posted previously on this list) that may (or may
> > not) be causing the problem you see.
>=20
> Thanks for the answer... but I can't figure out how to revert to
1.00a. Is
> the option accessible from xps ?
>=20
> As for the EmacLite, it works rather imperfectly:
> ping -s 2952 works
> ping -s 2953 doesn't...:
> [ 2340.664293] Badness at net/core/skbuff.c:317
> [ 2340.668479] NIP: c015bd24 LR: c015b3f4 CTR: 00000000
> [ 2340.673410] REGS: c7d0fd20 TRAP: 0700   Not tainted
(2.6.24-rc8-xlnx)
> [ 2340.679876] MSR: 00029030 <EE,ME,IR,DR>  CR: 28000048  XER:
20000000
> [ 2340.686189] TASK =3D c7c35810[243] 'ping' THREAD: c7d0e000
> [ 2340.691279] GPR00: 00000001 c7d0fdd0 c7c35810 c7d318e0 80000009
00000004
> c027bd38 00000200
> [ 2340.699571] GPR08: c7d0fdb8 c7d0e000 c027bd1c c0159910 c7d0fdb8
100b46f4
> ffffffff 00000000
> [ 2340.707864] GPR16: 10090000 100bd6e0 100b0000 100b0000 00000c11
7fbcf9a0
> 00000000 10004634
> [ 2340.716158] GPR24: 1007d370 7fbced90 10003fbc 100adf18 00000000
00000000
> c7c9e000 c7d318e0
> [ 2340.724625] NIP [c015bd24] skb_release_all+0x6c/0x94
> [ 2340.729551] LR [c015b3f4] __kfree_skb+0x18/0xc0
> [ 2340.734042] Call Trace:
> [ 2340.736465] [c7d0fdd0] [c0161b6c] netif_rx+0x124/0x158 (unreliable)
> [ 2340.742684] [c7d0fde0] [c015b3f4] __kfree_skb+0x18/0xc0
> [ 2340.747866] [c7d0fdf0] [c01466a0] SendHandler+0x44/0x94
> [ 2340.753050] [c7d0fe10] [c0147284]
XEmacLite_InterruptHandler+0x12c/0x140
> [ 2340.759702] [c7d0fe20] [c0146078] xemaclite_interrupt+0x20/0x34
> [ 2340.765577] [c7d0fe30] [c003c98c] handle_IRQ_event+0x4c/0xa0
> [ 2340.771193] [c7d0fe50] [c003ca94] __do_IRQ+0xb4/0x130
> [ 2340.776203] [c7d0fe70] [c0006990] do_IRQ+0x6c/0xa4
> [ 2340.780954] [c7d0fe80] [c000329c] ret_from_except+0x0/0x18
> [ 2340.786397] [c7d0ff40] [c0002c50] ret_from_syscall+0x0/0x3c
> [ 2340.791923] Instruction dump:
> [ 2340.794865] 3000ffff 7c005a2c 7c00592d 40a2fff0 817f006c 54290024
> 2f8b0000 419e0024
> [ 2340.802549] 8009000c 5400011e 7c0000d0 54000ffe <0f000000> 7fe3fb78
> 7d6903a6 4e800421
>  (192.168.1.185): 2953 data bytes
> --
> Guillaume Dargaud
> http://www.gdargaud.net/
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

^ permalink raw reply

* [PATCH] Added device tree for media5200 evaluation board
From: Steven Cavanagh @ 2008-04-21 15:14 UTC (permalink / raw)
  To: linuxppc-embedded

Added the media5200 device tree to support the
Freescale media5200. Added board configuration
under PPC_LITE5200

Signed-off-by: Steven Cavanagh <scavanagh@secretlab.ca>
---

 arch/powerpc/boot/Makefile                   |    1 
 arch/powerpc/boot/dts/media5200.dts          |  277 ++++++++++++++++++++++++++
 arch/powerpc/platforms/52xx/Kconfig          |    3 
 arch/powerpc/platforms/52xx/mpc5200_simple.c |    1 
 4 files changed, 281 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index f2e9abe..22cb470 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -227,6 +227,7 @@ image-$(CONFIG_PPC_ADDER875)		+= cuImage.adder875-uboot \
 # Board ports in arch/powerpc/platform/52xx/Kconfig
 image-$(CONFIG_PPC_LITE5200)		+= cuImage.lite5200 cuImage.lite5200b
 image-$(CONFIG_PPC_GDC_CSB)		+= cuImage.gdc-csb gdc-csb.dtb
+image-$(CONFIG_PPC_MPC5200_SIMPLE)	+= cuImage.media5200 
 
 # Board ports in arch/powerpc/platform/82xx/Kconfig
 image-$(CONFIG_MPC8272_ADS)		+= cuImage.mpc8272ads
diff --git a/arch/powerpc/boot/dts/media5200.dts b/arch/powerpc/boot/dts/media5200.dts
new file mode 100644
index 0000000..59207e1
--- /dev/null
+++ b/arch/powerpc/boot/dts/media5200.dts
@@ -0,0 +1,277 @@
+/*
+ * Freescale Media5200  board Device Tree Source
+ *
+ * Copyright 2008 Secret Lab Technologies Ltd.
+ * Grant Likely <grant.likely@secretlab.ca>
+ * Steven Cavanagh <scavanagh@secretlab.ca>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+	model = "fsl,media5200";
+	compatible = "fsl,media5200";
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	aliases {
+		console = &console;
+		ethernet0 = &eth0;
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		PowerPC,5200@0 {
+			device_type = "cpu";
+			reg = <0>;
+			d-cache-line-size = <32>;
+			i-cache-line-size = <32>;
+			d-cache-size = <0x4000>;		// L1, 16K
+			i-cache-size = <0x4000>;		// L1, 16K
+			timebase-frequency = <0x1f78a40>;	// 33 MHz
+			bus-frequency = <0x7de2900>;		// 132 MHz
+			clock-frequency = <0x179a7b00>;		// 396 MHz
+		};
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0 0x8000000>;	// 128MB
+	};
+
+	soc@f0000000 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "fsl,mpc5200b-immr";
+		ranges = <0 0xf0000000 0xc000>;
+		reg = <0xf0000000 0x100>;
+		bus-frequency = <0x7de2900>;// 132 MHz 
+		system-frequency = <0>;		// from bootloader
+
+		cdm@200 {
+			compatible = "fsl,mpc5200b-cdm","fsl,mpc5200-cdm";
+			reg = <0x200 0x38>;
+		};
+
+		mpc5200_pic: interrupt-controller@500 {
+			// 5200 interrupts are encoded into two levels;
+			interrupt-controller;
+			#interrupt-cells = <3>;
+			device_type = "interrupt-controller";
+			compatible = "fsl,mpc5200b-pic","fsl,mpc5200-pic";
+			reg = <0x500 0x80>;
+		};
+
+		timer@600 {	// General Purpose Timer
+			compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
+			cell-index = <0>;
+			reg = <0x600 0x10>;
+			interrupts = <1 9 0>;
+			interrupt-parent = <&mpc5200_pic>;
+			fsl,has-wdt;
+		};
+
+		timer@610 {	// General Purpose Timer
+			compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
+			cell-index = <1>;
+			reg = <0x610 0x10>;
+			interrupts = <1 10 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		timer@620 {	// General Purpose Timer
+			compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
+			cell-index = <2>;
+			reg = <0x620 0x10>;
+			interrupts = <1 11 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		timer@630 {	// General Purpose Timer
+			compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
+			cell-index = <3>;
+			reg = <0x630 0x10>;
+			interrupts = <1 12 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		timer@640 {	// General Purpose Timer
+			compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
+			cell-index = <4>;
+			reg = <0x640 0x10>;
+			interrupts = <1 13 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		timer@650 {	// General Purpose Timer
+			compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
+			cell-index = <5>;
+			reg = <0x650 0x10>;
+			interrupts = <1 14 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		timer@660 {	// General Purpose Timer
+			compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
+			cell-index = <6>;
+			reg = <0x660 0x10>;
+			interrupts = <1 15 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		timer@670 {	// General Purpose Timer
+			compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
+			cell-index = <7>;
+			reg = <0x670 0x10>;
+			interrupts = <1 16 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		rtc@800 {	// Real time clock
+			compatible = "fsl,mpc5200b-rtc","fsl,mpc5200-rtc";
+			device_type = "rtc";
+			reg = <0x800 0x100>;
+			interrupts = <1 5 0 1 6 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		can@900 {
+			compatible = "fsl,mpc5200b-mscan","fsl,mpc5200-mscan";
+			cell-index = <0>;
+			interrupts = <2 17 0>;
+			interrupt-parent = <&mpc5200_pic>;
+			reg = <0x900 0x80>;
+		};
+
+		can@980 {
+			compatible = "fsl,mpc5200b-mscan","fsl,mpc5200-mscan";
+			cell-index = <1>;
+			interrupts = <2 18 0>;
+			interrupt-parent = <&mpc5200_pic>;
+			reg = <0x980 0x80>;
+		};
+
+		gpio@b00 {
+			compatible = "fsl,mpc5200b-gpio","fsl,mpc5200-gpio";
+			reg = <0xb00 0x40>;
+			interrupts = <1 7 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		gpio@c00 {
+			compatible = "fsl,mpc5200b-gpio-wkup","fsl,mpc5200-gpio-wkup";
+			reg = <0xc00 0x40>;
+			interrupts = <1 8 0 0 3 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		spi@f00 {
+			compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
+			reg = <0xf00 0x20>;
+			interrupts = <2 13 0 2 14 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		usb@1000 {
+			compatible = "fsl,mpc5200b-ohci","fsl,mpc5200-ohci","ohci-be";
+			reg = <0x1000 0x100>;
+			interrupts = <2 6 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		dma-controller@1200 {
+			device_type = "dma-controller";
+			compatible = "fsl,mpc5200b-bestcomm","fsl,mpc5200-bestcomm";
+			reg = <0x1200 0x80>;
+			interrupts = <3 0 0  3 1 0  3 2 0  3 3 0
+			              3 4 0  3 5 0  3 6 0  3 7 0
+			              3 8 0  3 9 0  3 10 0  3 11 0
+			              3 12 0  3 13 0  3 14 0  3 15 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		xlb@1f00 {
+			compatible = "fsl,mpc5200b-xlb","fsl,mpc5200-xlb";
+			reg = <0x1f00 0x100>;
+		};
+
+		// PSC6 in uart mode
+		console: serial@2c00 {		// PSC6
+			device_type = "serial";
+			compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
+			cell-index = <5>;
+			port-number = <0>;  // Logical port assignment
+			reg = <0x2c00 0x100>;
+			interrupts = <2 4 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		eth0: ethernet@3000 {
+			device_type = "network";
+			compatible = "fsl,mpc5200b-fec","fsl,mpc5200-fec";
+			reg = <0x3000 0x400>;
+			local-mac-address = [ 00 00 00 00 00 00 ];
+			interrupts = <2 5 0>;
+			interrupt-parent = <&mpc5200_pic>;
+			phy-handle = <&phy0>;
+		};
+
+		mdio@3000 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "fsl,mpc5200b-mdio", "fsl,mpc5200-mdio";
+			reg = <0x3000 0x400>;	// fec range, since we need to setup fec interrupts
+			interrupts = <2 5 0>;	// these are for "mii command finished", not link changes & co.
+			interrupt-parent = <&mpc5200_pic>;
+
+			phy0:ethernet-phy@0 {
+				device_type = "ethernet-phy";
+				reg = <0>;
+			};
+		};
+
+		ata@3a00 {
+			device_type = "ata";
+			compatible = "fsl,mpc5200b-ata","fsl,mpc5200-ata";
+			reg = <0x3a00 0x100>;
+			interrupts = <2 7 0>;
+			interrupt-parent = <&mpc5200_pic>;
+		};
+
+		i2c@3d00 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
+			cell-index = <0>;
+			reg = <0x3d00 0x40>;
+			interrupts = <2 15 0>;
+			interrupt-parent = <&mpc5200_pic>;
+			fsl5200-clocking;
+		};
+
+		i2c@3d40 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
+			cell-index = <1>;
+			reg = <0x3d40 0x40>;
+			interrupts = <2 16 0>;
+			interrupt-parent = <&mpc5200_pic>;
+			fsl5200-clocking;
+		};
+		sram@8000 {
+			compatible = "fsl,mpc5200b-sram","fsl,mpc5200-sram","sram";
+			reg = <0x8000 0x4000>;
+		};
+	};
+
+	chosen {
+		linux,stdout-path = &console;
+	};
+};
diff --git a/arch/powerpc/platforms/52xx/Kconfig b/arch/powerpc/platforms/52xx/Kconfig
index a0636d4..1914650 100644
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -21,7 +21,8 @@ config PPC_MPC5200_SIMPLE
 	    and if there is a PCI bus node defined in the device tree.
 
 	  Boards that are compatible with this generic platform support
-	  are: 'tqc,tqm5200', 'promess,motionpro', 'schindler,cm5200'.
+	  are: 'tqc,tqm5200', 'promess,motionpro', 'schindler,cm5200',
+	  'fsl,media5200'.
 
 config PPC_EFIKA
 	bool "bPlan Efika 5k2. MPC5200B based computer"
diff --git a/arch/powerpc/platforms/52xx/mpc5200_simple.c b/arch/powerpc/platforms/52xx/mpc5200_simple.c
index c48b82b..3a31576 100644
--- a/arch/powerpc/platforms/52xx/mpc5200_simple.c
+++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
@@ -53,6 +53,7 @@ static char *board[] __initdata = {
 	"promess,motionpro",
 	"schindler,cm5200",
 	"tqc,tqm5200",
+	"fsl,media5200",
 	NULL
 };
 

^ permalink raw reply related

* Re: [PATCH] [POWERPC] 52xx: defconfigs for CM5200, Lite5200B, Motion-PRO and TQM5200
From: Bartlomiej Sieka @ 2008-04-21 16:55 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40804210726w3e8f4647mbc3dad8e48a124c0@mail.gmail.com>

Grant Likely wrote:
> On Mon, Apr 21, 2008 at 7:57 AM, Bartlomiej Sieka <tur@semihalf.com> wrote:
>> Bartlomiej Sieka wrote:
>>
>>> Board-specific defconfigs based on current mpc5200_defconfig, archival
>>> lite5200_defconfig, and [cm5200|motionpro|tqm5200]_defconfig from the
>>> linux-2.6-denx tree. Kernels build using these defconfigs were verified
>>> to boot with root filesystem mounted over NFS on Motion-PRO, TQM5200
>>> and Lite5200B boards. CM5200 target was not tested due to hardware
>>> unavailability.
>>>
>>  Hello Grant,
>>
>>  There hasn't been any negitve comments on the above patch -- will you
>>  push it upstream via your tree?
> 
> Yes, of course.

Thanks -- is it safe to assume that the patch will make it into 2.6.26 then?

Regards,
Bartlomiej

^ permalink raw reply

* Re: [PATCH] [POWERPC] 52xx: defconfigs for CM5200, Lite5200B, Motion-PRO and TQM5200
From: Grant Likely @ 2008-04-21 16:58 UTC (permalink / raw)
  To: Bartlomiej Sieka; +Cc: linuxppc-dev
In-Reply-To: <480CC6F9.3050700@semihalf.com>

On Mon, Apr 21, 2008 at 10:55 AM, Bartlomiej Sieka <tur@semihalf.com> wrote:
> Grant Likely wrote:
>
> > On Mon, Apr 21, 2008 at 7:57 AM, Bartlomiej Sieka <tur@semihalf.com>
> wrote:
> >
> > > Bartlomiej Sieka wrote:
> > >
> > >
> > > > Board-specific defconfigs based on current mpc5200_defconfig, archival
> > > > lite5200_defconfig, and [cm5200|motionpro|tqm5200]_defconfig from the
> > > > linux-2.6-denx tree. Kernels build using these defconfigs were
> verified
> > > > to boot with root filesystem mounted over NFS on Motion-PRO, TQM5200
> > > > and Lite5200B boards. CM5200 target was not tested due to hardware
> > > > unavailability.
> > > >
> > > >
> > >  Hello Grant,
> > >
> > >  There hasn't been any negitve comments on the above patch -- will you
> > >  push it upstream via your tree?
> > >
> >
> > Yes, of course.
> >
>
>  Thanks -- is it safe to assume that the patch will make it into 2.6.26
> then?

Yes; defconfigs are easy to get merged.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* Re: RFC: MPC5200 PSC AC97 driver
From: Matt Sealey @ 2008-04-21 17:04 UTC (permalink / raw)
  To: Juergen Beisert; +Cc: linuxppc-dev
In-Reply-To: <200804211002.07452.jbe@pengutronix.de>


Juergen Beisert wrote:

> Please don't forget what Sylvian said about this driver: "I also completely 
> skipped the 5200 (not B) support ..." and your own "I think it should be left 
> noted here that the CCR size changed from 16 bits to 32 bits from 5200 to 
> 5200B in order to reduce confusion.". Its not solved yet. So any user of an 
> old MPC5200 will be surprised...

+static struct of_device_id mpc52xx_ac97_of_match[] = {
+	{
+		.type		= "sound",
+		.compatible	= "mpc5200b-psc-ac97",	/* B only for now */
+	},
+};

It shouldn't even load, the matchlist is 5200b only..? No alarms and no surprises.. :)

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

^ permalink raw reply

* Re: RFC: Possible section mismatch problem in ibm_newemac?
From: Josh Boyer @ 2008-04-21 17:05 UTC (permalink / raw)
  To: Steven A. Falco; +Cc: linuxppc-dev
In-Reply-To: <480CBA91.5050003@harris.com>

On Mon, 21 Apr 2008 12:02:25 -0400
"Steven A. Falco" <sfalco@harris.com> wrote:

> I am using a recent DENX git tree.  I want to enable debugging in prom_parse.c.
> When I do that, I see link warnings like:

I already sent a patch a month and a half ago to clean all these
warnings up.  It never got pushed upstream.

josh

^ permalink raw reply

* Re: Help! mpc8247 porting kernel 2.6.25 problem.
From: Scott Wood @ 2008-04-21 17:34 UTC (permalink / raw)
  To: 张世乐; +Cc: Linuxppc-embedded
In-Reply-To: <8d59c9040804202006m607fe15bre29288240b73081d@mail.gmail.com>

On Mon, Apr 21, 2008 at 11:06:28AM +0800, 张世乐 wrote:
> Uncompressing Kernel Image ... OK
> Booting using the fdt at 0x600000
> 
> [nothing output and hanging here]
> 
> I use the led on the board to trace the kernel fund it stop in the function
> 
> setup_common_caches  in arch/powerpc/kernel/cpu_setup_6xx.S
> 
> Can you give me some ideas?

That's probably not where it's actually stopping, but rather where caches
are enabled without the MMU, thus making it difficult to access devices. 
You can try placing a dcbf after each write to the LED register, though
this may perturb nearby registers.

Have you tried enabling early debug printk?

-Scott

^ permalink raw reply

* [PATCH 1/2 v2] sysdev,mv64x60: I2C defaults
From: Remi Machet @ 2008-04-21 17:36 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev

I2C parameters freq_m and freq_n are assigned default in the code
but if those properties are not found in the open firmware description 
the init returns an error => the code now uses the default
values if the properties are not found.

Signed-off-by: Remi Machet (rmachet@slac.stanford.edu)
---
This is the first part of the re-submission of my patch of 4/17/2008
titled "[PATCH] sysdev,mv64x60: initialization of mv64x60 ethernet, 
serial and I2C"

--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -338,15 +338,13 @@ static int __init mv64x60_i2c_device_setup(struct device_node *np, int id)
 
 	pdata.freq_m = 8;	/* default */
 	prop = of_get_property(np, "freq_m", NULL);
-	if (!prop)
-		return -ENODEV;
-	pdata.freq_m = *prop;
+	if (prop)
+		pdata.freq_m = *prop;
 
 	pdata.freq_m = 3;	/* default */
 	prop = of_get_property(np, "freq_n", NULL);
-	if (!prop)
-		return -ENODEV;
-	pdata.freq_n = *prop;
+	if (prop)
+		pdata.freq_n = *prop;
 
 	pdata.timeout = 1000;				/* default: 1 second */
 

^ permalink raw reply

* [PATCH 2/2 v2] sysdev,mv64x60: initialization of mv64x60 ethernet, serial and I2C
From: Remi Machet @ 2008-04-21 17:37 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev

If one of the devices of the mv64x60 init fails, the remaining 
devices are not initialized => This patch change the code to 
display an error and continue the initialization.

Signed-off-by: Remi Machet (rmachet@slac.stanford.edu)
---
This is the second part of the re-submission of my patch of 4/17/2008
titled "[PATCH] sysdev,mv64x60: initialization of mv64x60 ethernet, 
serial and I2C"

--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -431,9 +431,14 @@ static int __init mv64x60_device_setup(void)
 	int err;
 
 	id = 0;
-	for_each_compatible_node(np, "serial", "marvell,mv64360-mpsc")
-		if ((err = mv64x60_mpsc_device_setup(np, id++)))
-			goto error;
+	for_each_compatible_node(np, "serial", "marvell,mv64360-mpsc") {
+		err = mv64x60_mpsc_device_setup(np, id++);
+		if (err) {
+			printk(KERN_ERR "Failed to initialize MV64x60 " \
+					"serial device %s: error %d.\n",
+					np->full_name, err);
+		};
+	};
 
 	id = 0;
 	id2 = 0;
@@ -441,38 +446,46 @@ static int __init mv64x60_device_setup(void)
 		pdev = mv64x60_eth_register_shared_pdev(np, id++);
 		if (IS_ERR(pdev)) {
 			err = PTR_ERR(pdev);
-			goto error;
-		}
+			printk(KERN_ERR "Failed to initialize MV64x60 " \
+					"network block %s: error %d.\n",
+					np->full_name, err);
+			continue;
+		};
 		for_each_child_of_node(np, np2) {
 			if (!of_device_is_compatible(np2,
 					"marvell,mv64360-eth"))
 				continue;
 			err = mv64x60_eth_device_setup(np2, id2++, pdev);
 			if (err) {
-				of_node_put(np2);
-				goto error;
+				printk(KERN_ERR "Failed to initialize " \
+						"MV64x60 network device %s: " \
+						"error %d.\n",
+						np2->full_name, err);
 			}
 		}
 	}
 
 	id = 0;
-	for_each_compatible_node(np, "i2c", "marvell,mv64360-i2c")
-		if ((err = mv64x60_i2c_device_setup(np, id++)))
-			goto error;
+	for_each_compatible_node(np, "i2c", "marvell,mv64360-i2c") {
+		err = mv64x60_i2c_device_setup(np, id++);
+		if (err) {
+			printk(KERN_ERR "Failed to initialize MV64x60 I2C " \
+					"bus %s: error %d.\n",
+					np->full_name, err);
+		};
+	};
 
 	/* support up to one watchdog timer */
 	np = of_find_compatible_node(np, NULL, "marvell,mv64360-wdt");
 	if (np) {
 		if ((err = mv64x60_wdt_device_setup(np, id)))
-			goto error;
+			printk(KERN_ERR "Failed to initialize MV64x60 " \
+					"Watchdog %s: error %d.\n",
+					np->full_name, err);
 		of_node_put(np);
 	}
 
 	return 0;
-
-error:
-	of_node_put(np);
-	return err;
 }
 arch_initcall(mv64x60_device_setup);
 

^ permalink raw reply

* Re: [PATCH] [POWERPC] Port fixmap from x86 and use for kmap_atomic
From: Kumar Gala @ 2008-04-21 17:44 UTC (permalink / raw)
  To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20080419110740.107700@gmx.net>


On Apr 19, 2008, at 6:07 AM, Gerhard Pircher wrote:
>
> -------- Original-Nachricht --------
>> Datum: Thu, 17 Apr 2008 21:57:05 -0500 (CDT)
>> Von: Kumar Gala <galak@kernel.crashing.org>
>> An: Paul Mackerras <paulus@samba.org>
>> CC: linuxppc-dev@ozlabs.org
>> Betreff: [PATCH] [POWERPC] Port fixmap from x86 and use for  
>> kmap_atomic
>
>> The fixmap code from x86 allows us to have compile time virtual  
>> addresses
>> that we change the physical addresses of at run time.
> ...
>> +/*
>> + * Here we define all the compile-time 'special' virtual
>> + * addresses. The point is to have a constant address at
>> + * compile time, but to set the physical address only
>> + * in the boot process. We allocate these special addresses
>> + * from the end of virtual memory (0xfffff000) backwards.
>> + * Also this lets us do fail-safe vmalloc(), we
>> + * can guarantee that these special addresses and
>> + * vmalloc()-ed addresses never overlap.
> I don't understand how highmem works, but I'm just interested to  
> know, if
> this implementation could conflict somehow with the non coherent DMA
> implementation in dma-noncoherent.c (which uses address space from
> 0xff100000 to 0xff300000 for DMA memory).

if the size is fixed we can easily change it so the Kconfig options  
aren't needed anymore.

> On the other side could dma-noncoherent.c benefit from fixmaps so  
> that it
> isn't necessary to configure a start address for DMA allocations?

Its possible however the fixmap is all about keeping the VA the same  
while changing the PA. I think some work that is being done for the SW  
IOMMU might be more useful to your needs.

- k

^ permalink raw reply

* Re: Patches added to powerpc.git master and powerpc-next branches
From: Kumar Gala @ 2008-04-21 17:51 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18441.58154.608911.337978@cargo.ozlabs.ibm.com>


On Apr 19, 2008, at 7:18 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> [POWERPC] 85xx: Add support for relocatble kernel (and booting at  
>> non-
>> zero)
>
> Should be OK to go though probably not in the first batch.  I want to
> look through it carefully again since it's touching code that is
> common to a lot of platforms.  The patch description looks reasonable
> as to what it explains but the english could use a touch-up here or
> there (e.g. "a physical address that is module 256M" doesn't actually
> mean anything; "a physical address that is 0 modulo 256M" would be
> correct).

Ok.  I'll have my grammar police review it and repost.

>> [POWERPC] Port fixmap from x86 and use for kmap_atomic
>
> Once again I want to go through it carefully and understand how it all
> works, and in particular understand things like the way it ensures
> that the base address for the kmap region is aligned to a 4M boundary
> so all the kmap ptes are in a single page (assuming it does :).

I'm not clear on why this is needed.  I can see value in having the  
PGD entry in place but the pte PAs would be changing all the time so I  
don't see what benefit there is in keeping them in one page.

For normal kmap ptes we cover things in one PGD via:

#define PKMAP_BASE      ((FIXADDR_BOOT_START - PAGE_SIZE*(LAST_PKMAP +  
1)) & PMD_MASK)

The kmap_atomic ptes do NOT have a similar guarantee as they are  
controlled via fixmap.  However we do "pre-allocate" the PGD via  
calling map_page() on all fixmap addresses.

- k

^ permalink raw reply

* Re: [RFC fs_enet: Convert MII bitbang driver to use GPIO lib
From: Scott Wood @ 2008-04-21 17:56 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linuxppc-dev, netdev
In-Reply-To: <200804181334.34229.laurentp@cse-semaphore.com>

On Fri, Apr 18, 2008 at 01:34:29PM +0200, Laurent Pinchart wrote:
> Scott Wood was concerned in 
> http://patchwork.ozlabs.org/linuxppc/patch?id=17490 that the gpio lib might 
> be an unnecessary burden for memory-constraint platforms. Should we keep two 
> mdio bitbang drivers, one with direct access to the ports and one using gpio 
> lib ? The later solves the concurrent access issues present in the current 
> fs_enet mdio bitbang driber.

The memory-constrained platform I had in mind was 8xx, which doesn't use
bitbanged MDIO.  It might nice to keep the gpiolib bit separate to avoid
situations such as ep8248e where mdiobb would be the only thing requiring
a gpiolib binding, though -- but it shouldn't be two separate bitbang
drivers, just the existing bitbang driver plus some glue code that binds
it to gpiolib.

-Scott

^ permalink raw reply

* Re: [PATCH 1/2 v2] sysdev,mv64x60: I2C defaults
From: Dale Farnsworth @ 2008-04-21 17:55 UTC (permalink / raw)
  To: Remi Machet; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1208799408.5789.52.camel@pcds-ts102.slac.stanford.edu>

On Mon, Apr 21, 2008 at 10:36:48AM -0700, Remi Machet wrote:
> I2C parameters freq_m and freq_n are assigned default in the code
> but if those properties are not found in the open firmware description 
> the init returns an error => the code now uses the default
> values if the properties are not found.
> 
> Signed-off-by: Remi Machet (rmachet@slac.stanford.edu)

Acked-by: Dale Farnsworth <dale@farnsworth.org>

^ permalink raw reply

* Re: SecretLab 2.6.24 with USB
From: Grant Likely @ 2008-04-21 18:09 UTC (permalink / raw)
  To: Sam Karp; +Cc: linuxppc-embedded
In-Reply-To: <800687fe0804141927y1f6ea75cv7ad0ba68b4fa637a@mail.gmail.com>

On Mon, Apr 14, 2008 at 8:27 PM, Sam Karp <sam.d.karp@gmail.com> wrote:
> Hi all,
>
> I've downloaded the SecretLab Xilinx Linux 2.6.24 Kernel and I'm trying to
> use a thumbdrive with the kernel.  I'm booting from a ramdisk and insert the
> thumbdrive but I have no /dev/sd* or /dev/hd* blocks.  Is there anything I
> need to add to the kernel or design to ensure that the thumbdrive is working
> or getting power?

Sorry I didn't get back to you earlier.  Your best bet is to use
Xilinx's git tree and manually patch in the c67x00 driver from Peter
Korsgaard's driver.

http://www.mail-archive.com/linux-usb@vger.kernel.org/msg01907.html
http://www.mail-archive.com/linux-usb@vger.kernel.org/msg01908.html
http://www.mail-archive.com/linux-usb@vger.kernel.org/msg01906.html
http://www.mail-archive.com/linux-usb@vger.kernel.org/msg01907.html

I haven't been keeping my tree up to date lately.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* Re: [PATCH 2/2 v2] sysdev,mv64x60: initialization of mv64x60 ethernet, serial and I2C
From: Dale Farnsworth @ 2008-04-21 18:23 UTC (permalink / raw)
  To: Remi Machet; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1208799434.5789.53.camel@pcds-ts102.slac.stanford.edu>

On Mon, Apr 21, 2008 at 10:37:14AM -0700, Remi Machet wrote:
> If one of the devices of the mv64x60 init fails, the remaining 
> devices are not initialized => This patch change the code to 
> display an error and continue the initialization.
> 
> Signed-off-by: Remi Machet (rmachet@slac.stanford.edu)
> ---
> This is the second part of the re-submission of my patch of 4/17/2008
> titled "[PATCH] sysdev,mv64x60: initialization of mv64x60 ethernet, 
> serial and I2C"
> 
> --- a/arch/powerpc/sysdev/mv64x60_dev.c
> +++ b/arch/powerpc/sysdev/mv64x60_dev.c
> @@ -431,9 +431,14 @@ static int __init mv64x60_device_setup(void)
>  	int err;
>  
>  	id = 0;
> -	for_each_compatible_node(np, "serial", "marvell,mv64360-mpsc")
> -		if ((err = mv64x60_mpsc_device_setup(np, id++)))
> -			goto error;
> +	for_each_compatible_node(np, "serial", "marvell,mv64360-mpsc") {
> +		err = mv64x60_mpsc_device_setup(np, id++);
> +		if (err) {
> +			printk(KERN_ERR "Failed to initialize MV64x60 " \

No need for the backslash continuation above.  Also below.

> +					"serial device %s: error %d.\n",
> +					np->full_name, err);
> +		};

You don't need the braces around the single printk statement.

> +	};

No need for the semi-colon following closing brace, also below.

>  
>  	id = 0;
>  	id2 = 0;
> @@ -441,38 +446,46 @@ static int __init mv64x60_device_setup(void)
>  		pdev = mv64x60_eth_register_shared_pdev(np, id++);
>  		if (IS_ERR(pdev)) {
>  			err = PTR_ERR(pdev);
> -			goto error;
> -		}
> +			printk(KERN_ERR "Failed to initialize MV64x60 " \
> +					"network block %s: error %d.\n",
> +					np->full_name, err);
> +			continue;
> +		};
>  		for_each_child_of_node(np, np2) {
>  			if (!of_device_is_compatible(np2,
>  					"marvell,mv64360-eth"))
>  				continue;
>  			err = mv64x60_eth_device_setup(np2, id2++, pdev);
>  			if (err) {
> -				of_node_put(np2);
> -				goto error;
> +				printk(KERN_ERR "Failed to initialize " \
> +						"MV64x60 network device %s: " \
> +						"error %d.\n",
> +						np2->full_name, err);
>  			}
>  		}
>  	}
>  
>  	id = 0;
> -	for_each_compatible_node(np, "i2c", "marvell,mv64360-i2c")
> -		if ((err = mv64x60_i2c_device_setup(np, id++)))
> -			goto error;
> +	for_each_compatible_node(np, "i2c", "marvell,mv64360-i2c") {
> +		err = mv64x60_i2c_device_setup(np, id++);
> +		if (err) {
> +			printk(KERN_ERR "Failed to initialize MV64x60 I2C " \
> +					"bus %s: error %d.\n",
> +					np->full_name, err);
> +		};
> +	};
>  
>  	/* support up to one watchdog timer */
>  	np = of_find_compatible_node(np, NULL, "marvell,mv64360-wdt");
>  	if (np) {
>  		if ((err = mv64x60_wdt_device_setup(np, id)))
> -			goto error;
> +			printk(KERN_ERR "Failed to initialize MV64x60 " \
> +					"Watchdog %s: error %d.\n",
> +					np->full_name, err);
>  		of_node_put(np);
>  	}
>  
>  	return 0;
> -
> -error:
> -	of_node_put(np);
> -	return err;
>  }
>  arch_initcall(mv64x60_device_setup);

^ permalink raw reply

* [PATCH v7] [POWERPC] 85xx: Add support for relocatable kernel (and booting at non-zero)
From: Kumar Gala @ 2008-04-21 18:22 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev

Added support to allow an 85xx kernel to be run from a non-zero physical
address (useful for cooperative asymmetric multiprocessing situations and
kdump).  The support can be configured at compile time by setting
CONFIG_PAGE_OFFSET, CONFIG_KERNEL_START, and CONFIG_PHYSICAL_START as
desired.

Alternatively, the kernel build can set CONFIG_RELOCATABLE.  Setting this
config option causes the kernel to determine at runtime the physical
addresses of CONFIG_PAGE_OFFSET and CONFIG_KERNEL_START.  If
CONFIG_RELOCATABLE is set, then CONFIG_PHYSICAL_START has no meaning.
However, CONFIG_PHYSICAL_START will always be used to set the LOAD program
header physical address field in the resulting ELF image.

Currently we are limited to running at a physical address that is modulo
256M.  This is due to how we map TLBs to cover lowmem. This should be
fixed to allow 64M or maybe even 16M alignment in the future.  It is
considered an error to try and run a kernel at a non-aligned physical
address.

All the magic for this support is accomplished by proper initialization
of the kernel memory subsystem and use of ARCH_PFN_OFFSET.

The use of ARCH_PFN_OFFSET only affects normal memory and not IO mappings.
ioremap uses map_page and isn't affected by ARCH_PFN_OFFSET.

/dev/mem continues to allow access to any physical address in the system
regardless of how CONFIG_PHYSICAL_START is set.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---

Improved the grammar of the commit message.

- k

 arch/powerpc/Kconfig                 |   69 ++++++++++++++++++++++++++++++++-
 arch/powerpc/kernel/head_fsl_booke.S |   11 +++++
 arch/powerpc/kernel/prom.c           |    4 ++
 arch/powerpc/kernel/setup_64.c       |    2 +-
 arch/powerpc/mm/fsl_booke_mmu.c      |    2 +-
 arch/powerpc/mm/init_32.c            |    5 ++-
 arch/powerpc/mm/init_64.c            |    3 +-
 arch/powerpc/mm/mem.c                |    5 +-
 include/asm-powerpc/kdump.h          |    5 --
 include/asm-powerpc/page.h           |   45 ++++++++++++++++++----
 include/asm-powerpc/page_32.h        |    6 +++
 11 files changed, 135 insertions(+), 22 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 4bb2e93..fdc755a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -656,21 +656,76 @@ config LOWMEM_SIZE
 	hex "Maximum low memory size (in bytes)" if LOWMEM_SIZE_BOOL
 	default "0x30000000"

+config RELOCATABLE
+	bool "Build a relocatable kernel (EXPERIMENTAL)"
+	depends on EXPERIMENTAL && ADVANCED_OPTIONS && FLATMEM && FSL_BOOKE
+	help
+	  This builds a kernel image that is capable of running at the
+	  location the kernel is loaded at (some alignment restrictions may
+	  exist).
+
+	  One use is for the kexec on panic case where the recovery kernel
+	  must live at a different physical address than the primary
+	  kernel.
+
+	  Note: If CONFIG_RELOCATABLE=y, then the kernel runs from the address
+	  it has been loaded at and the compile time physical addresses
+	  CONFIG_PHYSICAL_START is ignored.  However CONFIG_PHYSICAL_START
+	  setting can still be useful to bootwrappers that need to know the
+	  load location of the kernel (eg. u-boot/mkimage).
+
+config PAGE_OFFSET_BOOL
+	bool "Set custom page offset address"
+	depends on ADVANCED_OPTIONS
+	help
+	  This option allows you to set the kernel virtual address at which
+	  the kernel will map low memory.  This can be useful in optimizing
+	  the virtual memory layout of the system.
+
+	  Say N here unless you know what you are doing.
+
+config PAGE_OFFSET
+	hex "Virtual address of memory base" if PAGE_OFFSET_BOOL
+	default "0xc0000000"
+
 config KERNEL_START_BOOL
 	bool "Set custom kernel base address"
 	depends on ADVANCED_OPTIONS
 	help
 	  This option allows you to set the kernel virtual address at which
-	  the kernel will map low memory (the kernel image will be linked at
-	  this address).  This can be useful in optimizing the virtual memory
-	  layout of the system.
+	  the kernel will be loaded.  Normally this should match PAGE_OFFSET
+	  however there are times (like kdump) that one might not want them
+	  to be the same.

 	  Say N here unless you know what you are doing.

 config KERNEL_START
 	hex "Virtual address of kernel base" if KERNEL_START_BOOL
+	default PAGE_OFFSET if PAGE_OFFSET_BOOL
+	default "0xc2000000" if CRASH_DUMP
 	default "0xc0000000"

+config PHYSICAL_START_BOOL
+	bool "Set physical address where the kernel is loaded"
+	depends on ADVANCED_OPTIONS && FLATMEM && FSL_BOOKE
+	help
+	  This gives the physical address where the kernel is loaded.
+
+	  Say N here unless you know what you are doing.
+
+config PHYSICAL_START
+	hex "Physical address where the kernel is loaded" if PHYSICAL_START_BOOL
+	default "0x02000000" if PPC_STD_MMU && CRASH_DUMP
+	default "0x00000000"
+
+config PHYSICAL_ALIGN
+	hex
+	default "0x10000000" if FSL_BOOKE
+	help
+	  This value puts the alignment restrictions on physical address
+	  where kernel is loaded and run from. Kernel is compiled for an
+	  address which meets above alignment restriction.
+
 config TASK_SIZE_BOOL
 	bool "Set custom user task size"
 	depends on ADVANCED_OPTIONS
@@ -717,9 +772,17 @@ config PIN_TLB
 endmenu

 if PPC64
+config PAGE_OFFSET
+	hex
+	default "0xc000000000000000"
 config KERNEL_START
 	hex
+	default "0xc000000002000000" if CRASH_DUMP
 	default "0xc000000000000000"
+config PHYSICAL_START
+	hex
+	default "0x02000000" if CRASH_DUMP
+	default "0x00000000"
 endif

 source "net/Kconfig"
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index 4ff7441..e581524 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -371,6 +371,17 @@ skpinv:	addi	r6,r6,1				/* Increment */

 	bl	early_init

+#ifdef CONFIG_RELOCATABLE
+	lis	r3,kernstart_addr@ha
+	la	r3,kernstart_addr@l(r3)
+#ifdef CONFIG_PHYS_64BIT
+	stw	r23,0(r3)
+	stw	r25,4(r3)
+#else
+	stw	r25,0(r3)
+#endif
+#endif
+
 	mfspr	r3,SPRN_TLB1CFG
 	andi.	r3,r3,0xfff
 	lis	r4,num_tlbcam_entries@ha
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 3bfe783..2aefe2a 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -53,6 +53,7 @@
 #include <asm/pci-bridge.h>
 #include <asm/phyp_dump.h>
 #include <asm/kexec.h>
+#include <mm/mmu_decl.h>

 #ifdef DEBUG
 #define DBG(fmt...) printk(KERN_ERR fmt)
@@ -978,7 +979,10 @@ static int __init early_init_dt_scan_memory(unsigned long node,
 		}
 #endif
 		lmb_add(base, size);
+
+		memstart_addr = min((u64)memstart_addr, base);
 	}
+
 	return 0;
 }

diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 31ada9f..153a48d 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -435,7 +435,7 @@ void __init setup_system(void)
 		printk("htab_address                  = 0x%p\n", htab_address);
 	printk("htab_hash_mask                = 0x%lx\n", htab_hash_mask);
 #if PHYSICAL_START > 0
-	printk("physical_start                = 0x%x\n", PHYSICAL_START);
+	printk("physical_start                = 0x%lx\n", PHYSICAL_START);
 #endif
 	printk("-----------------------------------------------------\n");

diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
index ada249b..ce10e2b 100644
--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -202,7 +202,7 @@ adjust_total_lowmem(void)
 		cam_max_size = max_lowmem_size;

 	/* adjust lowmem size to max_lowmem_size */
-	ram = min(max_lowmem_size, total_lowmem);
+	ram = min(max_lowmem_size, (phys_addr_t)total_lowmem);

 	/* Calculate CAM values */
 	__cam0 = 1UL << 2 * (__ilog2(ram) / 2);
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 47325f2..578750e 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -59,7 +59,10 @@ DEFINE_PER_CPU(struct mmu_gather, mmu_gathers);
 unsigned long total_memory;
 unsigned long total_lowmem;

-phys_addr_t memstart_addr;
+phys_addr_t memstart_addr = (phys_addr_t)~0ull;
+EXPORT_SYMBOL(memstart_addr);
+phys_addr_t kernstart_addr;
+EXPORT_SYMBOL(kernstart_addr);
 phys_addr_t lowmem_end_addr;

 int boot_mapsize;
diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
index 698bd00..c5ac532 100644
--- a/arch/powerpc/mm/init_64.c
+++ b/arch/powerpc/mm/init_64.c
@@ -72,7 +72,8 @@
 #warning TASK_SIZE is smaller than it needs to be.
 #endif

-phys_addr_t memstart_addr;
+phys_addr_t memstart_addr = ~0;
+phys_addr_t kernstart_addr;

 void free_initmem(void)
 {
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 16def4d..0062e6b 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -216,7 +216,7 @@ void __init do_init_bootmem(void)
 	unsigned long total_pages;
 	int boot_mapsize;

-	max_pfn = lmb_end_of_DRAM() >> PAGE_SHIFT;
+	max_low_pfn = max_pfn = lmb_end_of_DRAM() >> PAGE_SHIFT;
 	total_pages = (lmb_end_of_DRAM() - memstart_addr) >> PAGE_SHIFT;
 #ifdef CONFIG_HIGHMEM
 	total_pages = total_lowmem >> PAGE_SHIFT;
@@ -232,7 +232,8 @@ void __init do_init_bootmem(void)

 	start = lmb_alloc(bootmap_pages << PAGE_SHIFT, PAGE_SIZE);

-	boot_mapsize = init_bootmem(start >> PAGE_SHIFT, total_pages);
+	min_low_pfn = MEMORY_START >> PAGE_SHIFT;
+	boot_mapsize = init_bootmem_node(NODE_DATA(0), start >> PAGE_SHIFT, min_low_pfn, max_low_pfn);

 	/* Add active regions with valid PFNs */
 	for (i = 0; i < lmb.memory.cnt; i++) {
diff --git a/include/asm-powerpc/kdump.h b/include/asm-powerpc/kdump.h
index 10e8eb1..f6c93c7 100644
--- a/include/asm-powerpc/kdump.h
+++ b/include/asm-powerpc/kdump.h
@@ -11,16 +11,11 @@

 #ifdef CONFIG_CRASH_DUMP

-#define PHYSICAL_START	KDUMP_KERNELBASE
 #define KDUMP_TRAMPOLINE_START	0x0100
 #define KDUMP_TRAMPOLINE_END	0x3000

 #define KDUMP_MIN_TCE_ENTRIES	2048

-#else /* !CONFIG_CRASH_DUMP */
-
-#define PHYSICAL_START	0x0
-
 #endif /* CONFIG_CRASH_DUMP */

 #ifndef __ASSEMBLY__
diff --git a/include/asm-powerpc/page.h b/include/asm-powerpc/page.h
index 6c85060..cffdf0e 100644
--- a/include/asm-powerpc/page.h
+++ b/include/asm-powerpc/page.h
@@ -12,6 +12,7 @@

 #include <asm/asm-compat.h>
 #include <asm/kdump.h>
+#include <asm/types.h>

 /*
  * On PPC32 page size is 4K. For PPC64 we support either 4K or 64K software
@@ -42,8 +43,23 @@
  *
  * The kdump dump kernel is one example where KERNELBASE != PAGE_OFFSET.
  *
- * To get a physical address from a virtual one you subtract PAGE_OFFSET,
- * _not_ KERNELBASE.
+ * PAGE_OFFSET is the virtual address of the start of lowmem.
+ *
+ * PHYSICAL_START is the physical address of the start of the kernel.
+ *
+ * MEMORY_START is the physical address of the start of lowmem.
+ *
+ * KERNELBASE, PAGE_OFFSET, and PHYSICAL_START are all configurable on
+ * ppc32 and based on how they are set we determine MEMORY_START.
+ *
+ * For the linear mapping the following equation should be true:
+ * KERNELBASE - PAGE_OFFSET = PHYSICAL_START - MEMORY_START
+ *
+ * Also, KERNELBASE >= PAGE_OFFSET and PHYSICAL_START >= MEMORY_START
+ *
+ * There are two was to determine a physical address from a virtual one:
+ * va = pa + PAGE_OFFSET - MEMORY_START
+ * va = pa + KERNELBASE - PHYSICAL_START
  *
  * If you want to know something's offset from the start of the kernel you
  * should subtract KERNELBASE.
@@ -51,20 +67,33 @@
  * If you want to test if something's a kernel address, use is_kernel_addr().
  */

-#define PAGE_OFFSET     ASM_CONST(CONFIG_KERNEL_START)
-#define KERNELBASE      (PAGE_OFFSET + PHYSICAL_START)
-#define LOAD_OFFSET	PAGE_OFFSET
+#define KERNELBASE      ASM_CONST(CONFIG_KERNEL_START)
+#define PAGE_OFFSET	ASM_CONST(CONFIG_PAGE_OFFSET)
+#define LOAD_OFFSET	ASM_CONST((CONFIG_KERNEL_START-CONFIG_PHYSICAL_START))
+
+#if defined(CONFIG_RELOCATABLE) && defined(CONFIG_FLATMEM)
+#ifndef __ASSEMBLY__
+extern phys_addr_t memstart_addr;
+extern phys_addr_t kernstart_addr;
+#endif
+#define PHYSICAL_START	kernstart_addr
+#define MEMORY_START	memstart_addr
+#else
+#define PHYSICAL_START	ASM_CONST(CONFIG_PHYSICAL_START)
+#define MEMORY_START	(PHYSICAL_START + PAGE_OFFSET - KERNELBASE)
+#endif

 #ifdef CONFIG_FLATMEM
-#define pfn_valid(pfn)		((pfn) < max_mapnr)
+#define ARCH_PFN_OFFSET		(MEMORY_START >> PAGE_SHIFT)
+#define pfn_valid(pfn)		((pfn) >= ARCH_PFN_OFFSET && (pfn) < (ARCH_PFN_OFFSET + max_mapnr))
 #endif

 #define virt_to_page(kaddr)	pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
 #define pfn_to_kaddr(pfn)	__va((pfn) << PAGE_SHIFT)
 #define virt_addr_valid(kaddr)	pfn_valid(__pa(kaddr) >> PAGE_SHIFT)

-#define __va(x) ((void *)((unsigned long)(x) + PAGE_OFFSET))
-#define __pa(x) ((unsigned long)(x) - PAGE_OFFSET)
+#define __va(x) ((void *)((unsigned long)(x) - PHYSICAL_START + KERNELBASE))
+#define __pa(x) ((unsigned long)(x) + PHYSICAL_START - KERNELBASE)

 /*
  * Unfortunately the PLT is in the BSS in the PPC32 ELF ABI,
diff --git a/include/asm-powerpc/page_32.h b/include/asm-powerpc/page_32.h
index 51f8134..ebfae53 100644
--- a/include/asm-powerpc/page_32.h
+++ b/include/asm-powerpc/page_32.h
@@ -1,6 +1,12 @@
 #ifndef _ASM_POWERPC_PAGE_32_H
 #define _ASM_POWERPC_PAGE_32_H

+#if defined(CONFIG_PHYSICAL_ALIGN) && (CONFIG_PHYSICAL_START != 0)
+#if (CONFIG_PHYSICAL_START % CONFIG_PHYSICAL_ALIGN) != 0
+#error "CONFIG_PHYSICAL_START must be a multiple of CONFIG_PHYSICAL_ALIGN"
+#endif
+#endif
+
 #define VM_DATA_DEFAULT_FLAGS	VM_DATA_DEFAULT_FLAGS32

 #ifdef CONFIG_NOT_COHERENT_CACHE
-- 
1.5.4.1

^ permalink raw reply related

* Re: [PATCH] [PPC] Remove mpc8272 ads board from arch/ppc
From: Scott Wood @ 2008-04-21 18:29 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <5422E8EE-4AFA-491B-8920-BDEBF596FF00@kernel.crashing.org>

On Mon, Apr 21, 2008 at 10:25:09AM -0500, Kumar Gala wrote:
> 
> On Apr 19, 2008, at 1:14 PM, Grant Likely wrote:
> >On Sat, Apr 19, 2008 at 9:52 AM, Kumar Gala  
> ><galak@kernel.crashing.org> wrote:
> >>We have a board port in arch/powerpc so we dont need this one  
> >>anymore.
> >>
> >>Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> >
> >Personally, I'd rather not do the piecemeal removal of board ports
> >from arch/ppc.  We've only got one release left anyway.  Removing them
> >just generates more churn and has the risk of causing other side
> >effects.
> 
> I can understand it, but I think removing them makes it obvious to  
> anyone that's lurking.  Call in maintainer prerogative :)

Speaking of making it obvious, is it time to put a #warning in some
prominent arch/ppc header?

-Scott

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox