* Re: Memory mapping PCI memory region to user space
From: Phil Nitschke @ 2006-03-29 2:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <43A30583-5E99-46A8-B419-1AEAB8440840@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]
On Mon, 2006-03-27 at 10:18 -0600, Kumar Gala wrote:
> On Mar 27, 2006, at 2:02 AM, Phil Nitschke wrote:
>
> > On Thu, 2006-03-23 at 09:44 -0600, Kumar Gala wrote:
> >> On Mar 23, 2006, at 8:21 AM, Wyse, Chris wrote:
> >>
> >>> Hi,
> >>>
> >>> I'm trying to map a PCI memory region 1 into user space from my
> >>> driver (PPC440GX, Linux 2.6.10). Here's the mmap routine of the
> >>> driver that I'm using:
> >>
> >> Why don't use the mmap file exposed by sysfs so you dont have to
> >> write your own code?
> >>
> >> See Documentation/filesystems/sysfs-pci.txt. But effectively down
> >> under /sys/bus/pci/devices/[domain:bus:dev:func]/ you will get
> >> resource[0..N-1] that corresponds to each BAR on the device. This is
> >> a mmap file to access that region.
> >
> > I have some custom hardware that appears on the PCI bus as follows:
> >
> > bash-3.00# lspci -vv
> > 00:01.0 Class 0680: 1172:0004 (rev 01)
> > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> > Stepping- SERR- FastB2B-
> > Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort+
> > <TAbort- <MAbort- >SERR- <PERR-
> > Latency: 128, Cache Line Size 08
> > Interrupt: pin A routed to IRQ 71
> > Region 0: Memory at 000000009ffff000 (32-bit, non-prefetchable)
> > [size=4K]
> > Region 1: Memory at 000000009fc00000 (32-bit, non-prefetchable)
> > [size=2M]
> >
> > But when I try to access resource0 or resource1, I get a read error.
> > What characteristic of the device or driver determines whether it will
> > allow mmap-ing?
> >
> > (I've written the driver for this device myself.)
>
> Nothing special beyond normal unix perms on the resource[0..n] files
> to my knowledge. When you say you get a read error what exactly does
> that mean?
It means I had a bug in my program which read (mmap()ed) the resouce :-(
It is fixed now (see below). Thanks for the tip.
--
Phil Nitschke <Phil.Nitschke@avalon.com.au>
Avalon Systems Pty Ltd
[-- Attachment #2: mmap.c --]
[-- Type: text/x-csrc, Size: 1009 bytes --]
#include <assert.h>
#include <byteswap.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <sys/mman.h>
#include <unistd.h>
int
main (int argc, char **argv)
{
/* Define constants for specific to the Base Address Register(s)
* (defining the PCI I/O Address Region) for our hardware. */
const uint32_t BAR_LENGTH = 0x200000;
const uint32_t CTRL_REGS = 0x80000;
const uint32_t CTRL_LEN = 0x30;
int i, fd;
uint32_t *ptr;
fd = open("/sys/bus/pci/devices/0000:00:01.0/resource1", O_RDWR);
ptr = (uint32_t*) mmap(NULL, BAR_LENGTH, PROT_READ|PROT_WRITE,
MAP_SHARED, fd, 0);
// If ptr == -1, then the user was probably not root
assert(ptr != MAP_FAILED);
printf ("Mapped %p bytes beginning at address %p\n", BAR_LENGTH, ptr);
for (i = CTRL_REGS; i < (CTRL_REGS + CTRL_LEN); i += 4)
printf ("mmap[0x%08x] (%p) = 0x%08x [0x%08x]\n",
i, ptr + i/4, *(ptr + i/4), bswap_32(*(ptr + i/4)));
munmap(ptr, BAR_LENGTH);
close(fd);
}
^ permalink raw reply
* Re: [PATCH] DTC - validation by device_type
From: Hollis Blanchard @ 2006-03-29 2:03 UTC (permalink / raw)
To: Paul Nasrat; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <1143586160.2660.19.camel@enki.eridu>
On Mar 28, 2006, at 4:49 PM, Paul Nasrat wrote:
>
> It'd be nice to be able to validate by device_type, to ensure that we
> don't reinvent the wheel (address vs. local-mac-address) and to give
> embedded designers an added level of sanity checking.
>
> Here is a proposed implementation with an implemented check for
> "network".
>
> Signed-off-by: Paul Nasrat <pnasrat@redhat.com>
>
> diff --git a/livetree.c b/livetree.c
> index ef54174..351773b 100644
> --- a/livetree.c
> +++ b/livetree.c
> @@ -441,6 +441,52 @@ static int check_structure(struct node *
> (propname), (node)->fullpath); \
> } while (0)
>
> +static int check_network(struct node *net)
> +{
> +
> + int ok = 1;
> + struct property *prop;
> +
> + CHECK_HAVE_STREQ(net, "device_type", "network");
The only reason you got into this function was that device_type ==
"network"...
> + CHECK_HAVE(net, "reg");
> + CHECK_HAVE(net, "local-mac-address");
> + CHECK_HAVE(net, "mac-address");
> + CHECK_HAVE(net, "address-bits");
> +
> + return ok;
> +}
> +
> +static struct {
> + char *devtype;
> + int (*check_fn)(struct node *node);
> +} devtype_checker_table[] = {
> + {"network", check_network},
> +};
> +
> +static int check_devtypes(struct node *root)
> +{
> +
> + struct node *child;
> + struct property *prop;
> + int ok = 1;
> + int i;
> +
> + for_each_child(root, child) {
> + /* check this node */
> + if ((prop = get_property((child), ("device_type"))))
> + for (i = 0; i < ARRAY_SIZE(devtype_checker_table); i++) {
> + if (streq(prop->val.val, devtype_checker_table[i].devtype))
> + if (! devtype_checker_table[i].check_fn(child)) {
> + ok = 0;
> + break;
> + }
Unless this is some weird style thing, that close brace seems
misindented.
> + }
> + ok = check_devtypes(child);
> + }
> +
> + return ok;
> +}
> +
> static int check_root(struct node *root)
> {
> struct property *prop;
> @@ -716,6 +762,7 @@ int check_device_tree(struct node *dt)
> ok = ok && check_cpus(dt);
> ok = ok && check_memory(dt);
> ok = ok && check_chosen(dt);
> + ok = ok && check_devtypes(dt);
> if (! ok)
> return 0;
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [OT] ppc64 serialization problem
From: Greg Smith @ 2006-03-29 1:58 UTC (permalink / raw)
To: linuxppc-dev
We have a multi-threaded app running on a p520 in 64 bit mode.
Thread A does
pthread_mutex_lock(&lock);
u32 &= ~bitA;
pthread_mutex_unlock(&lock);
and Thread B does
pthread_mutex_lock(&lock);
u32 |= bitB;
A = u32;
B = u32;
pthread_mutex_unlock(&lock);
On rare occasions, values A and B will differ! In the examples that I
have seen, there is contention with `lock'. This phenomenon does not
occur on ppc32 or a number of other architectures that we support.
I confess I do not know the linux version nor the glibc version nor what
pthreads implementation is being used. I'll find that out shortly.
What I am curious about is where the problem might lie
(kernel/lib/pthreads/app) so I can ask the right people.
Thank you for your patience,
Greg Smith
^ permalink raw reply
* Re: snd-aoa: new apple sound driver
From: Benjamin Herrenschmidt @ 2006-03-28 23:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, debian-powerpc, Alastair Poole
In-Reply-To: <1143547826.13615.24.camel@localhost>
> GPIO stuff. Currently, the only GPIO I touch is the amp-mute one to turn
> on the internal speakers. This is done in the onyx codec module which
> obviously isn't the right place for it. This should be moved into the
> layout fabric module which draws on some common gpio code to program the
> GPIOs. Then it creates controls alsa for amp-mute etc. instead of
> unconditionally turning it on, and also registers the interrupts for
> headhpone detection etc.
The GPIO stuff is a bit can-of-worms-ish ... we need at least 2
different implementations for machines using "old style" direct GPIO
access and machines using platform functions. So we may need a gpio
"driver" with 2 instances there.
I think we need to hook that with the input/output net... basically we
just say things like mute/unmute(id) and the gpio "layer" sort of
matches the input/output "id" with whatever gpios it has at hand. That's
also why I think your input/output IDs should have separate entries for
combo connectors vs. analog line out (at least you used not to, I
haven't looked at the latest code).
Then, the core would get events from interrupts (or clock switches from
the codecs) via a yet-to-be-defined call and would react by calling the
various mute/unmutes accordingly for available inputs and outputs on the
bus where the event occured.
For things like headphone/speaker automute, I think we need a kind of
tristate.. either that, or we need a bit mask of mute conditions. When
any of them is set, it's muted. That way, the "user" mute control sticks
regardless of the automute action or temporary mute to analog outputs
because, for example, the digital input lost its clock and we are
switching (we need to mute to avoid "clics").
> Clock setting. I'm clueless as to programming keylargo in linux. Thing
> is, I need to stop the clock to the i2s cell before reprogramming it's
> serial format register, and this requires access to the FCR registers.
> But I don't know how to get at them best. Need help here. Clock setting
> also includes running the i2s cell in slave mode so we can have digital
> input. The infrastructure for slave mode isn't too established yet, but
> it should be easy to fit it over what is currently there in
> soundbus.h/i2sbus.
Hrm... So my feature calls are doing too much at once... (they both do
the clocks and the cell enable). I don't do clock refcounting like Apple
does tho, thus the main clock sources are always enabled. So I think all
you have to do is toggle the I2Sn_CLK_ENABLE bits ...
Can you verify if all machines that have digital inputs (thus all
machines for which you may need to do that kind of clock switching) also
have working platform functions for doing so ? If they do, then it's
really just a matter of calling those. If not, then we can either
ioremap the FCR's in the driver and play with them (evil solution +
possibly locking problems) or add a feature call.
In the later case, you add a feature call in pmac_feature.h and the
appropriate entry in the table in feature.c and then you can toggle bits
as you wish with appropriate locking (look at eixsting code in there). I
can give you more details on irc if you need.
But it would be nice if it could all be done with platform functions
instead.
> Modalias situtation. I played some tricks: i2sbus depends on soundbus
> but announces its willingness to be bound to the i2s OF thing that macio
> exports on its bus, so i2sbus is loaded automatically. i2sbus creates
> some soundbus devices that have a name based on the layout ID if
> possible, which should in turn auto-load snd-aoa-fabric-layout which
> declares its willingness to be bound to such devices. This doesn't
> happen during boot, even though modprobe `cat ...../modalias` works just
> fine. No idea, need help from someone versed with hotplugging.
> But hey, it's already much much closer than snd-powermac ever was ;)
Yeah :) There might be some issue with the macio automatching from
userland, not sure yet, could just be missing bits in hotplug scripts.
> Recording. There's code to record sound, but it doesn't do anything on
> my machine. I have no idea why.
What machine ? The quad ? maybe you need some gpio manipulation or maybe
you just didn't get something right in onyx ... I'll try later.
> Suspend. I have a plan for it, so before thinking about it you may want
> to look at some old revisions of my code where a huge comment about
> suspend is buried in soundbus.h (I removed it again because it wasn't
> quite right any more, but still has the essence of what I intend to do).
No time to look now, but the idea would be that:
- macio_device gets the suspend resume event. That is, the i2s busses
basically. That code should forward to all attaches sub-busses which
then dispatch to codecs.
- ordering of things should be: mute all, stop alsa, stop codecs
(enable whatever internal power management mode they may have), stop
clocks, disable i2s cells.
> Onyx digital output. Currently, onyx always declares that the digital
> output is usable even if it is turned off, leading to a restriction in
> the output formats you can play. Note that due to 'clock switching'
> above, you can only play 44.1KHz currently anyway. But Onyx should make
> that depend on the status of the control, and then lock the control if a
> bitrate was chosen that isn't compatible with the digital output.
Yup.
> Make i2sbus compatible with old machines. I wrote i2sbus for new
> machines only, it relies a lot on stuff that older machines may not have
> in the device tree. So someone who has older machines should look into
> it and give me patches.
I'll play with adapting the whole stuff to older machines, I have plenty
of those :) We also need to implement a davbus module, so make sure you
don't have too much i2s-related assumptions in your core.. No timeframe
for that though, I'm fairly busy with other things at the moment
> Now, that said, it's actually working fine for just playing sound on the
> internal speakers now :)
> The GPIO stuff should be a fairly low-hanging fruit so if someone wants
> to take it...
It's also a complicated thing because of the need to deal with old
machines and the need to coordinate properly & serialize... things like
interrupts or events from the codec should, if possible, use alsa hidden
controls or whatever other ways to properly serialize, if possible, be
run at task level (from a work queue) and things like that (due to the
need for delays etc...
Ben.
^ permalink raw reply
* [PATCH] DTC - validation by device_type
From: Paul Nasrat @ 2006-03-28 22:49 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Jon,
It'd be nice to be able to validate by device_type, to ensure that we
don't reinvent the wheel (address vs. local-mac-address) and to give
embedded designers an added level of sanity checking.
Here is a proposed implementation with an implemented check for
"network".
Signed-off-by: Paul Nasrat <pnasrat@redhat.com>
diff --git a/livetree.c b/livetree.c
index ef54174..351773b 100644
--- a/livetree.c
+++ b/livetree.c
@@ -441,6 +441,52 @@ static int check_structure(struct node *
(propname), (node)->fullpath); \
} while (0)
+static int check_network(struct node *net)
+{
+
+ int ok = 1;
+ struct property *prop;
+
+ CHECK_HAVE_STREQ(net, "device_type", "network");
+ CHECK_HAVE(net, "reg");
+ CHECK_HAVE(net, "local-mac-address");
+ CHECK_HAVE(net, "mac-address");
+ CHECK_HAVE(net, "address-bits");
+
+ return ok;
+}
+
+static struct {
+ char *devtype;
+ int (*check_fn)(struct node *node);
+} devtype_checker_table[] = {
+ {"network", check_network},
+};
+
+static int check_devtypes(struct node *root)
+{
+
+ struct node *child;
+ struct property *prop;
+ int ok = 1;
+ int i;
+
+ for_each_child(root, child) {
+ /* check this node */
+ if ((prop = get_property((child), ("device_type"))))
+ for (i = 0; i < ARRAY_SIZE(devtype_checker_table); i++) {
+ if (streq(prop->val.val, devtype_checker_table[i].devtype))
+ if (! devtype_checker_table[i].check_fn(child)) {
+ ok = 0;
+ break;
+ }
+ }
+ ok = check_devtypes(child);
+ }
+
+ return ok;
+}
+
static int check_root(struct node *root)
{
struct property *prop;
@@ -716,6 +762,7 @@ int check_device_tree(struct node *dt)
ok = ok && check_cpus(dt);
ok = ok && check_memory(dt);
ok = ok && check_chosen(dt);
+ ok = ok && check_devtypes(dt);
if (! ok)
return 0;
^ permalink raw reply related
* [PATCH] Janitor: drivers/net/pcnet32: fix incorrect comments
From: Linas Vepstas @ 2006-03-28 22:36 UTC (permalink / raw)
To: tsbogend, donf; +Cc: linuxppc-dev, linux-kernel, jklewis, netdev
Please sign-off/ack/apply and/or forward upstream.
[PATCH] Janitor: drivers/net/pcnet32: fix incorrect comments
The comments concerning how the pcnet32 ethernet device driver selects
the MAC addr to use are incorrect. A recent patch (in the last 3 months)
changed how the code worked, but did not change the comments.
Side comment: the new behaviour is good; I've got a pcnet32 card which
powers up with garbage in the CSR's, and a good MAC addr in the PROM.
Signed-off-by: Linas Vepstas <linas@linas.org>
----
drivers/net/pcnet32.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.16-git6/drivers/net/pcnet32.c
===================================================================
--- linux-2.6.16-git6.orig/drivers/net/pcnet32.c 2006-03-23 12:21:41.000000000 -0600
+++ linux-2.6.16-git6/drivers/net/pcnet32.c 2006-03-28 16:08:23.398158717 -0600
@@ -1167,8 +1167,8 @@ pcnet32_probe1(unsigned long ioaddr, int
* station address PROM at the base address and programmed into the
* "Physical Address Registers" CSR12-14.
* As a precautionary measure, we read the PROM values and complain if
- * they disagree with the CSRs. Either way, we use the CSR values, and
- * double check that they are valid.
+ * they disagree with the CSRs. If they miscompare, and the PROM addr
+ * is valid, then the PROM addr is used.
*/
for (i = 0; i < 3; i++) {
unsigned int val;
^ permalink raw reply
* Re: Kernel for MPC Lite 5200 will not compile
From: Wolfgang Denk @ 2006-03-28 22:33 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-embedded
In-Reply-To: <4b73d43f0603280815n3fc7bb5dq38b72f87f18b905f@mail.gmail.com>
In message <4b73d43f0603280815n3fc7bb5dq38b72f87f18b905f@mail.gmail.com> you wrote:
>
> Sorry I'm not sure what the state of 5200 support in the eldk. I know that
> Wolfgang
> has said that 2.6 is not supported though. You may want to try out Sylvains
Well, that's exxactly the state: not supported (i. e. known to be
broken).
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Quotation, n. The act of repeating erroneously the words of another.
The words erroneously repeated.
- Ambrose Bierce _The Devil's Dictionary_
^ permalink raw reply
* Re: Kernel for MPC Lite 5200 will not compile
From: Wolfgang Denk @ 2006-03-28 22:31 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060328000703.GA95672@server.idefix.loc>
In message <20060328000703.GA95672@server.idefix.loc> you wrote:
>
> I installed today ELDK 4.0 for the LITE5200 board (icecube).
There is no "ELDK 4.0 for the LITE5200 board".
> ./install -d /usr/local/eldk ppc_6xx
This installas ELDK 4.0 for PPC 6xx processors. Nothing less, but
nothing more either.
> After compiling u-boot and playing a little bit with it, i tried to
> compile the kernel 2.6.
Which kernel tree are you using? There is no support for MPC5200 in
the DENX Linux tree. Well, some code is there, as there is in the
public 2.6 kernel tree, but it's known to be broken and not supported
by us.
> For this I used the git repository.
Which one?
> I copied the file arch/ppc/configs/lite5200_defconfig to .config, and
> tried the following one:
> make ARCH=ppc CROSS_COMPILE=ppc_6xx- uImage
That's not the official way to build images.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
We, the unwilling, led by the unknowing, are doing the impossible for
the ungrateful. We have done so much, for so long, with so little, we
are now qualified to do anything with nothing.
^ permalink raw reply
* Re: 2.6.16 does not boot on powerbook
From: Benjamin Herrenschmidt @ 2006-03-28 22:08 UTC (permalink / raw)
To: Dustin Lang; +Cc: linuxppc-dev, Michal Purzynski
In-Reply-To: <Pine.LNX.4.60.0603280630130.8520@tin.icics.ubc.ca>
> 2.6.16 works fine on my PowerBook 6,2. When I patched up to 2.6.16 I
> found I had to go through the config process - some of the PowerMac
> options seem to have been turned off. Maybe that was just me doing
> something wrong, or maybe some of the Kconfig defaults changed?
Some stuffs changed in Kconfig causing it to stupidly drop most of the
pmac options ...
Ben.
^ permalink raw reply
* Re: 2.6.16 does not boot on powerbook
From: Benjamin Herrenschmidt @ 2006-03-28 22:07 UTC (permalink / raw)
To: wrobell; +Cc: linuxppc-dev
In-Reply-To: <1143556705.3562.104.camel@RECENT-CONVERT>
On Tue, 2006-03-28 at 15:38 +0100, wrobell wrote:
> On Tue, 2006-03-28 at 14:01 +0200, Michal Purzynski wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > hey,
> >
> > i've just installed 2.6.16 vanilla kernel on powerbook G4 but it cannot
> > boot.
> [...]
> > my kernel config (the same config works on 2.6.15)
> [...]
> > # CONFIG_PPC_PMAC is not set
>
> you have to go through configuration options carefully.
> some of them are disabled because of ppc32/64 arch merging changes
> (please correct me if i am wrong).
There is a pmac32_defconfig you can use as a basis now.
Ben.
^ permalink raw reply
* Re: snd-aoa & rates
From: Benjamin Herrenschmidt @ 2006-03-28 22:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <1143548101.13615.30.camel@localhost>
On Tue, 2006-03-28 at 14:15 +0200, Johannes Berg wrote:
> Hi,
>
> > Current snd-aoa blew up on me at module load btw ... anyway, that's not
> > my point here :)
>
> Yeah, keywest programming. Need help, see other mail.
No other mail in the box ...
^ permalink raw reply
* Re: make install on ppc
From: Paul Mackerras @ 2006-03-28 21:13 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev list
In-Reply-To: <200603281402.02449.hollis@penguinppc.org>
Hollis Blanchard writes:
> I don't understand these objections. If someone's platform is so super-special
> that a script couldn't possibly know how to install a kernel, just don't run
> make install!
I don't see any problem either. If someone had bothered to produce a
patch, it would have been applied by now. :)
Paul.
^ permalink raw reply
* Re: Kernel for MPC Lite 5200 will not compile
From: Sylvain Munaut @ 2006-03-28 20:47 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-embedded
In-Reply-To: <4b73d43f0603280815n3fc7bb5dq38b72f87f18b905f@mail.gmail.com>
Hi Matthias,
You might want to try the "quick start" section of
http://www.246tnt.com/mpc52xx/
The last compile I tried worked just fine ... You just needed to be sure
CONFIG_NET is
enabled (even if you don't use network ... the issue is known and being
taken care of,
I've seen some posts of Russel King and Andrew Morton about it).
If it still doesnt work, report it and I'll have a closer look. Maybe
something changed
recently and I didn't update my tree since a few days ...
Sylvain
John Rigby wrote:
> Sorry I'm not sure what the state of 5200 support in the eldk. I know
> that Wolfgang
> has said that 2.6 is not supported though. You may want to try out
> Sylvains
> kernel: http://gitbits.246tnt.com/gitbits/linux-2.6-mpc52xx.git
>
> You can search in list for Syvains instructions on how to use it.
>
>
> On 3/28/06, *Matthias Fechner* <idefix@fechner.net
> <mailto:idefix@fechner.net>> wrote:
>
> Hello John,
>
> * John Rigby <jcrigby@gmail.com <mailto:jcrigby@gmail.com>>
> [27-03-06 18:01]:
> > try make lite5200_defconfig instead of copying it to .config
> > or make oldconfig after copying ti to .config
>
> I tried now several combinations with:
> make ARCH=ppc CROSS_COMPILE=ppc_6xx- lite5200_defconfig
> make ARCH=ppc CROSS_COMPILE=ppc_6xx- uImage
>
> then coping the file to .config and
> make ARCH=ppc CROSS_COMPILE=ppc_6xx- oldconfig
> make ARCH=ppc CROSS_COMPILE=ppc_6xx- uImage
>
> but it always leads to the same error message...
>
> Best regards,
> Matthias
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org <mailto:Linuxppc-embedded@ozlabs.org>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: make install on ppc
From: Geoff Levand @ 2006-03-28 20:30 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev list
In-Reply-To: <200603281402.02449.hollis@penguinppc.org>
Hollis Blanchard wrote:
> On Tuesday 28 March 2006 13:06, you wrote:
>> Problem is for multi-platform binary builds, 'install' could mean different
>> things for the different platforms, so to support install, there needs
>> to be some way to tell the build system what 'install' means that also
>> works with the muti-platform makefile logic. The current powerpc makefiles
>> don't have this, and it would take some non-trivial rework to add it.
>
> That is for the distribution- or user-supplied installkernel script to deal
> with.
To handle the situation I mentioned, the build system would need to either tell
the installkernel script what to do, or call different installkernel scripts,
so the build system itself needs to have some notion of what install means,
but as I mentioned, that is currently missing from the makefiles.
>> There is also the question of what install means when cross building.
>
> So don't run make install when cross-compiling (unless of course your
> installkernel script supports that).
But I would like to...
> I don't understand these objections. If someone's platform is so super-special
> that a script couldn't possibly know how to install a kernel, just don't run
> make install!
I guess you misunderstood me. I'm not objecting nor saying it shouldn't be
done, just stating some of what needs to be done to make it work properly.
The logic needed is not trivial, and more work is needed than just adding
an 'install' target line to a makefile.
-Geoff
^ permalink raw reply
* Re: make install on ppc
From: Hollis Blanchard @ 2006-03-28 20:02 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev list
In-Reply-To: <44298929.1060003@am.sony.com>
On Tuesday 28 March 2006 13:06, you wrote:
> Problem is for multi-platform binary builds, 'install' could mean differe=
nt
> things for the different platforms, so to support install, there needs
> to be some way to tell the build system what 'install' means that also
> works with the muti-platform makefile logic. =C2=A0The current powerpc ma=
kefiles
> don't have this, and it would take some non-trivial rework to add it.
That is for the distribution- or user-supplied installkernel script to deal=
=20
with.
> There is also the question of what install means when cross building.
So don't run make install when cross-compiling (unless of course your=20
installkernel script supports that).
I don't understand these objections. If someone's platform is so super-spec=
ial=20
that a script couldn't possibly know how to install a kernel, just don't ru=
n=20
make install!
=2DHollis
^ permalink raw reply
* Re: [PATCH] Workaround for RTAS bug
From: Mike Kravetz @ 2006-03-28 19:42 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060327231959.GA15383@w-mikek2.ibm.com>
On Mon, Mar 27, 2006 at 03:20:00PM -0800, Mike Kravetz wrote:
> Also note that the 32 bit version of enter_rtas() should have the same
> work around even though the chances of hitting the bug are much smaller
> due to the lack of DLPAR on 32 bit kernels. However, my assembly skills
> are a bit rusty and the 32 bit code doesn't seem to follow the conventions
> for where things should be saved. In addition, I don't have a system
> to test 32 bit kernels. Help creating and at least touch testing the
> same workaround for 32 bit would be appreciated.
Upon further examination, there does not appear to be any exposure to
this issue on 32 bit kernels. Therefore, the original patch for 64 bit
should be the only workaround that is required.
--
Mike
^ permalink raw reply
* Re: make install on ppc
From: Geoff Levand @ 2006-03-28 19:06 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev list
In-Reply-To: <f78eb6c06abb98fbc1cf8ae32bbf2268@penguinppc.org>
Hollis Blanchard wrote:
> On Mar 26, 2006, at 7:56 PM, Brent Cook wrote:
>
>> On Sunday 26 March 2006 19:42, Jin Qi Huang wrote:
>>> I also think the 'make install' is very useful, now on ia32, the
> 'make
>>> install' provided by the latest kernel linux-2.6.16 not only create
>>> initrd, copy vmlinuz and System.map to /boot directory, but also
>>> update
>>> grub, ppc32 does not provide this useful feature, maybe it is a pity!
>
> The feature sounds like a good idea to me, even if it's just the
> copying files part. Do any PPC distros provide a working installkernel
> script?
Problem is for multi-platform binary builds, 'install' could mean different
things for the different platforms, so to support install, there needs
to be some way to tell the build system what 'install' means that also
works with the muti-platform makefile logic. The current powerpc makefiles
don't have this, and it would take some non-trivial rework to add it.
There is also the question of what install means when cross building.
I run make from a script that I tell the platform. The script does
what's needed for that platform to get it built and installed.
-Geoff
^ permalink raw reply
* Re: PPC405EP and Abatron BDI help
From: Tolunay Orkun @ 2006-03-28 17:59 UTC (permalink / raw)
To: Jeff.Fellin; +Cc: linuxppc-embedded
In-Reply-To: <OF3A743E50.87BEEA66-ON8525713F.00587402@teal.com>
Hi,
I am also involved in bring up effort of a 405EP board (in-house
developed). We had 3rd party 405GP boards before so I expected bring up
to be less rocky but there are some subtle differences to note.
Are you configuring the PerWE* and PerCS* properly?
1) You need to set CPC0_PCI[SPE] bit to set PerWE* as output for CS0
(So, you can write your Flash connected to CS0. Note that this is DCR
0x0F9. There are incorrect references in the manual as the register
number is 0x0F4 (which is PLLMR1)
2) You need to program GPIO pins to alternate functions via GPIO0
registers (Read Chapter 23 of 405EP manual) otherwise you will not sett
CS* asserted for your devices (except CS0). For example, for CS1 you
need to set GPIO10 to alternate function.
On the 405GP these would normally be configured CPC0_CR0/1. 405EP
probably does not use these registers at all (well, the CPC0_CR
registers are not documented in 405EP manual except two places make
refer to it: table 3-6 and 12.2.1 Timer Base Counter -- someone else
could chime on this)
3) Of course you need to configure EBC0_BnCR and EBC0_BnAP as
appropriate to your peripheral as well.
Best regards,
Tolunay
Jeff.Fellin@rflelect.com wrote:
> I'm not sure if this forum can help me, but perhaps someone has experience
> with
> using an Abatron BDI2000 to control an AMCC PPC405EP evaluation board. I am
> having problems with getting the BDI to access devices on the external bus.
> I have verifed the EBC settings are correct by comparing them to the values
> set by Uboot 1.1.2 (Jun 2, 2005 Rev B) running on the board.
>
> I have used the base bubinga.cfg , Stefan Roese's configuration file, sent
> to me
> from someone on this mailing list. I modified the configuration to match
> the external
> device configuration of the AMCC PPC405EP evaluation board.
>
> Any ideas as to why I cannot access devices on the external bus using the
> BDI,
> but Uboot can?
>
>
> Jeff Fellin
> RFL Electronics
> Jeff.Fellin@rflelect.com
> 973 334-3100, x 327
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] lock PTE before updating it in 440/BookE page fault handler
From: Eugene Surovegin @ 2006-03-28 18:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17449.6575.927844.106127@cargo.ozlabs.ibm.com>
On Tue, Mar 28, 2006 at 10:10:39PM +1100, Paul Mackerras wrote:
> Eugene Surovegin writes:
>
> > Fix 44x and BookE page fault handler to correctly lock PTE before
> > trying to pte_update() it, otherwise this PTE might be swapped out
> > after pte_present() check but before pte_uptdate() call, resulting in
> > corrupted PTE. This can happen with enabled preemption and low memory
> > condition.
>
> That gives me this for an ARCH=powerpc 32-bit pmac build:
>
> /home/paulus/kernel/powerpc/arch/powerpc/mm/pgtable_32.c:376: error: conflicting types for 'get_pteptr'
> /home/paulus/kernel/powerpc/include/asm-ppc/pgtable.h:841: error: previous declaration of 'get_pteptr' was here
Oops, sorry. Haven't noticed we have duplicated files in ppc and
powerpc. Full patch follows.
Fix 44x and BookE page fault handler to correctly lock PTE before
trying to pte_update() it, otherwise this PTE might be swapped out
after pte_present() check but before pte_uptdate() call, resulting in
corrupted PTE. This can happen with enabled preemption and low memory
condition.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
arch/powerpc/mm/fault.c | 30 +++++++++++++++++-------------
arch/powerpc/mm/pgtable_32.c | 6 ++++--
arch/ppc/mm/fault.c | 30 +++++++++++++++++-------------
arch/ppc/mm/pgtable.c | 6 ++++--
include/asm-ppc/pgtable.h | 3 ++-
5 files changed, 44 insertions(+), 31 deletions(-)
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index ec4adcb..5aea090 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -267,25 +267,29 @@ good_area:
#endif
#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
pte_t *ptep;
+ pmd_t *pmdp;
/* Since 4xx/Book-E supports per-page execute permission,
* we lazily flush dcache to icache. */
ptep = NULL;
- if (get_pteptr(mm, address, &ptep) && pte_present(*ptep)) {
- struct page *page = pte_page(*ptep);
-
- if (! test_bit(PG_arch_1, &page->flags)) {
- flush_dcache_icache_page(page);
- set_bit(PG_arch_1, &page->flags);
+ if (get_pteptr(mm, address, &ptep, &pmdp)) {
+ spinlock_t *ptl = pte_lockptr(mm, pmdp);
+ spin_lock(ptl);
+ if (pte_present(*ptep)) {
+ struct page *page = pte_page(*ptep);
+
+ if (!test_bit(PG_arch_1, &page->flags)) {
+ flush_dcache_icache_page(page);
+ set_bit(PG_arch_1, &page->flags);
+ }
+ pte_update(ptep, 0, _PAGE_HWEXEC);
+ _tlbie(address);
+ pte_unmap_unlock(ptep, ptl);
+ up_read(&mm->mmap_sem);
+ return 0;
}
- pte_update(ptep, 0, _PAGE_HWEXEC);
- _tlbie(address);
- pte_unmap(ptep);
- up_read(&mm->mmap_sem);
- return 0;
+ pte_unmap_unlock(ptep, ptl);
}
- if (ptep != NULL)
- pte_unmap(ptep);
#endif
/* a write */
} else if (is_write) {
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index d296eb6..9062860 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -372,7 +372,7 @@ void __init io_block_mapping(unsigned lo
* the PTE pointer is unmodified if PTE is not found.
*/
int
-get_pteptr(struct mm_struct *mm, unsigned long addr, pte_t **ptep)
+get_pteptr(struct mm_struct *mm, unsigned long addr, pte_t **ptep, pmd_t **pmdp)
{
pgd_t *pgd;
pmd_t *pmd;
@@ -387,6 +387,8 @@ get_pteptr(struct mm_struct *mm, unsigne
if (pte) {
retval = 1;
*ptep = pte;
+ if (pmdp)
+ *pmdp = pmd;
/* XXX caller needs to do pte_unmap, yuck */
}
}
@@ -424,7 +426,7 @@ unsigned long iopa(unsigned long addr)
mm = &init_mm;
pa = 0;
- if (get_pteptr(mm, addr, &pte)) {
+ if (get_pteptr(mm, addr, &pte, NULL)) {
pa = (pte_val(*pte) & PAGE_MASK) | (addr & ~PAGE_MASK);
pte_unmap(pte);
}
diff --git a/arch/ppc/mm/fault.c b/arch/ppc/mm/fault.c
index 0217188..8e08ca3 100644
--- a/arch/ppc/mm/fault.c
+++ b/arch/ppc/mm/fault.c
@@ -202,6 +202,7 @@ good_area:
/* an exec - 4xx/Book-E allows for per-page execute permission */
} else if (TRAP(regs) == 0x400) {
pte_t *ptep;
+ pmd_t *pmdp;
#if 0
/* It would be nice to actually enforce the VM execute
@@ -215,21 +216,24 @@ good_area:
/* Since 4xx/Book-E supports per-page execute permission,
* we lazily flush dcache to icache. */
ptep = NULL;
- if (get_pteptr(mm, address, &ptep) && pte_present(*ptep)) {
- struct page *page = pte_page(*ptep);
-
- if (! test_bit(PG_arch_1, &page->flags)) {
- flush_dcache_icache_page(page);
- set_bit(PG_arch_1, &page->flags);
+ if (get_pteptr(mm, address, &ptep, &pmdp)) {
+ spinlock_t *ptl = pte_lockptr(mm, pmdp);
+ spin_lock(ptl);
+ if (pte_present(*ptep)) {
+ struct page *page = pte_page(*ptep);
+
+ if (!test_bit(PG_arch_1, &page->flags)) {
+ flush_dcache_icache_page(page);
+ set_bit(PG_arch_1, &page->flags);
+ }
+ pte_update(ptep, 0, _PAGE_HWEXEC);
+ _tlbie(address);
+ pte_unmap_unlock(ptep, ptl);
+ up_read(&mm->mmap_sem);
+ return 0;
}
- pte_update(ptep, 0, _PAGE_HWEXEC);
- _tlbie(address);
- pte_unmap(ptep);
- up_read(&mm->mmap_sem);
- return 0;
+ pte_unmap_unlock(ptep, ptl);
}
- if (ptep != NULL)
- pte_unmap(ptep);
#endif
/* a read */
} else {
diff --git a/arch/ppc/mm/pgtable.c b/arch/ppc/mm/pgtable.c
index 6ea9185..98a83be 100644
--- a/arch/ppc/mm/pgtable.c
+++ b/arch/ppc/mm/pgtable.c
@@ -368,7 +368,7 @@ void __init io_block_mapping(unsigned lo
* the PTE pointer is unmodified if PTE is not found.
*/
int
-get_pteptr(struct mm_struct *mm, unsigned long addr, pte_t **ptep)
+get_pteptr(struct mm_struct *mm, unsigned long addr, pte_t **ptep, pmd_t **pmdp)
{
pgd_t *pgd;
pmd_t *pmd;
@@ -383,6 +383,8 @@ get_pteptr(struct mm_struct *mm, unsigne
if (pte) {
retval = 1;
*ptep = pte;
+ if (pmdp)
+ *pmdp = pmd;
/* XXX caller needs to do pte_unmap, yuck */
}
}
@@ -420,7 +422,7 @@ unsigned long iopa(unsigned long addr)
mm = &init_mm;
pa = 0;
- if (get_pteptr(mm, addr, &pte)) {
+ if (get_pteptr(mm, addr, &pte, NULL)) {
pa = (pte_val(*pte) & PAGE_MASK) | (addr & ~PAGE_MASK);
pte_unmap(pte);
}
diff --git a/include/asm-ppc/pgtable.h b/include/asm-ppc/pgtable.h
index e1c62da..570b355 100644
--- a/include/asm-ppc/pgtable.h
+++ b/include/asm-ppc/pgtable.h
@@ -837,7 +837,8 @@ static inline int io_remap_pfn_range(str
*/
#define pgtable_cache_init() do { } while (0)
-extern int get_pteptr(struct mm_struct *mm, unsigned long addr, pte_t **ptep);
+extern int get_pteptr(struct mm_struct *mm, unsigned long addr, pte_t **ptep,
+ pmd_t **pmdp);
#include <asm-generic/pgtable.h>
^ permalink raw reply related
* Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Paul Nasrat @ 2006-03-28 16:55 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Jon Loeliger, Paul Mackerras
In-Reply-To: <20060328161431.18517.82573.stgit@vitb.ru.mvista.com>
On Tue, 2006-03-28 at 20:14 +0400, Vitaly Bordug wrote:
> Updated the documentation to include the initial description of the CPM2
> device that are used on PQII and PQIII families. Only initial sub-devices
> described so far, but that should be sufficient to move the respective
> boards to powerpc, with a reasonable minimum supporteddevice set.
>
> + 5) FCCs (Fast Communications Controllers)
> +
> + Required properties:
> +
> + - device_type : should be "network"
> + - model : "FCCx", x is typically a small number depending on the
> + devices amount
> + - compatible : should be "fs_enet"
> + - address : List of bytes representing the ethernet address of
> + this controller
Umm should we not use local-mac-address and mac-address (and
address-bits) as in section 3.7.4 in 1275-1994?
Paul
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Vitaly Bordug @ 2006-03-28 16:42 UTC (permalink / raw)
To: Kumar Gala; +Cc: Marcelo, linuxppc-dev, Paul Mackerras
In-Reply-To: <BA98B559-3041-4D80-A0DA-0CD9F6080B1B@kernel.crashing.org>
On Tue, 28 Mar 2006 10:37:02 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:
> Paul,
>
> Please dont accept this patch right away. I think we should let this
> have some discussion on the list before it goes in. I believe this
> is the first time any of the 8xx maintainers have seen this (Dan or
> Marcelo) so getting their feedback would be good.
>
That was implied... This is definitely RFC, I forgot to add that to the subject :)
> Nothing against your patch Vitaly :)
>
> - kumar
> --
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Kumar Gala @ 2006-03-28 16:37 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060328161431.18517.82573.stgit@vitb.ru.mvista.com>
Paul,
Please dont accept this patch right away. I think we should let this
have some discussion on the list before it goes in. I believe this
is the first time any of the 8xx maintainers have seen this (Dan or
Marcelo) so getting their feedback would be good.
Nothing against your patch Vitaly :)
- kumar
On Mar 28, 2006, at 10:14 AM, Vitaly Bordug wrote:
>
> Updated the documentation to include the initial description of the
> CPM2
> device that are used on PQII and PQIII families. Only initial sub-
> devices
> described so far, but that should be sufficient to move the respective
> boards to powerpc, with a reasonable minimum supporteddevice set.
>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
> ---
>
> Documentation/powerpc/booting-without-of.txt | 149 +++++++++++++++
> +++++++++++
> 1 files changed, 149 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/
> Documentation/powerpc/booting-without-of.txt
> index ee551c6..d44980c 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1436,6 +1436,155 @@ platforms are moved over to use the flat
> descriptor-types-mask = <073f1127>;
> };
>
> + h) Freescale SOC communication processor module (CPM)
> + This represents cpm module that is installed on PQ (PowerQUICC)
> + series,1-st, 2-nd and 3-rd generation. Basically, is is a bus of
> devices,
> + both those that are inalienable cpm parts (BRGs, etc.), and those
> that could act
> + more or less as a complete entity (FCC, SCC). All af them should be
> + siblings on the "root" cpm node, using the common properties from
> + there. The description below applies to the CPM2 (2-nd rev. found on
> + PQ2 and PQ3) but I beleive could be extended to the PQ CPM1 as well
> + later.
> +
> + 1) Root cpm2 device
> + Required properties:
> +
> + - device_type : Should be "cpm"
> + - model : Model of the device. Should be "CPM1" or "CPM2"
> + - reg : Offset and length of the register set for the device
> + - command-proc : Offset to the CPM command processor
> +
> + 2) Baud-rate generators (BRG)
> + The CPM contains eight independent, identical baud-rate
> generators (BRGs) that can be
> + used with the FCCs, SCCs, and SMCs. The clocks produced
> by the BRGs are sent to the
> + bank-of-clocks selection logic, where they can be routed
> to the controllers. In addition, the
> + output of a BRG can be routed to a pin to be used
> externally.
> +
> + Required properties:
> +
> + - device_type : Should be "brg"
> + - model : should be "BRGx", x relative to the BRG number (usually
> + from 1 to 8)
> + - reg : Offset to the configuration register (from cpm reg)
> + - linux,phandle : phandle for this node; likely referenced by
> the CPM
> + devices (SCC, FCC, SMC, etc.)
> +
> + Recommended properties:
> +
> + - clock-divider : 12-bit integer (internal counter that is
> decremented at the DIV16 output rate)
> + - div16 : Either <0> or <1> the 1/16 prescalar before reaching
> the clock divider
> + - ext-clock : Either <0> or phandle of the external clock source
> +
> + 3) CPM multiplexor
> + CPM supports special NMSI mode of operation for its devices. In
> short,
> + each serial device could be connected to the set of dedicated
> pins,
> + and this pseudo-device controls such behavior. They are
> different for
> + each device set, and could be recognised using "compatible" field.
> +
> + Required properties:
> +
> + - device_type : Should be "cpmux"
> + - reg : offset to the configuration register
> + - compatible : "fcc", "scc", or "smc"
> +
> + 4) SCCs (Serial Communications Controllers)
> +
> + Required properties:
> +
> + - device_type : "serial" or "network"
> + - model : "SCCx", x is typically a small number depending on the
> + devices amount
> + - compatible : Either "fs_enet" or "cpm_uart"
> + - reg : offset to the register set and its length
> + - reg-pram : offset to the device parameter RAM
> + - clock-setup : should be <CMX_RT CMX_MSK> where CMX_... values
> define
> + multiplexor clock routing and clock mask respectively
> + - interrupts : <a b> where a is the interrupt number and b is a
> + field that represents an encoding of the sense and level
> + information for the interrupt. This should be encoded based on
> + the information in section 2) depending on the type of interrupt
> + controller you have.
> + - interrupt-parent : the phandle for the interrupt controller that
> + services interrupts for this device.
> +
> + 5) FCCs (Fast Communications Controllers)
> +
> + Required properties:
> +
> + - device_type : should be "network"
> + - model : "FCCx", x is typically a small number depending on the
> + devices amount
> + - compatible : should be "fs_enet"
> + - address : List of bytes representing the ethernet address of
> + this controller
> + - reg : offset to the register set and its length
> + - reg-pram : offset to the device parameter RAM
> + - clock-setup : should be <CMX_RT CMX_MSK> where CMX_... values
> define
> + multiplexor clock routing and clock mask respectively
> + - interrupts : <a b> where a is the interrupt number and b is a
> + field that represents an encoding of the sense and level
> + information for the interrupt. This should be encoded based on
> + the information in section 2) depending on the type of interrupt
> + controller you have.
> + - interrupt-parent : the phandle for the interrupt controller that
> + services interrupts for this device.
> + - phy-handle : The phandle for the PHY connected to this ethernet
> + controller.
> + Example:
> + /*8272ADS*/
> + cpm@f0000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #interrupt-cells = <2>;
> + device_type = "cpm";
> + model = "CPM2";
> + ranges = <0 f0000000 00100000>;
> + reg = <f0000000 000101a8>;
> + command-proc = <119c0>
> +
> + brg@119f0 {
> + device_type = "brg";
> + model = "BRG1";
> + reg = <119f0>;
> + linux,phandle = <775>;
> + };
> +
> + cpmux@11b04 {
> + device_type = "cpmux";
> + compatible = "fcc";
> + reg = <11b04>;
> + };
> +
> + cpmux@11b08 {
> + device_type = "cpmux";
> + compatible = "scc";
> + reg = <11b08>;
> + };
> +
> + scc@11a20 {
> + device_type = "serial";
> + compatible = "cpm_uart";
> + model = "SCC1";
> + reg = <11a20 100>;
> + reg_pram = <8000 ff>;
> + clock_setup = <0x00ffffff 0>;
> + interrupts = <28 3>;
> + interrupt-parent = <700>;
> + brg_phandle = <775>;
> + };
> +
> + fcc@11300 {
> + device_type = "network";
> + compatible = "fs_enet";
> + model = "FCC1";
> + reg = <11300 1f>;
> + reg_pram = <8400 ff>;
> + address = [00 00 00 00 00 00];
> + interrupts = <20 3>;
> + interrupt-parent = <700>;
> + phy_handle = <2452000>;
> + };
> + };
>
> More devices will be defined as this spec matures.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* PPC405EP and Abatron BDI help
From: Jeff.Fellin @ 2006-03-28 16:36 UTC (permalink / raw)
To: linuxppc-embedded
I'm not sure if this forum can help me, but perhaps someone has experience
with
using an Abatron BDI2000 to control an AMCC PPC405EP evaluation board. I am
having problems with getting the BDI to access devices on the external bus.
I have verifed the EBC settings are correct by comparing them to the values
set by Uboot 1.1.2 (Jun 2, 2005 Rev B) running on the board.
I have used the base bubinga.cfg , Stefan Roese's configuration file, sent
to me
from someone on this mailing list. I modified the configuration to match
the external
device configuration of the AMCC PPC405EP evaluation board.
Any ideas as to why I cannot access devices on the external bus using the
BDI,
but Uboot can?
Jeff Fellin
RFL Electronics
Jeff.Fellin@rflelect.com
973 334-3100, x 327
^ permalink raw reply
* Re: Memory mapping PCI memory region to user space
From: David Hawkins @ 2006-03-28 16:35 UTC (permalink / raw)
To: Phil.Nitschke; +Cc: linuxppc-embedded
In-Reply-To: <1143528245.24304.28.camel@lamorak.int.avalon.com.au>
Hey Phil,
>
> Much better, thanks. I might be able to use your program/driver as a
> comparison to my own driver, at least as far as the mmap() goes, because
> mine is broken and yours isn't!
>
Great! Good to hear.
Dave
^ permalink raw reply
* Re: 2.6.16 does not boot on powerbook
From: Étienne Bersac @ 2006-03-28 16:31 UTC (permalink / raw)
To: Dustin Lang; +Cc: linuxppc-dev, Michal Purzynski
In-Reply-To: <Pine.LNX.4.60.0603280630130.8520@tin.icics.ubc.ca>
Michal, have you tried arch/powerpc/configs/ defconfigs ?
^ 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