* Re: MPC885 - USB HCI drivers.
From: Wolfgang Denk @ 2005-05-16 22:03 UTC (permalink / raw)
To: Kylo Ginsberg; +Cc: PPC_LINUX
In-Reply-To: <61cc712d05051614507b688c6e@mail.gmail.com>
Dear Kylo,
in message <61cc712d05051614507b688c6e@mail.gmail.com> you wrote:
>
> There is a driver in the linux-2.4 tree at denx.de, although I have no
No, there is not!
> experience with it. Here's info on the cvs repository:
> http://www.denx.de/e/solution-se.php. Look in drivers/usb for
> m8xxhci.[ch] This code is not in the 2.4/2.6 trees on kernel.org, not
> sure if patches have been submitted. I don't know the history here.
This code will NOT work on a MPC885. It was written for the old
MPC823/850 processors, and it NEVER worked really reliably on these
systems either.
My advice: use a _real_ USB controller.
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
For those who like this sort of thing, this is the sort of thing they
like. - Abraham Lincoln
^ permalink raw reply
* Re: MPC885 - USB HCI drivers.
From: Kylo Ginsberg @ 2005-05-16 21:50 UTC (permalink / raw)
To: Guillaume Autran; +Cc: PPC_LINUX
In-Reply-To: <4284E379.1060907@mrv.com>
Guillaume,
There is a driver in the linux-2.4 tree at denx.de, although I have no
experience with it. Here's info on the cvs repository:=20
http://www.denx.de/e/solution-se.php. Look in drivers/usb for
m8xxhci.[ch] This code is not in the 2.4/2.6 trees on kernel.org, not
sure if patches have been submitted. I don't know the history here.
I will shortly be in need of a 2.6-based driver for the mpc8555e, but
haven't found any patches. I'll probably look to port this driver, so
if you need to modify it, please post patches.
Cheers,
Kylo
On 5/13/05, Guillaume Autran <gautran@mrv.com> wrote:
> Hi,
>=20
> Is there any driver for the USB host controller interface built-in the
> MPC885 processors.
> Does anyone have any experience with it ?
>=20
> Thanks.
> Guillaume.
>=20
> --
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Guillaume Autran
> Senior Software Engineer
> MRV Communications, Inc.
> Tel: (978) 952-4932 office
> E-mail: gautran@mrv.com
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Dan Malek @ 2005-05-16 21:02 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, John Reiser
In-Reply-To: <428905F8.4030204@mvista.com>
On May 16, 2005, at 4:43 PM, Mark A. Greer wrote:
> I think I understand all of that. I wasn't clear in my email. I was
> talking about "fixing" such that 3GB works (i.e., io_block_mapping are
> above 3GB virt, if possible) not "fixing" such that we can get rid of
> io_block_mapping altogether. We still need io_block_mapping for
> exactly the reasons you state.
I think I've seen hacks from you that temporarily set up BATs for
serial console
access until the BAT is forcefully re-used later :-) I just wanted to
document the
issue for everyone, that breaking this is more than just a five minute
fix and
test exercise (which may only further obfuscate a hack than actually
change
anything) :-)
Thanks.
-- Dan
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Mark A. Greer @ 2005-05-16 20:43 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, John Reiser
In-Reply-To: <2dd506f0a6d4b03e771c0bc9d80735e6@embeddededge.com>
Dan Malek wrote:
>
> On May 16, 2005, at 2:06 PM, Mark A. Greer wrote:
>
>> Oops...
>> /me unintentionally stepped into the middle of a flame war :)
>
>
> Just pee on it :-)
Heh!
>
>
>> To be clear, "offender" == board that has an io_block_mapping below
>> the 3 GB line.
>
>
> That is one of the obvious changes. You are likely to find some other
> assumptions
> that may need attention. The problem with io_block_mapping is you
> just can't
> remove it, you have to fix up all of the code that is based on the
> assumption these
> spaces are mapped. You are likely to find yourself in a situation
> where you need
> access to some board control registers before VM is set up and you can
> call
> ioremap(). So, you will find yourself doing some hack in head.S to
> map BAT
> registers to get access to this, which is exactly what
> io_block_mapping() does,
> only in a way that is obvious :-)
I think I understand all of that. I wasn't clear in my email. I was
talking about "fixing" such that 3GB works (i.e., io_block_mapping are
above 3GB virt, if possible) not "fixing" such that we can get rid of
io_block_mapping altogether. We still need io_block_mapping for exactly
the reasons you state.
I need to learn how to write better emails... :(
Mark
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Dan Malek @ 2005-05-16 20:31 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, John Reiser
In-Reply-To: <4288E10A.9030408@mvista.com>
On May 16, 2005, at 2:06 PM, Mark A. Greer wrote:
> Oops...
> /me unintentionally stepped into the middle of a flame war :)
Just pee on it :-)
> To be clear, "offender" == board that has an io_block_mapping below
> the 3 GB line.
That is one of the obvious changes. You are likely to find some other
assumptions
that may need attention. The problem with io_block_mapping is you just
can't
remove it, you have to fix up all of the code that is based on the
assumption these
spaces are mapped. You are likely to find yourself in a situation
where you need
access to some board control registers before VM is set up and you can
call
ioremap(). So, you will find yourself doing some hack in head.S to map
BAT
registers to get access to this, which is exactly what
io_block_mapping() does,
only in a way that is obvious :-)
Thanks.
-- Dan
^ permalink raw reply
* Re: building gcc for ppc platform
From: Wolfgang Denk @ 2005-05-16 20:26 UTC (permalink / raw)
To: Przemysław Fąfara; +Cc: linuxppc
In-Reply-To: <4288FE12.5060907@gmail.com>
In message <4288FE12.5060907@gmail.com> you wrote:
>
> I have a problem with building ggc for ppc platform. I would like to
> build it and use it on my xilinx ml310 board. A'm using a montavista
> linux preview kit, but it doesn't have a gcc. Could you help me?
Use the ELDK - it's more complete, and free.
See http://www.denx.de/ELDK.html
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
People seldom know what they want until you give them what they ask
for.
^ permalink raw reply
* building gcc for ppc platform
From: Przemysław Fąfara @ 2005-05-16 20:09 UTC (permalink / raw)
To: linuxppc
[-- Attachment #1: Type: text/plain, Size: 303 bytes --]
hi
I have a problem with building ggc for ppc platform. I would like to
build it and use it on my xilinx ml310 board. A'm using a montavista
linux preview kit, but it doesn't have a gcc. Could you help me?
--
Przemyslaw Fafara
Institute of Electronic Systems
Warsaw University of Technology
POLAND
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3210 bytes --]
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Mark A. Greer @ 2005-05-16 18:06 UTC (permalink / raw)
To: Mark A. Greer; +Cc: John Reiser, linuxppc-dev
In-Reply-To: <4288DFCB.2080208@mvista.com>
Mark A. Greer wrote:
> Benjamin Herrenschmidt wrote:
>
>>
>> series are by no mean stable. Embedded code has been rather frozen in
>> the rock, I don't think it's much to ask from the appropriate maintainer
>> to have a quick look at possibly upgrading their board support as well.
>>
>
> Seems reasonable to me.
Oops...
/me unintentionally stepped into the middle of a flame war :)
>
>
>> And it isn't a difficult change for most 6xx/7xx/7xxx based boards
>> anyway.
>>
>
> From a quick grep, it looks like apus, gemini, k2, lopec, pplus, prep,
> and prpmc800 are the offenders in the 6xx/7xx/74xx world. Does anyone
> even care about the lopec and k2 anymore?
To be clear, "offender" == board that has an io_block_mapping below the
3 GB line. There are still io_block_mapping calls necessary to map regs
that are used to determine memory size & whatnot but many are above the
3 GB line and even >= 0xf0000000.
Mark
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Mark A. Greer @ 2005-05-16 18:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, John Reiser
In-Reply-To: <1116261725.5095.139.camel@gaston>
Benjamin Herrenschmidt wrote:
>
>series are by no mean stable. Embedded code has been rather frozen in
>the rock, I don't think it's much to ask from the appropriate maintainer
>to have a quick look at possibly upgrading their board support as well.
>
Seems reasonable to me.
>And it isn't a difficult change for most 6xx/7xx/7xxx based boards
>anyway.
>
From a quick grep, it looks like apus, gemini, k2, lopec, pplus, prep,
and prpmc800 are the offenders in the 6xx/7xx/74xx world. Does anyone
even care about the lopec and k2 anymore?
> What I'm worried about is that without some "pressure" (like
>breaking them), it will simply never be fixed...
>
Probably true...
Mark
^ permalink raw reply
* Re: [PATCH 2.6.11.7] ATA Over Ethernet Root, Mark 2
From: Ed L Cashin @ 2005-05-16 17:03 UTC (permalink / raw)
To: Greg KH; +Cc: PPC_LINUX, akpm, Linux Kernel
In-Reply-To: <20050516162011.GA8716@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Mon, May 16, 2005 at 09:14:02AM -0400, McMullan, Jason wrote:
...
[gregkh writes]
>> > Also, please CC the aoe maintainer, that's documented in
>> > Documentation/SubmittingPatches :)
>>
>> I did to support@coraid.com, in a separate message.
>
> That's not the email address listed in MAINTAINERS, is it?
I did get it, though. I didn't realize that the reason for the patch
is for use on systems that have so little RAM that they can't have an
initrd.
It seems like the system will hang forever with no diagnostics if the
root device isn't found. Perhaps an error message would be helpul?
I do wonder whether the problem this patch solves might be a special
case that doesn't merit the extra complexity of a Kconfig knob. It is
certainly a useful patch for some users, but I don't know how many.
--
Ed L Cashin <ecashin@coraid.com>
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Dan Malek @ 2005-05-16 17:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, John Reiser
In-Reply-To: <1116261725.5095.139.camel@gaston>
On May 16, 2005, at 12:42 PM, Benjamin Herrenschmidt wrote:
> On the other hands, how many embedded boards care about getting the
> latest "linus" tree ?
Why are you PMac guys always treating the embedded boards
as second class citizens? Don't any of you remember that all of
initial PowerPC work was done on an embedded board and the PMac
was a beneficiary of that work? :-)
Of course we care the "linus" tree is up to date. We use that
all of the time for new product development. If it wasn't for so few
of us having permission to write updates, we would probably register
many more than you do.
> ... Embedded code has been rather frozen in
> the rock, I don't think it's much to ask from the appropriate
> maintainer
> to have a quick look at possibly upgrading their board support as well.
It's not frozen, it's just more tedious because we are trying to find
solutions that are commonly good for everyone, not demanding
changes and forcing everyone else to adapt.
> And it isn't a difficult change for most 6xx/7xx/7xxx based boards
> anyway. What I'm worried about is that without some "pressure" (like
> breaking them), it will simply never be fixed...
Who cares? We have the ability to support the memory map flexibility
for everyone. If you need it, use it, and fix it if necessary. There
are
too many other things that need attention. Again, you are taking one
of the features we added for embedded boards a long time ago, and
demanding everyone support it. That's not necessary. If you want
to use this feature on a PMac, then use it, but please don't demand
everyone else do so. We didn't do that when the feature was added.
> The whole io_block_mapping() was a bad idea in the first place.
All of the ideas in 2.6 are going to look like bad ideas in the future
:-)
It's what worked and was necessary given the lack of any other
APIs at the time. We are working on removing these in the embedded
boards, and it has to be done on the PMac as well if you want to
take advantage of something other than a 2G task space.
As time permits, I will make whatever changes to the board ports
I'm aware of so they will accommodate a 3G task space, or fix up
the configuration files so the default is 2G. At some point, we can
make it the configuration default.
Thanks.
-- Dan
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Benjamin Herrenschmidt @ 2005-05-16 16:42 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, John Reiser
In-Reply-To: <fe487e7a8a89e65cfefd4f5dd39a982d@embeddededge.com>
> The PMac is only one "board" out of many we support, and I don't think
> it should be considered the default or generic configuration any more
> than any other board. The PMac is the easiest to update because it's
> a single configuration file.
Single ? Hrm... not so sure :) It's also the biggest (in terms of line
of code) subarch of the ppc32 architecture :) Besides, pmac is also chrp
& prep as I'm really talking about CONFIG_PPC_MULTIPLATFORM (too bad no
embedded vendor ever tried to be part of the common kernel... heh)
> If you want that to have a 3G default task
> space, then update that one configuration file.
Hrm... you mean the defconfig then ? Ok, right, well, I suppose we could
update pmac, prep and chrp defconfigs. It's still not the default as per
Kconfig which I find a little bit annoying.
> As we have time we
> will update all of the others, and when we get to the point where most
> boards are of that configuration, we'll make it the default and the
> minority of boards become the special cases.
On the other hands, how many embedded boards care about getting the
latest "linus" tree ? I mean, I do have to update pmac support regulary
as new developpement occurs, and you know as well as I do that 2.6.x
series are by no mean stable. Embedded code has been rather frozen in
the rock, I don't think it's much to ask from the appropriate maintainer
to have a quick look at possibly upgrading their board support as well.
And it isn't a difficult change for most 6xx/7xx/7xxx based boards
anyway. What I'm worried about is that without some "pressure" (like
breaking them), it will simply never be fixed...
The whole io_block_mapping() was a bad idea in the first place. We
introduced that API to replace an even worse one which was to set BATs
directly in the early days of the kernel, but I for one think we should
just have killed the whole thing in the first place.
Ben.
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Eugene Surovegin @ 2005-05-16 16:22 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20050516161108.5BD3CC1512@atlas.denx.de>
On Mon, May 16, 2005 at 06:11:03PM +0200, Wolfgang Denk wrote:
> In message <1116255938.5095.133.camel@gaston> you wrote:
> >
> > I suppose it would add about ... 1 instruction :) Which is probably
> > barely measurable compared to the cost of the cache misses of getting to
> > the page table entires...
>
> That would be just another "just 1 instruction" modifircation to a
> time critical path in a kernel which already now is so slow compared
> against an old 2.4 kernel that I'm really surprised to nobody seems
> to care.
Well, this just one instruction is needed to make code correct anyway,
because currently head_8xx.S, head_4xx.S, head_44x.s just hardcode
0x80000000 TASK_SIZE assumption, and you cannot change TASK_SIZE on
all this hardware.
--
Eugene
^ permalink raw reply
* Re: Missing m8260_cpm_dpfree()
From: Kumar Gala @ 2005-05-16 16:25 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20050516153939.6CF17C1512@atlas.denx.de>
On May 16, 2005, at 10:39 AM, Wolfgang Denk wrote:
> In message <20050516161503.0081b1b0.ajz@cambridgebroadband.com> you=20
> wrote:
> >
> > I have a question about the MPC8260 dual port RAM allocation=20
> routines.
> >
> > In arch/ppc/8260_io/commproc.c this is a=A0 m8260_cpm_dpalloc()=20
> routine,
> > but the m8260_cpm_dpfree() routine is missing.=A0 Does anybody know=20=
> where
> > I can find this?
>
> It was never implemented.
>
> We added this in the context of the 8xx tree, and submitted=A0 it=A0 =
here
> at least twice. The patches were never accepted for the publich sourc
> trees,=A0 so=A0 we=A0 stopped=A0 wasting=A0 our=A0 time on this. I =
think Pantelis
> Antoniou (?) submitted similar code later, but I don't remember=A0 =
what
> happened to it.
The 2.6 kernel has a better set of functions around managing cpm memory=20=
based on changes from Pantelis.
- kumar
^ permalink raw reply
* Re: [PATCH 2.6.11.7] ATA Over Ethernet Root, Mark 2
From: Greg KH @ 2005-05-16 16:20 UTC (permalink / raw)
To: McMullan, Jason; +Cc: akpm, Linux Kernel, ecashin, PPC_LINUX
In-Reply-To: <1116249602.9050.105.camel@jmcmullan.timesys>
On Mon, May 16, 2005 at 09:14:02AM -0400, McMullan, Jason wrote:
> [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.
Ouch, that's not good at all. Care to take this info to the
linux-hotplug-devel mailing list and we can work on fixing this for you?
(first a few things to try, use 'udevsend' and build udev using klibc.
Also do not have any rules that call out to shell scripts, as you are
using devfs I don't see that you need any special rules at all
probably.)
> > 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?
It can be based on your patch :)
Anyway, it's floating around in the lkml archives, sorry, don't have a
direct link.
> > Also, please CC the aoe maintainer, that's documented in
> > Documentation/SubmittingPatches :)
>
> I did to support@coraid.com, in a separate message.
That's not the email address listed in MAINTAINERS, is it?
> > > +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.
with klibc? Again, take it to linux-hotplug-devel, if we don't get
reports about problems, we assume that everyone is happy with it. I
haven't seen you asking about this there.
> > 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.
It's just a mirrage, it's not really that fast :)
> > 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.
Even with ash built with klibc and/or busybox?
> > - 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?
lkml archives. Or base it on your work you have already started to do
:)
thanks,
greg k-h
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Wolfgang Denk @ 2005-05-16 16:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1116255938.5095.133.camel@gaston>
In message <1116255938.5095.133.camel@gaston> you wrote:
>
> I suppose it would add about ... 1 instruction :) Which is probably
> barely measurable compared to the cost of the cache misses of getting to
> the page table entires...
That would be just another "just 1 instruction" modifircation to a
time critical path in a kernel which already now is so slow compared
against an old 2.4 kernel that I'm really surprised to nobody seems
to care.
> But I agree that we don't abolutely _need_ to break everybody. Maybe a
> better compromise would be to have the default beeing per CPU family ?
> 6xx/7xx/7xxx could default to 3G and 8xx stay at 2G...
How many systems actually need this? Why make the <1% of the systems
that need it the default?
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
Q: Why do PCs have a reset button on the front?
A: Because they are expected to run Microsoft operating systems.
^ permalink raw reply
* Re: [PATCH] i2c: Race fix for i2c-mpc.c
From: Sylvain Munaut @ 2005-05-16 16:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: Asier Llano Palacios, ML linuxppc-embedded
In-Reply-To: <5fe12cfac05d60b8af016382594e50db@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
Kumar Gala wrote:
> Sylvain,
>
> Are you really still using the OCP side of the driver? Do we need a
> similar fix for the platform driver side?
/me hits himself with a hammer
Damn I included the wrong diff ... Sorry about that, the good one is
in attachment.
No I don't use the OCP side but I changed both to stay coherent. I don't
experience the problem myself, it's Asier who reported it and it
apparently mostly shows up on the second i2c bus (where I have nothing
on my hardware and anyway my bootloader init I2C beforehand ...).
But the patch looks correct, when a bus is added, it should be ready to
be used.
Sylvain
---
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>
---
[-- Attachment #2: i2c-mpc-racefix.diff --]
[-- Type: text/x-patch, Size: 1314 bytes --]
--- linux-2.6/drivers/i2c/busses/i2c-mpc.c 2005-05-16 09:47:10.000000000 +0200
+++ linux-2.6-mpc52xx/drivers/i2c/busses/i2c-mpc.c 2005-05-16 17:50:18.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);
@@ -430,6 +431,9 @@
goto fail_irq;
}
+ mpc_i2c_setclock(i2c);
+ dev_set_drvdata(device, i2c);
+
i2c->adap = mpc_ops;
i2c_set_adapdata(&i2c->adap, i2c);
i2c->adap.dev.parent = &pdev->dev;
@@ -438,8 +442,6 @@
goto fail_add;
}
- mpc_i2c_setclock(i2c);
- dev_set_drvdata(device, i2c);
return result;
fail_add:
@@ -456,8 +458,8 @@
{
struct mpc_i2c *i2c = dev_get_drvdata(device);
- dev_set_drvdata(device, NULL);
i2c_del_adapter(&i2c->adap);
+ dev_set_drvdata(device, NULL);
if (i2c->irq != 0)
free_irq(i2c->irq, i2c);
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Dan Malek @ 2005-05-16 15:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, John Reiser
In-Reply-To: <1116255938.5095.133.camel@gaston>
On May 16, 2005, at 11:05 AM, Benjamin Herrenschmidt wrote:
> I suppose it would add about ... 1 instruction :)
It's a little more than that :-)
> But I agree that we don't abolutely _need_ to break everybody. Maybe a
> better compromise would be to have the default beeing per CPU family ?
> 6xx/7xx/7xxx could default to 3G and 8xx stay at 2G...
That's still going to break nearly every embedded board. My point is
that is all configurable for each individual board, so if you want that
to
be the default for a board, then just update the defconfig for that
board.
The PMac is only one "board" out of many we support, and I don't think
it should be considered the default or generic configuration any more
than any other board. The PMac is the easiest to update because it's
a single configuration file. If you want that to have a 3G default task
space, then update that one configuration file. As we have time we
will update all of the others, and when we get to the point where most
boards are of that configuration, we'll make it the default and the
minority of boards become the special cases.
Thanks.
-- Dan
^ permalink raw reply
* Re: Missing m8260_cpm_dpfree()
From: Wolfgang Denk @ 2005-05-16 15:39 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <20050516161503.0081b1b0.ajz@cambridgebroadband.com>
In message <20050516161503.0081b1b0.ajz@cambridgebroadband.com> you wrote:
>
> I have a question about the MPC8260 dual port RAM allocation routines.
>
> In arch/ppc/8260_io/commproc.c this is a m8260_cpm_dpalloc() routine,
> but the m8260_cpm_dpfree() routine is missing. Does anybody know where
> I can find this?
It was never implemented.
We added this in the context of the 8xx tree, and submitted it here
at least twice. The patches were never accepted for the publich sourc
trees, so we stopped wasting our time on this. I think Pantelis
Antoniou (?) submitted similar code later, but I don't remember what
happened to it.
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
Good manners are the settled medium of social, as specie is of
commercial, life; returns are equally expected for both.
- Lord Chesterfield _Letters to his Son_, 25 December 1753
^ permalink raw reply
* Re: [PATCH] i2c: Race fix for i2c-mpc.c
From: Kumar Gala @ 2005-05-16 15:30 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: Asier Llano Palacios, ML linuxppc-embedded
In-Reply-To: <0.20050516_092837.tnt@patchsend.246tNt.com>
Sylvain,
Are you really still using the OCP side of the driver? Do we need a=20
similar fix for the platform driver side?
- kumar
On May 16, 2005, at 1:24 AM, Sylvain Munaut wrote:
> 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=A0=A0=A0=A0=A0 2005-05-16=20=
> 09:08:02.000000000 +0200
> +++ linux-2.6/drivers/i2c/busses/i2c-mpc.c=A0=A0=A0=A0=A0 2005-05-16=20=
> 09:09:51.000000000 +0200
> @@ -333,6 +333,9 @@
> =A0=A0=A0=A0=A0=A0=A0 } else
> =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 i2c->irq =3D 0;
> =A0
> +=A0=A0=A0=A0=A0=A0 mpc_i2c_setclock(i2c);
> +=A0=A0=A0=A0=A0=A0 ocp_set_drvdata(ocp, i2c);
> +
> =A0=A0=A0=A0=A0=A0=A0 i2c->adap =3D mpc_ops;
> =A0=A0=A0=A0=A0=A0=A0 i2c_set_adapdata(&i2c->adap, i2c);
> =A0
> @@ -341,8 +344,6 @@
> =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 goto fail_add;
> =A0=A0=A0=A0=A0=A0=A0 }
> =A0
> -=A0=A0=A0=A0=A0=A0 mpc_i2c_setclock(i2c);
> -=A0=A0=A0=A0=A0=A0 ocp_set_drvdata(ocp, i2c);
> =A0=A0=A0=A0=A0=A0=A0 return result;
> =A0
> =A0=A0=A0=A0=A0=A0 fail_add:
> @@ -358,8 +359,8 @@
> =A0static void __devexit mpc_i2c_remove(struct ocp_device *ocp)
> =A0{
> =A0=A0=A0=A0=A0=A0=A0 struct mpc_i2c *i2c =3D ocp_get_drvdata(ocp);
> -=A0=A0=A0=A0=A0=A0 ocp_set_drvdata(ocp, NULL);
> =A0=A0=A0=A0=A0=A0=A0 i2c_del_adapter(&i2c->adap);
> +=A0=A0=A0=A0=A0=A0 ocp_set_drvdata(ocp, NULL);
> =A0
> =A0=A0=A0=A0=A0=A0=A0 if (ocp->def->irq !=3D OCP_IRQ_NA)
> =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 free_irq(i2c->irq, i2c);
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Missing m8260_cpm_dpfree()
From: Alex Zeffertt @ 2005-05-16 15:15 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I have a question about the MPC8260 dual port RAM allocation routines.
In arch/ppc/8260_io/commproc.c this is a m8260_cpm_dpalloc() routine,
but the m8260_cpm_dpfree() routine is missing. Does anybody know where
I can find this?
I am using denx's linuxppc_2_4_devel tree from 2005-03-06.
TIA,
Alex
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Benjamin Herrenschmidt @ 2005-05-16 15:05 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, John Reiser
In-Reply-To: <c58d28ab50872f95d4c4a751d1768513@embeddededge.com>
On Mon, 2005-05-16 at 11:04 -0400, Dan Malek wrote:
> On May 16, 2005, at 2:21 AM, Kumar Gala wrote:
>
> >
> > On May 16, 2005, at 12:52 AM, Benjamin Herrenschmidt wrote:
> >> 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.
>
> There isn't any reason to break everything and force updates. If
> someone wants
> a 3G task size, then just configure that with the advanced options.
> All of that
> grew out of the embedded board support, so just make PMac support it
> too.
> In particular, I don't want to force the 8xx to a 3G task space,
> because it adds
> more instructions to the TLB handlers, on a system that has never
> required
> such application space. We are 12 releases in 2.6, and it still seems
> like
> a development kernel :-) I think if someone wants this feature on a
> board
> port that doesn't support it, then just fix that one board port instead
> of breaking
> everything.
I suppose it would add about ... 1 instruction :) Which is probably
barely measurable compared to the cost of the cache misses of getting to
the page table entires...
But I agree that we don't abolutely _need_ to break everybody. Maybe a
better compromise would be to have the default beeing per CPU family ?
6xx/7xx/7xxx could default to 3G and 8xx stay at 2G...
Ben.
^ permalink raw reply
* Re: 2GB address space limit on 32-bit PowerPC Macintosh
From: Dan Malek @ 2005-05-16 15:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, John Reiser
In-Reply-To: <7d5cfed0ee1edade8050d2c4da94b3f1@freescale.com>
On May 16, 2005, at 2:21 AM, Kumar Gala wrote:
>
> On May 16, 2005, at 12:52 AM, Benjamin Herrenschmidt wrote:
>> 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.
There isn't any reason to break everything and force updates. If
someone wants
a 3G task size, then just configure that with the advanced options.
All of that
grew out of the embedded board support, so just make PMac support it
too.
In particular, I don't want to force the 8xx to a 3G task space,
because it adds
more instructions to the TLB handlers, on a system that has never
required
such application space. We are 12 releases in 2.6, and it still seems
like
a development kernel :-) I think if someone wants this feature on a
board
port that doesn't support it, then just fix that one board port instead
of breaking
everything.
Thanks.
-- Dan
^ permalink raw reply
* Re: udhcp problem
From: Grant Likely @ 2005-05-16 13:43 UTC (permalink / raw)
To: Atit_Shah; +Cc: linuxppc-embedded
In-Reply-To: <D8595042F3765A4285B848A78A2C2ED10277B7@bsdmsg002.corp.satyam.ad>
On 5/12/05, Atit_Shah <Atit_Shah@satyam.com> wrote:
> My configuration is as follows:
>=20
> _______________________
> | ROUTER |
> | ___ ___ |
> |_____| |_______| |___|
> LAN WAN
> /\ /\
> | |
> Stand Alone Company
> Windows System Network
> (eth0) (eth1)
>=20
> I have a udhcp server running on eth0. When I give the command on the
> windows machine "ipconfig /renew", the router assigns an IP address to
> the System in the range 192.168.1.x while the router itself has the IP
> 192.168.1.1 (default). I can ping the router from the system and
> vice-versa.
>=20
> I manually assigned a static IP to eth1 as 172.19.56.x insync with the
> company IP address scheme. I can ping from the router to any other
> system on the network.
>=20
> Now when I try to ping a system or eth1 from the windows machine I get a
> time out. But if I have to manually assign an IP to the windows
> machine(ie not through the udhcp server) I am able to ping eth1 and any
> other system on the network.
>=20
How have you set up routing? Are you trying to do NAT? You are
probably going to need to set up some IPTables. It's more than just a
matter of bringing up both interfaces. (BTW, congratulations on
getting both ports working now) Have you read through any of the
networking howtos on linuxdocs.org?
g.
^ 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