* Re: [PATCH 3/9] cpm2: Add SCCs to cpm2_clk_setup(), and cpm2_smc_clk_setup().
From: Vitaly Bordug @ 2007-09-04 20:43 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070830201500.GB5144@ld0162-tx32.am.freescale.net>
On Thu, 30 Aug 2007 15:15:00 -0500
Scott Wood wrote:
> On Thu, Aug 30, 2007 at 02:25:48AM +0400, Vitaly Bordug wrote:
> > I would have it in the same patch, that adds clocking stuff to 8xx.
>
> I was trying to keep the 8xx and 82xx patchsets reasonably separate.
>
> > And maybe in the same, segregate source rather then having it in the
> > foo_common.c, to ease fix/update/rework.
>
> I'm not sure I understand what you mean -- where do you want the code
> to go?
>
Thinking once again about this, It looks good the way it is, another way is prolly overkill so nm.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: Vitaly Bordug @ 2007-09-04 20:15 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20070904182028.GC18280@ld0162-tx32.am.freescale.net>
On Tue, 4 Sep 2007 13:20:28 -0500
Scott Wood wrote:
> > > _and system GPIOs_ :-)
> >
> > Yup, firmware should set up gpios, to make initial kernel boot.
>
> No, it should set all pins and similar setup-once type initialization
> that is board-specific rather than device-specific -- there's no
> reason for the kernel to need to care about that sort of thing.
>
> > After that, kernel can and should manage GPIOs. Few examples.
> >
> > Say units (like USB or SPI) can work in very different modes. And
> > it's okay if user want to change device mode in the runtime.
>
> This is a special case that warrants kernel involvement. It should
> not be used as justification for the bootloader leaving pins
> unconfigured in the majority of cases where it does not make sense to
> change them at runtime.
>
This argue is useless: both opinions have same weight. Firmware is able to provide meaningful default gpio setup, and nobody
will object. The point is, that blindly assume all the low-level stuff is fine, you are able only in case you've developed respective bits in the firmware.
More usual case is additional overhead of checking if the firmware not attempting to do something not really wanted, so we'll
always have a tradeoff.
--
Sincerely, Vitaly
^ permalink raw reply
* Problems with MPC8272ADS
From: Manil Gaouar @ 2007-09-04 19:53 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 396 bytes --]
Hi,
I am a bit newbie in this. I tried compiling Linux 2.4 using
ADS8272_deconfig from the kernel 2.6 and I have many compilation errors.
Are the deconfig files from 2.4 to 2.6 that different, or can I use the
2.6 file with little changes???
I don't understand why there is support for this board in 2.6 and not in
2.4, since Denx recommend 2.4.
Thx for your help!
[-- Attachment #2: Type: text/html, Size: 2241 bytes --]
^ permalink raw reply
* Re: "atomic" 64-bit math on 32-bit ppc's?
From: Scott Wood @ 2007-09-04 18:48 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: ppc-dev
In-Reply-To: <20070904113937.GA3994@iram.es>
On Tue, Sep 04, 2007 at 01:39:37PM +0200, Gabriel Paubert wrote:
> That's wrong if lock is assigned to r0, you should use
> a "b" constraint to avoid this. Same for atomic_dec below.
GCC should really have removed r0 from the "r" class (it isn't truly a
general-purpose register), and had a different class meaning "r"-plus-r0.
-Scott
^ permalink raw reply
* Re: disable interrput under ppc?
From: Josh Boyer @ 2007-09-04 18:37 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <20070904182433.GD18280@ld0162-tx32.am.freescale.net>
On Tue, 4 Sep 2007 13:24:33 -0500
Scott Wood <scottwood@freescale.com> wrote:
> On Tue, Sep 04, 2007 at 10:44:14AM +0800, Wang, Baojun wrote:
> > hi, list
> >
> > How can I disable interrput like `cli' in x86?
>
> local_irq_disable().
>
> > I want the following code freeze the box but it doesn't, $MSR is
> > altered however the box is still alive, how can I freeze the box like
> > `cli' in x86? Thanks very much!
>
> Disabling interrupts doesn't freeze the machine by itself -- it depends
> on what you do afterwards, which you didn't show.
If you're using a BOOKE variant, there is a way to use the DBCR0
register to set debug wait enable or something to basically hang the
CPU until something external clears that bit. But why you would want
to do that, I have no idea.
josh
^ permalink raw reply
* Re: disable interrput under ppc?
From: Scott Wood @ 2007-09-04 18:24 UTC (permalink / raw)
To: Wang, Baojun; +Cc: linuxppc-embedded
In-Reply-To: <200709041044.16525.wangbj@lzu.edu.cn>
On Tue, Sep 04, 2007 at 10:44:14AM +0800, Wang, Baojun wrote:
> hi, list
>
> How can I disable interrput like `cli' in x86?
local_irq_disable().
> I want the following code freeze the box but it doesn't, $MSR is
> altered however the box is still alive, how can I freeze the box like
> `cli' in x86? Thanks very much!
Disabling interrupts doesn't freeze the machine by itself -- it depends
on what you do afterwards, which you didn't show.
-Scott
^ permalink raw reply
* Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: Scott Wood @ 2007-09-04 18:20 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20070904104750.GA32451@localhost.localdomain>
On Tue, Sep 04, 2007 at 02:47:50PM +0400, Anton Vorontsov wrote:
> > _and system GPIOs_ :-)
>
> Yup, firmware should set up gpios, to make initial kernel boot.
No, it should set all pins and similar setup-once type initialization
that is board-specific rather than device-specific -- there's no reason
for the kernel to need to care about that sort of thing.
> After that, kernel can and should manage GPIOs. Few examples.
>
> Say units (like USB or SPI) can work in very different modes. And
> it's okay if user want to change device mode in the runtime.
This is a special case that warrants kernel involvement. It should not
be used as justification for the bootloader leaving pins unconfigured in
the majority of cases where it does not make sense to change them at
runtime.
> Another example, power management - if some unit temporarily unused,
> to save power GPIOs should be set up differently. Say if SPI unit
> turned off (unused just now), it's wise to bring their dedicated
> GPIOs to "power saving" state (be it output0/1 or input, it
> depends).
The kernel is of course welcome to do so -- and this may be a valid
reason to attach pin information to specific device nodes, if it actually
saves a non-negligible amount of power -- but it's not a reason to force
the kernel to have to care by not setting things up in the firmware.
-Scott
^ permalink raw reply
* Flash on ep8248e standard motherboards
From: Alan Bennett @ 2007-09-04 18:08 UTC (permalink / raw)
To: linuxppc-embedded
Please accept my apologies for sending the last email and accept this
email address and question. without the disclaimer.
---------------------------------------------------
Hello;
We have a custom board based on the ep8248e design from Embedded
Planet and I'm trying to use something other than codewarrior to flash
u-boot srec's
I'm not sure where the problem is, but I'm unable to flash the
u-boot.srec onto the Embedded Planet board (using the BDI2000), let
alone our custom board.
1. Embedded Planet ep8248E
64 MB SDRAM
64 MB Flash (x2 Am29LV256M)
2. Custom
128 MB SDRAM
128 MB Flash (X2 Spansion S29GL512N)
NOTE: CW successfully flashes both parts, but then again, it's CW.
BDI 2000 Config File:
; initialize - FLASH BR0 & OR0 (64 Mbyte)
;*******************************************
WM32 0xf0010100 0xfc001801
WM32 0xf0010104 0xfc0008c2
[FLASH]
CHIPTYPE MIRRORX16
CHIPSIZE 0x2000000
BUSWIDTH 16
I then attempt to unlock/erase/program
Check for Sanity (NOTE: using BDI 2000 PROMPT)
md 0xf0010100 2
f0010100 : 0xf8001801 - 134211583 ....
f0010104 : 0xf80008b2 - 134215502 ....
md 0xfff00000 2
fff00000 : 0x10101010 269488144 ....
fff00004 : 0x10101010 269488144 ....
All looks good. (10101010 is the existing planet core header)
TRY TO UNLOCK
unlock 0xfff00000 1000
Unlocking flash at 0xfff00000
# Invalid parameter for flash programming
TRY TO ERASE
erase 0xfff00000 UNLOCK 1000
Erasing flash at 0xfff00000
# Erasing flash memory failed
BUT
erase 0xffff0000 UNLOCK 1000
Erasing flash at 0xffff0000
Erasing flash passed
HOWEVER
mm 0xffff0000 0xdeadbeef
md 0xffff0000 1
ffff0000 : 0xffffffff
SO it doesn't seem to allow write access afterall...
Is there anyone that has a BDI 2000 config file for flashing the
ep8248e motherboard the 8MB Flash Version (64 MB flash version)
Thanks
-Alan
^ permalink raw reply
* Re: "atomic" 64-bit math on 32-bit ppc's?
From: Matt Sealey @ 2007-09-04 17:40 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: ppc-dev
In-Reply-To: <20070904160206.GA12698@iram.es>
Gabriel Paubert wrote:
> I don't know at all the ZFS code, not any filesystem code for the
> matter. But how many spinlocks would you have to take and release
> per actual disk operation?
I have no idea, but considering the space supported by the filesystem
it's probably a hell of a lot.
It seems like we've solved it; the Solaris ppc-dev repository has an
updated atomic.c which implements a kernel mutex for 64-bit ops. I've
forwarded this on, hopefully it ISN'T a hell of a lot or this is going
to knock filesystem performance on the head for 32-bit ppc :D
Thanks for your help.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Flash on ep8248e standard motherboards
From: Bennett, Alan @ 2007-09-04 17:09 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46DD65BF.5090304@kip.uni-heidelberg.de>
Hello;
We have a custom board based on the ep8248e design from Embedded Planet
and I'm trying to use something other than codewarrior to flash u-boot
srec's=20
I'm not sure where the problem is, but I'm unable to flash the
u-boot.srec onto the Embedded Planet board (using the BDI2000), let
alone our custom board.
1. Embedded Planet ep8248E
64 MB SDRAM
64 MB Flash (x2 Am29LV256M)
2. Custom
128 MB SDRAM
128 MB Flash (X2 Spansion S29GL512N)
NOTE: CW successfully flashes both parts, but then again, it's CW.
BDI 2000 Config File:
; initialize - FLASH BR0 & OR0 (64 Mbyte)
;*******************************************
WM32 0xf0010100 0xfc001801
WM32 0xf0010104 0xfc0008c2
[FLASH]
CHIPTYPE MIRRORX16
CHIPSIZE 0x2000000
BUSWIDTH 16
I then attempt to unlock/erase/program
Check for Sanity (NOTE: using BDI 2000 PROMPT)
md 0xf0010100 2
f0010100 : 0xf8001801 - 134211583 ....
f0010104 : 0xf80008b2 - 134215502 ....
md 0xfff00000 2
fff00000 : 0x10101010 269488144 ....
fff00004 : 0x10101010 269488144 ....
All looks good. (10101010 is the existing planet core header)
TRY TO UNLOCK
unlock 0xfff00000 1000
Unlocking flash at 0xfff00000
# Invalid parameter for flash programming
TRY TO ERASE
erase 0xfff00000 UNLOCK 1000
Erasing flash at 0xfff00000
# Erasing flash memory failed
BUT
erase 0xffff0000 UNLOCK 1000
Erasing flash at 0xffff0000
Erasing flash passed
HOWEVER
mm 0xffff0000 0xdeadbeef
md 0xffff0000 1
ffff0000 : 0xffffffff
SO it doesn't seem to allow write access afterall...
Is there anyone that has a BDI 2000 config file for flashing the ep8248e
motherboard the 8MB Flash Version (64 MB flash version)=20
Thanks
-Alan
*****************************************************************
*************
CONFIDENTIAL NOTE: This e-mail and any attachments may be
confidential and protected by legal privilege. If you are not
the intended recipient, be aware that you are hereby notified
that any unauthorized review, use, disclosure, dissemination,
distribution, or copying of this communication, or any of its
contents, is strictly prohibited. If you have received this
email in error, please notify us immediately by replying to the
sender and deleting this copy and the reply from your system.
Thank you for your cooperation.
EXPORT CONTROLLED DOCUMENT
This document may contain information whose export is restricted
by the Arms Export Control Act (Title 22, U.S.C., Sec 2751 Et
Seq.) or the Export Administration Act of 1979, as amended,
(Title 50, U.S.C., App. 2401, Et. Seq.) Violations to these
export laws are subject to severe criminal penalties.
All technical data forwarded by VT Miltope to its suppliers is
EXPORT CONTROLLED. Supplier shall not disclose technical data in
any form to a Foreign Person (including foreign person employees
of Supplier), or export the technical data from the United
States without U.S. Government authority and the written
authorization of VT Miltope Contracts Department.
*****************************************************************
*************
^ permalink raw reply
* Re: Regarding immap_86xx.h
From: Timur Tabi @ 2007-09-04 16:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, sivaji
In-Reply-To: <706FA05F-6E3E-4A9C-9DB0-52840E178F06@kernel.crashing.org>
Kumar Gala wrote:
> Its most likely been removed since these structures have been
> distributed to the places they are used.
Not only that, but I submitted a patch to remove the PCI structure, so all
that's left is the GUTS structure.
The GUTS structure is different from other devices since it contains registers
used by a variety of devices. It's a sort of catch-all for miscellaneous
hardware configuration. That's why there's no GUTS device driver, and why I
left the structure in immap_86xx.h.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: "atomic" 64-bit math on 32-bit ppc's?
From: Gabriel Paubert @ 2007-09-04 16:02 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev
In-Reply-To: <46DD500B.4020207@genesi-usa.com>
On Tue, Sep 04, 2007 at 01:31:07PM +0100, Matt Sealey wrote:
>
> Gabriel Paubert wrote:
> >On Tue, Sep 04, 2007 at 12:09:22PM +0100, Matt Sealey wrote:
> >>Hi guys,
> >>
> >>The Solaris PPC code drop included most of these functions for 32-bit ops
> >>on
> >>32-bit PPC architectures but the 64-bit operations are not present. What I
> >>a not clear on is the operation of lwarx and stwcx. and if they will work
> >>if
> >>you are doing operations on two words at a time.
> >
> >No. There is a single reservation for a single word.
>
> This is what I gathered from the programming environments manual at least.
Well, that's because it is fundamentally impossible to
have more than one, what would the hardware do if the second
update fails after the first has succeeded?
>
> >the 64 bit operations inside a spinlock on PPC32, and then select the
> >number /location of spinlock(s) based on your needs, from one global
> >per machine to one per 64 bit variable if you find excessive contention.
>
> Okay that makes sense, but it would have to be a super global big lock,
> I don't think the code is there in ZFS to give every 64-bit variable it's
> own dedicated spinlock (kind of an overhaul) and I'm trying to be fast..
I don't know at all the ZFS code, not any filesystem code for the
matter. But how many spinlocks would you have to take and release
per actual disk operation?
Regards,
Gabriel
^ permalink raw reply
* Newbie on embedded linux on PPC: error: cannot find boot.o
From: Thomas Gerlach @ 2007-09-04 14:03 UTC (permalink / raw)
To: linuxppc-embedded
hi folks,
my name is thomas trying to make embedded linux run on a powerpc, but we've got special boards here, although we use a xilinx virtex4 fpga...
as you said in the nabble-thread (see subject), i set up edk9.1 software platform settings und ran libgen to get the xparameters* files. i copied those bsp files into the kernel tree (i use your kernel linux-2.6-virtex from git.secretlabs.ca/git). after configuring the kernel settigs, i try
$ make ARCH=ppc CROSS_COMPILE=powerpc-eabi-
what i get is the following output:
> CHK include/linux/version.h
> CHK include/linux/utsrelease.h
> CALL scripts/checksyscalls.sh
> CHK include/linux/compile.h
> LD init/mounts.o
> powerpc-eabi-ld: cannot find boot.o
> make[1]: *** [init/mounts.o] Error 1
> make: *** [init] Error 2
so, i searched for boot.o (it exists) and even copied it into several dirs of the linux kernel tree (where i thought i would make sense), but the problem still remains.
googling results in
http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&getPagePath=17462&BV_SessionID=@@@@1197140711.1188909240@@@@&BV_EngineID=cccgaddllgmfkflcefeceihdffhdfkf.0
and this, too, doesn't take me further in solving the problem.
i hope you can help me.
many thanks in advance,
kind regards
thomas gerlach
^ permalink raw reply
* Re: Newbie on embedded linux on PPC: error: cannot find boot.o
From: Grant Likely @ 2007-09-04 14:47 UTC (permalink / raw)
To: Thomas Gerlach; +Cc: linuxppc-dev
In-Reply-To: <46DD6238.6030204@kip.uni-heidelberg.de>
On 9/4/07, Thomas Gerlach <gerlach@kip.uni-heidelberg.de> wrote:
> hi folks,
>
>
> my name is thomas trying to make embedded linux run on a powerpc, but we've got special boards here, although we use a xilinx virtex4 fpga...
>
> as you said in the nabble-thread (see subject), i set up edk9.1 software platform settings und ran libgen to get the xparameters* files. i copied those bsp files into the kernel tree (i use your kernel linux-2.6-virtex from git.secretlabs.ca/git). after configuring the kernel settigs, i try
>
> $ make ARCH=ppc CROSS_COMPILE=powerpc-eabi-
You should be using a Linux cross compiler, not powerpc-eabi-. The
Xilinx cross compiler will not work to compile Linux kernels.
You can build yourself a cross compiler using 'crosstool':
http://www.kegel.org/crosstool.
Alternately, you can download ELDK:
http://www.denx.de/wiki/view/DULG/ELDKAvailability
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: ppc Floating Point support status
From: Ben Buchli @ 2007-09-04 14:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <662F11BD-C521-4914-966C-8FCB84D5F808@kernel.crashing.org>
On Wednesday 22 August 2007 15:52:09 Kumar Gala wrote:
> On Aug 22, 2007, at 1:37 PM, Ben Buchli wrote:
> > Hello everybody,
> > I was wondering what the status was on supporting floating-point
> > instructions
> > for the mpc8548. I found the suggested patch:
> > http://patchwork.ozlabs.org/linuxppc/patch?
> > order=patch&filter=none&id=9455,
> > but I'm not sure for what kernel version this is and when it will be
> > officially supported.
> >
> > Thanks a lot for your help!
> >
> > Please CC to me (bbuchli at xes-inc.com) as I haven't subscribed to
> > this list.
>
> I thing these are still up in the air based on having some sense of
> testing related to them.
>
> - k
Kumar,
thanks for getting back with me.
We're doing some early performance testing on one of our boards with an
mpc8548e. I was wondering if there's a snapshot available that we could use
and maybe do some working/testing on.
Thanks a lot.
Ben
--
--
Ben Buchli
Extreme Engineering Solutions, Inc.
608-833-1155 ext 202
^ permalink raw reply
* Newbie on embedded linux on PPC: error: cannot find boot.o
From: Thomas Gerlach @ 2007-09-04 13:48 UTC (permalink / raw)
To: linuxppc-dev
hi folks,
my name is thomas trying to make embedded linux run on a powerpc, but we've got special boards here, although we use a xilinx virtex4 fpga...
as you said in the nabble-thread (see subject), i set up edk9.1 software platform settings und ran libgen to get the xparameters* files. i copied those bsp files into the kernel tree (i use your kernel linux-2.6-virtex from git.secretlabs.ca/git). after configuring the kernel settigs, i try
$ make ARCH=ppc CROSS_COMPILE=powerpc-eabi-
what i get is the following output:
> CHK include/linux/version.h
> CHK include/linux/utsrelease.h
> CALL scripts/checksyscalls.sh
> CHK include/linux/compile.h
> LD init/mounts.o
> powerpc-eabi-ld: cannot find boot.o
> make[1]: *** [init/mounts.o] Error 1
> make: *** [init] Error 2
so, i searched for boot.o (it exists) and even copied it into several dirs of the linux kernel tree (where i thought i would make sense), but the problem still remains.
googling results in
http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&getPagePath=17462&BV_SessionID=@@@@1197140711.1188909240@@@@&BV_EngineID=cccgaddllgmfkflcefeceihdffhdfkf.0
and this, too, doesn't take me further in solving the problem.
i hope you can help me.
many thanks in advance,
kind regards
thomas gerlach
^ permalink raw reply
* Re: Regarding immap_86xx.h
From: Kumar Gala @ 2007-09-04 14:25 UTC (permalink / raw)
To: sivaji; +Cc: linuxppc-dev
In-Reply-To: <12472670.post@talk.nabble.com>
On Sep 4, 2007, at 1:38 AM, sivaji wrote:
>
> Hi,
> I am using 2.6.23-rc3 kernel. In this kernel immap_86xx.h
> file was
> loacted in the path: include/asm-powerpc/immap_86xx.h.
>
> This file contains only PCI and Global utility Regsiters
> Declarations. LocalBus Controller, Local Access Registers and Rapid IO
> Register Declarations are missing. Where i can find these registers
> declaration and tell the reason why the CCSRBAR Registers are
> missing in the
> file immap_86xx.h
Its most likely been removed since these structures have been
distributed to the places they are used.
- k
^ permalink raw reply
* RE: Ethernet weirdness on 82xx
From: Rune Torgersen @ 2007-09-04 14:06 UTC (permalink / raw)
To: Denys, linuxppc-embedded, netdev
In-Reply-To: <20070902110957.M44221@visp.net.lb>
> -----Original Message-----
> From: Denys [mailto:denys@visp.net.lb]=20
> Sent: Sunday, September 02, 2007 6:12 AM
> To: Rune Torgersen; linuxppc-embedded@ozlabs.org;=20
> netdev@vger.kernel.org
> Subject: Re: Ethernet weirdness on 82xx
>=20
> Thats normal.
> Check arp_filter sysctl :
> arp_filter - BOOLEAN
Thank you, that was it.
Did the following, and now I don't get the double resond anymore
#only respond to arps on the correct port
echo 1 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 2 > /proc/sys/net/ipv4/conf/all/arp_ignore
^ permalink raw reply
* Re: Thanks and new problems
From: schardt @ 2007-09-04 12:48 UTC (permalink / raw)
Cc: Linux PPC Linux PPC
In-Reply-To: <46DD4F69.8060804@anagramm.de>
Ah, just found the problem in old postings
i've to use the 'a' Version of the IP-Core :)
Georg
Clemens Koller wrote:
> schardt schrieb:
>> First, many many thanks to Grant. My VirtexII Demo Board ist running a
>> 2.6. Linux :))
>>
>> But now, i switched to a Virtex4-Board with Ethernet (Mini Module from
>> Avnet)
>> This will i used in my application, if i can handle it. :)
>>
>> Linux is up and running, the ethernet is detected as eth0, link led
>> is on
>> but, and thats the problem, speed negotiating das not work.
>
> Check the PHY configuration (i.e. the bootstrap pins on the PHY).
>
> And - if appropriate - read out the PHY configuration (MDIO) and see
> if it's correct.
>
> Regards,
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.
Vorsitzender)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
^ permalink raw reply
* Re: [patch 3/6] Walnut DTS
From: Josh Boyer @ 2007-09-04 12:42 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <1188741584.3772.7.camel@localhost.localdomain>
On Sun, 02 Sep 2007 08:59:44 -0500
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Mon, 2007-09-03 at 11:08 +1000, David Gibson wrote:
> > On Fri, Aug 31, 2007 at 03:04:52PM -0500, Josh Boyer wrote:
> > > Device tree source file for the PPC405 Walnut evaluation board.
> > >
> > > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> > >
> > > ---
> > > arch/powerpc/boot/dts/walnut.dts | 183 +++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 183 insertions(+)
> > >
> > > --- /dev/null
> > > +++ linux-2.6/arch/powerpc/boot/dts/walnut.dts
> > > @@ -0,0 +1,183 @@
> > > +/*
> > > + * Device Tree Source for IBM Walnut
> > > + *
> > > + * Copyright 2007 IBM Corp.
> > > + * Josh Boyer <jwboyer@linux.vnet.ibm.com>
> > > + *
> > > + * This file is licensed under the terms of the GNU General Public
> > > + * License version 2. This program is licensed "as is" without
> > > + * any warranty of any kind, whether express or implied.
> > > + */
> > > +
> > > +/ {
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + model = "ibm,walnut";
> > > + compatible = "ibm,walnut";
> > > + dcr-parent = <&/cpus/PowerPC,405GP@0>;
> > > +
> > > + cpus {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + PowerPC,405GP@0 {
> > > + device_type = "cpu";
> > > + reg = <0>;
> > > + clock-frequency = <bebc200>; /* Filled in by zImage */
> > > + timebase-frequency = <0>; /* Filled in by zImage */
> > > + i-cache-line-size = <20>;
> > > + d-cache-line-size = <20>;
> > > + i-cache-size = <4000>;
> > > + d-cache-size = <4000>;
> > > + dcr-controller;
> > > + dcr-access-method = "native";
> > > + };
> > > + };
> > > +
> > > + memory {
> > > + device_type = "memory";
> > > + reg = <0 0>; /* Filled in by zImage */
> > > + };
> > > +
> > > + UIC0: interrupt-controller {
> > > + compatible = "ibm,uic";
> > > + interrupt-controller;
> > > + cell-index = <0>;
> > > + dcr-reg = <0c0 9>;
> > > + #address-cells = <0>;
> > > + #size-cells = <0>;
> > > + #interrupt-cells = <2>;
> > > + };
> > > +
> > > + plb {
> > > + compatible = "ibm,plb3";
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + ranges;
> > > + clock-frequency = <0>; /* Filled in by zImage */
> > > +
> > > + SDRAM0: memory-controller {
> > > + compatible = "ibm,sdram-405gp";
> > > + dcr-reg = <010 2>;
> > > + };
> > > +
> > > + MAL: mcmal {
> > > + compatible = "ibm,mcmal-405gp", "ibm,mcmal";
> > > + dcr-reg = <180 62>;
> > > + num-tx-chans = <2>;
> > > + num-rx-chans = <1>;
> > > + interrupt-parent = <&UIC0>;
> > > + interrupts = <a 4 b 4 c 4 d 4 e 4>;
> > > + };
> > > +
> > > + POB0: opb {
> > > + compatible = "ibm,opb";
> >
> > Need an opb-405gp here, too.
>
> Yep.
Fixed.
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + ranges = <0 ef600000 a00000>;
> >
> > Hrm... something we ought to clarify is the interpretation of the
> > POB0_BEAR register with respect to the bridge's ranges property. For
> > 440 I think the BEAR will need to be interpreted as an OPB address,
> > rather than a PLB address, but I'm not sure if that will work here
> > with the limited ranges property you have.
>
> Ok, I'll look at this.
The BEAR will still be interpreted as a PLB address here as far as I
can see. The ranges spans the entire OPB space. Am I missing
something?
josh
^ permalink raw reply
* Re: [patch 5/6] Walnut board support
From: Josh Boyer @ 2007-09-04 12:37 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <1188741546.3772.5.camel@localhost.localdomain>
On Sun, 02 Sep 2007 08:59:06 -0500
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Mon, 2007-09-03 at 11:11 +1000, David Gibson wrote:
> > On Fri, Aug 31, 2007 at 03:04:54PM -0500, Josh Boyer wrote:
> > > Board support for the PPC405 Walnut evaluation board
> > >
> > > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> >
> > [snip]
> > > --- linux-2.6.orig/arch/powerpc/platforms/40x/Kconfig
> > > +++ linux-2.6/arch/powerpc/platforms/40x/Kconfig
> > > @@ -53,13 +53,13 @@
> > > # help
> > > # This option enables support for the IBM PPC405GPr evaluation board.
> > >
> > > -#config WALNUT
> > > -# bool "Walnut"
> > > -# depends on 40x
> > > -# default y
> > > -# select 405GP
> > > -# help
> > > -# This option enables support for the IBM PPC405GP evaluation board.
> > > +config WALNUT
> > > + bool "Walnut"
> > > + depends on 40x
> > > + default y
> > > + select 405GP
> > > + help
> > > + This option enables support for the IBM PPC405GP evaluation board.
> >
> > Surely this needs WANT_DEVICE_TREE, too.
>
> Yes, will be fixed.
Er, actually no it won't. It doesn't need to be selected here, as 40x
in arch/powerpc/platforms/Kconfig.cputype already selects
WANT_DEVICE_TREE. Same thing that ebony and bamboo do for 44x.
josh
^ permalink raw reply
* Re: "atomic" 64-bit math on 32-bit ppc's?
From: Matt Sealey @ 2007-09-04 12:31 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: ppc-dev
In-Reply-To: <20070904113937.GA3994@iram.es>
Gabriel Paubert wrote:
> On Tue, Sep 04, 2007 at 12:09:22PM +0100, Matt Sealey wrote:
>> Hi guys,
>>
>> The Solaris PPC code drop included most of these functions for 32-bit ops on
>> 32-bit PPC architectures but the 64-bit operations are not present. What I
>> a not clear on is the operation of lwarx and stwcx. and if they will work if
>> you are doing operations on two words at a time.
>
> No. There is a single reservation for a single word.
This is what I gathered from the programming environments manual at least.
> the 64 bit operations inside a spinlock on PPC32, and then select the
> number /location of spinlock(s) based on your needs, from one global
> per machine to one per 64 bit variable if you find excessive contention.
Okay that makes sense, but it would have to be a super global big lock,
I don't think the code is there in ZFS to give every 64-bit variable it's
own dedicated spinlock (kind of an overhaul) and I'm trying to be fast..
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: Thanks and new problems
From: Clemens Koller @ 2007-09-04 12:28 UTC (permalink / raw)
To: schardt; +Cc: Linux PPC Linux PPC
In-Reply-To: <46DD4B6A.3020401@fz-juelich.de>
schardt schrieb:
> First, many many thanks to Grant. My VirtexII Demo Board ist running a
> 2.6. Linux :))
>
> But now, i switched to a Virtex4-Board with Ethernet (Mini Module from
> Avnet)
> This will i used in my application, if i can handle it. :)
>
> Linux is up and running, the ethernet is detected as eth0, link led is on
> but, and thats the problem, speed negotiating das not work.
Check the PHY configuration (i.e. the bootstrap pins on the PHY).
And - if appropriate - read out the PHY configuration (MDIO) and see
if it's correct.
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: [RFC] AmigaOne device tree source v2
From: Gerhard Pircher @ 2007-09-04 12:20 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, david
In-Reply-To: <6858c7a36ed061265937daa7b14cc5ac@kernel.crashing.org>
-------- Original-Nachricht --------
> Datum: Tue, 4 Sep 2007 00:52:02 +0200
> Von: Segher Boessenkool <segher@kernel.crashing.org>
> An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org, David Gibson <david@gibson.dropbear.id.au>
> Betreff: Re: [RFC] AmigaOne device tree source v2
> >>> Yeah, PCI is a special case for Linux. Maybe add a "pciclass,XXXX"
> >>> compatible property though, for good measure. Anything else isn't
> >>> all that useful I think.
> > Wouldn't that be the same as the class-code property?
>
> Sure, except it is a different property. If you use the "class-code"
> thing, you really should implement _all_ of the PCI binding's required
> properties. If you don't (since Linux doesn't use it anyway), it might
> still be nice to have a "compatible" property at least (since that is
> what is used for figuring out what device driver to use for this device
> node). Linux doesn't currently use that either, so you don't have to,
> but you could put it there and it would make sense, that's all.
Okay, I'll add a compatible = "pciclass,0101"; property to the node.
BTW: It looks like the Pegasos II device tree defines device_type = "spi"
for the IDE controller. Is that correct?
> If those addresses really show up in the PCI BARs (most controllers
> don't do that in legacy mode), the kernel's own PCI probing will
> see it already; if they aren't in BARs, it is a bit tricky to encode
> that correctly in the "reg" (it's perfectly well-defined, just a bit
> hard to get it right).
These addresses show up in the PCI BARs of the VIA 686B IDE controller,
even if it is configured for compatible mode.
> There is no such thing as "interrupt 14 and 15" on PCI. You can use
> the interrupt mapping recommended practice to show two interrupts
> (and their polarity, and how they are routed to the relevant interrupt
> controller) in the IDE node.
But I'll still need a quirk in the IDE driver, because it doesn't make
use of any interrupt routing information in the device tree. If so, I
can omit the whole IDE controller device node and simply rely on the
IDE driver's probe functions and the Pegasos IDE IRQ quirk.
I wonder how this issue will be handled for libata and the via-pata
driver, since IIRC this one doesn't contain the Pegasos IDE IRQ quirk.
Thanks,
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* Thanks and new problems
From: schardt @ 2007-09-04 12:11 UTC (permalink / raw)
To: Linux PPC Linux PPC
First, many many thanks to Grant. My VirtexII Demo Board ist running a
2.6. Linux :))
But now, i switched to a Virtex4-Board with Ethernet (Mini Module from
Avnet)
This will i used in my application, if i can handle it. :)
Linux is up and running, the ethernet is detected as eth0, link led is on
but, and thats the problem, speed negotiating das not work.
is this more a linux problem or hardware ???
Regards
Georg
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.
Vorsitzender)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
^ 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