* Re: [PATCH 00/10] Updated ML300 & ML403 patches
From: Peter Ryser @ 2006-01-17 17:06 UTC (permalink / raw)
To: Grant Likely
Cc: Andrei Konovalov, Grant Likely, Rick Moleres, linuxppc-embedded
In-Reply-To: <43CD1021.7080205@secretlab.ca>
> I don't understand what you mean. It sounds like your suggesting I do
> exactly opposite what you're arguing; hand modify one of the
> xparameters_*.h files. Are you saying that edk can't generate Linux
> redefines for the ml403 at the moment?
Yes, it can. It looks they are not present in the xparameters_ml403.h
that you submitted as part of your patch. I'll send you the
automatically generated file in a seperate email.
> I do *not* think I should replace the edk-generated
> xparameters_ml403.h with a hacked xparameters_ml300.h file. I'd
> rather use the generated _ml403 file and change the infrastructure
> when the Linux redefines are ready.
See above. BTW, I'm not sure how familiar you are with the process in
EDK. Let me know if I can help you step through it.
>> That's not a recommended flow. It's very easy to create an EDK design
>> with the proper settings and since it is very likely that things
>> change during the design process of the FPGA the small investment
>> into making the proper settings in the tool will save a lot of time
>> in the end.
>
>
> I understand that it's not *recommended*; I'm just saying it's not
> always *reality* :p
Yeah, that's true for user projects. However, I hope that we can get the
default included in the Linux 2.6 kernel right.
> Yes; but I already said that I'll change the patch to use the Xilinx
> redefines. My argument is simply that *if* changes are required,
> there is a way for the user to do it. In the normal (recommended)
> case; nothing will need to be done. (think Larry Wall's quote: "easy
> things easy; hard things possible)
>
> When it is needed; the fixups will be in xparameters.h; not
> xparameters_*.h; and they'll be for a specific port. The fixups will
> only need to be done once per project (most likely).
I'm not sure that I follow your argument here.
> My point is that the Linux redefines are useful to more than just
> Linux ports. Don't you think standalone apps could also benefit from
> a sane-set of defines for peripherals? In other words; shouldn't the
> Linux redefines be always available (and called something more generic)?
I see what you mean and I tend to agree.
> okay, I'll change the patch to use those names.
Great. Thanks.
- Peter
^ permalink raw reply
* Re: General GIT MO question
From: Grant Likely @ 2006-01-17 16:49 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <43CB3127.7060107@dlasys.net>
David H. Lynch Jr. wrote:
> I appreciate you feedback on the E12/UartLite stuff I posted earlier.
no problem
>
> I have gotten sufficiently compitent with git that I can use it as a
> source code manager.
> But despite perusing through a fairly significant amount of git docs, I
> have not really grasped how to get from how I work to what seems to be
> the norm for patch subimissions.
Heh, your tracking the same path of pain that I went through 2 months
ago. :)
>
> Fixing a bug or adding a small feature is one thing. You have a base,
> and and end result and a simple diff. But I am porting to a whole new
> board, adding support for two new serial drivers, and adding boot to
> init serial IO support - all at once, as well as dealing with bugs and
> mis-steps along the way.
>
> I can figure out how to get git to do alot of nice things, but I can
> not figure out how to get it to produce a nice modularized set of
> patches that includes only those things relevant for kernel submission.
Here's what I do, assuming that my changes are in the 'master' branch,
and 'master' is based off of 'origin'. BTW, I also use the cogito with git.
1. create a new branch 'cleanup' off of origin so it doesn't have any of
my patches in it.
$ git branch cleanup origin
$ git checkout origin
2. get a list of all my patches; I use 'cg log' and look for the sha1
'commit' tags.
$ cg log master
p
3a. start 'cherry-picking' my patches one-by-one from 'master' to
'cleanup'. Feel free to use this to reorder patches
$ git cherry-pick -r <first-commit-sha1>
$ git cherry-pick -r <second-commit-sha1>
$ git cherry-pick -r <third-commit-sha1>
3b. If I want to modify the patch before committing; I use the -n flag
to only apply the changes; clean up the change, then commit it with the
-c flag. Also do this if a patch conflicts.
$ git cherry-pick -r -n <messy-commit-sha1>
$ <edit stuff>
$ cg commit -c <messy-commit-sha1> # Use the original change message
3c. Cherry picking works for merging patches too
$ git cherry-pick -r -n <partial-patch1>
$ git cherry-pick -r -n <partial-patch2>
$ git cherry-pick -r -n <partial-patch3>
$ cg commit
4. generate patch files for submission to the mailing list
$ git-format-patch -o <output dir> origin cleanup
5. (optional) make 'cleanup' the new 'master
$ git branch -f master cleanup
$ git checkout master
>
> I am looking for a clue here. How do you produce a clean set of
> granular patches including only what you want and not the all the steps
> and mis-steps along the way ?
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
^ permalink raw reply
* Re: [PATCH 00/10] Updated ML300 & ML403 patches
From: Grant Likely @ 2006-01-17 15:41 UTC (permalink / raw)
To: Peter Ryser
Cc: Grant Likely, Andrei Konovalov, Rick Moleres, linuxppc-embedded
In-Reply-To: <43CCE89B.8050603@xilinx.com>
Peter Ryser wrote:
>
>> Hmm, did you use the ml403 and ml300 def configs? What date did you
>> pull Linus' tree? Kumar and Paul were talking today about some serial
>> subsystem breakage on the linux-2.6 tree this weekend... I'll fast
>> forward tonight and try it on my board.
>
>
> Okay, please let me know how this works for you.
>
>> Try seeking to commit: 67daf5f11f06b9b15f8320de1d237ccc2e74fe43
>> That's what I generated the latest patches against.
>
>
> Hmm, I only recently switched to using git. Is this number string some
> kind of a tag that I can synchronize my local git tree to? If so, how?
>
Yea, the number is kind of like a raw tag without a name associated with
it. The cg-seek command can be used to get you there. (But you also
need to have cogito installed)
>>> Anyway, there is another issue that I would like to bring up and it
>>> has to do with xparameters.h. The xparameters.h file, or more
>>> exactly, the xparameters_* file, is automatically generated by EDK
>>> and is then used to configure the devices in the Linux kernel at
>>> compile time. While I understand the desire to get away from a static
>>> device definition to device enumeration at run-time, the current set
>>> of patches is a step backwards for users from a useability point of
>>> view. Users will now have to modify xparameters*.h by hand which is
>>> an error-prone process.
>>
>>
>>
>> Actually, users should *never* modifiy generated files. The intent is
>> that board specific fixups go directly into the top level
>> xparameters.h so that newly generated files don't have to be touched.
>> But yes, I understand what you mean.
>
>
> An EDK user is free to choose arbitrary names for his peripherals.
> Additionally, Base System Builder uses different names for various
> boards (historically). With that it is impossible to make static
> assignments in xparameters.h. If you go back to the 2.4 kernel and have
> a look at xparameters_ml300.h you can see that the assignment of boards
> specific parameters to Linux specific parameters is done in there and
> that xparameters.h is basically used to chose the proper xparameters_*
> file for a given board.
okay
>
>>> Additionally, the original 'redefines' are now replaced with
>>> redefines in xparameters.h but differently for every board. I suggest
>>> we keep the 2.4 methodology until we can come up with a better
>>> approach to enumerate devices at run-time.
>>
>>
>>
>> Andrei & I are already discussing this. I'm going to change the
>> xparameters redefines to provide a default set of mappings that can be
>> used if xparameters_*.h has the linux specific mappings.
>
>
> Thanks. Why not just use the xparameters_ml300.h file created by the
> system_linux.xmp in the EDK reference design for the ML403 and rename it
> to xparameters_ml403.h for inclusion into the kernel tree? We could then
> make a change in EDK, add a parameter that lets the user specify the
> board he uses, and with that automatically create an xparameters_ml403.h
> (or any other board for that matter).
I don't understand what you mean. It sounds like your suggesting I do
exactly opposite what you're arguing; hand modify one of the
xparameters_*.h files. Are you saying that edk can't generate Linux
redefines for the ml403 at the moment?
I do *not* think I should replace the edk-generated xparameters_ml403.h
with a hacked xparameters_ml300.h file. I'd rather use the generated
_ml403 file and change the infrastructure when the Linux redefines are
ready.
>
>> However, due to the fact that generated xparam files don't have the
>> Linux redefines if the FPGA engineer doesn't select a linux bsp.
>
>
> That's not a recommended flow. It's very easy to create an EDK design
> with the proper settings and since it is very likely that things change
> during the design process of the FPGA the small investment into making
> the proper settings in the tool will save a lot of time in the end.
I understand that it's not *recommended*; I'm just saying it's not
always *reality* :p
>
>> I think it's important to allow user defined 'fixups' for their
>> board. (I've personally worked on a couple of projects where the FPGA
>> engineer would not generate the Linux BSP). Design specific fixups
>> can go into the top level xparameters.h without touching the generated
>> file
>
>
> I strongly believe that this approach fixes things in the wrong place.
> The correct thing to do is to use EDK to create a proper xparameters_*.h
> that matches the FPGA design. In your methodology, if the user decides
> to change the peripheral names in EDK he will have to go back and change
> the defines in xparameters.h. With the 2.4 kernel methodology that is
> not necessary as such changes will be represented in a regenerated
> board-specific xparameters_*.h
???
Yes; but I already said that I'll change the patch to use the Xilinx
redefines. My argument is simply that *if* changes are required, there
is a way for the user to do it. In the normal (recommended) case;
nothing will need to be done. (think Larry Wall's quote: "easy things
easy; hard things possible)
When it is needed; the fixups will be in xparameters.h; not
xparameters_*.h; and they'll be for a specific port. The fixups will
only need to be done once per project (most likely).
>
>> <rant> BTW; it really bugs me that edk will generate different xparam
>> files depending on the bsp; why isn't there a single standard set of
>> data that is loaded into all xparam files; regardless of software
>> target? Some no-OS targets need the same information that a Linux
>> port needs. </rant>
>
>
> EDK creates an xparameters.h that matches the names of the parameters in
> the hardware design. However, EDK is capable of assuming other
> personalities than 'standalone', for example Linux.
My point is that the Linux redefines are useful to more than just Linux
ports. Don't you think standalone apps could also benefit from a
sane-set of defines for peripherals? In other words; shouldn't the
Linux redefines be always available (and called something more generic)?
> With the Linux
> personality it creates the proper files AND directory structure for
> inclusion into the Linux kernel. Ideally, the source files that are used
> to create the Linux bsp for a given FPGA design should be included in
> the kernel tree and be maintained in there (maybe, in the xparameters
> directory). I'm not so sure though how well this would be accepted in
> the community. Opinions?
I'll get back to you on this; I've got some thoughts; but they'll take a
while to coallate.
>
>> I've avoided using the same names as used by the Linux redefines
>> because I don't know how stable the linux bsp naming convention is,
>> and I want to avoid a naming conflict. If you can *guarantee* me that
>> those linux redefines are stable, then I have no problem using them
>> instead of the new defines that are currently in the patch. If they
>> are not; then I'll just do a one-to-one mapping into a non-conflicting
>> namespace, and users can provide custom definitions as needed.
>
>
> The names are stable. They have not changed since xparameters_ml300.h
> has been initially published to the 2.4 repository and there are no
> intentions on changing them. And again, we really want to move towards a
> structure that allows for detecting peripherals at run-time. That will
> improve useability by a magnitude as no recompilation of the Linux
> kernel will be needed when the FPGA design changes.
okay, I'll change the patch to use those names.
>
>> This really isn't a big deal anyway; most of this discussion will
>> become moot in short order. Sometime in the next few releases,
>> linuxppc will flip over to using a flattened device tree to pass
>> device information from the boot loader to the kernel. xparameters
>> will drop out of the kernel proper entirely except for the
>> edk-generated device drivers (which is another issue entirely). All
>> the xparam stuff will be extracted into a device tree by u-boot or the
>> zImage wrapper. The kernel just won't care. :)
>
>
> I agree. That's the way to go. Let's work towards that goal and keep
> xparameters_* as they have been in 2.4 for the moment.
>
>>> Specific to the patch: XPAR_DDR_SIZE is not the same as XPAR_MEM_*.
>>> XPAR_DDR_SIZE is specifically defined by the user as part of the BSP
>>> generation and indicates how much memory is available for Linux. This
>>> can be (and typically is) the same as the physically available memory
>>> but can be less than that. On the other hand XPAR_MEM_* can be the
>>> same or a multiple of the physically available memory (aliasing for
>>> cached and non-cached accesses). Statically defining the memory size
>>> in xparameters_ml403.h is not desirable. This is especially true for
>>> the multi-processor FPGA devices that might want to share the
>>> physically available memory between themselves.
>>
>>
>>
>> As you can see in embed_config.c; I already discovered this the hard
>> way :(
>
>
> Right. Sorry, I was quoting the wrong file. The value should not be
> hard-coded in embed_config.c but instead XPAR_DDR_SIZE should be used
> which is defined in xparameters_ml403.h.
ok
>
>> Hmmm, I don't see any XPAR mem defines in xparameters_ml300.h. (I
>> don't have a copy of the linux xparams for ml403 in front of me at the
>> moment) Is this something new?
>
>
> I was referring to XPAR*MEM*, i.e. the base address and high address
> definition for the memory in EDK.
>
>> Really, this isn't statically defined anyway. The bootloader (u-boot
>> or zImage) passes the memory size into the kernel; and in fact the
>> kernel command line; or the board setup code can restrict the amount
>> of mem used by the kernel. XPAR_MEM_* isn't used by the kernel proper
>> at all.
>
>
> Agreed.
>
>> Thanks for the comments.
>
>
> Thanks for making this patch available. I know how much hard work it is
> to get this done.
>
>>
>>
>> Another issue we need to discuss is if/how to support the xilinx
>> generated BSP in the kernel proper; but I'll leave that for a
>> different email.
>
>
> Okay.
>
>> If there's enough interest; I'll setup another git tree for the virtex
>> specific patches.
>
>
> Hmm, interesting idea. Let's see what others think.
>
> - Peter
cool, thanks.
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
^ permalink raw reply
* Re: [PATCH 00/10] Updated ML300 & ML403 patches
From: Peter Ryser @ 2006-01-17 12:52 UTC (permalink / raw)
To: Grant Likely
Cc: Grant Likely, Andrei Konovalov, Rick Moleres, linuxppc-embedded
In-Reply-To: <43CC9F35.8010305@secretlab.ca>
> Hmm, did you use the ml403 and ml300 def configs? What date did you
> pull Linus' tree? Kumar and Paul were talking today about some serial
> subsystem breakage on the linux-2.6 tree this weekend... I'll fast
> forward tonight and try it on my board.
Okay, please let me know how this works for you.
> Try seeking to commit: 67daf5f11f06b9b15f8320de1d237ccc2e74fe43
> That's what I generated the latest patches against.
Hmm, I only recently switched to using git. Is this number string some
kind of a tag that I can synchronize my local git tree to? If so, how?
>> Anyway, there is another issue that I would like to bring up and it
>> has to do with xparameters.h. The xparameters.h file, or more
>> exactly, the xparameters_* file, is automatically generated by EDK
>> and is then used to configure the devices in the Linux kernel at
>> compile time. While I understand the desire to get away from a static
>> device definition to device enumeration at run-time, the current set
>> of patches is a step backwards for users from a useability point of
>> view. Users will now have to modify xparameters*.h by hand which is
>> an error-prone process.
>
>
> Actually, users should *never* modifiy generated files. The intent is
> that board specific fixups go directly into the top level
> xparameters.h so that newly generated files don't have to be touched.
> But yes, I understand what you mean.
An EDK user is free to choose arbitrary names for his peripherals.
Additionally, Base System Builder uses different names for various
boards (historically). With that it is impossible to make static
assignments in xparameters.h. If you go back to the 2.4 kernel and have
a look at xparameters_ml300.h you can see that the assignment of boards
specific parameters to Linux specific parameters is done in there and
that xparameters.h is basically used to chose the proper xparameters_*
file for a given board.
>> Additionally, the original 'redefines' are now replaced with
>> redefines in xparameters.h but differently for every board. I suggest
>> we keep the 2.4 methodology until we can come up with a better
>> approach to enumerate devices at run-time.
>
>
> Andrei & I are already discussing this. I'm going to change the
> xparameters redefines to provide a default set of mappings that can be
> used if xparameters_*.h has the linux specific mappings.
Thanks. Why not just use the xparameters_ml300.h file created by the
system_linux.xmp in the EDK reference design for the ML403 and rename it
to xparameters_ml403.h for inclusion into the kernel tree? We could then
make a change in EDK, add a parameter that lets the user specify the
board he uses, and with that automatically create an xparameters_ml403.h
(or any other board for that matter).
> However, due to the fact that generated xparam files don't have the
> Linux redefines if the FPGA engineer doesn't select a linux bsp.
That's not a recommended flow. It's very easy to create an EDK design
with the proper settings and since it is very likely that things change
during the design process of the FPGA the small investment into making
the proper settings in the tool will save a lot of time in the end.
> I think it's important to allow user defined 'fixups' for their
> board. (I've personally worked on a couple of projects where the FPGA
> engineer would not generate the Linux BSP). Design specific fixups
> can go into the top level xparameters.h without touching the generated
> file
I strongly believe that this approach fixes things in the wrong place.
The correct thing to do is to use EDK to create a proper xparameters_*.h
that matches the FPGA design. In your methodology, if the user decides
to change the peripheral names in EDK he will have to go back and change
the defines in xparameters.h. With the 2.4 kernel methodology that is
not necessary as such changes will be represented in a regenerated
board-specific xparameters_*.h
> <rant> BTW; it really bugs me that edk will generate different xparam
> files depending on the bsp; why isn't there a single standard set of
> data that is loaded into all xparam files; regardless of software
> target? Some no-OS targets need the same information that a Linux
> port needs. </rant>
EDK creates an xparameters.h that matches the names of the parameters in
the hardware design. However, EDK is capable of assuming other
personalities than 'standalone', for example Linux. With the Linux
personality it creates the proper files AND directory structure for
inclusion into the Linux kernel. Ideally, the source files that are used
to create the Linux bsp for a given FPGA design should be included in
the kernel tree and be maintained in there (maybe, in the xparameters
directory). I'm not so sure though how well this would be accepted in
the community. Opinions?
> I've avoided using the same names as used by the Linux redefines
> because I don't know how stable the linux bsp naming convention is,
> and I want to avoid a naming conflict. If you can *guarantee* me that
> those linux redefines are stable, then I have no problem using them
> instead of the new defines that are currently in the patch. If they
> are not; then I'll just do a one-to-one mapping into a non-conflicting
> namespace, and users can provide custom definitions as needed.
The names are stable. They have not changed since xparameters_ml300.h
has been initially published to the 2.4 repository and there are no
intentions on changing them. And again, we really want to move towards a
structure that allows for detecting peripherals at run-time. That will
improve useability by a magnitude as no recompilation of the Linux
kernel will be needed when the FPGA design changes.
> This really isn't a big deal anyway; most of this discussion will
> become moot in short order. Sometime in the next few releases,
> linuxppc will flip over to using a flattened device tree to pass
> device information from the boot loader to the kernel. xparameters
> will drop out of the kernel proper entirely except for the
> edk-generated device drivers (which is another issue entirely). All
> the xparam stuff will be extracted into a device tree by u-boot or the
> zImage wrapper. The kernel just won't care. :)
I agree. That's the way to go. Let's work towards that goal and keep
xparameters_* as they have been in 2.4 for the moment.
>> Specific to the patch: XPAR_DDR_SIZE is not the same as XPAR_MEM_*.
>> XPAR_DDR_SIZE is specifically defined by the user as part of the BSP
>> generation and indicates how much memory is available for Linux. This
>> can be (and typically is) the same as the physically available memory
>> but can be less than that. On the other hand XPAR_MEM_* can be the
>> same or a multiple of the physically available memory (aliasing for
>> cached and non-cached accesses). Statically defining the memory size
>> in xparameters_ml403.h is not desirable. This is especially true for
>> the multi-processor FPGA devices that might want to share the
>> physically available memory between themselves.
>
>
> As you can see in embed_config.c; I already discovered this the hard
> way :(
Right. Sorry, I was quoting the wrong file. The value should not be
hard-coded in embed_config.c but instead XPAR_DDR_SIZE should be used
which is defined in xparameters_ml403.h.
> Hmmm, I don't see any XPAR mem defines in xparameters_ml300.h. (I
> don't have a copy of the linux xparams for ml403 in front of me at the
> moment) Is this something new?
I was referring to XPAR*MEM*, i.e. the base address and high address
definition for the memory in EDK.
> Really, this isn't statically defined anyway. The bootloader (u-boot
> or zImage) passes the memory size into the kernel; and in fact the
> kernel command line; or the board setup code can restrict the amount
> of mem used by the kernel. XPAR_MEM_* isn't used by the kernel proper
> at all.
Agreed.
> Thanks for the comments.
Thanks for making this patch available. I know how much hard work it is
to get this done.
>
>
> Another issue we need to discuss is if/how to support the xilinx
> generated BSP in the kernel proper; but I'll leave that for a
> different email.
Okay.
> If there's enough interest; I'll setup another git tree for the virtex
> specific patches.
Hmm, interesting idea. Let's see what others think.
- Peter
^ permalink raw reply
* Re: Virtex-4 TEMAC device driver available?
From: Yoshio Kashiwagi @ 2006-01-17 11:54 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <93579fec0601170146h5363e65bt410276b8b696588f@mail.gmail.com>
Hi Patrick-san,
GSRD of the following URL is downloaded and the driver of mvl is
generated by EDK, the Xilinx temac driver and patch for 2.4 will be
obtained.
http://www.xilinx.co.jp/esp/wired/optical/xlnx_net/gsrd.htm
Now, I'm just working temac driver to 2.6 and have not yet completed.
Best Regards,
Yoshio Kashiwagi - Nissin Systems
> Hi,
>
> I'm using linux on several projects running on Virtex2Pro boards
> utilizing a softcore MAC ("OPB EMAC"). Recently, we built a new board
> based on the Virtex 4 FX and I noticed that its hardwired "TEMAC"
> differs significantly from the "OPB EMAC" we used before.
>
> Is there already a linux driver for this TEMAC available? I noticed
> that several patches for basic Virtex-4 support have been posted to
> this list, but I don't know what kernel these patches are based on, or
> where I can download a development snapshot.
>
> Unfortunately, the public rsync repository at source.mvista.com (where
> I got the kernel for our Virtex2Pro based stuff from) seems to be
> discontinued, and I don't see any PPC specific kernel stuff in the git
> repositories there.
>
> Thanks,
> Patrick
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* RE: back trace when a SIGSEGV
From: Redondo Garcia, Roberto @ 2006-01-17 10:29 UTC (permalink / raw)
Cc: linuxppc-dev
my final solution has been to capture signal SIGSEGV in my own program
with a signal handler: =20
signal(SIGSEGV, to segv_handler; =20
and after generate backtrace in my program with the functions
"backtrace()" and "backtrace_symbols()" and write it to file. =20
Thanks
example to generate backtrace: =20
http://www.delorie.com/gnu/docs/glibc/libc_665.html=20
-----Mensaje original-----
De: Dustin Lang [mailto:dalang@cs.ubc.ca]=20
Enviado el: viernes, 02 de diciembre de 2005 15:28
Para: Redondo Garcia, Roberto
CC: linuxppc-dev
Asunto: Re: back trace when a SIGSEGV
Hi,
SIGSEGV (also known as a "segmentation fault" or "segfault") usually
means your program is doing something wrong like trying to dereference a
null pointer. (ie, int* x =3D NULL; *x =3D 42;). To track this down, yo=
u
can use "gdb" (the gnu debugger) - gnu.org. Another option is
"valgrind" - valgrind.org - there is a PowerPC port (thanks, Paul!).
However, this mailing list is for _development_ of the linux _kernel_ on
PowerPC. Your question is not about kernel development so it doesn't
belong here. (Unless you are sure that your program is correct and
somehow the kernel is unfairly giving you a segfault - which doesn't
seem to be the case, based on your message.) Find a mailing list or
message board about userspace programming and ask your question there.
Also, you should learn how to write a bug report. Go to google.com,
type in "how to write a bug report", and read the first ten results.
(For
example: What program are you running? Something you wrote? What OS
are you using? Why do you think the SIGSEGV is something caused by
someone else's code and not your own? Why does it matter how long the
program runs before it crashes? Why didn't you type "debug" into google
and see what came up? (GDB is number 6! Come on, get with it!))
Happy debugging!
dustin.
> hello,
> I have a program that when it has been several hours running, it has a
> problem and falls and it produces a SIGSEGV. I would like to know to=20=
> how debug this error, because I do not have ulimit for generate core=20=
> dump o examine a back trace.
>
> thanks
-------------------------------------------------------------------------=
------------------------------------------
Este correo electr=F3nico y, en su caso, cualquier fichero anexo al mismo=
, contiene informaci=F3n de car=E1cter confidencial exclusivamente dirigi=
da a su destinatario o destinatarios. Queda prohibida su divulgaci=F3n, c=
opia o distribuci=F3n a terceros sin la previa autorizaci=F3n escrita de =
Indra. En el caso de haber recibido este correo electr=F3nico por error, =
se ruega notificar inmediatamente esta circunstancia mediante reenv=EDo a=
la direcci=F3n electr=F3nica del remitente. POR FAVOR, ANTES DE IMPRIMIR=
ESTE CORREO ELECTR=D3NICO CONSIDERE SU APORTACI=D3N A LA CONSERVACI=D3N =
DEL MEDIO AMBIENTE POR LA REDUCCI=D3N DE CONSUMO DE PAPEL.
The information in this e-mail and in any attachments is confidential and=
solely for the attention and use of the named addressee(s). You are here=
by notified that any dissemination, distribution or copy of this communic=
ation is prohibited without the prior written consent of Indra. If you ha=
ve received this communication in error, please, notify the sender by rep=
ly e-mail. PLEASE CONSIDER YOUR ENVIRONMENTAL RESPONSIBILITY BEFORE PRINT=
ING THIS E-MAIL.
^ permalink raw reply
* Virtex-4 TEMAC device driver available?
From: Patrick Huesmann @ 2006-01-17 9:46 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm using linux on several projects running on Virtex2Pro boards
utilizing a softcore MAC ("OPB EMAC"). Recently, we built a new board
based on the Virtex 4 FX and I noticed that its hardwired "TEMAC"
differs significantly from the "OPB EMAC" we used before.
Is there already a linux driver for this TEMAC available? I noticed
that several patches for basic Virtex-4 support have been posted to
this list, but I don't know what kernel these patches are based on, or
where I can download a development snapshot.
Unfortunately, the public rsync repository at source.mvista.com (where
I got the kernel for our Virtex2Pro based stuff from) seems to be
discontinued, and I don't see any PPC specific kernel stuff in the git
repositories there.
Thanks,
Patrick
^ permalink raw reply
* Re: AGPGART driver for ArticiaS - ioremap() problem
From: Gerhard Pircher @ 2006-01-17 8:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1137453496.4823.61.camel@localhost.localdomain>
> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: AGPGART driver for ArticiaS - ioremap() problem
> Datum: Tue, 17 Jan 2006 10:18:15 +1100
>
> > Ah, okay. So at least the approach to use the Uninorth code was a step
> > in the right direction. But that requires changes in the DRI and X
> > server code, right?
>
> Not you shouldn't... there are 2 different things here. One is how you
> access the GART table itself. One is how you access the AGP memory (the
> memory that is bound to the GART).
>
> I'm not 100% sure what of the 2 above cases triggered an error with
> ioremap, I'm not sure what approach should be used, because i don't know
> what your chipset does.
That's the problem: we don't have the datasheet for the ArticiaS. :-(
But the driver initializes correctly with the Uninorth code now and with the
DRI/DRM code changed. (The code in drm_vm.c checks for Apple's PCI vendor
ID. Therefore I just added a check for MAI's PCI vendor ID.) But the X
server freezes after the login screen is displayed (IIRC the mouse still
works, but the keyboard is dead!?).
BTW: A "agp_special_page" is reserved in init.c. Is this page necessary for
the DRI/DRM drivers to work with the Uninorth driver? I enabled this code
snipped for the AmigaONE too to be on the safe side. :-)
> I would need more infos about the hw there. But the basic idea is:
>
> - For the GART table, you don't need to ioremap it (which is generally
> a way to have it non-cacheable I suppose). You can just flush cache
> entries after populating them (see uninorth_insert_memory(), it flushes
> first the pages that are being inserted in the GART as AGP memory is not
> cacheable neither, and at the end of the function, flushes the GART
> entry proper).
There may be another problem: it seems that it is not possible to flush the
TLB cache of the ArticiaS with a specific register setting. At least MAI
didn't specify a bit for this purpose in the code. I have to do some reverse
engineering here. :-)
> - The AGP aperture itself. The main issue there is wether your chipset
> makes the AGP aperture visible to the CPU or not. The Apple UniNorth one
> doesn't for example, it;'s only visible to the graphic chip. That is why
> the uninorth driver sets cant_use_aperture to 1. That forces the DRM to
> generate AGP mappings by using the real memory pages and putting them
> together into a virtual mapping instead of doing a direct mapping of the
> AGP aperture on the bus. Most x86 chipsets however _can_, thus a simple
> remapping of pages is enough.
Good question! How would I have to modify the Uninorth driver to use a
direct mapping of the AGP aperture on the bus?
Thanks!
Gerhard
--
DSL-Aktion wegen großer Nachfrage bis 28.2.2006 verlängert:
GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl
^ permalink raw reply
* Re: [PATCH 00/10] Updated ML300 & ML403 patches
From: Grant Likely @ 2006-01-17 7:39 UTC (permalink / raw)
To: Peter Ryser
Cc: Grant Likely, Andrei Konovalov, Rick Moleres, linuxppc-embedded
In-Reply-To: <43CC5453.3060702@xilinx.com>
Let's keep this conversation on the mailing list.
Peter Ryser wrote:
> Hi Grant and Andrei,
>
> I'm glad to see some activity on the linuxppc email alias for the MLxxx
> boards and appreciate the work put into moving the 2.4 support to 2.6.
>
> I just tried to boot the 2.6 kernel with Grant's patches applied to
> Linus' latest tree on both the ML300 and the ML403 and in both cases end
> up with the PLB Error LED lit up. Both boards print the messages from
> the bootloader, print "Now booting the kernel" and then nothing (but the
> error LED). Anything you can think of that is going wrong?
Hmm, did you use the ml403 and ml300 def configs? What date did you
pull Linus' tree? Kumar and Paul were talking today about some serial
subsystem breakage on the linux-2.6 tree this weekend... I'll fast
forward tonight and try it on my board.
Try seeking to commit: 67daf5f11f06b9b15f8320de1d237ccc2e74fe43
That's what I generated the latest patches against.
>
> Anyway, there is another issue that I would like to bring up and it has
> to do with xparameters.h. The xparameters.h file, or more exactly, the
> xparameters_* file, is automatically generated by EDK and is then used
> to configure the devices in the Linux kernel at compile time. While I
> understand the desire to get away from a static device definition to
> device enumeration at run-time, the current set of patches is a step
> backwards for users from a useability point of view. Users will now have
> to modify xparameters*.h by hand which is an error-prone process.
Actually, users should *never* modifiy generated files. The intent is
that board specific fixups go directly into the top level xparameters.h
so that newly generated files don't have to be touched. But yes, I
understand what you mean.
> Additionally, the original 'redefines' are now replaced with redefines
> in xparameters.h but differently for every board. I suggest we keep the
> 2.4 methodology until we can come up with a better approach to enumerate
> devices at run-time.
Andrei & I are already discussing this. I'm going to change the
xparameters redefines to provide a default set of mappings that can be
used if xparameters_*.h has the linux specific mappings.
However, due to the fact that generated xparam files don't have the
Linux redefines if the FPGA engineer doesn't select a linux bsp. I
think it's important to allow user defined 'fixups' for their board.
(I've personally worked on a couple of projects where the FPGA engineer
would not generate the Linux BSP). Design specific fixups can go into
the top level xparameters.h without touching the generated file
<rant> BTW; it really bugs me that edk will generate different xparam
files depending on the bsp; why isn't there a single standard set of
data that is loaded into all xparam files; regardless of software
target? Some no-OS targets need the same information that a Linux port
needs. </rant>
I've avoided using the same names as used by the Linux redefines because
I don't know how stable the linux bsp naming convention is, and I want
to avoid a naming conflict. If you can *guarantee* me that those linux
redefines are stable, then I have no problem using them instead of the
new defines that are currently in the patch. If they are not; then I'll
just do a one-to-one mapping into a non-conflicting namespace, and users
can provide custom definitions as needed.
This really isn't a big deal anyway; most of this discussion will become
moot in short order. Sometime in the next few releases, linuxppc will
flip over to using a flattened device tree to pass device information
from the boot loader to the kernel. xparameters will drop out of the
kernel proper entirely except for the edk-generated device drivers
(which is another issue entirely). All the xparam stuff will be
extracted into a device tree by u-boot or the zImage wrapper. The
kernel just won't care. :)
>
> Specific to the patch: XPAR_DDR_SIZE is not the same as XPAR_MEM_*.
> XPAR_DDR_SIZE is specifically defined by the user as part of the BSP
> generation and indicates how much memory is available for Linux. This
> can be (and typically is) the same as the physically available memory
> but can be less than that. On the other hand XPAR_MEM_* can be the same
> or a multiple of the physically available memory (aliasing for cached
> and non-cached accesses). Statically defining the memory size in
> xparameters_ml403.h is not desirable. This is especially true for the
> multi-processor FPGA devices that might want to share the physically
> available memory between themselves.
As you can see in embed_config.c; I already discovered this the hard way
:(
Hmmm, I don't see any XPAR mem defines in xparameters_ml300.h. (I don't
have a copy of the linux xparams for ml403 in front of me at the moment)
Is this something new?
Really, this isn't statically defined anyway. The bootloader (u-boot or
zImage) passes the memory size into the kernel; and in fact the kernel
command line; or the board setup code can restrict the amount of mem
used by the kernel. XPAR_MEM_* isn't used by the kernel proper at all.
>
> - Peter
Thanks for the comments.
Another issue we need to discuss is if/how to support the xilinx
generated BSP in the kernel proper; but I'll leave that for a different
email.
If there's enough interest; I'll setup another git tree for the virtex
specific patches.
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
^ permalink raw reply
* [Patch 1/3] Support AMCC Yosemite 440EP and Yellowstone 440GR (v3)
From: John Otken @ 2006-01-17 0:39 UTC (permalink / raw)
To: linuxppc-embedded
This updated patch adds support for AMCC 440EP Yosemite
and 440GR Yellowstone evaluation boards.
I tested it against the 2.6.15 kernel on both boards using
gcc 4.0.0 (ELDK 4.0).
The Yosemite platform files are based on Wade Farnsworth's
Bamboo code. There is only a single board name macro that
depends on CONFIG_YOSEMITE vs CONFIG_YELLOWSTONE so I
didn't create an otherwise identical yellowstone.c/h.
The defconfig files are in parts 2 and 3.
This patch supersedes "Patch: [PATCH 1/3] Support AMCC
Yosemite 440EP and Yellowstone 440GR (v2)" from 9-03:
http://patchwork.ozlabs.org/linuxppc/patch?id=2240
This patch has Stefan Roese's YOSEMITE_PCI_IO_BASE bug fix.
440EP USB support requires Wade Farnsworth's patches:
Sep19 W Farnsworth Add support for the AMCC 440EP to the
PowerPC OHCI USB host driver
Sep19 W Farnsworth Add support for the USB Device interfaces
on the AMCC 440EP
Sep20 W Farnsworth Add support for USB to 440EP platform files
http://patchwork.ozlabs.org/linuxppc//patch?id=2481
Comments are welcome.
Signed-off-by: John Otken <jotken@softadvances.com>
diff -uprN a/arch/ppc/platforms/4xx/Kconfig c/arch/ppc/platforms/4xx/Kconfig
--- a/arch/ppc/platforms/4xx/Kconfig 2006-01-02 21:21:10.000000000 -0600
+++ c/arch/ppc/platforms/4xx/Kconfig 2006-01-16 11:23:57.679417517 -0600
@@ -94,6 +94,18 @@ config OCOTEA
help
This option enables support for the IBM PPC440GX evaluation board.
+config YELLOWSTONE
+ bool "Yellowstone"
+ select WANT_EARLY_SERIAL
+ help
+ This option enables support for the AMCC PPC440GR evaluation board.
+
+config YOSEMITE
+ bool "Yosemite"
+ select WANT_EARLY_SERIAL
+ help
+ This option enables support for the AMCC PPC440EP evaluation board.
+
endchoice
config EP405PC
@@ -111,7 +123,7 @@ config NP405H
config 440EP
bool
- depends on BAMBOO
+ depends on BAMBOO || YOSEMITE
select PPC_FPU
default y
@@ -120,6 +132,11 @@ config 440GP
depends on EBONY
default y
+config 440GR
+ bool
+ depends on YELLOWSTONE
+ default y
+
config 440GX
bool
depends on OCOTEA
@@ -137,7 +154,7 @@ config 440SPE
config 440
bool
- depends on 440GP || 440SP || 440SPE || 440EP
+ depends on 440GP || 440SP || 440SPE || 440EP || 440GR
default y
config 440A
@@ -147,7 +164,7 @@ config 440A
config IBM440EP_ERR42
bool
- depends on 440EP
+ depends on 440EP || 440GR
default y
# All 405-based cores up until the 405GPR and 405EP have this errata.
@@ -169,7 +186,7 @@ config BOOKE
config IBM_OCP
bool
- depends on ASH || BAMBOO || BUBINGA || CPCI405 || EBONY || EP405 || LUAN || YUCCA || OCOTEA || REDWOOD_5 || REDWOOD_6 || SYCAMORE || WALNUT
+ depends on ASH || BAMBOO || BUBINGA || CPCI405 || EBONY || EP405 || LUAN || YUCCA || OCOTEA || REDWOOD_5 || REDWOOD_6 || SYCAMORE || WALNUT || YELLOWSTONE || YOSEMITE
default y
config XILINX_OCP
diff -uprN a/arch/ppc/platforms/4xx/Makefile c/arch/ppc/platforms/4xx/Makefile
--- a/arch/ppc/platforms/4xx/Makefile 2006-01-02 21:21:10.000000000 -0600
+++ c/arch/ppc/platforms/4xx/Makefile 2006-01-13 10:09:21.000000000 -0600
@@ -14,12 +14,15 @@ obj-$(CONFIG_REDWOOD_6) += redwood6.o
obj-$(CONFIG_SYCAMORE) += sycamore.o
obj-$(CONFIG_WALNUT) += walnut.o
obj-$(CONFIG_XILINX_ML300) += xilinx_ml300.o
+obj-$(CONFIG_YELLOWSTONE) += yosemite.o
+obj-$(CONFIG_YOSEMITE) += yosemite.o
obj-$(CONFIG_405GP) += ibm405gp.o
obj-$(CONFIG_REDWOOD_5) += ibmstb4.o
obj-$(CONFIG_NP405H) += ibmnp405h.o
obj-$(CONFIG_REDWOOD_6) += ibmstbx25.o
obj-$(CONFIG_440EP) += ibm440ep.o
+obj-$(CONFIG_440GR) += ibm440ep.o
obj-$(CONFIG_440GP) += ibm440gp.o
obj-$(CONFIG_440GX) += ibm440gx.o
obj-$(CONFIG_440SP) += ibm440sp.o
diff -uprN a/arch/ppc/platforms/4xx/yosemite.c c/arch/ppc/platforms/4xx/yosemite.c
--- a/arch/ppc/platforms/4xx/yosemite.c 1969-12-31 17:00:00.000000000 -0700
+++ c/arch/ppc/platforms/4xx/yosemite.c 2006-01-15 12:17:15.000000000 -0600
@@ -0,0 +1,351 @@
+/*
+ * arch/ppc/platforms/4xx/yosemite.c
+ *
+ * Yosemite and Yellowstone board specific routines
+ *
+ * Wade Farnsworth <wfarnsworth@mvista.com>
+ * Copyright 2004 MontaVista Software Inc.
+ *
+ * John Otken <jotken@softadvances.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/config.h>
+#include <linux/stddef.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/pci.h>
+#include <linux/types.h>
+#include <linux/delay.h>
+#include <linux/initrd.h>
+#include <linux/irq.h>
+#include <linux/root_dev.h>
+#include <linux/tty.h>
+#include <linux/serial.h>
+#include <linux/serial_core.h>
+
+#include <asm/machdep.h>
+#include <asm/ocp.h>
+#include <asm/bootinfo.h>
+#include <asm/ppcboot.h>
+
+#include <syslib/ibm440gx_common.h>
+
+/*
+ * The AMCC Yosemite and Yellowstones boards share the same PC board.
+ * The Yosemite has a 440EP and USB support. The Yellowstone has a
+ * 440GR and no USB hardware. The 440EP and 440GR have the same PVR.
+ */
+#ifdef CONFIG_YELLOWSTONE
+#define BOARDNAME "440GR Yellowstone"
+#else
+#define BOARDNAME "440EP Yosemite"
+#endif
+
+
+extern bd_t __res;
+
+static struct ibm44x_clocks clocks __initdata;
+
+
+/*
+ * Yosemite external IRQ triggering/polarity settings
+ */
+unsigned char ppc4xx_uic_ext_irq_cfg[] __initdata = {
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ0: ETH0 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ1: ETH1 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ2: PCI_INTA */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ3: STTM_ALERT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ4: GPIO44 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ5: GND */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ6: GPIO45 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ7: GPIO46 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ8: GPIO47 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ9: GPIO48 */
+};
+
+
+static void __init
+yosemite_calibrate_decr(void)
+{
+ unsigned int freq;
+
+ if (mfspr(SPRN_CCR1) & CCR1_TCS)
+ freq = YOSEMITE_TMRCLK;
+ else
+ freq = clocks.cpu;
+
+ ibm44x_calibrate_decr(freq);
+}
+
+static int
+yosemite_show_cpuinfo(struct seq_file *m)
+{
+ seq_printf(m, "vendor\t\t: AMCC\n");
+ seq_printf(m, "machine\t\t: PPC" BOARDNAME "\n");
+
+ return 0;
+}
+
+static inline int
+yosemite_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char pin)
+{
+ static char pci_irq_table[][4] =
+ /*
+ * PCI IDSEL/INTPIN->INTLINE
+ * A B C D
+ */
+ {
+ { 25, 25, 25, 25 }, /* IDSEL 1 - PCI Slot 0 */
+ };
+
+ const long min_idsel = 12, max_idsel = 12, irqs_per_slot = 4;
+ return PCI_IRQ_TABLE_LOOKUP;
+}
+
+static void __init yosemite_set_emacdata(void)
+{
+ struct ocp_def *def;
+ struct ocp_func_emac_data *emacdata;
+
+ /* Set mac_addr and phy mode for each EMAC */
+
+ def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 0);
+ emacdata = def->additions;
+ memcpy(emacdata->mac_addr, __res.bi_enetaddr, 6);
+ emacdata->phy_mode = PHY_MODE_RMII;
+
+ def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 1);
+ emacdata = def->additions;
+ memcpy(emacdata->mac_addr, __res.bi_enet1addr, 6);
+ emacdata->phy_mode = PHY_MODE_RMII;
+}
+
+static int
+yosemite_exclude_device(unsigned char bus, unsigned char devfn)
+{
+ return (bus == 0 && devfn == 0);
+}
+
+#define PCI_READW(offset) \
+ (readw((void *)((u32)pci_reg_base+offset)))
+
+#define PCI_WRITEW(value, offset) \
+ (writew(value, (void *)((u32)pci_reg_base+offset)))
+
+#define PCI_WRITEL(value, offset) \
+ (writel(value, (void *)((u32)pci_reg_base+offset)))
+
+static void __init
+yosemite_setup_pci(void)
+{
+ void *pci_reg_base;
+ unsigned long memory_size;
+ memory_size = ppc_md.find_end_of_memory();
+
+ pci_reg_base = ioremap64(YOSEMITE_PCIL0_BASE, YOSEMITE_PCIL0_SIZE);
+
+ /* Enable PCI I/O, Mem, and Busmaster cycles */
+ PCI_WRITEW(PCI_READW(PCI_COMMAND) |
+ PCI_COMMAND_MEMORY |
+ PCI_COMMAND_MASTER, PCI_COMMAND);
+
+ /* Disable region first */
+ PCI_WRITEL(0, YOSEMITE_PCIL0_PMM0MA);
+
+ /* PLB starting addr: 0x00000000A0000000 */
+ PCI_WRITEL(YOSEMITE_PCI_PHY_MEM_BASE, YOSEMITE_PCIL0_PMM0LA);
+
+ /* PCI start addr, 0xA0000000 (PCI Address) */
+ PCI_WRITEL(YOSEMITE_PCI_MEM_BASE, YOSEMITE_PCIL0_PMM0PCILA);
+ PCI_WRITEL(0, YOSEMITE_PCIL0_PMM0PCIHA);
+
+ /* Enable no pre-fetch, enable region */
+ PCI_WRITEL(((0xffffffff -
+ (YOSEMITE_PCI_UPPER_MEM - YOSEMITE_PCI_MEM_BASE)) | 0x01),
+ YOSEMITE_PCIL0_PMM0MA);
+
+ /* Disable region one */
+ PCI_WRITEL(0, YOSEMITE_PCIL0_PMM1MA);
+ PCI_WRITEL(0, YOSEMITE_PCIL0_PMM1LA);
+ PCI_WRITEL(0, YOSEMITE_PCIL0_PMM1PCILA);
+ PCI_WRITEL(0, YOSEMITE_PCIL0_PMM1PCIHA);
+ PCI_WRITEL(0, YOSEMITE_PCIL0_PMM1MA);
+
+ /* Disable region two */
+ PCI_WRITEL(0, YOSEMITE_PCIL0_PMM2MA);
+ PCI_WRITEL(0, YOSEMITE_PCIL0_PMM2LA);
+ PCI_WRITEL(0, YOSEMITE_PCIL0_PMM2PCILA);
+ PCI_WRITEL(0, YOSEMITE_PCIL0_PMM2PCIHA);
+ PCI_WRITEL(0, YOSEMITE_PCIL0_PMM2MA);
+
+ /* Now configure the PCI->PLB windows, we only use PTM1
+ *
+ * For Inbound flow, set the window size to all available memory
+ * This is required because if size is smaller,
+ * then Eth/PCI DD would fail as PCI card not able to access
+ * the memory allocated by DD.
+ */
+
+ PCI_WRITEL(0, YOSEMITE_PCIL0_PTM1MS); /* disabled region 1 */
+ PCI_WRITEL(0, YOSEMITE_PCIL0_PTM1LA); /* begin of address map */
+
+ memory_size = 1 << fls(memory_size - 1);
+
+ /* Size low + Enabled */
+ PCI_WRITEL((0xffffffff - (memory_size - 1)) | 0x1, YOSEMITE_PCIL0_PTM1MS);
+
+ eieio();
+ iounmap(pci_reg_base);
+}
+
+static void __init
+yosemite_setup_hose(void)
+{
+ unsigned int bar_response, bar;
+ struct pci_controller *hose;
+
+ yosemite_setup_pci();
+
+ hose = pcibios_alloc_controller();
+
+ if (!hose)
+ return;
+
+ hose->first_busno = 0;
+ hose->last_busno = 0xff;
+
+ hose->pci_mem_offset = YOSEMITE_PCI_MEM_OFFSET;
+
+ pci_init_resource(&hose->io_resource,
+ YOSEMITE_PCI_LOWER_IO,
+ YOSEMITE_PCI_UPPER_IO,
+ IORESOURCE_IO,
+ "PCI host bridge");
+
+ pci_init_resource(&hose->mem_resources[0],
+ YOSEMITE_PCI_LOWER_MEM,
+ YOSEMITE_PCI_UPPER_MEM,
+ IORESOURCE_MEM,
+ "PCI host bridge");
+
+ ppc_md.pci_exclude_device = yosemite_exclude_device;
+
+ hose->io_space.start = YOSEMITE_PCI_LOWER_IO;
+ hose->io_space.end = YOSEMITE_PCI_UPPER_IO;
+ hose->mem_space.start = YOSEMITE_PCI_LOWER_MEM;
+ hose->mem_space.end = YOSEMITE_PCI_UPPER_MEM;
+ isa_io_base =
+ (unsigned long)ioremap64(YOSEMITE_PCI_IO_BASE, YOSEMITE_PCI_IO_SIZE);
+ hose->io_base_virt = (void *)isa_io_base;
+
+ setup_indirect_pci(hose,
+ YOSEMITE_PCI_CFGA_PLB32,
+ YOSEMITE_PCI_CFGD_PLB32);
+ hose->set_cfg_type = 1;
+
+ /* Zero config bars */
+ for (bar = PCI_BASE_ADDRESS_1; bar <= PCI_BASE_ADDRESS_2; bar += 4) {
+ early_write_config_dword(hose, hose->first_busno,
+ PCI_FUNC(hose->first_busno), bar,
+ 0x00000000);
+ early_read_config_dword(hose, hose->first_busno,
+ PCI_FUNC(hose->first_busno), bar,
+ &bar_response);
+ }
+
+ hose->last_busno = pciauto_bus_scan(hose, hose->first_busno);
+
+ ppc_md.pci_swizzle = common_swizzle;
+ ppc_md.pci_map_irq = yosemite_map_irq;
+}
+
+static void __init
+yosemite_early_serial_map(void)
+{
+ struct uart_port port;
+
+ /* Setup ioremapped serial port access */
+ memset(&port, 0, sizeof(port));
+ port.membase = ioremap64(PPC440EP_UART0_ADDR, 8);
+ port.irq = 0;
+ port.uartclk = clocks.uart0;
+ port.regshift = 0;
+ port.iotype = SERIAL_IO_MEM;
+ port.flags = ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST;
+ port.line = 0;
+
+ if (early_serial_setup(&port) != 0) {
+ printk("Early serial init of port 0 failed\n");
+ }
+
+#if defined(CONFIG_SERIAL_TEXT_DEBUG) || defined(CONFIG_KGDB)
+ /* Configure debug serial access */
+ gen550_init(0, &port);
+#endif
+
+ port.membase = ioremap64(PPC440EP_UART1_ADDR, 8);
+ port.irq = 1;
+ port.uartclk = clocks.uart1;
+ port.line = 1;
+
+ if (early_serial_setup(&port) != 0) {
+ printk("Early serial init of port 1 failed\n");
+ }
+
+#if defined(CONFIG_SERIAL_TEXT_DEBUG) || defined(CONFIG_KGDB)
+ /* Configure debug serial access */
+ gen550_init(1, &port);
+#endif
+}
+
+static void __init
+yosemite_setup_arch(void)
+{
+ yosemite_set_emacdata();
+
+ ibm440gx_get_clocks(&clocks, YOSEMITE_SYSCLK, 6 * 1843200);
+ ocp_sys_info.opb_bus_freq = clocks.opb;
+
+ /* init to some ~sane value until calibrate_delay() runs */
+ loops_per_jiffy = 50000000/HZ;
+
+ /* Setup PCI host bridge */
+ yosemite_setup_hose();
+
+#ifdef CONFIG_BLK_DEV_INITRD
+ if (initrd_start)
+ ROOT_DEV = Root_RAM0;
+ else
+#endif
+#ifdef CONFIG_ROOT_NFS
+ ROOT_DEV = Root_NFS;
+#else
+ ROOT_DEV = Root_HDA1;
+#endif
+
+ yosemite_early_serial_map();
+
+ /* Identify the system */
+ printk( "AMCC PowerPC " BOARDNAME " Platform\n" );
+}
+
+void __init platform_init(unsigned long r3, unsigned long r4,
+ unsigned long r5, unsigned long r6, unsigned long r7)
+{
+ ibm44x_platform_init(r3, r4, r5, r6, r7);
+
+ ppc_md.setup_arch = yosemite_setup_arch;
+ ppc_md.show_cpuinfo = yosemite_show_cpuinfo;
+ ppc_md.get_irq = NULL; /* Set in ppc4xx_pic_init() */
+
+ ppc_md.calibrate_decr = yosemite_calibrate_decr;
+
+#ifdef CONFIG_KGDB
+ ppc_md.early_serial_map = yosemite_early_serial_map;
+#endif
+}
diff -uprN a/arch/ppc/platforms/4xx/yosemite.h c/arch/ppc/platforms/4xx/yosemite.h
--- a/arch/ppc/platforms/4xx/yosemite.h 1969-12-31 17:00:00.000000000 -0700
+++ c/arch/ppc/platforms/4xx/yosemite.h 2006-01-15 07:38:56.000000000 -0600
@@ -0,0 +1,86 @@
+/*
+ * arch/ppc/platforms/4xx/yosemite.h
+ *
+ * Yosemite and Yellowstone board definitions
+ *
+ * Wade Farnsworth <wfarnsworth@mvista.com>
+ * Copyright 2004 MontaVista Software Inc.
+ *
+ * John Otken <jotken@softadvances.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#ifdef __KERNEL__
+#ifndef __ASM_YOSEMITE_H__
+#define __ASM_YOSEMITE_H__
+
+#include <linux/config.h>
+#include <platforms/4xx/ibm440ep.h>
+
+/* Default clock rate */
+#define YOSEMITE_TMRCLK 50000000
+#define YOSEMITE_SYSCLK 66666666
+
+/*
+ * Serial port defines
+ */
+#define RS_TABLE_SIZE 2
+
+#define UART0_IO_BASE 0xEF600300
+#define UART1_IO_BASE 0xEF600400
+
+#define BASE_BAUD 33177600/3/16
+#define UART0_INT 0
+#define UART1_INT 1
+
+#define STD_UART_OP(num) \
+ { 0, BASE_BAUD, 0, UART##num##_INT, \
+ (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST), \
+ iomem_base: UART##num##_IO_BASE, \
+ io_type: SERIAL_IO_MEM},
+
+#define SERIAL_PORT_DFNS \
+ STD_UART_OP(0) \
+ STD_UART_OP(1)
+
+/* PCI support */
+#define YOSEMITE_PCI_CFGA_PLB32 0xeec00000
+#define YOSEMITE_PCI_CFGD_PLB32 0xeec00004
+
+#define YOSEMITE_PCI_IO_BASE 0x00000000e8000000ULL
+#define YOSEMITE_PCI_IO_SIZE 0x00010000
+#define YOSEMITE_PCI_MEM_OFFSET 0x00000000
+#define YOSEMITE_PCI_PHY_MEM_BASE 0x00000000a0000000ULL
+
+#define YOSEMITE_PCI_LOWER_IO 0x00000000
+#define YOSEMITE_PCI_UPPER_IO 0x0000ffff
+#define YOSEMITE_PCI_LOWER_MEM 0xa0000000
+#define YOSEMITE_PCI_UPPER_MEM 0xafffffff
+#define YOSEMITE_PCI_MEM_BASE 0xa0000000
+
+#define YOSEMITE_PCIL0_BASE 0x00000000ef400000ULL
+#define YOSEMITE_PCIL0_SIZE 0x40
+
+#define YOSEMITE_PCIL0_PMM0LA 0x000
+#define YOSEMITE_PCIL0_PMM0MA 0x004
+#define YOSEMITE_PCIL0_PMM0PCILA 0x008
+#define YOSEMITE_PCIL0_PMM0PCIHA 0x00C
+#define YOSEMITE_PCIL0_PMM1LA 0x010
+#define YOSEMITE_PCIL0_PMM1MA 0x014
+#define YOSEMITE_PCIL0_PMM1PCILA 0x018
+#define YOSEMITE_PCIL0_PMM1PCIHA 0x01C
+#define YOSEMITE_PCIL0_PMM2LA 0x020
+#define YOSEMITE_PCIL0_PMM2MA 0x024
+#define YOSEMITE_PCIL0_PMM2PCILA 0x028
+#define YOSEMITE_PCIL0_PMM2PCIHA 0x02C
+#define YOSEMITE_PCIL0_PTM1MS 0x030
+#define YOSEMITE_PCIL0_PTM1LA 0x034
+#define YOSEMITE_PCIL0_PTM2MS 0x038
+#define YOSEMITE_PCIL0_PTM2LA 0x03C
+
+#endif /* __ASM_YOSEMITE_H__ */
+#endif /* __KERNEL__ */
diff -uprN a/arch/ppc/syslib/ibm440gx_common.c c/arch/ppc/syslib/ibm440gx_common.c
--- a/arch/ppc/syslib/ibm440gx_common.c 2006-01-02 21:21:10.000000000 -0600
+++ c/arch/ppc/syslib/ibm440gx_common.c 2006-01-13 10:09:21.000000000 -0600
@@ -34,7 +34,7 @@ void __init ibm440gx_get_clocks(struct i
u32 plld = CPR_READ(DCRN_CPR_PLLD);
u32 uart0 = SDR_READ(DCRN_SDR_UART0);
u32 uart1 = SDR_READ(DCRN_SDR_UART1);
-#ifdef CONFIG_440EP
+#if defined(CONFIG_440EP) || defined(CONFIG_440GR)
u32 uart2 = SDR_READ(DCRN_SDR_UART2);
u32 uart3 = SDR_READ(DCRN_SDR_UART3);
#endif
@@ -100,7 +100,7 @@ bypass:
p->uart1 = ser_clk;
else
p->uart1 = p->plb / __fix_zero(uart1 & 0xff, 256);
-#ifdef CONFIG_440EP
+#if defined(CONFIG_440EP) || defined(CONFIG_440GR)
if (uart2 & 0x00800000)
p->uart2 = ser_clk;
else
diff -uprN a/arch/ppc/syslib/ibm44x_common.h c/arch/ppc/syslib/ibm44x_common.h
--- a/arch/ppc/syslib/ibm44x_common.h 2006-01-02 21:21:10.000000000 -0600
+++ c/arch/ppc/syslib/ibm44x_common.h 2006-01-13 10:09:21.000000000 -0600
@@ -29,7 +29,7 @@ struct ibm44x_clocks {
unsigned int ebc; /* PerClk */
unsigned int uart0;
unsigned int uart1;
-#ifdef CONFIG_440EP
+#if defined(CONFIG_440EP) || defined(CONFIG_440GR)
unsigned int uart2;
unsigned int uart3;
#endif
diff -uprN a/arch/ppc/syslib/Makefile c/arch/ppc/syslib/Makefile
--- a/arch/ppc/syslib/Makefile 2006-01-02 21:21:10.000000000 -0600
+++ c/arch/ppc/syslib/Makefile 2006-01-13 10:09:21.000000000 -0600
@@ -12,6 +12,7 @@ obj-$(CONFIG_PPC_OCP) += ocp.o
obj-$(CONFIG_IBM_OCP) += ibm_ocp.o
obj-$(CONFIG_44x) += ibm44x_common.o
obj-$(CONFIG_440EP) += ibm440gx_common.o
+obj-$(CONFIG_440GR) += ibm440gx_common.o
obj-$(CONFIG_440GP) += ibm440gp_common.o
obj-$(CONFIG_440GX) += ibm440gx_common.o
obj-$(CONFIG_440SP) += ibm440gx_common.o ibm440sp_common.o
@@ -74,6 +75,8 @@ obj-$(CONFIG_SANDPOINT) += pci_auto.o t
obj-$(CONFIG_SBC82xx) += todc_time.o
obj-$(CONFIG_SPRUCE) += cpc700_pic.o pci_auto.o \
todc_time.o
+obj-$(CONFIG_YELLOWSTONE) += pci_auto.o
+obj-$(CONFIG_YOSEMITE) += pci_auto.o
obj-$(CONFIG_8260) += m8260_setup.o pq2_devices.o pq2_sys.o \
ppc_sys.o
obj-$(CONFIG_PCI_8260) += m82xx_pci.o pci_auto.o
diff -uprN a/include/asm-ppc/ibm44x.h c/include/asm-ppc/ibm44x.h
--- a/include/asm-ppc/ibm44x.h 2006-01-02 21:21:10.000000000 -0600
+++ c/include/asm-ppc/ibm44x.h 2006-01-13 10:09:21.000000000 -0600
@@ -44,7 +44,7 @@
#elif defined(CONFIG_440SPE)
#define UART0_PHYS_ERPN 4
#define UART0_PHYS_IO_BASE 0xf0000200
-#elif defined(CONFIG_440EP)
+#elif defined(CONFIG_440EP) || defined(CONFIG_440GR)
#define UART0_PHYS_IO_BASE 0xe0000000
#else
#define UART0_PHYS_ERPN 1
@@ -69,7 +69,7 @@
#define PPC44x_PCICFG_PAGE 0x0000000c00000000ULL
#define PPC44x_PCIIO_PAGE PPC44x_PCICFG_PAGE
#define PPC44x_PCIMEM_PAGE 0x0000000d00000000ULL
-#elif defined(CONFIG_440EP)
+#elif defined(CONFIG_440EP) || defined(CONFIG_440GR)
#define PPC44x_IO_PAGE 0x0000000000000000ULL
#define PPC44x_PCICFG_PAGE 0x0000000000000000ULL
#define PPC44x_PCIIO_PAGE PPC44x_PCICFG_PAGE
@@ -95,7 +95,7 @@
#define PPC44x_PCI2CFG_HI 0x2ec00007UL
#define PPC44x_PCIMEM_LO 0x80000000UL
#define PPC44x_PCIMEM_HI 0xdfffffffUL
-#elif defined(CONFIG_440EP)
+#elif defined(CONFIG_440EP) || defined(CONFIG_440GR)
#define PPC44x_IO_LO 0xef500000UL
#define PPC44x_IO_HI 0xefffffffUL
#define PPC44x_PCI0CFG_LO 0xeec00000UL
@@ -179,7 +179,7 @@
#define DCRN_SDR_UART0 0x0120
#define DCRN_SDR_UART1 0x0121
-#ifdef CONFIG_440EP
+#if defined(CONFIG_440EP) || defined(CONFIG_440GR)
#define DCRN_SDR_UART2 0x0122
#define DCRN_SDR_UART3 0x0123
#define DCRN_SDR_CUST0 0x4000
@@ -202,7 +202,7 @@
#define DCRNCAP_DMA_SG 1 /* have DMA scatter/gather capability */
#define DCRN_MAL_BASE 0x180
-#ifdef CONFIG_440EP
+#if defined(CONFIG_440EP) || defined(CONFIG_440GR)
#define DCRN_DMA2P40_BASE 0x300
#define DCRN_DMA2P41_BASE 0x308
#define DCRN_DMA2P42_BASE 0x310
diff -uprN a/include/asm-ppc/ibm4xx.h c/include/asm-ppc/ibm4xx.h
--- a/include/asm-ppc/ibm4xx.h 2006-01-02 21:21:10.000000000 -0600
+++ c/include/asm-ppc/ibm4xx.h 2006-01-13 10:09:21.000000000 -0600
@@ -105,6 +105,10 @@ void ppc4xx_init(unsigned long r3, unsig
#include <platforms/4xx/ocotea.h>
#endif
+#if defined(CONFIG_YELLOWSTONE) || defined(CONFIG_YOSEMITE)
+#include <platforms/4xx/yosemite.h>
+#endif
+
#ifndef __ASSEMBLY__
#ifdef CONFIG_40x
/*
^ permalink raw reply
* Re: [PATCH] powerpc: Add support for the MPC83xx watchdog
From: Marcelo Tosatti @ 2006-01-16 22:41 UTC (permalink / raw)
To: Kumar Gala
Cc: Andrew Morton, dave, linux-kernel, iinuxppc-embedded,
linuxppc-dev, wim
In-Reply-To: <Pine.LNX.4.44.0601131618020.26648-100000@gate.crashing.org>
> +static unsigned long wdt_is_open;
> +static spinlock_t wdt_spinlock;
> +
> +static void mpc83xx_wdt_keepalive(void)
> +{
> + /* Ping the WDT */
> + spin_lock(&wdt_spinlock);
> + out_be16(&wd_base->swsrr, 0x556c);
> + out_be16(&wd_base->swsrr, 0xaa39);
> + spin_unlock(&wdt_spinlock);
> +}
> +
> +static ssize_t mpc83xx_wdt_write(struct file * file, const char __user * buf,
> + size_t count, loff_t * ppos)
> +{
> + if(count)
> + mpc83xx_wdt_keepalive();
> + return count;
> +}
> +
> +static int mpc83xx_wdt_open(struct inode * inode, struct file * file)
> +{
> + u32 tmp = SWCRR_SWEN;
> + if (test_and_set_bit(0, &wdt_is_open))
> + return -EBUSY;
Hi Kumar,
What do you need the spinlock for if the device can't be opened
by more than one process?
^ permalink raw reply
* [Patch 2/3] Add Yosemite Platform defconfig
From: John Otken @ 2006-01-17 0:44 UTC (permalink / raw)
To: linuxppc-embedded
Add Yosemite Platform (AMCC 440EP) defconfig
Signed-off-by: John Otken <jotken@softadvances.com>
diff -uprN a/arch/ppc/configs/yosemite_defconfig c/arch/ppc/configs/yosemite_defconfig
--- a/arch/ppc/configs/yosemite_defconfig 1969-12-31 17:00:00.000000000 -0700
+++ c/arch/ppc/configs/yosemite_defconfig 2006-01-15 07:56:29.000000000 -0600
@@ -0,0 +1,1062 @@
+#
+# Automatically generated make config: don't edit
+# Linux kernel version: 2.6.15
+# Sun Jan 15 07:48:26 2006
+#
+CONFIG_MMU=y
+CONFIG_GENERIC_HARDIRQS=y
+CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_PPC=y
+CONFIG_PPC32=y
+CONFIG_GENERIC_NVRAM=y
+CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
+CONFIG_ARCH_MAY_HAVE_PC_FDC=y
+
+#
+# Code maturity level options
+#
+CONFIG_EXPERIMENTAL=y
+CONFIG_CLEAN_COMPILE=y
+CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
+
+#
+# General setup
+#
+CONFIG_LOCALVERSION=""
+CONFIG_LOCALVERSION_AUTO=y
+CONFIG_SWAP=y
+CONFIG_SYSVIPC=y
+# CONFIG_POSIX_MQUEUE is not set
+# CONFIG_BSD_PROCESS_ACCT is not set
+CONFIG_SYSCTL=y
+# CONFIG_AUDIT is not set
+# CONFIG_HOTPLUG is not set
+CONFIG_KOBJECT_UEVENT=y
+# CONFIG_IKCONFIG is not set
+CONFIG_INITRAMFS_SOURCE=""
+# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
+CONFIG_EMBEDDED=y
+CONFIG_KALLSYMS=y
+# CONFIG_KALLSYMS_ALL is not set
+# CONFIG_KALLSYMS_EXTRA_PASS is not set
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+CONFIG_BASE_FULL=y
+CONFIG_FUTEX=y
+CONFIG_EPOLL=y
+CONFIG_SHMEM=y
+CONFIG_CC_ALIGN_FUNCTIONS=0
+CONFIG_CC_ALIGN_LABELS=0
+CONFIG_CC_ALIGN_LOOPS=0
+CONFIG_CC_ALIGN_JUMPS=0
+# CONFIG_TINY_SHMEM is not set
+CONFIG_BASE_SMALL=0
+
+#
+# Loadable module support
+#
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_MODULE_FORCE_UNLOAD is not set
+CONFIG_OBSOLETE_MODPARM=y
+# CONFIG_MODVERSIONS is not set
+# CONFIG_MODULE_SRCVERSION_ALL is not set
+CONFIG_KMOD=y
+
+#
+# Block layer
+#
+# CONFIG_LBD is not set
+
+#
+# IO Schedulers
+#
+CONFIG_IOSCHED_NOOP=y
+CONFIG_IOSCHED_AS=y
+CONFIG_IOSCHED_DEADLINE=y
+CONFIG_IOSCHED_CFQ=y
+CONFIG_DEFAULT_AS=y
+# CONFIG_DEFAULT_DEADLINE is not set
+# CONFIG_DEFAULT_CFQ is not set
+# CONFIG_DEFAULT_NOOP is not set
+CONFIG_DEFAULT_IOSCHED="anticipatory"
+
+#
+# Processor
+#
+# CONFIG_6xx is not set
+# CONFIG_40x is not set
+CONFIG_44x=y
+# CONFIG_POWER3 is not set
+# CONFIG_POWER4 is not set
+# CONFIG_8xx is not set
+# CONFIG_E200 is not set
+# CONFIG_E500 is not set
+CONFIG_PPC_FPU=y
+CONFIG_BOOKE=y
+CONFIG_PTE_64BIT=y
+CONFIG_PHYS_64BIT=y
+# CONFIG_MATH_EMULATION is not set
+# CONFIG_KEXEC is not set
+# CONFIG_CPU_FREQ is not set
+CONFIG_4xx=y
+CONFIG_WANT_EARLY_SERIAL=y
+
+#
+# IBM 4xx options
+#
+# CONFIG_BAMBOO is not set
+# CONFIG_EBONY is not set
+# CONFIG_LUAN is not set
+# CONFIG_YUCCA is not set
+# CONFIG_OCOTEA is not set
+# CONFIG_YELLOWSTONE is not set
+CONFIG_YOSEMITE=y
+CONFIG_440EP=y
+CONFIG_440=y
+CONFIG_440_FPU=y
+CONFIG_IBM440EP_ERR42=y
+CONFIG_IBM_OCP=y
+# CONFIG_PPC4xx_DMA is not set
+CONFIG_PPC_GEN550=y
+CONFIG_NOT_COHERENT_CACHE=y
+
+#
+# Platform options
+#
+# CONFIG_PC_KEYBOARD is not set
+# CONFIG_HIGHMEM is not set
+# CONFIG_HZ_100 is not set
+CONFIG_HZ_250=y
+# CONFIG_HZ_1000 is not set
+CONFIG_HZ=250
+CONFIG_PREEMPT_NONE=y
+# CONFIG_PREEMPT_VOLUNTARY is not set
+# CONFIG_PREEMPT is not set
+CONFIG_SELECT_MEMORY_MODEL=y
+CONFIG_FLATMEM_MANUAL=y
+# CONFIG_DISCONTIGMEM_MANUAL is not set
+# CONFIG_SPARSEMEM_MANUAL is not set
+CONFIG_FLATMEM=y
+CONFIG_FLAT_NODE_MEM_MAP=y
+# CONFIG_SPARSEMEM_STATIC is not set
+CONFIG_SPLIT_PTLOCK_CPUS=4
+CONFIG_BINFMT_ELF=y
+# CONFIG_BINFMT_MISC is not set
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE="ip=on"
+CONFIG_SECCOMP=y
+CONFIG_ISA_DMA_API=y
+
+#
+# Bus options
+#
+# CONFIG_PPC_I8259 is not set
+CONFIG_PPC_INDIRECT_PCI=y
+CONFIG_PCI=y
+CONFIG_PCI_DOMAINS=y
+# CONFIG_PCI_LEGACY_PROC is not set
+# CONFIG_PCI_DEBUG is not set
+
+#
+# PCCARD (PCMCIA/CardBus) support
+#
+# CONFIG_PCCARD is not set
+
+#
+# Advanced setup
+#
+# CONFIG_ADVANCED_OPTIONS is not set
+
+#
+# Default settings for advanced configuration options are used
+#
+CONFIG_HIGHMEM_START=0xfe000000
+CONFIG_LOWMEM_SIZE=0x30000000
+CONFIG_KERNEL_START=0xc0000000
+CONFIG_TASK_SIZE=0x80000000
+CONFIG_CONSISTENT_START=0xff100000
+CONFIG_CONSISTENT_SIZE=0x00200000
+CONFIG_BOOT_LOAD=0x01000000
+
+#
+# Networking
+#
+CONFIG_NET=y
+
+#
+# Networking options
+#
+CONFIG_PACKET=y
+# CONFIG_PACKET_MMAP is not set
+CONFIG_UNIX=y
+# CONFIG_NET_KEY is not set
+CONFIG_INET=y
+# CONFIG_IP_MULTICAST is not set
+# CONFIG_IP_ADVANCED_ROUTER is not set
+CONFIG_IP_FIB_HASH=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+# 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_SYN_COOKIES is not set
+# CONFIG_INET_AH is not set
+# CONFIG_INET_ESP is not set
+# CONFIG_INET_IPCOMP is not set
+# CONFIG_INET_TUNNEL is not set
+CONFIG_INET_DIAG=y
+CONFIG_INET_TCP_DIAG=y
+# CONFIG_TCP_CONG_ADVANCED is not set
+CONFIG_TCP_CONG_BIC=y
+
+#
+# IP: Virtual Server Configuration
+#
+# CONFIG_IP_VS is not set
+# CONFIG_IPV6 is not set
+CONFIG_NETFILTER=y
+# CONFIG_NETFILTER_DEBUG is not set
+
+#
+# Core Netfilter Configuration
+#
+# CONFIG_NETFILTER_NETLINK is not set
+# CONFIG_NF_CONNTRACK is not set
+
+#
+# IP: Netfilter Configuration
+#
+# CONFIG_IP_NF_CONNTRACK is not set
+# CONFIG_IP_NF_QUEUE is not set
+# CONFIG_IP_NF_IPTABLES is not set
+# CONFIG_IP_NF_ARPTABLES is not set
+
+#
+# DCCP Configuration (EXPERIMENTAL)
+#
+# CONFIG_IP_DCCP is not set
+
+#
+# SCTP Configuration (EXPERIMENTAL)
+#
+# CONFIG_IP_SCTP is not set
+# CONFIG_ATM is not set
+# CONFIG_BRIDGE is not set
+# CONFIG_VLAN_8021Q is not set
+# CONFIG_DECNET is not set
+# CONFIG_LLC2 is not set
+# CONFIG_IPX is not set
+# CONFIG_ATALK is not set
+# CONFIG_X25 is not set
+# CONFIG_LAPB is not set
+# CONFIG_NET_DIVERT is not set
+# CONFIG_ECONET is not set
+# CONFIG_WAN_ROUTER is not set
+
+#
+# QoS and/or fair queueing
+#
+# CONFIG_NET_SCHED is not set
+
+#
+# Network testing
+#
+# CONFIG_NET_PKTGEN is not set
+# CONFIG_HAMRADIO is not set
+# CONFIG_IRDA is not set
+# CONFIG_BT is not set
+# CONFIG_IEEE80211 is not set
+
+#
+# Device Drivers
+#
+
+#
+# Generic Driver Options
+#
+# CONFIG_STANDALONE is not set
+CONFIG_PREVENT_FIRMWARE_BUILD=y
+# CONFIG_FW_LOADER is not set
+# CONFIG_DEBUG_DRIVER is not set
+
+#
+# Connector - unified userspace <-> kernelspace linker
+#
+# CONFIG_CONNECTOR is not set
+
+#
+# Memory Technology Devices (MTD)
+#
+# CONFIG_MTD is not set
+
+#
+# Parallel port support
+#
+# CONFIG_PARPORT is not set
+
+#
+# Plug and Play support
+#
+
+#
+# Block devices
+#
+# CONFIG_BLK_DEV_FD is not set
+# CONFIG_BLK_CPQ_DA is not set
+# CONFIG_BLK_CPQ_CISS_DA is not set
+# CONFIG_BLK_DEV_DAC960 is not set
+# CONFIG_BLK_DEV_UMEM is not set
+# CONFIG_BLK_DEV_COW_COMMON is not set
+# CONFIG_BLK_DEV_LOOP is not set
+# CONFIG_BLK_DEV_NBD is not set
+# CONFIG_BLK_DEV_SX8 is not set
+# CONFIG_BLK_DEV_UB is not set
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=16
+CONFIG_BLK_DEV_RAM_SIZE=4096
+CONFIG_BLK_DEV_INITRD=y
+# CONFIG_CDROM_PKTCDVD is not set
+# CONFIG_ATA_OVER_ETH is not set
+
+#
+# ATA/ATAPI/MFM/RLL support
+#
+CONFIG_IDE=y
+CONFIG_BLK_DEV_IDE=y
+
+#
+# Please see Documentation/ide.txt for help/info on IDE drives
+#
+# CONFIG_BLK_DEV_IDE_SATA is not set
+CONFIG_BLK_DEV_IDEDISK=y
+# CONFIG_IDEDISK_MULTI_MODE is not set
+# CONFIG_BLK_DEV_IDECD is not set
+# CONFIG_BLK_DEV_IDETAPE is not set
+# CONFIG_BLK_DEV_IDEFLOPPY is not set
+# CONFIG_BLK_DEV_IDESCSI is not set
+# CONFIG_IDE_TASK_IOCTL is not set
+
+#
+# IDE chipset support/bugfixes
+#
+CONFIG_IDE_GENERIC=y
+CONFIG_BLK_DEV_IDEPCI=y
+# CONFIG_IDEPCI_SHARE_IRQ is not set
+# CONFIG_BLK_DEV_OFFBOARD is not set
+# CONFIG_BLK_DEV_GENERIC is not set
+# CONFIG_BLK_DEV_OPTI621 is not set
+# CONFIG_BLK_DEV_SL82C105 is not set
+CONFIG_BLK_DEV_IDEDMA_PCI=y
+# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
+# CONFIG_IDEDMA_PCI_AUTO is not set
+# CONFIG_BLK_DEV_AEC62XX is not set
+# CONFIG_BLK_DEV_ALI15X3 is not set
+# CONFIG_BLK_DEV_AMD74XX is not set
+CONFIG_BLK_DEV_CMD64X=y
+# CONFIG_BLK_DEV_TRIFLEX is not set
+# CONFIG_BLK_DEV_CY82C693 is not set
+# CONFIG_BLK_DEV_CS5520 is not set
+# CONFIG_BLK_DEV_CS5530 is not set
+# CONFIG_BLK_DEV_HPT34X is not set
+# CONFIG_BLK_DEV_HPT366 is not set
+# CONFIG_BLK_DEV_SC1200 is not set
+# CONFIG_BLK_DEV_PIIX is not set
+# CONFIG_BLK_DEV_IT821X is not set
+# CONFIG_BLK_DEV_NS87415 is not set
+# CONFIG_BLK_DEV_PDC202XX_OLD is not set
+# CONFIG_BLK_DEV_PDC202XX_NEW is not set
+# CONFIG_BLK_DEV_SVWKS is not set
+# CONFIG_BLK_DEV_SIIMAGE is not set
+# CONFIG_BLK_DEV_SLC90E66 is not set
+# CONFIG_BLK_DEV_TRM290 is not set
+# CONFIG_BLK_DEV_VIA82CXXX is not set
+# CONFIG_IDE_ARM is not set
+CONFIG_BLK_DEV_IDEDMA=y
+# CONFIG_IDEDMA_IVB is not set
+# CONFIG_IDEDMA_AUTO is not set
+# CONFIG_BLK_DEV_HD is not set
+
+#
+# SCSI device support
+#
+# CONFIG_RAID_ATTRS is not set
+CONFIG_SCSI=y
+CONFIG_SCSI_PROC_FS=y
+
+#
+# SCSI support type (disk, tape, CD-ROM)
+#
+CONFIG_BLK_DEV_SD=y
+# CONFIG_CHR_DEV_ST is not set
+# CONFIG_CHR_DEV_OSST is not set
+# CONFIG_BLK_DEV_SR is not set
+# CONFIG_CHR_DEV_SG is not set
+# CONFIG_CHR_DEV_SCH is not set
+
+#
+# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
+#
+# CONFIG_SCSI_MULTI_LUN is not set
+# CONFIG_SCSI_CONSTANTS is not set
+# CONFIG_SCSI_LOGGING is not set
+
+#
+# SCSI Transport Attributes
+#
+CONFIG_SCSI_SPI_ATTRS=y
+# CONFIG_SCSI_FC_ATTRS is not set
+# CONFIG_SCSI_ISCSI_ATTRS is not set
+# CONFIG_SCSI_SAS_ATTRS is not set
+
+#
+# SCSI low-level drivers
+#
+# CONFIG_ISCSI_TCP is not set
+# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
+# CONFIG_SCSI_3W_9XXX is not set
+# CONFIG_SCSI_ACARD is not set
+# CONFIG_SCSI_AACRAID is not set
+# CONFIG_SCSI_AIC7XXX is not set
+# CONFIG_SCSI_AIC7XXX_OLD is not set
+# CONFIG_SCSI_AIC79XX is not set
+# CONFIG_SCSI_DPT_I2O is not set
+# CONFIG_MEGARAID_NEWGEN is not set
+# CONFIG_MEGARAID_LEGACY is not set
+# CONFIG_MEGARAID_SAS is not set
+# CONFIG_SCSI_SATA is not set
+# CONFIG_SCSI_BUSLOGIC is not set
+# CONFIG_SCSI_DMX3191D is not set
+# CONFIG_SCSI_EATA is not set
+# CONFIG_SCSI_FUTURE_DOMAIN is not set
+# CONFIG_SCSI_GDTH is not set
+# CONFIG_SCSI_IPS is not set
+# CONFIG_SCSI_INITIO is not set
+# CONFIG_SCSI_INIA100 is not set
+CONFIG_SCSI_SYM53C8XX_2=y
+CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
+CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
+CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
+# CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set
+# CONFIG_SCSI_IPR is not set
+# CONFIG_SCSI_QLOGIC_FC is not set
+# CONFIG_SCSI_QLOGIC_1280 is not set
+CONFIG_SCSI_QLA2XXX=y
+# CONFIG_SCSI_QLA21XX is not set
+# CONFIG_SCSI_QLA22XX is not set
+# CONFIG_SCSI_QLA2300 is not set
+# CONFIG_SCSI_QLA2322 is not set
+# CONFIG_SCSI_QLA6312 is not set
+# CONFIG_SCSI_QLA24XX is not set
+# CONFIG_SCSI_LPFC is not set
+# CONFIG_SCSI_DC395x is not set
+# CONFIG_SCSI_DC390T is not set
+# CONFIG_SCSI_NSP32 is not set
+# CONFIG_SCSI_DEBUG is not set
+
+#
+# Multi-device support (RAID and LVM)
+#
+# CONFIG_MD is not set
+
+#
+# Fusion MPT device support
+#
+# CONFIG_FUSION is not set
+# CONFIG_FUSION_SPI is not set
+# CONFIG_FUSION_FC is not set
+# CONFIG_FUSION_SAS is not set
+
+#
+# IEEE 1394 (FireWire) support
+#
+# CONFIG_IEEE1394 is not set
+
+#
+# I2O device support
+#
+# CONFIG_I2O is not set
+
+#
+# Macintosh device drivers
+#
+# CONFIG_WINDFARM is not set
+
+#
+# Network device support
+#
+CONFIG_NETDEVICES=y
+# CONFIG_DUMMY is not set
+# CONFIG_BONDING is not set
+# CONFIG_EQUALIZER is not set
+# CONFIG_TUN is not set
+
+#
+# ARCnet devices
+#
+# CONFIG_ARCNET is not set
+
+#
+# PHY device support
+#
+# CONFIG_PHYLIB is not set
+
+#
+# Ethernet (10 or 100Mbit)
+#
+CONFIG_NET_ETHERNET=y
+CONFIG_MII=y
+# CONFIG_HAPPYMEAL is not set
+# CONFIG_SUNGEM is not set
+# CONFIG_CASSINI is not set
+# CONFIG_NET_VENDOR_3COM is not set
+
+#
+# Tulip family network device support
+#
+# CONFIG_NET_TULIP is not set
+# CONFIG_HP100 is not set
+CONFIG_IBM_EMAC=y
+CONFIG_IBM_EMAC_RXB=64
+CONFIG_IBM_EMAC_TXB=8
+CONFIG_IBM_EMAC_POLL_WEIGHT=32
+CONFIG_IBM_EMAC_RX_COPY_THRESHOLD=256
+CONFIG_IBM_EMAC_RX_SKB_HEADROOM=0
+# CONFIG_IBM_EMAC_PHY_RX_CLK_FIX is not set
+# CONFIG_IBM_EMAC_DEBUG is not set
+CONFIG_IBM_EMAC_ZMII=y
+CONFIG_NET_PCI=y
+# CONFIG_PCNET32 is not set
+# CONFIG_AMD8111_ETH is not set
+# CONFIG_ADAPTEC_STARFIRE is not set
+# CONFIG_B44 is not set
+# CONFIG_FORCEDETH is not set
+# CONFIG_DGRS is not set
+# CONFIG_EEPRO100 is not set
+# CONFIG_E100 is not set
+# CONFIG_FEALNX is not set
+# CONFIG_NATSEMI is not set
+# CONFIG_NE2K_PCI is not set
+# CONFIG_8139CP is not set
+CONFIG_8139TOO=y
+# CONFIG_8139TOO_PIO is not set
+# CONFIG_8139TOO_TUNE_TWISTER is not set
+# CONFIG_8139TOO_8129 is not set
+# CONFIG_8139_OLD_RX_RESET is not set
+# CONFIG_SIS900 is not set
+# CONFIG_EPIC100 is not set
+# CONFIG_SUNDANCE is not set
+# CONFIG_TLAN is not set
+# CONFIG_VIA_RHINE is not set
+
+#
+# Ethernet (1000 Mbit)
+#
+# CONFIG_ACENIC is not set
+# CONFIG_DL2K is not set
+# CONFIG_E1000 is not set
+# CONFIG_NS83820 is not set
+# CONFIG_HAMACHI is not set
+# CONFIG_YELLOWFIN is not set
+# CONFIG_R8169 is not set
+# CONFIG_SIS190 is not set
+# CONFIG_SKGE is not set
+# CONFIG_SK98LIN is not set
+# CONFIG_VIA_VELOCITY is not set
+# CONFIG_TIGON3 is not set
+# CONFIG_BNX2 is not set
+
+#
+# Ethernet (10000 Mbit)
+#
+# CONFIG_CHELSIO_T1 is not set
+# CONFIG_IXGB is not set
+# CONFIG_S2IO is not set
+
+#
+# Token Ring devices
+#
+# CONFIG_TR is not set
+
+#
+# Wireless LAN (non-hamradio)
+#
+# CONFIG_NET_RADIO is not set
+
+#
+# Wan interfaces
+#
+# CONFIG_WAN is not set
+# CONFIG_FDDI is not set
+# CONFIG_HIPPI is not set
+# CONFIG_PPP is not set
+# CONFIG_SLIP is not set
+# CONFIG_NET_FC is not set
+# CONFIG_SHAPER is not set
+# CONFIG_NETCONSOLE is not set
+# CONFIG_NETPOLL is not set
+# CONFIG_NET_POLL_CONTROLLER is not set
+
+#
+# ISDN subsystem
+#
+# CONFIG_ISDN is not set
+
+#
+# Telephony Support
+#
+# CONFIG_PHONE is not set
+
+#
+# Input device support
+#
+# CONFIG_INPUT is not set
+
+#
+# Hardware I/O ports
+#
+CONFIG_SERIO=y
+# CONFIG_SERIO_I8042 is not set
+# CONFIG_SERIO_SERPORT is not set
+# CONFIG_SERIO_PCIPS2 is not set
+# CONFIG_SERIO_LIBPS2 is not set
+# CONFIG_SERIO_RAW is not set
+# CONFIG_GAMEPORT is not set
+
+#
+# Character devices
+#
+# CONFIG_VT is not set
+# CONFIG_SERIAL_NONSTANDARD is not set
+
+#
+# Serial drivers
+#
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=4
+CONFIG_SERIAL_8250_EXTENDED=y
+# CONFIG_SERIAL_8250_MANY_PORTS is not set
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+# CONFIG_SERIAL_8250_DETECT_IRQ is not set
+# CONFIG_SERIAL_8250_RSA is not set
+
+#
+# Non-8250 serial port support
+#
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+# CONFIG_SERIAL_JSM is not set
+CONFIG_UNIX98_PTYS=y
+CONFIG_LEGACY_PTYS=y
+CONFIG_LEGACY_PTY_COUNT=256
+
+#
+# IPMI
+#
+# CONFIG_IPMI_HANDLER is not set
+
+#
+# Watchdog Cards
+#
+# CONFIG_WATCHDOG is not set
+# CONFIG_NVRAM is not set
+# CONFIG_GEN_RTC is not set
+# CONFIG_DTLK is not set
+# CONFIG_R3964 is not set
+# CONFIG_APPLICOM is not set
+
+#
+# Ftape, the floppy tape device driver
+#
+# CONFIG_AGP is not set
+# CONFIG_DRM is not set
+# CONFIG_RAW_DRIVER is not set
+
+#
+# TPM devices
+#
+# CONFIG_TCG_TPM is not set
+# CONFIG_TELCLOCK is not set
+
+#
+# I2C support
+#
+# CONFIG_I2C is not set
+
+#
+# Dallas's 1-wire bus
+#
+# CONFIG_W1 is not set
+
+#
+# Hardware Monitoring support
+#
+CONFIG_HWMON=y
+# CONFIG_HWMON_VID is not set
+# CONFIG_HWMON_DEBUG_CHIP is not set
+
+#
+# Misc devices
+#
+
+#
+# Multimedia Capabilities Port drivers
+#
+
+#
+# Multimedia devices
+#
+# CONFIG_VIDEO_DEV is not set
+
+#
+# Digital Video Broadcasting Devices
+#
+# CONFIG_DVB is not set
+
+#
+# Graphics support
+#
+# CONFIG_FB is not set
+
+#
+# Sound
+#
+# CONFIG_SOUND is not set
+
+#
+# USB support
+#
+CONFIG_USB_ARCH_HAS_HCD=y
+CONFIG_USB_ARCH_HAS_OHCI=y
+CONFIG_USB=y
+# CONFIG_USB_DEBUG is not set
+
+#
+# Miscellaneous USB options
+#
+# CONFIG_USB_DEVICEFS is not set
+# CONFIG_USB_BANDWIDTH is not set
+# CONFIG_USB_DYNAMIC_MINORS is not set
+# CONFIG_USB_OTG is not set
+
+#
+# USB Host Controller Drivers
+#
+# CONFIG_USB_EHCI_HCD is not set
+# CONFIG_USB_ISP116X_HCD is not set
+CONFIG_USB_OHCI_HCD=y
+# CONFIG_USB_OHCI_BIG_ENDIAN is not set
+CONFIG_USB_OHCI_LITTLE_ENDIAN=y
+# CONFIG_USB_UHCI_HCD is not set
+# CONFIG_USB_SL811_HCD is not set
+
+#
+# USB Device Class drivers
+#
+# CONFIG_USB_ACM is not set
+# CONFIG_USB_PRINTER is not set
+
+#
+# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
+#
+
+#
+# may also be needed; see USB_STORAGE Help for more information
+#
+CONFIG_USB_STORAGE=y
+# CONFIG_USB_STORAGE_DEBUG is not set
+# CONFIG_USB_STORAGE_DATAFAB is not set
+# CONFIG_USB_STORAGE_FREECOM is not set
+# CONFIG_USB_STORAGE_ISD200 is not set
+# CONFIG_USB_STORAGE_DPCM is not set
+# CONFIG_USB_STORAGE_USBAT is not set
+# CONFIG_USB_STORAGE_SDDR09 is not set
+# CONFIG_USB_STORAGE_SDDR55 is not set
+# CONFIG_USB_STORAGE_JUMPSHOT is not set
+
+#
+# USB Input Devices
+#
+# CONFIG_USB_HID is not set
+
+#
+# USB HID Boot Protocol drivers
+#
+
+#
+# USB Imaging devices
+#
+# CONFIG_USB_MDC800 is not set
+# CONFIG_USB_MICROTEK is not set
+
+#
+# USB Multimedia devices
+#
+# CONFIG_USB_DABUSB is not set
+
+#
+# Video4Linux support is needed for USB Multimedia device support
+#
+
+#
+# USB Network Adapters
+#
+# CONFIG_USB_CATC is not set
+# CONFIG_USB_KAWETH is not set
+CONFIG_USB_PEGASUS=y
+# CONFIG_USB_RTL8150 is not set
+# CONFIG_USB_USBNET is not set
+CONFIG_USB_MON=y
+
+#
+# USB port drivers
+#
+
+#
+# USB Serial Converter support
+#
+# CONFIG_USB_SERIAL is not set
+
+#
+# USB Miscellaneous drivers
+#
+# CONFIG_USB_EMI62 is not set
+# CONFIG_USB_EMI26 is not set
+# CONFIG_USB_AUERSWALD is not set
+# CONFIG_USB_RIO500 is not set
+# CONFIG_USB_LEGOTOWER is not set
+# CONFIG_USB_LCD is not set
+# CONFIG_USB_LED is not set
+# CONFIG_USB_CYTHERM is not set
+# CONFIG_USB_PHIDGETKIT is not set
+# CONFIG_USB_PHIDGETSERVO is not set
+# CONFIG_USB_IDMOUSE is not set
+# CONFIG_USB_LD is not set
+
+#
+# USB DSL modem support
+#
+
+#
+# USB Gadget Support
+#
+CONFIG_USB_GADGET=y
+# CONFIG_USB_GADGET_DEBUG_FILES is not set
+CONFIG_USB_GADGET_SELECTED=y
+CONFIG_USB_GADGET_NET2280=y
+CONFIG_USB_NET2280=y
+# CONFIG_USB_GADGET_PXA2XX is not set
+# CONFIG_USB_GADGET_GOKU is not set
+# CONFIG_USB_GADGET_LH7A40X is not set
+# CONFIG_USB_GADGET_OMAP is not set
+# CONFIG_USB_GADGET_DUMMY_HCD is not set
+CONFIG_USB_GADGET_DUALSPEED=y
+CONFIG_USB_ZERO=y
+# CONFIG_USB_ETH is not set
+# CONFIG_USB_GADGETFS is not set
+# CONFIG_USB_FILE_STORAGE is not set
+# CONFIG_USB_G_SERIAL is not set
+
+#
+# MMC/SD Card support
+#
+# CONFIG_MMC is not set
+
+#
+# InfiniBand support
+#
+# CONFIG_INFINIBAND is not set
+
+#
+# SN Devices
+#
+
+#
+# File systems
+#
+CONFIG_EXT2_FS=y
+# CONFIG_EXT2_FS_XATTR is not set
+# CONFIG_EXT2_FS_XIP is not set
+# CONFIG_EXT3_FS is not set
+# CONFIG_JBD is not set
+# CONFIG_REISERFS_FS is not set
+# CONFIG_JFS_FS is not set
+# CONFIG_FS_POSIX_ACL is not set
+# CONFIG_XFS_FS is not set
+# CONFIG_MINIX_FS is not set
+# CONFIG_ROMFS_FS is not set
+CONFIG_INOTIFY=y
+# CONFIG_QUOTA is not set
+CONFIG_DNOTIFY=y
+# CONFIG_AUTOFS_FS is not set
+# CONFIG_AUTOFS4_FS is not set
+# CONFIG_FUSE_FS is not set
+
+#
+# CD-ROM/DVD Filesystems
+#
+# CONFIG_ISO9660_FS is not set
+# CONFIG_UDF_FS is not set
+
+#
+# DOS/FAT/NT Filesystems
+#
+CONFIG_FAT_FS=y
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_FAT_DEFAULT_CODEPAGE=437
+CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
+# CONFIG_NTFS_FS is not set
+
+#
+# Pseudo filesystems
+#
+CONFIG_PROC_FS=y
+CONFIG_PROC_KCORE=y
+CONFIG_SYSFS=y
+CONFIG_TMPFS=y
+# CONFIG_HUGETLB_PAGE is not set
+CONFIG_RAMFS=y
+# CONFIG_RELAYFS_FS is not set
+
+#
+# Miscellaneous filesystems
+#
+# CONFIG_ADFS_FS 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_BFS_FS is not set
+# CONFIG_EFS_FS is not set
+# CONFIG_CRAMFS is not set
+# CONFIG_VXFS_FS is not set
+# CONFIG_HPFS_FS is not set
+# CONFIG_QNX4FS_FS is not set
+# CONFIG_SYSV_FS is not set
+# CONFIG_UFS_FS is not set
+
+#
+# Network File Systems
+#
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3=y
+# CONFIG_NFS_V3_ACL is not set
+# CONFIG_NFS_V4 is not set
+# CONFIG_NFS_DIRECTIO is not set
+# CONFIG_NFSD is not set
+CONFIG_ROOT_NFS=y
+CONFIG_LOCKD=y
+CONFIG_LOCKD_V4=y
+CONFIG_NFS_COMMON=y
+CONFIG_SUNRPC=y
+# CONFIG_RPCSEC_GSS_KRB5 is not set
+# CONFIG_RPCSEC_GSS_SPKM3 is not set
+# CONFIG_SMB_FS is not set
+# CONFIG_CIFS is not set
+# CONFIG_NCP_FS is not set
+# CONFIG_CODA_FS is not set
+# CONFIG_AFS_FS is not set
+# CONFIG_9P_FS is not set
+
+#
+# Partition Types
+#
+# CONFIG_PARTITION_ADVANCED is not set
+CONFIG_MSDOS_PARTITION=y
+
+#
+# Native Language Support
+#
+CONFIG_NLS=y
+CONFIG_NLS_DEFAULT="iso8859-1"
+CONFIG_NLS_CODEPAGE_437=y
+# CONFIG_NLS_CODEPAGE_737 is not set
+# CONFIG_NLS_CODEPAGE_775 is not set
+# CONFIG_NLS_CODEPAGE_850 is not set
+# CONFIG_NLS_CODEPAGE_852 is not set
+# CONFIG_NLS_CODEPAGE_855 is not set
+# CONFIG_NLS_CODEPAGE_857 is not set
+# CONFIG_NLS_CODEPAGE_860 is not set
+# CONFIG_NLS_CODEPAGE_861 is not set
+# CONFIG_NLS_CODEPAGE_862 is not set
+# CONFIG_NLS_CODEPAGE_863 is not set
+# CONFIG_NLS_CODEPAGE_864 is not set
+# CONFIG_NLS_CODEPAGE_865 is not set
+# CONFIG_NLS_CODEPAGE_866 is not set
+# CONFIG_NLS_CODEPAGE_869 is not set
+# CONFIG_NLS_CODEPAGE_936 is not set
+# CONFIG_NLS_CODEPAGE_950 is not set
+# CONFIG_NLS_CODEPAGE_932 is not set
+# CONFIG_NLS_CODEPAGE_949 is not set
+# CONFIG_NLS_CODEPAGE_874 is not set
+# CONFIG_NLS_ISO8859_8 is not set
+# CONFIG_NLS_CODEPAGE_1250 is not set
+# CONFIG_NLS_CODEPAGE_1251 is not set
+# CONFIG_NLS_ASCII is not set
+CONFIG_NLS_ISO8859_1=y
+# CONFIG_NLS_ISO8859_2 is not set
+# CONFIG_NLS_ISO8859_3 is not set
+# CONFIG_NLS_ISO8859_4 is not set
+# CONFIG_NLS_ISO8859_5 is not set
+# CONFIG_NLS_ISO8859_6 is not set
+# CONFIG_NLS_ISO8859_7 is not set
+# CONFIG_NLS_ISO8859_9 is not set
+# CONFIG_NLS_ISO8859_13 is not set
+# CONFIG_NLS_ISO8859_14 is not set
+# CONFIG_NLS_ISO8859_15 is not set
+# CONFIG_NLS_KOI8_R is not set
+# CONFIG_NLS_KOI8_U is not set
+# CONFIG_NLS_UTF8 is not set
+
+#
+# Library routines
+#
+# CONFIG_CRC_CCITT is not set
+# CONFIG_CRC16 is not set
+CONFIG_CRC32=y
+# CONFIG_LIBCRC32C is not set
+# CONFIG_PROFILING is not set
+
+#
+# Kernel hacking
+#
+# CONFIG_PRINTK_TIME is not set
+CONFIG_DEBUG_KERNEL=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_DETECT_SOFTLOCKUP=y
+# CONFIG_SCHEDSTATS is not set
+# CONFIG_DEBUG_SLAB is not set
+# CONFIG_DEBUG_SPINLOCK is not set
+# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
+# CONFIG_DEBUG_KOBJECT is not set
+CONFIG_DEBUG_INFO=y
+# CONFIG_DEBUG_FS is not set
+# CONFIG_DEBUG_VM is not set
+# CONFIG_RCU_TORTURE_TEST is not set
+# CONFIG_KGDB is not set
+# CONFIG_XMON is not set
+CONFIG_BDI_SWITCH=y
+# CONFIG_SERIAL_TEXT_DEBUG is not set
+CONFIG_PPC_OCP=y
+
+#
+# Security options
+#
+# CONFIG_KEYS is not set
+# CONFIG_SECURITY is not set
+
+#
+# Cryptographic options
+#
+# CONFIG_CRYPTO is not set
+
+#
+# Hardware crypto devices
+#
^ permalink raw reply
* [Patch 3/3] Add Yellowstone Platform defconfig
From: John Otken @ 2006-01-17 0:45 UTC (permalink / raw)
To: linuxppc-embedded
Add Yellowstone Platform (AMCC 440GR) defconfig
Signed-off-by: John Otken <jotken@softadvances.com>
diff -uprN a/arch/ppc/configs/yellowstone_defconfig c/arch/ppc/configs/yellowstone_defconfig
--- a/arch/ppc/configs/yellowstone_defconfig 1969-12-31 17:00:00.000000000 -0700
+++ c/arch/ppc/configs/yellowstone_defconfig 2006-01-15 08:03:11.000000000 -0600
@@ -0,0 +1,824 @@
+#
+# Automatically generated make config: don't edit
+# Linux kernel version: 2.6.15
+# Sun Jan 15 07:57:26 2006
+#
+CONFIG_MMU=y
+CONFIG_GENERIC_HARDIRQS=y
+CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_PPC=y
+CONFIG_PPC32=y
+CONFIG_GENERIC_NVRAM=y
+CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
+CONFIG_ARCH_MAY_HAVE_PC_FDC=y
+
+#
+# Code maturity level options
+#
+CONFIG_EXPERIMENTAL=y
+CONFIG_CLEAN_COMPILE=y
+CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
+
+#
+# General setup
+#
+CONFIG_LOCALVERSION=""
+CONFIG_LOCALVERSION_AUTO=y
+CONFIG_SWAP=y
+CONFIG_SYSVIPC=y
+# CONFIG_POSIX_MQUEUE is not set
+# CONFIG_BSD_PROCESS_ACCT is not set
+CONFIG_SYSCTL=y
+# CONFIG_AUDIT is not set
+# CONFIG_HOTPLUG is not set
+CONFIG_KOBJECT_UEVENT=y
+# CONFIG_IKCONFIG is not set
+CONFIG_INITRAMFS_SOURCE=""
+# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
+CONFIG_EMBEDDED=y
+CONFIG_KALLSYMS=y
+# CONFIG_KALLSYMS_ALL is not set
+# CONFIG_KALLSYMS_EXTRA_PASS is not set
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+CONFIG_BASE_FULL=y
+CONFIG_FUTEX=y
+CONFIG_EPOLL=y
+CONFIG_SHMEM=y
+CONFIG_CC_ALIGN_FUNCTIONS=0
+CONFIG_CC_ALIGN_LABELS=0
+CONFIG_CC_ALIGN_LOOPS=0
+CONFIG_CC_ALIGN_JUMPS=0
+# CONFIG_TINY_SHMEM is not set
+CONFIG_BASE_SMALL=0
+
+#
+# Loadable module support
+#
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_MODULE_FORCE_UNLOAD is not set
+CONFIG_OBSOLETE_MODPARM=y
+# CONFIG_MODVERSIONS is not set
+# CONFIG_MODULE_SRCVERSION_ALL is not set
+CONFIG_KMOD=y
+
+#
+# Block layer
+#
+# CONFIG_LBD is not set
+
+#
+# IO Schedulers
+#
+CONFIG_IOSCHED_NOOP=y
+CONFIG_IOSCHED_AS=y
+CONFIG_IOSCHED_DEADLINE=y
+CONFIG_IOSCHED_CFQ=y
+CONFIG_DEFAULT_AS=y
+# CONFIG_DEFAULT_DEADLINE is not set
+# CONFIG_DEFAULT_CFQ is not set
+# CONFIG_DEFAULT_NOOP is not set
+CONFIG_DEFAULT_IOSCHED="anticipatory"
+
+#
+# Processor
+#
+# CONFIG_6xx is not set
+# CONFIG_40x is not set
+CONFIG_44x=y
+# CONFIG_POWER3 is not set
+# CONFIG_POWER4 is not set
+# CONFIG_8xx is not set
+# CONFIG_E200 is not set
+# CONFIG_E500 is not set
+CONFIG_PPC_FPU=y
+CONFIG_BOOKE=y
+CONFIG_PTE_64BIT=y
+CONFIG_PHYS_64BIT=y
+# CONFIG_MATH_EMULATION is not set
+# CONFIG_KEXEC is not set
+# CONFIG_CPU_FREQ is not set
+CONFIG_4xx=y
+CONFIG_WANT_EARLY_SERIAL=y
+
+#
+# IBM 4xx options
+#
+# CONFIG_BAMBOO is not set
+# CONFIG_EBONY is not set
+# CONFIG_LUAN is not set
+# CONFIG_YUCCA is not set
+# CONFIG_OCOTEA is not set
+CONFIG_YELLOWSTONE=y
+# CONFIG_YOSEMITE is not set
+CONFIG_440GR=y
+CONFIG_440=y
+CONFIG_IBM440EP_ERR42=y
+CONFIG_IBM_OCP=y
+# CONFIG_PPC4xx_DMA is not set
+CONFIG_PPC_GEN550=y
+CONFIG_NOT_COHERENT_CACHE=y
+
+#
+# Platform options
+#
+# CONFIG_PC_KEYBOARD is not set
+# CONFIG_HIGHMEM is not set
+# CONFIG_HZ_100 is not set
+CONFIG_HZ_250=y
+# CONFIG_HZ_1000 is not set
+CONFIG_HZ=250
+CONFIG_PREEMPT_NONE=y
+# CONFIG_PREEMPT_VOLUNTARY is not set
+# CONFIG_PREEMPT is not set
+CONFIG_SELECT_MEMORY_MODEL=y
+CONFIG_FLATMEM_MANUAL=y
+# CONFIG_DISCONTIGMEM_MANUAL is not set
+# CONFIG_SPARSEMEM_MANUAL is not set
+CONFIG_FLATMEM=y
+CONFIG_FLAT_NODE_MEM_MAP=y
+# CONFIG_SPARSEMEM_STATIC is not set
+CONFIG_SPLIT_PTLOCK_CPUS=4
+CONFIG_BINFMT_ELF=y
+# CONFIG_BINFMT_MISC is not set
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE="ip=on"
+CONFIG_SECCOMP=y
+CONFIG_ISA_DMA_API=y
+
+#
+# Bus options
+#
+# CONFIG_PPC_I8259 is not set
+CONFIG_PPC_INDIRECT_PCI=y
+CONFIG_PCI=y
+CONFIG_PCI_DOMAINS=y
+# CONFIG_PCI_LEGACY_PROC is not set
+# CONFIG_PCI_DEBUG is not set
+
+#
+# PCCARD (PCMCIA/CardBus) support
+#
+# CONFIG_PCCARD is not set
+
+#
+# Advanced setup
+#
+# CONFIG_ADVANCED_OPTIONS is not set
+
+#
+# Default settings for advanced configuration options are used
+#
+CONFIG_HIGHMEM_START=0xfe000000
+CONFIG_LOWMEM_SIZE=0x30000000
+CONFIG_KERNEL_START=0xc0000000
+CONFIG_TASK_SIZE=0x80000000
+CONFIG_CONSISTENT_START=0xff100000
+CONFIG_CONSISTENT_SIZE=0x00200000
+CONFIG_BOOT_LOAD=0x01000000
+
+#
+# Networking
+#
+CONFIG_NET=y
+
+#
+# Networking options
+#
+CONFIG_PACKET=y
+# CONFIG_PACKET_MMAP is not set
+CONFIG_UNIX=y
+# CONFIG_NET_KEY is not set
+CONFIG_INET=y
+# CONFIG_IP_MULTICAST is not set
+# CONFIG_IP_ADVANCED_ROUTER is not set
+CONFIG_IP_FIB_HASH=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+# 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_SYN_COOKIES is not set
+# CONFIG_INET_AH is not set
+# CONFIG_INET_ESP is not set
+# CONFIG_INET_IPCOMP is not set
+# CONFIG_INET_TUNNEL is not set
+CONFIG_INET_DIAG=y
+CONFIG_INET_TCP_DIAG=y
+# CONFIG_TCP_CONG_ADVANCED is not set
+CONFIG_TCP_CONG_BIC=y
+
+#
+# IP: Virtual Server Configuration
+#
+# CONFIG_IP_VS is not set
+# CONFIG_IPV6 is not set
+CONFIG_NETFILTER=y
+# CONFIG_NETFILTER_DEBUG is not set
+
+#
+# Core Netfilter Configuration
+#
+# CONFIG_NETFILTER_NETLINK is not set
+# CONFIG_NF_CONNTRACK is not set
+
+#
+# IP: Netfilter Configuration
+#
+# CONFIG_IP_NF_CONNTRACK is not set
+# CONFIG_IP_NF_QUEUE is not set
+# CONFIG_IP_NF_IPTABLES is not set
+# CONFIG_IP_NF_ARPTABLES is not set
+
+#
+# DCCP Configuration (EXPERIMENTAL)
+#
+# CONFIG_IP_DCCP is not set
+
+#
+# SCTP Configuration (EXPERIMENTAL)
+#
+# CONFIG_IP_SCTP is not set
+# CONFIG_ATM is not set
+# CONFIG_BRIDGE is not set
+# CONFIG_VLAN_8021Q is not set
+# CONFIG_DECNET is not set
+# CONFIG_LLC2 is not set
+# CONFIG_IPX is not set
+# CONFIG_ATALK is not set
+# CONFIG_X25 is not set
+# CONFIG_LAPB is not set
+# CONFIG_NET_DIVERT is not set
+# CONFIG_ECONET is not set
+# CONFIG_WAN_ROUTER is not set
+
+#
+# QoS and/or fair queueing
+#
+# CONFIG_NET_SCHED is not set
+
+#
+# Network testing
+#
+# CONFIG_NET_PKTGEN is not set
+# CONFIG_HAMRADIO is not set
+# CONFIG_IRDA is not set
+# CONFIG_BT is not set
+# CONFIG_IEEE80211 is not set
+
+#
+# Device Drivers
+#
+
+#
+# Generic Driver Options
+#
+# CONFIG_STANDALONE is not set
+CONFIG_PREVENT_FIRMWARE_BUILD=y
+# CONFIG_FW_LOADER is not set
+# CONFIG_DEBUG_DRIVER is not set
+
+#
+# Connector - unified userspace <-> kernelspace linker
+#
+# CONFIG_CONNECTOR is not set
+
+#
+# Memory Technology Devices (MTD)
+#
+# CONFIG_MTD is not set
+
+#
+# Parallel port support
+#
+# CONFIG_PARPORT is not set
+
+#
+# Plug and Play support
+#
+
+#
+# Block devices
+#
+# CONFIG_BLK_DEV_FD is not set
+# CONFIG_BLK_CPQ_DA is not set
+# CONFIG_BLK_CPQ_CISS_DA is not set
+# CONFIG_BLK_DEV_DAC960 is not set
+# CONFIG_BLK_DEV_UMEM is not set
+# CONFIG_BLK_DEV_COW_COMMON is not set
+# CONFIG_BLK_DEV_LOOP is not set
+# CONFIG_BLK_DEV_NBD is not set
+# CONFIG_BLK_DEV_SX8 is not set
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=16
+CONFIG_BLK_DEV_RAM_SIZE=4096
+CONFIG_BLK_DEV_INITRD=y
+# CONFIG_CDROM_PKTCDVD is not set
+# CONFIG_ATA_OVER_ETH is not set
+
+#
+# ATA/ATAPI/MFM/RLL support
+#
+CONFIG_IDE=y
+CONFIG_BLK_DEV_IDE=y
+
+#
+# Please see Documentation/ide.txt for help/info on IDE drives
+#
+# CONFIG_BLK_DEV_IDE_SATA is not set
+CONFIG_BLK_DEV_IDEDISK=y
+# CONFIG_IDEDISK_MULTI_MODE is not set
+# CONFIG_BLK_DEV_IDECD is not set
+# CONFIG_BLK_DEV_IDETAPE is not set
+# CONFIG_BLK_DEV_IDEFLOPPY is not set
+# CONFIG_IDE_TASK_IOCTL is not set
+
+#
+# IDE chipset support/bugfixes
+#
+CONFIG_IDE_GENERIC=y
+CONFIG_BLK_DEV_IDEPCI=y
+# CONFIG_IDEPCI_SHARE_IRQ is not set
+# CONFIG_BLK_DEV_OFFBOARD is not set
+# CONFIG_BLK_DEV_GENERIC is not set
+# CONFIG_BLK_DEV_OPTI621 is not set
+# CONFIG_BLK_DEV_SL82C105 is not set
+CONFIG_BLK_DEV_IDEDMA_PCI=y
+# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
+# CONFIG_IDEDMA_PCI_AUTO is not set
+# CONFIG_BLK_DEV_AEC62XX is not set
+# CONFIG_BLK_DEV_ALI15X3 is not set
+# CONFIG_BLK_DEV_AMD74XX is not set
+CONFIG_BLK_DEV_CMD64X=y
+# CONFIG_BLK_DEV_TRIFLEX is not set
+# CONFIG_BLK_DEV_CY82C693 is not set
+# CONFIG_BLK_DEV_CS5520 is not set
+# CONFIG_BLK_DEV_CS5530 is not set
+# CONFIG_BLK_DEV_HPT34X is not set
+# CONFIG_BLK_DEV_HPT366 is not set
+# CONFIG_BLK_DEV_SC1200 is not set
+# CONFIG_BLK_DEV_PIIX is not set
+# CONFIG_BLK_DEV_IT821X is not set
+# CONFIG_BLK_DEV_NS87415 is not set
+# CONFIG_BLK_DEV_PDC202XX_OLD is not set
+# CONFIG_BLK_DEV_PDC202XX_NEW is not set
+# CONFIG_BLK_DEV_SVWKS is not set
+# CONFIG_BLK_DEV_SIIMAGE is not set
+# CONFIG_BLK_DEV_SLC90E66 is not set
+# CONFIG_BLK_DEV_TRM290 is not set
+# CONFIG_BLK_DEV_VIA82CXXX is not set
+# CONFIG_IDE_ARM is not set
+CONFIG_BLK_DEV_IDEDMA=y
+# CONFIG_IDEDMA_IVB is not set
+# CONFIG_IDEDMA_AUTO is not set
+# CONFIG_BLK_DEV_HD is not set
+
+#
+# SCSI device support
+#
+# CONFIG_RAID_ATTRS is not set
+# CONFIG_SCSI is not set
+
+#
+# Multi-device support (RAID and LVM)
+#
+# CONFIG_MD is not set
+
+#
+# Fusion MPT device support
+#
+# CONFIG_FUSION is not set
+
+#
+# IEEE 1394 (FireWire) support
+#
+# CONFIG_IEEE1394 is not set
+
+#
+# I2O device support
+#
+# CONFIG_I2O is not set
+
+#
+# Macintosh device drivers
+#
+# CONFIG_WINDFARM is not set
+
+#
+# Network device support
+#
+CONFIG_NETDEVICES=y
+# CONFIG_DUMMY is not set
+# CONFIG_BONDING is not set
+# CONFIG_EQUALIZER is not set
+# CONFIG_TUN is not set
+
+#
+# ARCnet devices
+#
+# CONFIG_ARCNET is not set
+
+#
+# PHY device support
+#
+# CONFIG_PHYLIB is not set
+
+#
+# Ethernet (10 or 100Mbit)
+#
+CONFIG_NET_ETHERNET=y
+CONFIG_MII=y
+# CONFIG_HAPPYMEAL is not set
+# CONFIG_SUNGEM is not set
+# CONFIG_CASSINI is not set
+# CONFIG_NET_VENDOR_3COM is not set
+
+#
+# Tulip family network device support
+#
+# CONFIG_NET_TULIP is not set
+# CONFIG_HP100 is not set
+CONFIG_IBM_EMAC=y
+CONFIG_IBM_EMAC_RXB=64
+CONFIG_IBM_EMAC_TXB=8
+CONFIG_IBM_EMAC_POLL_WEIGHT=32
+CONFIG_IBM_EMAC_RX_COPY_THRESHOLD=256
+CONFIG_IBM_EMAC_RX_SKB_HEADROOM=0
+# CONFIG_IBM_EMAC_PHY_RX_CLK_FIX is not set
+# CONFIG_IBM_EMAC_DEBUG is not set
+CONFIG_IBM_EMAC_ZMII=y
+CONFIG_NET_PCI=y
+# CONFIG_PCNET32 is not set
+# CONFIG_AMD8111_ETH is not set
+# CONFIG_ADAPTEC_STARFIRE is not set
+# CONFIG_B44 is not set
+# CONFIG_FORCEDETH is not set
+# CONFIG_DGRS is not set
+# CONFIG_EEPRO100 is not set
+# CONFIG_E100 is not set
+# CONFIG_FEALNX is not set
+# CONFIG_NATSEMI is not set
+# CONFIG_NE2K_PCI is not set
+# CONFIG_8139CP is not set
+CONFIG_8139TOO=y
+# CONFIG_8139TOO_PIO is not set
+# CONFIG_8139TOO_TUNE_TWISTER is not set
+# CONFIG_8139TOO_8129 is not set
+# CONFIG_8139_OLD_RX_RESET is not set
+# CONFIG_SIS900 is not set
+# CONFIG_EPIC100 is not set
+# CONFIG_SUNDANCE is not set
+# CONFIG_TLAN is not set
+# CONFIG_VIA_RHINE is not set
+
+#
+# Ethernet (1000 Mbit)
+#
+# CONFIG_ACENIC is not set
+# CONFIG_DL2K is not set
+# CONFIG_E1000 is not set
+# CONFIG_NS83820 is not set
+# CONFIG_HAMACHI is not set
+# CONFIG_YELLOWFIN is not set
+# CONFIG_R8169 is not set
+# CONFIG_SIS190 is not set
+# CONFIG_SKGE is not set
+# CONFIG_SK98LIN is not set
+# CONFIG_VIA_VELOCITY is not set
+# CONFIG_TIGON3 is not set
+# CONFIG_BNX2 is not set
+
+#
+# Ethernet (10000 Mbit)
+#
+# CONFIG_CHELSIO_T1 is not set
+# CONFIG_IXGB is not set
+# CONFIG_S2IO is not set
+
+#
+# Token Ring devices
+#
+# CONFIG_TR is not set
+
+#
+# Wireless LAN (non-hamradio)
+#
+# CONFIG_NET_RADIO is not set
+
+#
+# Wan interfaces
+#
+# CONFIG_WAN is not set
+# CONFIG_FDDI is not set
+# CONFIG_HIPPI is not set
+# CONFIG_PPP is not set
+# CONFIG_SLIP is not set
+# CONFIG_SHAPER is not set
+# CONFIG_NETCONSOLE is not set
+# CONFIG_NETPOLL is not set
+# CONFIG_NET_POLL_CONTROLLER is not set
+
+#
+# ISDN subsystem
+#
+# CONFIG_ISDN is not set
+
+#
+# Telephony Support
+#
+# CONFIG_PHONE is not set
+
+#
+# Input device support
+#
+# CONFIG_INPUT is not set
+
+#
+# Hardware I/O ports
+#
+CONFIG_SERIO=y
+# CONFIG_SERIO_I8042 is not set
+# CONFIG_SERIO_SERPORT is not set
+# CONFIG_SERIO_PCIPS2 is not set
+# CONFIG_SERIO_LIBPS2 is not set
+# CONFIG_SERIO_RAW is not set
+# CONFIG_GAMEPORT is not set
+
+#
+# Character devices
+#
+# CONFIG_VT is not set
+# CONFIG_SERIAL_NONSTANDARD is not set
+
+#
+# Serial drivers
+#
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=4
+CONFIG_SERIAL_8250_EXTENDED=y
+# CONFIG_SERIAL_8250_MANY_PORTS is not set
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+# CONFIG_SERIAL_8250_DETECT_IRQ is not set
+# CONFIG_SERIAL_8250_RSA is not set
+
+#
+# Non-8250 serial port support
+#
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+# CONFIG_SERIAL_JSM is not set
+CONFIG_UNIX98_PTYS=y
+CONFIG_LEGACY_PTYS=y
+CONFIG_LEGACY_PTY_COUNT=256
+
+#
+# IPMI
+#
+# CONFIG_IPMI_HANDLER is not set
+
+#
+# Watchdog Cards
+#
+# CONFIG_WATCHDOG is not set
+# CONFIG_NVRAM is not set
+# CONFIG_GEN_RTC is not set
+# CONFIG_DTLK is not set
+# CONFIG_R3964 is not set
+# CONFIG_APPLICOM is not set
+
+#
+# Ftape, the floppy tape device driver
+#
+# CONFIG_AGP is not set
+# CONFIG_DRM is not set
+# CONFIG_RAW_DRIVER is not set
+
+#
+# TPM devices
+#
+# CONFIG_TCG_TPM is not set
+# CONFIG_TELCLOCK is not set
+
+#
+# I2C support
+#
+# CONFIG_I2C is not set
+
+#
+# Dallas's 1-wire bus
+#
+# CONFIG_W1 is not set
+
+#
+# Hardware Monitoring support
+#
+CONFIG_HWMON=y
+# CONFIG_HWMON_VID is not set
+# CONFIG_HWMON_DEBUG_CHIP is not set
+
+#
+# Misc devices
+#
+
+#
+# Multimedia Capabilities Port drivers
+#
+
+#
+# Multimedia devices
+#
+# CONFIG_VIDEO_DEV is not set
+
+#
+# Digital Video Broadcasting Devices
+#
+# CONFIG_DVB is not set
+
+#
+# Graphics support
+#
+# CONFIG_FB is not set
+
+#
+# Sound
+#
+# CONFIG_SOUND is not set
+
+#
+# USB support
+#
+CONFIG_USB_ARCH_HAS_HCD=y
+CONFIG_USB_ARCH_HAS_OHCI=y
+# CONFIG_USB is not set
+
+#
+# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
+#
+
+#
+# USB Gadget Support
+#
+# CONFIG_USB_GADGET is not set
+
+#
+# MMC/SD Card support
+#
+# CONFIG_MMC is not set
+
+#
+# InfiniBand support
+#
+# CONFIG_INFINIBAND is not set
+
+#
+# SN Devices
+#
+
+#
+# File systems
+#
+CONFIG_EXT2_FS=y
+# CONFIG_EXT2_FS_XATTR is not set
+# CONFIG_EXT2_FS_XIP is not set
+# CONFIG_EXT3_FS is not set
+# CONFIG_JBD is not set
+# CONFIG_REISERFS_FS is not set
+# CONFIG_JFS_FS is not set
+# CONFIG_FS_POSIX_ACL is not set
+# CONFIG_XFS_FS is not set
+# CONFIG_MINIX_FS is not set
+# CONFIG_ROMFS_FS is not set
+CONFIG_INOTIFY=y
+# CONFIG_QUOTA is not set
+CONFIG_DNOTIFY=y
+# CONFIG_AUTOFS_FS is not set
+# CONFIG_AUTOFS4_FS is not set
+# CONFIG_FUSE_FS is not set
+
+#
+# CD-ROM/DVD Filesystems
+#
+# CONFIG_ISO9660_FS is not set
+# CONFIG_UDF_FS is not set
+
+#
+# DOS/FAT/NT Filesystems
+#
+# CONFIG_MSDOS_FS is not set
+# CONFIG_VFAT_FS is not set
+# CONFIG_NTFS_FS is not set
+
+#
+# Pseudo filesystems
+#
+CONFIG_PROC_FS=y
+CONFIG_PROC_KCORE=y
+CONFIG_SYSFS=y
+CONFIG_TMPFS=y
+# CONFIG_HUGETLB_PAGE is not set
+CONFIG_RAMFS=y
+# CONFIG_RELAYFS_FS is not set
+
+#
+# Miscellaneous filesystems
+#
+# CONFIG_ADFS_FS 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_BFS_FS is not set
+# CONFIG_EFS_FS is not set
+# CONFIG_CRAMFS is not set
+# CONFIG_VXFS_FS is not set
+# CONFIG_HPFS_FS is not set
+# CONFIG_QNX4FS_FS is not set
+# CONFIG_SYSV_FS is not set
+# CONFIG_UFS_FS is not set
+
+#
+# Network File Systems
+#
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3=y
+# CONFIG_NFS_V3_ACL is not set
+# CONFIG_NFS_V4 is not set
+# CONFIG_NFS_DIRECTIO is not set
+# CONFIG_NFSD is not set
+CONFIG_ROOT_NFS=y
+CONFIG_LOCKD=y
+CONFIG_LOCKD_V4=y
+CONFIG_NFS_COMMON=y
+CONFIG_SUNRPC=y
+# CONFIG_RPCSEC_GSS_KRB5 is not set
+# CONFIG_RPCSEC_GSS_SPKM3 is not set
+# CONFIG_SMB_FS is not set
+# CONFIG_CIFS is not set
+# CONFIG_NCP_FS is not set
+# CONFIG_CODA_FS is not set
+# CONFIG_AFS_FS is not set
+# CONFIG_9P_FS is not set
+
+#
+# Partition Types
+#
+# CONFIG_PARTITION_ADVANCED is not set
+CONFIG_MSDOS_PARTITION=y
+
+#
+# Native Language Support
+#
+# CONFIG_NLS is not set
+
+#
+# Library routines
+#
+# CONFIG_CRC_CCITT is not set
+# CONFIG_CRC16 is not set
+CONFIG_CRC32=y
+# CONFIG_LIBCRC32C is not set
+# CONFIG_PROFILING is not set
+
+#
+# Kernel hacking
+#
+# CONFIG_PRINTK_TIME is not set
+CONFIG_DEBUG_KERNEL=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_DETECT_SOFTLOCKUP=y
+# CONFIG_SCHEDSTATS is not set
+# CONFIG_DEBUG_SLAB is not set
+# CONFIG_DEBUG_SPINLOCK is not set
+# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
+# CONFIG_DEBUG_KOBJECT is not set
+CONFIG_DEBUG_INFO=y
+# CONFIG_DEBUG_FS is not set
+# CONFIG_DEBUG_VM is not set
+# CONFIG_RCU_TORTURE_TEST is not set
+# CONFIG_KGDB is not set
+# CONFIG_XMON is not set
+CONFIG_BDI_SWITCH=y
+# CONFIG_SERIAL_TEXT_DEBUG is not set
+CONFIG_PPC_OCP=y
+
+#
+# Security options
+#
+# CONFIG_KEYS is not set
+# CONFIG_SECURITY is not set
+
+#
+# Cryptographic options
+#
+# CONFIG_CRYPTO is not set
+
+#
+# Hardware crypto devices
+#
^ permalink raw reply
* Re: AGPGART driver for ArticiaS - ioremap() problem
From: Benjamin Herrenschmidt @ 2006-01-16 23:18 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <19548.1137399114@www099.gmx.net>
> Ah, okay. So at least the approach to use the Uninorth code was a step in
> the right direction. But that requires changes in the DRI and X server code,
> right?
Not you shouldn't... there are 2 different things here. One is how you
access the GART table itself. One is how you access the AGP memory (the
memory that is bound to the GART).
I'm not 100% sure what of the 2 above cases triggered an error with
ioremap, I'm not sure what approach should be used, because i don't know
what your chipset does. I would need more infos about the hw there. But
the basic idea is:
- For the GART table, you don't need to ioremap it (which is generally
a way to have it non-cacheable I suppose). You can just flush cache
entries after populating them (see uninorth_insert_memory(), it flushes
first the pages that are being inserted in the GART as AGP memory is not
cacheable neither, and at the end of the function, flushes the GART
entry proper).
- The AGP aperture itself. The main issue there is wether your chipset
makes the AGP aperture visible to the CPU or not. The Apple UniNorth one
doesn't for example, it;'s only visible to the graphic chip. That is why
the uninorth driver sets cant_use_aperture to 1. That forces the DRM to
generate AGP mappings by using the real memory pages and putting them
together into a virtual mapping instead of doing a direct mapping of the
AGP aperture on the bus. Most x86 chipsets however _can_, thus a simple
remapping of pages is enough.
Ben.
^ permalink raw reply
* Issue while linking c++ applicatiopn on Linux Power
From: Abhay Singh @ 2006-01-16 12:38 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]
Hi,
I am porting a huge c++ server application on Linux Power PC.
The compiler which I am using is IBM xlC 7.0 version. The gcc version
installed is 3.3.3.
I am using xlC for building the c++ application and shared objects, as
opposed for the gcc -fPIC option, Iam using -qpic=large for creating the
position independance code.
While linking one of out libraries, we encountered an issue like "
"relocation truncated to fit: R_PPC_LOCAL24PC
_GLOBAL_OFFSET_TABLE_+fffffffffffffffc"
Then after using the -Wl,--relax as linker option we were able to create the
shared library.
Now but during the creation of the final executable during the link time, I
am facing a similar issue like
objws/opt/dcsdblk.o(.text+0xe620): In function `os_vector<DCWFormat
const*>::reserve(unsigned int)':
: relocation truncated to fit: R_PPC_LOCAL24PC
_GLOBAL_OFFSET_TABLE_+fffffffffffffffc
objws/opt/dcsdblk.o(.text+0xe70c): In function `os_allocator<DCWFormat
const*>::allocate(unsigned int, void const*)':
: relocation truncated to fit: R_PPC_LOCAL24PC
_GLOBAL_OFFSET_TABLE_+fffffffffffffffc
objws/opt/dcsdblk.o(.text+0xe790): In function `os_vector<DCWFormat
const*>::insert(DCWFormat const**, unsigned int, DCWFormat const* const&)':
: relocation truncated to fit: R_PPC_LOCAL24PC
_GLOBAL_OFFSET_TABLE_+fffffffffffffffc
Even the Wl,--relax option is noy helping us.
I saw one small c test program as
#include <stdio.h>
char realbig[36000032] = {1,2};
int main()
{
printf ("&realbig = %#lx\n", &realbig);
}
while compiling gives the same kind of error. Although this error vanishes,
if we do a 64 bit build using option -q64 for xlC and -m64 for gcc.
Please let me know, if there is any resolution for the above described
issue.
Thanks and regards,
Abhay Kumar Singh
Oracle India Private Limited.
Tel: 91-80-51086837
[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2468 bytes --]
^ permalink raw reply
* [PATCH][UPDATE] powerpc: Add CONFIG_DEFAULT_UIMAGE to build a uImage by default for a board
From: Kumar Gala @ 2006-01-16 16:53 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Embedded boards that u-boot require a kernel image in the uImage format.
This allows a given board to specify it wants a uImage built by default.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit dc9904232f13395c8aa3a46a3cce759c82c03278
tree 7f2d49a2bfffdfb5eaae3693fb749a1243a94c1c
parent 7ba6450ca6461a19638f963af152e0b5ab00ef15
author Kumar Gala <galak@kernel.crashing.org> Mon, 16 Jan 2006 10:58:51 -0600
committer Kumar Gala <galak@kernel.crashing.org> Mon, 16 Jan 2006 10:58:51 -0600
arch/powerpc/Kconfig | 6 ++++++
arch/powerpc/Makefile | 1 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index df338c5..80d114a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -83,6 +83,12 @@ config GENERIC_TBSYNC
default y if PPC32 && SMP
default n
+config DEFAULT_UIMAGE
+ bool
+ help
+ Used to allow a board to specify it wants a uImage built by default
+ default n
+
menu "Processor support"
choice
prompt "Processor Type"
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 44dd82b..15fc3e9 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -142,6 +142,7 @@ drivers-$(CONFIG_OPROFILE) += arch/power
# Default to zImage, override when needed
defaultimage-y := zImage
defaultimage-$(CONFIG_PPC_ISERIES) := vmlinux
+defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
KBUILD_IMAGE := $(defaultimage-y)
all: $(KBUILD_IMAGE)
^ permalink raw reply related
* Re: PPC440EP/Yosemite PCI misbehavior
From: David Hawkins @ 2006-01-16 16:56 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200601151021.13798.sr@denx.de>
Hi Stefan,
> I have to admit, that PCI I/O can't have worked until now on
> Yosemite/Yellowstone. I just found a bug in
> arch/ppc/platforms/4xx/yosemite.h:
>
> -#define YOSEMITE_PCI_IO_BASE 0x00000000e0000000ULL
> +#define YOSEMITE_PCI_IO_BASE 0x00000000e8000000ULL
>
> Please give it a try and let me know if the problem is fixed.
Yes, that was it! Its all working now.
Thanks very much!
Dave
^ permalink raw reply
* RE: ppc4xx DMA fixes for simultaneous sg transfers
From: Peter Fercher @ 2006-01-16 16:33 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: 'ductusrhe'
In-Reply-To: <518B77BB6246D54D9E88FC49AFB0389D4F26BD@seskoptronicmsx.optronic.local>
[-- Attachment #1: Type: text/plain, Size: 12460 bytes --]
can somebody provide an example usage of the ppc4xx_ scatter/gather dma
library by mvista ?
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of ductusrhe
Sent: Mittwoch, 7. Dezember 2005 22:33
To: linuxppc-embedded@ozlabs.org
Subject: ppc4xx DMA fixes for simultaneous sg transfers
Linux 2.4.20 (probably 2.6 as well?)
Conclusion:
Scatter/gather DMA is not thread safe.
Background:
1. We run all four dma channels simultaneously in SG mode on the PPC440EP,
starting and stopping them in different threads.
2. Also we need to change channel configs between different transfers, i.e.
run ppc4xx_init_dma_channel() to set read or write mode.
Problem and cause:
1. All is well when running one channel at a time, but when
starting/stopping a new channel during the time another is active can - if
you are unlucky - cause problems.
Because all channels SG start/stop bits are in the same register (ASGC),
it must not be read then changed and written to the way it was done.
That can cause a channel that is just done, to start again, or a newly
started channel to stop.
The register includes a feature that can be used as a semaphore - the
read enable (mask) bits, but it was not used correctly in the code, it was
enabled for all channels in the start-up.
2. It is said in the comment of ppc4xx_init_dma_channel() that it should
only be used once in the start-up. If you comply, you will not have any
problem with it.
However, when running this for a channel when other channels are active,
can cause channels to stop or maybe never give an interrupt or false
interrupts. The method clears the entire status register, not only the bits
for the given channel.
Solution:
1. - In ppc4xx_alloc_dma_handle(), do not touch the ASGC register!
- In ppc4xx_enable_dma_sgl() and ppc4xx_disable_dma_sgl(), when setting
the ASGC register, only change the given channel.
That's done without reading the register at all, just set/clear the
enable bit of the channel to change, then set the MASK_ENABLE for the same
channel.
Probably this is the way the register was intended to be handled?
2. - In ppc4xx_init_dma_channel(), only clear the correct bits of the DMASR
register, not the whole register.
(The polarity was also not set as it's supposed to in this function,
but there exists a patch for that)
I can send a patch with our changes, that works very well and stable, but
there are many changes and not all of them in line with the current official
version of the files (we handle the sg descriptor list differently). Maybe
someone feeling for it will take a look at the changes and make them into
the real code, since the above fixes does not interfere with the usage, only
improves thread safety.
I have no idea if this has been fixed in some patch already... but I have
not seen it on this list anyway.
I'm not a regular poster, just want to help others avoid some of the
struggle when running many channels.
/Ronnie Hedlund
Our changed code:
In "ppc4xx_dma.c"
-----------------------
/*
* The comment states that this function should only be run at start-up,
and never more.
* That is unacceptable, with the fix it can be run anywhere as long as the
given channel is not running.
*/
int ppc4xx_init_dma_channel(unsigned int dmanr, ppc_dma_ch_t * p_init)
{
unsigned int status_bits[] = { DMA_CS0 | DMA_TS0 | DMA_CH0_ERR,
DMA_CS1 | DMA_TS1 | DMA_CH1_ERR,
DMA_CS2 | DMA_TS2 | DMA_CH2_ERR,
DMA_CS3 | DMA_TS3 | DMA_CH3_ERR};
unsigned int polarity;
uint32_t control = 0;
ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
DMA_MODE_READ = (unsigned long) DMA_TD; /* Peripheral to Memory */
DMA_MODE_WRITE = 0; /* Memory to Peripheral */
if (!p_init) {
printk("ppc4xx_init_dma_channel: NULL p_init\n");
return DMA_STATUS_NULL_POINTER;
}
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("ppc4xx_init_dma_channel: bad channel %d\n", dmanr);
return DMA_STATUS_BAD_CHANNEL;
}
#if DCRN_POL > 0
polarity = mfdcr(DCRN_POL);
#else
polarity = 0;
#endif
/* Setup the control register based on the values passed to
* us in p_init. Then, over-write the control register with this
* new value.
*/
control |= SET_DMA_CONTROL;
switch (dmanr) {
case 0:
/* clear all polarity signals and then "or" in new signal
levels */
polarity &= ~GET_DMA_POLARITY(0);
polarity |= p_init->polarity;
#if DCRN_POL > 0
mtdcr(DCRN_POL, polarity);
#endif
mtdcr(DCRN_DMACR0, control);
break;
case 1:
polarity &= ~GET_DMA_POLARITY(1);
polarity |= p_init->polarity;
#if DCRN_POL > 0
mtdcr(DCRN_POL, polarity);
#endif
mtdcr(DCRN_DMACR1, control);
break;
case 2:
polarity &= ~GET_DMA_POLARITY(2);
polarity |= p_init->polarity;
#if DCRN_POL > 0
mtdcr(DCRN_POL, polarity);
#endif
mtdcr(DCRN_DMACR2, control);
break;
case 3:
polarity &= ~GET_DMA_POLARITY(3);
polarity |= p_init->polarity;
#if DCRN_POL > 0
mtdcr(DCRN_POL, polarity);
#endif
mtdcr(DCRN_DMACR3, control);
break;
default:
return DMA_STATUS_BAD_CHANNEL;
}
/* save these values in our dma channel structure */
memcpy(p_dma_ch, p_init, sizeof (ppc_dma_ch_t));
/*
* The peripheral width values written in the control register are:
* PW_8 0
* PW_16 1
* PW_32 2
* PW_64 3
*
* Since the DMA count register takes the number of "transfers",
* we need to divide the count sent to us in certain
* functions by the appropriate number. It so happens that our
* right shift value is equal to the peripheral width value.
*/
p_dma_ch->shift = p_init->pwidth;
/*
* Save the control word for easy access.
*/
p_dma_ch->control = control;
/*
* clear status register for the channel
* only TS, CS and RI needs to be cleared.
*/
mtdcr(DCRN_DMASR, status_bits[dmanr]);
return DMA_STATUS_GOOD;
}
In "ppc4xx_sgdma.c"
-----------------------
int
ppc4xx_alloc_dma_handle(sgl_handle_t * phandle, unsigned int mode, unsigned
int dmanr)
{
sgl_list_info_t *psgl = NULL;
ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
//uint32_t sg_command;
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("ppc4xx_alloc_dma_handle: invalid channel 0x%x\n",
dmanr);
return DMA_STATUS_BAD_CHANNEL;
}
if (!phandle) {
printk("ppc4xx_alloc_dma_handle: null handle pointer\n");
return DMA_STATUS_NULL_POINTER;
}
/* Get memory for the listinfo struct */
psgl = kmalloc(sizeof(sgl_list_info_t), GFP_KERNEL);
if (psgl == NULL) {
*phandle = (sgl_handle_t) NULL;
return DMA_STATUS_OUT_OF_MEMORY;
}
memset(psgl, 0, sizeof(sgl_list_info_t));
/* dma_addr is unused now */
psgl->dmanr = dmanr;
/*
* Modify and save the control word. These words will be
* written to each sgl descriptor. The DMA engine then
* loads this control word into the control register
* every time it reads a new descriptor.
*/
psgl->control = p_dma_ch->control;
/* Clear all mode bits */
psgl->control &= ~(DMA_TM_MASK | DMA_TD);
/* Save control word and mode */
psgl->control |= (mode | DMA_CE_ENABLE);
/* PPC Errata? DMA else ignore count on first in list */
psgl->control |= SET_DMA_TCE(1);
/* In MM mode, we must set ETD/TCE */
if (mode == DMA_MODE_MM)
psgl->control |= DMA_ETD_OUTPUT | DMA_TCE_ENABLE;
if (p_dma_ch->int_enable) {
/* Enable channel interrupt */
psgl->control |= DMA_CIE_ENABLE;
} else {
psgl->control &= ~DMA_CIE_ENABLE;
}
/* we must not touch the SGC, it can cause problems to other
channels! */
psgl->sgl_control = SG_LINK;
if (p_dma_ch->int_enable) {
if (p_dma_ch->tce_enable)
{
/* reuse as Terminal Count Interrupt Enable on all
descr. */
psgl->sgl_control |= SG_TCI_ENABLE;
}
psgl->sgl_control |= SG_ERI_ENABLE | SG_ETI_ENABLE;
}
*phandle = (sgl_handle_t) psgl;
return DMA_STATUS_GOOD;
}
void
ppc4xx_enable_dma_sgl(sgl_handle_t handle)
{
sgl_list_info_t *psgl = (sgl_list_info_t *) handle;
ppc_dma_ch_t *p_dma_ch;
uint32_t sg_command;
if (!handle) {
printk("ppc4xx_enable_dma_sgl: null handle\n");
return;
} else if (psgl->dmanr > (MAX_PPC4xx_DMA_CHANNELS - 1)) {
printk("ppc4xx_enable_dma_sgl: bad channel in handle %d\n",
psgl->dmanr);
return;
} else if (!psgl->phead) {
printk("ppc4xx_enable_dma_sgl: sg list empty\n");
return;
}
p_dma_ch = &dma_channels[psgl->dmanr];
psgl->ptail->control_count &= ~SG_LINK; /* make this the last
dscrptr */
if (p_dma_ch->int_enable)
{
/* Require Terminal Count interrupt on last */
psgl->ptail->control_count |= SG_TCI_ENABLE;
}
/* No more changes to tail object allowed */
//dma_cache_wback((unsigned long)psgl->ptail, sizeof(ppc_sgl_t));
dma_cache_wback_inv((unsigned long)psgl->ptail, sizeof(ppc_sgl_t));
ppc4xx_set_sg_addr(psgl->dmanr, virt_to_phys(psgl->phead));
sg_command = 0;
switch (psgl->dmanr) {
case 0:
sg_command = SSG0_ENABLE | SSG0_MASK_ENABLE;
break;
case 1:
sg_command = SSG1_ENABLE | SSG1_MASK_ENABLE;
break;
case 2:
sg_command = SSG2_ENABLE | SSG2_MASK_ENABLE;
break;
case 3:
sg_command = SSG3_ENABLE | SSG3_MASK_ENABLE;
break;
default:
printk("ppc4xx_enable_dma_sgl: bad channel: %d\n",
psgl->dmanr);
}
mtdcr(DCRN_ASGC, sg_command); /* start transfer */
}
void
ppc4xx_disable_dma_sgl(sgl_handle_t handle)
{
sgl_list_info_t *psgl = (sgl_list_info_t *) handle;
uint32_t sg_command;
if (!handle) {
printk("ppc4xx_disable_dma_sgl: null handle\n");
return;
} else if (psgl->dmanr > (MAX_PPC4xx_DMA_CHANNELS - 1)) {
printk("ppc4xx_disable_dma_sgl: bad channel in handle %d\n",
psgl->dmanr);
return;
}
sg_command = 0; //disable dma
switch (psgl->dmanr) {
case 0:
sg_command = SSG0_MASK_ENABLE;
break;
case 1:
sg_command = SSG1_MASK_ENABLE;
break;
case 2:
sg_command = SSG2_MASK_ENABLE;
break;
case 3:
sg_command = SSG3_MASK_ENABLE;
break;
default:
printk("ppc4xx_disable_dma_sgl: bad channel: %d\n",
psgl->dmanr);
}
mtdcr(DCRN_ASGC, sg_command); /* stop transfer */
}
[-- Attachment #2: Type: text/html, Size: 30210 bytes --]
^ permalink raw reply
* Re: [PATCH] drop linuxppc64-dev
From: Olaf Hering @ 2006-01-16 16:30 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev
In-Reply-To: <1137426731.22151.8.camel@localhost.localdomain>
On Mon, Jan 16, Hollis Blanchard wrote:
> Are you suggesting that nobody should ever use linuxppc64-dev now? If
> so, patching MAINTAINERS doesn't seem like the right way to enforce
> that.
It felt like a good starting point for this kind of discussion. :-)
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: [PATCH] fix spider compilation
From: Arnd Bergmann @ 2006-01-16 12:45 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, jgarzik, Jens Osterkamp
In-Reply-To: <20060116121157.GA7171@suse.de>
Olaf Hering <olh@suse.de> wrote on 01/16/2006 01:11:57 PM:
>
> linux-2.6.15/drivers/net/spider_net.c: In function
> `spider_net_set_txdescr_cmdstat':
> linux-2.6.15/drivers/net/spider_net.c:890: error: `IPPROTO_TCP'
> undeclared (first use in this function)
> linux-2.6.15/drivers/net/spider_net.c:890: error: (Each undeclared
> identifier is reported only once
> linux-2.6.15/drivers/net/spider_net.c:890: error: for each function
> it appears in.)
> linux-2.6.15/drivers/net/spider_net.c:892: error: `IPPROTO_UDP'
> undeclared (first use in this function)
>
> Signed-off-by: Olaf Hering <olh@suse.de>
Thanks. I already submitted the same patch to Jeff Garzik,
but had a problem with a quilt bug that caused another patch
in the series to fail.
Jeff, did you get the '[RESEND 2]' patches for spidernet?
Sorry for messing this up twice before, but I'm pretty
sure that I fixed up the diff now and the contents are
somewhat important, at least the compile fix.
Arnd <><
> drivers/net/spider_net.c | 1 +
> 1 files changed, 1 insertion(+)
>
> Index: linux-2.6.15/drivers/net/spider_net.c
> ===================================================================
> --- linux-2.6.15.orig/drivers/net/spider_net.c
> +++ linux-2.6.15/drivers/net/spider_net.c
> @@ -33,6 +33,7 @@
> #include <linux/init.h>
> #include <linux/ioport.h>
> #include <linux/ip.h>
> +#include <linux/in.h>
> #include <linux/kernel.h>
> #include <linux/mii.h>
> #include <linux/module.h>
^ permalink raw reply
* Re: [PATCH] drop linuxppc64-dev
From: Hollis Blanchard @ 2006-01-16 15:52 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060116121244.GB7171@suse.de>
On Mon, 2006-01-16 at 13:12 +0100, Olaf Hering wrote:
> Everything is merged into arch/powerpc now.
> Stop cross-posting.
> --- linux-2.6.15-olh.orig/MAINTAINERS
> +++ linux-2.6.15-olh/MAINTAINERS
> @@ -527,7 +527,7 @@ S: Supported
> BROADBAND PROCESSOR ARCHITECTURE
> P: Arnd Bergmann
> M: arnd@arndb.de
> -L: linuxppc64-dev@ozlabs.org
> +L: linuxppc-dev@ozlabs.org
> W: http://linuxppc64.org
> S: Supported
Are you suggesting that nobody should ever use linuxppc64-dev now? If
so, patching MAINTAINERS doesn't seem like the right way to enforce
that.
Do we want to think about merging the mailing lists? Both seem fairly
high-volume right now (compare
http://ozlabs.org/pipermail/linuxppc64-dev/ and
http://ozlabs.org/pipermail/linuxppc-dev/). linuxppc-embedded is
separate. There are certainly lots of emails and patches that are common
to both 32- and 64-bit, though...
The subscriber lists don't overlap 100%, but the difference might be
small enough not to matter to many people.
-Hollis
^ permalink raw reply
* [PATCH] drop linuxppc64-dev
From: Olaf Hering @ 2006-01-16 12:12 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Everything is merged into arch/powerpc now.
Stop cross-posting.
Signed-off-by: Olaf Hering <olh@suse.de>
Documentation/powerpc/hvcs.txt | 2 +-
MAINTAINERS | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.15-olh/Documentation/powerpc/hvcs.txt
===================================================================
--- linux-2.6.15-olh.orig/Documentation/powerpc/hvcs.txt
+++ linux-2.6.15-olh/Documentation/powerpc/hvcs.txt
@@ -560,7 +560,7 @@ The proper channel for reporting bugs is
distribution company that provided your OS or by posting issues to the
ppc64 development mailing list at:
-linuxppc64-dev@lists.linuxppc.org
+linuxppc-dev@ozlabs.org
This request is to provide a documented and searchable public exchange
of the problems and solutions surrounding this driver for the benefit of
Index: linux-2.6.15-olh/MAINTAINERS
===================================================================
--- linux-2.6.15-olh.orig/MAINTAINERS
+++ linux-2.6.15-olh/MAINTAINERS
@@ -527,7 +527,7 @@ S: Supported
BROADBAND PROCESSOR ARCHITECTURE
P: Arnd Bergmann
M: arnd@arndb.de
-L: linuxppc64-dev@ozlabs.org
+L: linuxppc-dev@ozlabs.org
W: http://linuxppc64.org
S: Supported
@@ -1606,7 +1606,7 @@ P: Anton Blanchard
M: anton@samba.org
M: anton@au.ibm.com
W: http://linuxppc64.org
-L: linuxppc64-dev@ozlabs.org
+L: linuxppc-dev@ozlabs.org
S: Supported
LINUX SECURITY MODULE (LSM) FRAMEWORK
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* [PATCH] fix spider compilation
From: Olaf Hering @ 2006-01-16 12:11 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev
linux-2.6.15/drivers/net/spider_net.c: In function `spider_net_set_txdescr_cmdstat':
linux-2.6.15/drivers/net/spider_net.c:890: error: `IPPROTO_TCP' undeclared (first use in this function)
linux-2.6.15/drivers/net/spider_net.c:890: error: (Each undeclared identifier is reported only once
linux-2.6.15/drivers/net/spider_net.c:890: error: for each function it appears in.)
linux-2.6.15/drivers/net/spider_net.c:892: error: `IPPROTO_UDP' undeclared (first use in this function)
Signed-off-by: Olaf Hering <olh@suse.de>
drivers/net/spider_net.c | 1 +
1 files changed, 1 insertion(+)
Index: linux-2.6.15/drivers/net/spider_net.c
===================================================================
--- linux-2.6.15.orig/drivers/net/spider_net.c
+++ linux-2.6.15/drivers/net/spider_net.c
@@ -33,6 +33,7 @@
#include <linux/init.h>
#include <linux/ioport.h>
#include <linux/ip.h>
+#include <linux/in.h>
#include <linux/kernel.h>
#include <linux/mii.h>
#include <linux/module.h>
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: AGPGART driver for ArticiaS - ioremap() problem
From: Gerhard Pircher @ 2006-01-16 8:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1137367531.4823.42.camel@localhost.localdomain>
> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: AGPGART driver for ArticiaS - ioremap() problem
> Datum: Mon, 16 Jan 2006 10:25:31 +1100
>
> >Actually at least the bridge does everthing right until now (IMHO :-).
> >The bridge is detected and also the aperture size is read out correctly
> >from the registers. After that, the agp_backend_initialize() function in
> >drivers/cahr/agp/backend.c calls the create_gatt_table() function of the
> >driver (articias_create_gatt_table). Based on the detected aperture size
> >and its definitions, this function allocates pages for the GATT table
> >(alloc_gatt_pages). The function then tries to map this pages with
> >ioremap_nocache(virt_to_gatt(table, (PAGE_SIZE * (1 << page_order))).
> >But ioremap_nocache() cannot remap the pages, because the following code
> >snipped in __ioremap (arch/ppc/mm/pgtable.c) is trigged:
>
> Yes, you are not allowed to ioremap RAM on ppc at least not with
> CONFIG_6xx. You should leave it cacheable and use explicit cache flush
> like the UniNorth driver.
Ah, okay. So at least the approach to use the Uninorth code was a step in
the right direction. But that requires changes in the DRI and X server code,
right?
Thanks!
regards,
Gerhard
--
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++
^ permalink raw reply
* Re: [PATCH 00/10] Xilinx Virtex-* updates
From: Grant Likely @ 2006-01-16 7:30 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <43CB2EAB.7080307@dlasys.net>
David H. Lynch Jr. wrote:
> I merged your ml403 changes into my copy of the kernel.org linux-2.6 git
> repository, and I am working to adapt my Pico E12-Virtex-4 port to work
> with them. I have mostly succeeded, but I am still working through a few
> rough spots.
Cool, thanks! Let me know about anything you've got issues with.
It looks like I missed the merge window for 2.6.16, so this stuff
probably won't get in until 2.6.17. OTOH, that give us some time to get
the weeds out.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761
^ 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