* Re: [PATCH] powerpc: add of_find_next_property andof_get_aliased_index
From: Stefan Roese @ 2008-06-26 18:41 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20080626142732.0ff6e64c@lappy.seanm.ca>
On Thursday 26 June 2008, Sean MacLennan wrote:
> > Well, there's a lot of disagreement on this subject. Not only do we
> > not agree on a method of enumerating devices, a lot of people have a
> > problem with the concept of enumerating them in the first place!
>
> An interesting point is that I enforced an index in the i2c-ibm_iic
> driver with no disagreement at all ;)
You have been lucky I suppose. :)
I could easily just have used this existing "index" property for the other 4xx
boards, but expected NAK's for this. That and because FSL uses "cell-index"
is why I asked prior to sending patches.
Now I have no idea how to support I2C on the other 4xx boards. Perhaps Josh
could advise how this should be done?
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] powerpc: add of_find_next_property andof_get_aliased_index
From: Timur Tabi @ 2008-06-26 18:29 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20080626142732.0ff6e64c@lappy.seanm.ca>
Sean MacLennan wrote:
> On Thu, 26 Jun 2008 10:55:14 -0500
> "Timur Tabi" <timur@freescale.com> wrote:
>
>> Well, there's a lot of disagreement on this subject. Not only do we
>> not agree on a method of enumerating devices, a lot of people have a
>> problem with the concept of enumerating them in the first place!
>
> An interesting point is that I enforced an index in the i2c-ibm_iic
> driver with no disagreement at all ;)
I added it to the fsl_soc as well without any fuss, but I may need to withdraw
it. Technically, the I2C nodes in our device trees should not have a cell-index
property, because there are no shared registers.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc: add of_find_next_property andof_get_aliased_index
From: Sean MacLennan @ 2008-06-26 18:27 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <4863BBE2.2060107@freescale.com>
On Thu, 26 Jun 2008 10:55:14 -0500
"Timur Tabi" <timur@freescale.com> wrote:
> Well, there's a lot of disagreement on this subject. Not only do we
> not agree on a method of enumerating devices, a lot of people have a
> problem with the concept of enumerating them in the first place!
An interesting point is that I enforced an index in the i2c-ibm_iic
driver with no disagreement at all ;)
Cheers,
Sean
^ permalink raw reply
* RE: Migrating from 2.6.11 to 2.6.23 breaks pci-e with LSI 1068 SAS chip
From: Siva Prasad @ 2008-06-26 18:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <74ADD192-AAA8-4105-9E78-AC44D84444DC@kernel.crashing.org>
Kumar,
We are using it onboard, not as add-on card. But I am sure there must be
PCI-E to SAS PCI cards based on LSI SAS controllers.
I just googled....
http://cgi.ebay.com/LSI-LSISAS3080X-R-8-Port-3Gb-s-SAS-PCI-X-Host-Bus-Ad
apt_W0QQitemZ220243588314QQihZ012QQcategoryZ90715QQcmdZViewItem?refid=3Ds=
t
ore
- Siva
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Thursday, June 26, 2008 6:37 AM
To: Siva Prasad
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Migrating from 2.6.11 to 2.6.23 breaks pci-e with LSI 1068
SAS chip
Is the LSI chipset something you guys have on an add-on card =20
(something we can put into a reference board) or is hard wired into =20
your boards?
If its an add on card a pointer to one would be appreciated.
- k
On Jun 25, 2008, at 5:20 PM, Siva Prasad wrote:
> I am also having problems with PCI-E device LSI 1064E on 2.6.24-rc6
> kernel. This is running on 8641D processor.
>
> I can see the device, access the config space, but seems access from
> device to memory is not working. Same device (same exact hardware) =20
> works
> fine for 2.6.15 kernel.
>
> - Siva
>
>
> -----Original Message-----
>
> Date: Wed, 25 Jun 2008 10:30:35 -0500
> From: Kumar Gala <galak@kernel.crashing.org>
> Subject: Re: Migrating from 2.6.11 to 2.6.23 breaks pci-e with LSI
> 1068 SAS chip
> To: Vince Asbridge <vasbridge@sanblaze.com>
> Cc: linuxppc-embedded@ozlabs.org
> Message-ID: <D7261455-1BB8-44E7-940D-84C207A40CA7@kernel.crashing.org>
> Content-Type: text/plain; charset=3DWINDOWS-1252; format=3Dflowed;
> delsp=3Dyes
>
>
> On Jun 24, 2008, at 10:51 AM, Vince Asbridge wrote:
>
>> All,
>>
>> I'm new to this mailing list, but have not had any luck finding
>> information on this issue.
>>
>> Please be kind if I break the forum rules on my first post.
>>
>> We recently tried to upgrade our Freescale CDS 8548 look-alike
>> module (code name ATCA1000) from the 2.6.11 based BSP to the 2.6.23
>> based BSP.
>>
>> The upgrade went fairly smoothly, until we tried using SOME pci-e
>> devices (some work fine, some don't show up to lspci).
>>
>> LSI pci-e controllers no longer show up at all!
>>
>> We see the ixgbe (intel 10G), SiliconImage SATA controller but do
>> not see LSI devices (Specifically 1068 SAS, FC949-E fibrechannel).
>>
>> We're guessing it's a resource issue behind the bridge, because the
>> LSI devices try to allocate 1 - 3M behind the bridge, but we can't
>> find the bug, or where we would debug such an issue.
>>
>> The devices seem to "train" correctly, because we have an LED on the
>> pci-e switch (PLX 8 port pci-e switch), and it's ON indicating pci-e
>> link between the bridge and the 1068 device).
>>
>> We're totally at a loss as to why this always worked on the 2.6.11
>> kernel but doesn?t work on 2.6.23.
>>
>> Using lspci, the LSI adapters do not show up in the list at all, as
>> though they are not plugged into the system.
>>
>> Is there something that needs to be done with respect to PCI-E
>> devices that is new in the 2.6.23 based BSP that did not need to be
>> done in the 2.6.11 based kit? For example, are pci resources
>> allocated by a different piece of code, that may have some issue
>> allocating resources for the LSI adapters?
>>
>>
>>
> Can you tree 2.6.25? There are some fixes in that kernel related to
> PCIe support:
>
> [POWERPC] FSL: Rework PCI/PCIe support for 85xx/86xx
>
> However, its odd that lspci doesn't even show the device. Are you
> using u-boot? if so what version? and does u-boot see the LSI?
>
> - k
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic
From: Adrian Bunk @ 2008-06-26 18:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch, alan, Michal Simek, vapier.adi, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, monstr, John.Linn, john.williams
In-Reply-To: <200806261838.33787.arnd@arndb.de>
On Thu, Jun 26, 2008 at 06:38:32PM +0200, Arnd Bergmann wrote:
> On Thursday 26 June 2008, Adrian Bunk wrote:
> > The comment could be nuked (as well as the #ifdef __KERNEL__), but for
> > the one #define an asm-generic header would IMHO be overkill.
>
> I agree that it doesn't technically make sense to have a one-line
> asm-generic header, but I like the idea of reducing the number of
> asm/*.h files that actually contain anything other that
> #include <asm-generic/$FILE.h>, mostly for documentation purposes.
>
> If we can eventually agree on a way to get rid of the requirement
> for explicit redirection, we can remove a larger number of source
> files completely.
Honestly, I do not completely like your approach of getting the
microblaze port submitter to create the asm-generic files - I would
personally prefer if the microblaze port would look exactly like all
other ports and the (reasonable) changes you have in mind were not
being discussed and done as part of the submission of a new port.
After all, it won't matter whether we'll unify resp. remove
22 or 23 files.
> Arnd <><
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic
From: H. Peter Anvin @ 2008-06-26 17:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch, alan, Adrian Bunk, vapier.adi, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, Michal Simek, monstr, John.Linn, john.williams
In-Reply-To: <200806261838.33787.arnd@arndb.de>
Arnd Bergmann wrote:
> On Thursday 26 June 2008, Adrian Bunk wrote:
>> The comment could be nuked (as well as the #ifdef __KERNEL__), but for
>> the one #define an asm-generic header would IMHO be overkill.
>
> I agree that it doesn't technically make sense to have a one-line
> asm-generic header, but I like the idea of reducing the number of
> asm/*.h files that actually contain anything other that
> #include <asm-generic/$FILE.h>, mostly for documentation purposes.
>
> If we can eventually agree on a way to get rid of the requirement
> for explicit redirection, we can remove a larger number of source
> files completely.
>
The sanest way to do that would probably be something along the lines of:
-> Change include/asm-xxx to arch/xxx/include/asm
-> Create arch/generic
-> Make sure arch/xxx/include/asm and arch/generic/include/asm are both
in the include path, in that order.
That would also get rid of the symlink.
On the other hand, the redirection isn't all that bad.
-hpa
^ permalink raw reply
* Re: Microblaze init port v4
From: H. Peter Anvin @ 2008-06-26 17:54 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch, alan, vapier.adi, matthew, microblaze-uclinux,
linux-kernel, drepper, linuxppc-dev, will.newton, monstr,
John.Linn, john.williams
In-Reply-To: <200806261951.12809.arnd@arndb.de>
Arnd Bergmann wrote:
>
> * You are using sys_ipc and sys_socketcall instead of the
> broken-out syscalls, which is a direct consequence of following
> the i386 numbering scheme.
>
Please pretty please kill, kill, kill...
-hpa
^ permalink raw reply
* Re: Microblaze init port v4
From: Arnd Bergmann @ 2008-06-26 17:51 UTC (permalink / raw)
To: monstr
Cc: linux-arch, alan, vapier.adi, matthew, microblaze-uclinux,
linux-kernel, drepper, linuxppc-dev, will.newton, hpa, John.Linn,
john.williams
In-Reply-To: <200806261709.37045.arnd@arndb.de>
On Thursday 26 June 2008, Arnd Bergmann wrote:
> That still leaves the problem that a lot of your syscalls have bugs
> copied from other platforms. If you need to maintain backwards compatibility
> with your existing binaries, that's fine, but please fix the code you are
> adding.
Sorry for my harsh words here, I should have read your patch set before
commenting on the introduction.
Most of the interfaces look good now, there are really just details left
now.
So contrary to what we had discussed before, you seem to have decided
to try to maintain source level compatibility with old uClibc versions,
but dropped binary compatibility that does not make much sense on
your architecture (considering that people synthesize their CPU with
a custom instruction set and then build kernel and user space for that),
which sounds reasonable to me, based on the earlier discussion.
On a more detailed level, there are a number of decisions in your
syscall interface, so let me summarize what I see you have done
and please tell me if this was all intentional or just an arbitrary
decision that seemed good at some point:
* off_t is 32 bit, and you use both off_t and loff_t based syscalls:
This is required because uClibc calls both versions of the syscalls,
otherwise you'd need to add a lot of code in uClibc.
* You implement both legacy and rt signal interfaces, just like
everyone else does. It probably seemed like a good idea because
something might actually be using the legacy interfaces in
arch/microblaze/kernel/signal.c, but AFAICT, neither libc nor
uClibc has been using them in a very long time when they are
both present, certainly longer than microblaze has been around.
The fact that you never noticed the missing sigaltstack implementation
is a good indication that this code has never seen any testing
and probably has more bugs.
* You have not implemented the *at() family of syscalls, which seems
to be an accidental misimplementation, and you have consequently
not removed the older versions of these syscalls, which is
correct if you don't want to break source level compatibility.
* Your syscall list follows the exact same numbering as i386,
which is fairly unusual, but not incorrect, despite wasting
a little memory on the unused slots. I suppose you did this
in order to keep some level of binary compatibility with older
user code. Since you are subtly breaking compatibility now,
I would still recommend changing all the numbers so that you
can guarantee that every old binary is obviously broken
instead of showing random problems.
* You are using sys_ipc and sys_socketcall instead of the
broken-out syscalls, which is a direct consequence of following
the i386 numbering scheme.
* You have defined both stat and stat64, with different definitions.
uClibc does have a copy of the two struct definitions, so you can't
easily change them without changing uClibc as well. Otherwise it
would have been good to define struct stat in the same way as
struct stat64, and only provide sys_stat but not sys_stat64 as
a syscall.
* I have already commented on the __ARCH_WANT_SYS_* macros you
define. Independent of the off_t, signal and *at() syscalls, I
think you should reduce the number of them by as much as you
can without breaking uClibc support. You can probably remove
almost all of them (not __ARCH_WANT_SYS_RT_SIGACTION,
__ARCH_WANT_STAT64 and __ARCH_WANT_SYS_SOCKETCALL, as I mentioned).
* Your syscall_table now contains two entries for each of the
uid32 functions, e.g __NR_setreuid32 and __NR_setreuid have
different numbers but both point to sys_setreuid.
No problem here, but a little unusual. As with the other functions
I mentioned, uClibc and glibc always call the *32 variant if that
is defined and the other one if it's not. I would suggest doing either
#define __NR_setreuid32 __NR_setreuid
#define __NR_setreuid 203
or (better)
#undef __NR_setreuid32
#define __NR_setreuid 203
to make the architecture more regular in this regard.
Arnd <><
^ permalink raw reply
* Re: [PATCH 59/60] microblaze_v4: syscall_table.S and unistd.h
From: H. Peter Anvin @ 2008-06-26 17:02 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch, alan, Michal Simek, vapier.adi, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, monstr, John.Linn, john.williams
In-Reply-To: <200806261831.19187.arnd@arndb.de>
Arnd Bergmann wrote:
>
> You still set __NR_fork. There is no point defining the number if you
> can't actually call the syscall in the first place.
>
Worse, it is actively *harmful* to set the number; klibc or anything
that uses similar kinds of scripts for portability will see the symbol
and think the system call is available.
-hpa
^ permalink raw reply
* Re: [PATCH] powerpc/bootwrapper: Add documentation of boot wrapper targets
From: Peter Mendham @ 2008-06-26 17:21 UTC (permalink / raw)
To: Grant Likely; +Cc: John Linn, paulus, linuxppc-dev
In-Reply-To: <20080626164842.1D3AB1358053@mail15-sin.bigfish.com>
Thanks for this documentation - I found it very illuminating. My
question was going to be similar to Stephen's in that I don't find it
clear which of the images with an embedded device tree I should be
using. This is all in contrast to the Xilinx git tree where I just use
zImage with a config option for embedding the device tree...
-- Peter
Stephen Neuendorffer wrote:
> My unanswered questions:
>
> 1) Why are there 4 different types of targets that embed a device tree?
> I assume they differ in how they are started loaded, but (unfortunately)
> the names are meaningless (With the exception of cuImage, which is only
> cryptic.. :) If I'm adding support for a new board, which should I use?
>
> 2) The simpleImage target is capable of selecting a head.s file to link
> based on the target name. This needs to be documented.
>
>
>> -----Original Message-----
>> From: Grant Likely [mailto:grant.likely@secretlab.ca]
>> Sent: Wednesday, June 25, 2008 1:21 PM
>> To: John Linn; Stephen Neuendorffer; linuxppc-dev@ozlabs.com;
>>
> paulus@samba.org
>
>> Cc: petermendham@computing.dundee.ac.uk
>> Subject: [PATCH] powerpc/bootwrapper: Add documentation of boot
>>
> wrapper targets
>
>> From: Grant Likely <grant.likely@secretlab.ca>
>>
>> There have been many questions on and off the mailing list about how
>> exactly the bootwrapper is used for embedded targets. Add some
>> documentation and help text to try and clarify the system.
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>> ---
>>
>> Documentation/powerpc/bootwrapper.txt | 78
>>
> +++++++++++++++++++++++++++++++++
>
>> arch/powerpc/Makefile | 15 ++++++
>> arch/powerpc/boot/wrapper | 4 ++
>> 3 files changed, 96 insertions(+), 1 deletions(-)
>>
>> diff --git a/Documentation/powerpc/bootwrapper.txt
>>
> b/Documentation/powerpc/bootwrapper.txt
>
>> new file mode 100644
>> index 0000000..8dcb560
>> --- /dev/null
>> +++ b/Documentation/powerpc/bootwrapper.txt
>> @@ -0,0 +1,78 @@
>> +The PowerPC boot wrapper
>> +------------------------
>> +Copyright (C) Secret Lab Technologies Ltd.
>> +
>> +PowerPC image targets compresses and wraps the kernel image (vmlinux)
>>
> with
>
>> +a boot wrapper to make it usable by the system firmware. There is no
>> +standard PowerPC firmware interface, so the boot wrapper is designed
>>
> to
>
>> +be adaptable for each kind of image that needs to be built.
>> +
>> +The boot wrapper can be found in the arch/powerpc/boot/ directory.
>>
> The
>
>> +Makefile in that directory has targets for all the available image
>>
> types.
>
>> +Currently, the following image targets exist:
>> +
>> + cuImage.%: Backwards compatible uImage for older
>>
> version of
>
>> + U-Boot (for versions that don't understand the
>>
> device
>
>> + tree). This image embeds a device tree blob
>>
> inside
>
>> + the image.
>> + dtbImage.%: Similar to zImage, except device tree
>>
> blob is embedded
>
>> + inside the image.
>> + simpleImage.%: Firmware independent compressed image that does
>>
> not
>
>> + depend on any particular firmware interface and
>>
> embeds
>
>> + a device tree blob. This image can be loaded to
>>
> any
>
>> + location in RAM and jumped to. Firmware cannot
>>
> pass
>
>> + any configuration data to the kernel with this
>>
> image
>
>> + type and the kernel depends on the device tree
>>
> to
>
>> + determine its console device.
>> + treeImage.%; Image format for some versions of ppc4xx
>>
> firmware (non
>
>> + U-Boot firmware). This image embeds a device
>>
> tree
>
>> + blob inside the image.
>> + uImage: Native image format used by U-Boot. The uImage
>>
> target
>
>> + does not add any boot code. It just wraps a
>>
> compressed
>
>> + vmlinux in the uImage data structure.
>> + zImage.%: Image usable by OpenFirmware. Image expects
>>
> firmware
>
>> + to provide the device tree using OpenFirmware
>> + interfaces. Typically general purpose hardware
>>
> uses
>
>> + this image format.
>> +
>> +Image types which embed a device tree blob (simpleImage, dtbImage,
>>
> treeImage,
>
>> +and cuImage) all generate the device tree blob from a file in the
>> +arch/powerpc/boot/dts/ directory. The Makefile selects the correct
>>
> device
>
>> +tree source based on the name of the target. Therefore, if the
>>
> kernel is
>
>> +built with 'make treeImage.walnut simpleImage.virtex405-ml403', then
>>
> the
>
>> +build system will use arch/powerpc/boot/dts/walnut.dts to build
>> +treeImage.walnut and arch/powerpc/boot/dts/virtex405-ml403.dts to
>>
> build
>
>> +the simpleImage.virtex405-ml403.
>> +
>> +Two special targets called 'zImage' and 'zImage.initrd' also exist.
>>
> These
>
>> +targets build all the default images as selected by the kernel
>>
> configuration.
>
>> +Default images are selected by the boot wrapper Makefile
>> +(arch/powerpc/boot/Makefile) by adding targets to the $image-y
>>
> variable. Look
>
>> +at the Makefile to see which default image targets are available.
>> +
>> +How it is built
>> +---------------
>> +arch/powerpc is designed to support multiplatform kernels, which
>>
> means
>
>> +that a single vmlinux image can be booted on many different target
>>
> boards.
>
>> +It also means that the boot wrapper must be able to wrap for many
>>
> kinds of
>
>> +images on a single build. The design decision was made to not use
>>
> any
>
>> +conditional compilation code (#ifdef, etc) in the boot wrapper source
>>
> code.
>
>> +All of the boot wrapper pieces are buildable at any time regardless
>>
> of the
>
>> +kernel configuration. Building all the wrapper bits on every kernel
>>
> build
>
>> +also ensures that obscure parts of the wrapper are at the very least
>>
> compile
>
>> +tested in a large variety of environments.
>> +
>> +The wrapper is adapted for different image types at link time by
>>
> linking in
>
>> +just the wrapper bits that are appropriate for the image type. The
>>
> 'wrapper'
>
>> +script (found in arch/powerpc/boot/wrapper) is called by the Makefile
>>
> and
>
>> +is responsible for selecting the correct wrapper bits for the image
>>
> type.
>
>> +The arguments are well documented in the script's comment block, so
>>
> they
>
>> +are not repeated here. However, it is worth mentioning that the
>>
> script
>
>> +uses the -p (platform) argument as the main method of deciding which
>>
> wrapper
>
>> +bits to compile in. Look for the large 'case "$platform" in' block
>>
> in the
>
>> +middle of the script. This is also the place where platform specific
>>
> fixups
>
>> +can be selected by changing the link order.
>> +
>> +In particular, care should be taken when working with cuImages.
>>
> cuImage
>
>> +wrapper bits are very board specific and care should be taken to make
>>
> sure
>
>> +the target you are trying to build is supported by the wrapper bits.
>> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
>> index b7d4c4c..754c7eb 100644
>> --- a/arch/powerpc/Makefile
>> +++ b/arch/powerpc/Makefile
>> @@ -169,12 +169,25 @@ bootwrapper_install %.dtb:
>> $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst
>>
> %,$(boot)/%,$@)
>
>> define archhelp
>> - @echo '* zImage - Compressed kernel image
>>
> (arch/$(ARCH)/boot/zImage.*)'
>
>> + @echo '* zImage - Build default images selected by kernel
>>
> config'
>
>> + @echo ' zImage.* - Compressed kernel image
>>
> (arch/$(ARCH)/boot/zImage.*)'
>
>> + @echo ' uImage - U-Book native image format'
>> + @echo ' cuImage.<dt> - Backwards compatible U-Boot image for
>>
> older'
>
>> + @echo ' versions which do not support device
>>
> trees'
>
>> + @echo ' dtbImage.<dt> - zImage with an embedded device tree
>>
> blob'
>
>> + @echo ' simpleImage.<dt> - Firmware independant image.'
>> + @echo ' treeImage.<dt> - Support for older IBM 4xx firmware (not
>>
> U-Boot)'
>
>> @echo ' install - Install kernel using'
>> @echo ' (your) ~/bin/installkernel or'
>> @echo ' (distribution) /sbin/installkernel or'
>> @echo ' install to $$(INSTALL_PATH) and run
>>
> lilo'
>
>> @echo ' *_defconfig - Select default config from
>>
> arch/$(ARCH)/configs'
>
>> + @echo ''
>> + @echo ' Targets with <dt> embed a device tree blob inside the
>>
> image'
>
>> + @echo ' These targets support board with firmware that does not'
>> + @echo ' support passing a device tree directly. Replace <dt> with
>>
> the'
>
>> + @echo ' name of a dts file from the arch/$(ARCH)/boot/dts/
>>
> directory'
>
>> + @echo ' (minus the .dts extension).'
>> endef
>>
>> install:
>> diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
>> index d6c96d9..7cd4182 100755
>> --- a/arch/powerpc/boot/wrapper
>> +++ b/arch/powerpc/boot/wrapper
>> @@ -203,6 +203,10 @@ simpleboot-virtex405-*)
>> platformo="$object/virtex405-head.o $object/simpleboot.o"
>> binary=y
>> ;;
>> +simpleboot-*)
>> + platformo="$object/simpleboot.o"
>> + binary=y
>> + ;;
>> esac
>>
>> vmz="$tmpdir/`basename \"$kernel\"`.$ext"
>>
>>
>
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
>
>
The University of Dundee is a Scottish Registered Charity, No. SC015096.
^ permalink raw reply
* Why doesn't "mtmsr" instruction work well?
From: EVANGELION @ 2008-06-26 17:03 UTC (permalink / raw)
To: linuxppc-dev
Hello, all:
I am building a Linux kernel module for PPC405EP.
My developing board is PPChameleonEVB. I am debugging
with BDI2000 and GDB, and my problem is:
In GDB, a section of the codes is disassembled to:
mfmsr r0
ori r0,r0,32768
mtmsr r0
blr
From BDI2000, I have checked that after "ori",
GPR0 contains "0x00029030". This value should be
written into MSR by "mtmsr" to set EE bit of MSR as 1,
but after single step in BDI, "mtmsr" does not work as
hoped. MSR becomes "0x00000030", GPR0 becomes some
weird number, and there is "Step timeout detected".
Meanwhile, the board traps into "Data machine check in
kernel mode". I also have tried "wrteei 1" instead of
the codes above, but failed again. However, those
codes works well in PPC440EP Yosemite board.
405EP>ti
Core number : 0
Core state : debug mode
Debug entry cause : single step
Current PC : 0xc32b1008
Current CR : 0x84000084
Current MSR : 0x00021030
Current LR : 0xc32b46c4
405EP>rd
GPR00: 00029030 c1dd9d60 c1fe7bf0 00000000
GPR04: 00000001 00000000 c32b2c8c 00000000
GPR08: c3068000 c3068000 00000001 c3062000
GPR12: 00000000 10019dd8 c32c0000 c32b0000
GPR16: 00000001 c32b0000 00000002 7ff4f670
GPR20: 00000028 c32b0000 c32b0000 10011000
GPR24: c306a000 00000000 00000000 10012c6c
GPR28: c18e4000 c32c0000 00000000 00000000
CR : 84000084 MSR: 00021030
405EP>ti
Core number : 0
Core state : debug mode
Debug entry cause : JTAG stop request
Current PC : 0xc000490c
Current CR : 0x42000082
Current MSR : 0x00000030
Current LR : 0xc001f1b8
# Step timeout detected
405EP>rd
GPR00: 03929800 c02f3e60 c3066000 000102f1
GPR04: 00005424 00000007 c0146f3c c0260000
GPR08: 00000000 c02d0000 c3062000 00000000
GPR12: 00000000 10019dd8 c32c0000 c32b0000
GPR16: 00000001 c32b0000 00000002 7ff4f670
GPR20: 00000028 c32b0000 c32b0000 10011000
GPR24: c306a000 00000000 00000000 10012c6c
GPR28: c02f0000 00000152 c3066000 c02f0000
CR : 42000082 MSR: 00000030
==========================================
Data machine check in kernel mode.
PLB0: BEAR= 0x03066004 ACR= 0x00000000 BESR=
0x00c00000
PLB0 to OPB: BEAR= 0x04000000 BESR0= 0x00000000 BESR1=
0x00000000
Oops: machine check, sig: 7 [#1]
NIP: 00002AD0 LR: 000005A0 CTR: C000CC58
REGS: c02f3f50 TRAP: 0202 Not tainted
(2.6.19.2-eldk)
MSR: 00021000 <ME> CR: 24000084 XER: 20000000
TASK = c3066000[0] '' THREAD: c02d2000
GPR00: 00029030 C1DD9CA0 C3066000 C1DD9CB0 00000001
00000000 C32B2C8C 00000000
GPR08: C3068000 00000000 00021032 01DD9CA0 030661B0
10019DD8 C32C0000 C32B0000
GPR16: 00000001 C32B0000 00000002 7FF4F670 00000028
C32B0000 C32B0000 10011000
GPR24: C306A000 00000000 00000000 10012C6C C18E4000
C32C0000 00000000 00000000
NIP [00002AD0] 0x2ad0
LR [000005A0] 0x5a0
Call Trace:
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX
Kernel panic - not syncing: Attempted to kill the idle
task!
<0>Rebooting in 180 seconds..
Thanks for advice!
Best Regards
Evangelion
June 26th, 2008
___________________________________________________________
雅虎邮箱，您的终生邮箱！
http://cn.mail.yahoo.com/
^ permalink raw reply
* [PATCH 2/2] powerpc: Move mpc83xx_add_bridge to fsl_pci.c [rev2]
From: John Rigby @ 2008-06-26 17:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, John Rigby
In-Reply-To: <1214500077-9254-2-git-send-email-jrigby@freescale.com>
This allows other platforms with the same pci
block like MPC5121 to use it.
Signed-off-by: John Rigby <jrigby@freescale.com>
---
arch/powerpc/platforms/83xx/Kconfig | 2 +-
arch/powerpc/platforms/83xx/Makefile | 1 -
arch/powerpc/platforms/83xx/mpc831x_rdb.c | 1 +
arch/powerpc/platforms/83xx/mpc832x_mds.c | 1 +
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 1 +
arch/powerpc/platforms/83xx/mpc834x_itx.c | 1 +
arch/powerpc/platforms/83xx/mpc834x_mds.c | 1 +
arch/powerpc/platforms/83xx/mpc836x_mds.c | 1 +
arch/powerpc/platforms/83xx/mpc837x_mds.c | 1 +
arch/powerpc/platforms/83xx/mpc837x_rdb.c | 1 +
arch/powerpc/platforms/83xx/mpc83xx.h | 1 -
arch/powerpc/platforms/83xx/pci.c | 91 -----------------------------
arch/powerpc/platforms/83xx/sbc834x.c | 1 +
arch/powerpc/sysdev/fsl_pci.c | 61 +++++++++++++++++++
arch/powerpc/sysdev/fsl_pci.h | 1 +
15 files changed, 72 insertions(+), 94 deletions(-)
delete mode 100644 arch/powerpc/platforms/83xx/pci.c
diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig
index 0a306eb..ca2c149 100644
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -3,7 +3,7 @@ menuconfig MPC83xx
depends on PPC_83xx
select PPC_UDBG_16550
select PPC_PCI_CHOICE
- select PPC_INDIRECT_PCI
+ select FSL_PCI if PCI
if MPC83xx
diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/platforms/83xx/Makefile
index 76494be..59c413c 100644
--- a/arch/powerpc/platforms/83xx/Makefile
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -2,7 +2,6 @@
# Makefile for the PowerPC 83xx linux kernel.
#
obj-y := misc.o usb.o
-obj-$(CONFIG_PCI) += pci.o
obj-$(CONFIG_MPC831x_RDB) += mpc831x_rdb.o
obj-$(CONFIG_MPC832x_RDB) += mpc832x_rdb.o
obj-$(CONFIG_MPC834x_MDS) += mpc834x_mds.o
diff --git a/arch/powerpc/platforms/83xx/mpc831x_rdb.c b/arch/powerpc/platforms/83xx/mpc831x_rdb.c
index c4db517..a428f8d 100644
--- a/arch/powerpc/platforms/83xx/mpc831x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc831x_rdb.c
@@ -19,6 +19,7 @@
#include <asm/time.h>
#include <asm/ipic.h>
#include <asm/udbg.h>
+#include <sysdev/fsl_pci.h>
#include "mpc83xx.h"
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index 6dbc6ea..dd4be4a 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -36,6 +36,7 @@
#include <asm/prom.h>
#include <asm/udbg.h>
#include <sysdev/fsl_soc.h>
+#include <sysdev/fsl_pci.h>
#include <asm/qe.h>
#include <asm/qe_ic.h>
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index e7f706b..f049d69 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -27,6 +27,7 @@
#include <asm/qe.h>
#include <asm/qe_ic.h>
#include <sysdev/fsl_soc.h>
+#include <sysdev/fsl_pci.h>
#include "mpc83xx.h"
diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/powerpc/platforms/83xx/mpc834x_itx.c
index 50e8f63..7301d77 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
@@ -35,6 +35,7 @@
#include <asm/prom.h>
#include <asm/udbg.h>
#include <sysdev/fsl_soc.h>
+#include <sysdev/fsl_pci.h>
#include "mpc83xx.h"
diff --git a/arch/powerpc/platforms/83xx/mpc834x_mds.c b/arch/powerpc/platforms/83xx/mpc834x_mds.c
index 2b8a0a3..30d509a 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_mds.c
@@ -35,6 +35,7 @@
#include <asm/prom.h>
#include <asm/udbg.h>
#include <sysdev/fsl_soc.h>
+#include <sysdev/fsl_pci.h>
#include "mpc83xx.h"
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index c2e5de6..75b80e8 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -42,6 +42,7 @@
#include <asm/prom.h>
#include <asm/udbg.h>
#include <sysdev/fsl_soc.h>
+#include <sysdev/fsl_pci.h>
#include <asm/qe.h>
#include <asm/qe_ic.h>
diff --git a/arch/powerpc/platforms/83xx/mpc837x_mds.c b/arch/powerpc/platforms/83xx/mpc837x_mds.c
index 64d17b0..be62de2 100644
--- a/arch/powerpc/platforms/83xx/mpc837x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc837x_mds.c
@@ -19,6 +19,7 @@
#include <asm/ipic.h>
#include <asm/udbg.h>
#include <asm/prom.h>
+#include <sysdev/fsl_pci.h>
#include "mpc83xx.h"
diff --git a/arch/powerpc/platforms/83xx/mpc837x_rdb.c b/arch/powerpc/platforms/83xx/mpc837x_rdb.c
index c00356b..da030af 100644
--- a/arch/powerpc/platforms/83xx/mpc837x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc837x_rdb.c
@@ -17,6 +17,7 @@
#include <asm/time.h>
#include <asm/ipic.h>
#include <asm/udbg.h>
+#include <sysdev/fsl_pci.h>
#include "mpc83xx.h"
diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h b/arch/powerpc/platforms/83xx/mpc83xx.h
index 88a3b5c..393dfec 100644
--- a/arch/powerpc/platforms/83xx/mpc83xx.h
+++ b/arch/powerpc/platforms/83xx/mpc83xx.h
@@ -55,7 +55,6 @@
* mpc83xx_* files. Mostly for use by mpc83xx_setup
*/
-extern int mpc83xx_add_bridge(struct device_node *dev);
extern void mpc83xx_restart(char *cmd);
extern long mpc83xx_time_init(void);
extern int mpc834x_usb_cfg(void);
diff --git a/arch/powerpc/platforms/83xx/pci.c b/arch/powerpc/platforms/83xx/pci.c
deleted file mode 100644
index 14f1080..0000000
--- a/arch/powerpc/platforms/83xx/pci.c
+++ /dev/null
@@ -1,91 +0,0 @@
-/*
- * FSL SoC setup code
- *
- * Maintained by Kumar Gala (see MAINTAINERS for contact information)
- *
- * 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/stddef.h>
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/errno.h>
-#include <linux/pci.h>
-#include <linux/delay.h>
-#include <linux/irq.h>
-#include <linux/module.h>
-
-#include <asm/system.h>
-#include <asm/atomic.h>
-#include <asm/io.h>
-#include <asm/pci-bridge.h>
-#include <asm/prom.h>
-#include <sysdev/fsl_soc.h>
-
-#undef DEBUG
-
-#ifdef DEBUG
-#define DBG(x...) printk(x)
-#else
-#define DBG(x...)
-#endif
-
-int __init mpc83xx_add_bridge(struct device_node *dev)
-{
- int len;
- struct pci_controller *hose;
- struct resource rsrc;
- const int *bus_range;
- int primary = 1, has_address = 0;
- phys_addr_t immr = get_immrbase();
-
- DBG("Adding PCI host bridge %s\n", dev->full_name);
-
- /* Fetch host bridge registers address */
- has_address = (of_address_to_resource(dev, 0, &rsrc) == 0);
-
- /* Get bus range if any */
- bus_range = of_get_property(dev, "bus-range", &len);
- if (bus_range == NULL || len < 2 * sizeof(int)) {
- printk(KERN_WARNING "Can't get bus-range for %s, assume"
- " bus 0\n", dev->full_name);
- }
-
- ppc_pci_flags |= PPC_PCI_REASSIGN_ALL_BUS;
- hose = pcibios_alloc_controller(dev);
- if (!hose)
- return -ENOMEM;
-
- hose->first_busno = bus_range ? bus_range[0] : 0;
- hose->last_busno = bus_range ? bus_range[1] : 0xff;
-
- /* MPC83xx supports up to two host controllers one at 0x8500 from immrbar
- * the other at 0x8600, we consider the 0x8500 the primary controller
- */
- /* PCI 1 */
- if ((rsrc.start & 0xfffff) == 0x8500) {
- setup_indirect_pci(hose, immr + 0x8300, immr + 0x8304, 0);
- }
- /* PCI 2 */
- if ((rsrc.start & 0xfffff) == 0x8600) {
- setup_indirect_pci(hose, immr + 0x8380, immr + 0x8384, 0);
- primary = 0;
- }
-
- printk(KERN_INFO "Found MPC83xx PCI host bridge at 0x%016llx. "
- "Firmware bus number: %d->%d\n",
- (unsigned long long)rsrc.start, hose->first_busno,
- hose->last_busno);
-
- DBG(" ->Hose at 0x%p, cfg_addr=0x%p,cfg_data=0x%p\n",
- hose, hose->cfg_addr, hose->cfg_data);
-
- /* Interpret the "ranges" property */
- /* This also maps the I/O region and sets isa_io/mem_base */
- pci_process_bridge_OF_ranges(hose, dev, primary);
-
- return 0;
-}
diff --git a/arch/powerpc/platforms/83xx/sbc834x.c b/arch/powerpc/platforms/83xx/sbc834x.c
index cf38247..fc21f5c 100644
--- a/arch/powerpc/platforms/83xx/sbc834x.c
+++ b/arch/powerpc/platforms/83xx/sbc834x.c
@@ -37,6 +37,7 @@
#include <asm/prom.h>
#include <asm/udbg.h>
#include <sysdev/fsl_soc.h>
+#include <sysdev/fsl_pci.h>
#include "mpc83xx.h"
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 489ca5a..68583f6 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -27,6 +27,7 @@
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
+#if defined(CONFIG_PPC_85xx) || defined(CONFIG_PPC_86xx)
/* atmu setup for fsl pci/pcie controller */
void __init setup_pci_atmu(struct pci_controller *hose, struct resource *rsrc)
{
@@ -246,3 +247,63 @@ DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8572, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8641, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8641D, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8610, quirk_fsl_pcie_header);
+#endif /* CONFIG_PPC_85xx || CONFIG_PPC_86xx */
+
+#if defined(CONFIG_PPC_83xx)
+int __init mpc83xx_add_bridge(struct device_node *dev)
+{
+ int len;
+ struct pci_controller *hose;
+ struct resource rsrc;
+ const int *bus_range;
+ int primary = 1, has_address = 0;
+ phys_addr_t immr = get_immrbase();
+
+ pr_debug("Adding PCI host bridge %s\n", dev->full_name);
+
+ /* Fetch host bridge registers address */
+ has_address = (of_address_to_resource(dev, 0, &rsrc) == 0);
+
+ /* Get bus range if any */
+ bus_range = of_get_property(dev, "bus-range", &len);
+ if (bus_range == NULL || len < 2 * sizeof(int)) {
+ printk(KERN_WARNING "Can't get bus-range for %s, assume"
+ " bus 0\n", dev->full_name);
+ }
+
+ ppc_pci_flags |= PPC_PCI_REASSIGN_ALL_BUS;
+ hose = pcibios_alloc_controller(dev);
+ if (!hose)
+ return -ENOMEM;
+
+ hose->first_busno = bus_range ? bus_range[0] : 0;
+ hose->last_busno = bus_range ? bus_range[1] : 0xff;
+
+ /* MPC83xx supports up to two host controllers one at 0x8500 from immrbar
+ * the other at 0x8600, we consider the 0x8500 the primary controller
+ */
+ /* PCI 1 */
+ if ((rsrc.start & 0xfffff) == 0x8500) {
+ setup_indirect_pci(hose, immr + 0x8300, immr + 0x8304, 0);
+ }
+ /* PCI 2 */
+ if ((rsrc.start & 0xfffff) == 0x8600) {
+ setup_indirect_pci(hose, immr + 0x8380, immr + 0x8384, 0);
+ primary = 0;
+ }
+
+ printk(KERN_INFO "Found MPC83xx PCI host bridge at 0x%016llx. "
+ "Firmware bus number: %d->%d\n",
+ (unsigned long long)rsrc.start, hose->first_busno,
+ hose->last_busno);
+
+ pr_debug(" ->Hose at 0x%p, cfg_addr=0x%p,cfg_data=0x%p\n",
+ hose, hose->cfg_addr, hose->cfg_data);
+
+ /* Interpret the "ranges" property */
+ /* This also maps the I/O region and sets isa_io/mem_base */
+ pci_process_bridge_OF_ranges(hose, dev, primary);
+
+ return 0;
+}
+#endif /* CONFIG_PPC_83xx */
diff --git a/arch/powerpc/sysdev/fsl_pci.h b/arch/powerpc/sysdev/fsl_pci.h
index 37b04ad..13f30c2 100644
--- a/arch/powerpc/sysdev/fsl_pci.h
+++ b/arch/powerpc/sysdev/fsl_pci.h
@@ -83,6 +83,7 @@ struct ccsr_pci {
extern int fsl_add_bridge(struct device_node *dev, int is_primary);
extern void fsl_pcibios_fixup_bus(struct pci_bus *bus);
+extern int mpc83xx_add_bridge(struct device_node *dev);
#endif /* __POWERPC_FSL_PCI_H */
#endif /* __KERNEL__ */
--
1.5.6.rc0.46.gd2b3
^ permalink raw reply related
* [PATCH 1/2] powerpc: pci config cleanup [rev2]
From: John Rigby @ 2008-06-26 17:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, John Rigby
In-Reply-To: <1214500077-9254-1-git-send-email-jrigby@freescale.com>
Choosing PCI or not at config time is allowed on some
platforms via an if expression in arch/powerpc/Kconfig.
To add a new platform with PCI support selectable at
config time, you must change the if expression. This
patch makes this easier by changing:
bool "PCI support" if <long expression>
to
bool "PCI support" if PPC_PCI_CHOICE
and adding select PPC_PCI_CHOICE to all the config nodes that
were previously in the PCI if expression.
Platforms with unconditional PCI support continue to
just select PCI in their config nodes.
Signed-off-by: John Rigby <jrigby@freescale.com>
---
arch/powerpc/Kconfig | 12 ++++++++----
arch/powerpc/platforms/52xx/Kconfig | 1 +
arch/powerpc/platforms/83xx/Kconfig | 1 +
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/86xx/Kconfig | 2 ++
arch/powerpc/platforms/Kconfig | 1 +
arch/powerpc/platforms/Kconfig.cputype | 2 ++
arch/powerpc/platforms/iseries/Kconfig | 1 +
arch/powerpc/platforms/ps3/Kconfig | 1 +
arch/powerpc/platforms/pseries/Kconfig | 1 +
10 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 3934e26..36c8d1c 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -542,11 +542,15 @@ config FSL_LBC
config MCA
bool
+# Platforms that what PCI turned unconditionally just do select PCI
+# in their config node. Platforms that want to choose at config
+# time should select PPC_PCI_CHOICE
+config PPC_PCI_CHOICE
+ bool
+
config PCI
- bool "PCI support" if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_86xx \
- || PPC_MPC52xx || (EMBEDDED && (PPC_PSERIES || PPC_ISERIES)) \
- || PPC_PS3 || 44x
- default y if !40x && !CPM2 && !8xx && !PPC_MPC512x && !PPC_83xx \
+ bool "PCI support" if PPC_PCI_CHOICE
+ default y if !40x && !CPM2 && !8xx && !PPC_83xx \
&& !PPC_85xx && !PPC_86xx
default PCI_PERMEDIA if !4xx && !CPM2 && !8xx
default PCI_QSPAN if !4xx && !CPM2 && 8xx
diff --git a/arch/powerpc/platforms/52xx/Kconfig b/arch/powerpc/platforms/52xx/Kconfig
index acd2fc8..d664b1b 100644
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -3,6 +3,7 @@ config PPC_MPC52xx
depends on PPC_MULTIPLATFORM && PPC32
select FSL_SOC
select PPC_CLOCK
+ select PPC_PCI_CHOICE
config PPC_MPC5200_SIMPLE
bool "Generic support for simple MPC5200 based boards"
diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig
index 583b0c7..0a306eb 100644
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -2,6 +2,7 @@ menuconfig MPC83xx
bool "83xx Board Type"
depends on PPC_83xx
select PPC_UDBG_16550
+ select PPC_PCI_CHOICE
select PPC_INDIRECT_PCI
if MPC83xx
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 7ff29d5..82a3023 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -2,8 +2,8 @@ menuconfig MPC85xx
bool "Machine Type"
depends on PPC_85xx
select PPC_UDBG_16550
- select PPC_INDIRECT_PCI if PCI
select MPIC
+ select PPC_PCI_CHOICE
select FSL_PCI if PCI
select SERIAL_8250_SHARE_IRQ if SERIAL_8250
default y
diff --git a/arch/powerpc/platforms/86xx/Kconfig b/arch/powerpc/platforms/86xx/Kconfig
index 053f49a..3500e67 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -28,6 +28,7 @@ endchoice
config MPC8641
bool
+ select PPC_PCI_CHOICE
select FSL_PCI if PCI
select PPC_UDBG_16550
select MPIC
@@ -35,6 +36,7 @@ config MPC8641
config MPC8610
bool
+ select PPC_PCI_CHOICE
select FSL_PCI if PCI
select PPC_UDBG_16550
select MPIC
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 87454c5..aead68a 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -280,6 +280,7 @@ config CPM2
depends on MPC85xx || 8260
select CPM
select PPC_LIB_RHEAP
+ select PPC_PCI_CHOICE
help
The CPM2 (Communications Processor Module) is a coprocessor on
embedded CPUs made by Freescale. Selecting this option means that
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index f7efaa9..01e7561 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -42,12 +42,14 @@ config 40x
select PPC_DCR_NATIVE
select PPC_UDBG_16550
select 4xx_SOC
+ select PPC_PCI_CHOICE
config 44x
bool "AMCC 44x"
select PPC_DCR_NATIVE
select PPC_UDBG_16550
select 4xx_SOC
+ select PPC_PCI_CHOICE
config E200
bool "Freescale e200"
diff --git a/arch/powerpc/platforms/iseries/Kconfig b/arch/powerpc/platforms/iseries/Kconfig
index 761d9e9..ea3e541 100644
--- a/arch/powerpc/platforms/iseries/Kconfig
+++ b/arch/powerpc/platforms/iseries/Kconfig
@@ -2,6 +2,7 @@ config PPC_ISERIES
bool "IBM Legacy iSeries"
depends on PPC_MULTIPLATFORM && PPC64
select PPC_INDIRECT_IO
+ select PPC_PCI_CHOICE if EMBEDDED
menu "iSeries device drivers"
depends on PPC_ISERIES
diff --git a/arch/powerpc/platforms/ps3/Kconfig b/arch/powerpc/platforms/ps3/Kconfig
index a5f4e95..920cf7a 100644
--- a/arch/powerpc/platforms/ps3/Kconfig
+++ b/arch/powerpc/platforms/ps3/Kconfig
@@ -8,6 +8,7 @@ config PPC_PS3
select USB_ARCH_HAS_EHCI
select USB_EHCI_BIG_ENDIAN_MMIO
select MEMORY_HOTPLUG
+ select PPC_PCI_CHOICE
help
This option enables support for the Sony PS3 game console
and other platforms using the PS3 hypervisor. Enabling this
diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
index 07fe5b6..757c029 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -7,6 +7,7 @@ config PPC_PSERIES
select RTAS_ERROR_LOGGING
select PPC_UDBG_16550
select PPC_NATIVE
+ select PPC_PCI_CHOICE if EMBEDDED
default y
config PPC_SPLPAR
--
1.5.6.rc0.46.gd2b3
^ permalink raw reply related
* [PATCH 0/2] powerpc: pci cleanup [rev2]
From: John Rigby @ 2008-06-26 17:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, John Rigby
patch 1/2 cleans up powerpc pci config
Thanks to Michael Ellerman for his comments. This new version
calls the new config var PPC_PCI_CHOICE instead of PPC_HAS_PCI
patch 2/2 moves mpc83xx_add_bridge to fsl_pci.c
This is unchanged.
^ permalink raw reply
* Re: [PATCH] Remove experimental status of kdump on PPC64
From: Bernhard Walle @ 2008-06-26 17:02 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, kexec, linux-kernel, vgoyal
In-Reply-To: <1214494132.2791.0.camel@weaponx>
* Josh Boyer <jwboyer@gmail.com> [2008-06-26 11:28]:
>
> On Thu, 2008-06-26 at 14:57 +0200, Bernhard Walle wrote:
> > This patch removes the experimental status of kdump on IA64. kdump is on IA64
> > now since more than one year and it has proven to be stable.
>
> I think you mean PPC64?
Right. Copy & paste, I made the same patch for IA64. Resent. Sorry. :)
Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development
^ permalink raw reply
* [PATCH] Remove experimental status of kdump on PPC64
From: Bernhard Walle @ 2008-06-26 17:02 UTC (permalink / raw)
To: jwboyer; +Cc: linuxppc-dev, Bernhard Walle, kexec, linux-kernel, vgoyal
In-Reply-To: <1214494132.2791.0.camel@weaponx>
This patch removes the experimental status of kdump on PPC64. kdump is on PPC64
now since more than one year and it has proven to be stable.
For i386/x86_64, a similar patch has been accepted by Ingo Molnar and Vivek
Goyal.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
---
arch/powerpc/Kconfig | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 3934e26..2a116b9 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -308,8 +308,8 @@ config KEXEC
strongly in flux, so no good recommendation can be made.
config CRASH_DUMP
- bool "Build a kdump crash kernel (EXPERIMENTAL)"
- depends on PPC_MULTIPLATFORM && PPC64 && EXPERIMENTAL
+ bool "Build a kdump crash kernel"
+ depends on PPC_MULTIPLATFORM && PPC64
help
Build a kernel suitable for use as a kdump capture kernel.
The kernel will be linked at a different address than normal, and
--
1.5.6
^ permalink raw reply related
* RE: [PATCH] powerpc/bootwrapper: Add documentation of boot wrapper targets
From: Stephen Neuendorffer @ 2008-06-26 16:48 UTC (permalink / raw)
To: Grant Likely, John Linn, linuxppc-dev, paulus; +Cc: petermendham
In-Reply-To: <20080625202104.30114.47902.stgit@trillian.secretlab.ca>
My unanswered questions:
1) Why are there 4 different types of targets that embed a device tree?
I assume they differ in how they are started loaded, but (unfortunately)
the names are meaningless (With the exception of cuImage, which is only
cryptic.. :) If I'm adding support for a new board, which should I use?
2) The simpleImage target is capable of selecting a head.s file to link
based on the target name. This needs to be documented.
> -----Original Message-----
> From: Grant Likely [mailto:grant.likely@secretlab.ca]
> Sent: Wednesday, June 25, 2008 1:21 PM
> To: John Linn; Stephen Neuendorffer; linuxppc-dev@ozlabs.com;
paulus@samba.org
> Cc: petermendham@computing.dundee.ac.uk
> Subject: [PATCH] powerpc/bootwrapper: Add documentation of boot
wrapper targets
> =
> From: Grant Likely <grant.likely@secretlab.ca>
> =
> There have been many questions on and off the mailing list about how
> exactly the bootwrapper is used for embedded targets. Add some
> documentation and help text to try and clarify the system.
> =
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> =
> Documentation/powerpc/bootwrapper.txt | 78
+++++++++++++++++++++++++++++++++
> arch/powerpc/Makefile | 15 ++++++
> arch/powerpc/boot/wrapper | 4 ++
> 3 files changed, 96 insertions(+), 1 deletions(-)
> =
> diff --git a/Documentation/powerpc/bootwrapper.txt
b/Documentation/powerpc/bootwrapper.txt
> new file mode 100644
> index 0000000..8dcb560
> --- /dev/null
> +++ b/Documentation/powerpc/bootwrapper.txt
> @@ -0,0 +1,78 @@
> +The PowerPC boot wrapper
> +------------------------
> +Copyright (C) Secret Lab Technologies Ltd.
> +
> +PowerPC image targets compresses and wraps the kernel image (vmlinux)
with
> +a boot wrapper to make it usable by the system firmware. There is no
> +standard PowerPC firmware interface, so the boot wrapper is designed
to
> +be adaptable for each kind of image that needs to be built.
> +
> +The boot wrapper can be found in the arch/powerpc/boot/ directory.
The
> +Makefile in that directory has targets for all the available image
types.
> +Currently, the following image targets exist:
> +
> + cuImage.%: Backwards compatible uImage for older
version of
> + U-Boot (for versions that don't understand the
device
> + tree). This image embeds a device tree blob
inside
> + the image.
> + dtbImage.%: Similar to zImage, except device tree
blob is embedded
> + inside the image.
> + simpleImage.%: Firmware independent compressed image that does
not
> + depend on any particular firmware interface and
embeds
> + a device tree blob. This image can be loaded to
any
> + location in RAM and jumped to. Firmware cannot
pass
> + any configuration data to the kernel with this
image
> + type and the kernel depends on the device tree
to
> + determine its console device.
> + treeImage.%; Image format for some versions of ppc4xx
firmware (non
> + U-Boot firmware). This image embeds a device
tree
> + blob inside the image.
> + uImage: Native image format used by U-Boot. The uImage
target
> + does not add any boot code. It just wraps a
compressed
> + vmlinux in the uImage data structure.
> + zImage.%: Image usable by OpenFirmware. Image expects
firmware
> + to provide the device tree using OpenFirmware
> + interfaces. Typically general purpose hardware
uses
> + this image format.
> +
> +Image types which embed a device tree blob (simpleImage, dtbImage,
treeImage,
> +and cuImage) all generate the device tree blob from a file in the
> +arch/powerpc/boot/dts/ directory. The Makefile selects the correct
device
> +tree source based on the name of the target. Therefore, if the
kernel is
> +built with 'make treeImage.walnut simpleImage.virtex405-ml403', then
the
> +build system will use arch/powerpc/boot/dts/walnut.dts to build
> +treeImage.walnut and arch/powerpc/boot/dts/virtex405-ml403.dts to
build
> +the simpleImage.virtex405-ml403.
> +
> +Two special targets called 'zImage' and 'zImage.initrd' also exist.
These
> +targets build all the default images as selected by the kernel
configuration.
> +Default images are selected by the boot wrapper Makefile
> +(arch/powerpc/boot/Makefile) by adding targets to the $image-y
variable. Look
> +at the Makefile to see which default image targets are available.
> +
> +How it is built
> +---------------
> +arch/powerpc is designed to support multiplatform kernels, which
means
> +that a single vmlinux image can be booted on many different target
boards.
> +It also means that the boot wrapper must be able to wrap for many
kinds of
> +images on a single build. The design decision was made to not use
any
> +conditional compilation code (#ifdef, etc) in the boot wrapper source
code.
> +All of the boot wrapper pieces are buildable at any time regardless
of the
> +kernel configuration. Building all the wrapper bits on every kernel
build
> +also ensures that obscure parts of the wrapper are at the very least
compile
> +tested in a large variety of environments.
> +
> +The wrapper is adapted for different image types at link time by
linking in
> +just the wrapper bits that are appropriate for the image type. The
'wrapper'
> +script (found in arch/powerpc/boot/wrapper) is called by the Makefile
and
> +is responsible for selecting the correct wrapper bits for the image
type.
> +The arguments are well documented in the script's comment block, so
they
> +are not repeated here. However, it is worth mentioning that the
script
> +uses the -p (platform) argument as the main method of deciding which
wrapper
> +bits to compile in. Look for the large 'case "$platform" in' block
in the
> +middle of the script. This is also the place where platform specific
fixups
> +can be selected by changing the link order.
> +
> +In particular, care should be taken when working with cuImages.
cuImage
> +wrapper bits are very board specific and care should be taken to make
sure
> +the target you are trying to build is supported by the wrapper bits.
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index b7d4c4c..754c7eb 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -169,12 +169,25 @@ bootwrapper_install %.dtb:
> $(Q)$(MAKE) ARCH=3Dppc64 $(build)=3D$(boot) $(patsubst
%,$(boot)/%,$@)
> =
> define archhelp
> - @echo '* zImage - Compressed kernel image
(arch/$(ARCH)/boot/zImage.*)'
> + @echo '* zImage - Build default images selected by kernel
config'
> + @echo ' zImage.* - Compressed kernel image
(arch/$(ARCH)/boot/zImage.*)'
> + @echo ' uImage - U-Book native image format'
> + @echo ' cuImage.<dt> - Backwards compatible U-Boot image for
older'
> + @echo ' versions which do not support device
trees'
> + @echo ' dtbImage.<dt> - zImage with an embedded device tree
blob'
> + @echo ' simpleImage.<dt> - Firmware independant image.'
> + @echo ' treeImage.<dt> - Support for older IBM 4xx firmware (not
U-Boot)'
> @echo ' install - Install kernel using'
> @echo ' (your) ~/bin/installkernel or'
> @echo ' (distribution) /sbin/installkernel or'
> @echo ' install to $$(INSTALL_PATH) and run
lilo'
> @echo ' *_defconfig - Select default config from
arch/$(ARCH)/configs'
> + @echo ''
> + @echo ' Targets with <dt> embed a device tree blob inside the
image'
> + @echo ' These targets support board with firmware that does not'
> + @echo ' support passing a device tree directly. Replace <dt> with
the'
> + @echo ' name of a dts file from the arch/$(ARCH)/boot/dts/
directory'
> + @echo ' (minus the .dts extension).'
> endef
> =
> install:
> diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
> index d6c96d9..7cd4182 100755
> --- a/arch/powerpc/boot/wrapper
> +++ b/arch/powerpc/boot/wrapper
> @@ -203,6 +203,10 @@ simpleboot-virtex405-*)
> platformo=3D"$object/virtex405-head.o $object/simpleboot.o"
> binary=3Dy
> ;;
> +simpleboot-*)
> + platformo=3D"$object/simpleboot.o"
> + binary=3Dy
> + ;;
> esac
> =
> vmz=3D"$tmpdir/`basename \"$kernel\"`.$ext"
> =
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [PATCH 52/60] microblaze_v4: fcntl.h sockios.h ucontext.h
From: Arnd Bergmann @ 2008-06-26 16:46 UTC (permalink / raw)
To: monstr
Cc: linux-arch, alan, Michal Simek, vapier.adi, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, John.Linn, john.williams
In-Reply-To: <200806261743.10441.arnd@arndb.de>
On Thursday 26 June 2008, Arnd Bergmann wrote:
> On Thursday 26 June 2008, monstr@seznam.cz wrote:
> > =A0include/asm-generic/sockios.h =A0 =A0 | =A0 23 +++++++++++++++++++++=
++
> > =A0include/asm-generic/ucontext.h =A0 =A0| =A0 24 +++++++++++++++++++++=
+++
> > =A0include/asm-microblaze/fcntl.h =A0 =A0| =A0 =A01 +
> > =A0include/asm-microblaze/sockios.h =A0| =A0 23 +++++++++++++++++++++++
> > =A0include/asm-microblaze/ucontext.h | =A0 =A01 +
>=20
> Also, the sockios file here looks like it should be in asm-generic.
I just realized that you are adding the same sockios file to both
asm-generic and asm-microblaze, so I guess that is just an oversight
and you meant the microblaze file to be just a redirection.
Note that when you add an asm-generic header file that contains
a user interface, you need to add it to asm-generic/Kbuild as well
in order to get it installed correctly with make headers_install.
Running make headers_check should tell you about this problem if
it exists in other places.
Arnd <><
^ permalink raw reply
* Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic
From: Arnd Bergmann @ 2008-06-26 16:38 UTC (permalink / raw)
To: Adrian Bunk
Cc: linux-arch, alan, Michal Simek, vapier.adi, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, monstr, John.Linn, john.williams
In-Reply-To: <20080626162118.GG22025@cs181140183.pp.htv.fi>
On Thursday 26 June 2008, Adrian Bunk wrote:
> The comment could be nuked (as well as the #ifdef __KERNEL__), but for
> the one #define an asm-generic header would IMHO be overkill.
I agree that it doesn't technically make sense to have a one-line
asm-generic header, but I like the idea of reducing the number of
asm/*.h files that actually contain anything other that
#include <asm-generic/$FILE.h>, mostly for documentation purposes.
If we can eventually agree on a way to get rid of the requirement
for explicit redirection, we can remove a larger number of source
files completely.
Arnd <><
^ permalink raw reply
* Re: [PATCH 08/60] microblaze_v4: exception handling
From: Ray Lee @ 2008-06-26 16:35 UTC (permalink / raw)
To: monstr
Cc: linux-arch, alan, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, John.Linn, john.williams
In-Reply-To: <1214483429-32360-9-git-send-email-monstr@seznam.cz>
On Thu, Jun 26, 2008 at 5:29 AM, <monstr@seznam.cz> wrote:
> +ex_sw:
> + /* Get the destination register number into r5 */
> + lbui r5, r0, ex_reg_op;
> + /* Form store_word jump table offset (sw_table + (8 * regnum)) */
> + la r6, r0, sw_table;
> + add r5, r5, r5;
> + add r5, r5, r5;
> + add r5, r5, r5;
> + add r5, r5, r6;
> + bra r5;
Possibly stupid question: This is part of the unaligned store word
exception handler, yes? Shouldn't the above add's be addk's to
preserve the state of the carry register pre/post store?
^ permalink raw reply
* Re: [PATCH 59/60] microblaze_v4: syscall_table.S and unistd.h
From: Arnd Bergmann @ 2008-06-26 16:31 UTC (permalink / raw)
To: monstr
Cc: linux-arch, alan, Michal Simek, vapier.adi, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, John.Linn, john.williams
In-Reply-To: <1214483429-32360-60-git-send-email-monstr@seznam.cz>
On Thursday 26 June 2008, monstr@seznam.cz wrote:
> From: Michal Simek <monstr@monstr.eu>
>
>
> Signed-off-by: Michal Simek <monstr@monstr.eu>
> ---
> arch/microblaze/kernel/syscall_table.S | 330 +++++++++++++++++++++++++++
> include/asm-microblaze/unistd.h | 390 ++++++++++++++++++++++++++++++++
> 2 files changed, 720 insertions(+), 0 deletions(-)
> create mode 100644 arch/microblaze/kernel/syscall_table.S
> create mode 100644 include/asm-microblaze/unistd.h
The two tables don't seem to match:
> diff --git a/arch/microblaze/kernel/syscall_table.S b/arch/microblaze/kernel/syscall_table.S
> new file mode 100644
> index 0000000..0ffa19e
> --- /dev/null
> +++ b/arch/microblaze/kernel/syscall_table.S
> @@ -0,0 +1,330 @@
> +ENTRY(sys_call_table)
> + .long sys_restart_syscall /* 0 - old "setup()" system call,
> + * used for restarting */
> + .long sys_exit
> + .long sys_ni_syscall /* was fork */
You still set __NR_fork. There is no point defining the number if you
can't actually call the syscall in the first place.
I'd suggest leaving out the definitions for these from unistd.h and
removing the comments. Who cares what the syscall was on an architecture
that you're not running?
> + .long sys_read
> + .long sys_write
> + .long sys_open /* 5 */
> + .long sys_close
> + .long sys_waitpid
> + .long sys_creat
> + .long sys_link
> + .long sys_unlink /* 10 */
> + .long sys_execve_wrapper
> + .long sys_chdir
> + .long sys_time
> + .long sys_mknod
> + .long sys_chmod /* 15 */
> + .long sys_lchown
> + .long sys_ni_syscall /* old break syscall holder */
> + .long sys_ni_syscall /* stat */
also __NR_break and __NR_oldstat
> + .long sys_lseek
> + .long sys_getpid /* 20 */
> + .long sys_mount
> + .long sys_oldumount
What applications depend on oldumount?
> + .long sys_setuid
> + .long sys_getuid
> + .long sys_stime /* 25 */
> + .long sys_ptrace
> + .long sys_alarm
> + .long sys_ni_syscall /* fstat */
> + .long sys_pause
> + .long sys_utime /* 30 */
> + .long sys_ni_syscall /* old stty syscall holder */
> + .long sys_ni_syscall /* old gtty syscall holder */
and __NR_stty and __NR_gtty
> + .long sys_access
> + .long sys_nice
> + .long sys_ni_syscall /* 35 - old ftime syscall holder */
and __NR_ftime
> + .long sys_sync
> + .long sys_kill
> + .long sys_rename
> + .long sys_mkdir
> + .long sys_rmdir /* 40 */
> + .long sys_dup
> + .long sys_pipe
> + .long sys_times
> + .long sys_ni_syscall /* old prof syscall holder */
and __NR_prof
> + .long sys_brk /* 45 */
> + .long sys_setgid
> + .long sys_getgid
> + .long sys_signal
> + .long sys_geteuid
> + .long sys_getegid /* 50 */
> + .long sys_acct
> + .long sys_umount /* recycled never used phys() */
> + .long sys_ni_syscall /* old lock syscall holder */
and __NR_lock
> + .long sys_ioctl
> + .long sys_fcntl /* 55 */
> + .long sys_ni_syscall /* old mpx syscall holder */
> + .long sys_setpgid
> + .long sys_ni_syscall /* old ulimit syscall holder */
> + .long sys_ni_syscall /* olduname */
and __NR_mpx, __NR_ulimit and __NR_olduname
> + .long sys_umask /* 60 */
> + .long sys_chroot
> + .long sys_ustat
> + .long sys_dup2
> + .long sys_getppid
> + .long sys_getpgrp /* 65 */
> + .long sys_setsid
> + .long sys_sigaction
> + .long sys_sgetmask
> + .long sys_ssetmask
> + .long sys_setreuid /* 70 */
> + .long sys_setregid
> + .long sys_sigsuspend_wrapper
> + .long sys_sigpending
> + .long sys_sethostname
> + .long sys_setrlimit /* 75 */
> + .long sys_ni_syscall /* old_getrlimit */
> + .long sys_getrusage
> + .long sys_gettimeofday
> + .long sys_settimeofday
> + .long sys_getgroups /* 80 */
> + .long sys_setgroups
> + .long sys_ni_syscall /* old_select */
> + .long sys_symlink
> + .long sys_ni_syscall /* lstat */
Three more: getrlimit, select, oldlstat
> + .long sys_readlink /* 85 */
> + .long sys_uselib
Why do you need uselib?
> + .long sys_swapon
> + .long sys_reboot
> + .long sys_ni_syscall /* old_readdir */
again: remove __NR_readdir
> + .long sys_mmap /* 90 */ /* old_mmap */
What does the comment tell us?
> + .long sys_munmap
> + .long sys_truncate
> + .long sys_ftruncate
> + .long sys_fchmod
> + .long sys_fchown /* 95 */
> + .long sys_getpriority
> + .long sys_setpriority
> + .long sys_ni_syscall /* old profil syscall holder */
> + .long sys_statfs
> + .long sys_fstatfs /* 100 */
> + .long sys_ni_syscall /* ioperm */
kill __NR_profil and __NR_ioperm
> + .long sys_socketcall
> + .long sys_syslog /* operation with system console */
That comment seems pointless here
> + .long sys_setitimer
> + .long sys_getitimer /* 105 */
> + .long sys_newstat
> + .long sys_newlstat
> + .long sys_newfstat
> + .long sys_ni_syscall /* uname */
> + .long sys_ni_syscall /* 110 */ /* iopl */
> + .long sys_vhangup
> + .long sys_ni_syscall /* old "idle" system call */
> + .long sys_ni_syscall /* old sys_vm86old */
kill __NR_olduname, __NR_iopl, __NR_idle and __NR_vm86old
> + .long sys_wait4
> + .long sys_swapoff /* 115 */
> + .long sys_sysinfo
> + .long sys_ipc
> + .long sys_fsync
> + .long sys_sigreturn_wrapper
> + .long sys_clone_wrapper /* 120 */
> + .long sys_setdomainname
> + .long sys_newuname
> + .long sys_ni_syscall /* modify_ldt */
> + .long sys_adjtimex
> + .long sys_ni_syscall /* 125: sys_mprotect */
> + .long sys_sigprocmask
> + .long sys_ni_syscall /* old "create_module" */
> + .long sys_init_module
> + .long sys_delete_module
> + .long sys_ni_syscall /* 130: old "get_kernel_syms" */
kill __NR_modify_ldt, __NR_mprotect, __NR_create_module and __NR_get_kernel_syms
> + .long sys_quotactl
> + .long sys_getpgid
> + .long sys_fchdir
> + .long sys_bdflush
> + .long sys_sysfs /* 135 */
> + .long sys_personality
> + .long sys_ni_syscall /* reserved for afs_syscall */
afs_syscall is not going to make it into the kernel, so no need to
define __NR_afs_syscall.
> + .long sys_setfsuid
> + .long sys_setfsgid
> + .long sys_llseek /* 140 */
> + .long sys_getdents
> + .long sys_select
> + .long sys_flock
> + .long sys_ni_syscall /* sys_msync */
> + .long sys_readv /* 145 */
> + .long sys_writev
> + .long sys_getsid
> + .long sys_fdatasync
> + .long sys_sysctl
> + .long sys_ni_syscall /* 150: sys_mlock */
> + .long sys_ni_syscall /* sys_munlock */
> + .long sys_ni_syscall /* sys_mlockall */
> + .long sys_ni_syscall /* sys_munlockall */
How about killing all of these mmu specific syscall numbers
right now, so you can add them as a nice block later when
you add mmu support to the kernel?
> + .long sys_sched_setparam
> + .long sys_sched_getparam /* 155 */
> + .long sys_sched_setscheduler
> + .long sys_sched_getscheduler
> + .long sys_sched_yield
> + .long sys_sched_get_priority_max
> + .long sys_sched_get_priority_min /* 160 */
> + .long sys_sched_rr_get_interval
> + .long sys_nanosleep
> + .long sys_ni_syscall /* sys_mremap */
__NR_mremap fits in there as well.
> + .long sys_setresuid
> + .long sys_getresuid /* 165 */
> + .long sys_ni_syscall /* sys_vm86 */
> + .long sys_ni_syscall /* Old sys_query_module */
__NR_vm86 and __NR_query_module can never be implemented, so kill them.
> + .long sys_poll
> + .long sys_nfsservctl
> + .long sys_setresgid /* 170 */
> + .long sys_getresgid
> + .long sys_prctl
> + .long sys_rt_sigreturn_wrapper
> + .long sys_rt_sigaction
> + .long sys_rt_sigprocmask /* 175 */
> + .long sys_rt_sigpending
> + .long sys_rt_sigtimedwait
> + .long sys_rt_sigqueueinfo
> + .long sys_rt_sigsuspend_wrapper
> + .long sys_pread64 /* 180 */
> + .long sys_pwrite64
> + .long sys_chown
> + .long sys_getcwd
> + .long sys_capget
> + .long sys_capset /* 185 */
> + .long sys_ni_syscall /* sigaltstack */
> + .long sys_sendfile
> + .long sys_ni_syscall /* reserved for streams1 */
> + .long sys_ni_syscall /* reserved for streams2 */
same for streams support.
For sigaltstack, you define both the syscall number and the function,
but not the sys_call_table entry, so it's not actually usable.
I suggest killing the implementation.
> + .long sys_vfork_wrapper /* 190 */
> + .long sys_getrlimit
> + .long sys_mmap2 /* mmap2 */
> + .long sys_truncate64
> + .long sys_ftruncate64
> + .long sys_stat64 /* 195 */
> + .long sys_lstat64
> + .long sys_fstat64
> + .long sys_lchown
> + .long sys_getuid
> + .long sys_getgid /* 200 */
> + .long sys_geteuid
> + .long sys_getegid
> + .long sys_setreuid
> + .long sys_setregid
> + .long sys_getgroups /* 205 */
> + .long sys_setgroups
> + .long sys_fchown
> + .long sys_setresuid
> + .long sys_getresuid
> + .long sys_setresgid /* 210 */
> + .long sys_getresgid
> + .long sys_chown
> + .long sys_setuid
> + .long sys_setgid
> + .long sys_setfsuid /* 215 */
> + .long sys_setfsgid
> + .long sys_pivot_root
> + .long sys_ni_syscall /* sys_mincore */
> + .long sys_ni_syscall /* sys_madvise */
These go with the other mmu syscalls.
> + .long sys_getdents64 /* 220 */
> + .long sys_fcntl64
> + .long sys_ni_syscall /* reserved for TUX */
> + .long sys_ni_syscall
> + .long sys_gettid
> + .long sys_readahead /* 225 */
> + .long sys_setxattr
> + .long sys_lsetxattr
> + .long sys_fsetxattr
> + .long sys_getxattr
> + .long sys_lgetxattr /* 230 */
> + .long sys_fgetxattr
> + .long sys_listxattr
> + .long sys_llistxattr
> + .long sys_flistxattr
> + .long sys_removexattr /* 235 */
> + .long sys_lremovexattr
> + .long sys_fremovexattr
> + .long sys_tkill
> + .long sys_sendfile64
> + .long sys_futex /* 240 */
> + .long sys_sched_setaffinity
> + .long sys_sched_getaffinity
> + .long sys_ni_syscall /* set_thread_area */
> + .long sys_ni_syscall /* get_thread_area */
same for these two
> + .long sys_io_setup /* 245 */
> + .long sys_io_destroy
> + .long sys_io_getevents
> + .long sys_io_submit
> + .long sys_io_cancel
> + .long sys_fadvise64 /* 250 */
> + .long sys_ni_syscall
> + .long sys_exit_group
> + .long sys_lookup_dcookie
> + .long sys_epoll_create
> + .long sys_epoll_ctl /* 255 */
> + .long sys_epoll_wait
> + .long sys_ni_syscall /* sys_remap_file_pages */
and this one
> + .long sys_set_tid_address
> + .long sys_timer_create
> + .long sys_timer_settime /* 260 */
> + .long sys_timer_gettime
> + .long sys_timer_getoverrun
> + .long sys_timer_delete
> + .long sys_clock_settime
> + .long sys_clock_gettime /* 265 */
> + .long sys_clock_getres
> + .long sys_clock_nanosleep
> + .long sys_statfs64
> + .long sys_fstatfs64
> + .long sys_tgkill /* 270 */
> + .long sys_utimes
> + .long sys_fadvise64_64
> + .long sys_ni_syscall /* sys_vserver */
Everyone seems to define __NR_vserver for a possible future extension,
so just leave this one in.
> + .long sys_mbind
> + .long sys_get_mempolicy
> + .long sys_set_mempolicy
> + .long sys_mq_open
> + .long sys_mq_unlink
> + .long sys_mq_timedsend
> + .long sys_mq_timedreceive /* 280 */
> + .long sys_mq_notify
> + .long sys_mq_getsetattr
> + .long sys_kexec_load
> + .long sys_waitid
> + .long sys_ni_syscall /* 285 */ /* available */
You define __NR_setaltroot 285, so I wouldn't call it available.
Better not define the number and also not reuse the syscall.
> + .long sys_add_key
> + .long sys_request_key
> + .long sys_keyctl
> + .long sys_ioprio_set
> + .long sys_ioprio_get /* 290 */
> + .long sys_inotify_init
> + .long sys_inotify_add_watch
> + .long sys_inotify_rm_watch
> + .long sys_ni_syscall /* sys_migrate_pages */
> + .long sys_ni_syscall /* 295 */ /* sys_openat */
> + .long sys_ni_syscall /* sys_mkdirat */
> + .long sys_ni_syscall /* sys_mknodat */
> + .long sys_ni_syscall /* sys_fchownat */
> + .long sys_ni_syscall /* sys_futimesat */
> + .long sys_ni_syscall /* 300 */ /* sys_fstatat64 */
> + .long sys_ni_syscall /* sys_unlinkat */
> + .long sys_ni_syscall /* sys_renameat */
> + .long sys_ni_syscall /* sys_linkat */
> + .long sys_ni_syscall /* sys_symlinkat */
> + .long sys_ni_syscall /* 305 */ /* sys_readlinkat */
> + .long sys_ni_syscall /* sys_fchmodat */
> + .long sys_ni_syscall /* sys_faccessat */
> + .long sys_ni_syscall /* pselect6 */
> + .long sys_ni_syscall /* ppoll */
> + .long sys_ni_syscall /* 310 */ /* sys_unshare */
> + .long sys_ni_syscall /* sys_set_robust_list */
> + .long sys_ni_syscall /* sys_get_robust_list */
> + .long sys_ni_syscall /* sys_splice */
> + .long sys_ni_syscall /* sys_sync_file_range */
> + .long sys_ni_syscall /* 315 */ /* sys_tee */
> + .long sys_ni_syscall /* sys_vmsplice */
All of these should definitely be activated, with the exception
of __NR_futimesat, which has already been superceded by
__NR_utimensat, so you don't need to introduce it now.
> + .long sys_move_pages
> + .long sys_getcpu
> + .long sys_epoll_pwait
> + .long sys_utimensat /* 320 */
> + .long sys_signalfd
> + .long sys_timerfd_create
> + .long sys_eventfd
> + .long sys_fallocate
> + .long sys_semtimedop /* 325 */
Up to this point, you follow the numbering scheme from x86, so why
do you stop here? x86 does not define semtimedop but rather implements
it in sys_ipc.
> + .long sys_timerfd_settime
> + .long sys_timerfd_gettime
> +#define __ARCH_WANT_IPC_PARSE_VERSION
I'm pretty sure that no application uses IPC versioning on microblaze,
so just leave this out.
> +/* #define __ARCH_WANT_OLD_READDIR */
> +/* #define __ARCH_WANT_OLD_STAT */
> +#define __ARCH_WANT_STAT64
> +#define __ARCH_WANT_SYS_ALARM
> +#define __ARCH_WANT_SYS_GETHOSTNAME
You don't have sys_gethostname in your sys_call_table, so you can
remove this.
> +#define __ARCH_WANT_SYS_PAUSE
> +#define __ARCH_WANT_SYS_SGETMASK
> +#define __ARCH_WANT_SYS_SIGNAL
> +#define __ARCH_WANT_SYS_TIME
> +#define __ARCH_WANT_SYS_UTIME
> +#define __ARCH_WANT_SYS_WAITPID
These are in all your table, but are you sure that uClibc uses them?
If you have built with your current unistd.h, a modern libc should
not add calls to these.
> +#define __ARCH_WANT_SYS_SOCKETCALL
This one (along with sys_ipc) is unfortunate, there simply
isn't a way to get around it without rebuilding your libc.
OTOH, I have seen that you are now using UID32 as I suggested,
so it seems you have already given up on full binary compatibility
and only care about source level compatibility at this point, right?
> +#define __ARCH_WANT_SYS_FADVISE64
Which one does uClibc use? fadvise, fadvise64 or fadvise64_64?
> +#define __ARCH_WANT_SYS_GETPGRP
> +#define __ARCH_WANT_SYS_LLSEEK
> +#define __ARCH_WANT_SYS_NICE
> +#define __ARCH_WANT_SYS_OLDUMOUNT
Same as the list above, do you really need them for compatibility?
> +#define __ARCH_WANT_SYS_SIGPENDING
> +#define __ARCH_WANT_SYS_SIGPROCMASK
> +#define __ARCH_WANT_SYS_RT_SIGACTION
For these, it seems that they are required, it is just unfortunate
that the logic in the kernel requires them to be set to do the right
thing, instead of left out to get it right, like the others.
Arnd <><
^ permalink raw reply
* Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic
From: Adrian Bunk @ 2008-06-26 16:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch, alan, Michal Simek, vapier.adi, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, monstr, John.Linn, john.williams
In-Reply-To: <200806261735.12738.arnd@arndb.de>
On Thu, Jun 26, 2008 at 05:35:11PM +0200, Arnd Bergmann wrote:
> On Thursday 26 June 2008, monstr@seznam.cz wrote:
> > +
> > +#ifndef _ASM_MICROBLAZE_NAMEI_H
> > +#define _ASM_MICROBLAZE_NAMEI_H
> > +
> > +#ifdef __KERNEL__
> > +
> > +/* This dummy routine maybe changed to something useful
> > + * for /usr/gnemul/ emulation stuff.
> > + * Look at asm-sparc/namei.h for details.
> > + */
> > +#define __emul_prefix() NULL
> > +
> > +#endif /* __KERNEL__ */
> > +
> > +#endif /* _ASM_MICROBLAZE_NAMEI_H */
>
> Could you move this to asm-generic? Note that the comment is wrong,
> asm-sparc doesn't actually implement it any more, only ia64, mips and
> arm have an implementation that actually does something interesting
> here.
The comment could be nuked (as well as the #ifdef __KERNEL__), but for
the one #define an asm-generic header would IMHO be overkill.
> Arnd <><
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH 58/60] microblaze_v4: sys_microblaze.c
From: Arnd Bergmann @ 2008-06-26 16:04 UTC (permalink / raw)
To: monstr
Cc: linux-arch, alan, Michal Simek, vapier.adi, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, John.Linn, john.williams
In-Reply-To: <1214483429-32360-59-git-send-email-monstr@seznam.cz>
On Thursday 26 June 2008, monstr@seznam.cz wrote:
> +
> +int sys_uname(struct old_utsname *name)
> +{
> +=A0=A0=A0=A0=A0=A0=A0int err =3D -EFAULT;
> +
> +=A0=A0=A0=A0=A0=A0=A0down_read(&uts_sem);
> +=A0=A0=A0=A0=A0=A0=A0if (name && !copy_to_user(name, utsname(), sizeof(*=
name)))
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0err =3D 0;
> +=A0=A0=A0=A0=A0=A0=A0up_read(&uts_sem);
> +=A0=A0=A0=A0=A0=A0=A0return err;
> +}
This actually seems to be dead code, as your sys_call_table only contains
sys_newuname but not sys_uname.
Arnd <><
^ permalink raw reply
* Re: [PATCH] powerpc: add of_find_next_property and of_get_aliased_index
From: Timur Tabi @ 2008-06-26 15:55 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200806261751.05379.sr@denx.de>
Stefan Roese wrote:
> On Thursday 26 June 2008, Timur Tabi wrote:
>>> The only thing a platform should ever use aliases for is if it needs
>>> to (for whatever purpose) find a specific device, that it cannot
>>> identify otherwise (via "reg", ...). And then that platform code
>>> should look up the device by the alias, not look up the alias by the
>>> device -- there is no 1-1 mapping from device to alias!
>> Hmmm, I hadn't through about that. I guess this patch isn't such a great
>> idea after all. I rescind it.
>
> Too bad. So now we're back to where we started with the discussion
> about "cell-index" vs. "index" vs. no index on I2C device nodes. :-(
Well, there's a lot of disagreement on this subject. Not only do we not agree
on a method of enumerating devices, a lot of people have a problem with the
concept of enumerating them in the first place!
This whole thing started with a problem I had in ASoC V2: identifying an I2C
device by name and number. Scott W. pointed out that all I need in my "fabric
driver" is a pointer to the i2c_adapter structure that the I2C driver was using.
If we create a link from the I2C device node to its matching i2c_adapter
structure, then I won't care what the adapter/bus number is. Unfortunately, it
appears the current I2C code in fsl_soc.c can't handle that, but of_i2c.c can.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc: add of_find_next_property and of_get_aliased_index
From: Stefan Roese @ 2008-06-26 15:51 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <4863B1C1.1060300@freescale.com>
On Thursday 26 June 2008, Timur Tabi wrote:
> > The only thing a platform should ever use aliases for is if it needs
> > to (for whatever purpose) find a specific device, that it cannot
> > identify otherwise (via "reg", ...). And then that platform code
> > should look up the device by the alias, not look up the alias by the
> > device -- there is no 1-1 mapping from device to alias!
>
> Hmmm, I hadn't through about that. I guess this patch isn't such a great
> idea after all. I rescind it.
Too bad. So now we're back to where we started with the discussion
about "cell-index" vs. "index" vs. no index on I2C device nodes. :-(
Best regards,
Stefan
^ 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