On Mon, 2 Mar 2009 08:08:02 -0700, Grant Likely
wrote:
> On Mon, Mar 2, 2009 at 4:58 AM, Michael Guntsche
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 statical
On Tue, 3 Mar 2009 17:22:32 +1100 Stephen Rothwell
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 librarie
Hi Andrew,
On Mon, 2 Mar 2009 21:38:01 -0800 Andrew Morton
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
On Tue, 3 Mar 2009 15:40:43 +1100 Stephen Rothwell
wrote:
> Hi Andrew,
>
> On Mon, 2 Mar 2009 20:08:09 -0800 Andrew Morton
> 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 com
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_atca61
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.
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 b
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
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 las
--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
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.
Ch
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 th
On Tue, 3 Mar 2009 14:19:05 +1100 Stephen Rothwell
wrote:
> Hi Andrew,
>
> On Mon, 2 Mar 2009 18:55:14 -0800 Andrew Morton
> wrote:
> >
> > Using built-in specs.
> > Target: powerpc64-unknown-linux-gnu
> > Configured with:
> > /home/axboe/crosstool-0.43/build/powerpc64-unknown-linux-gnu/gcc-
Hi Andrew,
On Mon, 2 Mar 2009 18:55:14 -0800 Andrew Morton
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 -
On Tue, 3 Mar 2009 13:52:03 +1100 Stephen Rothwell
wrote:
> Hi Andrew,
>
> On Mon, 2 Mar 2009 18:40:49 -0800 Andrew Morton
> 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-gn
Hi Andrew,
On Mon, 2 Mar 2009 18:40:49 -0800 Andrew Morton
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 on
On Tue, 03 Mar 2009 13:31:10 +1100 Michael Neuling 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/utsreleas
> 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/as
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@oz
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 scr
> 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 specificat
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 t
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
On Mon, Mar 2, 2009 at 10:16 AM, Anton Vorontsov
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,
>>
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
> wrote:
> > Hello,
> >
> > I've got a target derived from the Lite5200 that needs to use simple
> > interrupt GPIO pins. I creat
On Mon, Mar 2, 2009 at 4:58 AM, Michael Guntsche wrote:
> On Sun, 1 Mar 2009 18:15:32 -0700, Grant Likely
> 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 simpleImag
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
Linu
On Sun, 1 Mar 2009 18:15:32 -0700, Grant Likely
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
On Mon, 2 Mar 2009 11:28:01 +0100 (CET)
Geert Uytterhoeven 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
On Mon, 2 Mar 2009, Alessandro Zummo wrote:
> On Mon, 2 Mar 2009 10:54:14 +0100 (CET)
> Geert Uytterhoeven 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
On Mon, 2 Mar 2009 10:54:14 +0100 (CET)
Geert Uytterhoeven 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 hav
On Fri, 27 Feb 2009, Richard Zidlicky wrote:
> On Wed, Feb 25, 2009 at 11:18:36AM +0100, Alessandro Zummo wrote:
> > On Wed, 25 Feb 2009 11:00:13 +0100 (CET)
> > Geert Uytterhoeven wrote:
> >
> > > I didn't know NTP was broken with RTC class drivers?
> > >
> > > So we should actually keep on usi
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
33 matches
Mail list logo
