How to using TSEC in u-boot ?
hello all now we are using Rtl821Xb Giga PHY , i am finding driver/net/tsec.c in u-boot ,there is most phy testing function ,but i donot known how to using tsec ? Qiaofeng Tech Co; leowang 2009:03:02 ___ 好玩贺卡等你发，邮箱贺卡全新上线！ http://card.mail.cn.yahoo.com/___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
On Mon, 2 Mar 2009 10:54:14 +0100 (CET) Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote: Indeed. You can have a working RTC class driver for lots of hardware by just writing ca. 100 lines of code on top of the generic framework. That's true, but we would then have two generic frameworks. And one of them will have its code scattered all around the kernel. So you either use the old rtc framework, which is perfectly functional, or you move to the new rtc lass and write the drivers. Layering a generic framework over another generic framework is quite a nonsense . -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
On Mon, 2 Mar 2009, Alessandro Zummo wrote: On Mon, 2 Mar 2009 10:54:14 +0100 (CET) Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote: Indeed. You can have a working RTC class driver for lots of hardware by just writing ca. 100 lines of code on top of the generic framework. That's true, but we would then have two generic frameworks. And one of them will have its code scattered all around the kernel. So you either use the old rtc framework, which is perfectly functional, or you move to the new rtc lass and write the drivers. So I can solve my problem (autoloading the RTC driver on PS3 by udev) by converting the old genrtc driver into a platform device driver and creating platform devices where appropriate. However, this doesn't solve the distro's problem: as the old RTC framework depends on RTC_LIB=n, you cannot have both old and new RTC drivers in your (single) distro kernel. That's why dmwm2 created drivers/rtc/rtc-ppc.c: Fedora had to support machines with both old and new RTC drivers. As all of the old drivers are actually behind the ppc_md.[sg]et_rtc_time() abstraction, this was very easy. Hence it's all or nothing, and we have to convert all of them. drivers/rtc/rtc-generic.c would allow to have a working system without old RTC drivers, until all low-level code has been converted to individual RTC drivers. Layering a generic framework over another generic framework is quite a nonsense . IMHO these two generic frameworks are quite different: [sg]et_rtc_time() abstracts the low-level RTC hardware interface, while RTC class handles the interaction with userspace. With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: geert.uytterhoe...@sonycom.com Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
On Mon, 2 Mar 2009 11:28:01 +0100 (CET) Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote: So I can solve my problem (autoloading the RTC driver on PS3 by udev) by converting the old genrtc driver into a platform device driver and creating platform devices where appropriate. yes. btw, if you are building a kernel specific for the PS3, I would compile the rtc driver statically, otherwise it won't be available early on boot. However, this doesn't solve the distro's problem: as the old RTC framework depends on RTC_LIB=n, you cannot have both old and new RTC drivers in your (single) distro kernel. That's why dmwm2 created drivers/rtc/rtc-ppc.c: Fedora had to support machines with both old and new RTC drivers. As all of the old drivers are actually behind the ppc_md.[sg]et_rtc_time() abstraction, this was very easy. ok, generic kernel. you will have to load the modules on initrd. no, sadly you can't have both of them. you might stick with the old interface or convert them all. Hence it's all or nothing, and we have to convert all of them. drivers/rtc/rtc-generic.c would allow to have a working system without old RTC drivers, until all low-level code has been converted to individual RTC drivers. I know but I have enough experience to foresee that once a generic over generic framework is in place it's very hard to get rid of it because people will have no incentives. If you really need rtc-generic you can keep using it even if it's not in the kernel, distributions often have their specific set of kernel patches. But I'd strongly suggest to plan and execute a conversion process. Layering a generic framework over another generic framework is quite a nonsense . IMHO these two generic frameworks are quite different: [sg]et_rtc_time() abstracts the low-level RTC hardware interface, while RTC class handles the interaction with userspace. When I wrote it my intention was to make it as an abstraction _between_ the userspace and the hardware according to the platform/device model. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PHY not found after migration of gianfar driver to an of_platform_driver
On Sun, 1 Mar 2009 18:15:32 -0700, Grant Likely grant.lik...@secretlab.ca
wrote:
So, what you need is a new adapter which parses the data passed in by
routerboot (maybe call it routerImage?) and modifies the .dtb blob to
match. You can use simpleImage as a starting point.
I had a look at that. And this is what I understood so-far.
SimpleImage just takes the dtb from the segment and parses it as the new
device tree.
_dtb_start = .;
.kernel:dtb : { *(.kernel:dtb) }
_dtb_end = .;
No I do understand that dtb_start points to this device tree. I also know
that the standard kernel boot-process
is able to read he device tree out of the firmware/bootloader (it works if
I just put with a standard kernel image) but I cannot figure out, where
exactly (in the code) it is doing that. My problem is now that I have zero
documentation of the existing bootloader. All I know is that the prom code
is able to find and parse it.
So now my question, is there a way to get to the device tree at this stage
of the boot process?
Can't I just add them in the rbppc.c specific init stuff
programmatically
withouth a DTS file?
You need a device tree. You could theoretically generate the entire
tree programmatically, but that is the long way around. What you want
is a base .dts file and a new bootwrapper to fill in the missing bits
at boot time.
Well the board already provides a device tree so all I would need is the
missing entries so the PHYs are detected correctly. So I would modify an
existing tree.
thanks for your help,
Michael
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull 'next' branch
On Tue, Feb 24, 2009 at 09:08:00AM -0500, Josh Boyer wrote: Hi Ben, Please pull the next branch of the 4xx tree. It has a few small commits for 2.6.30, as well as the 256K page size patch for 44x. Ben, ping? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PHY not found after migration of gianfar driver to an of_platform_driver
On Mon, Mar 2, 2009 at 4:58 AM, Michael Guntsche m...@it-loops.com wrote:
On Sun, 1 Mar 2009 18:15:32 -0700, Grant Likely grant.lik...@secretlab.ca
wrote:
So, what you need is a new adapter which parses the data passed in by
routerboot (maybe call it routerImage?) and modifies the .dtb blob to
match. You can use simpleImage as a starting point.
I had a look at that. And this is what I understood so-far.
SimpleImage just takes the dtb from the segment and parses it as the new
device tree.
_dtb_start = .;
.kernel:dtb : { *(.kernel:dtb) }
_dtb_end = .;
No I do understand that dtb_start points to this device tree. I also know
that the standard kernel boot-process
is able to read he device tree out of the firmware/bootloader (it works if
I just put with a standard kernel image)
Only if the firmware supports passing in a device tree. Many embedded
firmwares do not, in which case the .dtb must be linked into the
bootwrapper statically.
but I cannot figure out, where
exactly (in the code) it is doing that.
Every bootwrapper image (simpleBoot, zImage, cuImage, etc. uImage is
the exception; it doesn't use the bootwarpper) has a function called
platform_init() with the arguments r3, r4, r5, r6, and r7 which hold
the values of those registers when the bootwrapper is called.
platform_init() is called by crt0.S before calling the 'start()' entry
point in main.c and one purpose of it is to adapt the information
available about the board into the device tree.
platform_init is different for each kind of bootwrapper image. In
simpleboot.c, r3-r7 are simply ignored. In a cuImage, a pointer to
the bd_info structure is retrieved from r3 (cuboot.h).
My problem is now that I have zero
documentation of the existing bootloader. All I know is that the prom code
is able to find and parse it.
So now my question, is there a way to get to the device tree at this stage
of the boot process?
You mean like loading it of the CF or something? Yeah, I suppose so
if you wrote a minimal CF driver, but that seems the hard way around
also. You're far better off to statically link in a .dtb image and
modify it. If the bootloader doesn't provide you with any useful
information, you can read the SoC registers to detect memory size and
clock rate. If you're lucky, the bootloader will have already
assigned the correct MAC addresses for you and you can read those out
also.
You can also try inspecting the memory pointed to by r3-r7 and seeing
if any of them point to something interesting.
Can't I just add them in the rbppc.c specific init stuff
programmatically
withouth a DTS file?
You need a device tree. You could theoretically generate the entire
tree programmatically, but that is the long way around. What you want
is a base .dts file and a new bootwrapper to fill in the missing bits
at boot time.
Well the board already provides a device tree so all I would need is the
missing entries so the PHYs are detected correctly. So I would modify an
existing tree.
Oh. So routerboot does understand dtb blobs? Okay, I didn't
understand that. Yes, you can call the libfdt functions in your
platform_init() to add the missing nodes.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add MPC52xx simple interrupt GPIO support
On Thu, Feb 26, 2009 at 10:06:59PM -0700, Grant Likely wrote:
Hi Roman,
Thanks for this work. Comments below.
On Thu, Feb 26, 2009 at 7:24 AM, Roman Fietze
roman.fie...@telemotive.de wrote:
Hello,
I've got a target derived from the Lite5200 that needs to use simple
interrupt GPIO pins. I created a patch to support this kind of GPIO.
I would need your opinion and like to hear any criticism. Esp. the
facts that I ad to split up struct mpc52xx_gpio and that the GPIO
numbering might get mixed up concern me.
While I understand why this patch is written the way it is, I don't
think it is the right approach.
This patch changes the mpc5200 gpio binding to adapt to a Linux
internal implementation detail. Specifically, the of_mm
infrastructure only allows a 1:1 relationship between a 'struct
of_gpio_chip' and a 'struct gpio_chip'. When working with device
trees, this is the wrong way around. The device tree describes the
hardware, not the Linux implementation details.
An argument could be made that the current binding isn't ideal and
that it would be better to split the simple, interrupt and output-only
gpio pins into separate nodes, but that pretty much comes down to a
matter of opinion as the existing binding describes the hardware just
fine. I'm actually of the opinion that it would be better to fewer
gpio nodes, not more, by merging the simple and wakeup pins into a
single node, but what's done is done and there is no technical reason
for changing the current binding.
So, that leaves the problem working with the of_mm infrastructure. I
think the correct solution is to modify of_gpio_chip to hold an array
of struct gpio_chip and to change of_gpio_simple_xlate() to handle it.
Maybe something like:
struct of_gpio_chip {
int gpio_cells;
int (*xlate)(struct of_gpio_chip *of_gc, struct device_node *np,
const void *gpio_spec, enum of_gpio_flags *flags);
struct gpio_chip gc[1];
};
I'd suggest to not touch of_gpio_chip structure, I'd like to keep
of_gpio_chip struct 1:1 bound to a pure gpio_chip structure. This keeps
things simple and understandable on the low level.
And when you need several gpio controllers bound to some Linux struct,
I would rather suggest this:
struct mpc5200_gpio_controller {
void __iomem *regs;
void (*save_regs)(struct of_mm_gpio_chip *mm_gc);
struct of_gpio_chip of_gc[1];
};
In the of_gc-xlate callback you'll always get of_gc[0], but since you
know that this is mpc5200 controller, you can add needed offset depending
on gpio_spec.
(s/mpc5200/of_multi_mm/ or something like this, if you'll manage to
do this for the general case.)
OTOH, there is even more straightforward solution, all you actually need
is to define HW GPIO bindings (which are wkup, which are interrupt, etc.),
and then:
void mpc5200_gpio_set(struct gpio_chip *gc, unsigned int gpio, int value)
{
if (mpc5200_is_wkup(gpio))
write to the wkup registers block;
else if (mpc5200_is_int(gpio))
write to the int registers block;
else
...
}
That is, the same thing we do for the interrupt controllers.
(Note that these ifs can be replaced by a table, as in
arch/powerpc/sysdev/qe_lib/qe_ic.c).
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add MPC52xx simple interrupt GPIO support
On Mon, Mar 2, 2009 at 10:16 AM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
On Thu, Feb 26, 2009 at 10:06:59PM -0700, Grant Likely wrote:
Maybe something like:
struct of_gpio_chip {
int gpio_cells;
int (*xlate)(struct of_gpio_chip *of_gc, struct device_node *np,
const void *gpio_spec, enum of_gpio_flags *flags);
struct gpio_chip gc[1];
};
I'd suggest to not touch of_gpio_chip structure, I'd like to keep
of_gpio_chip struct 1:1 bound to a pure gpio_chip structure. This keeps
things simple and understandable on the low level.
And when you need several gpio controllers bound to some Linux struct,
I would rather suggest this:
struct mpc5200_gpio_controller {
void __iomem *regs;
void (*save_regs)(struct of_mm_gpio_chip *mm_gc);
struct of_gpio_chip of_gc[1];
};
In the of_gc-xlate callback you'll always get of_gc[0], but since you
know that this is mpc5200 controller, you can add needed offset depending
on gpio_spec.
Fair enough. That works too.
OTOH, there is even more straightforward solution, all you actually need
is to define HW GPIO bindings (which are wkup, which are interrupt, etc.),
and then:
void mpc5200_gpio_set(struct gpio_chip *gc, unsigned int gpio, int value)
{
if (mpc5200_is_wkup(gpio))
write to the wkup registers block;
else if (mpc5200_is_int(gpio))
write to the int registers block;
else
...
}
That is, the same thing we do for the interrupt controllers.
Ugh, I'd really do not want to use this approach. The GPIOs path is
too long as is. When GPIOs are used for things like JTAG or other bus
emulation, every cycle counts. As much as possible the long path,
such as figuring out which chip, should be preprocessed so that it is
already known by the time the set/get/direction hooks are called.
IRQ controllers typically need to deal with far lower frequencies on
the IRQ line.
(Note that these ifs can be replaced by a table, as in
arch/powerpc/sysdev/qe_lib/qe_ic.c).
Even with the table it is a cost I don't want in the GPIO handler. If
it were possible to do so, I'd even like to remove the spinlocks from
the hooks, but that isn't an option at the moment.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: add defintion for MSR[GS] to list of MSR bits
Add macros for the GS (guest state) bit to the list of MSR bit definitions. On PowerPC cores that support embedded hypervisor mode, GS is cleared if the system is running in hypervisor state (and MSR[PR] is cleared), and set if it's running in guest state. See the Power ISA 2.06 specification for more information. Signed-off-by: Timur Tabi ti...@freescale.com --- arch/powerpc/include/asm/reg.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h index c6d1ab6..ca5c7f8 100644 --- a/arch/powerpc/include/asm/reg.h +++ b/arch/powerpc/include/asm/reg.h @@ -29,6 +29,7 @@ #define MSR_SF_LG 63 /* Enable 64 bit mode */ #define MSR_ISF_LG 61 /* Interrupt 64b mode valid on 630 */ #define MSR_HV_LG 60 /* Hypervisor state */ +#define MSR_GS_LG 28 /* Guest state */ #define MSR_VEC_LG 25 /* Enable AltiVec */ #define MSR_VSX_LG 23 /* Enable VSX */ #define MSR_POW_LG 18 /* Enable Power Management */ @@ -71,6 +72,7 @@ #define MSR_HV 0 #endif +#define MSR_GS __MASK(MSR_GS_LG) /* Guest state */ #define MSR_VEC__MASK(MSR_VEC_LG) /* Enable AltiVec */ #define MSR_VSX__MASK(MSR_VSX_LG) /* Enable VSX */ #define MSR_POW__MASK(MSR_POW_LG) /* Enable Power Management */ -- 1.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
DTS format for direct SGMII TSEC link?
Hello, I am working with a Freescale 8572 board which uses direct SGMII connections (no real PHY) for three of the four TSECs. I have been trying to figure out the appropriate DTS elements to set this up, but haven't yet managed to figure it out. Everything works great in u-boot, so I know that the connections hardware are functional. I've tried setting up dummy physical phys, using only the tbi-phy, and using the 'fixed-link' property, none of which have achieved the desired result. I realize I'm taking the lazy way out by not digging into the gianfar code, but I was hoping that this problem had already been seen and addressed and could be handled with the right text in the DTS file. Thanks, Aaron Pace ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add defintion for MSR[GS] to list of MSR bits
Add macros for the GS (guest state) bit to the list of MSR bit definitions. On PowerPC cores that support embedded hypervisor mode, GS is cleared if the system is running in hypervisor state (and MSR[PR] is cleared), and set if it's running in guest state. See the Power ISA 2.06 specification for more information. Signed-off-by: Timur Tabi ti...@freescale.com --- arch/powerpc/include/asm/reg.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h Shouldn't this be in reg_booke.h? Mikey index c6d1ab6..ca5c7f8 100644 --- a/arch/powerpc/include/asm/reg.h +++ b/arch/powerpc/include/asm/reg.h @@ -29,6 +29,7 @@ #define MSR_SF_LG63 /* Enable 64 bit mode */ #define MSR_ISF_LG 61 /* Interrupt 64b mode valid on 630 */ #define MSR_HV_LG60 /* Hypervisor state */ +#define MSR_GS_LG28 /* Guest state */ #define MSR_VEC_LG 25 /* Enable AltiVec */ #define MSR_VSX_LG 23 /* Enable VSX */ #define MSR_POW_LG 18 /* Enable Power Management */ @@ -71,6 +72,7 @@ #define MSR_HV 0 #endif +#define MSR_GS __MASK(MSR_GS_LG) /* Guest state */ #define MSR_VEC __MASK(MSR_VEC_LG) /* Enable AltiVec */ #define MSR_VSX __MASK(MSR_VSX_LG) /* Enable VSX */ #define MSR_POW __MASK(MSR_POW_LG) /* Enable Power Managem ent */ -- 1.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add defintion for MSR[GS] to list of MSR bits
Michael Neuling wrote: diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h Shouldn't this be in reg_booke.h? Yes, you're right. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc allnoconfig
On Tue, 03 Mar 2009 13:31:10 +1100 Michael Neuling mi...@neuling.org wrote: make mrproper make allnoconfig make vmlinux gives: scripts/kconfig/conf -s arch/powerpc/Kconfig CHK include/linux/version.h UPD include/linux/version.h CHK include/linux/utsrelease.h UPD include/linux/utsrelease.h SYMLINK include/asm - include/asm-powerpc HOSTCC scripts/ihex2fw HOSTCC scripts/kallsyms HOSTCC scripts/conmakehash CC scripts/mod/empty.o HOSTCC scripts/mod/mk_elfconfig scripts/mod/empty.c:1: error: -m64 requires a PowerPC64 cpu make[2]: *** [scripts/mod/empty.o] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [scripts/mod] Error 2 make[1]: *** Waiting for unfinished jobs make: *** [scripts] Error 2 I can't replicate this with Linus' latest tree with gcc 4.3 or 4.0. ho hum. What's your tool chain? Does it compile 32 or 64bit by default? It's a cross-compiler: http://userweb.kernel.org/~akpm/cross-compilers/ Here's a `make V=1': rm -f include/config/kernel.release echo 2.6.29-rc6 include/config/kernel.release set -e; : ' CHK include/linux/version.h'; mkdir -p include/linux/; (echo \#define LINUX_VERSION_CODE 132637; echo '#define KERNEL_VERSION(a,b,c) (((a) 16) + ((b) 8) + (c))';) /usr/src/25/Makefile include/linux/version.h.tmp; if [ -r include/linux/version.h ] cmp -s include/linux/version.h include/linux/version.h.tmp; then rm -f include/linux/version.h.tmp; else : ' UPD include/linux/version.h'; mv -f include/linux/version.h.tmp include/linux/version.h; fi set -e; : ' CHK include/linux/utsrelease.h'; mkdir -p include/linux/; if [ `echo -n 2.6.29-rc6 | wc -c ` -gt 64 ]; then echo '2.6.29-rc6 exceeds 64 characters' 2; exit 1; fi; (echo \#define UTS_RELEASE \2.6.29-rc6\;) include/config/kernel.release include/linux/utsrelease.h.tmp; if [ -r include/linux/utsrelease.h ] cmp -s include/linux/utsrelease.h include/linux/utsrelease.h.tmp; then rm -f include/linux/utsrelease.h.tmp; else : ' UPD include/linux/utsrelease.h'; mv -f include/linux/utsrelease.h.tmp include/linux/utsrelease.h; fi set -e; if [ -L include/asm ]; then asmlink=`readlink include/asm | cut -d '-' -f 2`; if [ $asmlink != powerpc ]; then echo ERROR: the symlink include/asm points to asm-$asmlink but asm-powerpc was expected; echo set ARCH or save .config and run 'make mrproper' to fix it; exit 1; fi; test -e $asmlink || rm include/asm; elif [ -d include/asm ]; then echo ERROR: include/asm is a directory but a symlink was expected; exit 1; fi make -f scripts/Makefile.build obj=scripts/basic if [ ! -L include/asm ]; then : ' SYMLINK include/asm - include/asm-powerpc'; if [ ! -d include/asm-powerpc ]; then mkdir -p include/asm-powerpc; fi; ln -fsn asm-powerpc include/asm; fi mkdir -p .tmp_versions make -f scripts/Makefile.build obj=scripts make -f scripts/Makefile.build obj=scripts/mod /opt/crosstool/gcc-4.1.0-glibc-2.3.6/powerpc64-unknown-linux-gnu/bin/powerpc64-unknown-linux-gnu-gcc -Wp,-MD,scripts/mod/.empty.o.d -nostdinc -isystem /opt/crosstool/gcc-4.1.0-glibc-2.3.6/powerpc64-unknown-linux-gnu/lib/gcc/powerpc64-unknown-linux-gnu/4.1.0/./include -Iinclude -I/usr/src/25/arch/powerpc/include -include include/linux/autoconf.h -D__KERNEL__ -Iarch/powerpc -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -O2 -msoft-float -pipe -Iarch/powerpc -ffixed-r2 -mmultiple -mno-altivec -mno-spe -mspe=no -funit-at-a-time -mno-string -mcpu=powerpc -Wa,-maltivec -fno-stack-protector -fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(empty) -DKBUILD_MODNAME=KBUILD_STR(empty) -c -o scripts/mod/empty.o scripts/mod/empty.c scripts/mod/empty.c:1: error: -m64 requires a PowerPC64 cpu make[2]: *** [scripts/mod/empty.o] Error 1 make[1]: *** [scripts/mod] Error 2 make: *** [scripts] Error 2 **FAILED** ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc allnoconfig
Hi Andrew, On Mon, 2 Mar 2009 18:40:49 -0800 Andrew Morton a...@linux-foundation.org wrote: It's a cross-compiler: http://userweb.kernel.org/~akpm/cross-compilers/ What does /opt/crosstool/gcc-4.1.0-glibc-2.3.6/powerpc64-unknown-linux-gnu/bin/powerpc64-unknown-linux-gnu-gcc -v say? I suspect you have a 64 bit only compiler and allnoconfig produces a 32 bit kernel. Is this a new error? -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpCEcVOQhvP9.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc allnoconfig
On Tue, 3 Mar 2009 13:52:03 +1100 Stephen Rothwell s...@canb.auug.org.au wrote: Hi Andrew, On Mon, 2 Mar 2009 18:40:49 -0800 Andrew Morton a...@linux-foundation.org wrote: It's a cross-compiler: http://userweb.kernel.org/~akpm/cross-compilers/ What does /opt/crosstool/gcc-4.1.0-glibc-2.3.6/powerpc64-unknown-linux-gnu/bin/powerpc64-unknown-linux-gnu-gcc -v say? Using built-in specs. Target: powerpc64-unknown-linux-gnu Configured with: /home/axboe/crosstool-0.43/build/powerpc64-unknown-linux-gnu/gcc-4.1.0-glibc-2.3.6/gcc-4.1.0/configure --target=powerpc64-unknown-linux-gnu --host=x86_64-host_unknown-linux-gnu --prefix=/opt/crosstool/gcc-4.1.0-glibc-2.3.6/powerpc64-unknown-linux-gnu --disable-multilib --with-sysroot=/opt/crosstool/gcc-4.1.0-glibc-2.3.6/powerpc64-unknown-linux-gnu/powerpc64-unknown-linux-gnu/sys-root --with-local-prefix=/opt/crosstool/gcc-4.1.0-glibc-2.3.6/powerpc64-unknown-linux-gnu/powerpc64-unknown-linux-gnu/sys-root --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c --enable-shared --enable-c99 --enable-long-long Thread model: posix gcc version 4.1.0 I suspect you have a 64 bit only compiler and allnoconfig produces a 32 bit kernel. Is this a new error? 2.6.28 does the same thing. I don't recall having tested allnoconfig for ages if at all, so I don't know if it's a regression. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc allnoconfig
Hi Andrew, On Mon, 2 Mar 2009 18:55:14 -0800 Andrew Morton a...@linux-foundation.org wrote: Using built-in specs. Target: powerpc64-unknown-linux-gnu Configured with: /home/axboe/crosstool-0.43/build/powerpc64-unknown-linux-gnu/gcc-4.1.0-glibc-2.3.6/gcc-4.1.0/configure --target=powerpc64-unknown-linux-gnu --host=x86_64-host_unknown-linux-gnu --prefix=/opt/crosstool/gcc-4.1.0-glibc-2.3.6/powerpc64-unknown-linux-gnu --disable-multilib --with-sysroot=/opt/crosstool/gcc-4.1.0-glibc-2.3.6/powerpc64-unknown-linux-gnu/powerpc64-unknown-linux-gnu/sys-root --with-local-prefix=/opt/crosstool/gcc-4.1.0-glibc-2.3.6/powerpc64-unknown-linux-gnu/powerpc64-unknown-linux-gnu/sys-root --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c --enable-shared --enable-c99 --enable-long-long Thread model: posix gcc version 4.1.0 I suspect you have a 64 bit only compiler and allnoconfig produces a 32 bit kernel. Is this a new error? 2.6.28 does the same thing. I don't recall having tested allnoconfig for ages if at all, so I don't know if it's a regression. Right, you have a 64 bit only compiler. Also it is version 4.1.0 which we now black ban (I think). You need to either build a biarch cross compiler (--enable-targets=all) or try: $ cat xxx EOF CONFIG_PPC64=y EOF $ KCONFIG_ALLCONFIG=xxx make allnoconfig $ make vmlinux let us know if that works :-) -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpCkBjJL9pA8.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc allnoconfig
On Tue, 3 Mar 2009 14:19:05 +1100 Stephen Rothwell s...@canb.auug.org.au wrote: Hi Andrew, On Mon, 2 Mar 2009 18:55:14 -0800 Andrew Morton a...@linux-foundation.org wrote: Using built-in specs. Target: powerpc64-unknown-linux-gnu Configured with: /home/axboe/crosstool-0.43/build/powerpc64-unknown-linux-gnu/gcc-4.1.0-glibc-2.3.6/gcc-4.1.0/configure --target=powerpc64-unknown-linux-gnu --host=x86_64-host_unknown-linux-gnu --prefix=/opt/crosstool/gcc-4.1.0-glibc-2.3.6/powerpc64-unknown-linux-gnu --disable-multilib --with-sysroot=/opt/crosstool/gcc-4.1.0-glibc-2.3.6/powerpc64-unknown-linux-gnu/powerpc64-unknown-linux-gnu/sys-root --with-local-prefix=/opt/crosstool/gcc-4.1.0-glibc-2.3.6/powerpc64-unknown-linux-gnu/powerpc64-unknown-linux-gnu/sys-root --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c --enable-shared --enable-c99 --enable-long-long Thread model: posix gcc version 4.1.0 I suspect you have a 64 bit only compiler and allnoconfig produces a 32 bit kernel. Is this a new error? 2.6.28 does the same thing. I don't recall having tested allnoconfig for ages if at all, so I don't know if it's a regression. Right, you have a 64 bit only compiler. Also it is version 4.1.0 which we now black ban (I think). Probably. But I only use it for compilation testing, so the `Your version of gcc miscompiles the __weak directive' thing is a pointless PITA, so I patch it out. You need to either build a biarch cross compiler (--enable-targets=all) or try: $ cat xxx EOF CONFIG_PPC64=y EOF $ KCONFIG_ALLCONFIG=xxx make allnoconfig $ make vmlinux let us know if that works :-) didn't. Oh well. It seems odd that it breaks an allnoconfig build, whereas defconfig and allmodconfig are OK. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Can't load module spi_mpc83xx : No such device
Hi All,
Linus' tree is still lacking few patches for spi_mpc83xx driver, the
patches makes spi_mpc83xx work with the device tree directly.
I modified the spi_mpc83xx to work with the device tree using mpc52xx_psc_spi.c
as a guide.
However, the device-dev-platform_data member is NULL (I thought the child
node would provide that).
What am I missing?
I'm trying to create the SPI driver as a loadable module which will be used by
the m25p80 chip driver (drivers/mtd/devices) which also will be a loadable
module. Am I on the right track?
[...]
Part of my device tree is as follows:
soc8...@e000 {
...
s...@7000 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,spi;
reg = 0x7000 0x1000;
interrupts = 0x10 0x8;
interrupt-parent = ipic ;
You don't seem to have any chip-selects (i.e. gpios = ) specified.
Could you elaborate on this point please? I couldn't find any examples of gpios
defined within SPI nodes.
[...]
m25...@2 {
compatible = m25p80;
spi-max-frequency = 2500;
reg = 2;
Thanks again.
D
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull 'next' branch
On Mon, 2009-03-02 at 08:25 -0500, Josh Boyer wrote: On Tue, Feb 24, 2009 at 09:08:00AM -0500, Josh Boyer wrote: Hi Ben, Please pull the next branch of the 4xx tree. It has a few small commits for 2.6.30, as well as the 256K page size patch for 44x. Ben, ping? It's up now. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc allnoconfig
Hi Andrew, On Mon, 2 Mar 2009 20:08:09 -0800 Andrew Morton a...@linux-foundation.org wrote: Right, you have a 64 bit only compiler. Also it is version 4.1.0 which we now black ban (I think). Probably. But I only use it for compilation testing, so the `Your version of gcc miscompiles the __weak directive' thing is a pointless PITA, so I patch it out. Ah, ok. let us know if that works :-) didn't. Oh well. Rats! I think we need a better bug report :-) Kernel version? What error do you get now? It works for me: $ /home/sfr/kernels/cross/bin/powerpc64-linux-gcc -v Using built-in specs. Target: powerpc64-linux Configured with: /home/sfr/kernels/tools/gcc-4.3.2/configure --target=powerpc64-linux --enable-targets=all --prefix=/home/sfr/kernels/cross --with-mpfr=/usr --enable-languages=c --without-headers --enable-sjlj-exceptions --with-system-libunwind --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --enable-checking=release Thread model: single gcc version 4.3.2 (GCC) $ git describe --all tags/next-20090302 also Linus' recent tree works: $ git describe v2.6.29-rc6-216-g778ef1e It seems odd that it breaks an allnoconfig build, whereas defconfig and allmodconfig are OK. allmodconfig and defconfig turn CONFIG_PPC64 on. allnoconfig turns it off so you are trying to build a 32 bit kernel with a 64 bit compiler. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpoC4ewcSeoS.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
next branch status
Hoy hoy ! So I somewhat lost track of what I announced and what not already so here's a full shortlog of what's in today vs. Linus, followed by a diffstat. Heads up as the merge window is opening soon. I still have to scrub patchwork for new stuff that got posted since the last test update last week, don't go bonkers if you don't see your patch in if you posted it last week, only if it's older than that. Note: Test is empty right now (ie. == next) Note: Kumar and Grant, pls be a bit more careful with files outside of arch/powerpc ... like the 5200 fec driver change, even if it's really powerpc only stuff and quite clearly so, it's in drivers/net, it wouldn't have hurt to seek davem ack for it... No big deal, it's only 2 or 3 files that I might need to give Linus an explanation about tho :-) Cheers, Ben. Anton Blanchard (11): powerpc/mm: Move 64-bit unmapped_area to top of address space powerpc/mm: Reduce hashtable size when using 64kB pages powerpc: Move is_32bit_task powerpc: Rearrange mmap.c powerpc: Randomise mmap start address powerpc: More stack randomisation for 64bit binaries powerpc: Randomise lower bits of stack address powerpc: Randomise the brk region powerpc: Ensure random space between stack and mmaps powerpc: Increase stack gap on 64bit binaries powerpc: Randomise PIEs Anton Vorontsov (5): powerpc/fsl_pci: Add MPC83xx PCI-E controller RC mode support powerpc/83xx: Add PCI-E support for all MPC83xx boards with PCI-E powerpc: Document FSL eSDHC bindings powerpc/83xx: Convert existing sdhc nodes to new bindings powerpc/83xx: Add FSL eSDHC support for MPC837x-RDB boards Arnd Bergmann (1): powerpc/cell: Fix dependency in cpufreq Benjamin Herrenschmidt (3): powerpc/mm: Rework I$/D$ coherency (v3) powerpc/4xx: Add missing USB and i2c devices to Canyonlands powerpc/4xx: Enable PCI domains on 4xx Benjamin Krill (1): powerpc/cell: Add rtas rtc calls for the QPACE platform Brian King (1): powerpc/pseries: Fix partition migration hang under load Gabriel Paubert (1): powerpc: Disable mv643xx Ethernet port 0 on Pegasos Gerhard Pircher (4): powerpc/amigaone: Add platform support for AmigaOne powerpc/amigaone: Generic device tree for all AmigaOne boards powerpc/amigaone: Bootwrapper and serial console support for AmigaOne powerpc/amigaone: Default config for AmigaOne boards Giuliano Pochini (1): powerpc/powermac: Hotplug /sys entries are missing Grant Likely (7): powerpc/5200: Stop using device_type and port-number properties powerpc/5200: Trim cruft from device trees powerpc/5200: Don't specify IRQF_SHARED in PSC UART driver powerpc/5200: Remove pr_debug() from hot paths in irq driver powerpc/5200: Refactor mpc5200 interrupt controller driver powerpc/5200: Rework GPT driver to also be an IRQ controller powerpc/5200: Add support for the Media5200 board from Freescale Grzegorz Bernacki (1): powerpc/5200: Add support for the digsy MTC board. Ilya Yanok (1): powerpc: Rework dma-noncoherent to use generic vmalloc layer Jeremy Kerr (3): powerpc/spufs: Use correct return value for spu_handle_mm_fault powerpc/spufs: Clear purge status before setting up isolated mode powerpc/spufs: Constify context contents and coredump callback constants Kumar Gala (10): powerpc/fsl-booke: Cleanup init/exception setup to be runtime powerpc/fsl: Ensure PCI_QUIRKS are enabled for FSL_PCI powerpc/85xx: Fixed PCI IO region sizes in mpc8572ds*.dts powerpc/85xx: Added 36-bit physical device tree for mpc8572ds board powerpc/fsl-booke: Add new ISA 2.06 page sizes and MAS defines powerpc/book-3e: Introduce concept of Book-3e MMU powerpc/fsl-booke: Fix compile warning powerpc: Unify opcode definitions and support powerpc: Fix warnings from make headers_check powerpc: Add support for using doorbells for SMP IPI Laurent Pinchart (1): cpm2: Round the baud-rate clock divider to the nearest integer. Madhulika Madishetty (1): AMCC PPC 460SX redwood SoC platform initial framework Martyn Welch (3): powerpc/86xx: Board support for GE Fanuc SBC310 powerpc/86xx: Default configutation for GE Fanuc's SBC310 powerpc/86xx: Extend GE Fanuc GPIO driver for the SBC310 Michael Ellerman (9): powerpc: Remove unused ppc64_terminate_msg() powerpc: Allow debugging of LMBs with lmb=debug lmb: Rework lmb_dump_all() output powerpc/pseries: Fix MSI-X interrupt querying powerpc/pseries: Add support for ibm,req#msi-x powerpc/pseries: Check for MSI-X also in rtas_msi_pci_irq_fixup() powerpc/pseries: Return the number of MSIs we could allocate powerpc/pseries: Return req#msi(-x) if request is larger powerpc/pseries: Implement a quota system for MSIs Michael Neuling (2):
[PATCH 1/2] powerpc/mm: Tweak PTE bit combination definitions (v2)
This patch tweaks the way some PTE bit combinations are defined, in such a
way that the 32 and 64-bit variant become almost identical and that will
make it easier to bring in a new common pte-* file for the new variant
of the Book3-E support.
The combination of bits defining access to kernel pages are now clearly
separated from the combination used by userspace and the core VM. The
resulting generated code should remain identical unless I made a mistake.
Note: While at it, I removed a non-sensical statement related to CONFIG_KGDB
in ppc_mmu_32.c which could cause kernel mappings to be user accessible when
that option is enabled. Probably something that bitrot.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
v2: Fix mixup with next patch
arch/powerpc/include/asm/fixmap.h|2 -
arch/powerpc/include/asm/pgtable-ppc32.h | 39 -
arch/powerpc/include/asm/pgtable-ppc64.h | 44 +
arch/powerpc/include/asm/pgtable.h |4 ++
arch/powerpc/include/asm/pte-8xx.h |3 +
arch/powerpc/include/asm/pte-hash32.h|1
arch/powerpc/include/asm/pte-hash64-4k.h |3 -
arch/powerpc/include/asm/pte-hash64.h| 47 +--
arch/powerpc/mm/fsl_booke_mmu.c |2 -
arch/powerpc/mm/pgtable_32.c |4 +-
arch/powerpc/mm/ppc_mmu_32.c | 10 +-
arch/powerpc/sysdev/cpm_common.c |2 -
12 files changed, 86 insertions(+), 75 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/pgtable-ppc64.h2009-03-03
16:09:33.0 +1100
+++ linux-work/arch/powerpc/include/asm/pgtable-ppc64.h 2009-03-03
16:17:29.0 +1100
@@ -81,11 +81,6 @@
*/
#include asm/pte-hash64.h
-/* To make some generic powerpc code happy */
-#ifndef _PAGE_HWEXEC
-#define _PAGE_HWEXEC 0
-#endif
-
/* Some other useful definitions */
#define PTE_RPN_MAX(1UL (64 - PTE_RPN_SHIFT))
#define PTE_RPN_MASK (~((1ULPTE_RPN_SHIFT)-1))
@@ -96,24 +91,38 @@
#define _PAGE_CHG_MASK (PTE_RPN_MASK | _PAGE_HPTEFLAGS | _PAGE_DIRTY | \
_PAGE_ACCESSED | _PAGE_SPECIAL)
+#define _PAGE_BASE_NC (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_PSIZE)
+#define _PAGE_BASE (_PAGE_BASE_NC | _PAGE_COHERENT)
-/* __pgprot defined in arch/powerpc/include/asm/page.h */
-#define PAGE_NONE __pgprot(_PAGE_PRESENT | _PAGE_ACCESSED)
-
-#define PAGE_SHARED__pgprot(_PAGE_BASE | _PAGE_RW | _PAGE_USER)
-#define PAGE_SHARED_X __pgprot(_PAGE_BASE | _PAGE_RW | _PAGE_USER |
_PAGE_EXEC)
+/* Permission masks used to generate the __P and __S table,
+ *
+ * Note:__pgprot is defined in arch/powerpc/include/asm/page.h
+ */
+#define PAGE_NONE __pgprot(_PAGE_BASE)
+#define PAGE_SHARED__pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_RW)
+#define PAGE_SHARED_X __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_RW |
_PAGE_EXEC)
#define PAGE_COPY __pgprot(_PAGE_BASE | _PAGE_USER)
#define PAGE_COPY_X__pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_EXEC)
#define PAGE_READONLY __pgprot(_PAGE_BASE | _PAGE_USER)
#define PAGE_READONLY_X__pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_EXEC)
-#define PAGE_KERNEL__pgprot(_PAGE_BASE | _PAGE_WRENABLE)
-#define PAGE_KERNEL_CI __pgprot(_PAGE_PRESENT | _PAGE_ACCESSED | \
- _PAGE_WRENABLE | _PAGE_NO_CACHE | _PAGE_GUARDED)
-#define PAGE_KERNEL_EXEC __pgprot(_PAGE_BASE | _PAGE_WRENABLE | _PAGE_EXEC)
-#define PAGE_AGP __pgprot(_PAGE_BASE | _PAGE_WRENABLE | _PAGE_NO_CACHE)
-#define HAVE_PAGE_AGP
+/* Permission masks used for kernel mappings */
+#define PAGE_KERNEL__pgprot(_PAGE_BASE | _PAGE_KERNEL_RW)
+#define PAGE_KERNEL_NC __pgprot(_PAGE_BASE_NC | _PAGE_KERNEL_RW | \
+_PAGE_NO_CACHE)
+#define PAGE_KERNEL_NCG__pgprot(_PAGE_BASE_NC | _PAGE_KERNEL_RW | \
+_PAGE_NO_CACHE | _PAGE_GUARDED)
+#define PAGE_KERNEL_X __pgprot(_PAGE_BASE | _PAGE_KERNEL_RW | _PAGE_EXEC)
+#define PAGE_KERNEL_RO __pgprot(_PAGE_BASE | _PAGE_KERNEL_RO)
+#define PAGE_KERNEL_ROX __pgprot(_PAGE_BASE | _PAGE_KERNEL_RO | _PAGE_EXEC)
+
+/* Protection bits for use by pte_pgprot() */
+#define PAGE_PROT_BITS (_PAGE_GUARDED | _PAGE_COHERENT | \
+_PAGE_NO_CACHE | _PAGE_WRITETHRU | \
+_PAGE_4K_PFN | _PAGE_USER | _PAGE_RW | \
+_PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_EXEC)
+
/* We always have _PAGE_SPECIAL on 64 bit */
#define __HAVE_ARCH_PTE_SPECIAL
@@ -395,7 +404,8 @@ static inline void pte_clear(struct mm_s
static inline void __ptep_set_access_flags(pte_t *ptep, pte_t entry)
{
unsigned long bits = pte_val(entry)
- (_PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_RW | _PAGE_EXEC);
+ (_PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_RW |
+_PAGE_EXEC | _PAGE_HWEXEC);
unsigned long old, tmp;
__asm__ __volatile__(
Index:
[PATCH 2/2] powerpc/mm: Merge various PTE bits and accessors definitions (v2)
Now that they are almost identical, we can merge some of the definitions related to the PTE format into common files. This creates a new pte-common.h which is included by both 32 and 64-bit right after the CPU specific pte-*.h file, and which defines some bits to default values if they haven't been defined already, and then provides a generic definition of most of the bit combinations based on these and exposed to the rest of the kernel. I also moved to the common pgtable.h most of the small accessors to the PTE bits and modification helpers (pte_mk*). The actual accessors remain in their separate files. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- v2: Fix mixup with previous patch arch/powerpc/include/asm/pgtable-ppc32.h | 204 --- arch/powerpc/include/asm/pgtable-ppc64.h | 130 --- arch/powerpc/include/asm/pgtable.h | 53 +++- arch/powerpc/include/asm/pte-common.h| 177 ++ 4 files changed, 229 insertions(+), 335 deletions(-) --- linux-work.orig/arch/powerpc/include/asm/pgtable-ppc32.h2009-03-03 16:18:34.0 +1100 +++ linux-work/arch/powerpc/include/asm/pgtable-ppc32.h 2009-03-03 16:19:23.0 +1100 @@ -97,174 +97,11 @@ extern int icache_44x_need_flush; #include asm/pte-hash32.h #endif -/* If _PAGE_SPECIAL is defined, then we advertise our support for it */ -#ifdef _PAGE_SPECIAL -#define __HAVE_ARCH_PTE_SPECIAL -#endif - -/* - * Some bits are only used on some cpu families... Make sure that all - * the undefined gets defined as 0 - */ -#ifndef _PAGE_HASHPTE -#define _PAGE_HASHPTE 0 -#endif -#ifndef _PTE_NONE_MASK -#define _PTE_NONE_MASK 0 -#endif -#ifndef _PAGE_SHARED -#define _PAGE_SHARED 0 -#endif -#ifndef _PAGE_HWWRITE -#define _PAGE_HWWRITE 0 -#endif -#ifndef _PAGE_HWEXEC -#define _PAGE_HWEXEC 0 -#endif -#ifndef _PAGE_EXEC -#define _PAGE_EXEC 0 -#endif -#ifndef _PAGE_ENDIAN -#define _PAGE_ENDIAN 0 -#endif -#ifndef _PAGE_COHERENT -#define _PAGE_COHERENT 0 -#endif -#ifndef _PAGE_WRITETHRU -#define _PAGE_WRITETHRU0 -#endif -#ifndef _PAGE_SPECIAL -#define _PAGE_SPECIAL 0 -#endif -#ifndef _PMD_PRESENT_MASK -#define _PMD_PRESENT_MASK _PMD_PRESENT -#endif -#ifndef _PMD_SIZE -#define _PMD_SIZE 0 -#define PMD_PAGE_SIZE(pmd) bad_call_to_PMD_PAGE_SIZE() -#endif - -#ifndef _PAGE_KERNEL_RO -#define _PAGE_KERNEL_RO0 -#endif -#ifndef _PAGE_KERNEL_RW -#define _PAGE_KERNEL_RW(_PAGE_DIRTY | _PAGE_RW | _PAGE_HWWRITE) -#endif - -#define _PAGE_HPTEFLAGS _PAGE_HASHPTE - -/* Location of the PFN in the PTE. Most platforms use the same as _PAGE_SHIFT - * here (ie, naturally aligned). Platform who don't just pre-define the - * value so we don't override it here - */ -#ifndef PTE_RPN_SHIFT -#define PTE_RPN_SHIFT (PAGE_SHIFT) -#endif - -#ifdef CONFIG_PTE_64BIT -#define PTE_RPN_MAX(1ULL (64 - PTE_RPN_SHIFT)) -#define PTE_RPN_MASK (~((1ULLPTE_RPN_SHIFT)-1)) -#else -#define PTE_RPN_MAX(1UL (32 - PTE_RPN_SHIFT)) -#define PTE_RPN_MASK (~((1ULPTE_RPN_SHIFT)-1)) -#endif - -/* _PAGE_CHG_MASK masks of bits that are to be preserved accross - * pgprot changes - */ -#define _PAGE_CHG_MASK (PTE_RPN_MASK | _PAGE_HPTEFLAGS | _PAGE_DIRTY | \ - _PAGE_ACCESSED | _PAGE_SPECIAL) - -/* Mask of bits returned by pte_pgprot() */ -#define PAGE_PROT_BITS (_PAGE_GUARDED | _PAGE_COHERENT | _PAGE_NO_CACHE | \ -_PAGE_WRITETHRU | _PAGE_ENDIAN | \ -_PAGE_USER | _PAGE_ACCESSED | \ -_PAGE_RW | _PAGE_HWWRITE | _PAGE_DIRTY | \ -_PAGE_EXEC | _PAGE_HWEXEC) - -/* - * We define 2 sets of base prot bits, one for basic pages (ie, - * cacheable kernel and user pages) and one for non cacheable - * pages. We always set _PAGE_COHERENT when SMP is enabled or - * the processor might need it for DMA coherency. - */ -#if defined(CONFIG_SMP) || defined(CONFIG_PPC_STD_MMU) -#define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_COHERENT) -#else -#define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED) -#endif -#define _PAGE_BASE_NC (_PAGE_PRESENT | _PAGE_ACCESSED) - -/* Permission masks used for kernel mappings */ -#define PAGE_KERNEL__pgprot(_PAGE_BASE | _PAGE_KERNEL_RW) -#define PAGE_KERNEL_NC __pgprot(_PAGE_BASE_NC | _PAGE_KERNEL_RW | \ -_PAGE_NO_CACHE) -#define PAGE_KERNEL_NCG__pgprot(_PAGE_BASE_NC | _PAGE_KERNEL_RW | \ -_PAGE_NO_CACHE | _PAGE_GUARDED) -#define PAGE_KERNEL_X __pgprot(_PAGE_BASE | _PAGE_KERNEL_RW | _PAGE_EXEC) -#define PAGE_KERNEL_RO __pgprot(_PAGE_BASE | _PAGE_KERNEL_RO) -#define PAGE_KERNEL_ROX __pgprot(_PAGE_BASE | _PAGE_KERNEL_RO | _PAGE_EXEC) - -#if defined(CONFIG_KGDB) || defined(CONFIG_XMON) || defined(CONFIG_BDI_SWITCH) ||\ - defined(CONFIG_KPROBES) -/* We want the debuggers to be able to set breakpoints anywhere, so - * don't write protect the
Re: [PATCH] Enable hashdist by default on 64bit NUMA
On Thu, 2009-02-26 at 22:24 +1100, Anton Blanchard wrote: Hi David, Hmmm... my bad, I think you need to keep the CONFIG_NUMA there too as there is a TLB usage penalty for non-NUMA systems if you only use CONFIG_64BIT there. Sorry that was my screwup, here's a fixed version. Sounds good, how do we proceed for merging that ? Andrew ? Should it hop by linux-mm ? Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- Anton -- On PowerPC we allocate large boot time hashes on node 0. This leads to an imbalance in the free memory, for example on a 64GB box (4 x 16GB nodes): Free memory: Node 0: 97.03% Node 1: 98.54% Node 2: 98.42% Node 3: 98.53% If we switch to using vmalloc (like ia64 and x86-64) things are more balanced: Free memory: Node 0: 97.53% Node 1: 98.35% Node 2: 98.33% Node 3: 98.33% For many HPC applications we are limited by the free available memory on the smallest node, so even though the same amount of memory is used the better balancing helps. Since all 64bit NUMA capable architectures should have sufficient vmalloc space, it makes sense to enable it via CONFIG_64BIT. Signed-off-by: Anton Blanchard an...@samba.org --- diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h index 95837bf..0c4d4b7 100644 --- a/include/linux/bootmem.h +++ b/include/linux/bootmem.h @@ -144,10 +144,10 @@ extern void *alloc_large_system_hash(const char *tablename, #define HASH_EARLY 0x0001 /* Allocating during early boot? */ -/* Only NUMA needs hash distribution. - * IA64 and x86_64 have sufficient vmalloc space. +/* Only NUMA needs hash distribution. 64bit NUMA architectures have + * sufficient vmalloc space. */ -#if defined(CONFIG_NUMA) (defined(CONFIG_IA64) || defined(CONFIG_X86_64)) +#if defined(CONFIG_NUMA) defined(CONFIG_64BIT) #define HASHDIST_DEFAULT 1 #else #define HASHDIST_DEFAULT 0 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/1] Fix 64bit Mapple Host Bridge Address and Size Nodes
Thanks.
Now, is there any reason you can't fold the fix inside the existing
fixup_device_tree_maple() fixup ? IE. Does it apply to any Maple board
or only this ATCA6101 ?
If not (if it does only apply to this specific board), then give the
function a better name, such as fixup_device_tree_atca6101() and make it
check for the /model property of the device-tree to make sure you only
hit that board and nothing else.
Cheers,
Ben.
On Fri, 2009-02-27 at 09:55 +0800, Tiejun Chen wrote:
2009/2/27 Benjamin Herrenschmidt b...@kernel.crashing.org
On Thu, 2009-02-26 at 18:08 +0800, Tiejun Chen wrote:
In the DTB tree created by firmware on Maple 64bit target,
host bridge
parent
node has specified both of these two properties to be 2.
However, the
actual
cell value for host bridge node is 1. we have to provide
one fixup
function.
Hi !
Thanks for the patch. A couple of things tho: Can you make it
a bit
more robust by properly checking the board type first ?
That is ATCA 6101 and the following is from the MOTLoad firmware.
--
Copyright Motorola Inc. 1999-2006, All Rights Reserved
MOTLoad RTOS Version 2.0, PAL Version 1.1 RM01
Built on Tue Jun 13 10:31:56 EDT 2006 by q3316c
bbs 2.0 build 38
Part Number =01-W3930F04A
Serial Number=001
MPU-Type =PPC970FX DD3.1
MPU-Int Clock Speed =1800MHz
Memory Speed =333MHz
PCI bus instance 1 =64 bit, 100 MHz, PCI-X
PCI bus instance 2 =64 bit, 100 MHz, PCI-X
PCI bus instance 3 =64 bit, 100 MHz, PCI-X
PCI bus instance 4 =64 bit, 100 MHz, PCI-X
PCI bus instance 5 =32 bit, 33 MHz, PCI
HT Link instance 1 =16 bit, 400 MHz
HT Link instance 2 = 8 bit, 600 MHz
HT Link instance 3 = 8 bit, 200 MHz
MOTLoad FLASH Image =FLASH Bank A
Local Memory Found =08000 (2147483648)
User Download Buffer =0611A5000:0613A4FFF
--
Here is some board information I can know:
--
Board revision: 01
Boot loader version: 2.0
Silicon revision: 3.1 (pvr 003c 0301)
--
Also, what is this hostbridge node ? ie, what does it
represent ?
That means IBM CPC925 system controller resided on the ATCA 6101.
Can you send me a full dump of /proc/device-tree from the
machine ?
(ie tar it up)
See the attachment.
Finally, it looks like your patch was whitespace damaged by
your mailer.
After you confirm others is ok I will send v2 improved patch.
Thanks Best Regards
Tiejun
Cheers,
Ben.
Signed-off-by: Tiejun Chen tiejun.ch...@gmail.com
---
arch/powerpc/kernel/prom_init.c | 42
+++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c
b/arch/powerpc/kernel/prom_init.c
index 2445945..9cd23b6 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1948,8 +1948,49 @@ static void __init
fixup_device_tree_maple(void)
prom_setprop(isa, name, ranges,
isa_ranges, sizeof(isa_ranges));
}
+
+/* On Maple 64bit target host bridge parent node has
specified
address and
+ * size properties to be 2. But the actual cell value for
host
bridge node
+ * is 1 since early MOTLoad internal bug. */
+static void __init fixup_device_tree_maple_hb(void)
+{
+ phandle hb;
+ u32 hb_ranges[4];
+ u32 size_cell, addr_cell;
+ struct prom_t *_prom = RELOC(prom);
+ char *name;
+
+ name = /hostbri...@f800;
+ hb = call_prom(finddevice, 1, 1, ADDR(name));
+ if (!PHANDLE_VALID(hb))
+ return;
+
+ if (prom_getproplen(hb, reg) != 8)
+ return;
+
+ if (prom_getprop(hb, reg, hb_ranges,
(sizeof(hb_ranges))/2)
+ == PROM_ERROR)
+ return;
+
+ prom_getprop(_prom-root, #address-cells,
addr_cell,
sizeof(addr_cell));
+ prom_getprop(_prom-root, #size-cells, size_cell,
sizeof(size_cell));
+
+ if ((addr_cell != 2) || (size_cell != 2) ||
+ (hb_ranges[0] != 0xf800))
+ return;
+
+ prom_printf(Fixing up bogus HOSTBRIDGE reg on
Re: powerpc allnoconfig
On Tue, 3 Mar 2009 15:40:43 +1100 Stephen Rothwell s...@canb.auug.org.au wrote: Hi Andrew, On Mon, 2 Mar 2009 20:08:09 -0800 Andrew Morton a...@linux-foundation.org wrote: Right, you have a 64 bit only compiler. Also it is version 4.1.0 which we now black ban (I think). Probably. But I only use it for compilation testing, so the `Your version of gcc miscompiles the __weak directive' thing is a pointless PITA, so I patch it out. Ah, ok. let us know if that works :-) didn't. Oh well. Rats! I think we need a better bug report :-) Kernel version? Current mainline. What error do you get now? Same as before. allmodconfig and defconfig turn CONFIG_PPC64 on. allnoconfig turns it off so you are trying to build a 32 bit kernel with a 64 bit compiler. Oh. Well that will tear it. How does one prepare a powerpc64 allnoconfig? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc allnoconfig
Hi Andrew, On Mon, 2 Mar 2009 21:38:01 -0800 Andrew Morton a...@linux-foundation.org wrote: I think we need a better bug report :-) Kernel version? Current mainline. What error do you get now? Same as before. allmodconfig and defconfig turn CONFIG_PPC64 on. allnoconfig turns it off so you are trying to build a 32 bit kernel with a 64 bit compiler. Oh. Well that will tear it. How does one prepare a powerpc64 allnoconfig? Like above. See this is what happens for me: $ git describe v2.6.29-rc6-305-g2450cf5 $ /home/sfr/kernels/cross/bin/powerpc64-linux-gcc -v Using built-in specs. Target: powerpc64-linux Configured with: /home/sfr/kernels/tools/gcc-4.3.2/configure --target=powerpc64-linux --enable-targets=all --prefix=/home/sfr/kernels/cross --with-mpfr=/usr --enable-languages=c --without-headers --enable-sjlj-exceptions --with-system-libunwind --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --enable-checking=release Thread model: single gcc version 4.3.2 (GCC) $ mkdir ../powerpc_allnoconfig $ echo CONFIG_PPC64=y ../powerpc64_allnoconfig $ KCONFIG_ALLCONFIG=../powerpc64_allnoconfig make O=../powerpc_allnoconfig ARCH=powerpc CROSS_COMPILE=/home/sfr/kernels/cross/bin/powerpc64-linux- allnoconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc HOSTCC scripts/basic/hash GEN /home/sfr/kernels/powerpc_allnoconfig/Makefile HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/kxgettext.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf -n arch/powerpc/Kconfig # # configuration written to .config # $ make O=../powerpc_allnoconfig ARCH=powerpc CROSS_COMPILE=/home/sfr/kernels/cross/bin/powerpc64-linux- vmlinux GEN /home/sfr/kernels/powerpc_allnoconfig/Makefile scripts/kconfig/conf -s arch/powerpc/Kconfig Using /home/sfr/kernels/work as source for kernel GEN /home/sfr/kernels/powerpc_allnoconfig/Makefile CHK include/linux/version.h UPD include/linux/version.h CHK include/linux/utsrelease.h UPD include/linux/utsrelease.h SYMLINK include/asm - include/asm-powerpc CC kernel/bounds.s GEN include/linux/bounds.h CC arch/powerpc/kernel/asm-offsets.s GEN include/asm/asm-offsets.h CALL/home/sfr/kernels/work/scripts/checksyscalls.sh CC scripts/mod/empty.o HOSTCC scripts/mod/mk_elfconfig MKELF scripts/mod/elfconfig.h HOSTCC scripts/mod/file2alias.o . . . CC kernel/sysctl.o /home/sfr/kernels/work/kernel/sysctl.c:103: warning: 'one' defined but not used . . . LD vmlinux.o MODPOST vmlinux.o WARNING: modpost: Found 2 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 KSYM.tmp_kallsyms1.S AS .tmp_kallsyms1.o LD .tmp_vmlinux2 KSYM.tmp_kallsyms2.S AS .tmp_kallsyms2.o LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map $ grep CONFIG_PPC64 ../powerpc_allnoconfig/.config CONFIG_PPC64=y $ file ../powerpc_allnoconfig/vmlinux ../powerpc_allnoconfig/vmlinux: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), statically linked, not stripped So, I can only imagine it is your toolchain that is letting you down. What is your host machine? Can I send you a new toolchain? (Mine are only good for building kernels - they have no libraries - they are build by a script I got from Segher Boessenkool.) -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgprpLsa1VX5G.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc allnoconfig
On Tue, 3 Mar 2009 17:22:32 +1100 Stephen Rothwell s...@canb.auug.org.au wrote: So, I can only imagine it is your toolchain that is letting you down. hrm. I blame Rusty. What is your host machine? x86_64/FCx Can I send you a new toolchain? (Mine are only good for building kernels - they have no libraries - they are build by a script I got from Segher Boessenkool.) It's OK - I don't really care and as long as it's OK on a realistic build setup, I guess we're good. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PHY not found after migration of gianfar driver to an of_platform_driver
On Mon, 2 Mar 2009 08:08:02 -0700, Grant Likely grant.lik...@secretlab.ca wrote: On Mon, Mar 2, 2009 at 4:58 AM, Michael Guntsche m...@it-loops.com wrote: You mean like loading it of the CF or something? Yeah, I suppose so if you wrote a minimal CF driver, but that seems the hard way around also. You're far better off to statically link in a .dtb image and modify it. If the bootloader doesn't provide you with any useful information, you can read the SoC registers to detect memory size and clock rate. If you're lucky, the bootloader will have already assigned the correct MAC addresses for you and you can read those out also. You can also try inspecting the memory pointed to by r3-r7 and seeing if any of them point to something interesting. Regarding the registers I did a printf(Reg: %lu\n, r3); after the init of the serial console. While r4 to r7 where empty, I got back a number 8756... from R3. I do not know what's in there though. Is there another better way to get to the data? Oh. So routerboot does understand dtb blobs? Okay, I didn't understand that. Yes, you can call the libfdt functions in your platform_init() to add the missing nodes. I don't know if routerboot understands dtb blobs. If I boot with a standard vmlinux image the board boots as well so I think that the firmware provides a tree the prom code can read. As for adding additional information to the tree, can I also use libfdt functions in platform/83xx/rbppc.c or is it better to do this via a dedicated platform_init that simpleboot then uses? Once again thank you very much for helping me with this, Michael ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
