* 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
* Re: [PATCH 2.6.11.7] ATA Over Ethernet Root, Mark 2
From: McMullan, Jason @ 2005-05-16 13:20 UTC (permalink / raw)
To: Greg KH, akpm; +Cc: Linux Kernel, ecashin, PPC_LINUX
In-Reply-To: <20050514072826.GB20021@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]
[First off: Andrew, I'm sorry I didn't make it more clear that the AOE
root patch was just for review, not for submission. Please remove it
from -mm]
On Sat, 2005-05-14 at 00:28 -0700, Greg KH wrote:
> I'm guessing you are only testing this out on devfs?
Yes. udev takes 5 minutes to complete on my 8mb, 100Mhz board.
> 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...
Sure. No problem. Where is this patch you speak of?
> Also, please CC the aoe maintainer, that's documented in
> Documentation/SubmittingPatches :)
I did to support@coraid.com, in a separate message.
> > +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.)
Because kernel major/minor change dynamically based upon the number of
AOE blades on your LAN. As setting them in __setup() - sure, no problem,
this patch was just a 15 minute hack job.
> You do know devfs is going away in 2 months, right?
Yes, much to my disappointment. udevd is so frick'n bloaty.
> Looks like you are mixing up shelf and slot values with major and minor
> numbers. I'm confused.
As was I. The original driver uses the words 'major' and 'minor' to
mean *both* kernel major/minor numbers and AOE blade slot/shelf IDs,
depending on context. Took me a bit to wrap my brain around it too.
> 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 :)
Yeah, I know, I was just being lazy and using the uber-fast devfs.
> 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?
Yep.
> 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.
I only have 8Mb of RAM. No room for initrd.
> - 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.
Again, this happy patch you speak of... Where can I find this wonder?
--
Jason McMullan <jason.mcmullan@timesys.com>
TimeSys Corporation
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Ethernet on A&M Rattler 8248
From: tony.ford @ 2005-05-16 13:00 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Sorry, you guys must have heard this a million times but...
I'm having problems pinging out once Linux has booted. I use the=20
same interface to tftp the kernel image in u-boot. The interface appears
on FCC1 and both the kernel messages and ifconfig confirm that the
IP params are set. When I try to ping out I see TXpackets and carrier
increment using ifconfig.
I've tried changing the config until I'm blue in the face but I'm
obviously missing something.
Any pointers would be appreciated. I've attached the console log and
config file for your information. (I've masked part of the IP but
believe me it's the same number everywhere)
Console Log:
-----------
U-Boot 1.1.3 (May 5 2005 - 13:24:54)
MPC8248 Reset Status: External Soft, External Hard
MPC8248 Clock Configuration
- Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq 25-75 , Core Freq =
100-300
- dfbrg 1, corecnf 0x0a, busdf 3, cpmdf 1, plldf 0, pllmf 3
- vco_out 400000000, scc_clk 100000000, brg_clk 25000000
- cpu_clk 400000000, cpm_clk 200000000, bus_clk 100000000
- pci_clk 33333333
CPU: MPC8248 (HiP7 Rev 13, Mask 0.0 0K50M) at 400 MHz
Board: Rattler Rev. D
DRAM: 32 MB
FLASH: 16 MB
In: serial
Out: serial
Err: serial
Net: FCC1 ETHERNET
Hit any key to stop autoboot: 0=20
=3D> tftpboot fe050000 uImage
Using FCC1 ETHERNET device
TFTP from server 194.xxx.174.19; our IP address is 194.xxx.174.30
Filename 'uImage'.
Load address: 0xfe050000
Loading: =
#################################################################
=
#################################################################
########
done
Bytes transferred =3D 702468 (ab804 hex)
=3D> mboot fe050000 fe100000
Unknown command 'mboot' - try 'help'
=3D> bootm fe050000 fe100000
## Booting image at fe050000 ...
Image Name: Linux-2.4.25
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 702404 Bytes =3D 685.9 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at fe100000 ...
Image Name: Simple Embedded Linux Framework
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1400198 Bytes =3D 1.3 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 01a62000, end 01bb7d86 ... OK
Memory BAT mapping: BAT2=3D32Mb, BAT3=3D0Mb, residual: 0Mb
Linux version 2.4.25 (tony@foobar) (gcc version 3.3.3 (DENX ELDK 3.1.1 =
3.3.3-9)) #1 Fri May 1
3 14:19:00 BST 2005
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=3D/dev/ram rw =
ip=3D194.xxx.174.30:194.xxx.174.19:194.xxx.174.19:255.25
5.255.128:powerpc::
Warning: real time clock seems stuck!
Calibrating delay loop... 266.24 BogoMIPS
Memory: 29340k available (1204k kernel code, 408k data, 52k init, 0k =
highmem)
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode cache hash table entries: 2048 (order: 2, 16384 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: 8192 (order: 3, 32768 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
Starting kswapd
Journalled Block Device driver loaded
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
CPM UART driver version 0.01
ttyS0 on SMC1 at 0x0000, BRG7
ttyS1 on SMC2 at 0x0040, BRG8
ttyS2 on SCC1 at 0x8000, BRG1
ttyS3 on SCC2 at 0x8100, BRG2
pty: 256 Unix98 ptys configured
eth0: FCC1 ENET Version 0.4, 00:08:E5:11:22:33
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 4096)
IP-Config: Complete:
device=3Deth0, addr=3D194.xxx.174.30, mask=3D255.255.255.128, =
gw=3D194.xxx.174.19,
host=3Dpowerpc, domain=3D, nis-domain=3D(none),
bootserver=3D194.xxx.174.19, rootserver=3D194.xxx.174.19, =
rootpath=3D
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 1367k freed
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 52k init
### Application running ...
BusyBox v0.60.1 (2002.10.24-02:29+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.
# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:08:E5:11:22:33 =20
inet addr:194.xxx.174.30 Bcast:194.xxx.174.127 =
Mask:255.255.255.128
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000=20
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Base address:0x8400=20
lo Link encap:Local Loopback =20
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0=20
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
/* ping myself - works */
# ping 194.xxx.174.30
194.xxx.174.30 is alive!
/* ping tftp server - don't works */
# ping 194.xxx.174.19
No response from 194.xxx.174.19
#=20
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use =
Iface
194.xxx.174.0 * 255.255.255.128 U 0 0 0 =
eth0
Config file: (I've chopped sections where no config vars have been
set to try to limit the size of this mail)
------------
#
# Automatically generated make config: don't edit
#
# CONFIG_UID16 is not set
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
# CONFIG_HAVE_DEC_LOCK is not set
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=3Dy
# CONFIG_ADVANCED_OPTIONS is not set
#
# Loadable module support
#
CONFIG_MODULES=3Dy
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=3Dy
#
# Platform support
#
CONFIG_PPC=3Dy
CONFIG_PPC32=3Dy
CONFIG_6xx=3Dy
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_E500 is not set
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
# CONFIG_8xx is not set
CONFIG_8260=3Dy
CONFIG_PPC_STD_MMU=3Dy
CONFIG_SERIAL_CONSOLE=3Dy
CONFIG_SERIAL_TEXT_DEBUG=3Dy
# CONFIG_ATC is not set
# CONFIG_ADS8260 is not set
# CONFIG_EST8260 is not set
# CONFIG_PM826 is not set
# CONFIG_SBS8260 is not set
# CONFIG_RPX6 is not set
# CONFIG_TQM8260=3Dy
CONFIG_QS10G=3Dy
# CONFIG_CPU86 is not set
# CONFIG_MEG32 is not set
# CONFIG_WILLOW is not set
# CONFIG_SMP is not set
CONFIG_EMBEDDEDBOOT=3Dy
#
# General setup
#
# CONFIG_BIGPHYS_AREA is not set
# CONFIG_HIGHMEM is not set
CONFIG_HIGHMEM_START=3D0xfe000000
CONFIG_LOWMEM_SIZE=3D0x30000000
CONFIG_KERNEL_START=3D0xc0000000
CONFIG_TASK_SIZE=3D0x80000000
# CONFIG_ISA is not set
# CONFIG_EISA is not set
# CONFIG_SBUS is not set
# CONFIG_MCA is not set
# CONFIG_PCI is not set
# CONFIG_8260_PCI9 is not set
# CONFIG_PC_KEYBOARD is not set
CONFIG_NET=3Dy
CONFIG_SYSCTL=3Dy
CONFIG_SYSVIPC=3Dy
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_KCORE_ELF=3Dy
CONFIG_BINFMT_ELF=3Dy
CONFIG_KERNEL_ELF=3Dy
# CONFIG_BINFMT_MISC is not set
# CONFIG_OOM_KILLER is not set
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=3Dy
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_PARTITIONS=3Dy
# CONFIG_MTD_CONCAT is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=3Dy
#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=3Dy
CONFIG_MTD_BLOCK=3Dy
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=3Dy
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=3Dy
CONFIG_MTD_CFI_ADV_OPTIONS=3Dy
CONFIG_MTD_CFI_NOSWAP=3Dy
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
CONFIG_MTD_CFI_GEOMETRY=3Dy
# CONFIG_MTD_MAP_BANK_WIDTH_1 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_2 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_4 is not set
CONFIG_MTD_MAP_BANK_WIDTH_8=3Dy
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
# CONFIG_MTD_CFI_I1 is not set
# CONFIG_MTD_CFI_I2 is not set
CONFIG_MTD_CFI_I4=3Dy
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_OTP is not set
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=3Dy
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=3Dy
# 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,m=20
# CONFIG_MTD_AMDSTD is not set
# CONFIG_MTD_SHARP is not set
# CONFIG_MTD_JEDEC is not set
#
#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_CISS_SCSI_TAPE is not set
# CONFIG_CISS_MONITOR_THREAD is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=3Dy
CONFIG_BLK_DEV_RAM_SIZE=3D4096
CONFIG_BLK_DEV_INITRD=3Dy
# CONFIG_BLK_STATS is not set
#
# Networking options
#
CONFIG_PACKET=3Dy
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV is not set
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=3Dy
CONFIG_INET=3Dy
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=3Dy
# CONFIG_IP_PNP_DHCP is not set
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
#
# Network device support
#
CONFIG_NETDEVICES=3Dy
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=3Dy
# CONFIG_MACE is not set
# CONFIG_BMAC is not set
# CONFIG_GMAC is not set
# CONFIG_SUNLANCE is not set
# CONFIG_SUNBMAC is not set
# CONFIG_SUNQE is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_NET_ISA is not set
# CONFIG_NET_PCI is not set
# CONFIG_NET_POCKET is not set
#
# Character devices
#
# CONFIG_VT is not set
# CONFIG_SERIAL is not set
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_UNIX98_PTYS=3Dy
#
# File systems
#
# CONFIG_QUOTA is not set
# CONFIG_QFMT_V2 is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_ADFS_FS is not set
# CONFIG_ADFS_FS_RW is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BEFS_DEBUG is not set
# CONFIG_BFS_FS is not set
CONFIG_EXT3_FS=3Dy
CONFIG_JBD=3Dy
# CONFIG_JBD_DEBUG is not set
# CONFIG_FAT_FS is not set
# CONFIG_MSDOS_FS is not set
# CONFIG_UMSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
CONFIG_JFFS2_FS=3Dy
CONFIG_JFFS2_FS_DEBUG=3D0
CONFIG_JFFS2_FS_WRITEBUFFER=3Dy
CONFIG_JFFS2_ZLIB=3Dy
CONFIG_JFFS2_RTIME=3Dy
# CONFIG_JFFS2_RUBIN is not set
# CONFIG_JFFS2_LZO is not set
# CONFIG_JFFS2_LZARI is not set
# CONFIG_JFFS2_CMODE_NONE is not set
CONFIG_JFFS2_CMODE_PRIORITY=3Dy
# CONFIG_JFFS2_CMODE_SIZE is not set
CONFIG_JFFS2_PROC=3Dy
CONFIG_CRAMFS=3Dy
CONFIG_TMPFS=3Dy
CONFIG_RAMFS=3Dy
# CONFIG_ISO9660_FS is not set
# CONFIG_JOLIET is not set
# CONFIG_ZISOFS is not set
# CONFIG_JFS_FS is not set
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_NTFS_RW is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=3Dy
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVFS_MOUNT is not set
# CONFIG_DEVFS_DEBUG is not set
CONFIG_DEVPTS_FS=3Dy
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX4FS_RW is not set
# CONFIG_ROMFS_FS is not set
CONFIG_EXT2_FS=3Dy
# CONFIG_SYSV_FS is not set
# CONFIG_UDF_FS is not set
# CONFIG_UDF_RW is not set
# CONFIG_UFS_FS is not set
# CONFIG_UFS_FS_WRITE is not set
# CONFIG_XFS_FS is not set
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_RT is not set
# CONFIG_XFS_TRACE is not set
# CONFIG_XFS_DEBUG is not set
#
# Network File Systems
#
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
CONFIG_NFS_FS=3Dy
CONFIG_NFS_V3=3Dy
# CONFIG_NFS_DIRECTIO is not set
CONFIG_ROOT_NFS=3Dy
# CONFIG_NFSD is not set
# CONFIG_NFSD_V3 is not set
# CONFIG_NFSD_TCP is not set
CONFIG_SUNRPC=3Dy
CONFIG_LOCKD=3Dy
CONFIG_LOCKD_V4=3Dy
# CONFIG_SMB_FS is not set
# CONFIG_NCP_FS is not set
# CONFIG_NCPFS_PACKET_SIGNING is not set
# CONFIG_NCPFS_IOCTL_LOCKING is not set
# CONFIG_NCPFS_STRONG is not set
# CONFIG_NCPFS_NFS_NS is not set
# CONFIG_NCPFS_OS2_NS is not set
# CONFIG_NCPFS_SMALLDOS is not set
# CONFIG_NCPFS_NLS is not set
# CONFIG_NCPFS_EXTRAS is not set
# CONFIG_ZISOFS_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=3Dy
# CONFIG_SMB_NLS is not set
# CONFIG_NLS is not set
#
# MPC8260 CPM Options
#
# CONFIG_SCC_CONSOLE is not set
# CONFIG_SCC_ENET is not set
CONFIG_FEC_ENET=3Dy
CONFIG_FCC1_ENET=3Dy
# CONFIG_FCC2_ENET is not set
# CONFIG_FCC3_ENET is not set
# CONFIG_USE_MDIO is not set
# CONFIG_FCC_LXT970 is not set
# CONFIG_FCC_LXT971 is not set
# CONFIG_FCC_QS6612 is not set
# CONFIG_FCC_AMD79C873 is not set
# CONFIG_FCC_DM9131 is not set
# CONFIG_CPM_SPI is not set
#
# SCC UART h/w handshaking options
#
#
# SCC1
#
CONFIG_PORT_CTS1_NONE=3Dy
# CONFIG_CTS1_15 is not set
# CONFIG_CTS1_29 is not set
CONFIG_PORT_RTS1_NONE=3Dy
# CONFIG_UART_RTS_CONTROL_SCC1 is not set
CONFIG_PORT_CD1_NONE=3Dy
# CONFIG_UART_CD_CONTROL_SCC1 is not set
CONFIG_PORT_DTR1_NONE=3Dy
# CONFIG_PORT_DTR1_A is not set
# CONFIG_PORT_DTR1_B is not set
# CONFIG_PORT_DTR1_C is not set
# CONFIG_PORT_DTR1_D is not set
#
# SCC2
#
CONFIG_PORT_CTS2_NONE=3Dy
# CONFIG_CTS2_13 is not set
# CONFIG_CTS2_28 is not set
CONFIG_PORT_RTS2_NONE=3Dy
# CONFIG_UART_RTS_CONTROL_SCC2 is not set
CONFIG_PORT_CD2_NONE=3Dy
# CONFIG_UART_CD_CONTROL_SCC2 is not set
CONFIG_PORT_DTR2_NONE=3Dy
# CONFIG_PORT_DTR2_A is not set
# CONFIG_PORT_DTR2_B is not set
# CONFIG_PORT_DTR2_C is not set
# CONFIG_PORT_DTR2_D is not set
#
# SCC3
#
CONFIG_PORT_CTS3_NONE=3Dy
# CONFIG_UART_CTS_CONTROL_SCC3 is not set
CONFIG_PORT_RTS3_NONE=3Dy
# CONFIG_UART_RTS_CONTROL_SCC3 is not set
CONFIG_PORT_CD3_NONE=3Dy
# CONFIG_UART_CD_CONTROL_SCC3 is not set
CONFIG_PORT_DTR3_NONE=3Dy
# CONFIG_PORT_DTR3_A is not set
# CONFIG_PORT_DTR3_B is not set
# CONFIG_PORT_DTR3_C is not set
# CONFIG_PORT_DTR3_D is not set
#
# SCC4
#
CONFIG_PORT_CTS4_NONE=3Dy
# CONFIG_UART_CTS_CONTROL_SCC4 is not set
CONFIG_PORT_RTS4_NONE=3Dy
# CONFIG_UART_RTS_CONTROL_SCC4 is not set
CONFIG_PORT_CD4_NONE=3Dy
# CONFIG_UART_CD_CONTROL_SCC4 is not set
CONFIG_PORT_DTR4_NONE=3Dy
# CONFIG_PORT_DTR4_A is not set
# CONFIG_PORT_DTR4_B is not set
# CONFIG_PORT_DTR4_C is not set
# CONFIG_PORT_DTR4_D is not set
#
# Library routines
#
# CONFIG_CRC32 is not set
CONFIG_ZLIB_INFLATE=3Dy
CONFIG_ZLIB_DEFLATE=3Dy
# CONFIG_REED_SOLOMON is not set
#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set
CONFIG_LOG_BUF_SHIFT=3D0
--
^ 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