* Re: MPC860 CP / CPM Misbehaving
From: Wolfgang Denk @ 2005-05-13 23:42 UTC (permalink / raw)
To: Martin, Tim; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <846BA3AF7C8A2048937F1801FD3129C902DB5942@messenger.viasat.com>
In message <846BA3AF7C8A2048937F1801FD3129C902DB5942@messenger.viasat.com> you wrote:
>
> I'm using a custom MPC860 based embedded board and having problems with SCC1
> and SMC1 reception. I have SCC1 setup in ethernet mode, and SMC1 setup in
> UART mode. The general problem manifests itself as getting receive buffer
> descriptors (BDs) from the CPM with the OV bit set (bit 14 of the RxBD
> status/control field, "Overrun. Set when a receiver overrun occurs during
> reception").
...
> This isn't a board hardware problem, the board runs fine with other software
> (different operating system, etc). It's most likely a configuration problem
> on my end.
<speculation>
Are you 100% sure that your SDRAM is working fine when stressed with
burst mode accesses?
See http://www.denx.de/twiki/bin/view/DULG/UBootCrashAfterRelocation
</speculation>
> My thoughts are that it's almost as if the CP (CPM RISC processor) or SDMA
> is being occasionally frozen out while the core PowerPC MPC860 processor is
You may see "funny" problems when your SDRAM is not working right.
And yes, this may happen especially on DMA transfers which will use
burst mode.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
... Hiroshima 45 ... Chernobyl 86 ... Windows 95 ...
^ permalink raw reply
* RE: MPC860 CP / CPM Misbehaving
From: Martin, Tim @ 2005-05-13 23:57 UTC (permalink / raw)
To: 'wd@denx.de'; +Cc: 'linuxppc-embedded@ozlabs.org'
Wolfgang,
The SDRAM timings (UPM registers) are setup by a BDM/JTAG debugger script.
The same script is run when I download the other software, which works.
That being said, I wasn't the one who wrote the UPM portion of the script
and it is one of the few things I haven't verified, so it does sound like a
likely candidate. Thanks for the tip.
Tim
-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]
Sent: Friday, May 13, 2005 4:42 PM
To: Martin, Tim
Cc: 'linuxppc-embedded@ozlabs.org'
Subject: Re: MPC860 CP / CPM Misbehaving
In message <846BA3AF7C8A2048937F1801FD3129C902DB5942@messenger.viasat.com>
you wrote:
>
> I'm using a custom MPC860 based embedded board and having problems with
SCC1
> and SMC1 reception. I have SCC1 setup in ethernet mode, and SMC1 setup in
> UART mode. The general problem manifests itself as getting receive buffer
> descriptors (BDs) from the CPM with the OV bit set (bit 14 of the RxBD
> status/control field, "Overrun. Set when a receiver overrun occurs during
> reception").
...
> This isn't a board hardware problem, the board runs fine with other
software
> (different operating system, etc). It's most likely a configuration
problem
> on my end.
<speculation>
Are you 100% sure that your SDRAM is working fine when stressed with
burst mode accesses?
See http://www.denx.de/twiki/bin/view/DULG/UBootCrashAfterRelocation
</speculation>
> My thoughts are that it's almost as if the CP (CPM RISC processor) or SDMA
> is being occasionally frozen out while the core PowerPC MPC860 processor
is
You may see "funny" problems when your SDRAM is not working right.
And yes, this may happen especially on DMA transfers which will use
burst mode.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
... Hiroshima 45 ... Chernobyl 86 ... Windows 95 ...
^ permalink raw reply
* problems with ppc405 on 2.6.11.8.
From: Michael Richardson @ 2005-05-13 23:37 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
-----BEGIN PGP SIGNED MESSAGE-----
A customer of mine has a PPC405 system, which was based upon the
Embedded Planet design. It runs U-boot 0.4.0, and the system currently
ships with a kernel based upon Timesys 2.4.18.
We are in the process of upgrading to 2.6.11. (linus, not timesys. We
see no value add from timesys)
The major stumbling block was using boot/simple/{head,relocate}.S,
and the inftrees.c. For reasons we do not understand, the system would
fail in huft_build() when (setting up for) decompressing. We traced
through this using our bdi2000, after failing with puts() additions.
My gut instinct was originally that we were blowing our stack, or
overwriting running code while decompressing.
Kyle McMartin tried (I'm not sure why yet) replacing the head.S with
the one from 2.4.18-timesys. It seemed to solve the problem.
I'm posting this in two hopes:
a) that someone else not hit the same problem.
b) that someone else might have a suggestion on
what might be different between head.S+relocate.S and head.S(2.4.18).
- --
] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [
] mcr @ xelerance.com Now doing IPsec training, see |net architect[
] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQoU6E4qHRg3pndX9AQEtswP5AXD3+gxobRZWfZUGU7MqzoJSJFCLcrYc
0yqfGHBL79g3zbkJUONnE30qBBdEyYkH5ghmg6Xqxt4YjgPId3ZOWHBtrRrp+PCA
lBm8WzsgBBBT5SCKNDe6kOy2rSKUjunxv4GXJ0lSQpZMvuceAOmD73no4tWIM/I8
2iETSMLkr9Q=
=2Tlk
-----END PGP SIGNATURE-----
^ permalink raw reply
* floating point in kernel (Re: insmod problem)
From: Roger Larsson @ 2005-05-14 2:55 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <ed43f07150d50a594be2bc2589e902a0@freescale.com>
On Friday 13 May 2005 15.46, Kumar Gala wrote:
> On May 13, 2005, at 8:14 AM, Mark Chambers wrote:
> > > You're using floating arithmetic in the kernel.
> > >
> > > That's not supported.
> > >
> > > Regards
> > >
> > > Pantelis
> >
> > Just for my edification:=A0 Is floating point itself not supported
> > (floating
> > point register
> > corruption or something like that) or just linking to user space
> > libraries?
>
> Use of floating point registers and instructions. Its possible to use
> FP in rare cases inside the kernel buts its extremely discouraged.
>
The kernel is doing lazy saving of FP registers, only saving for user=20
processes that uses them. And especially avoiding to save for every
interrupt!
So if you like to use any FP (registers) in kernel you have to:
=2D disable kernel preemption (YES)
=2D save previous value
=2D do your stuff
=2D restore
=2D enable preemption
I remember a preemption bug caused by using MMX/SSE to copy
memory uncached.
/RogerL
^ permalink raw reply
* Re: problems with ppc405 on 2.6.11.8.
From: Roger Larsson @ 2005-05-14 2:59 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <3086.1116027422@marajade.sandelman.ottawa.on.ca>
On Saturday 14 May 2005 01.37, Michael Richardson wrote:
> We are in the process of upgrading to 2.6.11. (linus, not timesys. We
> see no value add from timesys)
>
> - - -
>
> Kyle McMartin tried (I'm not sure why yet) replacing the head.S with
> the one from 2.4.18-timesys. It seemed to solve the problem.
>
:-)
/RogerL
^ permalink raw reply
* Re: problems with ppc405 on 2.6.11.8.
From: Matt Porter @ 2005-05-14 1:44 UTC (permalink / raw)
To: Michael Richardson; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <3086.1116027422@marajade.sandelman.ottawa.on.ca>
On Fri, May 13, 2005 at 07:37:02PM -0400, Michael Richardson wrote:
> A customer of mine has a PPC405 system, which was based upon the
> Embedded Planet design. It runs U-boot 0.4.0, and the system currently
> ships with a kernel based upon Timesys 2.4.18.
>
> We are in the process of upgrading to 2.6.11. (linus, not timesys. We
> see no value add from timesys)
>
> The major stumbling block was using boot/simple/{head,relocate}.S,
> and the inftrees.c. For reasons we do not understand, the system would
> fail in huft_build() when (setting up for) decompressing. We traced
> through this using our bdi2000, after failing with puts() additions.
If you are booting off of U-boot, why are you trying to boot a
zImage? You should be booting a uImage which doesn't use the
bootwrapper glue code in arch/ppc/boot/. Load the right image
and you will avoid all of this.
-Matt
^ permalink raw reply
* hello everyone, a porting problem!
From: lan-j04 @ 2005-05-14 2:50 UTC (permalink / raw)
To: linuxppc-dev
hello!
i'm now try to port a linux kernel to a mpc5200 board, and i'm a freshman in the
embeded field, can anyone give me some guidance on the steps for this? thanks!
best regards
^ permalink raw reply
* Re: [PATCH 2.6.11.7] ATA Over Ethernet Root, Mark 2
From: Greg KH @ 2005-05-14 7:28 UTC (permalink / raw)
To: McMullan, Jason, ecashin; +Cc: Linux Kernel, PPC_LINUX
In-Reply-To: <1116011879.9050.92.camel@jmcmullan.timesys>
On Fri, May 13, 2005 at 03:12:07PM -0400, McMullan, Jason wrote:
> Second revision of my ATA Over Ethernet root device patch, now with
> white space correction and removed debugging crud.
>
> Any more comment, suggestions?
I'm guessing you are only testing this out on devfs?
Why not fix this up properly, and allow root devices on _any_ type of
block device that is not immediately present at "try to mount time"? The
USB and firewire users of the world will love you...
Also, please CC the aoe maintainer, that's documented in
Documentation/SubmittingPatches :)
> +config ATA_OVER_ETH_ROOT_SHELF
> + int "Shelf ID"
> + depends on ATA_OVER_ETH_ROOT
Ick. Why not use a boot parameter if you really want to use something
so icky (hint, we should rely on the name or major/minor, not something
else like this.)
> --- linux-orig/drivers/block/aoe/aoeblk.c
> +++ linux/drivers/block/aoe/aoeblk.c
> @@ -229,6 +229,7 @@
> gd->capacity = d->ssize;
> snprintf(gd->disk_name, sizeof gd->disk_name, "etherd/e%ld.%ld",
> d->aoemajor, d->aoeminor);
> + strncpy(gd->devfs_name, gd->disk_name, sizeof gd->devfs_name);
You do know devfs is going away in 2 months, right?
> +#ifdef CONFIG_ATA_OVER_ETH_ROOT
> +void aoe_root(unsigned long major, unsigned long minor)
> +{
> + struct net_device *dev;
> +
> + printk(KERN_INFO
> + "aoe: Waiting for root AOE device e%ld.%ld\n", major, minor);
> +
> + /* Give hardware a chance to settle */
> + msleep(500);
> +
> + rtnl_shlock();
> + /* bring loopback device up first */
> + if (dev_change_flags(&loopback_dev, loopback_dev.flags | IFF_UP) < 0)
> + printk(KERN_ERR "AOE Root: Failed to open %s\n", loopback_dev.name);
> +
> + /* Setup all network devices */
> + for (dev = dev_base; dev ; dev = dev->next) {
> + if (dev == &loopback_dev)
> + continue;
> + dev_change_flags(dev, dev->flags | IFF_UP);
> + }
> + rtnl_shunlock();
> +
> + /* Give drivers a chance to settle */
> + ssleep(1);
> +
> + do {
> + aoecmd_cfg(major, minor);
> + msleep(1);
> + } while (!aoedev_bymajor_minor(CONFIG_ATA_OVER_ETH_ROOT_SHELF,CONFIG_ATA_OVER_ETH_ROOT_SLOT));
Looks like you are mixing up shelf and slot values with major and minor
numbers. I'm confused.
> +
> +}
> +#endif
> +
> static void
> aoe_exit(void)
> {
> @@ -63,6 +106,7 @@
> aoechr_exit();
> aoedev_exit();
> aoeblk_exit(); /* free cache after de-allocating bufs */
> + devfs_remove("etherd");
> }
>
> static int __init
> @@ -70,6 +114,8 @@
> {
> int ret;
>
> + devfs_mk_dir("etherd");
> +
Should be in a separate patch, to fix up devfs issues in the driver,
right? This goes for the other devfs calls in this patch. That is if
you don't mind me removing them in 2 months :)
> ret = aoedev_init();
> if (ret)
> return ret;
> @@ -91,6 +137,9 @@
> printk(KERN_INFO
> "aoe: aoe_init: AoE v2.6-%s initialised.\n",
> VERSION);
> +#ifdef CONFIG_ATA_OVER_ETH_ROOT
> + aoe_root(CONFIG_ATA_OVER_ETH_ROOT_SHELF,CONFIG_ATA_OVER_ETH_ROOT_SLOT);
Again with the major/minor confusion. I'm really confused now (you pass
the values in, yet use them as #defines in the function...)
> +#endif
And you could do this without an ifdef, if you really needed to do so.
So, my main question is, why is this patch needed? Is it because aoe
devices aren't quite present and found quick enough during the boot
process? If so, I suggest one of the two solutions:
- do like the rest of the world does for usb and firewire and
other types of slow boot devices and use an initrd/initramfs
that mounts the root partition after it is properly found.
Distros do this all the time, so there are lots of examples to
pull from if you want to do this for yours.
- fix up the patch that is floating around that allows the
kernel to pause and wait and not oops out if the root
partition is not found. That way all users of all kinds of
slow devices can benefit, and driver specific hacks like this
are not needed.
Andrew, care to drop this from your tree until it gets sorted out?
thanks,
greg k-h
^ permalink raw reply
* reg_book.h changes
From: Josh @ 2005-05-14 14:02 UTC (permalink / raw)
To: linuxppc-embedded
Hi -
I was just wondering why the MSR_DE bit was removed from the MSR_KERNEL
define in reg_booke.h(was removed in a 2.6.10 patch).
This "breaks" debugging with the bdi2000 - depending on the reason it
was removed, maybe it might be better to modify it in such a way so that
if CONFIG_BDI_SWITCH is enabled, the MSR_DE bit will also be set?
Thanks,
Josh
^ permalink raw reply
* Re: MPC860 CP / CPM Misbehaving
From: Wolfgang Denk @ 2005-05-14 14:46 UTC (permalink / raw)
To: Martin, Tim; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <846BA3AF7C8A2048937F1801FD3129C902DB5944@messenger.viasat.com>
In message <846BA3AF7C8A2048937F1801FD3129C902DB5944@messenger.viasat.com> you wrote:
>
> The SDRAM timings (UPM registers) are setup by a BDM/JTAG debugger script.
The UPM setup is only half of the story. Please check with your SDRAM
manufacturer's manual for the _complete_ initialization sequence that
is necessary on your chips.
> The same script is run when I download the other software, which works.
This is no indication that the setup is right. We have seen pSOS+ and
VxWorks running fine on some systems, and Linux constantly crashing
on the same hardware because of bad SDRAM initialization. See the FAQ
section in the DULG.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Old programmers never die, they just become managers.
^ permalink raw reply
* 2GB address space limit on 32-bit PowerPC Macintosh
From: John Reiser @ 2005-05-15 22:36 UTC (permalink / raw)
To: linuxppc-dev
The 2GB limit on TASK_SIZE for user address space on 32-bit PowerPC
Apple Macintosh is getting in the way of database, filesystem
maintenance, and scientific applications. In user mode, most
i686 desktops can address 3GB. While 64-bit systems are becoming
available, the vast majority of existing systems are still 32-bit.
What can be done to get a larger address space for existing Macs?
According to arch/ppc/syslib/prom_init.c, the first problem is
that CONFIG_BOOTX_TEXT restricts CONFIG_TASK_SIZE to only 0x80000000.
Is this an initialization-only restriction that just happens
to persist beyond initialization? What would it take to remove
this collision from affecting life after boot? How much of booting
does CONFIG_BOOTX_TEXT affect?
--
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Benjamin Herrenschmidt @ 2005-05-15 23:01 UTC (permalink / raw)
To: John Reiser; +Cc: linuxppc-dev
In-Reply-To: <4287CF06.5000809@BitWagon.com>
On Sun, 2005-05-15 at 15:36 -0700, John Reiser wrote:
> The 2GB limit on TASK_SIZE for user address space on 32-bit PowerPC
> Apple Macintosh is getting in the way of database, filesystem
> maintenance, and scientific applications. In user mode, most
> i686 desktops can address 3GB. While 64-bit systems are becoming
> available, the vast majority of existing systems are still 32-bit.
> What can be done to get a larger address space for existing Macs?
>
> According to arch/ppc/syslib/prom_init.c, the first problem is
> that CONFIG_BOOTX_TEXT restricts CONFIG_TASK_SIZE to only 0x80000000.
> Is this an initialization-only restriction that just happens
> to persist beyond initialization? What would it take to remove
> this collision from affecting life after boot? How much of booting
> does CONFIG_BOOTX_TEXT affect?
The limitation related to CONFIG_BOOTX_TEXT is only a problem on G5,
which isn't supported for 32 bits kernel anymore anyway. "Normal" 32
bits kernel should work fine with TASK_SIZE set to 3Gb. However, there
is another reason why it defaults to 2GB currently, and it is non-32
bits machines.
We "inherited" from some historic junk in the prep and chrp support,
that a lot of embedded platforms blindly copied, where archs use
io_block_mapping() early during boot to hard-wire various IO stuffs in
various places in the address space, including just after 2Gb. It's
totally bogus, but nobody really cared to fix it so far. The 2Gb
TASK_SIZE limit doesn't seem to have ever been an issue for ppc32 users
so far I must say, at least you are the first one to complain ;)
Anyway, nothing prevents you, on a Mac, to force it to 3Gb in
the .config, it will work fine hopefully. If you are using a G5, just
use a 64 bits kernel.
Ben.
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Paul Mackerras @ 2005-05-15 23:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, John Reiser
In-Reply-To: <1116198114.5095.43.camel@gaston>
Benjamin Herrenschmidt writes:
> We "inherited" from some historic junk in the prep and chrp support,
> that a lot of embedded platforms blindly copied, where archs use
> io_block_mapping() early during boot to hard-wire various IO stuffs in
> various places in the address space, including just after 2Gb. It's
> totally bogus, but nobody really cared to fix it so far. The 2Gb
> TASK_SIZE limit doesn't seem to have ever been an issue for ppc32 users
> so far I must say, at least you are the first one to complain ;)
I believe that prep and chrp are also now OK with a 3GB TASK_SIZE
limit, it's just various embedded board ports that will blow up with
3GB. We should change the default to 3GB to encourage the embedded
guys to fix their ports properly (or else to put in the appropriate
Kconfig stuff to force it back to 2GB for their port).
Paul.
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Benjamin Herrenschmidt @ 2005-05-15 23:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, John Reiser
In-Reply-To: <17031.56167.926193.391545@cargo.ozlabs.ibm.com>
On Mon, 2005-05-16 at 09:29 +1000, Paul Mackerras wrote:
> Benjamin Herrenschmidt writes:
>
> > We "inherited" from some historic junk in the prep and chrp support,
> > that a lot of embedded platforms blindly copied, where archs use
> > io_block_mapping() early during boot to hard-wire various IO stuffs in
> > various places in the address space, including just after 2Gb. It's
> > totally bogus, but nobody really cared to fix it so far. The 2Gb
> > TASK_SIZE limit doesn't seem to have ever been an issue for ppc32 users
> > so far I must say, at least you are the first one to complain ;)
>
> I believe that prep and chrp are also now OK with a 3GB TASK_SIZE
> limit, it's just various embedded board ports that will blow up with
> 3GB. We should change the default to 3GB to encourage the embedded
> guys to fix their ports properly (or else to put in the appropriate
> Kconfig stuff to force it back to 2GB for their port).
>
static void __init
prep_map_io(void)
{
io_block_mapping(0x80000000, PREP_ISA_IO_BASE, 0x10000000, _PAGE_IO);
io_block_mapping(0xf0000000, PREP_ISA_MEM_BASE, 0x08000000, _PAGE_IO);
}
We need to fix that too :) Though I suppose we can just switch that to
page tables, I don't really see the point of using a BAT here...
Ben.
^ permalink raw reply
* Re: {PATCH] Fix IBM EMAC driver ioctl bug
From: Jeff Garzik @ 2005-05-16 2:44 UTC (permalink / raw)
To: Geoff Levand; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <425EB470.9040203@am.sony.com>
applied
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Kumar Gala @ 2005-05-16 5:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, John Reiser
In-Reply-To: <1116200069.5095.51.camel@gaston>
On May 15, 2005, at 6:34 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2005-05-16 at 09:29 +1000, Paul Mackerras wrote:
> > Benjamin Herrenschmidt writes:
> >
> > > We "inherited" from some historic junk in the prep and chrp=20
> support,
> > > that a lot of embedded platforms blindly copied, where archs use
> > > io_block_mapping() early during boot to hard-wire various IO=20
> stuffs in
> > > various places in the address space, including just after 2Gb.=20
> It's
> > > totally bogus, but nobody really cared to fix it so far. The 2Gb
> > > TASK_SIZE limit doesn't seem to have ever been an issue for ppc32=20=
> users
> > > so far I must say, at least you are the first one to complain ;)
> >
> > I believe that prep and chrp are also now OK with a 3GB TASK_SIZE
> > limit, it's just various embedded board ports that will blow up =
with
> > 3GB.=A0 We should change the default to 3GB to encourage the =
embedded
> > guys to fix their ports properly (or else to put in the appropriate
> > Kconfig stuff to force it back to 2GB for their port).
> >
>
> static void __init
> prep_map_io(void)
> {
> =A0=A0=A0=A0=A0=A0=A0 io_block_mapping(0x80000000, PREP_ISA_IO_BASE, =
0x10000000,=20
> _PAGE_IO);
> =A0=A0=A0=A0=A0=A0=A0 io_block_mapping(0xf0000000, PREP_ISA_MEM_BASE, =
0x08000000,=20
> _PAGE_IO);
> }
>
> We need to fix that too :) Though I suppose we can just switch that to
> page tables, I don't really see the point of using a BAT here...
Are the embedded board ports broken because of similar=20
io_block_mapping() calls or for some other reason?
I'm in agreement that we should bump TASK_SIZE to 3GB and fix things,=20
how about after 2.6.12 is out?
- kumar=
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Benjamin Herrenschmidt @ 2005-05-16 5:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, John Reiser
In-Reply-To: <5833cd030098e5fc4600f691cab4f36c@freescale.com>
> >
> > We need to fix that too :) Though I suppose we can just switch that to
> > page tables, I don't really see the point of using a BAT here...
>
> Are the embedded board ports broken because of similar
> io_block_mapping() calls or for some other reason?
Mostly because of the above, though some embedded ports may do even more
horrible things for what i know :) The problem with io_block_mapping()
is that 1) it lets you put those BARs or mappings where you want, and 2)
you end up with plenty of code hard-coding this virtual address here or
there that need to be fixed.
> I'm in agreement that we should bump TASK_SIZE to 3GB and fix things,
> how about after 2.6.12 is out?
Agreed. I'll fix PReP/CHRP/pmac & defconfig. Every embedded board
vendor/maintainer will be responsible for fixing his/her boards support.
Ben.
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Kumar Gala @ 2005-05-16 6:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, John Reiser
In-Reply-To: <1116222720.5095.86.camel@gaston>
On May 16, 2005, at 12:52 AM, Benjamin Herrenschmidt wrote:
>
>
> > >
> > > We need to fix that too :) Though I suppose we can just switch=20
> that to
> > >=A0 page tables, I don't really see the point of using a BAT =
here...
> >
> > Are the embedded board ports broken because of similar
> > io_block_mapping() calls or for some other reason?
> =A0
> Mostly because of the above, though some embedded ports may do even=20=
> more
> horrible things for what i know :) The problem with =
io_block_mapping()
> is that 1) it lets you put those BARs or mappings where you want, and=20=
> 2)
> you end up with plenty of code hard-coding this virtual address here=20=
> or
> there that need to be fixed.
I'm interested to see if Paul is aware of any other embedded port=20
issues, since he mentioned the problem there.
Agreed, the other problem that comes up from time to time due to=20
io_block_mapping() that I've see is problem with modules not working=20
because the kernel doesn't think it has any vmalloc() space left.
> > I'm in agreement that we should bump TASK_SIZE to 3GB and fix =
things,
> > how about after 2.6.12 is out?
>
> Agreed. I'll fix PReP/CHRP/pmac & defconfig. Every embedded board
> vendor/maintainer will be responsible for fixing his/her boards=20
> support.
Agreed. We should probably send an email to linuxppc-embedded with a=20
more proper subject line to let people know.
- kumar
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Benjamin Herrenschmidt @ 2005-05-16 6:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, John Reiser
In-Reply-To: <7d5cfed0ee1edade8050d2c4da94b3f1@freescale.com>
> I'm interested to see if Paul is aware of any other embedded port
> issues, since he mentioned the problem there.
Well, we need to dig out from the part of our memory containing things
we don't want to have to deal with anymore things details about the
booke, 4xx, 8xx, ... memory management :)
> Agreed, the other problem that comes up from time to time due to
> io_block_mapping() that I've see is problem with modules not working
> because the kernel doesn't think it has any vmalloc() space left.
How so ? Because we ioremap too much ? Well, that's an ooooold problem.
ppc32 PCI code for example goes at length trying to minimize the amount
of IO space mapped by PCI bridges (since IO space, unlike memory space,
on our current PCI implementation is permanently mapped in). With a
standard setup, we can only ioremap/vmalloc what is left between top of
memory and 1Gb ... Unless you force your lowmem limit to something lower
than the current limit which I think is 768Mb.
> > > I'm in agreement that we should bump TASK_SIZE to 3GB and fix things,
> > > how about after 2.6.12 is out?
> >
> > Agreed. I'll fix PReP/CHRP/pmac & defconfig. Every embedded board
> > vendor/maintainer will be responsible for fixing his/her boards
> > support.
>
> Agreed. We should probably send an email to linuxppc-embedded with a
> more proper subject line to let people know.
>
> - kumar
>
^ permalink raw reply
* Re: [PATCH] BOOKE_WDT Part 1/2 (Re: PPC 44x Watchdog timer)
From: Takeharu KATO @ 2005-05-16 6:57 UTC (permalink / raw)
To: Kumar Gala; +Cc: Glenn Burkhardt, Gala Kumar K.-galak, linuxppc-embedded
In-Reply-To: <b8b42fd26b024d5e26060a508600f631@freescale.com>
Hi Kumar:
I'm sorry that the reply becomes slow.
Kumar Gala wrote:
>>
>
> Any reason you moved this code into DecrementerHandler?
>
>> /* 0x1000 - Programmable Interval Timer (PIT) Exception */
>> START_EXCEPTION(0x1000, Decrementer)
>> - NORMAL_EXCEPTION_PROLOG
>> - lis r0,TSR_PIS@h
>> - mtspr SPRN_TSR,r0 /* Clear the PIT exception */
>> - addi r3,r1,STACK_FRAME_OVERHEAD
>> - EXC_XFER_LITE(0x1000, timer_interrupt)
>> + b DecrementerHandler
>>
Current PIT exception handler is too big.
If it is not moved, compilation is failed with relocation error.
Because current PIT handler overwrites WDT handler's codes, the compiler
can not relocate PIT and WDT handler correctly.
^ permalink raw reply
* [PATCH] i2c: Race fix for i2c-mpc.c
From: Sylvain Munaut @ 2005-05-16 6:24 UTC (permalink / raw)
To: Adrian Cox; +Cc: Sylvain Munaut, Asier Llano Palacios, ML linuxppc-embedded
i2c: Race fix for i2c-mpc.c
The problem was that the clock speed and driver data is
initialized after the i2c adapter was added. This caused
the i2c bus to start working at a wrong speed. (Mostly
noticable on the second bus on mpc5200)
With this patch we've tried to keep the i2c adapter
working perfectly all the time it is included in the system.
Initialize before added, Remove garbage after deleleted.
Submitted-by: Asier Llano Palacios
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
--- linux-2.6/drivers/i2c/busses/i2c-mpc.c 2005-05-16 09:08:02.000000000 +0200
+++ linux-2.6/drivers/i2c/busses/i2c-mpc.c 2005-05-16 09:09:51.000000000 +0200
@@ -333,6 +333,9 @@
} else
i2c->irq = 0;
+ mpc_i2c_setclock(i2c);
+ ocp_set_drvdata(ocp, i2c);
+
i2c->adap = mpc_ops;
i2c_set_adapdata(&i2c->adap, i2c);
@@ -341,8 +344,6 @@
goto fail_add;
}
- mpc_i2c_setclock(i2c);
- ocp_set_drvdata(ocp, i2c);
return result;
fail_add:
@@ -358,8 +359,8 @@
static void __devexit mpc_i2c_remove(struct ocp_device *ocp)
{
struct mpc_i2c *i2c = ocp_get_drvdata(ocp);
- ocp_set_drvdata(ocp, NULL);
i2c_del_adapter(&i2c->adap);
+ ocp_set_drvdata(ocp, NULL);
if (ocp->def->irq != OCP_IRQ_NA)
free_irq(i2c->irq, i2c);
^ permalink raw reply
* Re: [PATCH 2.6.12-rc2] Freescale 8272ADS PCI bridge support to the
From: Vitaly Bordug @ 2005-05-16 7:44 UTC (permalink / raw)
To: Allen Curtis; +Cc: linuxppc-embedded list
In-Reply-To: <541a45636bdf88d9eb3c08febd63d5c5@onz.com>
Allen,
Some details about 8272 PCI below...
Allen Curtis wrote:
> Is the patch necessary? In the March archive it appears that people
> were using the standard 8260 PCI support. What is the issue? Perhaps I
> could provide a patch to m8260_pci.c (as you suggested)
>
The point is that stuff existent in the current tree for the 82xx has
limited functionality. Take a look at
http://ozlabs.org/pipermail/linuxppc-embedded/2005-April/017948.html.
Current source _does not_ contain any IRQ handlers & demux (which the
patch adds), so the device will remain malfunction. Also the patch has
some 8272 & PQ2FADS - specific bits.
>>> Where can I find the kernel tree with this integrated?
>>
>>
>> One doesn't exist.
>>
> Is there an embedded 2.5/2.6 tree somewhere? (I know about the
> bkbits.net/ppc/linux-2.5 tree
>
There is no special `embedded` tree - use one from kernel.org or git
repo if you need development version (http://www.kernel.org/git/).
--
Sincerely,
Vitaly
^ permalink raw reply
* RE : eth0: PHY id 0x00221619 is not supported! HELP
From: Garcia Jérémie @ 2005-05-16 8:42 UTC (permalink / raw)
To: Nghiem, Tien, linuxppc-dev
FIrst of all tks a lot for your answers everybody.
Tien, in my case, I do not have and so do not use the function =
"mii_phy_probe(struct mii_phy *phy, int mii_id)" in the "ibm_ocp_phy.c" =
file.
Here is the list of call used in my process:
--> ocp_enet_probe(int curr_emac) =
[ibm_ocp_enet.c]
--> find_phy(struct net_device *dev) =
[ibm_ocp_phy.c]
--> check_phy(struct net_device *dev, int phnum) =
[ibm_ocp_phy.c]
And here are the function detailed:
-------------------------------------------------------------------------=
-------------------
static int
ocp_enet_probe(int curr_emac)
{
int ret =3D 1;
int i;
bd_t *bd;
struct net_device *dev;
struct ocp_enet_private *ep;
struct ocp_dev *emac_driver;
dev_list_t *new_dev_list; =09
dev =3D init_etherdev(NULL, sizeof (struct ocp_enet_private)); =20
if (dev =3D=3D NULL) {
printk(KERN_ERR
"ibm_ocp_enet: Could not allocate ethernet device.\n");
return -1;
} =20
/* create devlist instance */
new_dev_list =3D (dev_list_t *)kmalloc(sizeof(struct =
dev_list),GFP_ATOMIC);
if(new_dev_list =3D=3D NULL)
{
printk(KERN_ERR "IBM_OCP_ENET: dev_list alloc failed \n");
return -1;
}
new_dev_list->next =3D NULL;
new_dev_list->dev =3D dev;
if (emac_dev_list =3D=3D NULL)
{
emac_dev_list =3D new_dev_list;
cur_dev_list =3D new_dev_list;
}
else
{
cur_dev_list->next =3D new_dev_list;
cur_dev_list =3D new_dev_list;
}
=09
ep =3D dev->priv;
ep->emac_num =3D curr_emac;
ep->mal =3D DCRN_MAL_BASE;
ep->sequence_done =3D 0;
emac_driver =3D &ep->ocpdev;
emac_driver->type =3D EMAC;
ocp_register(emac_driver);
ocp_set_drvdata(emac_driver, dev);
ep->emacp =3D (volatile emac_t *) __ioremap
(emac_driver->paddr, sizeof (emac_t), _PAGE_NO_CACHE);
init_zmii(ZMII_AUTO, dev);
/******************************/
/* Beginning of my pb */
/******************************/
find_phy(dev);
if (!ep->phy) {
ocp_remove_one(emac_driver);
return -1;
}
ep->link =3D 1;
ep->txchan =3D 0x80000000 >> curr_emac*2 ;
ep->rxchan =3D 0x80000000 >> curr_emac;
dev->irq =3D ocp_get_irq(EMAC,curr_emac);
/* read the MAC Address */
bd =3D (bd_t *) __res; =20
for (i =3D 0; i < 6; i++)
dev->dev_addr[i] =3D bd->BD_EMAC_ADDR(curr_emac, i); /* Marco to =
disques array */ =20
/* Fill in the driver function table */
dev->open =3D &ppc405_enet_open;
dev->hard_start_xmit =3D &ppc405_enet_start_xmit;
dev->stop =3D &ppc405_enet_close;
dev->get_stats =3D &ppc405_enet_stats;
dev->set_multicast_list =3D &ppc405_enet_set_multicast_list;
dev->do_ioctl =3D &ocp_enet_ioctl;
emac_dev[curr_emac] =3D dev;
printk(KERN_NOTICE "Reset ethernet interfaces\n");
/* Reset the EMAC */
out_be32(&ep->emacp->em0mr0, EMAC_M0_SRST);
udelay(10);
if (in_be32(&ep->emacp->em0mr0) & EMAC_M0_SRST) {
printk(KERN_NOTICE "%s: Cannot open interface without Link\n",
dev->name);
return -1;
}
config_mal(ep);
return (ret);
}
-------------------------------------------------------------------------=
-------------------
static int check_phy(struct net_device *dev, int phnum)
{
struct ocp_enet_private *fep =3D dev->priv;
uint phy_reg;
int i;
fep->phy_addr =3D phnum;
if (ocp_enet_mdio_read(dev, mk_mii_read(MII_REG_PHYIR1), &phy_reg))
return 0;
ppc405_phy_dump(dev);
/* Got 2nd part of ID, now get remainder. */
fep->phy_id =3D (phy_reg & 0xffff) << 16;
if (ocp_enet_mdio_read(dev, mk_mii_read(MII_REG_PHYIR2), &phy_reg)) {
if (phnum =3D=3D MIN_PHY_ADDR)
printk(KERN_ERR "%s: Got bad Phy Read, missing MDIO pullup?\n",
dev->name);
return 0;
}
fep->phy_id |=3D (phy_reg & 0xffff);
for (i =3D 0; phy_info[i]; i++)
if (phy_info[i]->id =3D=3D (fep->phy_id >> phy_info[i]->shift))
break;
if (!phy_info[i]) {
printk(KERN_ERR "%s: PHY id 0x%08x is not supported!\n",
dev->name, fep->phy_id);
return 0;
}
fep->phy =3D phy_info[i];
printk("%s: Phy @ 0x%x, type %s (0x%08x)\n",
dev->name, fep->phy_addr, fep->phy->name, fep->phy_id);
return 1;
}
-------------------------------------------------------------------------=
-------------------
void find_phy(struct net_device *dev)
{
int i;
for (i =3D next_phy_available; i <=3D MAX_PHY_ADDR; i++)
if (check_phy(dev, i)){
next_phy_available =3D i + 1;
return;
}
printk("%s: No PHY device found.\n", dev->name);
}
So, how can I apply your method Thien? Could you give me a clue =
(again...lol)?
Tks a lot cause this part of linux code is very very unknown to me...
J=E9r=E9mie
-------- Message d'origine--------
De: Nghiem, Tien [mailto:TNghiem@oerlikon.ca]
Date: ven. 13/05/2005 20:25
=C0: Garcia J=E9r=E9mie; linuxppc-dev@ozlabs.org
Objet : RE: eth0: PHY id 0x00221619 is not supported! HELP
=20
Hi Garcia,
In the ibm_ocp_phy.c file, the function mii_phy_probe(struct mii_phy =
*phy, int mii_id) has not found the ID of your ethernet transceiver, so =
you can bypass it by doing the following:
int rc;
u32 id;
struct mii_phy_def* def;
int i;
=20
phy->autoneg =3D 0;
phy->advertising =3D 0;
phy->mii_id =3D mii_id;
phy->speed =3D 0;
phy->duplex =3D 0;
phy->pause =3D 0;
=20
/* Take PHY out of isloate mode and reset it. */
rc =3D reset_one_mii_phy(phy, mii_id);
//if (rc)
// return -ENODEV;
=20
/* Read ID and find matching entry */ =20
//id =3D (phy_read(phy, MII_PHYSID1) << 16 | phy_read(phy, =
MII_PHYSID2))
& 0xfffffff0;
//for (i=3D0; (def =3D mii_phy_table[i]) !=3D NULL; i++)
// if ((id & def->phy_id_mask) =3D=3D def->phy_id)
// break;
=20
def =3D mii_phy_table[0];
=20
/* Should never be NULL (we have a generic entry), but... */
if (def =3D=3D NULL)
return -ENODEV;
=20
phy->def =3D def;
/* Setup default advertising */
phy->advertising =3D def->features;
=20
return 0;
I don't know the PPC 405EP, but I did it for my custom board (MPC8260). =
It should work.
Tien
-----Original Message-----
From: linuxppc-dev-bounces@ozlabs.org
[mailto:linuxppc-dev-bounces@ozlabs.org]On Behalf Of Garcia J=E9r=E9mie
Sent: Friday, May 13, 2005 11:15 AM
To: linuxppc-dev@ozlabs.org
Subject: eth0: PHY id 0x00221619 is not supported! HELP
Hi everybody,
We are developping a custom board which uses a ppc405EP and on which one =
we'd like to load a linux hardhat.
During the boot process, we're getting error messages about the ethernet =
PHY. That is really annoying cause we plan to moubnt the file system via =
nfs. So no ethernet no NFS...
Could someone give us a tip and tell us if the messages displayed before =
seem to be normal cause we had to modify some part of the kernel in =
order to get Linux booting.
What those ethernet messages mean? Everythin seems to happen in the =
"ibm_ocp_enet.c" eand "ibm_ocp_phy.c" filesPlease help....
So here we go ---->>>>>>>>>
Linux/PPC load: console=3DttyS0,19200 root=3D/dev/nfs rw ip=3Don
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.4.20_mvl31-405ep_eval =
(root@sop-dhcp-10-16-5-126.amcc.com) (version gcc 3.3.1 (MontaVista =
3.3.1-3.0.10.0300532 2003-12-24)) #26 ven mai 13 5
AMCC Q80G Board
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=3DttyS0,19200 root=3D/dev/nfs rw ip=3Don
hr_time_init: arch_to_nsec =3D 10485759, nsec_to_arch =3D 858993476
Calibrating delay loop... 199.47 BogoMIPS
Memory: 14416k available (1280k kernel code, 424k data, 64k init, 0k =
highmem)
Dentry cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
OCP uart ver 1.6.2 init complete
LSP Revision 1
ikconfig 0.5 with /proc/ikconfig
Starting kswapd
Disabling the Out Of Memory Killer
JFFS2 version 2.1. (C) 2001, 2002 Red Hat, Inc., designed by Axis =
Communications AB.
i2c-core.o: i2c core module version 2.6.2 (20011118)
i2c-dev.o: i2c /dev entries driver module version 2.6.2 (20011118)
i2c-proc.o version 2.6.2 (20011118)
pty: 256 Unix98 ptys configured
eeprom.o version 2.6.2 (20011118)
Serial driver version 5.05c (2001-07-08) with no serial options enabled
ttyS00 at 0xef600300 (irq =3D 0) is a 16550A
ttyS01 at 0xef600400 (irq =3D 1) is a 16550A
IBM gpio driver version 07.25.02
GPIO #0 at 0xc207d700
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
eth0: PHY id 0x00221619 is not supported!
eth0: PHY id 0x00221619 is not supported!
eth0: No PHY device found.
removing net dev
eth0: PHY id 0x00221619 is not supported!
eth0: PHY id 0x00221619 is not supported!
eth0: No PHY device found.
removing net dev
IBM IIC driver v2.0
ibm-iic: using compatibility value for OPB freq, fix your board specific =
setup
ibm-iic0: using standard (100 kHz) mode
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMPIP: routing cache hash table of 512 =
buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 2048)
IP-Config: No network devices available.
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
kmod: failed to exec /sbin/modprobe -s -k block-major-2, errno =3D 2
VFS: Cannot open root device "nfs" or 02:00
Please append a correct "root=3D" boot option
Kernel panic: VFS: Unable to mount root fs on 02:00
<0>Rebooting in 180 seconds..
Tks a lot for your precious help
Dj=E9
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* 2.6.x insmod problem on 82xx platform
From: Sam Song @ 2005-05-16 12:59 UTC (permalink / raw)
To: 'linuxppc-embedded maillist'
Hi all,
I met a strange problem when trying to insmod a
extern module in 2.6.12-rc2 on a MPC8241 board.
Even lsmod didn't work. Following is the error
message working on ELDK3.0.
bash-2.05b# insmod mymodule.o
insmod: QM_MODULES: Function not implemented
bash-2.05b# lsmod
Module Size Used by
lsmod: QM_MODULES: Function not implemented
I greped QM_MODULES in the kernel source code
but found nothing. What's happening to LKM in
2.6.x?
Don't tell me that LKM hasn't been supported
yet in 2.6.x:-)
Thanks in advance,
Sam
_________________________________________________________
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
http://music.yisou.com/
美女明星应有尽有，搜遍美图、艳图和酷图
http://image.yisou.com
1G就是1000兆，雅虎电邮自助扩容！
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/
^ permalink raw reply
* Re: 2.6.x insmod problem on 82xx platform
From: Mike Rapoport @ 2005-05-16 14:13 UTC (permalink / raw)
To: Sam Song; +Cc: linuxppc-embedded
In-Reply-To: <20050516125932.71078.qmail@web15802.mail.cnb.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]
Sam Song wrote:
>Hi all,
>
>I met a strange problem when trying to insmod a
>extern module in 2.6.12-rc2 on a MPC8241 board.
>Even lsmod didn't work. Following is the error
>message working on ELDK3.0.
>
>bash-2.05b# insmod mymodule.o
>insmod: QM_MODULES: Function not implemented
>
>bash-2.05b# lsmod
>Module Size Used by
>lsmod: QM_MODULES: Function not implemented
>
>
>
I think you use modutils for 2.4 kernel. In order to work with LKM in
2.6 you need module-init-tools package.
Take a look at http://www.kernel.org/pub/linux/kernel/people/rusty/modules/
>I greped QM_MODULES in the kernel source code
>but found nothing. What's happening to LKM in
>2.6.x?
>
>Don't tell me that LKM hasn't been supported
>yet in 2.6.x:-)
>
>Thanks in advance,
>
>Sam
>
>_________________________________________________________
>Do You Yahoo!?
>150万曲MP3疯狂搜，带您闯入音乐殿堂
>http://music.yisou.com/
>美女明星应有尽有，搜遍美图、艳图和酷图
>http://image.yisou.com
>1G就是1000兆，雅虎电邮自助扩容！
>http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
>
>
--
Sincerely yours,
Mike
[-- Attachment #2: Type: text/html, Size: 2302 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox