RE: USB Host support on mpc 8313
> -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > rg] On Behalf Of Joaquin Luna > Sent: Monday, November 24, 2008 11:24 AM > To: linuxppc-embedded@ozlabs.org > Subject: USB Host support on mpc 8313 > > Is there anyone out there who has tried getting usb to work > under the 2.6.27 kernel? I am using the Freescale MPC831x > RDB platform and when I enable "Support for Freescale on-chip > EHCI USB controller" (USB_EHCI_FSL) I get stuck during boot > up. The last two lines of my boot log are: > > > > fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller > > fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1 > > > > > > With the 2.6.20 kernel I had usb working and my boot log looked like: > > > > fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller > > fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1 > > fsl-ehci fsl-ehci.0: irq 38, io base 0xe0023000 > > fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 > > > > > > I did notice that there were a few usb bug fixes that went > into 2.6.27.7 so I updated to the latest version, but it did > not help. Any idea how or where I can begin looking for a solution? There are two settings of the board (USB internal PHY/ USB external PHY). They are described in the board UM. Is the phy_type property in DTS matching the board setting? utmi_wide for internal PHY ulpi for external PHY - Leo ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Merge linuxppc-embedded with linuxppc-dev
On Tue, Sep 23, 2008 at 6:20 AM, Grant Likely <[EMAIL PROTECTED]> wrote: > On Mon, Sep 22, 2008 at 4:11 PM, Mike Frysinger <[EMAIL PROTECTED]> wrote: >> On Mon, Sep 22, 2008 at 18:08, Grant Likely <[EMAIL PROTECTED]> wrote: >>> Jeremy, >>> >>> Can we eliminate the linuxppc-embedded mailing list and merge it with >>> linuxppc-dev? I don't think we need two separate lists anymore and >>> patches to linuxppc-embedded don't always get dealt with. >>> >>> Anyone have any objections to eliminating linuxppc-embedded? >> >> you sent this e-mail to "linux-embedded" instead of "linuxppc-embedded" >> -mike > > See! My point proven! That list just causes confusion. :-) > > Oops. I've cc'd the linuxppc-embedded list now. Sorry to all the > non-powerpc linux-embedded folks for the noise. I agree. Given the fact that most active embedded people are already watching the linuxppc-dev list. It's a good idea for embedded people not having to subscribe two lists. But I don't know if non-embedded people would like this idea. - Leo ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: [PATCH] DMA Engine: fix error path(s) in fsl-dma driver
> -Original Message- > From: Sebastian Siewior [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 01, 2008 2:19 AM > To: Li Yang > Cc: Zhang Wei; linuxppc-embedded@ozlabs.org; > [EMAIL PROTECTED] > Subject: [PATCH] DMA Engine: fix error path(s) in fsl-dma driver > > of_fsl_dma_probe: > - kfree(NULL) doesn't hurt but dereferencing the pointer in > iounmap does > - also, the irq can be freed > > of_fsl_dma_chan_probe: > - iounmap(NULL) resolved in vunmap() what which in turn is > able to handle NULL > pointer but dereferencing still doesn't work > - don't clean up not yet allocated ressources, like list_del > before list_add > > fsl_dma_self_test: > - call fsl_dma_free_chan_resources() if the first dma trans > didn't complete Thanks Sebastian, But similar patch has already been waiting in sub-system maintainer's tree which can be found at http://git.kernel.org/?p=linux/kernel/git/djbw/async_tx.git;a=commit;h=29ec9bdef73d68134e7070ee91ccda0718d46150 - Leo ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: USB Host-to-Serial or USB Host-to-Ethernet
> -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > rg] On Behalf Of Huub Eikens > Sent: Monday, June 02, 2008 5:22 PM > To: linuxppc-embedded@ozlabs.org > Subject: USB Host-to-Serial or USB Host-to-Ethernet > > Hi, > > I have platform based on the Freescale MPC8270 processor that > runs on linux 2.4.25. On it I want to mount a memory stick. > Due to hardware (layout) restrictions , I cannot use an > external USB Host Controller. Also, I cannot use the on-chip > USB Host Controller since there is no driver available that > is reliable and has good performance. > > Therefor, I am exploring the possibility of doing a > USB-to-Serial or USB-to-ethernet. Does anyone know which chip > to use for which a driver exists for linux 2.4.25? Note that > such a chip must act as a USB Host (!). Can you use a PCI USB card? I don't quite understand how USB-to-serial or USB-to-ethernet can help you mount a USB memory stick. Unless you want USB memory stick to be mounted on another system and exported with NFS. - Leo ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
> > Hi Jocke, > > > > QUICC engine supports dynamic maximum frame length. If you are not > > expecting to receive only tagged frames, I recommend to use this > > feature by setting dynamicMaxFrameLength and > dynamicMinFrameLength in > > ug_info instead of increasing the MaxLength for both tagged > and untagged frames. > > See the following part from the reference manual. > > > > The MFLR entry in the Global Parameter RAM defines the > length of the > > largest frame, excluding Q TAG but including FCS, that is > still valid. > > When REMODER[DXE]=1, a tagged frame that has length equals > > MaxLength+4 considered valid, and a non tagged frame that has length > > equals MaxLength is the longest > > that is still considered valid. When REMODER[DXE]=0, any > frame longer > > than MaxLength consider erroneous frame. > > For systems with only tagged frames, set REMODER[DXE]=0 and set > > MaxLength = Max LLC size+4. > > > > - Leo > > Interesting, that should also work although QinQ will not. I > will have a closer look but I still don't see how my orginal > patch would harm anything. One could add my patch on top but > with only 4 bytes extra. Hi, The increase of max packet length may cause a waste of QE internal buffer for every packet. Furthermore it affects the hardware statistics of jumbo packets. - Leo ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
> -Original Message- > From: Joakim Tjernlund [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 25, 2008 5:18 PM > To: Li Yang > Cc: Netdev; Linuxppc-Embedded@Ozlabs.Org > Subject: Re: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs > > > On Sat, 2008-03-22 at 12:51 +0100, Joakim Tjernlund wrote: > > >> -Original Message- > > >> From: [EMAIL PROTECTED] > > >> [mailto:[EMAIL PROTECTED] On Behalf Of > Joakim Tjernlund > > > Sent: Tuesday, March 18, 2008 11:11 PM > > >> To: Netdev; Li Yang > > >> Cc: Joakim Tjernlund > > >>Subject: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs > > >> > > >> Creating a VLAN interface on top of ucc_geth adds 4 bytes to the > > >> frame and the HW controller is not prepared to TX a frame bigger > > >> than 1518 bytes which is 4 bytes too small for a full > VLAN frame. > > >> Also add 4 extra bytes for future expansion. > > > > > > IMO, VLAN and Jumbo packet support is not general case of > Ethernet. > > > Could you make this change optional? Thanks. > > > > > > - Leo > > > > hmm, I do not agree. VLAN is common today. > > > > If you were to enable HW support for VLAN then the ethernet > controller > > would inject an extra 4 bytes into the frame. > > This change does not change the visible MTU for the user. > As is now, > > soft VLAN is silently broken. Do you really want the user > to find and > > turn on a controller specific feature to use VLAN? > > > > What does netdev people think? > > > > Jocke > > hmm, I misread the HW specs. The change has nothing to do > with TX, it is the MAX RX frame size that was too small for > VLAN and that is what the patch addresses. I see that tg3.c > adds 4 bytes to MAX RX pkgs: > /* MTU + ethernet header + FCS + optional VLAN tag */ > tw32(MAC_RX_MTU_SIZE, tp->dev->mtu + ETH_HLEN + 8); So > I don't think this change should be hidden behind a new > CONFIG option. Updated patch below with changed description. Hi Jocke, QUICC engine supports dynamic maximum frame length. If you are not expecting to receive only tagged frames, I recommend to use this feature by setting dynamicMaxFrameLength and dynamicMinFrameLength in ug_info instead of increasing the MaxLength for both tagged and untagged frames. See the following part from the reference manual. The MFLR entry in the Global Parameter RAM defines the length of the largest frame, excluding Q TAG but including FCS, that is still valid. When REMODER[DXE]=1, a tagged frame that has length equals MaxLength+4 considered valid, and a non tagged frame that has length equals MaxLength is the longest that is still considered valid. When REMODER[DXE]=0, any frame longer than MaxLength consider erroneous frame. For systems with only tagged frames, set REMODER[DXE]=0 and set MaxLength = Max LLC size+4. - Leo ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Joakim Tjernlund
> Sent: Tuesday, March 18, 2008 11:11 PM
> To: Netdev; Li Yang
> Cc: Joakim Tjernlund
> Subject: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
>
> Creating a VLAN interface on top of ucc_geth adds 4 bytes to
> the frame and the HW controller is not prepared to TX a frame
> bigger than 1518 bytes which is 4 bytes too small for a full
> VLAN frame. Also add 4 extra bytes for future expansion.
IMO, VLAN and Jumbo packet support is not general case of Ethernet.
Could you make this change optional? Thanks.
- Leo
>
> Signed-off-by: Joakim Tjernlund <[EMAIL PROTECTED]>
> ---
> drivers/net/ucc_geth.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> index 348892b..038ec75 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -114,10 +114,10 @@ static struct ucc_geth_info
> ugeth_primary_info = {
> .maxGroupAddrInHash = 4,
> .maxIndAddrInHash = 4,
> .prel = 7,
> - .maxFrameLength = 1518,
> + .maxFrameLength = 1518+8, /* Add 4 bytes for VLAN tags
> and 4 extra
> +bytes */
> .minFrameLength = 64,
> - .maxD1Length = 1520,
> - .maxD2Length = 1520,
> + .maxD1Length = 1520+8,
> + .maxD2Length = 1520+8,
> .vlantype = 0x8100,
> .ecamptr = ((uint32_t) NULL),
> .eventRegMask = UCCE_OTHER,
> --
> 1.5.4.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> netdev" in the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: [PATCH] Add Fixed PHY support for ucc_geth
> -Original Message-
> From: Joakim Tjernlund [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 18, 2008 5:47 PM
> To: Netdev; Li Yang; Linuxppc-Embedded@Ozlabs.Org
> Cc: Joakim Tjernlund
> Subject: [PATCH] Add Fixed PHY support for ucc_geth
>
> The new Fixed PHY method, fixed-link property, isn't
> impl. for ucc_geth which makes fixed PHYs non functional.
> Add support for the new method to restore the Fixed PHY
> functionality.
>
> Signed-off-by: Joakim Tjernlund <[EMAIL PROTECTED]>
Signed-off-by: Li Yang <[EMAIL PROTECTED]>
---
Ps: This patch depends on the patch "ucc_geth: use correct thread number
for 10/100Mbps link" to apply, which hasn't made to Linus' tree for now
but has already been in Jeff and David's trees.
> ---
>
> This is a regression as fixed PHYs works in 2.6.23 and I am
> using it.
>
> drivers/net/ucc_geth.c | 53
> +++
> 1 files changed, 30 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> index ecc5712..18c8b39 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -3836,6 +3836,7 @@ static int ucc_geth_probe(struct
> of_device* ofdev, const struct of_device_id *ma
> struct device_node *phy;
> int err, ucc_num, max_speed = 0;
> const phandle *ph;
> + const u32 *fixed_link;
> const unsigned int *prop;
> const char *sprop;
> const void *mac_addr;
> @@ -3926,18 +3927,38 @@ static int ucc_geth_probe(struct
> of_device* ofdev, const struct of_device_id *ma
>
> ug_info->uf_info.regs = res.start;
> ug_info->uf_info.irq = irq_of_parse_and_map(np, 0);
> + fixed_link = of_get_property(np, "fixed-link", NULL);
> + if (fixed_link) {
> + ug_info->mdio_bus = 0;
> + ug_info->phy_address = fixed_link[0];
> + phy = NULL;
> + } else {
> + ph = of_get_property(np, "phy-handle", NULL);
> + phy = of_find_node_by_phandle(*ph);
>
> - ph = of_get_property(np, "phy-handle", NULL);
> - phy = of_find_node_by_phandle(*ph);
> + if (phy == NULL)
> + return -ENODEV;
>
> - if (phy == NULL)
> - return -ENODEV;
> + /* set the PHY address */
> + prop = of_get_property(phy, "reg", NULL);
> + if (prop == NULL)
> + return -1;
> + ug_info->phy_address = *prop;
> +
> + /* Set the bus id */
> + mdio = of_get_parent(phy);
> +
> + if (mdio == NULL)
> + return -1;
>
> - /* set the PHY address */
> - prop = of_get_property(phy, "reg", NULL);
> - if (prop == NULL)
> - return -1;
> - ug_info->phy_address = *prop;
> + err = of_address_to_resource(mdio, 0, &res);
> + of_node_put(mdio);
> +
> + if (err)
> + return -1;
> +
> + ug_info->mdio_bus = res.start;
> + }
>
> /* get the phy interface type, or default to MII */
> prop = of_get_property(np, "phy-connection-type", NULL);
> @@ -3982,20 +4003,6 @@ static int ucc_geth_probe(struct
> of_device* ofdev, const struct of_device_id *ma
> ug_info->numThreadsRx = UCC_GETH_NUM_OF_THREADS_4;
> }
>
> - /* Set the bus id */
> - mdio = of_get_parent(phy);
> -
> - if (mdio == NULL)
> - return -1;
> -
> - err = of_address_to_resource(mdio, 0, &res);
> - of_node_put(mdio);
> -
> - if (err)
> - return -1;
> -
> - ug_info->mdio_bus = res.start;
> -
> if (netif_msg_probe(&debug))
> printk(KERN_INFO "ucc_geth: UCC%1d at 0x%8x
> (irq = %d) \n",
> ug_info->uf_info.ucc_num + 1,
> ug_info->uf_info.regs,
> --
> 1.5.4.3
>
>
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[GIT PATCH] ucc_geth fixes for 2.6.22-rc1
Please pull from 'ucc_geth' branch of
master.kernel.org:/pub/scm/linux/kernel/git/leo/fsl-soc.git ucc_geth
to receive the following fixes:
drivers/net/ucc_geth_ethtool.c |1 -
drivers/net/ucc_geth_mii.c |3 ++-
2 files changed, 2 insertions(+), 2 deletions(-)
Domen Puncer (1):
ucc_geth: fix section mismatch
Jan Altenberg (1):
ucc_geth: remove get_perm_addr from ucc_geth_ethtool.c
diff --git a/drivers/net/ucc_geth_ethtool.c
b/drivers/net/ucc_geth_ethtool.c
index a8994c7..64bef7c 100644
--- a/drivers/net/ucc_geth_ethtool.c
+++ b/drivers/net/ucc_geth_ethtool.c
@@ -379,7 +379,6 @@ static const struct ethtool_ops uec_ethtool_ops = {
.get_stats_count= uec_get_stats_count,
.get_strings= uec_get_strings,
.get_ethtool_stats = uec_get_ethtool_stats,
- .get_perm_addr = ethtool_op_get_perm_addr,
};
void uec_set_ethtool_ops(struct net_device *netdev)
diff --git a/drivers/net/ucc_geth_mii.c b/drivers/net/ucc_geth_mii.c
index 5f8c2d3..6c257b8 100644
--- a/drivers/net/ucc_geth_mii.c
+++ b/drivers/net/ucc_geth_mii.c
@@ -272,7 +272,8 @@ int __init uec_mdio_init(void)
return of_register_platform_driver(&uec_mdio_driver);
}
-void __exit uec_mdio_exit(void)
+/* called from __init ucc_geth_init, therefore can not be __exit */
+void uec_mdio_exit(void)
{
of_unregister_platform_driver(&uec_mdio_driver);
}
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: mpc83xx USB support status
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grant > Likely > Sent: Saturday, July 07, 2007 4:02 AM > To: Li Yang-r58472; Tabi Timur-B04825; Behan Webster; Linux PPC Linux PPC > Subject: mpc83xx USB support status > > Li, > > What is the state of mpc83xx support in arch/powerpc? I saw some of > the patches you posted to the ppc and usb-devel lists, but I want to > make sure I've got the whole set. Also, can you tell me what the > state of those patches are (ie. which ones will be picked up for > 2.6.23?) The USB host/gadget should be working in arch/powerpc with all the patches I submitted to ppc and usb-devel applied. AFAIK, all the patches posted to usb-devel will be picked up for 2.6.23. I hope the platform rework code will also be picked up; I see nothing preventing it from being included. > > I'm working on the mpc8349-mitx-gp board, and I can do the work to get > your changes working on that board. Good, the USB drivers are intended to be platform independent. The soc specific configuration will be done in the rework patch I submitted. The only thing you need to take care of is board specific setup. Feel free to contact me if you have any problem. - Leo ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Anyone using QE UART mode?
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Ying Lin > Sent: Tuesday, July 03, 2007 12:02 AM > To: Tabi Timur-B04825 > Cc: linuxppc-embedded@ozlabs.org > Subject: RE: Anyone using QE UART mode? > > OK, the missing piece (UART driver) I am looking for is not available > yet. I will seek alternative solutions (create a simple UART driver, or > just wait). Which chip are you using? There should be separate 16550 compatible UART controller on MPC8360. The driver is already there and working pretty well. - Leo ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: USB Host at full speed
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Tuesday, May 29, 2007 5:11 PM > To: Linuxppc-embedded@ozlabs.org > Subject: USB Host at full speed > > Hello ALL, > > I m currently trying to force the USB host controller from MPC8349 to only work > at full speed i.e. whatever is the connected device, the bandwidth should be 12MB. > I thought i could perform it just by setting some registers to right value but it > aren't working. > I fear i have to force software to always use TT and split transfer but i dont > know exactly where to start.. > > If anybody could help, would be so great!! Your question can be interpreted as how to force EHCI host driver to work in full speed. Usb-devel list cc'ed should be a better place for such a question. - Leo ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] NET: add MAINTAINERS entry for ucc_geth driver
Signed-off-by: Li Yang <[EMAIL PROTECTED]> --- MAINTAINERS |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 4c3277c..3faed72 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1463,6 +1463,13 @@ L: [EMAIL PROTECTED] L: linuxppc-embedded@ozlabs.org S: Maintained +FREESCALE QUICC ENGINE UCC ETHERNET DRIVER +P: Li Yang +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] +L: linuxppc-embedded@ozlabs.org +S: Maintained + FILE LOCKING (flock() and fcntl()/lockf()) P: Matthew Wilcox M: [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: [patch 1/1] ppc: Possible bug fix for FCC driver
Hi Cedric, For ppc embedded related patches, please also cc: [EMAIL PROTECTED] > We use a kernel 2.6.14 on PPC platform (MPC 8555). The FCC driver works To submit a kernel patch upstream, the patch should be against the latest kernel version which is 2.6.21-rc now. > well with a 100Mbps link. But it doesn't with a 10Mbps link. To solve > it, I modified the GFMR register init: removed TCI bit and set CRC32 bit > instead of. I don't know how these bits caused the 10M link issue. Do you have any reasoning? > Signed-off-by: Cedric Pontois <[EMAIL PROTECTED]> > > > - > > diff -ruN pa-original/arch/ppc/8260_io/fcc_enet.c > pa-patched/arch/ppc/8260_io/fcc_enet.c > --- pa-original/arch/ppc/8260_io/fcc_enet.c 2007-03-02 > 14:57:07.000197000 +0100 > +++ pa-patched/arch/ppc/8260_io/fcc_enet.c2007-03-02 > 14:57:08.38000 +0100 > @@ -2232,7 +2232,7 @@ > > /* Set GFMR to enable Ethernet operating mode. >*/ > - fccp->fcc_gfmr = (FCC_GFMR_TCI | FCC_GFMR_MODE_ENET); > + fccp->fcc_gfmr = (FCC_GFMR_TCRC_32 | FCC_GFMR_MODE_ENET); > > /* Set sync/delimiters. > */ > ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: 8360 UCC_GETH INIT_WORK compile error
Russ, Please use the latest git tree. The fix has been merged. - Leo From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Russell McGuire Sent: Friday, January 26, 2007 2:07 PM To: linuxppc-embedded@ozlabs.org Subject: 8360 UCC_GETH INIT_WORK compile error Kumar / ALL, I was having problems compiling the UCC_GETH driver for 8360. INIT_WORK declared with 2 parameters instead of 3. Googling around, I noticed that somebody posted a temporary patch back in December 14, 2006. Has this been resolved? I am not able to boot the 2.6.19.2 Kernel the moment since the Ethernet/UCCF driver won't compile. -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: MPC8260 I2C Problem
You are talking about the wrong i2c driver. For 8260, you need a cpm
i2c driver, not the i2c-mpc driver.
- Leo
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
Behalf Of
> jimmy liu
> Sent: Friday, January 26, 2007 1:06 AM
> To: embedded linuxppc
> Subject: RE: MPC8260 I2C Problem
>
> In the arch\ppc\syslib\pq2_devices.c, there has the
> device descriptions.
> Do I still need manually create the plateform bus
> tree?
>
> --- Li Yang-r58472 <[EMAIL PROTECTED]> wrote:
>
> > > -Original Message-
> > > From:
> >
> [EMAIL PROTECTED]
> > >
> >
> [mailto:[EMAIL PROTECTED]
> > On
> > Behalf Of
> > > jimmy liu
> > > Sent: Thursday, January 25, 2007 11:22 AM
> > > To: embedded linuxppc
> > > Subject: MPC8260 I2C Problem
> > >
> > > I download the linux kernel 2.6.19 from
> > > ftp://ftp.denx.de/pub/linux/ site.
> > >
> > > When I add mpc8260 I2C driver to Linux kernel
> > 2.6.19,
> > > the init function looks like that
> > > static int __init fsl_i2c_init(void)
> > > {
> > > return driver_register(&fsl_i2c_driver);
> > > }
> > > I set the debug on, and found that the
> > fsl_i2c_probe()
> > > function is never called, so there is not I2C
> > device
> > > enabled, and the user space function
> > > open("/dev/i2c-0",O_RDWR) always return error. I
> > set
> > > something wrong? Could somebody help me?
> >
> > Do you have an fsl-i2c node in your device tree?
> >
> > - Leo
> >
>
>
>
>
>
__
> __
> Don't pick lemons.
> See all the new 2007 cars at Yahoo! Autos.
> http://autos.yahoo.com/new_cars.html
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: MPC8260 I2C Problem
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
Behalf Of
> jimmy liu
> Sent: Thursday, January 25, 2007 11:22 AM
> To: embedded linuxppc
> Subject: MPC8260 I2C Problem
>
> I download the linux kernel 2.6.19 from
> ftp://ftp.denx.de/pub/linux/ site.
>
> When I add mpc8260 I2C driver to Linux kernel 2.6.19,
> the init function looks like that
> static int __init fsl_i2c_init(void)
> {
> return driver_register(&fsl_i2c_driver);
> }
> I set the debug on, and found that the fsl_i2c_probe()
> function is never called, so there is not I2C device
> enabled, and the user space function
> open("/dev/i2c-0",O_RDWR) always return error. I set
> something wrong? Could somebody help me?
Do you have an fsl-i2c node in your device tree?
- Leo
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: regarding kgdb in ppc
I'm facing the same problem for almost two weeks and still don't have a clue. Please keep me in the thread. Thanks! - Reeve On 12/24/06, sudheer <[EMAIL PROTECTED]> wrote: > > Hello All > > > Hi Shakti > > > > > > Then executed the command mkinird and copied and added initrd in the > > > grub.conf - situation is same. > > > I changed the root parameter to LABEL=/ - situation is same. > > > > Basically, block device, initrd support for ramdisk should be enabled: > > CONFIG_BLK_DEV_RAM > > CONFIG_BLK_DEV_INITRD > > > > Double check your .config file. > > > > I have checked all the above and are enabled in the config. I have tried > changing the kernel command line argumnets. > > I get the same error saying: (All from init/main.c) > > unable to open an initial console > No init found. Try passing init= option to kernel. > - > I am able to debug the kernel on x86 systems. Thanks for all the support. > > Now I am working with kgdb on mpc8540 board. > target kernel version - linux-2.6.13 > KGDB version - linux-2.6.13-kgdb-2.3 > > I am getting the following error: > > [EMAIL PROTECTED] sudheer]# /opt/eldk-3.1.1/usr/bin/ppc_85xx-gdb vmlinux > GNU gdb Red Hat Linux (6.3.0.0-1.21_1rh) > ... > This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux"... > (gdb) set remotebaud 115200 > (gdb) target remote /dev/ttyS0 > Remote debugging using /dev/ttyS0 > Ignoring packet error, continuing... > > On the target side, i could see that the target kernel kgdb waiting for > host communication. > > On the target board with kernel version - linux-2.6.13 , I could boot it > only after applying the patches: > 1. Gain_Phy_update > 2.patch-2.6.14-rc5 > 3.Phy_Platform_Update > The patch-2.6.14-rc5 when applied , deleted the file > arch/ppc/platforms/pcore.c and > pcore.h but the kernel boots well. > > In the KGDB version - linux-2.6.13-kgdb-2.3 > The ppc-lite.patch tries to modify the pcore.c which is not available. > > I am not sure wether this affects the serial communication establishment. > > Please help me to solve this. > > Thanks > Sudheer > > > > > > > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: ARCH=powerpc: IRQ numbers change mysteriously
The irq number on powerpc ARCH is now a virtual number. This change was
introduced by Ben's irq mapping change in early 2.6.18-rc.
- Leo
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
Behalf Of
> Fredrik Roubert
> Sent: Tuesday, October 24, 2006 12:41 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: ARCH=powerpc: IRQ numbers change mysteriously
>
> Hi!
>
> On my MPC8439 based board, running Linux 2.6.18 with ARCH=powerpc, the
> IRQ's for the I2C behave in a for me mysterious way.
>
> In my DTS file, I have the following:
>
>
> [EMAIL PROTECTED] {
> device_type = "i2c";
> compatible = "fsl-i2c";
> reg = <3000 100>;
> interrupts = ;
> interrupt-parent = <&/[EMAIL PROTECTED]/[EMAIL PROTECTED]>;
> dfsrr;
> };
>
> [EMAIL PROTECTED] {
> device_type = "i2c";
> compatible = "fsl-i2c";
> reg = <3000 100>;
> interrupts = ;
> interrupt-parent = <&/[EMAIL PROTECTED]/[EMAIL PROTECTED]>;
> dfsrr;
> };
>
>
> But when I boot the system and cat /proc/interrupts, the output says:
>
>
> 18: 61 IPIC Level i2c-mpc
> 19: 0 IPIC Level i2c-mpc
>
>
> This doesn't make sense to me. Why are the IRQ numbers changed? They
are
> still adjacent, so it seems to be some logic to the change. Does
anyone
> know what this is?
>
> Cheers // Fredrik Roubert
>
> --
> Barco Medical Imaging | +32 56 233549
> http://www.barco.com/medical/ | [EMAIL PROTECTED]
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
bdm/jtag interface for MPC834x with gdb access
Can anyone share experience on bcm/jtag interface for MPC834x with gdb access? I'm using windriver usb jtag probe. Is there any bdm interface with gdb access available for it? Thanks. - Reeve ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Need help on PPC8343E bringup
Thanks Machael. On my flash data sheet, there are some command about security: Lock Block | Block Address | 0060h | Block Address | 0001h Unlock Block|Block Address| 0060h | Block Address | 00d0h So I guess it needs two write cycle to perfomr the command, and the unlock command should be 006000d0. I tried that but still get the same error. Bad! :( Another questions is that is there any way to change CPU register directy? For 8343E all registers are mapped to 1m starting from 0xff40. I want to change on 0Xff400c08, but visionclick reject me to write on that address. - ReeveOn 9/29/06, Michael Galassi <[EMAIL PROTECTED]> wrote: >>Hello linux-ppc experts,I'm trying to use using wind river jtag probe to download uboot to our>>switching box which is with PPC8343E/Intel 28F128J3D memory flash(16M).>>Memory mapping is starting from 0xFF00 to 0x which is 16M. The >>JTAG software I'm using is visionclick8.The problem now is that I even couldn't erash flash, with following error>>message:TF ERASE FFF0.. INTEL 28F128Jx ( 8192 x 16 ) 1 Device >>Erasing Flash(s) ... Failed>>!ERROR! - [msg10] Failed while erasing the device(s)>>>BKM>>>!HALT! - [msg90009] Target Stopped : CheckStop taken; PC = 0x7404 [EVENT >>Taken]>>>BKM>Does anyone has experiece to bring up this CPU, and could shed some lights>>on it? Thank you in advance.- Reeve>>Your flash part[s] are almost certainly write-protected, or part of them >is. Get the data-sheet for them and find what combination to write to>them to un-protect them and try again. For the parts I'm using (micron>MT28F128J3) writing 0x00600060 followed by 0x00d000d0 to the part does >the trick.>>-michaelI must be lonely, responding to my own email :-).The other option you have is re-build u-boot to run from ram (presumablyat some lower address), then use u-boot itself to clear the write protect bits on your flash. U-boot's makefile has config targets forram & flash for some target boards which you may be able to takeadvantage of. My first solution is probably still quicker if you're not trying to debug u-boot itself.-michael ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Need help on PPC8343E bringup
Hello linux-ppc experts, I'm trying to use using wind river jtag probe to download uboot to our switching box which is with PPC8343E/Intel 28F128J3D memory flash(16M). Memory mapping is starting from 0xFF00 to 0x which is 16M. The JTAG software I'm using is visionclick8. The problem now is that I even couldn't erash flash, with following error message: TF ERASE FFF0.. INTEL 28F128Jx ( 8192 x 16 ) 1 Device Erasing Flash(s) ... Failed !ERROR! - [msg10] Failed while erasing the device(s) >BKM> !HALT! - [msg90009] Target Stopped : CheckStop taken; PC = 0x7404 [EVENT Taken] >BKM> Does anyone has experiece to bring up this CPU, and could shed some lights on it? Thank you in advance. - Reeve ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: bsp for Linux kernel 2.6
Shen, Wind River Linux 1.3 has BSP support for this board. The kernel version is 2.6.14. Regards, Steve Yang -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of shenbagaraj Sent: Thursday, September 21, 2006 5:07 PM To: linuxppc-embedded@ozlabs.org Subject: bsp for Linux kernel 2.6 Hi, I ma working on Windriver powerquicc board 8260.where do i get the required patches for linux 2.6.11.11. regards, shen ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MPC8360E USB Host Controller Driver
> Could you give a direct link ? I've been browsing around the > Freescale website for an hour, downloaded hundreds of > megabytes of archives but haven't been able to find the > MPC8360E USB Linux driver. > > Laurent Pinchart > > PS: Am I the only one to get lost almost every time when I > look for information on www.freescale.com ? PS: Contacting local FAE is always a good way and recommended way to get the latest information. - Leo
MPC8360E USB Host Controller Driver
On 9/7/06, Alex Zeffertt wrote: > Li Yang-r58472 wrote: > >> i have a MPC8347E running with the Freescale E(F)HCI driver > >> and Kernel 2.6.17 (Freescale LTIB). > >> > >> Because of this mail, i checked, if there are any periodical > >> interrupts, without real USB payload. > >> > >> The result is: NO > >> > >> If i attach a USB-mouse, i get 5 interrupts. > >> If i remove it again, 1 additional. > >> > >> Nothing else, silence ! > >> > >> USB works well with USB 1.1 and 2.0 devices (This was not the > >> case with earlier Kernels, e.g. 2.6.13, because for the > >> switching between 1.1 and 2.0 you need a transaction > >> translator driver). > > > > MPC834x USB is very different from the USB of CPM/QE. It is an > > integrated EHCI controller. > > > > > So, the question is still open, does the QuiccEngine HCI (a.k.a. FHCI) > generate loading on the PPC core when there is no traffic on the USB? Yes, but no. If the bus is idle for some time, you can put the bus into suspend state. Then there will be no extra load to the core. - Leo
RE: MPC8360E USB Host Controller Driver
> Could you give a direct link ? I've been browsing around the > Freescale website for an hour, downloaded hundreds of > megabytes of archives but haven't been able to find the > MPC8360E USB Linux driver. > > Laurent Pinchart > > PS: Am I the only one to get lost almost every time when I > look for information on www.freescale.com ? PS: Contacting local FAE is always a good way and recommended way to get the latest information. - Leo ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MPC8360E USB Host Controller Driver
On 9/7/06, Laurent Pinchart wrote: > > >I am working in MPC8360E processor board. I want the > > > PowerQUICC II's Pro USB Host controller Driver. In the > > > manual, they told that this controller does not belong to > > > UHCI or OHCI standard. > > > > Yes, you can call it FHCI if you like. :) > > > > > I have doubt that whether Freescale has its own USB standard. > > > > The interface is stated clearly in the UM. > > > > > Please give the link or patch for that driver. > > > > There is an 8360 host driver in Freescale LTIB BSP. Please find it on > > www.freescale.com, if it has been released. > > Could you give a direct link ? I've been browsing around the Freescale website > for an hour, downloaded hundreds of megabytes of archives but haven't been > able to find the MPC8360E USB Linux driver. You can bookmark this link: http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=0127268688033202A5 - Leo
MPC8360E USB Host Controller Driver
> i have a MPC8347E running with the Freescale E(F)HCI driver > and Kernel 2.6.17 (Freescale LTIB). > > Because of this mail, i checked, if there are any periodical > interrupts, without real USB payload. > > The result is: NO > > If i attach a USB-mouse, i get 5 interrupts. > If i remove it again, 1 additional. > > Nothing else, silence ! > > USB works well with USB 1.1 and 2.0 devices (This was not the > case with earlier Kernels, e.g. 2.6.13, because for the > switching between 1.1 and 2.0 you need a transaction > translator driver). MPC834x USB is very different from the USB of CPM/QE. It is an integrated EHCI controller. - Leo
MPC8360E USB Host Controller Driver
> -Original Message- > From: Alex Zeffertt [mailto:ajz at cambridgebroadband.com] > Sent: Thursday, September 07, 2006 6:59 PM > To: Li Yang-r58472 > Cc: n.balaji at gdatech.co.in; linuxppc-embedded at ozlabs.org > Subject: Re: MPC8360E USB Host Controller Driver > > >> manual, they told that this controller does not belong to UHCI or > >> OHCI standard. > > > > Yes, you can call it FHCI if you like. :) > > I heard that on the PQII (82xx) devices the FHCI required > intervention from the core, even when there was zero traffic > on the USB. I think this was because the core had to > continuously service a 1ms interrupt. This generates > significant extra loading, making it worth considering using > a cheap EHCI chip instead There are improvements on future chips with a QE. However it is still full-speed and need CPU intervention. But keep in mind that USB is not a key feature for netcomm devices which PQ is targeting. > > Does anyone know if this is still the case with the PQII Pro (83xx)? 834x has a integrated EHCI controller instead. - Leo
MPC8360E USB Host Controller Driver
> -Original Message- > From: > linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org > [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.o > rg] On Behalf Of n.balaji at gdatech.co.in > Sent: Thursday, September 07, 2006 4:04 PM > To: linuxppc-embedded at ozlabs.org > Subject: MPC8360E USB Host Controller Driver > > Hi All, >I am working in MPC8360E processor board. I want the > PowerQUICC II's Pro USB Host controller Driver. In the > manual, they told that this controller does not belong to > UHCI or OHCI standard. Yes, you can call it FHCI if you like. :) > > I have doubt that whether Freescale has its own USB standard. The interface is stated clearly in the UM. > > Please give the link or patch for that driver. There is an 8360 host driver in Freescale LTIB BSP. Please find it on www.freescale.com, if it has been released. - Leo
Re: MPC8360E USB Host Controller Driver
On 9/7/06, Alex Zeffertt <[EMAIL PROTECTED]> wrote: > Li Yang-r58472 wrote: > >> i have a MPC8347E running with the Freescale E(F)HCI driver > >> and Kernel 2.6.17 (Freescale LTIB). > >> > >> Because of this mail, i checked, if there are any periodical > >> interrupts, without real USB payload. > >> > >> The result is: NO > >> > >> If i attach a USB-mouse, i get 5 interrupts. > >> If i remove it again, 1 additional. > >> > >> Nothing else, silence ! > >> > >> USB works well with USB 1.1 and 2.0 devices (This was not the > >> case with earlier Kernels, e.g. 2.6.13, because for the > >> switching between 1.1 and 2.0 you need a transaction > >> translator driver). > > > > MPC834x USB is very different from the USB of CPM/QE. It is an > > integrated EHCI controller. > > > > > So, the question is still open, does the QuiccEngine HCI (a.k.a. FHCI) > generate loading on the PPC core when there is no traffic on the USB? Yes, but no. If the bus is idle for some time, you can put the bus into suspend state. Then there will be no extra load to the core. - Leo ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8360E USB Host Controller Driver
On 9/7/06, Laurent Pinchart <[EMAIL PROTECTED]> wrote: > > >I am working in MPC8360E processor board. I want the > > > PowerQUICC II's Pro USB Host controller Driver. In the > > > manual, they told that this controller does not belong to > > > UHCI or OHCI standard. > > > > Yes, you can call it FHCI if you like. :) > > > > > I have doubt that whether Freescale has its own USB standard. > > > > The interface is stated clearly in the UM. > > > > > Please give the link or patch for that driver. > > > > There is an 8360 host driver in Freescale LTIB BSP. Please find it on > > www.freescale.com, if it has been released. > > Could you give a direct link ? I've been browsing around the Freescale website > for an hour, downloaded hundreds of megabytes of archives but haven't been > able to find the MPC8360E USB Linux driver. You can bookmark this link: http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=0127268688033202A5 - Leo ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: MPC8360E USB Host Controller Driver
> i have a MPC8347E running with the Freescale E(F)HCI driver > and Kernel 2.6.17 (Freescale LTIB). > > Because of this mail, i checked, if there are any periodical > interrupts, without real USB payload. > > The result is: NO > > If i attach a USB-mouse, i get 5 interrupts. > If i remove it again, 1 additional. > > Nothing else, silence ! > > USB works well with USB 1.1 and 2.0 devices (This was not the > case with earlier Kernels, e.g. 2.6.13, because for the > switching between 1.1 and 2.0 you need a transaction > translator driver). MPC834x USB is very different from the USB of CPM/QE. It is an integrated EHCI controller. - Leo ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: MPC8360E USB Host Controller Driver
> -Original Message- > From: Alex Zeffertt [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 07, 2006 6:59 PM > To: Li Yang-r58472 > Cc: [EMAIL PROTECTED]; linuxppc-embedded@ozlabs.org > Subject: Re: MPC8360E USB Host Controller Driver > > >> manual, they told that this controller does not belong to UHCI or > >> OHCI standard. > > > > Yes, you can call it FHCI if you like. :) > > I heard that on the PQII (82xx) devices the FHCI required > intervention from the core, even when there was zero traffic > on the USB. I think this was because the core had to > continuously service a 1ms interrupt. This generates > significant extra loading, making it worth considering using > a cheap EHCI chip instead There are improvements on future chips with a QE. However it is still full-speed and need CPU intervention. But keep in mind that USB is not a key feature for netcomm devices which PQ is targeting. > > Does anyone know if this is still the case with the PQII Pro (83xx)? 834x has a integrated EHCI controller instead. - Leo ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: MPC8360E USB Host Controller Driver
> -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > rg] On Behalf Of [EMAIL PROTECTED] > Sent: Thursday, September 07, 2006 4:04 PM > To: linuxppc-embedded@ozlabs.org > Subject: MPC8360E USB Host Controller Driver > > Hi All, >I am working in MPC8360E processor board. I want the > PowerQUICC II's Pro USB Host controller Driver. In the > manual, they told that this controller does not belong to > UHCI or OHCI standard. Yes, you can call it FHCI if you like. :) > > I have doubt that whether Freescale has its own USB standard. The interface is stated clearly in the UM. > > Please give the link or patch for that driver. There is an 8360 host driver in Freescale LTIB BSP. Please find it on www.freescale.com, if it has been released. - Leo ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MPC8245 reset register
LoL, my bad not understanding the humor.
This becomes an interesting topic. I looked at different CPUs, it seems
everyone uses different method to reset itself, and there is no uniformed or
easy for 603e. I searched on google but didn't see anyone have similiar
concern. Actually lots of boxes/systems using MPC8245, why nobody cares
about it? :)
To use watchdog timeout, or gpio port to assert reset line on CPU are not
flexible enough. If using watchdog, I have to enable watchdog and reduce the
timeout length (if it's too long). If using some GPIO device, I'll have to
rely on i2c bus or whatever io interface to write data. Acutally our system
has RESET by a GPIO(PCA9556) port.
Interesting enough, I resolved the problem by writing a data to an invalid
address with hoping for a machine check exception (in fact this is what
u-boot does). Would it be good to make it as a stardard "restart" function
in mpc10x_common.c? If it's acceptable I could send out my patch.
- Reeve
On 9/6/06, Jon Scully wrote:
>
> On 9/5/06, Reeve Yang wrote:
> > I'm kind of curious what's the proper way to reset the
> > 8245 CPU? For anyone who doesn't know MPC8245, which is 603e core.
>
> You could starve the watchdog (assuming SWE=1 in SYPCR). If you own
> the hardware design, you could add an addressable WO latch (FPGA) that
> asserts reset for the right number of clock cycles (what I would
> normally provide or ask for in a design -- but *only* during
> development). Otherwise... If this is for development purposes,
> consider using JTAG (Boundary Scan) to control /SRESET.
>
> (My reference to RST was supposed to be humorous -- as in, remember
> the good old days when you could do that in S/W?! ('RST 7' in Z80 &
> 8085) Sorry for my bad humor.)
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
-- next part --
An HTML attachment was scrubbed...
URL:
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060906/3a42d9f1/attachment.htm
where can I find MPC8245 assembler reference?
Could anyone point me to online document for MPC8245 assembler reference? I couldn't find it anywhere but the command list in user manual. Thanks! - Reeve -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060905/83c90ede/attachment.htm
MPC8245 reset register
Hi Jon, Could you elaborate it a bit? I wrote 0x1 to PI register, but CPU hangs without resetting. I'm kind of curious what's the proper way to reset the 8245 CPU? For anyone who doesn't know MPC8245, which is 603e core. Thanks a lot. - Reeve On 9/2/06, Jon Scully wrote: > > On 9/2/06, Reeve Yang wrote: > > Can anyone tell me which register should I use to do soft reset on > MPC8241/5 > > CPU? I searched its manuall but only find EPIC to send SRESET exception > on > > offset 0x41090. > > > > Thanks. > > > > - Reeve > > > > Use the reset instruction (RST in assembly). > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060905/acea4d5b/attachment.htm
Re: MPC8245 reset register
LoL, my bad not understanding the humor.
This becomes an interesting topic. I looked at different CPUs, it seems
everyone uses different method to reset itself, and there is no
uniformed or easy for 603e. I searched on google but didn't see anyone
have similiar concern. Actually lots of boxes/systems using MPC8245,
why nobody cares about it? :)
To use watchdog timeout, or gpio port to assert reset line on CPU are
not flexible enough. If using watchdog, I have to enable watchdog and
reduce the timeout length (if it's too long). If using some GPIO
device, I'll have to rely on i2c bus or whatever io interface to write
data. Acutally our system has RESET by a GPIO(PCA9556) port.
Interesting enough, I resolved the problem by writing a data to an
invalid address with hoping for a machine check exception (in fact this
is what u-boot does). Would it be good to make it as a stardard
"restart" function in mpc10x_common.c? If it's acceptable I could send
out my patch.
- ReeveOn 9/6/06, Jon Scully <[EMAIL PROTECTED]> wrote:
On 9/5/06, Reeve Yang <[EMAIL PROTECTED]> wrote:> I'm kind of curious what's the proper way to reset the> 8245 CPU? For anyone who doesn't know MPC8245, which is 603e core.
You could starve the watchdog (assuming SWE=1 in SYPCR). If you ownthe hardware design, you could add an addressable WO latch (FPGA) thatasserts reset for the right number of clock cycles (what I would
normally provide or ask for in a design -- but *only* duringdevelopment). Otherwise... If this is for development purposes,consider using JTAG (Boundary Scan) to control /SRESET.(My reference to RST was supposed to be humorous -- as in, remember
the good old days when you could do that in S/W?! ('RST 7' in Z80 &8085) Sorry for my bad humor.)___Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.orghttps://ozlabs.org/mailman/listinfo/linuxppc-embedded
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
where can I find MPC8245 assembler reference?
Could anyone point me to online document for MPC8245 assembler reference? I couldn't find it anywhere but the command list in user manual. Thanks! - Reeve ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8245 reset register
Hi Jon, Could you elaborate it a bit? I wrote 0x1 to PI register, but CPU hangs without resetting. I'm kind of curious what's the proper way to reset the 8245 CPU? For anyone who doesn't know MPC8245, which is 603e core. Thanks a lot. - ReeveOn 9/2/06, Jon Scully <[EMAIL PROTECTED]> wrote: On 9/2/06, Reeve Yang <[EMAIL PROTECTED]> wrote:> Can anyone tell me which register should I use to do soft reset on MPC8241/5> CPU? I searched its manuall but only find EPIC to send SRESET exception on > offset 0x41090.>> Thanks.>> - Reeve>Use the reset instruction (RST in assembly).___Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.orghttps://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MPC8245 reset register
Can anyone tell me which register should I use to do soft reset on MPC8241/5 CPU? I searched its manuall but only find EPIC to send SRESET exception on offset 0x41090. Thanks. - Reeve -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060902/34917fd7/attachment.htm
MPC8245 reset register
Can anyone tell me which register should I use to do soft reset on MPC8241/5 CPU? I searched its manuall but only find EPIC to send SRESET exception on offset 0x41090. Thanks. - Reeve ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Rattler 8347 and USB 2.0
> -Original Message- > From: > linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org > [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.o > rg] On Behalf Of Jamie Guinan > Sent: Friday, September 01, 2006 12:14 AM > To: linuxppc-embedded at ozlabs.org > Subject: Rattler 8347 and USB 2.0 > > > Greetings, > > I have an mpc8347 board here (A&M Rattler 8347). It shipped with a > 2.6.16 patched enough to boot the board, but support for > freescale USB 2.0 (ehci) is not present. > > Working my way backwards in the mainline kernel tree > (2.6.18-rc5), I found drivers/usb/host/ehci-fsl.c, for > FreeScale/PPC EHCI support. > > In that module, usb_hcd_fsl_probe() requires an initialized > "struct fsl_usb2_platform_data", which only appears in > arch/powerpc/sysdev/fsl_soc.c, yet the 2.6.16 patch provided > puts the board in arch/ppc. > > My question is, what would be the best way to go about > getting ehci-fsl.c working with this board? > > 1) Nudge the Rattler port from arch/ppc to arch/powerpc. One > problem with this is that the rattler uses RedBoot, and reading this, > > http://ozlabs.org/pipermail/linuxppc-embedded/2006-August/024116.html > > it looks like arch/powerpc wants to boot from > OpenFirmware-like "flattened device tree" (does RedBoot > support this?). Use a shim which directly builds FDT in kernel to use powerpc arch. > > 2) Support ehci-fsl.c from arch/ppc. If arch/ppc is > deprecated, that's a bad long-term solution. And since > fsl_soc.c lives under arch/powerpc, that doesn't look good either. Actually you don't need fsl_soc.c in ppc arch. There are predefined platform_device and platform_data in arch/ppc/syslib/mpc83xx_devices.c. You can add your usb platform_data there easily.
RE: Rattler 8347 and USB 2.0
> -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > rg] On Behalf Of Jamie Guinan > Sent: Friday, September 01, 2006 12:14 AM > To: linuxppc-embedded@ozlabs.org > Subject: Rattler 8347 and USB 2.0 > > > Greetings, > > I have an mpc8347 board here (A&M Rattler 8347). It shipped with a > 2.6.16 patched enough to boot the board, but support for > freescale USB 2.0 (ehci) is not present. > > Working my way backwards in the mainline kernel tree > (2.6.18-rc5), I found drivers/usb/host/ehci-fsl.c, for > FreeScale/PPC EHCI support. > > In that module, usb_hcd_fsl_probe() requires an initialized > "struct fsl_usb2_platform_data", which only appears in > arch/powerpc/sysdev/fsl_soc.c, yet the 2.6.16 patch provided > puts the board in arch/ppc. > > My question is, what would be the best way to go about > getting ehci-fsl.c working with this board? > > 1) Nudge the Rattler port from arch/ppc to arch/powerpc. One > problem with this is that the rattler uses RedBoot, and reading this, > > http://ozlabs.org/pipermail/linuxppc-embedded/2006-August/024116.html > > it looks like arch/powerpc wants to boot from > OpenFirmware-like "flattened device tree" (does RedBoot > support this?). Use a shim which directly builds FDT in kernel to use powerpc arch. > > 2) Support ehci-fsl.c from arch/ppc. If arch/ppc is > deprecated, that's a bad long-term solution. And since > fsl_soc.c lives under arch/powerpc, that doesn't look good either. Actually you don't need fsl_soc.c in ppc arch. There are predefined platform_device and platform_data in arch/ppc/syslib/mpc83xx_devices.c. You can add your usb platform_data there easily. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
How to turn off MMU in MPC8540
> -Original Message- > From: > linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org > [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.o > rg] On Behalf Of Reddy Suneel-ASR125 > Sent: Wednesday, August 30, 2006 2:25 PM > To: linuxppc-embedded at ozlabs.org > Subject: How to turn off MMU in MPC8540 > > Hi > > Can anyone know how to turn off MMU in MPC8540? I heard that it can't be turned off on e500.
atomic operations in user space
> -Original Message- > From: Liu Dave-r63238 > Sent: Wednesday, August 30, 2006 10:43 AM > To: Li Yang-r58472; 'linuxppc-embedded at ozlabs.org'; 'linuxppc-dev at ozlabs.org' > Subject: RE: RE: atomic operations in user space > > [snip] > > > > > > Is this your reason we cannot do atomic operation in user space? > > > > > > How about the kernel space? You can image it. > > > The context switching as above also happen in kernel space, > > Why we can > > > do atomic operation in kernel space, not do in user space? > > > > > > > There are substantial different between kernel and user > > control path. First, interrupt can't be interrupted by user > > process. Second, context switch can be explicitly controlled > > in kernel, but not in user space. > > I agree this, but from the processor's view, the context switch > is the same to user space and kernel space. The exception > control flow only happen at exception interrupt. Exception is special and tiny part of the kernel, which should be programmed carefully not to break any thing. Anyway, as you found, clear reservation in exception do solve all the problems. > > What is different you point ? > > > > You are assuming the context switching cause the reservation broken. > > > but we can do atomic operation in kernel space. The > > context switching > > > really is the execption of processor, If we can clear the wrong > > > RESERVATION before exception return, I think we can solve this > > > problem. We can dummy stwcx. before exception return or the > > processor > > > automaticly clear the reservation in exception. > > > > I assume stwcx is a costing instruction, and I don't see such > > code indeed.
atomic operations in user space
> -Original Message- > From: Liu Dave-r63238 > Sent: Wednesday, August 30, 2006 10:27 AM > To: Liu Dave-r63238; Li Yang-r58472; linuxppc-embedded at ozlabs.org; > linuxppc-dev at ozlabs.org > Subject: RE: atomic operations in user space > > > [snip] > > > I surely know all the theories you mentioned clearly. But > > please do > > > look at the case I gave. Correct me if I missed anything. Thanks > > > > > > All the lwarx and stwcx operate on the same address. > > > > > > > Task A Task B > > > > lwarx > > > // Get RESERVATION > > > > .. > > > > lwarx > > > > stwcx > > > > > > // RESERVATION cleared > > > > > > > > . > > > > . > > > > lwarx > > > > > > // Get RESERVATION again > > > > stwcx > > > > > > //Note here: RESERVATION is valid, address is the same. > > > So the result is commited, no retry for task A > > > > > > > . > > > > stwcx > > > //RESERVATION is cleared, retry atomic op for task B > > > > > > Please be noted that reservation is only identified by > > reservation bit > > > and address operated on. So different lwarx's on the same address, > > > may be considered as the same reservation. > > > > Is this your reason we cannot do atomic operation in user space? > > > > How about the kernel space? You can image it. > > The context switching as above also happen in kernel space, > > Why we can do atomic operation in kernel space, not do in user space? > > > > You are assuming the context switching cause the reservation broken. > > but we can do atomic operation in kernel space. The context > > switching really is the execption of processor, If we can > > clear the wrong RESERVATION before exception return, I think > > we can solve this problem. We can dummy stwcx. before > > exception return or the processor automaticly clear the > > reservation in exception. > > > > Are you missing these important things? > > > > -DAve > > I got it. I noticed that all of execption return in kernel did stwcx. > to clear the wrong reserved bit. See the source code. > > .globl ret_from_except_full > ret_from_except_full: > REST_NVGPRS(r1) > /* fall through */ > > .globl ret_from_except > ret_from_except: >.. > > restore: > lwz r0,GPR0(r1) > lwz r2,GPR2(r1) > REST_4GPRS(3, r1) > REST_2GPRS(7, r1) > > lwz r10,_XER(r1) > lwz r11,_CTR(r1) > mtspr SPRN_XER,r10 > mtctr r11 > > PPC405_ERR77(0,r1) > stwcx. r0,0,r1 /* to clear the reservation */ Ya, you found the point. There is no problem for me about this question. - Leo
atomic operations in user space
> -Original Message- > From: Liu Dave-r63238 > Sent: Wednesday, August 30, 2006 10:17 AM > To: Li Yang-r58472; linuxppc-embedded at ozlabs.org; linuxppc-dev at ozlabs.org > Subject: RE: atomic operations in user space > > [snip] > > I surely know all the theories you mentioned clearly. But > > please do look at the case I gave. Correct me if I missed > > anything. Thanks > > > > All the lwarx and stwcx operate on the same address. > > > > > Task ATask B > > > lwarx > > // Get RESERVATION > > > .. > > > lwarx > > > stwcx > > > > // RESERVATION cleared > > > > > > . > > > . > > > lwarx > > > > // Get RESERVATION again > > > stwcx > > > > //Note here: RESERVATION is valid, address is the same. > > So the result is commited, no retry for task A > > > > > . > > > stwcx > > //RESERVATION is cleared, retry atomic op for task B > > > > Please be noted that reservation is only identified by > > reservation bit and address operated on. So different > > lwarx's on the same address, may be considered as the same > > reservation. > > Is this your reason we cannot do atomic operation in user space? > > How about the kernel space? You can image it. > The context switching as above also happen in kernel space, > Why we can do atomic operation in kernel space, not do in user space? > There are substantial different between kernel and user control path. First, interrupt can't be interrupted by user process. Second, context switch can be explicitly controlled in kernel, but not in user space. > You are assuming the context switching cause the reservation broken. > but we can do atomic operation in kernel space. The context switching > really is the execption of processor, If we can clear the wrong RESERVATION > before exception return, I think we can solve this problem. We can dummy > stwcx. before exception return or the processor automaticly clear the > reservation in exception. I assume stwcx is a costing instruction, and I don't see such code indeed. - Leo
atomic operations in user space
On 8/30/06, Esben Nielsen wrote: > > > On Tue, 29 Aug 2006, Li Yang wrote: > > >> This is exactly how it is supposed to work! That's why there is a loop > >> in the atomic increment - you check if you still had the reservation > >> after the transaction by checking the result from the stwcx, and if not, > >> retry. > > > > I surely know all the theories you mentioned clearly. But please do > > look at the case I gave. Correct me if I missed anything. Thanks > > > > All the lwarx and stwcx operate on the same address. > > > >> Task A Task B > >> lwarx > > // Get RESERVATION > >> .. > >> lwarx > >> stwcx > > > > // RESERVATION cleared > >> > >> . > >> . > >> lwarx > > > > // Get RESERVATION again > > Now we do a task switch involving atomic operations, and thus an > reservation on another address. > This makes sense for me.
RE: How to turn off MMU in MPC8540
> -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > rg] On Behalf Of Reddy Suneel-ASR125 > Sent: Wednesday, August 30, 2006 2:25 PM > To: linuxppc-embedded@ozlabs.org > Subject: How to turn off MMU in MPC8540 > > Hi > > Can anyone know how to turn off MMU in MPC8540? I heard that it can't be turned off on e500. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
atomic operations in user space
> This is exactly how it is supposed to work! That's why there is a loop > in the atomic increment - you check if you still had the reservation > after the transaction by checking the result from the stwcx, and if not, > retry. I surely know all the theories you mentioned clearly. But please do look at the case I gave. Correct me if I missed anything. Thanks All the lwarx and stwcx operate on the same address. > Task ATask B > lwarx // Get RESERVATION > .. > lwarx > stwcx // RESERVATION cleared > > . > . > lwarx // Get RESERVATION again > stwcx //Note here: RESERVATION is valid, address is the same. So the result is commited, no retry for task A > . > stwcx //RESERVATION is cleared, retry atomic op for task B Please be noted that reservation is only identified by reservation bit and address operated on. So different lwarx's on the same address, may be considered as the same reservation.
RE: RE: atomic operations in user space
> -Original Message- > From: Liu Dave-r63238 > Sent: Wednesday, August 30, 2006 10:43 AM > To: Li Yang-r58472; 'linuxppc-embedded@ozlabs.org'; '[EMAIL PROTECTED]' > Subject: RE: RE: atomic operations in user space > > [snip] > > > > > > Is this your reason we cannot do atomic operation in user space? > > > > > > How about the kernel space? You can image it. > > > The context switching as above also happen in kernel space, > > Why we can > > > do atomic operation in kernel space, not do in user space? > > > > > > > There are substantial different between kernel and user > > control path. First, interrupt can't be interrupted by user > > process. Second, context switch can be explicitly controlled > > in kernel, but not in user space. > > I agree this, but from the processor's view, the context switch > is the same to user space and kernel space. The exception > control flow only happen at exception interrupt. Exception is special and tiny part of the kernel, which should be programmed carefully not to break any thing. Anyway, as you found, clear reservation in exception do solve all the problems. > > What is different you point ? > > > > You are assuming the context switching cause the reservation broken. > > > but we can do atomic operation in kernel space. The > > context switching > > > really is the execption of processor, If we can clear the wrong > > > RESERVATION before exception return, I think we can solve this > > > problem. We can dummy stwcx. before exception return or the > > processor > > > automaticly clear the reservation in exception. > > > > I assume stwcx is a costing instruction, and I don't see such > > code indeed. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: atomic operations in user space
> -Original Message- > From: Liu Dave-r63238 > Sent: Wednesday, August 30, 2006 10:27 AM > To: Liu Dave-r63238; Li Yang-r58472; linuxppc-embedded@ozlabs.org; > [EMAIL PROTECTED] > Subject: RE: atomic operations in user space > > > [snip] > > > I surely know all the theories you mentioned clearly. But > > please do > > > look at the case I gave. Correct me if I missed anything. Thanks > > > > > > All the lwarx and stwcx operate on the same address. > > > > > > > Task A Task B > > > > lwarx > > > // Get RESERVATION > > > > .. > > > > lwarx > > > > stwcx > > > > > > // RESERVATION cleared > > > > > > > > . > > > > . > > > > lwarx > > > > > > // Get RESERVATION again > > > > stwcx > > > > > > //Note here: RESERVATION is valid, address is the same. > > > So the result is commited, no retry for task A > > > > > > > . > > > > stwcx > > > //RESERVATION is cleared, retry atomic op for task B > > > > > > Please be noted that reservation is only identified by > > reservation bit > > > and address operated on. So different lwarx's on the same address, > > > may be considered as the same reservation. > > > > Is this your reason we cannot do atomic operation in user space? > > > > How about the kernel space? You can image it. > > The context switching as above also happen in kernel space, > > Why we can do atomic operation in kernel space, not do in user space? > > > > You are assuming the context switching cause the reservation broken. > > but we can do atomic operation in kernel space. The context > > switching really is the execption of processor, If we can > > clear the wrong RESERVATION before exception return, I think > > we can solve this problem. We can dummy stwcx. before > > exception return or the processor automaticly clear the > > reservation in exception. > > > > Are you missing these important things? > > > > -DAve > > I got it. I noticed that all of execption return in kernel did stwcx. > to clear the wrong reserved bit. See the source code. > > .globl ret_from_except_full > ret_from_except_full: > REST_NVGPRS(r1) > /* fall through */ > > .globl ret_from_except > ret_from_except: >.. > > restore: > lwz r0,GPR0(r1) > lwz r2,GPR2(r1) > REST_4GPRS(3, r1) > REST_2GPRS(7, r1) > > lwz r10,_XER(r1) > lwz r11,_CTR(r1) > mtspr SPRN_XER,r10 > mtctr r11 > > PPC405_ERR77(0,r1) > stwcx. r0,0,r1 /* to clear the reservation */ Ya, you found the point. There is no problem for me about this question. - Leo ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: RE: atomic operations in user space
> -Original Message- > From: Liu Dave-r63238 > Sent: Wednesday, August 30, 2006 10:17 AM > To: Li Yang-r58472; linuxppc-embedded@ozlabs.org; [EMAIL PROTECTED] > Subject: RE: atomic operations in user space > > [snip] > > I surely know all the theories you mentioned clearly. But > > please do look at the case I gave. Correct me if I missed > > anything. Thanks > > > > All the lwarx and stwcx operate on the same address. > > > > > Task ATask B > > > lwarx > > // Get RESERVATION > > > .. > > > lwarx > > > stwcx > > > > // RESERVATION cleared > > > > > > . > > > . > > > lwarx > > > > // Get RESERVATION again > > > stwcx > > > > //Note here: RESERVATION is valid, address is the same. > > So the result is commited, no retry for task A > > > > > . > > > stwcx > > //RESERVATION is cleared, retry atomic op for task B > > > > Please be noted that reservation is only identified by > > reservation bit and address operated on. So different > > lwarx's on the same address, may be considered as the same > > reservation. > > Is this your reason we cannot do atomic operation in user space? > > How about the kernel space? You can image it. > The context switching as above also happen in kernel space, > Why we can do atomic operation in kernel space, not do in user space? > There are substantial different between kernel and user control path. First, interrupt can't be interrupted by user process. Second, context switch can be explicitly controlled in kernel, but not in user space. > You are assuming the context switching cause the reservation broken. > but we can do atomic operation in kernel space. The context switching > really is the execption of processor, If we can clear the wrong RESERVATION > before exception return, I think we can solve this problem. We can dummy > stwcx. before exception return or the processor automaticly clear the > reservation in exception. I assume stwcx is a costing instruction, and I don't see such code indeed. - Leo ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
atomic operations in user space
> -Original Message- > From: Esben Nielsen [mailto:nielsen.esben at gogglemail.com] > Sent: Tuesday, August 29, 2006 5:57 PM > To: Liu Dave-r63238 > Cc: Li Yang-r58472; Esben Nielsen; Xupei Liang; linuxppc-embedded at ozlabs.org > Subject: RE: atomic operations in user space > > > > On Tue, 29 Aug 2006, Liu Dave-r63238 wrote: > > >>> 2) These mutexes are based on futexes which requires atomic > >>> operations in userspace. These are available on most architectures. > > Look at > >>> the glibc code in > >>> nptl/sysdeps/unix/sysv/linux/powerpc/lowlevellock.h for instance. > >>> Use that and your PPC manual to implement your atomic operations. > >> > >> No matter semaphore or futex, it uses system calls to kernel. > > There is only a system call if there is congestion - that is the whole idea > behind the futex. > > >> And the > >> true atomic operation is in kernel not user space. > > "True" atomic operations are available in user space on most architectures. > > >> Maybe > >> it's feasible > >> for other architectures to do atomic operations directly in > >> user space. > >> IMHO, not for powerpc. > > It is available for PowerPC, but not in POWER and POWER2 instructionsets > according to http://www.nersc.gov/vendor_docs/ibm/asm/lwarx.htm#idx607 > It is the same in the ARM world: Atomic instructions was introduced in > ARMv6 I believe. Older ARM processors don't have them. Yes, I do know there are lwarx and stwrx instructions. But there is only one reservation per CPU and reservation can be re-established with no difference. So there are possibilities reservation is broken and reserved again in one atomic block. Task A Task B lwarx .. lwarx stwrx . . lwarx stwrx . stwrx The addresses of above operations are the same. In this case Thread A thinks that it is atomic as it holds the same reservation, but it is actually broken. Such control flow can't be prevented in user space. > > > > > Are you meaning that we didn't do atomic operations directly in user > > space > > on powerpc platform ? > > > > Well, that is not the conclusion I get either when reading the glibc code. > Try to look at glibc-2.3.5/sysdeps/powerpc/bits/atomic.h. > > This is by the way probably what the original post in this thread wanted > in the first place! > > Esben > > > > -DAve
atomic operations in user space
> -Original Message- > From: Esben Nielsen [mailto:nielsen.esben at gogglemail.com] > Sent: Tuesday, August 29, 2006 4:33 PM > To: Li Yang-r58472 > Cc: Xupei Liang; linuxppc-embedded at ozlabs.org > Subject: RE: atomic operations in user space > > > > On Tue, 29 Aug 2006, Li Yang-r58472 wrote: > > >> -Original Message- > >> From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org > >> [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On > > Behalf Of > >> Xupei Liang > >> Sent: Tuesday, August 29, 2006 8:44 AM > >> To: linuxppc-embedded at ozlabs.org > >> Subject: RE: atomic operations in user space > >> > >> I think it is less expensive using atomic operation > >> sometimes in the user space, e.g. when updating a > > > > Atomic operations are working under strict restrictions. Generally they > > won't work for user space. Your best bet is to use semaphore instead. > > > > Wrong. > 1) Semaphores give priority inversions. Use a mutex with priority > inheritance instead. This comes in 2.6.18. > 2) These mutexes are based on futexes which requires atomic operations in > userspace. These are available on most architectures. Look at the glibc code > in nptl/sysdeps/unix/sysv/linux/powerpc/lowlevellock.h forinstance. > Use that and your PPC manual to implement your atomic operations. No matter semaphore or futex, it uses system calls to kernel. And the true atomic operation is in kernel not user space. Maybe it's feasible for other architectures to do atomic operations directly in user space. IMHO, not for powerpc. > > Esben > > >> counter. If this counter is to be updated by a lot of > >> processes, using semaphore can potentially cause a lot > >> of task switching. > >> > >> Regards, > >> > >> Terry Liang > >> > >> > >>> -Original Message----- > >>> From: Brent Cook [mailto:bcook at bpointsys.com] > >>> Sent: Thursday, August 24, 2006 10:18 PM > >>> To: linuxppc-embedded at ozlabs.org > >>> Cc: Li Yang-r58472; Terry Liang > >>> Subject: Re: atomic operations in user space > >>> > >>> On Thursday 24 August 2006 05:39, Li Yang-r58472 > >> wrote: > >>> > >>>> Why do you need atomic operations in user land? > >> IPC will be > >> sufficient > >>> > >>>> to deal with race conditions between processes. > >>> > >>>> > >>> > >>>> Best Regards, > >>> > >>>> Leo > >>> > >>> What about multiple threads within a process > >> updating a counter? > >> > >> Is there anything preventing semaphore to be used in > >> threads? > >>> > >>> Of course, if you look at these functions in the > >> kernel header, > >> they're just 2 or > >>> 3 inline assembly calls - you could easily rewrite > >> them. Google for > >> 'PowerPC atomic > >>> increment' and grab one of the unencumbered > >> implementations if you > >> need to use it > >>> in a non-GPL program. > >>> > >>> On the other hand, I see no license at the top of my > >> /usr/include/asm-i386/atomic.h > >>> file at all, same for PowerPC - are Linux header > >> files actually GPL or > >> are they > >>> more like the glibc headers, with exceptions made > >> for userspace > >> programs? > >>> > >>> The atomic operations on x86 were accidentally > >> exported early on, so > >> they have to > >>> hang around apparently for compatibility (there are > >> some mailing list > >> threads out > >>> there to this effect.) Currently, you just have to > >> assume in Linux > >> that if you > >>> include something from /usr/include/linux or asm > >> that it will not > >> necessarily be > >>> cross-version or cross-architecture compatible. Not > >> every arch in > >> Linux even has > >>> atomic operations of this nature, which I guess is > >> the main reason why > >> they are > >>> not exported in general. > >>> > >>> - Brent > >> > >> > >> > >> __ > >> Do You Yahoo!? > >> Tired of spam? Yahoo! Mail has the best spam protection around > >> http://mail.yahoo.com > >> ___ > >> Linuxppc-embedded mailing list > >> Linuxppc-embedded at ozlabs.org > >> https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > ___ > > Linuxppc-embedded mailing list > > Linuxppc-embedded at ozlabs.org > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > >
atomic operations in user space
> -Original Message- > From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org > [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On Behalf Of > Xupei Liang > Sent: Tuesday, August 29, 2006 8:44 AM > To: linuxppc-embedded at ozlabs.org > Subject: RE: atomic operations in user space > > I think it is less expensive using atomic operation > sometimes in the user space, e.g. when updating a Atomic operations are working under strict restrictions. Generally they won't work for user space. Your best bet is to use semaphore instead. > counter. If this counter is to be updated by a lot of > processes, using semaphore can potentially cause a lot > of task switching. > > Regards, > > Terry Liang > > > > -Original Message- > > From: Brent Cook [mailto:bcook at bpointsys.com] > > Sent: Thursday, August 24, 2006 10:18 PM > > To: linuxppc-embedded at ozlabs.org > > Cc: Li Yang-r58472; Terry Liang > > Subject: Re: atomic operations in user space > > > > On Thursday 24 August 2006 05:39, Li Yang-r58472 > wrote: > > > > > Why do you need atomic operations in user land? > IPC will be > sufficient > > > > > to deal with race conditions between processes. > > > > > > > > > > Best Regards, > > > > > Leo > > > > What about multiple threads within a process > updating a counter? > > Is there anything preventing semaphore to be used in > threads? > > > > Of course, if you look at these functions in the > kernel header, > they're just 2 or > > 3 inline assembly calls - you could easily rewrite > them. Google for > 'PowerPC atomic > > increment' and grab one of the unencumbered > implementations if you > need to use it > > in a non-GPL program. > > > > On the other hand, I see no license at the top of my > /usr/include/asm-i386/atomic.h > > file at all, same for PowerPC - are Linux header > files actually GPL or > are they > > more like the glibc headers, with exceptions made > for userspace > programs? > > > > The atomic operations on x86 were accidentally > exported early on, so > they have to > > hang around apparently for compatibility (there are > some mailing list > threads out > > there to this effect.) Currently, you just have to > assume in Linux > that if you > > include something from /usr/include/linux or asm > that it will not > necessarily be > > cross-version or cross-architecture compatible. Not > every arch in > Linux even has > > atomic operations of this nature, which I guess is > the main reason why > they are > > not exported in general. > > > > - Brent > > > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: atomic operations in user space
On 8/30/06, Esben Nielsen <[EMAIL PROTECTED]> wrote: > > > On Tue, 29 Aug 2006, Li Yang wrote: > > >> This is exactly how it is supposed to work! That's why there is a loop > >> in the atomic increment - you check if you still had the reservation > >> after the transaction by checking the result from the stwcx, and if not, > >> retry. > > > > I surely know all the theories you mentioned clearly. But please do > > look at the case I gave. Correct me if I missed anything. Thanks > > > > All the lwarx and stwcx operate on the same address. > > > >> Task A Task B > >> lwarx > > // Get RESERVATION > >> .. > >> lwarx > >> stwcx > > > > // RESERVATION cleared > >> > >> . > >> . > >> lwarx > > > > // Get RESERVATION again > > Now we do a task switch involving atomic operations, and thus an > reservation on another address. > This makes sense for me. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: atomic operations in user space
> This is exactly how it is supposed to work! That's why there is a loop > in the atomic increment - you check if you still had the reservation > after the transaction by checking the result from the stwcx, and if not, > retry. I surely know all the theories you mentioned clearly. But please do look at the case I gave. Correct me if I missed anything. Thanks All the lwarx and stwcx operate on the same address. > Task ATask B > lwarx // Get RESERVATION > .. > lwarx > stwcx // RESERVATION cleared > > . > . > lwarx // Get RESERVATION again > stwcx //Note here: RESERVATION is valid, address is the same. So the result is commited, no retry for task A > . > stwcx //RESERVATION is cleared, retry atomic op for task B Please be noted that reservation is only identified by reservation bit and address operated on. So different lwarx's on the same address, may be considered as the same reservation. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: atomic operations in user space
> -Original Message- > From: Esben Nielsen [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 29, 2006 5:57 PM > To: Liu Dave-r63238 > Cc: Li Yang-r58472; Esben Nielsen; Xupei Liang; linuxppc-embedded@ozlabs.org > Subject: RE: atomic operations in user space > > > > On Tue, 29 Aug 2006, Liu Dave-r63238 wrote: > > >>> 2) These mutexes are based on futexes which requires atomic > >>> operations in userspace. These are available on most architectures. > > Look at > >>> the glibc code in > >>> nptl/sysdeps/unix/sysv/linux/powerpc/lowlevellock.h for instance. > >>> Use that and your PPC manual to implement your atomic operations. > >> > >> No matter semaphore or futex, it uses system calls to kernel. > > There is only a system call if there is congestion - that is the whole idea > behind the futex. > > >> And the > >> true atomic operation is in kernel not user space. > > "True" atomic operations are available in user space on most architectures. > > >> Maybe > >> it's feasible > >> for other architectures to do atomic operations directly in > >> user space. > >> IMHO, not for powerpc. > > It is available for PowerPC, but not in POWER and POWER2 instructionsets > according to http://www.nersc.gov/vendor_docs/ibm/asm/lwarx.htm#idx607 > It is the same in the ARM world: Atomic instructions was introduced in > ARMv6 I believe. Older ARM processors don't have them. Yes, I do know there are lwarx and stwrx instructions. But there is only one reservation per CPU and reservation can be re-established with no difference. So there are possibilities reservation is broken and reserved again in one atomic block. Task A Task B lwarx .. lwarx stwrx . . lwarx stwrx . stwrx The addresses of above operations are the same. In this case Thread A thinks that it is atomic as it holds the same reservation, but it is actually broken. Such control flow can't be prevented in user space. > > > > > Are you meaning that we didn't do atomic operations directly in user > > space > > on powerpc platform ? > > > > Well, that is not the conclusion I get either when reading the glibc code. > Try to look at glibc-2.3.5/sysdeps/powerpc/bits/atomic.h. > > This is by the way probably what the original post in this thread wanted > in the first place! > > Esben > > > > -DAve ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: atomic operations in user space
> -Original Message- > From: Esben Nielsen [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 29, 2006 4:33 PM > To: Li Yang-r58472 > Cc: Xupei Liang; linuxppc-embedded@ozlabs.org > Subject: RE: atomic operations in user space > > > > On Tue, 29 Aug 2006, Li Yang-r58472 wrote: > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On > > Behalf Of > >> Xupei Liang > >> Sent: Tuesday, August 29, 2006 8:44 AM > >> To: linuxppc-embedded@ozlabs.org > >> Subject: RE: atomic operations in user space > >> > >> I think it is less expensive using atomic operation > >> sometimes in the user space, e.g. when updating a > > > > Atomic operations are working under strict restrictions. Generally they > > won't work for user space. Your best bet is to use semaphore instead. > > > > Wrong. > 1) Semaphores give priority inversions. Use a mutex with priority > inheritance instead. This comes in 2.6.18. > 2) These mutexes are based on futexes which requires atomic operations in > userspace. These are available on most architectures. Look at the glibc code > in nptl/sysdeps/unix/sysv/linux/powerpc/lowlevellock.h forinstance. > Use that and your PPC manual to implement your atomic operations. No matter semaphore or futex, it uses system calls to kernel. And the true atomic operation is in kernel not user space. Maybe it's feasible for other architectures to do atomic operations directly in user space. IMHO, not for powerpc. > > Esben > > >> counter. If this counter is to be updated by a lot of > >> processes, using semaphore can potentially cause a lot > >> of task switching. > >> > >> Regards, > >> > >> Terry Liang > >> > >> > >>> -Original Message----- > >>> From: Brent Cook [mailto:bcook at bpointsys.com] > >>> Sent: Thursday, August 24, 2006 10:18 PM > >>> To: linuxppc-embedded at ozlabs.org > >>> Cc: Li Yang-r58472; Terry Liang > >>> Subject: Re: atomic operations in user space > >>> > >>> On Thursday 24 August 2006 05:39, Li Yang-r58472 > >> wrote: > >>> > >>>> Why do you need atomic operations in user land? > >> IPC will be > >> sufficient > >>> > >>>> to deal with race conditions between processes. > >>> > >>>> > >>> > >>>> Best Regards, > >>> > >>>> Leo > >>> > >>> What about multiple threads within a process > >> updating a counter? > >> > >> Is there anything preventing semaphore to be used in > >> threads? > >>> > >>> Of course, if you look at these functions in the > >> kernel header, > >> they're just 2 or > >>> 3 inline assembly calls - you could easily rewrite > >> them. Google for > >> 'PowerPC atomic > >>> increment' and grab one of the unencumbered > >> implementations if you > >> need to use it > >>> in a non-GPL program. > >>> > >>> On the other hand, I see no license at the top of my > >> /usr/include/asm-i386/atomic.h > >>> file at all, same for PowerPC - are Linux header > >> files actually GPL or > >> are they > >>> more like the glibc headers, with exceptions made > >> for userspace > >> programs? > >>> > >>> The atomic operations on x86 were accidentally > >> exported early on, so > >> they have to > >>> hang around apparently for compatibility (there are > >> some mailing list > >> threads out > >>> there to this effect.) Currently, you just have to > >> assume in Linux > >> that if you > >>> include something from /usr/include/linux or asm > >> that it will not > >> necessarily be > >>> cross-version or cross-architecture compatible. Not > >> every arch in > >> Linux even has > >>> atomic operations of this nature, which I guess is > >> the main reason why > >> they are > >>> not exported in general. > >>> > >>> - Brent > >> > >> > >> > >> __ > >> Do You Yahoo!? > >> Tired of spam? Yahoo! Mail has the best spam protection around > >> http://mail.yahoo.com > >> ___ > >> Linuxppc-embedded mailing list > >> Linuxppc-embedded@ozlabs.org > >> https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > ___ > > Linuxppc-embedded mailing list > > Linuxppc-embedded@ozlabs.org > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: atomic operations in user space
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Xupei Liang > Sent: Tuesday, August 29, 2006 8:44 AM > To: linuxppc-embedded@ozlabs.org > Subject: RE: atomic operations in user space > > I think it is less expensive using atomic operation > sometimes in the user space, e.g. when updating a Atomic operations are working under strict restrictions. Generally they won't work for user space. Your best bet is to use semaphore instead. > counter. If this counter is to be updated by a lot of > processes, using semaphore can potentially cause a lot > of task switching. > > Regards, > > Terry Liang > > > > -Original Message- > > From: Brent Cook [mailto:bcook at bpointsys.com] > > Sent: Thursday, August 24, 2006 10:18 PM > > To: linuxppc-embedded at ozlabs.org > > Cc: Li Yang-r58472; Terry Liang > > Subject: Re: atomic operations in user space > > > > On Thursday 24 August 2006 05:39, Li Yang-r58472 > wrote: > > > > > Why do you need atomic operations in user land? > IPC will be > sufficient > > > > > to deal with race conditions between processes. > > > > > > > > > > Best Regards, > > > > > Leo > > > > What about multiple threads within a process > updating a counter? > > Is there anything preventing semaphore to be used in > threads? > > > > Of course, if you look at these functions in the > kernel header, > they're just 2 or > > 3 inline assembly calls - you could easily rewrite > them. Google for > 'PowerPC atomic > > increment' and grab one of the unencumbered > implementations if you > need to use it > > in a non-GPL program. > > > > On the other hand, I see no license at the top of my > /usr/include/asm-i386/atomic.h > > file at all, same for PowerPC - are Linux header > files actually GPL or > are they > > more like the glibc headers, with exceptions made > for userspace > programs? > > > > The atomic operations on x86 were accidentally > exported early on, so > they have to > > hang around apparently for compatibility (there are > some mailing list > threads out > > there to this effect.) Currently, you just have to > assume in Linux > that if you > > include something from /usr/include/linux or asm > that it will not > necessarily be > > cross-version or cross-architecture compatible. Not > every arch in > Linux even has > > atomic operations of this nature, which I guess is > the main reason why > they are > > not exported in general. > > > > - Brent > > > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
How to boot powerPC linux-2.6.10 from diifferent address other than 0x0000
You need to do two things: - mem remap your boot sector memory block to virtual address 0xc0008000 - using uboot commond "go xxx" to boot it from 0xc0008000, or define env variable "bootcmd", and run "boot". On 8/25/06, Reddy Suneel-ASR125 wrote: > > Hi, > We are working on MPC 8540, Linux kernel version is 2.6.10 from > Montavista. The bootloader used in Uboot and currently it loads the uImage > at physical memory address 0x0 and transfers control to it. We want to load > the kernel at a different address say 0x8000 and for this we made the > following changes. > > 1) Altered the Makefile to linked the kernel at virtual address 0xc0008000 > ( the default was 0xc000:) > 2) Modified Uboot to load kernel at 0x8000 instead of 0x0 > > The kernel space still starts from 0xc000: > > When we transferred control to the kernel (loaded at 0x8000) we found that > the execution proceeds only till the mapping and invalidation on TLBs. We do > not know where the control goes after this as the further instructions does > not seems to get executed. Currently we do not have the provision to connect > a debugger and hence we are unable to make out what is happening. > > Can some one give us any clue as to what we might have done wrong? This is > our first experience on PowerPC. > > > Thanks®ards > Suneel > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060828/bd867c75/attachment.htm
Help with booting with very large initrd
I had a similiar problem long time ago. I remember it was related to the size of ramdisk. Double check if your ramdisk size big enough. On 8/25/06, Howard, Marc wrote: > > Hi, > > I'm developing a PPC440GX based board that uses U-Boot to boot a > multi-file boot image composed of the kernel and a very large (> 96MB > uncompressed) initrd file. The board has 512MB of RAM of which the > upper 16MB is reserved for dedicated hardware. The 16MB block is > reserved via "mem=496M" and U-Boot is told to stay out of that area by > setting "initrd_high=1f00". > > Before anyone asks there are several reasons for doing things this way. > NFS is not an option in the target environment. > > I can tftp the combined boot image to my board. I checked the crc with > the crc32 command and it agrees exactly with the result obtained on the > host machine using the boot file. Therefore there is not a "TFTP >32MB" > problem here. > > If I boot I get the following: > > => boot > Waiting for PHY auto negotiation to complete... done > ENET Speed is 1000 Mbps - FULL duplex connection > Using ppc_4xx_eth2 device > TFTP from server 192.168.168.108; our IP address is 192.168.168.111 > Filename 'pMulti-ramdisk'. > Load address: 0x40 > Loading: * > done > Bytes transferred = 38825407 (2506dbf hex) > Automatic boot of image at addr 0x0040 ... > ## Booting image at 0040 ... >Image Name: Linux-2.6.10_mvl401-440gx_eval-I >Created: 2006-08-25 1:01:29 UTC >Image Type: PowerPC Linux Multi-File Image (gzip compressed) >Data Size:38825343 Bytes = 37 MB >Load Address: >Entry Point: >Contents: >Image 0: 1137986 Bytes = 1.1 MB >Image 1: 37687343 Bytes = 35.9 MB >Verifying Checksum ... OK >Uncompressing Multi-File Image ... OK >Loading Ramdisk to 1cc0e000, end 1efff02f ... OK > Linux version 2.6.10_mvl401-440gx_eval (cram at toaster.kla-tencor.com) > (gcc version 3.4.3 (MontaVista 3.4.3-25.0.107.0601076 2006-07-21)) #46 > Thu Aug 24 17:28:09 PDT 2006 > IBM Ocotea port (MontaVista Software, Inc. ) > Built 1 zonelists > Kernel command line: ramdisk_size=262144 root=/dev/ram rw > console=ttyS0,115200 > ip=192.168.168.111:192.168.168.108::255.255.255.0:scpu2:eth0: off > mem=496M > PID hash table entries: 2048 (order: 11, 32768 bytes) > > ..stuff deleted.. > > RAMDISK driver initialized: 8 RAM disks of 262144K size 1024 blocksize > loop: loaded (max 8 devices) > > ..more stuff deleted.. > > eth0: link is down > eth0: link is up, 1000 FDX, pause enabled > IP-Config: Complete: > device=eth0, addr=192.168.168.111, mask=255.255.255.0, > gw=255.255.255.255, host=scpu2, domain=, nis-domain=(none), > bootserver=192.168.168.108, rootserver=192.168.168.108, rootpath= > RAMDISK: Compressed image found at block 0 > crc error (orig 0x9a278d64, CRC_VALUE 0xa7bcd2e3 -- ignoring! > length error (orig = 0x0c00, bytes_out = 0x0c15 -- ignored > VFS: Mounted root (ext2 filesystem). > Freeing unused kernel memory: 120k init > Warning: unable to open an initial console. > Kernel panic - not syncing: No init found. Try passing init= option to > kernel. > <0>Rebooting in 180 seconds.. > > (I modified lib/inflate.c so that the crc and length checks would > provide more info). > > Since the overall file CRC is good and U-Boot checksums are also okay > this looks like some sort of size limitation with the inflate routine. > BTW, The kerenel was made assuming a 256MB ramdisk; likewise the command > line specs one as well. The initrd image would fit easily in that > space. > > Have any of you worked on this problem before and come up with a > solution? > > Thanks, > > Marc Howard > > > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060828/4fbedbb6/attachment.htm
Re: How to boot powerPC linux-2.6.10 from diifferent address other than 0x0000
You need to do two things: - mem remap your boot sector memory block to virtual address 0xc0008000 - using uboot commond "go xxx" to boot it from 0xc0008000, or define env variable "bootcmd", and run "boot". On 8/25/06, Reddy Suneel-ASR125 <[EMAIL PROTECTED]> wrote: Hi, We are working on MPC 8540, Linux kernel version is 2.6.10 from Montavista. The bootloader used in Uboot and currently it loads the uImage at physical memory address 0x0 and transfers control to it. We want to load the kernel at a different address say 0x8000 and for this we made the following changes. 1) Altered the Makefile to linked the kernel at virtual address 0xc0008000 ( the default was 0xc000:) 2) Modified Uboot to load kernel at 0x8000 instead of 0x0 The kernel space still starts from 0xc000: When we transferred control to the kernel (loaded at 0x8000) we found that the execution proceeds only till the mapping and invalidation on TLBs. We do not know where the control goes after this as the further instructions does not seems to get executed. Currently we do not have the provision to connect a debugger and hence we are unable to make out what is happening. Can some one give us any clue as to what we might have done wrong? This is our first experience on PowerPC. Thanks®ards Suneel ___Linuxppc-embedded mailing list[EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Help with booting with very large initrd
I had a similiar problem long time ago. I remember it was related to the size of ramdisk. Double check if your ramdisk size big enough.On 8/25/06, Howard, Marc <[EMAIL PROTECTED] > wrote:Hi,I'm developing a PPC440GX based board that uses U-Boot to boot a multi-file boot image composed of the kernel and a very large (> 96MBuncompressed) initrd file. The board has 512MB of RAM of which theupper 16MB is reserved for dedicated hardware. The 16MB block isreserved via "mem=496M" and U-Boot is told to stay out of that area by setting "initrd_high=1f00".Before anyone asks there are several reasons for doing things this way.NFS is not an option in the target environment.I can tftp the combined boot image to my board. I checked the crc with the crc32 command and it agrees exactly with the result obtained on thehost machine using the boot file. Therefore there is not a "TFTP >32MB"problem here.If I boot I get the following: => bootWaiting for PHY auto negotiation to complete... doneENET Speed is 1000 Mbps - FULL duplex connectionUsing ppc_4xx_eth2 deviceTFTP from server 192.168.168.108 ; our IP address is 192.168.168.111Filename 'pMulti-ramdisk'.Load address: 0x40Loading: *doneBytes transferred = 38825407 (2506dbf hex)Automatic boot of image at addr 0x0040 ... ## Booting image at 0040 ... Image Name: Linux-2.6.10_mvl401-440gx_eval-I Created: 2006-08-25 1:01:29 UTC Image Type: PowerPC Linux Multi-File Image (gzip compressed) Data Size:38825343 Bytes = 37 MB Load Address: Entry Point: Contents: Image 0: 1137986 Bytes = 1.1 MB Image 1: 37687343 Bytes = 35.9 MB Verifying Checksum ... OK Uncompressing Multi-File Image ... OK Loading Ramdisk to 1cc0e000, end 1efff02f ... OKLinux version 2.6.10_mvl401-440gx_eval ([EMAIL PROTECTED])(gcc version 3.4.3 (MontaVista 3.4.3-25.0.107.0601076 2006-07-21)) #46Thu Aug 24 17:28:09 PDT 2006IBM Ocotea port (MontaVista Software, Inc. <[EMAIL PROTECTED]>)Built 1 zonelistsKernel command line: ramdisk_size=262144 root=/dev/ram rw console=ttyS0,115200ip=192.168.168.111:192.168.168.108::255.255.255.0:scpu2:eth0: offmem=496MPID hash table entries: 2048 (order: 11, 32768 bytes)..stuff deleted.. RAMDISK driver initialized: 8 RAM disks of 262144K size 1024 blocksizeloop: loaded (max 8 devices)..more stuff deleted..eth0: link is downeth0: link is up, 1000 FDX, pause enabled IP-Config: Complete: device=eth0, addr=192.168.168.111, mask=255.255.255.0,gw=255.255.255.255, host=scpu2, domain=, nis-domain=(none), bootserver=192.168.168.108, rootserver=192.168.168.108, rootpath=RAMDISK: Compressed image found at block 0crc error (orig 0x9a278d64, CRC_VALUE 0xa7bcd2e3 -- ignoring! length error (orig = 0x0c00, bytes_out = 0x0c15 -- ignoredVFS: Mounted root (ext2 filesystem).Freeing unused kernel memory: 120k initWarning: unable to open an initial console.Kernel panic - not syncing: No init found. Try passing init= option to kernel. <0>Rebooting in 180 seconds..(I modified lib/inflate.c so that the crc and length checks wouldprovide more info).Since the overall file CRC is good and U-Boot checksums are also okay this looks like some sort of size limitation with the inflate routine.BTW, The kerenel was made assuming a 256MB ramdisk; likewise the commandline specs one as well. The initrd image would fit easily in that space.Have any of you worked on this problem before and come up with asolution?Thanks,Marc Howard___Linuxppc-embedded mailing list [EMAIL PROTECTED]https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Cache coherency question
> -Original Message- > From: Liu Dave-r63238 > Sent: Monday, August 28, 2006 3:00 PM > To: Li Yang-r58472; 'Martin, Tim'; 'ppc' > Subject: RE: Cache coherency question > > > > Looking from source code, there is such problem for MV64360. > > It's likely that MV54360 has the same problem. > > What is the MV54360? >From document at http://www.motorola.com/mot/doc/5/5503_MotDoc.pdf#search=%22MV54360%22 The board uses MV54360. I don't know if it is a typo or new variant though. > > -Dave
Cache coherency question
> -Original Message- > From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org > [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On Behalf Of > Liu Dave-r63238 > Sent: Monday, August 28, 2006 11:18 AM > To: Martin, Tim; ppc > Subject: RE: Cache coherency question > > > Ah. This must be the problem. I have a few PCI devices, and > > on one of them it looked like snooping was working. I just > > assumed the other device was setup correctly. > > Why one is looked like snooping was working, and the other device > not working? > > > > Also, you can define the CONFIG_NOT_COHERENT_CACHE, then you are > > > assuming The system has not hardware coherency. You need use the > > > software to keep the cache coherency. > > > > > > > I tried this, and got compiler errors. Which arch are you using? powerpc or ppc? CONFIG_NOT_COHERENT_CACHE doesn't seem to be ported to powerpc arch completely. > > What is the file got compiler errors? I notice that the > /ev64360_defconfig > Did define CONFIG_NOT_COHERENT_CACHE. > > > > I added some inline assembly dcbi/dcbf (invalidate/flush) > > instructions to the particular code in question, and the > > problems went away. So definitely a cache problem. As I > > said above, defining CONFIG_NOT_COHERENT_CACHE causes > > compiler errors, so I'm going to look into this more. I > > suppose whatever file implements the > > include/linux/dma-mapping.h stuff isn't BSP specific, so its > > probably just not being compiled in? Will look into it. > > Somebody said from maillist. The bridge MV64360 seems > having some issue about cache coherent. I don't know if it is really? Looking from source code, there is such problem for MV64360. It's likely that MV54360 has the same problem.
atomic operations in user space
> -Original Message- > From: Brent Cook [mailto:bcook at bpointsys.com] > Sent: Thursday, August 24, 2006 10:18 PM > To: linuxppc-embedded at ozlabs.org > Cc: Li Yang-r58472; Terry Liang > Subject: Re: atomic operations in user space > > On Thursday 24 August 2006 05:39, Li Yang-r58472 wrote: > > > Why do you need atomic operations in user land? IPC will be sufficient > > > to deal with race conditions between processes. > > > > > > Best Regards, > > > Leo > > What about multiple threads within a process updating a counter? Is there anything preventing semaphore to be used in threads? > > Of course, if you look at these functions in the kernel header, they're just 2 or > 3 inline assembly calls - you could easily rewrite them. Google for 'PowerPC atomic > increment' and grab one of the unencumbered implementations if you need to use it > in a non-GPL program. > > On the other hand, I see no license at the top of my /usr/include/asm-i386/atomic.h > file at all, same for PowerPC - are Linux header files actually GPL or are they > more like the glibc headers, with exceptions made for userspace programs? > > The atomic operations on x86 were accidentally exported early on, so they have to > hang around apparently for compatibility (there are some mailing list threads out > there to this effect.) Currently, you just have to assume in Linux that if you > include something from /usr/include/linux or asm that it will not necessarily be > cross-version or cross-architecture compatible. Not every arch in Linux even has > atomic operations of this nature, which I guess is the main reason why they are > not exported in general. > > - Brent
I2C driver for SAA7121 on MPC855 and linux-2.4.25
> -Original Message- > From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org > [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On Behalf Of > Xu, Li (GE, Research) > Sent: Thursday, August 24, 2006 4:02 PM > To: linuxppc-embedded at ozlabs.org > Subject: I2C driver for SAA7121 on MPC855 and linux-2.4.25 > > Hi, > > I am trying to setup i2c driver for saa7121 on my mpc855 based board > normally the address for saa7121 is 0x88, but when I enable i2c bus > scan, the driver detect it's address is 0x34, so I just stick to 0x34. Is it the only device on i2c bus? > > Anyway, I can write to saa7121via i2c bus successfully, but I can't enable > color bar, so I don't know whether the driver is working properly or not? Are you sure you are operating on the correct device? What operation can you do successfully on the device? Can you read from the i2c bus? > > BTW, I setup I2C driver for SAA7113 and it works fine. > > Tim
atomic operations in user space
Why do you need atomic operations in user land? IPC will be sufficient to deal with race conditions between processes. Best Regards, Leo > -Original Message- > From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org > [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On Behalf Of > Terry Liang > Sent: Thursday, August 24, 2006 3:04 AM > To: linuxppc-embedded at ozlabs.org > Subject: atomic operations in user space > > Thanks. Arnd. My main concern is whether the operations are really atomic as they > are in the kernel space. I have read some discussion in another forum that on other > platforms, even if you are able to compile the atomic_add(), atomic_set(), etc. > from an user space application, they don't guarantee to be atomic. Thanks. > > Regards, > > Terry Liang
USB-Driver for Freescale ehci-fsl.c on Kernel 2.6.17
ehci-fsl.c is included in ehci.c, not handled by Makefile. Best Regards, Leo > -Original Message- > From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org > [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On Behalf Of > Claus Gindhart > Sent: Friday, August 18, 2006 2:26 PM > To: linuxppc-embedded at ozlabs.org > Subject: USB-Driver for Freescale ehci-fsl.c on Kernel 2.6.17 > > Hi, > > currently i am migrating an existing Linux-BSP for the MPC8347/9 from Kernel 2.6.13 > to 2.6.17 with flattened device tree. > > Now, i recognized, that the Makefile and Kconfig in drivers/usb/host do not have > any entries to configure and compile the ehci-fsl.c driver. > > Does this mean, that ehci-fsl.c is no longer required, because the generic > EHCI-driver now handles this; or is it just the case, that USB for Freescale > processor was not yet tested on Kernel 2.6.17 ? > > -- > Mit freundlichen Gruessen / Best regards > > Claus Gindhart > SW R&D > Kontron Modular Computers > phone :++49 (0)8341-803-374 > mailto:claus.gindhart at kontron-modular.com > http://www.kontron.com > > -BEGIN GEEK CODE BLOCK- > Version: 3.1 > GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o? > K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++ > D-- G e++> h--- !r x+++ > --END GEEK CODE BLOCK-- > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
how to generate kernel.img
I don't think "kernel.img" is a standard name for any kind of images. Maybe you have to look into the content to find out which kind of image it is. Best Regards, Leo > -Original Message- > From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org > [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On Behalf Of > tony > Sent: Thursday, August 10, 2006 5:01 PM > To: linuxppc-embedded at ozlabs.org > Subject: how to generate kernel.img > > Dear all > sometimes I met the "kernel.img", I guess it may generated by the tool "mkimage", > right? and how to generate a kernel.img file during we compile the linux kernel? > any idea is welcome. > thanks. > > > > > Sincerely > Tony > >
Trouble on building crossover compiler for Synology 8041 PPCbased NAS
http://images.tomshardware.com/2006/06/28/not_going_wrong_with_the_synol ogy_ds/synology_ds106e_main_board_big.jpg Here is a picture of the exact model. I can confirm that it's a MPC8241. Best Regards, Leo > -Original Message- > From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org > [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On Behalf Of > David Hawkins > Sent: Wednesday, August 09, 2006 12:48 AM > To: chun fung siu > Cc: linuxppc-embedded at ozlabs.org > Subject: Re: Trouble on building crossover compiler for Synology 8041 PPCbased NAS > > chun fung siu wrote: > > Hi, > > > > I recently bought a Synology Network Attached Server DS-106e, run using > > a "Linux 2. 4.22-uc-0" Kernel, under 8041 PPC, no "gcc" installed. I > > want to build a crosslink gcc compiler for it in another "debian 2.6 > > kernel" linux. I find many options in the crosslink build script on ppc, > > but can't find any option for 8041 PPC. So what option should I choose? > > And further can I put the artifacts just compiled in my Network Attached > > Server? So that I can compile anything directly in my NAS. > > The processor is probably an *MPC8241*. > > The DS101g is also an MPC8241. So this should provide you with > some useful info: > > http://www.nslu2-linux.org/wiki/DS101/HomePage > http://www.nslu2-linux.org/wiki/DS101/DS101GHardware > > Dave > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
cpm_dpalloc
I'm not very familiar with SPI. See if someone on the list can help. Best Regards, Leo > -Original Message- > From: Keinen Namen [mailto:GSM909 at gmx.de] > Sent: Monday, July 31, 2006 9:39 PM > To: Li Yang-r58472 > Subject: Re: RE: RE: cpm_dpalloc > > Thx, now it?s working fine. > > But my Problem didn?t solved :( > But I have an other Question about SPI. > > How can I see that the init of RX and TX Parameter are succsesful ? > I just looking till the CPM_CR_FLG till is cleard but I did not see if the > init > is ok? > > I try to look at the RX internal byte count in the Parameter ram, but there > is nothing > chance. > > Regards > Fred > > Original-Nachricht > Datum: Mon, 31 Jul 2006 17:24:30 +0800 > Von: "Li Yang-r58472" > An: "Keinen Namen" > Betreff: RE: RE: cpm_dpalloc > > > Yes, but that patch is for powerpc arch. You can use this patch for ppc. > > http://patchwork.ozlabs.org/linuxppc/patch?id=4317 > > > > Best Regards, > > Leo > > > -Original Message- > > > From: Keinen Namen [mailto:GSM909 at gmx.de] > > > Sent: Monday, July 31, 2006 5:21 PM > > > To: Li Yang-r58472 > > > Subject: Re: RE: cpm_dpalloc > > > > > > Thanks for your fast Help. > > > > > > I?m not firm in patches. Is this the patch ? > > > http://lkml.org/lkml/2006/6/30/108 > > > > > > Regards > > > Fred > > > Original-Nachricht > > > Datum: Mon, 31 Jul 2006 16:56:54 +0800 > > > Von: "Li Yang-r58472" > > > An: GSM909 at gmx.de, linuxppc-embedded at ozlabs.org > > > Betreff: RE: cpm_dpalloc > > > > > > > There is a bug in rheap for alignment. The patch is still hanging > > around. > > > > > > > > Search rheap and alignment on the linuxppc-dev list for patch > > previously > > > > posted. > > > > > > > > Best Regards, > > > > Leo > > > > > -Original Message- > > > > > From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org > > > > > [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] > > > > > On > > > > Behalf Of > > > > > GSM909 at gmx.de > > > > > Sent: Monday, July 31, 2006 4:50 PM > > > > > To: linuxppc-embedded at ozlabs.org > > > > > Subject: cpm_dpalloc > > > > > > > > > > Hi All > > > > > > > > > > I have a MPC82xx Processor from Freescale with Linux 2.6.14 ( Can?t > > > > chance to an > > > > > new version). > > > > > > > > > > My Problem is that I want to allocate a 64byte of memory in the dual > > > > ported ram > > > > > with an alignment of 64bytes. (Needed for SPI Parameter Ram) > > > > > > > > > > the funktion cpm_dpalloc(64,64) returned 0x220 but that are not in a > > 64 > > > > byte > > > > > alignment. > > > > > > > > > > Regards > > > > > Fred > > > > > -- > > > > > > > > > > > > > > > Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! > > > > > Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer > > > > > ___ > > > > > Linuxppc-embedded mailing list > > > > > Linuxppc-embedded at ozlabs.org > > > > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > > > ___ > > > > Linuxppc-embedded mailing list > > > > Linuxppc-embedded at ozlabs.org > > > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > > > > > -- > > > > > > > > > Echte DSL-Flatrate dauerhaft f?r 0,- Euro*. Nur noch kurze Zeit! > > > "Feel free" mit GMX DSL: http://www.gmx.net/de/go/dsl > > -- > > > Echte DSL-Flatrate dauerhaft f?r 0,- Euro*. Nur noch kurze Zeit! > "Feel free" mit GMX DSL: http://www.gmx.net/de/go/dsl
cpm_dpalloc
There is a bug in rheap for alignment. The patch is still hanging around. Search rheap and alignment on the linuxppc-dev list for patch previously posted. Best Regards, Leo > -Original Message- > From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org > [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On > Behalf Of > GSM909 at gmx.de > Sent: Monday, July 31, 2006 4:50 PM > To: linuxppc-embedded at ozlabs.org > Subject: cpm_dpalloc > > Hi All > > I have a MPC82xx Processor from Freescale with Linux 2.6.14 ( Can?t chance to > an > new version). > > My Problem is that I want to allocate a 64byte of memory in the dual ported > ram > with an alignment of 64bytes. (Needed for SPI Parameter Ram) > > the funktion cpm_dpalloc(64,64) returned 0x220 but that are not in a 64 byte > alignment. > > Regards > Fred > -- > > > Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! > Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Host USB on MPC8247
> -Original Message- > From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org > [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On Behalf Of > Uros Borovsak > Sent: Monday, July 31, 2006 4:14 PM > To: linuxppc-embedded at ozlabs.org > Subject: Re: Host USB on MPC8247 > > Thanks for reply, > > I made a mistake while typing the message. > > In reality I was asking how difficult would it be to port USB part of > kernel from 2.6.10 to 2.6.13, but I mixed kernel version's when typing. USB subsystem is relatively stand-alone. So, try replace the whole drivers/usb/ directory and update usb related header files under include/. ps: the question is off-topic on powerpc list. > > Mike Rapoport wrote: > > Uros Borovsak wrote: > > > > > >> Hello, > >> > >> Can you at least give me some idea how difficult would it be to patch > >> USB part of kernel from 2.6.13 to 2.6.10? > >> > >> > >> > > As far as I know USB core undergone signifcant changes between 2.6.10 > > and 2.6.13. Still it's hard to tell how difficult would it be to > > backport USB from 2.6.13 to 2.6.10. > > Besides, it maybe worth upgrading your kernel instead of backporing > > USB to 2.6.10. > > > > > Upgrading the whole kernel is not a way to go for me here, becouse > company is using montavista kernel, and if I upgrade the whole kernel, I > would have to port all their patches also. > > I believe that MontaVista will use higher kernel version some time, so I > wouldn't go backporting driver to 2.6.10, but I would prefer to port USB > part of kernel from 2.6.10 to 2.6.13. > > Do you think that is possible and how hard would it be? > > Best regards > > Uros > >> Are changes only in usb part of kernel, or are there also some > >> changes in other parts of kernel, that I would have to port? > >> > >> Thanks, > >> > >> Best regards > >> > >> Uros
Linux bin Commands download
So you are using embedded powerpc platform? There are several embedded Linux distributions, e.g. from montavista, denx, and Freescale. You can google them yourself. If you are using Freescale powerpc, I would recommend the LTIB BSP packages which can be downloaded at www.freescale.com Best Regards, Leo > -Original Message- > From: andreas Sotirakopoulos [mailto:menwn at yahoo.co.uk] > Sent: Thursday, July 20, 2006 4:34 PM > To: Li Yang-r58472 > Subject: Re: Linux bin Commands download > > On Wednesday 19 July 2006 08:31, you wrote: > Thanks, I would like though to know... is rpm suitable for the purpose i want > them? > I want to store the commands (lets say the command ls) in a directory > on a FreeBSD 6 box (i386) and export this directory for NFS so as to mount it > bfrom the powerpc and run the commands from that directory. > thanks in advance > andreas > > > -Original Message- > > > From: linuxppc-dev-bounces+leoli=freescale.com at ozlabs.org > > > [mailto:linuxppc-dev-bounces+leoli=freescale.com at ozlabs.org] On Behalf > > > > Of none > > > > > none > > > Sent: Tuesday, July 18, 2006 8:35 PM > > > To: linuxppc-dev at ozlabs.org > > > Subject: Linux bin Commands download > > > > > > Hi > > > I would like to download precompiled linux commands > > > and programs for powerPC but i cannot find any > > > binaries anyware. Are there any links? > > > > You can find rpm at http://rpmfind.net. And there are also a couple of > > powerpc distributions out there. > > > > > thanks in advance > > > sotirakopoulos andreas > > > > > ___ > All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of > use." - PC Magazine > http://uk.docs.yahoo.com/nowyoucan.html
reboot on PQ2FADS board.
> -Original Message- > From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org > [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On Behalf Of Lei Sun > Sent: Tuesday, July 18, 2006 11:41 AM > To: linuxppc-embedded at ozlabs.org > Subject: reboot on PQ2FADS board. > > Hi: > I have linux 2.4.30 runnning on this board, the "reboot -f" > command cause machine check and kernel ooops. The problem seems in > the "m8260_gorom" in head.S. The restart() function in m8260_setup.c > passed 2 parameters to that assembly code, r3 is the bd_info , r4 is > the warm start address, I changed it to 0xFF800100, that's where the > u-boot's _start_warm lives, I have verified that address by typing "g > ff800100" in u-boot console, which cause the board reset. Are you sure ff800100 is _start_warm lives? In latest u-boot _start_warm is at EXC_OFF_SYS_RESET + 0x10. In your case, that will be 0xff800110. Please try with the correct address. > I assume the m8260_gorom has been heavily tested for other > boards. I wonder if anyone got a PQ2FADS-VR board that has the similar > problem? I am not familar with the assembly code for PPC. Any > suggestions? > > Thanks > lei > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
weird behavior for jffs2 on PQ2FADS-VR board
Here is the kernel config we used, you can have a try. # Memory Technology Devices (MTD) # CONFIG_MTD=y # CONFIG_MTD_DEBUG is not set CONFIG_MTD_PARTITIONS=y # CONFIG_MTD_CONCAT is not set # CONFIG_MTD_REDBOOT_PARTS is not set # CONFIG_MTD_CMDLINE_PARTS is not set # # User Modules And Translation Layers # CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y # CONFIG_FTL is not set # CONFIG_NFTL is not set # # RAM/ROM/Flash chip drivers # # CONFIG_MTD_CFI is not set CONFIG_MTD_JEDECPROBE=y CONFIG_MTD_GEN_PROBE=y CONFIG_MTD_CFI_ADV_OPTIONS=y # CONFIG_MTD_CFI_NOSWAP is not set # CONFIG_MTD_CFI_BE_BYTE_SWAP is not set CONFIG_MTD_CFI_LE_BYTE_SWAP=y # CONFIG_MTD_CFI_GEOMETRY is not set CONFIG_MTD_CFI_INTELEXT=y # CONFIG_MTD_CFI_AMDSTD is not set # CONFIG_MTD_CFI_STAA is not set # CONFIG_MTD_RAM is not set # CONFIG_MTD_ROM is not set # CONFIG_MTD_ABSENT is not set # CONFIG_MTD_OBSOLETE_CHIPS is not set # CONFIG_MTD_AMDSTD is not set # CONFIG_MTD_SHARP is not set # CONFIG_MTD_JEDEC is not set Best Regards, Leo > -Original Message- > From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org > [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On Behalf > Of Lei Sun > Sent: Wednesday, July 12, 2006 12:23 PM > To: linuxppc-embedded at ozlabs.org > Subject: weird behavior for jffs2 on PQ2FADS-VR board > > Hi all: > I brought up linux-2.4.30 on PQ2FADS-VR board, everything was fine > untill i try to mount the jffs2. My mtd partition looks like this: > > dev:size erasesize name > mtd0: 0080 0004 "Flash SIMM" > mtd1: 0008 0004 "u-boot" > mtd2: 0010 0004 "Kernel" > mtd3: 0058 0004 "Rootfs" > mtd4: 0008 0004 "u-boot env" > mtd5: 0008 0004 "unused" > > Basically, I tried > "eraseall /dev/mtd3", and then > "mount -t jffs2 /dev/mtdblock3 /mnt", it showed as mounted, then I > issued "echo "hello,world" > test.txt" to create a file, > a warning was printed out > "Node totlen on flash (0x4400) != totlen in node ref (0x0044)" > , but subsequent > "cat test.txt " still showed the correct string from that newly created file". > However, after I umount the file and remount it again, it give me > lots of errors" > Magic bitmask 0x1985 not found at 0x00240004: 0x0c00 instead" > Then the moutn operation failed. > I am suspecting it is mtd driver problem (the board use > LH28F016SCT-L95 from sharp). But don't know how to proceed , e.g. how > to verify the content was written into flash in a mounted jffs2 file > system? > Has anybody experienced similar issue? Any suggestion? > Forgive me if this is wrong list to post, and very appreciate if > anybody can direct me to the right place. > > Thanks! > lei > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
SIU_INT_IRQ4 in MPC 8260
Interrupt is signal sending from external devices to CPU notifying
something has happened. So if you want your interrupt handler be
called, first you have to make sure the device does send such signals.
Best Regards,
Leo
> -Original Message-
> From: jagannathanjay at aim.com [mailto:jagannathanjay at aim.com]
> Sent: Friday, July 07, 2006 5:24 PM
> To: Li Yang-r58472
> Subject: Re: SIU_INT_IRQ4 in MPC 8260
>
> No I haven't measured the IRQ4 line
>
> I am newbie into MPC8260 .
>
> Can u guide me as to what way I should proceed to get my interrupt
> handler working?
>
> Regards
> Jagan
>
>
>
> -Original Message-
> From: Li Yang-r58472
> To: jagannathanjay at aim.com; linuxppc-embedded at ozlabs.org
> Sent: Fri, 7 Jul 2006 17:18:54 +0800
> Subject: RE: SIU_INT_IRQ4 in MPC 8260
>
>Are you sure the IRQ4 line is generating irqs? Did you measure the
> line
> using an oscilloscope?
>
> Best Regards,
> Leo
> > -Original Message-
> > From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org
> > [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On
> Behalf
> > Of jagannathanjay at aim.com
> > Sent: Friday, July 07, 2006 5:05 PM
> > To: linuxppc-embedded at ozlabs.org
> > Subject: SIU_INT_IRQ4 in MPC 8260
> >
> > Hi all
> >
> > I am trying to set up a interrupt handler for SIU_INT_IRQ4.
> >
> > The target I am using is MPC 8260 , emmbedded planet Evaluation
board.
> >
> > The OS is Embedded Linux .
> >
>
> -
> >
> > void my_interrupt_handler(int irq, void *dev_id, struct pt_regs
*regs)
> > {
> >
> > printk("***
> ");
> >
> > }
> >
> >
> > if( request_irq(SIU_INT_IRQ4,my_interrupt_handler,0,0,0) < 0)
> > {
> > printk("
> unable to register the interrupt handler
> ");
> > }
> >
> >
>
> -
> >
> >
> > But my_interrupt_handler isn't getting called .
> >
> > Can anyone help me to fix this problem
> >
> > Regards
> > Jagan
> >
> >
> >
> >
> >
> >
>
> > Check Out the new free AIM(R) Mail -- 2 GB of storage and
> > industry-leading spam and email virus protection.
> >
> > ___
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded at ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
> Check Out the new free AIM(R) Mail -- 2 GB of storage and
> industry-leading spam and email virus protection.
SIU_INT_IRQ4 in MPC 8260
Are you sure the IRQ4 line is generating irqs? Did you measure the line
using an oscilloscope?
Best Regards,
Leo
> -Original Message-
> From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On
Behalf
> Of jagannathanjay at aim.com
> Sent: Friday, July 07, 2006 5:05 PM
> To: linuxppc-embedded at ozlabs.org
> Subject: SIU_INT_IRQ4 in MPC 8260
>
> Hi all
>
> I am trying to set up a interrupt handler for SIU_INT_IRQ4.
>
> The target I am using is MPC 8260 , emmbedded planet Evaluation board.
>
> The OS is Embedded Linux .
>
-
>
> void my_interrupt_handler(int irq, void *dev_id, struct pt_regs *regs)
> {
>
> printk("*** \n");
>
> }
>
>
> if( request_irq(SIU_INT_IRQ4,my_interrupt_handler,0,0,0) < 0)
> {
> printk("\n unable to register the interrupt handler \n");
> }
>
>
-
>
>
> But my_interrupt_handler isn't getting called .
>
> Can anyone help me to fix this problem
>
> Regards
> Jagan
>
>
>
>
>
>
> Check Out the new free AIM(R) Mail -- 2 GB of storage and
> industry-leading spam and email virus protection.
>
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Linux 2.6.x : cpm_dpalloc alignment bug perhaps not fully r esolved
> -Original Message- > From: Laurent Lagrange [mailto:lagrange at fr.oleane.com] > Sent: Wednesday, July 05, 2006 4:26 PM > To: Li Yang-r58472; pantelis at embeddedalley.com > Cc: linuxppc-embedded at ozlabs.org > Subject: RE: Linux 2.6.x : cpm_dpalloc alignment bug perhaps not fully > resolved > > Hi Leo, > > Thanks for the reply. > > The patch, I already applied, comes directly from Pantelis > and is the same code as found at > http://patchwork.ozlabs.org/linuxppc/patch?id=3484 Sure, it is the patch I mentioned. Also be noted that the patch only fixes rheap in arch/ppc/. If you are using latest 2.6 source, you are most probably using code under arch/powerpc/. > > What do you mean by the alignment patch ? > > I suspect a problem in the cpm_dpfree function, > not in the cpm_dpalloc function. > > I'll try to give more details. > > Best regards > Laurent > > > > > -Message d'origine- > > De : Li Yang-r58472 [mailto:LeoLi at freescale.com] > > Envoy? : mer. 5 juillet 2006 03:32 > > ? : Laurent Lagrange; pantelis at embeddedalley.com > > Cc : linuxppc-embedded at ozlabs.org > > Objet : RE: Linux 2.6.x : cpm_dpalloc alignment bug perhaps not fully > > resolved > > > > > > Did you apply the alignment patch too? AFAIK, the problem is > > never fixed in > > mainstream trees. > > > > Best Regards, > > Leo > >
Linux 2.6.x : cpm_dpalloc alignment bug perhaps not fully r esolved
Did you apply the alignment patch too? AFAIK, the problem is never fixed in mainstream trees. Best Regards, Leo > -Original Message- > From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org > [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On Behalf > Of Laurent Lagrange > Sent: Tuesday, July 04, 2006 11:37 PM > To: pantelis at embeddedalley.com > Cc: linuxppc-embedded at ozlabs.org > Subject: Linux 2.6.x : cpm_dpalloc alignment bug perhaps not fully resolved > > > Hello Pantelis, > > Few months ago (25 January 2006), I sent a mail about an alignment bug in > cpm_dpalloc. > I applied and verified the provided patch. I was very satisfied with the > result. > > Today I port a driver from Linux 2.4 to Linux 2.6 and I have strange > results. > > The driver allocates rx and tx bds (8 bytes aligned) in the module_init for > 4 SCC ports. > That is always right. Then one port is opened by an application and a user > configuration > is set via an ioctl (set_conf). > > This ioctl first frees the old bds : > cpm_dpfree(chan->rx_bd_offset); > cpm_dpfree(chan->tx_bd_offset); > then allocates the new ones : > chan->rx_bd_offset = cpm_dpalloc(sizeof(cbd_t) * chan->conf.rx_bufnbr, > 8); > chan->tx_bd_offset = cpm_dpalloc(sizeof(cbd_t) * chan->conf.tx_bufnbr, > 8); > with rx_bufnbr == 8 and tx_bufnbr == 2 > > module_init > SCC1 rx_bd_offset=160 > SCC1 tx_bd_offset=1a8 > SCC2 rx_bd_offset=1c0 > SCC2 tx_bd_offset=208 > SCC3 rx_bd_offset=220 > SCC3 tx_bd_offset=260 > SCC4 rx_bd_offset=278 > SCC4 tx_bd_offset=2c0 > set_conf > SCC1 rx_bd_offset=160 > SCC1 tx_bd_offset=1a4 -> ??? > > module_init > SCC1 rx_bd_offset=160 > SCC1 tx_bd_offset=1a8 > SCC2 rx_bd_offset=1c0 > SCC2 tx_bd_offset=208 > SCC3 rx_bd_offset=220 > SCC3 tx_bd_offset=260 > SCC4 rx_bd_offset=278 > SCC4 tx_bd_offset=2c0 > set_conf > SCC2 rx_bd_offset=1c0 > SCC2 tx_bd_offset=202 -> ??? > > module_init > SCC1 rx_bd_offset=160 > SCC1 tx_bd_offset=1a8 > SCC2 rx_bd_offset=1c0 > SCC2 tx_bd_offset=208 > SCC3 rx_bd_offset=220 > SCC3 tx_bd_offset=260 > SCC4 rx_bd_offset=278 > SCC4 tx_bd_offset=2c0 > set_conf > SCC3 rx_bd_offset=220 > SCC3 tx_bd_offset=260 -> ok > > module_init > SCC1 rx_bd_offset=160 > SCC1 tx_bd_offset=1a8 > SCC2 rx_bd_offset=1c0 > SCC2 tx_bd_offset=208 > SCC3 rx_bd_offset=220 > SCC3 tx_bd_offset=260 > SCC4 rx_bd_offset=278 > SCC4 tx_bd_offset=2c0 > set_conf > SCC4 rx_bd_offset=278 > SCC4 tx_bd_offset=2c0 -> ok > > WARNING : if I only uses the SCC1 port without allocating bds for the other > ports, > I can free and reallocate the bds for the SCC1 port as many times I want. > > module_init > SCC1 rx_bd_offset=160 > SCC1 tx_bd_offset=1a8 > set_conf > SCC1 rx_bd_offset=160 > SCC1 tx_bd_offset=1a8 -> ok > > Really, I don't understand how this can arise. > Any idea ? > > Thanks > Laurent > > > > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
eth0: tx queue full
Can you repeat the problem? Kernel 2.4.20 is considerable old even for 2.4 series. Could you try to replace the fec driver from latest 2.4 kernel? Best Regards, Leo > -Original Message- > From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org > [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On Behalf > Of salvatore cusenza > Sent: Tuesday, June 06, 2006 4:14 PM > To: linuxppc-embedded at ozlabs.org > Subject: eth0: tx queue full > > At runtime during the usual life of my board (MPC852 and linux-2.4.20 Denk's > distribution) > I have experienced the following crash: > > > eth0: tx queue full!. > eth0: tx queue full!. > eth0: tx queue full!. > > Oops: kernel access of bad area, sig: 11 > NIP: C000D440 XER: LR: C00BB040 SP: C0C9BC10 REGS: c0c9bb60 TRAP: > 0300 > Tainted: P > MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 > DAR: 1F9D, DSISR: 00E4 > TASK = c0c9a000[145] 'L5421' Last syscall: 4 > last math last altivec > GPR00: C0C9BC10 C0C9A000 C0F56D70 1F99 003C C0F56D6C 0007 > GPR08: 0001 003C C0F56DB0 C0D83C3C 10071D28 C312 > GPR16: C311CB04 C311C8D8 C311C754 C017 C312 C311CB30 0001 C0169DA0 > GPR24: FE00 1F9D C0F58400 003C 0040 C2080100 C0F58200 C0F501B0 > Call backtrace: > C00BAF8C C00BABC8 C0005848 C3119448 C31194C0 C31194F8 C00066F8 > C0011A48 C00BA8FC C00CADD8 C00C3F00 C0016B50 C00AFE4C C00B4B94 > C00B5EF4 C003571C C000457C 0FFD5E4C 0FEDB8DC 0FEDB284 1003B5B8 > 1003D558 1003A88C 0FED34A4 0FED32D0 0FFCFEE4 0FD5F590 > Kernel panic: Aiee, killing interrupt handler! > In interrupt handler - not syncing > <0>Rebooting in 180 seconds.. > > > Could you suggest me something to investigate? >
delay programming
That depends on how accurate you want. Sleep() functions can't be too accurate for Linux schedule characteristic. To get best accuracy, you can use hardware timer. udelay() is a choice which reduces the overall system performance. Best Regards, Leo > -Original Message- > From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org > [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On Behalf > Of tony > Sent: Wednesday, May 24, 2006 5:24 PM > To: linuxppc-embedded at ozlabs.org > Subject: delay programming > > > hi all > I want to delay 1ms in the program, > does usleep(1000) works accurate? > any good idea? > > regards > tony > > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Routing problem
Antonio, Try this: sysctl net.ipv4.ip_forward=1 Regards, Steve Yang 510-749-4535 Alameda AIM: steveyang4535 -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-embedded-bounces+syang=windriver.com at ozlabs.org] On Behalf Of Antonio Di Bacco Sent: Friday, May 12, 2006 1:53 PM To: linuxppc-embedded at ozlabs.org Subject: Routing problem Hi all, I have a board with an MPC880 using the tow FECs as two ethernet interfaces. I tried to enable the ip forwarding with no success. I have issued "echo 1 > /proc/sys/net/ipv4/ip_forward", is it sufficient to make Linux work as > a router? Bye, Antonio. ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
of_platform bus?
I noticed that there is a new bus type of_platform_bus added. Current ppc embedded systems are using platform_device, and are changing to use OF flat device tree structure. Does it mean that current drivers need to be switched from platform_bus to of_platform_bus? -- Regards, Leo
[PATCH] MPC8349 MDS USB HOST support
Hi,
Here is the patch we have in Freescale released BSP. I post it here in case
anyone may need it without the BSP. It's for kernel 2.6.11, and won't have big
problem for newer kernel, I think. The patch is not done by myself, and maybe
submitted later formally after merge with OTG and clean up. Here goes the
patch.
diff -Nur linux/drivers/usb/core/hcd.c linux-8349-2.6/drivers/usb/core/hcd.c
--- linux/drivers/usb/core/hcd.c2005-03-02 15:38:10.0 +0800
+++ linux-8349-2.6/drivers/usb/core/hcd.c 2005-08-15 13:54:13.0
+0800
@@ -1116,13 +1116,20 @@
if (hcd->self.controller->dma_mask) {
if (usb_pipecontrol (urb->pipe)
&& !(urb->transfer_flags & URB_NO_SETUP_DMA_MAP))
+#ifdef CONFIG_FSL_USB20
+ urb->setup_dma = (unsigned long)urb->setup_packet;
+#else
urb->setup_dma = dma_map_single (
hcd->self.controller,
urb->setup_packet,
sizeof (struct usb_ctrlrequest),
DMA_TO_DEVICE);
+#endif
if (urb->transfer_buffer_length != 0
&& !(urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP))
+#ifdef CONFIG_FSL_USB20
+ urb->transfer_dma = (unsigned long)urb->transfer_buffer;
+#else
urb->transfer_dma = dma_map_single (
hcd->self.controller,
urb->transfer_buffer,
@@ -1130,6 +1137,7 @@
usb_pipein (urb->pipe)
? DMA_FROM_DEVICE
: DMA_TO_DEVICE);
+#endif
}
status = hcd->driver->urb_enqueue (hcd, ep, urb, mem_flags);
@@ -1469,6 +1477,8 @@
// It would catch exit/unlink paths for all urbs.
/* lower level hcd code should use *_dma exclusively */
+#ifdef CONFIG_FSL_USB20
+#else
if (hcd->self.controller->dma_mask) {
if (usb_pipecontrol (urb->pipe)
&& !(urb->transfer_flags & URB_NO_SETUP_DMA_MAP))
@@ -1484,7 +1494,7 @@
? DMA_FROM_DEVICE
: DMA_TO_DEVICE);
}
-
+#endif
/* pass ownership to the completion handler */
urb->complete (urb, regs);
atomic_dec (&urb->use_count);
diff -Nur linux/drivers/usb/core/hub.c linux-8349-2.6/drivers/usb/core/hub.c
--- linux/drivers/usb/core/hub.c2005-03-02 15:38:08.0 +0800
+++ linux-8349-2.6/drivers/usb/core/hub.c 2005-08-15 13:56:05.0
+0800
@@ -2155,7 +2155,11 @@
} else if (udev->speed != USB_SPEED_HIGH
&& hdev->speed == USB_SPEED_HIGH) {
udev->tt = &hub->tt;
+#ifdef CONFIG_FSL_USB20
+ udev->ttport = port1+1;
+#else
udev->ttport = port1;
+#endif
}
/* Why interleave GET_DESCRIPTOR and SET_ADDRESS this way?
diff -Nur linux/drivers/usb/host/ehci.h linux-8349-2.6/drivers/usb/host/ehci.h
--- linux/drivers/usb/host/ehci.h 2005-03-02 15:38:25.0 +0800
+++ linux-8349-2.6/drivers/usb/host/ehci.h 2005-08-15 10:25:52.0
+0800
@@ -59,6 +59,9 @@
#defineDEFAULT_I_TDPS 1024/* some HCs can do less
*/
unsignedperiodic_size;
__le32 *periodic; /* hw periodic table */
+#ifdef CONFIG_FSL_USB20
+ u32 orig_periodic;
+#endif
dma_addr_t periodic_dma;
unsignedi_thresh; /* uframes HC might cache */
@@ -70,11 +73,17 @@
unsigned long reset_done [EHCI_MAX_ROOT_PORTS];
/* per-HC memory pools (could be per-bus, but ...) */
+#ifdef CONFIG_FSL_USB20
+ t_MemorySegment *qh_pool; /* qh per active urb */
+ t_MemorySegment *qtd_pool;/* one or more per qh */
+ t_MemorySegment *itd_pool;/* itd per iso urb*/
+ t_MemorySegment *sitd_pool; /* sitd per split iso urb */
+#else
struct dma_pool *qh_pool; /* qh per active urb */
struct dma_pool *qtd_pool; /* one or more per qh */
struct dma_pool *itd_pool; /* itd per iso urb */
struct dma_pool *sitd_pool; /* sitd per split iso urb */
-
+#endif
struct timer_list watchdog;
struct notifier_block reboot_notifier;
unsigned long actions;
@@ -230,9 +239,26 @@
u32 frame_list; /* points to periodic list */
/* ASYNCLISTADDR: offset 0x18 */
u32 async_next; /* address of next async queue head */
-
+#ifdef CONFIG_FSL_USB20
+/* ASYNCTTSTS: offset 0x1c */
+ u32
[PATCH] Fix MPC8349 USB memory mapping
Hi,
The memory mappings for MPC8349 USB MPH and DR modules were reversed.
Signed-off-by: Li Yang
Signed-off-by: Jiang Bo
---
--- arch/ppc/syslib/mpc83xx_devices.c.orig 2005-08-04 16:37:20.0
+0800
+++ arch/ppc/syslib/mpc83xx_devices.c 2005-08-04 16:38:25.0 +0800
@@ -191,8 +191,8 @@ struct platform_device ppc_sys_platform_
.num_resources = 2,
.resource = (struct resource[]) {
{
- .start = 0x22000,
- .end= 0x22fff,
+ .start = 0x23000,
+ .end= 0x23fff,
.flags = IORESOURCE_MEM,
},
{
@@ -208,8 +208,8 @@ struct platform_device ppc_sys_platform_
.num_resources = 2,
.resource = (struct resource[]) {
{
- .start = 0x23000,
- .end= 0x23fff,
+ .start = 0x22000,
+ .end= 0x22fff,
.flags = IORESOURCE_MEM,
},
{
--
Leo Li
Freescale Semiconductor
LeoLi at freescale.com
[PATCH] MPC8349 gadget UDC driver
Hi,
We have worked out a gadget udc driver for MPC8349 tested with 8349-MDS board.
The driver is still a preliminary one, only tested with
file_storage(Linux/Windows), ether(only Linux host), serial(only Linux host).
More tests and code cleaning is underway. What we want here is comment on the
driver, both driver architecture and coding style. Any advice and comment are
appreciated.
Here is the patch generated from 2.6.12.1 usb stack.
diff -uprN usb-old/gadget/ether.c usb/gadget/ether.c
--- usb-old/gadget/ether.c 2005-06-23 03:33:05.0 +0800
+++ usb/gadget/ether.c 2005-08-04 15:51:26.0 +0800
@@ -255,6 +255,10 @@ MODULE_PARM_DESC(host_addr, "Host Ethern
#define DEV_CONFIG_CDC
#endif
+#ifdef CONFIG_USB_GADGET_MPC
+#define DEV_CONFIG_CDC
+#endif
+
/* For CDC-incapable hardware, choose the simple cdc subset.
* Anything that talks bulk (without notable bugs) can do this.
@@ -2303,6 +2310,8 @@ eth_bind (struct usb_gadget *gadget)
device_desc.bcdDevice = __constant_cpu_to_le16 (0x0212);
} else if (gadget_is_at91(gadget)) {
device_desc.bcdDevice = __constant_cpu_to_le16 (0x0213);
+ } else if (gadget_is_8349(gadget)) {
+ device_desc.bcdDevice = __constant_cpu_to_le16 (0x0212);
} else {
/* can't assume CDC works. don't want to default to
* anything less functional on CDC-capable hardware,
diff -uprN usb-old/gadget/file_storage.c usb/gadget/file_storage.c
--- usb-old/gadget/file_storage.c 2005-06-23 03:33:05.0 +0800
+++ usb/gadget/file_storage.c 2005-07-27 14:00:27.0 +0800
@@ -3755,6 +3755,8 @@ static int __init check_parameters(struc
mod_data.release = 0x0312;
else if (gadget_is_at91(fsg->gadget))
mod_data.release = 0x0313;
+ else if (gadget_is_8349(fsg->gadget))
+ mod_data.release = 0x0314;
else {
WARN(fsg, "controller '%s' not recognized\n",
fsg->gadget->name);
diff -uprN usb-old/gadget/gadget_chips.h usb/gadget/gadget_chips.h
--- usb-old/gadget/gadget_chips.h 2005-06-23 03:33:05.0 +0800
+++ usb/gadget/gadget_chips.h 2005-07-27 11:57:13.0 +0800
@@ -86,6 +86,12 @@
#define gadget_is_at91(g) 0
#endif
+#ifdef CONFIG_USB_GADGET_MPC
+#definegadget_is_8349(g) !strcmp("fsl-usb2-dr", (g)->name)
+#else
+#definegadget_is_8349(g) 0
+#endif
+
// CONFIG_USB_GADGET_SX2
// CONFIG_USB_GADGET_AU1X00
// ...
diff -uprN usb-old/gadget/Kconfig usb/gadget/Kconfig
--- usb-old/gadget/Kconfig 2005-06-23 03:33:05.0 +0800
+++ usb/gadget/Kconfig 2005-07-28 17:45:25.0 +0800
@@ -167,6 +167,26 @@ config USB_OMAP
tristate
depends on USB_GADGET_OMAP
default USB_GADGET
+
+config USB_GADGET_MPC
+ boolean "Freescale PowerPC USB Device Controller"
+ depends on MPC834x
+ select USB_GADGET_DUALSPEED
+ help
+ Some of Freescale PowerPC processors have a High Speed
+ Dual-Role(DR) USB controller, which support device mode
+ with 5 programmable endpoints. This driver supports the
+ controller in the MPC8349, and should work with controllers
+ in other Freescale processors too, given minor tweaks.
+
+ Say "y" to link the driver statically, or "m" to build a
+ dynamically linked module called "mpc_udc" and force all
+ gadget drivers to also be dynamically linked.
+
+config USB_MPC
+ tristate
+ depends on USB_GADGET_MPC
+ default USB_GADGET
config USB_OTG
boolean "OTG Support"
diff -uprN usb-old/gadget/Makefile usb/gadget/Makefile
--- usb-old/gadget/Makefile 2005-06-23 03:33:05.0 +0800
+++ usb/gadget/Makefile 2005-07-27 11:44:37.0 +0800
@@ -7,6 +7,7 @@ obj-$(CONFIG_USB_PXA2XX)+= pxa2xx_udc.o
obj-$(CONFIG_USB_GOKU) += goku_udc.o
obj-$(CONFIG_USB_OMAP) += omap_udc.o
obj-$(CONFIG_USB_LH7A40X) += lh7a40x_udc.o
+obj-$(CONFIG_USB_MPC) += mpc_udc.o
#
# USB gadget drivers
diff -uprN usb-old/gadget/mpc_udc.c usb/gadget/mpc_udc.c
--- usb-old/gadget/mpc_udc.c1970-01-01 08:00:00.0 +0800
+++ usb/gadget/mpc_udc.c2005-08-04 14:15:41.0 +0800
@@ -0,0 +1,2530 @@
+/*
+ * driver/usb/gadget/mpc_udc.c
+ *
+ * PowerPC USB Device Controller Driver
+ * Driver for USB module in PPC8349 for 8349MDS platform
+ *
+ * Copyright (c) 2004-2005 Freescale Semiconductor, Inc.
+ *
+ * Author: Li Yang (leoli at freescale.com)
+ * Jiang Bo (Tanya.jiang at freescale.com)
+ * Based on bare board code of Dave Liu and Shlomi Gridish.
+ *
+ *
+ * This program is free software; you can redistribute it a
search in ppclinux mailing list
Google probably will do the similar job
using: site:http://ozlabs.org/pipermail/linuxppc-embedded/ {keyword}
Best Regards,
Leo
> -Original Message-
> From: linuxppc-embedded-bounces at ozlabs.org
> [mailto:linuxppc-embedded-bounces at ozlabs.org] On Behalf Of
>
> Sent: Friday, April 22, 2005 4:34 PM
> To: linuxppc-embedded at ozlabs.org
> Subject: search in ppclinux mailing list
>
>
>
> Hello all!
>
> Does anybody know ppclinux mailing archives with ability to search by
> subject in them. I would appreciate a lot.
>
> Kind regards,
> Kirnasov A.
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Problem running Linux 2.6.11 on MPC8272ADS
Good point. There is also IMMR need to be passed from bootloader to kernel. We can make more use of the u-boot bd_info mechanism. But it binds ppc linux to u-boot boot loader. I don't know if we should make it a porting convention. Best Regards, Leo > -Original Message- > From: Eugene Surovegin [mailto:ebs at ebshome.net] > Sent: Thursday, March 31, 2005 11:27 AM > To: Li Yang-r58472 > Cc: Walter L. Wimer III; Gala Kumar K.-galak; Linux PPC Embedded list > Subject: Re: Problem running Linux 2.6.11 on MPC8272ADS > > On Thu, Mar 31, 2005 at 11:03:00AM +0800, Li Yang-r58472 wrote: > > Well, it seems to be a historic problem. Freescale BSP was > > originally ported from u-boot-1.0.0 and linux-2.4.22. So the BCSR > > was freely chosen as 0xf800. Later, we updated them to > > u-boot-1.1.1 and linux-2.4.26, and make the BCSR consistent to older > > version. However the sourceforge u-boot-1.1.1 support for > > MPC8272ADS > > was committed by Arabella guys, they chose BCSR mapping to > > 0xf450. Kumar's MPC8272 support which is in 2.6.11 source was > > developed using sourceforge u-boot-1.1.1 seemingly. > > > > This might brought up a question that if we need a convention or > > something to define the recommended memory mapping for PowerPC BSPs. > > As there are different groups of people around the world developing > > BSPs for PowerPC platforms, and often the communication between them > > is very limited. > > > > For now using kernel and u-boot released from the same vendor is > > recommended. > > > > There is trivial solution which will work regardless on which version > of U-Boot and kernel you are using. > > DO NOT hardcode such stuff in TWO DIFFERENT places, do this only in > one, in this case it should be firmware (e.g. U-Boot). > > In kernel just read BRx register for that chip select and use this > address for accesses from the kernel. This is how I do on all my > board ports. > > No need to establish any artificial conventions on memory map, etc. > > -- > Eugene
Problem running Linux 2.6.11 on MPC8272ADS
Well, it seems to be a historic problem. Freescale BSP was originally ported
from u-boot-1.0.0 and linux-2.4.22. So the BCSR was freely chosen as
0xf800. Later, we updated them to u-boot-1.1.1 and linux-2.4.26, and make
the BCSR consistent to older version. However the sourceforge u-boot-1.1.1
support for MPC8272ADS was committed by Arabella guys, they chose BCSR mapping
to 0xf450. Kumar's MPC8272 support which is in 2.6.11 source was developed
using sourceforge u-boot-1.1.1 seemingly.
This might brought up a question that if we need a convention or something to
define the recommended memory mapping for PowerPC BSPs. As there are different
groups of people around the world developing BSPs for PowerPC platforms, and
often the communication between them is very limited.
For now using kernel and u-boot released from the same vendor is recommended.
Best Regards,
Leo
> -Original Message-
> From: linuxppc-embedded-bounces at ozlabs.org
> [mailto:linuxppc-embedded-bounces at ozlabs.org] On Behalf Of Walter L. Wimer
> III
> Sent: Thursday, March 31, 2005 12:00 AM
> To: Linux PPC Embedded list
> Subject: Re: Problem running Linux 2.6.11 on MPC8272ADS
>
>
> This matched my experience as well.
>
> Does anyone know why U-Boot 1.1.1 from Freescale uses a different BCSR
> address than U-Boot 1.1.1 from Sourceforge?
>
> Any opinions on which address is the "correct" one to use? Kumar asked
> for a patch to fix this, so what do we think the correct fix is?
>
>
>
> Thanks!
>
> Walt
>
>
>
> On Wed, 2005-03-30 at 10:18 +0200, Mike Rapoport wrote:
> > Walter,
> > Thanks for you help. I've discovered several things and now the things
> > seem to work fine.
> > I've used u-boot-1.1.1 that came with the Freescale BSP and it maps BCSR
> > to 0xf800. The "regular" u-boot-1.1.1 (from sf.net) maps the BCSR to
> > 0xf450 as well as the kernel does (arch/ppc/platforms/pq2ads.h). The
> > difference causes the "hang"-like behaviour when the kernel initializes
> > serial comm and kernel crash afterwards when FCC is initialized.
> >
> > Mike.
> >
> > >Thanks for the data points, Alex.
> > >
> > >I'm using U-Boot 1.1.1 and vanilla kernel.org 2.6.11.4 (actually now
> > >2.6.11.5). My BCSR_ADDR looks the same as what you've listed below, so
> > >I'd guess the difference is with U-Boot... (Another engineer here
> > >installed U-Boot on my board, from, I believe, a binary copy he got from
> > >a Freescale(?) CD... I didn't build U-Boot from source... That's
> > >something I'll need to take a look at...)
> > >
> > >Mike, have you discovered anything further about your problem?
> > >
> > >
> > >
> > >Walt
> > >
> > >
> > >
> > >On Tue, 2005-03-29 at 08:29 +0200, Bastos Fernandez Alexandre wrote:
> > >
> > >
> > >>Hi,
> > >>
> > >>>From "linux/arch/ppc/platforms/pq2ads.h"
> > >>#define BCSR_ADDR ((uint) 0xf450)
> > >>>From "u-boot/include/configs/MPC8260ADS.h"
> > >>#define CFG_BCSR 0xF450
> > >>So ...
> > >>Which version of u-boot and/or linux tree are you using?
> > >>With linuxppc-2.5 and u-boot 1.2 everything works fine for me.
> > >>Maybe Mike's problem is other. Maybe not. :-)
> > >>
> > >>Best regards,
> > >>Alex
> > >>
> > >>
> > >>
> > >>>-Original Message-
> > >>>From:Walter L. Wimer III [SMTP:walt.wimer at timesys.com]
> > >>>Sent:Monday, March 28, 2005 6:07 PM
> > >>>To: Mike Rapoport
> > >>>Cc: linuxppc-embedded at ozlabs.org
> > >>>Subject: Re: Problem running Linux 2.6.11 on MPC8272ADS
> > >>>
> > >>>
> > >>>Hi Mike,
> > >>>
> > >>>I had the same "hang" experience. The file arch/ppc/platforms/pq2ads.c
> > >>>contains the following function:
> > >>>
> > >>> void __init
> > >>> m82xx_board_setup(void)
> > >>> {
> > >>> /* Enable the 2nd UART port */
> > >>> *(volatile uint *)(BCSR_ADDR + 4) &= ~BCSR1_RS232_EN2;
> > >>> }
> > >>>
> > >>>
> > >>>I had to ifdef-out the assignment statement above. It appears that the
> > >>>definition for BCSR_ADDR in the kernel code differs from what U-Boot is
> > >>>using, and that area of memory isn't properly mapped into the kernel
> > >>>address space this early in the boot sequence. As a result, I was
> > >>>getting an Oops() before the console was even enabled (I could see the
> > >>>Oops message by examining the kernel's printk log buffer using a
> > >>>BDI-2000 hardware debugger).
> > >>>
> > >>>
> > >>>
> > >>>Good luck,
> > >>>
> > >>>Walt Wimer
> > >>>TimeSys Corporation
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>On Sun, 2005-03-27 at 11:31 +0200, Mike Rapoport wrote:
> > >>>
> > >>>
> > Hi,
> > I'm trying to bring up the Linux 2.6.11 on MPC8272ADS and it seem to
> > hang up at the very beginning.
> > I use ads8272_defconfig and then enable console on SCC:
> >
> > CONFIG_SERIAL_CPM=y
> > CONFIG_SERIAL_CPM_CONSOLE=y
> > CONFIG_SERIAL_CPM_SCC1=y
> >
> >
> > when I boot the kernel from the u-boot the system hangs up right after
> > t
JTAG debug mechanism
Hi, I know this question is off topic, but I can't find a better place to ask. I will be grateful if anyone can give me a hint or direct me to a reference. As we know PowerPC use JTAG to debug CPU, which implements a Boundary-Scan mechanism. It can manipulate any input/output signals of the CPU by a serial shift/scan process. But my question is how it can read/write the core registers and system memory as implemented by most JTAG emulators. Thanks, Leo ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] PQII FCC Ethernet driver: transmit buffer leak for 2.4
Hi,
When PQII FCC Ethernet runs under heavy tx load(such as using NetPIPE to
measure network performance), you may observe memory leak. Eventually
makes system crash. I digged into this problem and found that 2.6.7
don't have this problem. I pulled the fix to 2.4.x, and generated patch
(for 2.4.26, and can be easily modified for other versions). I suggest
that anyone using linux-2.4.x on PQII apply this patch. The problem is
kind of serious. And this should be merged into kernel.org tree as soon
as possible. Who can pass this to the 2.4 maintainer?
--
Leo Li
Software Engineer
Metrowerks -- Freescale
Patch
==
--- linux-2.4.26/arch/ppc/cpm2_io/fcc_enet.c2004-04-14 21:05:27.0
+0800
+++ linux-2.4.26/arch/ppc/cpm2_io/fcc_enet.c.new2004-06-28
17:02:19.060144928 +0800
@@ -304,6 +304,8 @@
struct sk_buff* tx_skbuff[TX_RING_SIZE];
ushort skb_cur;
ushort skb_dirty;
+
+ atomic_t n_pkts;/* Number of packets in tx ring */
/* CPM dual port RAM relative addresses.
*/
@@ -396,13 +398,15 @@
bdp->cbd_datlen = skb->len;
bdp->cbd_bufaddr = __pa(skb->data);
+ spin_lock_irq(&cep->lock);
+
/* Save skb pointer. */
cep->tx_skbuff[cep->skb_cur] = skb;
cep->stats.tx_bytes += skb->len;
cep->skb_cur = (cep->skb_cur+1) & TX_RING_MOD_MASK;
- spin_lock_irq(&cep->lock);
+ atomic_inc(&cep->n_pkts);
/* Send it on its way. Tell CPM its ready, interrupt when done,
* its the last BD of the frame, and to put the CRC on the end.
@@ -421,9 +425,12 @@
else
bdp++;
- if (bdp->cbd_sc & BD_ENET_TX_READY) {
- netif_stop_queue(dev);
+ /* If the tx_ring is full, stop the queue */
+ if (atomic_read(&cep->n_pkts) >= (TX_RING_SIZE-1)) {
+ if (!netif_queue_stopped(dev)) {
+ netif_stop_queue(dev);
cep->tx_full = 1;
+ }
}
cep->cur_tx = (cbd_t *)bdp;
@@ -541,6 +548,8 @@
/* Free the sk buffer associated with this last transmit. */
dev_kfree_skb_irq(cep->tx_skbuff[cep->skb_dirty]);
cep->skb_dirty = (cep->skb_dirty + 1) & TX_RING_MOD_MASK;
+
+ atomic_dec(&cep->n_pkts);
/* Update pointer to next buffer descriptor to be transmitted.
*/
if (bdp->cbd_sc & BD_ENET_TX_WRAP)
@@ -1782,6 +1791,7 @@
while (cp->cp_cpcr & CPM_CR_FLG);
cep->skb_cur = cep->skb_dirty = 0;
+ atomic_set(&cep->n_pkts, 0);
}
/* Let 'er rip.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
kernel source trees maintenance
Hi I am confused about the maintaining mechanism of kernel.org tree and linuxppc tree. How a patch goes into linuxppc tree? And how patch from linuxppc tree goes into kernel.org tree? Is there any patch that goes directly into kernel.org tree? Who are the decision makers of merging a patch for both trees? Regards, Leo ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
405GP booting question
Hello all, I am using 405GP custom board with 16M memory but I got stuck when I tried to boot mvista linux. Right now my boot loader can start the "simple" boot loader coming with mvista linux and simple boot loader can take over the control and make some initialization such as serial port initialization etc. And I did get the serial output such as "loaded at relocated to zImage at avail ram Now booting the kernel" But the system hangs after this output. I check the code and found the head_4xx.S (I am using 405GP) has been called. But somehow the program stopped at the following part: " /* We now have the lower 16 Meg mapped into TLB entries, and the caches * ready to work. */ turn_on_mmu: li r0,MSR_KERNEL mtspr SRR1,r0 lis r0,start_here at h ori r0,r0,start_here at l mtspr SRR0,r0 SYNC rfi /* enables MMU */ " The program stopped right after SYNC and before rfi. I think rfi is pretty straightforward. It's just used to start run "start_here". I don't quite understand what make the program stop here. Also, why is the comment of instruction rfi "enables MMU"? How is the MMU enabled here? I put a break point in start_here and was sure that start_here hasn't been called. Anyone can give me some clues? Thanks in advance! Frank Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
How to get the tools to make a Minix filesystem
Hi,
I try make a Minix filesytem on my board because it's flash is too
small, only 2 MB, to store a JFFS filesystem. Besides, I learn from my
friend that the tool, namely mkfs.minix, to make a minix filesystem is
related to CPU's archtecture. Now there is no mkfs.minix based on PPC8xx, so
I have to build it by myself.
Would you like to tell me where I can get the soure to binary file --
mkfs.minix and whether I must compile it with ppc_8xx-gcc or not? Thank you
very much!
Best regards,
yang
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
