* Re: 2.6.23-rc3 broken on G5
From: Paul Mackerras @ 2007-08-19 2:01 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <jey7g9i3qk.fsf@sykes.suse.de>
Andreas Schwab writes:
> 1.25 GB. It also has an nvidia gfx card, in case it matters.
Could you try this patch and see if it fixes it? It puts the code
back to being a bit closer to what it was before.
Paul.
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index a73d2d7..1cef209 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -226,8 +226,12 @@ void slb_initialize(void)
vflags = SLB_VSID_KERNEL | vmalloc_llp;
/* Invalidate the entire SLB (even slot 0) & all the ERATS */
+ asm volatile("isync":::"memory");
+ asm volatile("slbmte %0,%0"::"r" (0) : "memory");
+ asm volatile("isync; slbia; isync":::"memory");
+
slb_shadow_update(PAGE_OFFSET, lflags, 0);
- asm volatile("isync; slbia; sync; slbmte %0,%1; isync" ::
+ asm volatile("slbmte %0,%1; isync" ::
"r" (get_slb_shadow()->save_area[0].vsid),
"r" (get_slb_shadow()->save_area[0].esid) : "memory");
^ permalink raw reply related
* Re: [PATCH] Consolidate XILINX_VIRTEX board support
From: Josh Boyer @ 2007-08-19 1:57 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <46C79E33.8090600@dlasys.net>
On Sat, 18 Aug 2007 21:34:43 -0400
"David H. Lynch Jr." <dhlii@dlasys.net> wrote:
> arch/boot/simple/embed_config.c jusst seems to be a random collection
> of board specific code anyway.
> A giant case statement implimented with #ifdef's. It is just
> screaming to be done some better way.
You mean like a device tree? ;)
josh
^ permalink raw reply
* Re: [PATCH 1/2] Add scaled time to taskstats based process accounting
From: Balbir Singh @ 2007-08-19 8:56 UTC (permalink / raw)
To: Andrew Morton
Cc: Michael Neuling, Benjamin, Jay Lan, linux-kernel, linuxppc-dev,
Paul Mackerras
In-Reply-To: <20070817115951.e1368a7d.akpm@linux-foundation.org>
Andrew Morton wrote:
>>
>> unsigned int rt_priority;
>> - cputime_t utime, stime;
>> + cputime_t utime, stime, utimescaled, stimescaled;
>
> Adding 8 or 16 bytes to the task_struct for all architectures for something
> which only powerpc uses?
>
> Is there any prospect that other CPUs can use this?
>
Hi, Andrew,
There is definitely the prospect for other architectures to use this
feature
x86 provides the APERF and MPERF model specific registers.
The ratio of APERF to MPERF gives the current scaled load on the
system (acpi-cpufreq, get_measured_perf()) I have been looking at
exploiting this functionality for x-series, but ran into a problem;
as per the specification, APERF and MPERF are to be reset to 0
upon reading them. As a result, I am still figuring out a good
way to share the data amongst the ondemand governor and utimescaled
statistics.
I think for now, we can
1. Put utimescaled and stimescaled under an #ifdef for ARCH_POWERPC
2. Add utimescaled and stimescaled and add a big fat comment stating
that work for other architectures is on it's way.
In either case, I think the functionality is useful and can be
exploited by other architectures. The powerpc port is complete and
I think the implementation would provide a good reference for
other implementations to follow.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: 2.6.23-rc3 broken on G5
From: Andreas Schwab @ 2007-08-19 12:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18119.42120.893384.555002@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Andreas Schwab writes:
>
>> 1.25 GB. It also has an nvidia gfx card, in case it matters.
>
> Could you try this patch and see if it fixes it? It puts the code
> back to being a bit closer to what it was before.
That didn't change anything visibly.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: Sergei Shtylyov @ 2007-08-19 12:59 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <20070807032806.GE15619@localhost.localdomain>
Hello.
I'm having sort of vacation, mostly away from computer, hence my belated
reply...
David Gibson wrote:
>>>>>Can you describe some of the options for *not* direct mapped flash
>>>>>chips - I can't reasonably come up with a way of describing the
>>>>>distinction when I've never seen NOR flash other than direct mapped.
>>>> You're lucky to live in the single-endian world. Once you're in bi-endian
>>>>one, all kinds of strange mappings become possible. I've seen the MIPS
>> Well, not necessarily -- 16-bit only accesses are always possibly (no
>>dount this would be a strange mapping however)...
> I have no idea what you're getting at here.
The code fragment that I've posted before -- it used readw() in read8()
method of the mapping.
>>>>mapping driver which required swapping flash bytes in s/w in BE mode, i.e.
>>>>couldn't be served by physmap, yet that's not all... here's the code of its
>>>>map read*() methods:
>>>Aha! Ok, now I understand the sorts of situations you're talking
>>>about. By "not direct mapped", I thought you were talking about some
>>>kind of access via address/data registers on some indirect bus
>>>controller, rather than weird variations on endianness and
>>>bit-swizzling.
>> No, that would be just too ridiculous for a NOR flash -- I hope. :-)
> Heh. In my experience, very little is so ridiculous that some
> embedded vendor won't do it.
Right. :-)
>>>Hrm.. this is a property of how the flash is wired onto the bus,
>>>rather than of the flash chips themselves,
>> Indeed.
>>>so I'm not entirely sure where description of it belongs.
>> So, you're saying that the 1:1 address correspondence rule stops to apply
>>here?
> Well.. it all depends what exactly you consider the address space of
> the flash bank. By which I mean the whole shmozzle represented by the
> device node, not the individual flash chips. It's not immediately
> obvious whether or not that should include any swizzling done by the
> bus wiring.
> It would be possible, I guess, to define a 'swizzled-ranges' property
> or something which allows child devices to be embedded in the parent's
> address range in a not-direct way. However, the swizzling on the
> flash bank is really a property of the flash bank, not of the parent
> bus - requiring it to be encoded in the parent is pretty yucky -
> especially if the flash bank is just part of a larger chunk of bus
> address space, defined by a single large ranges entry in the parent.
[...]
>>>>>>>+ - reg : Address range of the flash chip
>>>>>>>+ - bank-width : Width (in bytes) of the flash bank. Equal to the device width
>>>>>>>+ times the number of interleaved chips.
>>>>>>>+ - device-width : (optional) Width of a single flash chip. If omitted,
>>>>>>>+ assumed to be equal to 'bank-width'.
>>>>>> Why then not just introduce the "interleave" prop and obsolete the
>>>>>>"bank-width"?
>>>>>Because they're equivalent information, and bank-width is what the
>>>>>code ends up actually caring about. I don't see any reason to prefer
>>>>>giving the interleave.
>>>> Well, "device-width" is not the thing that we care about either. ;-)
>>>Well, yes but we need to encode it somehow. Segher preferred
>>>device-width to interleave, because it's closer to a description of
>>>the actual hardware, rather than an abstration decribing its wiring.
>>>In other words I *still* don't see any reason to prefer giving the
>>>interleave.
Well, for example, enable "Flash chip driver advanced configuration
options" (appers in the "RAM/ROM/Flash chip drivers menu" when you enable CFI
probe, and it has a choice of bus widths 8 to 256 bits (here buswidth == bank
width) and *interleave factors* 1 to 8...
>> I wasn't talking of "interleave" preference over "device-width", I was
>>talking about obsoleting "bank-width" with this pair.
> Whatever. You haven't given any argument to prefer interleave over
> either device-width or bank-width.
Consistency? The bank width is a product of the chip width and interleave
factor. However, I don't insist. The MTD core itself has a different view on
the CFI flash geometry: bank width (which is a property of a mapping driver)
and interleave (which is a property of a chip driver).
>>>>>>>Index: working-2.6/drivers/mtd/maps/physmap_of.c
>>>>>>>===================================================================
>>>>>>>--- working-2.6.orig/drivers/mtd/maps/physmap_of.c 2007-07-30 17:07:11.000000000 +1000
>>>>>>>+++ working-2.6/drivers/mtd/maps/physmap_of.c 2007-07-30 17:07:14.000000000 +1000
>>>>[...]
>>>>>>>@@ -221,6 +297,14 @@ err_out:
>>>>>>>
>>>>>>>static struct of_device_id of_physmap_match[] = {
>>>>>>> {
>>>>>>>+ .compatible = "cfi-flash",
>>>>>>>+ .data = (void *)"cfi_probe",
>>>>>>>+ },
>>>>>>>+ {
>>>>>>>+ .compatible = "jedec-flash",
>>>>>>>+ .data = (void *)"jedec_probe",
>>>>>>>+ },
>>>>>>>+ {
>>>>>> This would also trigger on non-linearly mapped CFI or JEDEC
>>>>>>flashes which is not a good idea -- however, as we're using the MTD
>>>>>>probing code anyway, it will just fail, so it's not luckily is not a
>>>>>>fatal design flaw.
>>>>>Well, if there's nothing else to distinguish them. Which there isn't
>>>>>yet, but will need to be: see above about incomplete - helpful
>>>>>suggestions about how to describe the mapping would be more useful
>>>>>than merely pointing out the lack.
>>>> I was thinking about adding "direct-mapped" prop... but maybe adding
>>>>"ranges" to the parent node (that's "ebc") would indeed ensure that the flash
>>>>is mapped 1:1 to the EBC's parent bus also.
>>>The ebc already has a ranges property. But that can't describe the
>> Not in the device tree that started that thread -- I haven't seen another.
> Ah sorry. The ranges property isn't in the dts, it's added by the
> bootwrapper based on the EBC register contents.
Cool. :-)
>>>sorts of bit-swizzling you're talking about.
>> Let's hear what Segher says (if he's not yet tired of all this :-).
>>>>>>>Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
>>>>>>>===================================================================
>>>>>>>--- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts 2007-07-30 17:07:14.000000000 +1000
>>>>>>>+++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2007-07-30 17:07:14.000000000 +1000
>>>>>>[...]
>>>>>>>@@ -158,14 +161,20 @@
>>>>>>> };
>>>>>>> large-flash@2,0 {
>>>>>> Hmm... what does @2,0 mean? :-O
>>>>>EBC chip select 2, offset 0.
>>>> Well, so this node is under some kind of local bus node -- that's good.
>>>>Didn't know that the spec allows commas after @...
>>>Well, now you do. I believe USB usually uses that format, too.
>> USB what, hosts or devices?
> Devices.
And what the comma-separated numbers mean there?
[...]
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/2] Add scaled time to taskstats based process accounting
From: Michael Neuling @ 2007-08-19 13:12 UTC (permalink / raw)
To: balbir
Cc: Benjamin, Jay Lan, linux-kernel, linuxppc-dev, Paul Mackerras,
Andrew Morton
In-Reply-To: <46C805B0.1000300@linux.vnet.ibm.com>
In message <46C805B0.1000300@linux.vnet.ibm.com> you wrote:
> Andrew Morton wrote:
> >>
> >> unsigned int rt_priority;
> >> - cputime_t utime, stime;
> >> + cputime_t utime, stime, utimescaled, stimescaled;
> >
> > Adding 8 or 16 bytes to the task_struct for all architectures for something
> > which only powerpc uses?
> >
> > Is there any prospect that other CPUs can use this?
> >
>
> Hi, Andrew,
>
> There is definitely the prospect for other architectures to use this
> feature
>
> x86 provides the APERF and MPERF model specific registers.
> The ratio of APERF to MPERF gives the current scaled load on the
> system (acpi-cpufreq, get_measured_perf()) I have been looking at
> exploiting this functionality for x-series, but ran into a problem;
> as per the specification, APERF and MPERF are to be reset to 0
> upon reading them. As a result, I am still figuring out a good
> way to share the data amongst the ondemand governor and utimescaled
> statistics.
>
> I think for now, we can
>
> 1. Put utimescaled and stimescaled under an #ifdef for ARCH_POWERPC
... or even #ifdef TASKSTATS
> 2. Add utimescaled and stimescaled and add a big fat comment stating
> that work for other architectures is on it's way.
>
> In either case, I think the functionality is useful and can be
> exploited by other architectures. The powerpc port is complete and
> I think the implementation would provide a good reference for
> other implementations to follow.
>
> --
> Warm Regards,
> Balbir Singh
> Linux Technology Center
> IBM, ISTL
>
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Matt Sealey @ 2007-08-19 15:39 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-embedded
In-Reply-To: <20070818100643.GA31233@nd47.coderock.org>
Domen,
Do it in a Forth script, or in nvramrc (after probe-all). Don't clutter
Linux with more fixups. The Efika PHY isn't going to change to something
else and it's a bog standard no-frills MII PHY anyway.
I think it is a distinction that the OF docs forgot to make, that the
client interface is *all those Forth words* and not just the 6 or 7
distinct, special callable functions like claim (they exist because of
the simple fact that claiming memory shouldn't involve claiming memory
and such other paradoxes) and call-method. Call-method is a perfectly
valid way of doing things.
But, I'd really recommend you please think of a different way.. if you
want to spec out a device tree entry for it I'll update my script which
I am probably going to stick as an 'official' Genesi support file in
the next week.
If you insist on using prom_init and fixups, yaboot has the best
examples of call-method and interpret, both readable and fairly
easily available.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Domen Puncer wrote:
> Hi!
>
> On 10/08/07 11:51 +0200, Domen Puncer wrote:
>> Index: work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
>> ===================================================================
>> --- work-powerpc.git.orig/arch/powerpc/boot/dts/lite5200b.dts
>> +++ work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
>> + mdio@3000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + device_type = "mdio";
>> + compatible = "mpc5200b-fec-phy";
>> + reg = <3000 400>; // fec range, since we need to setup fec interrupts
>> + interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
>> + interrupt-parent = <&mpc5200_pic>;
>> +
>> + phy0:ethernet-phy@0 {
>> + device_type = "ethernet-phy";
>> + reg = <0>;
>> + };
>> };
>
> I am struggling with this part on Efika.
> I would like to add this to the device tree from
> fixup_device_tree_efika() (arch/powerpc/kernel/prom_init.c).
>
> AFAICS client-services doesn't offer anything like new-device,
> so I guess "interpret" or "call-method" will have to be used.
>
> I have read some docs, but I'm still wandering in the dark.
> Can I please get an example?
> Pretty please with a cherry on top?
>
>
> Domen
^ permalink raw reply
* LINKSTATION default config update for linux-2.6.23-rc3
From: Jonathan Li @ 2007-08-19 18:11 UTC (permalink / raw)
To: linuxppc-dev; +Cc: g.liakhovetski
Hello,
Please update the default config in linux-2.6.23 for the LINKSTATION
board with the following changes:
SK98LIN SysKonnect driver is deprecated. Use SKGE instead.
Regards,
Jon
^ permalink raw reply
* Re: LINKSTATION default config update for linux-2.6.23-rc3
From: Segher Boessenkool @ 2007-08-19 19:18 UTC (permalink / raw)
To: Jonathan Li; +Cc: linuxppc-dev, g.liakhovetski
In-Reply-To: <9050bda20708191111n497e1565h87eb9a2423a6ba56@mail.gmail.com>
> Please update the default config in linux-2.6.23 for the LINKSTATION
> board with the following changes:
>
> SK98LIN SysKonnect driver is deprecated. Use SKGE instead.
/me confused...
None of SK98LIN, SKGE, SKY2 are in the linkstation_defconfig --
not unsurprisingly, since the hardware doesn't contain any such
chip.
Segher
^ permalink raw reply
* Re: [PATCH 6/7 v2] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
From: Scott Wood @ 2007-08-20 1:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <55FCD650-548C-40C9-8B1E-16259EF93F1D@kernel.crashing.org>
On Sat, Aug 18, 2007 at 11:36:24AM -0500, Kumar Gala wrote:
> This patch seems to mix moving to using the device tree directly w/o
> some other modifications. Can it be broken into those two changes as
> they'd be easier to review.
The last iteration of these patches, I got complaints that I was
splitting them up too fine-grained. I don't think it's productive to
keep iterating on exactly how much is in any given patch until I hit the
right combination of granularity and whoever happens to be reading e-mail
when I submit.
In the case of this particular patch, most of what isn't directly related
to converting to using the device tree directly is fixing problems that I
encountered in doing so -- what value is there in coming up with
intermediary versions that kind-of-sort-of make sense, on a good day, if
you don't look to closely? The existing codebase is crap, and if every
logical change were its own patch, the patchset would be ten times as
long, and take ten times as long to produce. Note that I did separate
what I thought were the more relevant-to-review and/or highly indpendent
changes.
The major thing I see in this patch that could have been usefully
separated out was the conversion of mii_bitbang.c to use the generic code
introduced by patch 1. However, that would require retrieving and
retesting the intermediate version, and I don't think there's sufficient
damage to reviewability (apart perhaps from diff's stupidity in thinking
that a single "{" is relevant common ground between completely unrelated
chunks of code) relative to the cost in preparing such a split.
Is there anything of the actual content of the patch that you object to,
or have a question about?
-Scott
^ permalink raw reply
* Re: Please pull from 'for-2.6.24' branch
From: Paul Mackerras @ 2007-08-20 4:45 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070817084623.3e9835d0@weaponx.rchland.ibm.com>
Josh Boyer writes:
> Josh Boyer (10):
> Rename 4xx paths to 40x
> 4xx Kconfig cleanup
> Rename 44x bootwrapper
> 4xx bootwrapper reworks
> 40x MMU
> 40x decrementer fixes
> Fix 40x build
> Bamboo DTS
> Bamboo board support
> Bamboo zImage wrapper
Could you re-do these with [POWERPC] at the start of the summary line?
Thanks,
Paul.
^ permalink raw reply
* [PATCH] [POWERPC] iSeries: clean up lparmap mess
From: Stephen Rothwell @ 2007-08-20 4:58 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
We need to have xLparMap in ead_64.S so that it is at a fixed address
(because the linker will not resolve (address & 0xffffffff) for us).
But the assembler miscalculates the KERNEL_VSID() expressions. So put
the confusing expressions into asm-offset.c.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/Makefile | 7 -------
arch/powerpc/kernel/asm-offsets.c | 8 ++++++++
arch/powerpc/kernel/head_64.S | 27 +++++++++++++++++++--------
arch/powerpc/kernel/lparmap.c | 32 --------------------------------
include/asm-powerpc/iseries/lpar_map.h | 3 +++
include/asm-powerpc/page_64.h | 2 +-
6 files changed, 31 insertions(+), 48 deletions(-)
delete mode 100644 arch/powerpc/kernel/lparmap.c
This has been built and booted for iseries_defconfig and ppc64_defconfig
and built for allmodconfig. Tony Breeds cross built
arch/powerpc/kernel/head_64.s on i386 for me and we verified the
constants all had the correct values.
Segher: this was plan C :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index b0cb2e6..5987912 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -80,13 +80,6 @@ ifneq ($(CONFIG_PPC_INDIRECT_IO),y)
obj-y += iomap.o
endif
-ifeq ($(CONFIG_PPC_ISERIES),y)
-CFLAGS_lparmap.s += -g0
-extra-y += lparmap.s
-$(obj)/head_64.o: $(obj)/lparmap.s
-AFLAGS_head_64.o += -I$(obj)
-endif
-
else
# stuff used from here for ARCH=ppc
smpobj-$(CONFIG_SMP) += smp.o
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index 2cb1d94..a408053 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -312,5 +312,13 @@ int main(void)
#ifdef CONFIG_BUG
DEFINE(BUG_ENTRY_SIZE, sizeof(struct bug_entry));
#endif
+
+#ifdef CONFIG_PPC_ISERIES
+ /* the assembler miscalculates the VSID values */
+ DEFINE(PAGE_OFFSET_ESID, GET_ESID(PAGE_OFFSET));
+ DEFINE(PAGE_OFFSET_VSID, KERNEL_VSID(PAGE_OFFSET));
+ DEFINE(VMALLOC_START_ESID, GET_ESID(VMALLOC_START));
+ DEFINE(VMALLOC_START_VSID, KERNEL_VSID(VMALLOC_START));
+#endif
return 0;
}
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 1718000..1e6d9cc 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -34,6 +34,7 @@
#include <asm/iseries/lpar_map.h>
#include <asm/thread_info.h>
#include <asm/firmware.h>
+#include <asm/page_64.h>
#define DO_SOFT_DISABLE
@@ -1519,8 +1520,8 @@ _GLOBAL(do_stab_bolted)
* Space for CPU0's segment table.
*
* On iSeries, the hypervisor must fill in at least one entry before
- * we get control (with relocate on). The address is give to the hv
- * as a page number (see xLparMap in lpardata.c), so this must be at a
+ * we get control (with relocate on). The address is given to the hv
+ * as a page number (see xLparMap below), so this must be at a
* fixed address (the linker can't compute (u64)&initial_stab >>
* PAGE_SHIFT).
*/
@@ -1542,12 +1543,22 @@ fwnmi_data_area:
* both pSeries and iSeries */
#ifdef CONFIG_PPC_ISERIES
. = LPARMAP_PHYS
-#include "lparmap.s"
-/*
- * This ".text" is here for old compilers that generate a trailing
- * .note section when compiling .c files to .s
- */
- .text
+ .globl xLparMap
+xLparMap:
+ .quad HvEsidsToMap /* xNumberEsids */
+ .quad HvRangesToMap /* xNumberRanges */
+ .quad STAB0_PAGE /* xSegmentTableOffs */
+ .zero 40 /* xRsvd */
+ /* xEsids (HvEsidsToMap entries of 2 quads) */
+ .quad PAGE_OFFSET_ESID /* xKernelEsid */
+ .quad PAGE_OFFSET_VSID /* xKernelVsid */
+ .quad VMALLOC_START_ESID /* xKernelEsid */
+ .quad VMALLOC_START_VSID /* xKernelVsid */
+ /* xRanges (HvRangesToMap entries of 3 quads) */
+ .quad HvPagesToMap /* xPages */
+ .quad 0 /* xOffset */
+ .quad PAGE_OFFSET_VSID << (SID_SHIFT - HW_PAGE_SHIFT) /* xVPN */
+
#endif /* CONFIG_PPC_ISERIES */
. = 0x8000
diff --git a/arch/powerpc/kernel/lparmap.c b/arch/powerpc/kernel/lparmap.c
deleted file mode 100644
index af11285..0000000
--- a/arch/powerpc/kernel/lparmap.c
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * Copyright (C) 2005 Stephen Rothwell IBM Corp.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-#include <asm/mmu.h>
-#include <asm/pgtable.h>
-#include <asm/iseries/lpar_map.h>
-
-/* The # is to stop gcc trying to make .text nonexecutable */
-const struct LparMap __attribute__((__section__(".text #"))) xLparMap = {
- .xNumberEsids = HvEsidsToMap,
- .xNumberRanges = HvRangesToMap,
- .xSegmentTableOffs = STAB0_PAGE,
-
- .xEsids = {
- { .xKernelEsid = GET_ESID(PAGE_OFFSET),
- .xKernelVsid = KERNEL_VSID(PAGE_OFFSET), },
- { .xKernelEsid = GET_ESID(VMALLOC_START),
- .xKernelVsid = KERNEL_VSID(VMALLOC_START), },
- },
-
- .xRanges = {
- { .xPages = HvPagesToMap,
- .xOffset = 0,
- .xVPN = KERNEL_VSID(PAGE_OFFSET) << (SID_SHIFT - HW_PAGE_SHIFT),
- },
- },
-};
diff --git a/include/asm-powerpc/iseries/lpar_map.h b/include/asm-powerpc/iseries/lpar_map.h
index 2ec384d..5e9f3e1 100644
--- a/include/asm-powerpc/iseries/lpar_map.h
+++ b/include/asm-powerpc/iseries/lpar_map.h
@@ -22,6 +22,8 @@
#include <asm/types.h>
+#endif
+
/*
* The iSeries hypervisor will set up mapping for one or more
* ESID/VSID pairs (in SLB/segment registers) and will set up
@@ -56,6 +58,7 @@
/* Hypervisor initially maps 32MB of the load area */
#define HvPagesToMap 8192
+#ifndef __ASSEMBLY__
struct LparMap {
u64 xNumberEsids; // Number of ESID/VSID pairs
u64 xNumberRanges; // Number of VA ranges to map
diff --git a/include/asm-powerpc/page_64.h b/include/asm-powerpc/page_64.h
index 4ceb113..56a2df0 100644
--- a/include/asm-powerpc/page_64.h
+++ b/include/asm-powerpc/page_64.h
@@ -28,7 +28,7 @@
/* Segment size */
#define SID_SHIFT 28
-#define SID_MASK 0xfffffffffUL
+#define SID_MASK ASM_CONST(0xfffffffff)
#define ESID_MASK 0xfffffffff0000000UL
#define GET_ESID(x) (((x) >> SID_SHIFT) & SID_MASK)
--
1.5.2.4
^ permalink raw reply related
* Please pull Kumar's fixes-2.6.23 branch
From: Paul Mackerras @ 2007-08-20 5:27 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git fixes-2.6.23
to get four commits from Kumar that fix some bugs in the platform
support for Freescale PowerPC platforms.
One of the commits looks rather large, but that is because rather than
fix the same bugs in two places, Kumar moved a chunk of almost
identical code for two platforms into a single file that is used for
both platforms, and fixed the bugs in one place. Also, the affected
files are only used on some Freescale embedded platforms, so the
number of users that could be affected by this is small.
Thanks,
Paul.
arch/powerpc/boot/dts/mpc8544ds.dts | 88 ++++------
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 114 +++----------
arch/powerpc/kernel/traps.c | 4
arch/powerpc/platforms/85xx/Kconfig | 1
arch/powerpc/platforms/85xx/mpc8544_ds.c | 214 ++---------------------
arch/powerpc/platforms/86xx/Kconfig | 1
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 224 ++-----------------------
arch/powerpc/platforms/Kconfig | 8 +
arch/powerpc/platforms/Makefile | 3
arch/powerpc/platforms/fsl_uli1575.c | 255 ++++++++++++++++++++++++++++
arch/powerpc/sysdev/fsl_soc.c | 1
arch/powerpc/sysdev/rtc_cmos_setup.c | 17 +-
include/asm-powerpc/reg_booke.h | 12 +
13 files changed, 389 insertions(+), 553 deletions(-)
create mode 100644 arch/powerpc/platforms/fsl_uli1575.c
commit 0af666fa6cf4bc639fb6170600b5fb0d8b6504b9
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Fri Aug 17 08:23:06 2007 -0500
[POWERPC] Fix 8xx compile failure
CC arch/powerpc/sysdev/commproc.o
arch/powerpc/sysdev/fsl_soc.c: In function fsl_pcmcia_of_init:
arch/powerpc/sysdev/fsl_soc.c:1109: error: implicit declaration of function of_platform_device_create
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 86d7a9a9c4775f864e6bc5f5da66ef9ea3715734
Author: Becky Bruce <becky.bruce@freescale.com>
Date: Thu Aug 2 15:37:15 2007 -0500
[POWERPC] Fix FSL BookE machine check reporting
Reserved MCSR bits on FSL BookE parts may have spurious values
when mcheck occurs. Mask these off when printing the MCSR to
avoid confusion. Also, get rid of the MCSR_GL_CI bit defined
for e500 - this bit doesn't actually have any meaning.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit b66510cb9992d204f216049e9c01d432c7635f6c
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Thu Aug 16 23:55:55 2007 -0500
[POWERPC] Fix interrupt routing and setup of ULI M1575 on FSL boards
The interrupt routing in the device trees for the ULI M1575 was
inproperly using the interrupt line field as pci function. Fixed
up the device tree's to actual conform for to specification and
changed the interrupt mapping code so it just uses a static mapping
setup as follows:
PIRQA - IRQ9
PIRQB - IRQ10
PIRQC - IRQ11
PIRQD - IRQ12
USB 1.1 OCHI (1c.0) - IRQ12
USB 1.1 OCHI (1c.1) - IRQ9
USB 1.1 OCHI (1c.2) - IRQ10
USB 1.1 ECHI (1c.3) - IRQ11
LAN (1b.0) - IRQ6
AC97 (1d.0) - IRQ6
Modem (1d.1) - IRQ6
HD Audio (1d.2) - IRQ6
SATA (1f.1) - IRQ5
SMB (1e.1) - IRQ7
PMU (1e.2) - IRQ7
PATA (1f.0) - IRQ14/15
Took the oppurtunity to refactor the code into a single file so we
don't have to duplicate these fixes on the two current boards in the
tree and several forth coming boards that will also need the code.
Fixed RTC support that requires a dummy memory read on the P2P bridge
to unlock the RTC and setup the default of the RTC alarm registers to
match with a basic x86 style CMOS RTC.
Moved code that poked ISA registers to a FIXUP_FINAL quirk to ensure
the PCI IO space has been setup properly before we start poking ISA
registers at random locations.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit ada3ea6fcde45abc55e2af0e564455fd7f943a79
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Thu Aug 16 23:44:00 2007 -0500
[POWERPC] Add interrupt resource for RTC CMOS driver
The RTC CMOS driver expects the interrupt to be a resource of the platform
device. Use a fixed interrupt value of 8 since on PPC if we are using this
its off an i8259 which we ensure has interrupt numbers 0..15.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
^ permalink raw reply
* Re: [PATCH 3/3 v2][POWERPC] Stop include asm-ppc when building ARCH=powerpc for ppc32
From: Paul Mackerras @ 2007-08-20 5:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0708181210390.31362@blarg.am.freescale.net>
Kumar Gala writes:
> We no longer have any dependancies on include/asm-ppc so we can get ride
> of the makefile hacks to include it in the build process.
On 32-bit powermac, I get:
CC [M] drivers/macintosh/ans-lcd.o
/home/paulus/kernel/powerpc/drivers/macintosh/ans-lcd.c:17:25: error: asm/ans-lcd.h: No such file or directory
plus a whole pile of things undefined after that.
Paul.
^ permalink raw reply
* some error about nfs
From: 李明 @ 2007-08-20 5:55 UTC (permalink / raw)
To: linux-arch; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 984 bytes --]
hello,everyone
when I open nfs on my linux server, and set the bootargs in the uboot, there is some error like this:
IP-Config: Device `off' not found.
ip_tables: (C) 2000-2002 Netfilter core team
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Ethernet Bridge 008 for NET4.0
lec.c: Aug 20 2007 13:01:25 initialized
Looking up port of RPC 100003/2 on 192.168.2.172
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 192.168.2.172
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get mountd port number from server, using default
RPC: sendmsg returned error 101
mount: RPC call returned error 101
Root-NFS: Server returned error -101 while mounting /home/lim/Ramdisk
what is wrong, and what should I do ?
--------------
李 明
MSN:lim.live@msn.com
务实奋斗，不断挑战
2007-08-20
[-- Attachment #2: man_016.gif --]
[-- Type: image/gif, Size: 1729 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3 v2][POWERPC] Stop include asm-ppc when building ARCH=powerpc for ppc32
From: Paul Mackerras @ 2007-08-20 5:57 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev
In-Reply-To: <18121.11392.459659.535657@cargo.ozlabs.ibm.com>
I wrote:
> On 32-bit powermac, I get:
>
> CC [M] drivers/macintosh/ans-lcd.o
> /home/paulus/kernel/powerpc/drivers/macintosh/ans-lcd.c:17:25: error: asm/ans-lcd.h: No such file or directory
>
> plus a whole pile of things undefined after that.
And on mpc7448_hpc2 I get
CC arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.o
In file included from /home/paulus/kernel/powerpc/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c:43:
/home/paulus/kernel/powerpc/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.h:19:25: error: asm/ppcboot.h: No such file or directory
Paul.
^ permalink raw reply
* Re: [PATCH 0/3 v2] Remove need for include/asm-ppc
From: David Gibson @ 2007-08-20 6:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0708181203320.31362@blarg.am.freescale.net>
On Sat, Aug 18, 2007 at 12:05:36PM -0500, Kumar Gala wrote:
> This patch series removes the need for include/asm-ppc in the ARCH=powerpc
> build for ppc32. They exist in the following git tree:
>
> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.24
>
> posting here for everyone else to see.
>
> Updated with changes suggested by Arnd & Segher. (removal 82xx pci header
> and moving some headers under platforms if not globally needed).
Nice! I'm hoping the next step after this is to do the other way
around - make ARCH=ppc builds independent of things in arch/powerpc or
include/asm-powerpc, which is almost the more important change.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Domen Puncer @ 2007-08-20 8:31 UTC (permalink / raw)
To: Matt Sealey; +Cc: Domen Puncer, linuxppc-embedded
In-Reply-To: <46C8643B.7010104@genesi-usa.com>
On 19/08/07 16:39 +0100, Matt Sealey wrote:
> Domen,
>
> Do it in a Forth script, or in nvramrc (after probe-all). Don't clutter
> Linux with more fixups. The Efika PHY isn't going to change to something
> else and it's a bog standard no-frills MII PHY anyway.
Fine with me, but I'm worried people won't update nvramrc.
Currently I have this:
--- start ---
s" /builtin" find-device
new-device
1 encode-int s" #address-cells" property
0 encode-int s" #size-cells" property
s" mdio" 2dup device-name device-type
s" mpc5200b-fec-phy" s" compatible" property
0xf0003000 0x400 reg
0x2 encode-int
0x5 encode-int
0x3 encode-int
encode+ encode+
s" interupts" property
new-device
s" ethernet-phy@0" device-name
s" ethernet-phy" device-type
0 encode-int s" reg" property
my-self \ save our phandle to stack
ihandle>phandle
finish-device
finish-device
s" /builtin/ethernet" find-device
encode-int \ phy's phandle
s" phy-handle" property
device-end
--- end ---
But I have a problem with it, possibly due to my not-knowledge of Forth.
Compatible keep getting set to:
compatible "/builtin/etherne"
<spin>
> If you insist on using prom_init and fixups, yaboot has the best
> examples of call-method and interpret, both readable and fairly
> easily available.
Thanks.
Domen
> > On 10/08/07 11:51 +0200, Domen Puncer wrote:
> >> Index: work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
> >> ===================================================================
> >> --- work-powerpc.git.orig/arch/powerpc/boot/dts/lite5200b.dts
> >> +++ work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
> >> + mdio@3000 {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + device_type = "mdio";
> >> + compatible = "mpc5200b-fec-phy";
> >> + reg = <3000 400>; // fec range, since we need to setup fec interrupts
> >> + interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
> >> + interrupt-parent = <&mpc5200_pic>;
> >> +
> >> + phy0:ethernet-phy@0 {
> >> + device_type = "ethernet-phy";
> >> + reg = <0>;
> >> + };
> >> };
> >
> > I am struggling with this part on Efika.
> > I would like to add this to the device tree from
> > fixup_device_tree_efika() (arch/powerpc/kernel/prom_init.c).
> >
> > AFAICS client-services doesn't offer anything like new-device,
> > so I guess "interpret" or "call-method" will have to be used.
> >
> > I have read some docs, but I'm still wandering in the dark.
> > Can I please get an example?
> > Pretty please with a cherry on top?
> >
> >
> > Domen
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Driver for device behind a PCI-VME bridge
From: Konstantin Boyanov @ 2007-08-20 8:40 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]
Hi list,
I'm currently reading the LDD 3rd Edition and trying to create a device
driver for a custom device located on VME bus. I have already linux
2.6.15running on the master board, as well as the device driver for
the PCI-VME
bridge. The main problem I have is understanding how to "attach" my driver
for the custom device to the bridge device driver.
The bridge device driver is implemented as a class, i.e. doesn't define a
new bus type. Should I define a new class for my driver, or should I connect
it somehow to the existing one (maybe by something as "subclass")?
All I want to do is to redirect I/O reads and writes to the VME bus, but I
got no clue as to how to use the existing VME bridge driver for this
purpose. After I get through this I think all other things (VME interrupt
registration & handling, etc.) will be straightforward.
The LDD 3rd book states that defining a new bus type is the last thing one
would like to do, instead defining a class is far better approach. Why is
that?
Any recommendations and sharing of practical experience are highly
appreciated.
Best Regards,
Konstantin
[-- Attachment #2: Type: text/html, Size: 1200 bytes --]
^ permalink raw reply
* Re: Driver for device behind a PCI-VME bridge
From: Johan Borkhuis @ 2007-08-20 8:45 UTC (permalink / raw)
To: Konstantin Boyanov; +Cc: linuxppc-embedded
In-Reply-To: <929bf310708200140w6efc57f6k81a1339845059e2d@mail.gmail.com>
Hello Konstantin,
Konstantin Boyanov wrote:
> Hi list,
>
> I'm currently reading the LDD 3rd Edition and trying to create a
> device driver for a custom device located on VME bus. I have already
> linux 2.6.15 running on the master board, as well as the device driver
> for the PCI-VME bridge. The main problem I have is understanding how
> to "attach" my driver for the custom device to the bridge device driver.
> The bridge device driver is implemented as a class, i.e. doesn't
> define a new bus type. Should I define a new class for my driver, or
> should I connect it somehow to the existing one (maybe by something as
> "subclass")?
> All I want to do is to redirect I/O reads and writes to the VME bus,
> but I got no clue as to how to use the existing VME bridge driver for
> this purpose. After I get through this I think all other things (VME
> interrupt registration & handling, etc.) will be straightforward.
> The LDD 3rd book states that defining a new bus type is the last thing
> one would like to do, instead defining a class is far better approach.
> Why is that?
>
> Any recommendations and sharing of practical experience are highly
> appreciated.
I am also working on a VME-board. What I did was use mmap to map
specific parts of the VME-memory into user space.
BTW: what kind of board and Linux-flavor are you using?
Kind regards,
Johan Borkhuis
^ permalink raw reply
* Re: Driver for device behind a PCI-VME bridge
From: Konstantin Boyanov @ 2007-08-20 8:58 UTC (permalink / raw)
To: Johan Borkhuis; +Cc: linuxppc-embedded
In-Reply-To: <46C954AA.7050609@dutchspace.nl>
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
Hi Johan,
I already went through the user space stuff with the help of other people on
this list, but now I want to do reads and writes in kernel space, in other
words on driver level.
Main reason for the development of a driver for the device is interrupt
handling and signal sending to user space processes by the custom device in
short time frames (within miliseconds), e.g. proper and fast respond is
crutial. But for now I don't know how to do a simple read/write...
I'm using MVME6100 with ELinOS-based distro, kernel 2.6.15.
Regards,
Konstantin
[-- Attachment #2: Type: text/html, Size: 592 bytes --]
^ permalink raw reply
* problem in configuring PC13 for Ext interrupt
From: Misbah khan @ 2007-08-20 11:21 UTC (permalink / raw)
To: linuxppc-embedded
Hi
I myself is working on PPC 8272, There i am facing a serious problem . The
problem is this :-
I have configured PC13 for an external Interrupt In the Init of the driver.
The configuration is OK, but when ever i press a key from the key board i
use to get an an interrupt from PC13 (The handler is being called )
regardless of whether the interrupt is comming or not.
Please send me ur suggessions for this unpredictible issue.
regard
Misbah
--
View this message in context: http://www.nabble.com/problem-in-configuring-PC13-for-Ext-interrupt-tf4298263.html#a12234154
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: signals handling in the kernel
From: Mirek23 @ 2007-08-20 11:49 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46B8BA93.8020909@ovro.caltech.edu>
Thank you for you suggestions. Sorry for the dealy but I was on holidays.
I understand that select() is more appropriate solution to handle
interrupts.
In my case I found somehow more convenient to deal with signals. The server
program which I use was originally written for VxWorks. In VxWorks there was
no separation betwenn the user and kernel space. When the interrupt occured
in VxWorks the interrupt service routine was called. The interrupt service
routine was implemented in the server.
I found it somehow easier to use signals to trigger signal handler
(previously in VxWorks interrupt service routine) than changing the
structure of the server to deal with select().
I hope however that there is no fundamental problem with sending signals
from kernel (interrupt service routine) to the user space.
I do not know why the function kill_proc_info does not export its symbol
within the kernel 2.6.21 .
With previous version of the kernel 2.4 and early 2.6.* the kill_proc_info
symbol was exported.
Best Regards
Mirek
David Hawkins-3 wrote:
>
>
> Hi Mirek,
>
>>> I would like to send signals from the interrupt handler
>>> routine (in the kernel) to the user application (in user space).
>>> I have googled on that net and I have found that it could be done with
>>> the
>>> function: kill_proc_info.
>>
>> Look in Rubini for the section regarding asynchronous
>> notification, Ch 6.
>>
>> The callback to generate SIGIO is fasync.
>>
>
> Actually, before you go off and implement something, can
> you describe why you want to use signals.
>
> I mistakenly used signals once to indicate notification of
> an event. Then when I wanted multiple events from multiple
> boards I found the problem with signals; you don't know
> who sent it.
>
> Using select() on multiple file descriptors ended up being
> a more appropriate solution for my application. That
> solution also works nicely with the ACE C++ ACE_Reactor
> pattern.
>
> Cheers,
> Dave
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/signals-handling-in-the-kernel-tf4229566.html#a12234438
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Please pull from 'for-2.6.24' branch
From: Josh Boyer @ 2007-08-20 12:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18121.7269.300478.589492@cargo.ozlabs.ibm.com>
On Mon, 20 Aug 2007 14:45:25 +1000
Paul Mackerras <paulus@samba.org> wrote:
> Josh Boyer writes:
>
> > Josh Boyer (10):
> > Rename 4xx paths to 40x
> > 4xx Kconfig cleanup
> > Rename 44x bootwrapper
> > 4xx bootwrapper reworks
> > 40x MMU
> > 40x decrementer fixes
> > Fix 40x build
> > Bamboo DTS
> > Bamboo board support
> > Bamboo zImage wrapper
>
> Could you re-do these with [POWERPC] at the start of the summary line?
Yes, done. Git tree is updated:
Josh Boyer (10):
[POWERPC] Rename 4xx paths to 40x
[POWERPC] 4xx Kconfig cleanup
[POWERPC] Rename 44x bootwrapper
[POWERPC] 4xx bootwrapper reworks
[POWERPC] 40x MMU
[POWERPC] 40x decrementer fixes
[POWERPC] Fix 40x build
[POWERPC] Bamboo DTS
[POWERPC] Bamboo board support
[POWERPC] Bamboo zImage wrapper
josh
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Domen Puncer @ 2007-08-20 13:13 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-embedded
In-Reply-To: <20070820083137.GJ13994@moe.telargo.com>
[-- Attachment #1: Type: text/plain, Size: 647 bytes --]
On 20/08/07 10:31 +0200, Domen Puncer wrote:
> On 19/08/07 16:39 +0100, Matt Sealey wrote:
> > Domen,
> >
> > Do it in a Forth script, or in nvramrc (after probe-all). Don't clutter
> > Linux with more fixups. The Efika PHY isn't going to change to something
> > else and it's a bog standard no-frills MII PHY anyway.
>
> Fine with me, but I'm worried people won't update nvramrc.
>
...
> But I have a problem with it, possibly due to my not-knowledge of Forth.
> Compatible keep getting set to:
> compatible "/builtin/etherne"
I missed the encode-string.
Matt, can you please add attached Forth script to Efika updates.
Domen
[-- Attachment #2: smart_firmware_phy --]
[-- Type: text/plain, Size: 613 bytes --]
s" /builtin" find-device
new-device
1 encode-int s" #address-cells" property
0 encode-int s" #size-cells" property
s" mdio" 2dup device-name device-type
s" mpc5200b-fec-phy" encode-string s" compatible" property
0xf0003000 0x400 reg
0x2 encode-int
0x5 encode-int
0x3 encode-int
encode+ encode+
s" interrupts" property
new-device
s" ethernet-phy" 2dup device-name device-type
0x10 encode-int s" reg" property
my-self \ save our phandle to stack
ihandle>phandle
finish-device
finish-device
s" /builtin/ethernet" find-device
encode-int \ phy's phandle
s" phy-handle" property
device-end
^ 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