* Re: [patch 0/6] pasemi_mac updates for 2.6.26
From: Olof Johansson @ 2008-02-26 14:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: netdev, pasemi-linux, jgarzik, linuxppc-dev
In-Reply-To: <18371.57542.77446.443231@cargo.ozlabs.ibm.com>
On Tue, Feb 26, 2008 at 08:49:58PM +1100, Paul Mackerras wrote:
> Olof Johansson writes:
>
> > Here's a set of updates for pasemi_mac for 2.6.26. Some of them touch
> > the dma_lib in the platform code as well, but it's easier if it's all
> > merged through netdev to avoid dependencies.
> >
> > Major highlights are jumbo frame support and ethtool basics, the rest
> > is mostly minor plumbing around it.
>
> What route do you think these should take upstream? I'm happy to take
> them if Jeff is OK with that.
I've sent them through Jeff in the past, that's been convenient when
there's been churn in the network APIs. I'm not sure if there's much of
that for .26 though.
If Jeff prefers to ACK, I'll just add it to my git and ask you to pull
that. But I was originally planning to just feed it through him.
(Note: I'll repost the patch set later today or tomorrow with a couple
of tweaks).
-Olof
^ permalink raw reply
* Re: [patch 1/6] pasemi_mac: Move RX/TX section enablement to dma_lib
From: Olof Johansson @ 2008-02-26 14:14 UTC (permalink / raw)
To: Michael Ellerman; +Cc: netdev, pasemi-linux, jgarzik, linuxppc-dev
In-Reply-To: <1204026366.7203.9.camel@concordia>
Hi,
On Tue, Feb 26, 2008 at 10:46:06PM +1100, Michael Ellerman wrote:
> On Wed, 2008-02-20 at 20:57 -0600, Olof Johansson wrote:
> > + i = 1000;
> > + pasemi_write_dma_reg(PAS_DMA_COM_RXCMD, 0);
> > + while ((i > 0) && (pasemi_read_dma_reg(PAS_DMA_COM_RXSTA) & 1))
> > + i--;
> > + if (i < 0)
> > + printk(KERN_INFO "Warning: Could not disable RX section\n");
> > +
> > + i = 1000;
> > + pasemi_write_dma_reg(PAS_DMA_COM_TXCMD, 0);
> > + while ((i > 0) && (pasemi_read_dma_reg(PAS_DMA_COM_TXSTA) & 1))
> > + i--;
>
> This kind of caught my eye, is it still going to work when the next core
> is twice as fast?
Actually, I added the variable right before posting, I used to have an
infinite loop there while testing the patch. I've never seen it do more
than a few rounds, so I'm not that worried.
We already have a similar loop in the channel shutdown code, but it runs
a bit longer. I might bring that over instead. Thanks for pointing it
out.
-Olof
^ permalink raw reply
* Re: [RFC][PATCH] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround
From: Valentine Barshak @ 2008-02-26 12:25 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080222144919.3ded7c54@weaponx>
Josh Boyer wrote:
> On Fri, 22 Feb 2008 22:28:17 +0300
> Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
>> This patch adds ibm_newemac phy clock workaround for 440EP/440GR emacs.
>> The code is based on the previous ibm_emac driver stuff. The 440EP/440GR
>> allows controlling each EMAC clock spearately as opposed to global clock
>> selection for 440GX.
>>
>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>> ---
>
> [snip]
>
>> +/* EMAC PHY clock workaround:
>> + * 440EP/440GR has more sane SDR0_MFR register implementation than 440GX,
>> + * which allows controlling each EMAC clock
>> + */
>> +static inline void emac_rx_clk_tx(struct emac_instance *dev)
>> +{
>> + if (emac_has_feature(dev, EMAC_FTR_440EP_PHY_CLK_FIX)) {
>> + unsigned long flags;
>> +
>> + local_irq_save(flags);
>> + mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR) |
>> + (SDR0_MFR_ECS >> dev->cell_index));
>> + local_irq_restore(flags);
>> + }
>> +}
>> +
>> +static inline void emac_rx_clk_default(struct emac_instance *dev)
>> +{
>> + if (emac_has_feature(dev, EMAC_FTR_440EP_PHY_CLK_FIX)) {
>> + unsigned long flags;
>> +
>> + local_irq_save(flags);
>> + mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR) &
>> + ~(SDR0_MFR_ECS >> dev->cell_index));
>> + local_irq_restore(flags);
>> + }
>> +}
>
> Why did you do local_irq_save in these two functions? mtdcri already
> does spin_lock_irqsave...
>
> josh
Oops, this got copy-pasted from the older ibm_emac.
Thanks,
Valentine.
^ permalink raw reply
* Patches added to master & powerpc-next branches of powerpc.git
From: Paul Mackerras @ 2008-02-26 12:03 UTC (permalink / raw)
To: linuxppc-dev
I have created a powerpc-next branch in the powerpc.git tree, which
has the following commits on it so far. The master branch is at the
same point. I've pulled in Dave Miller's tree (for the LMB changes)
and applied some other patches from the list.
I'm expecting that platform/subarchitecture maintainers will be
sending me pull requests for their trees from time to time.
Paul.
Anton Vorontsov (1):
[POWERPC] 8xx: Timebase frequency should not depend on bus-frequency
Badari Pulavarty (1):
[POWERPC] Add code for removing HPTEs for parts of the linear mapping
Becky Bruce (1):
[LMB]: Make lmb support large physical addressing
Benjamin Herrenschmidt (1):
[POWERPC] Fix thinko in cpu_thread_mask_to_cores()
Dale Farnsworth (1):
[POWERPC] Remove dead code at KernelAltiVec
David S. Miller (2):
[LIB]: Make PowerPC LMB code generic so sparc64 can use it too.
[LMB]: Fix bug in __lmb_alloc_base().
Johannes Berg (1):
[POWERPC] mpic: Make sparse happy
Julia Lawall (1):
[POWERPC] Use FIELD_SIZEOF in arch/ppc
Kumar Gala (2):
[LMB]: Fix initial lmb add region with a non-zero base
[LMB]: Fix lmb_add_region if region should be added at the head
^ permalink raw reply
* Re: [patch 1/6] pasemi_mac: Move RX/TX section enablement to dma_lib
From: Michael Ellerman @ 2008-02-26 11:46 UTC (permalink / raw)
To: Olof Johansson; +Cc: netdev, pasemi-linux, jgarzik, linuxppc-dev
In-Reply-To: <20080221025929.082348000@lixom.net>
[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]
On Wed, 2008-02-20 at 20:57 -0600, Olof Johansson wrote:
> plain text document attachment (in-progress)
> Also stop both rx and tx sections before changing the configuration of
> the dma device during init.
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
>
> Index: k.org/arch/powerpc/platforms/pasemi/dma_lib.c
> ===================================================================
> --- k.org.orig/arch/powerpc/platforms/pasemi/dma_lib.c
> +++ k.org/arch/powerpc/platforms/pasemi/dma_lib.c
> @@ -478,6 +478,30 @@ int pasemi_dma_init(void)
> for (i = 0; i < MAX_RXCH; i++)
> __set_bit(i, rxch_free);
>
> + i = 1000;
> + pasemi_write_dma_reg(PAS_DMA_COM_RXCMD, 0);
> + while ((i > 0) && (pasemi_read_dma_reg(PAS_DMA_COM_RXSTA) & 1))
> + i--;
> + if (i < 0)
> + printk(KERN_INFO "Warning: Could not disable RX section\n");
> +
> + i = 1000;
> + pasemi_write_dma_reg(PAS_DMA_COM_TXCMD, 0);
> + while ((i > 0) && (pasemi_read_dma_reg(PAS_DMA_COM_TXSTA) & 1))
> + i--;
This kind of caught my eye, is it still going to work when the next core
is twice as fast?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: MPC8540 : What's "SPE used in kernel" ?
From: Philippe De Muyter @ 2008-02-26 10:34 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <8B0E09C7-BA68-4994-9AB6-36F400F65832@kernel.crashing.org>
Hi Kumar,
On Tue, Feb 26, 2008 at 01:39:20AM -0600, Kumar Gala wrote:
>
> On Feb 23, 2008, at 4:25 AM, Johannes Berg wrote:
>
>>
>>> But as I said in the same mail, processes still dies unexpectedly.
>>
>> Yeah, no idea though. I guess you could try putting that into the
>> arch/ppc Makefile, but arch/ppc will be removed this year so you don't
>> want to rely on it.
>
> Its been removed (or will be for 2.6.25).
>
> What compiler version are you using?
a gcc-4.2.1 derivative from codesourcery (4.2-50) that I needed to compile
eglibc for e500 and that I tweaked to use it with CLFS and that I compiled
with --host=powerpc-linuxspe. I now noticed that it still generates
spe insn's even when given '-mno-spe'.
I am now busy to retest with a vanilla powerpc-linuxspe-gcc-4.2.2 and
that seems to work fine. I don't think, though, that it is able to compile
eglibc for e500.
Thanks for the attention, and sorry for the noise.
Philippe
^ permalink raw reply
* Re: [PATCH] Fix for Freescale ppc cores: major revision detection
From: Paul Mackerras @ 2008-02-26 10:32 UTC (permalink / raw)
To: Martin Langer; +Cc: linuxppc-dev
In-Reply-To: <20080211202933.GA3399@tuba>
Martin Langer writes:
> Thanks for the hint. Inspired by that I did the logic the other way
> round. So we have the same default cases as we had before and
> additionally it will fit for the cores mentioned in the doc.
Care to resend this with a proper description and a Signed-off-by
line?
> + switch (PVR_VER(pvr)) {
> + case 0x8000: /* 7441/7450/7451, Vger */
> + case 0x8001: /* 7445/7455, Apollo 6 */
> + case 0x8002: /* 7447/7457, Apollo 7 */
> + case 0x8003: /* 7447A, Apollo 7 PM */
> + case 0x8004: /* 7448, Apollo 8 */
> + case 0x800c: /* 7410, Nitro */
BTW, these case labels are all indented one tab too far.
Paul.
^ permalink raw reply
* Re: [patch 0/6] pasemi_mac updates for 2.6.26
From: Paul Mackerras @ 2008-02-26 9:49 UTC (permalink / raw)
To: Olof Johansson; +Cc: netdev, pasemi-linux, jgarzik, linuxppc-dev
In-Reply-To: <20080221025753.903665000@lixom.net>
Olof Johansson writes:
> Here's a set of updates for pasemi_mac for 2.6.26. Some of them touch
> the dma_lib in the platform code as well, but it's easier if it's all
> merged through netdev to avoid dependencies.
>
> Major highlights are jumbo frame support and ethtool basics, the rest
> is mostly minor plumbing around it.
What route do you think these should take upstream? I'm happy to take
them if Jeff is OK with that.
Paul.
^ permalink raw reply
* Re: [PATCH][OF] Add of_device_is_available function
From: Paul Mackerras @ 2008-02-26 9:04 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, sfr, davem
In-Reply-To: <20080223202357.20a12b84@zod.rchland.ibm.com>
Josh Boyer writes:
> + status = of_get_property(device, "status", NULL);
> + if (status == NULL)
> + return 1;
> +
> + if (!strcmp(status, "okay") || !strcmp(status, "ok"))
It would probably be good to defend against the possibility that the
property isn't null-terminated (for example if its length is zero).
Paul.
^ permalink raw reply
* Re: MPC8540 : What's "SPE used in kernel" ?
From: Kumar Gala @ 2008-02-26 7:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, Philippe De Muyter
In-Reply-To: <1203762305.13162.17.camel@johannes.berg>
On Feb 23, 2008, at 4:25 AM, Johannes Berg wrote:
>
>> But as I said in the same mail, processes still dies unexpectedly.
>
> Yeah, no idea though. I guess you could try putting that into the
> arch/ppc Makefile, but arch/ppc will be removed this year so you don't
> want to rely on it.
Its been removed (or will be for 2.6.25).
What compiler version are you using?
- k
^ permalink raw reply
* dtc: Fix error reporting in push_input_file()
From: David Gibson @ 2008-02-26 5:44 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Error reporting in push_input_file() is a mess. One error results in
a message and exit(1), others result in a message and return 0 - which
is turned into an exit(1) at one callsite. The other callsite doesn't
check errors, but probably should. One of the error conditions gives
a message, but can only be the result of an internal programming
error, not a user error.
So. Clean that up by making push_input_file() a void function, using
die() to report errors and quit.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
dtc-lexer.l | 28 ++++++++--------------------
srcpos.h | 2 +-
2 files changed, 9 insertions(+), 21 deletions(-)
Index: dtc/dtc-lexer.l
===================================================================
--- dtc.orig/dtc-lexer.l 2008-02-26 15:35:38.000000000 +1100
+++ dtc/dtc-lexer.l 2008-02-26 16:38:31.000000000 +1100
@@ -59,10 +59,7 @@ static int dts_version; /* = 0 */
<INCLUDE>\"[^"\n]*\" {
yytext[strlen(yytext) - 1] = 0;
- if (!push_input_file(yytext + 1)) {
- /* Some unrecoverable error.*/
- exit(1);
- }
+ push_input_file(yytext + 1);
yy_pop_state();
}
@@ -243,21 +240,16 @@ struct incl_file *incl_file_stack;
static int incl_depth = 0;
-int push_input_file(const char *filename)
+void push_input_file(const char *filename)
{
struct incl_file *incl_file;
struct dtc_file *newfile;
struct search_path search, *searchptr = NULL;
- if (!filename) {
- yyerror("No include file name given.");
- return 0;
- }
+ assert(filename);
- if (incl_depth++ >= MAX_INCLUDE_DEPTH) {
- yyerror("Includes nested too deeply");
- return 0;
- }
+ if (incl_depth++ >= MAX_INCLUDE_DEPTH)
+ die("Includes nested too deeply");
if (srcpos_file) {
search.dir = srcpos_file->dir;
@@ -267,11 +259,9 @@ int push_input_file(const char *filename
}
newfile = dtc_open_file(filename, searchptr);
- if (!newfile) {
- yyerrorf("Couldn't open \"%s\": %s",
- filename, strerror(errno));
- exit(1);
- }
+ if (!newfile)
+ die("Couldn't open \"%s\": %s", filename, strerror(errno));
+
incl_file = xmalloc(sizeof(struct incl_file));
@@ -292,8 +282,6 @@ int push_input_file(const char *filename
yylineno = 1;
yyin = newfile->file;
yy_switch_to_buffer(yy_create_buffer(yyin, YY_BUF_SIZE));
-
- return 1;
}
Index: dtc/srcpos.h
===================================================================
--- dtc.orig/srcpos.h 2008-02-26 15:38:55.000000000 +1100
+++ dtc/srcpos.h 2008-02-26 15:39:11.000000000 +1100
@@ -75,7 +75,7 @@ extern void yyerrorf(char const *, ...)
extern struct dtc_file *srcpos_file;
-extern int push_input_file(const char *filename);
+extern void push_input_file(const char *filename);
extern int pop_input_file(void);
struct search_path {
--
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: copy_from_user problem
From: Paul Mackerras @ 2008-02-26 5:29 UTC (permalink / raw)
To: maynardj; +Cc: linuxppc-dev
In-Reply-To: <47C36FBA.1030600@us.ibm.com>
Maynard Johnson writes:
> I'm developing a kernel module that needs to parse the in-memory ELF
> objects for a shared library (libc, to be specific). When running my
> test on a 32-bit library, it works fine, but for a 64-bit library, the
> very first copy_from_user() fails:
> Elf64_Ehdr ehdr;
> copy_from_user(&ehdr, location_of_lib, sizeof(Elf64_Ehdr);
Should be OK provided location_of_lib is a user address. I assume you
know that copy_from_user returns the number of bytes *not* copied,
hence a 0 return means success.
> I talked this over a bit with Will Schmidt. He determined that
> access_ok (being done as a result of copy_from_user) was failing, but we
I suggest you print out the value of location_of_lib just to
sanity-check it.
Paul.
^ permalink raw reply
* Re: Start removing linux,network-index in favour of aliases
From: David Gibson @ 2008-02-26 3:09 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <47C380B2.7060505@pikatech.com>
On Mon, Feb 25, 2008 at 10:00:02PM -0500, Sean MacLennan wrote:
> David Gibson wrote:
[snip]
> > Subsumes my earlier Ebony-only patch. Tested on Ebony, could do with
> > testing on Taishan, Bamboo, Sequoia, Warp, Rainier and Walnut.
[snip]
> >
> Worked for me on the warp.
That's good to know, but in future *please* trim your quotes to what's
relevant when replying...
--
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: Start removing linux,network-index in favour of aliases
From: Sean MacLennan @ 2008-02-26 3:00 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080226004320.GB24382@localhost.localdomain>
David Gibson wrote:
> This patch alters the bootwrapper for a number of machines (roubhly
> all 4xx based cuboot or treeboot platforms) to use aliases instead of
> the linux,network-index hack to work out which MAC address to attach
> to which ethernet device node.
>
> The now obsolete linux,network-index properties are removed from the
> corresponding device trees. This won't break backwards compatiblity,
> because in cases where this fixup code is relevant, the device tree is
> part of the kernel image.
>
> The references to linux,network-index are removed from
> booting-without-of.txt. Not only is it now deprecated, but as a hack
> applicable only when the device tree blob and fixup code were in the
> same image, this property never belonged in booting-without-of.txt
> which describes the interface between the kernel and firmware or
> bootloaders which produce a device tree. By the time the device tree
> reaches the kernel, all the MAC addresses must be fully filled in.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> ---
>
> Subsumes my earlier Ebony-only patch. Tested on Ebony, could do with
> testing on Taishan, Bamboo, Sequoia, Warp, Rainier and Walnut.
>
> Index: working-2.6/arch/powerpc/boot/ebony.c
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/ebony.c 2008-02-26 11:30:30.000000000 +1100
> +++ working-2.6/arch/powerpc/boot/ebony.c 2008-02-26 11:34:26.000000000 +1100
> @@ -75,7 +75,8 @@ static void ebony_fixups(void)
>
> ibm440gp_fixup_clocks(sysclk, 6 * 1843200);
> ibm4xx_sdram_fixup_memsize();
> - dt_fixup_mac_addresses(ebony_mac0, ebony_mac1);
> + dt_fixup_mac_address_by_alias("ethernet0", ebony_mac0);
> + dt_fixup_mac_address_by_alias("ethernet1", ebony_mac1);
> ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
> ebony_flashsel_fixup();
> }
> Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts 2008-02-26 11:30:30.000000000 +1100
> +++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2008-02-26 11:34:26.000000000 +1100
> @@ -243,7 +243,6 @@
> };
>
> EMAC0: ethernet@40000800 {
> - linux,network-index = <0>;
> device_type = "network";
> compatible = "ibm,emac-440gp", "ibm,emac";
> interrupt-parent = <&UIC1>;
> @@ -263,7 +262,6 @@
> zmii-channel = <0>;
> };
> EMAC1: ethernet@40000900 {
> - linux,network-index = <1>;
> device_type = "network";
> compatible = "ibm,emac-440gp", "ibm,emac";
> interrupt-parent = <&UIC1>;
> Index: working-2.6/arch/powerpc/boot/cuboot-taishan.c
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/cuboot-taishan.c 2008-02-26 11:30:30.000000000 +1100
> +++ working-2.6/arch/powerpc/boot/cuboot-taishan.c 2008-02-26 11:34:26.000000000 +1100
> @@ -38,7 +38,8 @@ static void taishan_fixups(void)
>
> ibm4xx_sdram_fixup_memsize();
>
> - dt_fixup_mac_addresses(bd.bi_enetaddr, bd.bi_enet1addr);
> + dt_fixup_mac_address_by_alias("ethernet0", bd.bi_enetaddr);
> + dt_fixup_mac_address_by_alias("ethernet1", bd.bi_enet1addr);
>
> ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
> }
> Index: working-2.6/arch/powerpc/boot/dts/taishan.dts
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/dts/taishan.dts 2008-02-26 11:30:30.000000000 +1100
> +++ working-2.6/arch/powerpc/boot/dts/taishan.dts 2008-02-26 11:34:26.000000000 +1100
> @@ -239,7 +239,6 @@
>
> EMAC0: ethernet@40000800 {
> unused = <1>;
> - linux,network-index = <2>;
> device_type = "network";
> compatible = "ibm,emac-440gx", "ibm,emac4";
> interrupt-parent = <&UIC1>;
> @@ -260,7 +259,6 @@
> };
> EMAC1: ethernet@40000900 {
> unused = <1>;
> - linux,network-index = <3>;
> device_type = "network";
> compatible = "ibm,emac-440gx", "ibm,emac4";
> interrupt-parent = <&UIC1>;
> @@ -281,7 +279,6 @@
> };
>
> EMAC2: ethernet@40000c00 {
> - linux,network-index = <0>;
> device_type = "network";
> compatible = "ibm,emac-440gx", "ibm,emac4";
> interrupt-parent = <&UIC2>;
> @@ -304,7 +301,6 @@
> };
>
> EMAC3: ethernet@40000e00 {
> - linux,network-index = <1>;
> device_type = "network";
> compatible = "ibm,emac-440gx", "ibm,emac4";
> interrupt-parent = <&UIC2>;
> Index: working-2.6/arch/powerpc/boot/bamboo.c
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/bamboo.c 2008-02-26 11:30:30.000000000 +1100
> +++ working-2.6/arch/powerpc/boot/bamboo.c 2008-02-26 11:34:26.000000000 +1100
> @@ -33,7 +33,8 @@ static void bamboo_fixups(void)
> ibm440ep_fixup_clocks(sysclk, 11059200, 25000000);
> ibm4xx_sdram_fixup_memsize();
> ibm4xx_quiesce_eth((u32 *)0xef600e00, (u32 *)0xef600f00);
> - dt_fixup_mac_addresses(bamboo_mac0, bamboo_mac1);
> + dt_fixup_mac_address_by_alias("ethernet0", bamboo_mac0);
> + dt_fixup_mac_address_by_alias("ethernet1", bamboo_mac1);
> }
>
> void bamboo_init(void *mac0, void *mac1)
> Index: working-2.6/arch/powerpc/boot/cuboot-sequoia.c
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/cuboot-sequoia.c 2008-02-26 11:30:30.000000000 +1100
> +++ working-2.6/arch/powerpc/boot/cuboot-sequoia.c 2008-02-26 11:34:26.000000000 +1100
> @@ -42,7 +42,8 @@ static void sequoia_fixups(void)
> ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
> ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
> ibm4xx_denali_fixup_memsize();
> - dt_fixup_mac_addresses(&bd.bi_enetaddr, &bd.bi_enet1addr);
> + dt_fixup_mac_address_by_alias("ethernet0", bd.bi_enetaddr);
> + dt_fixup_mac_address_by_alias("ethernet1", bd.bi_enet1addr);
> }
>
> void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
> Index: working-2.6/arch/powerpc/boot/cuboot-warp.c
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/cuboot-warp.c 2008-02-26 11:30:30.000000000 +1100
> +++ working-2.6/arch/powerpc/boot/cuboot-warp.c 2008-02-26 11:34:26.000000000 +1100
> @@ -23,7 +23,7 @@ static void warp_fixups(void)
> ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
> ibm4xx_sdram_fixup_memsize();
> ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
> - dt_fixup_mac_addresses(&bd.bi_enetaddr);
> + dt_fixup_mac_address_by_alias("ethernet0", bd.bi_enetaddr);
> }
>
>
> Index: working-2.6/arch/powerpc/boot/dts/bamboo.dts
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/dts/bamboo.dts 2008-02-26 11:30:30.000000000 +1100
> +++ working-2.6/arch/powerpc/boot/dts/bamboo.dts 2008-02-26 11:34:26.000000000 +1100
> @@ -207,7 +207,6 @@
> };
>
> EMAC0: ethernet@ef600e00 {
> - linux,network-index = <0>;
> device_type = "network";
> compatible = "ibm,emac-440ep", "ibm,emac-440gp", "ibm,emac";
> interrupt-parent = <&UIC1>;
> @@ -228,7 +227,6 @@
> };
>
> EMAC1: ethernet@ef600f00 {
> - linux,network-index = <1>;
> device_type = "network";
> compatible = "ibm,emac-440ep", "ibm,emac-440gp", "ibm,emac";
> interrupt-parent = <&UIC1>;
> Index: working-2.6/arch/powerpc/boot/dts/warp.dts
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/dts/warp.dts 2008-02-26 11:30:30.000000000 +1100
> +++ working-2.6/arch/powerpc/boot/dts/warp.dts 2008-02-26 11:34:26.000000000 +1100
> @@ -204,7 +204,6 @@
> };
>
> EMAC0: ethernet@ef600e00 {
> - linux,network-index = <0>;
> device_type = "network";
> compatible = "ibm,emac-440ep", "ibm,emac-440gp", "ibm,emac";
> interrupt-parent = <&UIC1>;
> Index: working-2.6/arch/powerpc/boot/dts/sequoia.dts
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/dts/sequoia.dts 2008-02-26 11:30:30.000000000 +1100
> +++ working-2.6/arch/powerpc/boot/dts/sequoia.dts 2008-02-26 11:34:26.000000000 +1100
> @@ -273,7 +273,6 @@
> };
>
> EMAC0: ethernet@ef600e00 {
> - linux,network-index = <0>;
> device_type = "network";
> compatible = "ibm,emac-440epx", "ibm,emac4";
> interrupt-parent = <&EMAC0>;
> @@ -303,7 +302,6 @@
> };
>
> EMAC1: ethernet@ef600f00 {
> - linux,network-index = <1>;
> device_type = "network";
> compatible = "ibm,emac-440epx", "ibm,emac4";
> interrupt-parent = <&EMAC1>;
> Index: working-2.6/arch/powerpc/boot/cuboot-rainier.c
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/cuboot-rainier.c 2008-02-26 11:30:30.000000000 +1100
> +++ working-2.6/arch/powerpc/boot/cuboot-rainier.c 2008-02-26 11:34:26.000000000 +1100
> @@ -42,7 +42,8 @@ static void rainier_fixups(void)
> ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
> ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
> ibm4xx_denali_fixup_memsize();
> - dt_fixup_mac_addresses(&bd.bi_enetaddr, &bd.bi_enet1addr);
> + dt_fixup_mac_address_by_alias("ethernet0", bd.bi_enetaddr);
> + dt_fixup_mac_address_by_alias("ethernet1", bd.bi_enet1addr);
> }
>
> void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
> Index: working-2.6/arch/powerpc/boot/dts/rainier.dts
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/dts/rainier.dts 2008-02-26 11:30:30.000000000 +1100
> +++ working-2.6/arch/powerpc/boot/dts/rainier.dts 2008-02-26 11:34:26.000000000 +1100
> @@ -258,7 +258,6 @@
> };
>
> EMAC0: ethernet@ef600e00 {
> - linux,network-index = <0>;
> device_type = "network";
> compatible = "ibm,emac-440grx", "ibm,emac-440epx", "ibm,emac4";
> interrupt-parent = <&EMAC0>;
> @@ -288,7 +287,6 @@
> };
>
> EMAC1: ethernet@ef600f00 {
> - linux,network-index = <1>;
> device_type = "network";
> compatible = "ibm,emac-440grx", "ibm,emac-440epx", "ibm,emac4";
> interrupt-parent = <&EMAC1>;
> Index: working-2.6/arch/powerpc/boot/dts/walnut.dts
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/dts/walnut.dts 2008-02-26 11:30:30.000000000 +1100
> +++ working-2.6/arch/powerpc/boot/dts/walnut.dts 2008-02-26 11:34:26.000000000 +1100
> @@ -125,7 +125,6 @@
> };
>
> EMAC: ethernet@ef600800 {
> - linux,network-index = <0>;
> device_type = "network";
> compatible = "ibm,emac-405gp", "ibm,emac";
> interrupt-parent = <&UIC0>;
> Index: working-2.6/arch/powerpc/boot/treeboot-walnut.c
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/treeboot-walnut.c 2008-02-26 11:30:30.000000000 +1100
> +++ working-2.6/arch/powerpc/boot/treeboot-walnut.c 2008-02-26 11:34:26.000000000 +1100
> @@ -68,7 +68,7 @@ static void walnut_fixups(void)
> ibm4xx_quiesce_eth((u32 *)0xef600800, NULL);
> ibm4xx_fixup_ebc_ranges("/plb/ebc");
> walnut_flashsel_fixup();
> - dt_fixup_mac_addresses((u8 *) WALNUT_OPENBIOS_MAC_OFF);
> + dt_fixup_mac_address_by_alias("ethernet0", (u8 *) WALNUT_OPENBIOS_MAC_OFF);
> }
>
> void platform_init(void)
> Index: working-2.6/Documentation/powerpc/booting-without-of.txt
> ===================================================================
> --- working-2.6.orig/Documentation/powerpc/booting-without-of.txt 2008-02-26 11:30:30.000000000 +1100
> +++ working-2.6/Documentation/powerpc/booting-without-of.txt 2008-02-26 11:34:26.000000000 +1100
> @@ -1269,10 +1269,6 @@ platforms are moved over to use the flat
>
> Recommended properties:
>
> - - linux,network-index : This is the intended "index" of this
> - network device. This is used by the bootwrapper to interpret
> - MAC addresses passed by the firmware when no information other
> - than indices is available to associate an address with a device.
> - phy-connection-type : a string naming the controller/PHY interface type,
> i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "sgmii",
> "tbi", or "rtbi". This property is only really needed if the connection
> @@ -1667,10 +1663,6 @@ platforms are moved over to use the flat
> - phy-handle : The phandle for the PHY connected to this controller.
>
> Recommended properties:
> - - linux,network-index : This is the intended "index" of this
> - network device. This is used by the bootwrapper to interpret
> - MAC addresses passed by the firmware when no information other
> - than indices is available to associate an address with a device.
> - phy-connection-type : a string naming the controller/PHY interface type,
> i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id" (Internal
> Delay), "rgmii-txid" (delay on TX only), "rgmii-rxid" (delay on RX only),
> @@ -1995,7 +1987,6 @@ platforms are moved over to use the flat
> interrupts = <20 8>;
> interrupt-parent = <&PIC>;
> phy-handle = <&PHY0>;
> - linux,network-index = <0>;
> fsl,cpm-command = <12000300>;
> };
>
> @@ -2217,12 +2208,6 @@ platforms are moved over to use the flat
> EMAC, that is the content of the current (bogus) "phy-port"
> property.
>
> - Recommended properties:
> - - linux,network-index : This is the intended "index" of this
> - network device. This is used by the bootwrapper to interpret
> - MAC addresses passed by the firmware when no information other
> - than indices is available to associate an address with a device.
> -
> Optional properties:
> - phy-address : 1 cell, optional, MDIO address of the PHY. If absent,
> a search is performed.
> @@ -2246,7 +2231,6 @@ platforms are moved over to use the flat
> Example:
>
> EMAC0: ethernet@40000800 {
> - linux,network-index = <0>;
> device_type = "network";
> compatible = "ibm,emac-440gp", "ibm,emac";
> interrupt-parent = <&UIC1>;
>
>
Worked for me on the warp.
Cheers,
Sean
^ permalink raw reply
* Re: copy_from_user problem
From: Benjamin Herrenschmidt @ 2008-02-26 2:56 UTC (permalink / raw)
To: maynardj; +Cc: linuxppc-dev
In-Reply-To: <47C36FBA.1030600@us.ibm.com>
On Mon, 2008-02-25 at 19:47 -0600, Maynard Johnson wrote:
> Hi,
> I'm developing a kernel module that needs to parse the in-memory ELF
> objects for a shared library (libc, to be specific). When running my
> test on a 32-bit library, it works fine, but for a 64-bit library, the
> very first copy_from_user() fails:
> Elf64_Ehdr ehdr;
> copy_from_user(&ehdr, location_of_lib, sizeof(Elf64_Ehdr);
>
> I talked this over a bit with Will Schmidt. He determined that
> access_ok (being done as a result of copy_from_user) was failing, but we
> don't know why. I have 32-bit and 64-bit testcases that start up and
> then pause, waiting for input. We look at the entry for libc in
> /proc/<pid>/maps, and the permissions are the same for both 32-bit and
> 64-bit.
>
> I've run this test on both a stock SLES 10 SP1 kernel and on 2.6.24.
> I'm sure this is a user error, but for the life of me, I don't know what
> I'm doing wrong.
>
> Can anyone out there help?
I would have to look at the code.
Ben.
^ permalink raw reply
* copy_from_user problem
From: Maynard Johnson @ 2008-02-26 1:47 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm developing a kernel module that needs to parse the in-memory ELF
objects for a shared library (libc, to be specific). When running my
test on a 32-bit library, it works fine, but for a 64-bit library, the
very first copy_from_user() fails:
Elf64_Ehdr ehdr;
copy_from_user(&ehdr, location_of_lib, sizeof(Elf64_Ehdr);
I talked this over a bit with Will Schmidt. He determined that
access_ok (being done as a result of copy_from_user) was failing, but we
don't know why. I have 32-bit and 64-bit testcases that start up and
then pause, waiting for input. We look at the entry for libc in
/proc/<pid>/maps, and the permissions are the same for both 32-bit and
64-bit.
I've run this test on both a stock SLES 10 SP1 kernel and on 2.6.24.
I'm sure this is a user error, but for the life of me, I don't know what
I'm doing wrong.
Can anyone out there help?
Thanks.
Maynard Johnson
LTC POWER Toolchain
^ permalink raw reply
* Start removing linux,network-index in favour of aliases
From: David Gibson @ 2008-02-26 0:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
This patch alters the bootwrapper for a number of machines (roubhly
all 4xx based cuboot or treeboot platforms) to use aliases instead of
the linux,network-index hack to work out which MAC address to attach
to which ethernet device node.
The now obsolete linux,network-index properties are removed from the
corresponding device trees. This won't break backwards compatiblity,
because in cases where this fixup code is relevant, the device tree is
part of the kernel image.
The references to linux,network-index are removed from
booting-without-of.txt. Not only is it now deprecated, but as a hack
applicable only when the device tree blob and fixup code were in the
same image, this property never belonged in booting-without-of.txt
which describes the interface between the kernel and firmware or
bootloaders which produce a device tree. By the time the device tree
reaches the kernel, all the MAC addresses must be fully filled in.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Subsumes my earlier Ebony-only patch. Tested on Ebony, could do with
testing on Taishan, Bamboo, Sequoia, Warp, Rainier and Walnut.
Index: working-2.6/arch/powerpc/boot/ebony.c
===================================================================
--- working-2.6.orig/arch/powerpc/boot/ebony.c 2008-02-26 11:30:30.000000000 +1100
+++ working-2.6/arch/powerpc/boot/ebony.c 2008-02-26 11:34:26.000000000 +1100
@@ -75,7 +75,8 @@ static void ebony_fixups(void)
ibm440gp_fixup_clocks(sysclk, 6 * 1843200);
ibm4xx_sdram_fixup_memsize();
- dt_fixup_mac_addresses(ebony_mac0, ebony_mac1);
+ dt_fixup_mac_address_by_alias("ethernet0", ebony_mac0);
+ dt_fixup_mac_address_by_alias("ethernet1", ebony_mac1);
ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
ebony_flashsel_fixup();
}
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================
--- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts 2008-02-26 11:30:30.000000000 +1100
+++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2008-02-26 11:34:26.000000000 +1100
@@ -243,7 +243,6 @@
};
EMAC0: ethernet@40000800 {
- linux,network-index = <0>;
device_type = "network";
compatible = "ibm,emac-440gp", "ibm,emac";
interrupt-parent = <&UIC1>;
@@ -263,7 +262,6 @@
zmii-channel = <0>;
};
EMAC1: ethernet@40000900 {
- linux,network-index = <1>;
device_type = "network";
compatible = "ibm,emac-440gp", "ibm,emac";
interrupt-parent = <&UIC1>;
Index: working-2.6/arch/powerpc/boot/cuboot-taishan.c
===================================================================
--- working-2.6.orig/arch/powerpc/boot/cuboot-taishan.c 2008-02-26 11:30:30.000000000 +1100
+++ working-2.6/arch/powerpc/boot/cuboot-taishan.c 2008-02-26 11:34:26.000000000 +1100
@@ -38,7 +38,8 @@ static void taishan_fixups(void)
ibm4xx_sdram_fixup_memsize();
- dt_fixup_mac_addresses(bd.bi_enetaddr, bd.bi_enet1addr);
+ dt_fixup_mac_address_by_alias("ethernet0", bd.bi_enetaddr);
+ dt_fixup_mac_address_by_alias("ethernet1", bd.bi_enet1addr);
ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
}
Index: working-2.6/arch/powerpc/boot/dts/taishan.dts
===================================================================
--- working-2.6.orig/arch/powerpc/boot/dts/taishan.dts 2008-02-26 11:30:30.000000000 +1100
+++ working-2.6/arch/powerpc/boot/dts/taishan.dts 2008-02-26 11:34:26.000000000 +1100
@@ -239,7 +239,6 @@
EMAC0: ethernet@40000800 {
unused = <1>;
- linux,network-index = <2>;
device_type = "network";
compatible = "ibm,emac-440gx", "ibm,emac4";
interrupt-parent = <&UIC1>;
@@ -260,7 +259,6 @@
};
EMAC1: ethernet@40000900 {
unused = <1>;
- linux,network-index = <3>;
device_type = "network";
compatible = "ibm,emac-440gx", "ibm,emac4";
interrupt-parent = <&UIC1>;
@@ -281,7 +279,6 @@
};
EMAC2: ethernet@40000c00 {
- linux,network-index = <0>;
device_type = "network";
compatible = "ibm,emac-440gx", "ibm,emac4";
interrupt-parent = <&UIC2>;
@@ -304,7 +301,6 @@
};
EMAC3: ethernet@40000e00 {
- linux,network-index = <1>;
device_type = "network";
compatible = "ibm,emac-440gx", "ibm,emac4";
interrupt-parent = <&UIC2>;
Index: working-2.6/arch/powerpc/boot/bamboo.c
===================================================================
--- working-2.6.orig/arch/powerpc/boot/bamboo.c 2008-02-26 11:30:30.000000000 +1100
+++ working-2.6/arch/powerpc/boot/bamboo.c 2008-02-26 11:34:26.000000000 +1100
@@ -33,7 +33,8 @@ static void bamboo_fixups(void)
ibm440ep_fixup_clocks(sysclk, 11059200, 25000000);
ibm4xx_sdram_fixup_memsize();
ibm4xx_quiesce_eth((u32 *)0xef600e00, (u32 *)0xef600f00);
- dt_fixup_mac_addresses(bamboo_mac0, bamboo_mac1);
+ dt_fixup_mac_address_by_alias("ethernet0", bamboo_mac0);
+ dt_fixup_mac_address_by_alias("ethernet1", bamboo_mac1);
}
void bamboo_init(void *mac0, void *mac1)
Index: working-2.6/arch/powerpc/boot/cuboot-sequoia.c
===================================================================
--- working-2.6.orig/arch/powerpc/boot/cuboot-sequoia.c 2008-02-26 11:30:30.000000000 +1100
+++ working-2.6/arch/powerpc/boot/cuboot-sequoia.c 2008-02-26 11:34:26.000000000 +1100
@@ -42,7 +42,8 @@ static void sequoia_fixups(void)
ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
ibm4xx_denali_fixup_memsize();
- dt_fixup_mac_addresses(&bd.bi_enetaddr, &bd.bi_enet1addr);
+ dt_fixup_mac_address_by_alias("ethernet0", bd.bi_enetaddr);
+ dt_fixup_mac_address_by_alias("ethernet1", bd.bi_enet1addr);
}
void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
Index: working-2.6/arch/powerpc/boot/cuboot-warp.c
===================================================================
--- working-2.6.orig/arch/powerpc/boot/cuboot-warp.c 2008-02-26 11:30:30.000000000 +1100
+++ working-2.6/arch/powerpc/boot/cuboot-warp.c 2008-02-26 11:34:26.000000000 +1100
@@ -23,7 +23,7 @@ static void warp_fixups(void)
ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
ibm4xx_sdram_fixup_memsize();
ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
- dt_fixup_mac_addresses(&bd.bi_enetaddr);
+ dt_fixup_mac_address_by_alias("ethernet0", bd.bi_enetaddr);
}
Index: working-2.6/arch/powerpc/boot/dts/bamboo.dts
===================================================================
--- working-2.6.orig/arch/powerpc/boot/dts/bamboo.dts 2008-02-26 11:30:30.000000000 +1100
+++ working-2.6/arch/powerpc/boot/dts/bamboo.dts 2008-02-26 11:34:26.000000000 +1100
@@ -207,7 +207,6 @@
};
EMAC0: ethernet@ef600e00 {
- linux,network-index = <0>;
device_type = "network";
compatible = "ibm,emac-440ep", "ibm,emac-440gp", "ibm,emac";
interrupt-parent = <&UIC1>;
@@ -228,7 +227,6 @@
};
EMAC1: ethernet@ef600f00 {
- linux,network-index = <1>;
device_type = "network";
compatible = "ibm,emac-440ep", "ibm,emac-440gp", "ibm,emac";
interrupt-parent = <&UIC1>;
Index: working-2.6/arch/powerpc/boot/dts/warp.dts
===================================================================
--- working-2.6.orig/arch/powerpc/boot/dts/warp.dts 2008-02-26 11:30:30.000000000 +1100
+++ working-2.6/arch/powerpc/boot/dts/warp.dts 2008-02-26 11:34:26.000000000 +1100
@@ -204,7 +204,6 @@
};
EMAC0: ethernet@ef600e00 {
- linux,network-index = <0>;
device_type = "network";
compatible = "ibm,emac-440ep", "ibm,emac-440gp", "ibm,emac";
interrupt-parent = <&UIC1>;
Index: working-2.6/arch/powerpc/boot/dts/sequoia.dts
===================================================================
--- working-2.6.orig/arch/powerpc/boot/dts/sequoia.dts 2008-02-26 11:30:30.000000000 +1100
+++ working-2.6/arch/powerpc/boot/dts/sequoia.dts 2008-02-26 11:34:26.000000000 +1100
@@ -273,7 +273,6 @@
};
EMAC0: ethernet@ef600e00 {
- linux,network-index = <0>;
device_type = "network";
compatible = "ibm,emac-440epx", "ibm,emac4";
interrupt-parent = <&EMAC0>;
@@ -303,7 +302,6 @@
};
EMAC1: ethernet@ef600f00 {
- linux,network-index = <1>;
device_type = "network";
compatible = "ibm,emac-440epx", "ibm,emac4";
interrupt-parent = <&EMAC1>;
Index: working-2.6/arch/powerpc/boot/cuboot-rainier.c
===================================================================
--- working-2.6.orig/arch/powerpc/boot/cuboot-rainier.c 2008-02-26 11:30:30.000000000 +1100
+++ working-2.6/arch/powerpc/boot/cuboot-rainier.c 2008-02-26 11:34:26.000000000 +1100
@@ -42,7 +42,8 @@ static void rainier_fixups(void)
ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
ibm4xx_denali_fixup_memsize();
- dt_fixup_mac_addresses(&bd.bi_enetaddr, &bd.bi_enet1addr);
+ dt_fixup_mac_address_by_alias("ethernet0", bd.bi_enetaddr);
+ dt_fixup_mac_address_by_alias("ethernet1", bd.bi_enet1addr);
}
void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
Index: working-2.6/arch/powerpc/boot/dts/rainier.dts
===================================================================
--- working-2.6.orig/arch/powerpc/boot/dts/rainier.dts 2008-02-26 11:30:30.000000000 +1100
+++ working-2.6/arch/powerpc/boot/dts/rainier.dts 2008-02-26 11:34:26.000000000 +1100
@@ -258,7 +258,6 @@
};
EMAC0: ethernet@ef600e00 {
- linux,network-index = <0>;
device_type = "network";
compatible = "ibm,emac-440grx", "ibm,emac-440epx", "ibm,emac4";
interrupt-parent = <&EMAC0>;
@@ -288,7 +287,6 @@
};
EMAC1: ethernet@ef600f00 {
- linux,network-index = <1>;
device_type = "network";
compatible = "ibm,emac-440grx", "ibm,emac-440epx", "ibm,emac4";
interrupt-parent = <&EMAC1>;
Index: working-2.6/arch/powerpc/boot/dts/walnut.dts
===================================================================
--- working-2.6.orig/arch/powerpc/boot/dts/walnut.dts 2008-02-26 11:30:30.000000000 +1100
+++ working-2.6/arch/powerpc/boot/dts/walnut.dts 2008-02-26 11:34:26.000000000 +1100
@@ -125,7 +125,6 @@
};
EMAC: ethernet@ef600800 {
- linux,network-index = <0>;
device_type = "network";
compatible = "ibm,emac-405gp", "ibm,emac";
interrupt-parent = <&UIC0>;
Index: working-2.6/arch/powerpc/boot/treeboot-walnut.c
===================================================================
--- working-2.6.orig/arch/powerpc/boot/treeboot-walnut.c 2008-02-26 11:30:30.000000000 +1100
+++ working-2.6/arch/powerpc/boot/treeboot-walnut.c 2008-02-26 11:34:26.000000000 +1100
@@ -68,7 +68,7 @@ static void walnut_fixups(void)
ibm4xx_quiesce_eth((u32 *)0xef600800, NULL);
ibm4xx_fixup_ebc_ranges("/plb/ebc");
walnut_flashsel_fixup();
- dt_fixup_mac_addresses((u8 *) WALNUT_OPENBIOS_MAC_OFF);
+ dt_fixup_mac_address_by_alias("ethernet0", (u8 *) WALNUT_OPENBIOS_MAC_OFF);
}
void platform_init(void)
Index: working-2.6/Documentation/powerpc/booting-without-of.txt
===================================================================
--- working-2.6.orig/Documentation/powerpc/booting-without-of.txt 2008-02-26 11:30:30.000000000 +1100
+++ working-2.6/Documentation/powerpc/booting-without-of.txt 2008-02-26 11:34:26.000000000 +1100
@@ -1269,10 +1269,6 @@ platforms are moved over to use the flat
Recommended properties:
- - linux,network-index : This is the intended "index" of this
- network device. This is used by the bootwrapper to interpret
- MAC addresses passed by the firmware when no information other
- than indices is available to associate an address with a device.
- phy-connection-type : a string naming the controller/PHY interface type,
i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "sgmii",
"tbi", or "rtbi". This property is only really needed if the connection
@@ -1667,10 +1663,6 @@ platforms are moved over to use the flat
- phy-handle : The phandle for the PHY connected to this controller.
Recommended properties:
- - linux,network-index : This is the intended "index" of this
- network device. This is used by the bootwrapper to interpret
- MAC addresses passed by the firmware when no information other
- than indices is available to associate an address with a device.
- phy-connection-type : a string naming the controller/PHY interface type,
i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id" (Internal
Delay), "rgmii-txid" (delay on TX only), "rgmii-rxid" (delay on RX only),
@@ -1995,7 +1987,6 @@ platforms are moved over to use the flat
interrupts = <20 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY0>;
- linux,network-index = <0>;
fsl,cpm-command = <12000300>;
};
@@ -2217,12 +2208,6 @@ platforms are moved over to use the flat
EMAC, that is the content of the current (bogus) "phy-port"
property.
- Recommended properties:
- - linux,network-index : This is the intended "index" of this
- network device. This is used by the bootwrapper to interpret
- MAC addresses passed by the firmware when no information other
- than indices is available to associate an address with a device.
-
Optional properties:
- phy-address : 1 cell, optional, MDIO address of the PHY. If absent,
a search is performed.
@@ -2246,7 +2231,6 @@ platforms are moved over to use the flat
Example:
EMAC0: ethernet@40000800 {
- linux,network-index = <0>;
device_type = "network";
compatible = "ibm,emac-440gp", "ibm,emac";
interrupt-parent = <&UIC1>;
--
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: [PATCH] Add support for binary includes.
From: David Gibson @ 2008-02-26 0:39 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl
In-Reply-To: <20080220191941.GA2062@ld0162-tx32.am.freescale.net>
On Wed, Feb 20, 2008 at 01:19:41PM -0600, Scott Wood wrote:
> A property's data can be populated with a file's contents
> as follows:
>
> node {
> prop = /incbin/("path/to/data");
> };
>
> A subset of a file can be included by passing start and size parameters.
> For example, to include bytes 8 through 23:
>
> node {
> prop = /incbin/("path/to/data", 8, 16);
> };
>
> As with /include/, non-absolute paths are looked for in the directory
> of the source file that includes them.
Well, while I discuss the syntax with Jon, here's some comments on the
implementation.
> diff --git a/Makefile b/Makefile
> index 8a47c34..d4d935c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -16,7 +16,7 @@ LOCAL_VERSION =
> CONFIG_LOCALVERSION =
>
> CPPFLAGS = -I libfdt
> -CFLAGS = -Wall -g -Os
> +CFLAGS = -Wall -g -Os -D_FILE_OFFSET_BITS=64
Is this portable?
>
> BISON = bison
> LEX = flex
> diff --git a/data.c b/data.c
> index a94718c..f9464bf 100644
> --- a/data.c
> +++ b/data.c
> @@ -19,6 +19,7 @@
> */
>
> #include "dtc.h"
> +#include "srcpos.h"
>
> void data_free(struct data d)
> {
> @@ -189,7 +190,41 @@ struct data data_copy_file(FILE *f, size_t len)
> d = data_grow_for(empty_data, len);
>
> d.len = len;
> - fread(d.val, len, 1, f);
> + if (fread(d.val, len, 1, f) != 1) {
> + yyerrorf("Couldn't read %zu bytes from file: %s",
> + len, feof(f) ? "end-of-file" : strerror(errno));
> + return empty_data;
Ugh.
1) Error messages direct to the user really don't belong in
data.c's low-level support routines. This does mean we might need to
substantially change this function so there's some other way of
reporting the error to the caller who can report it.
2) The horrid name 'yyerror()' exists only to match what bison
expects. It should never be used outside the parse code (we probably
should create more generally usable error/warning functions, though).
3) Is %zu portable?
> + }
> +
> + return d;
> +}
> +
> +struct data data_copy_file_all(FILE *f)
It should be possible to combine these two functions.
> +{
> + char buf[4096];
> + struct data d = empty_data;
> +
> + while (1) {
> + size_t ret = fread(buf, 1, sizeof(buf), f);
> + if (ret == 0) {
> + if (!feof(f))
> + yyerrorf("Error reading file: %s", strerror(errno));
> +
> + break;
> + }
> +
> + assert(ret <= sizeof(buf));
> +
> + d = data_grow_for(d, ret);
> + memcpy(d.val + d.len, buf, ret);
> +
> + if (d.len + ret < d.len) {
> + yyerror("Binary include too large");
Hrm. A test which will cover this case should go into
data_grow_for(), I think.
--
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: XUP Virtex II p with Linux 2.4 - Question
From: Grant Likely @ 2008-02-25 20:05 UTC (permalink / raw)
To: rodolfo; +Cc: linuxppc-embedded
In-Reply-To: <9974727a671b73eacef871a6a394c6cb@lesc.ufc.br>
On Mon, Feb 25, 2008 at 12:05 PM, rodolfo <rodolfo@lesc.ufc.br> wrote:
> Hey everybody,
>
> I'm in trouble;
>
> 1) The EDK flow: I set the OS in the Software Plataform Settings to
> linux_2_6 version 1.00.a. after that, in OS and Library section I have to
> fill out the fields "memory size" , "connected_periphs" , "ramdisk size"
> ... ? How would I do it ?
>
> 2) Do I place xparametera_ml300.h in /opt/ELDK/ppc_4xx/usr/src/linux-2.6.15
> ? if not where?
You should download a current release of the linux kernel. Don't use
the one that comes with ELDK.
in arch/ppc/platforms/4xx/xparameters/xparameters_ml403.h. If you're
using the ml403 reference design, it is already there. If you're
using a custom design then you'll need to replace it.
See here for hints:
http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex
> 3) I downloaded "ppc-2006-01-11.iso" from denx (ELDK) website and I'm
> trying to follow their instructions for ppc 4xx plataform.
> [ website: http://www.denx.de/wiki/view/DULG/ELDK ]
This is an old release of ELDK. You should probably move up to a more
recent release.
>
> In /opt/ELDK/ppc_4xx/usr/src/u-boot-1.1.4/ I do:
>
> "make distclen" and "make ml300_config" are ok! After "make all" in I've
> got an error:
>
> a - ppc_longjmp.o
> a - ppc_setjmp.o
> a - stubs.o
> make[1]: *** No rules for processing the target `hello_world.srec', needed
> by `all'. Stop. --> note: "TRANSLATION FROM PORTUGESE"
> make[1]: Exiting `/opt/ELDK/ppc_4xx/usr/src/u-boot-1.1.4/examples'
> make: ** [examples] Error 2
You're using an ancient copy of u-boot that breaks with certain
versions of the 'make' program. You should try using a recent release
of u-boot. Alternately, you can hack the u-boot makefile to not build
the examples directory.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Status of 5200B and 440 Kernel Support
From: Albrecht Dreß @ 2008-02-25 20:01 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20080224073800.4bdb30ac@zod.rchland.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]
Hi Josh,
thanks a lot for your answers!
Am 24.02.08 14:38 schrieb(en) Josh Boyer:
> > - MTD/NAND controller
>
> NOR flash works. NAND needs some additional code.
Hmm - does it mean it's currently under development? I couldn't find
anything in make xconfig for stock 2.6.24 (running on a PowerMac, but
of course with the 44x enabled).
> UART works. IIC has recent patches. No idea about SPI.
SPI is probably not too hard. I did some hacks for a slave in an
arm920 based environment for that. Here I would need master mode, so I
guess some of the infrastructure form drivers/spi can be used.
> > - local external bus (not PCI) DMA
>
> DMA to the EBC for what?
To load data from an external measurement device which should be
connected to the cpu's external bus at a fixed address. It will
produce "bursts" which should be shifted out of it without cpu
intervention if possible, as it does not have a big fifo, and I must
not lose data.
Thanks,
Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: XUP Virtex II p with Linux 2.4 - Question
From: rodolfo @ 2008-02-25 19:05 UTC (permalink / raw)
To: linuxppc-embedded
Hey everybody,
I'm in trouble;
1) The EDK flow: I set the OS in the Software Plataform Settings to
linux_2_6 version 1.00.a. after that, in OS and Library section I have to
fill out the fields "memory size" , "connected_periphs" , "ramdisk size"
... ? How would I do it ?
2) Do I place xparametera_ml300.h in /opt/ELDK/ppc_4xx/usr/src/linux-2.6.15
? if not where?
3) I downloaded "ppc-2006-01-11.iso" from denx (ELDK) website and I'm
trying to follow their instructions for ppc 4xx plataform.
[ website: http://www.denx.de/wiki/view/DULG/ELDK ]
In /opt/ELDK/ppc_4xx/usr/src/u-boot-1.1.4/ I do:
"make distclen" and "make ml300_config" are ok! After "make all" in I've
got an error:
a - ppc_longjmp.o
a - ppc_setjmp.o
a - stubs.o
make[1]: *** No rules for processing the target `hello_world.srec', needed
by `all'. Stop. --> note: "TRANSLATION FROM PORTUGESE"
make[1]: Exiting `/opt/ELDK/ppc_4xx/usr/src/u-boot-1.1.4/examples'
make: ** [examples] Error 2
Can you help me, please?
Thanks in advance,
Rodolfo Galvão.
On Tue, 19 Feb 2008 10:07:54 -0700, "Grant Likely"
<grant.likely@secretlab.ca> wrote:
> On Feb 19, 2008 9:55 AM, rodolfo <rodolfo@lesc.ufc.br> wrote:
>> ok Grant Likely. i have a talk with my professor and he agrees with you.
>> Now i'm reading about ELDK. Following this guide, i will have problems
> with
>> edk version?
>
> No. One of the advantages of going with 2.6 is that you no longer
> need to copy the BSP generated by EDK into the linux kernel tree.
> Instead you only need to copy one file; xparameters_ml40x.h
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: What happened to cpm2_hostalloc
From: Scott Wood @ 2008-02-25 19:02 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-dev
In-Reply-To: <F795765B112E7344AF36AA911279641502D1AAEC@xmb-sjc-212.amer.cisco.com>
On Mon, Feb 25, 2008 at 10:47:04AM -0800, Bizhan Gholikhamseh (bgholikh) wrote:
> In Linux 2.6.11 version, there was a function named "cpm2_hostalloc" to
> allocate memory at
> specific boundary. I am not able to locate that in the latest Linux
> version, 2.6.24-rc4. Is there any
> similiar function to this that I can use?
> The SPI module on the CPM2 module required the memory descriptor on the
> ram to be at specific
> boundray (8 bytes).
It's probably best to use DPRAM for the descriptors if possible. However,
if you want/need to use RAM, just allocate 8 bytes more than you need and
manually align it.
-Scott
^ permalink raw reply
* What happened to cpm2_hostalloc
From: Bizhan Gholikhamseh (bgholikh) @ 2008-02-25 18:47 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 404 bytes --]
Hi All,
In Linux 2.6.11 version, there was a function named "cpm2_hostalloc" to
allocate memory at
specific boundary. I am not able to locate that in the latest Linux
version, 2.6.24-rc4. Is there any
similiar function to this that I can use?
The SPI module on the CPM2 module required the memory descriptor on the
ram to be at specific
boundray (8 bytes).
Many thanks in advance,
Bizhan
[-- Attachment #2: Type: text/html, Size: 1392 bytes --]
^ permalink raw reply
* Re: [PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
From: Jochen Friedrich @ 2008-02-25 16:48 UTC (permalink / raw)
To: Olof Johansson
Cc: Jean Delvare, linuxppc-dev list, linux-kernel, Scott Wood, i2c
In-Reply-To: <20080224181509.GA6745@lixom.net>
Hi Olof,
> And even if you DO decide to go that route, guess what? You need a
> translation table just as with (3) anyway!
True.
>>>> 3. use a glue layer with a translation map.
>>> In my opinion this is an OK solution since the same information has to
>>> be added somewhere already anyway -- eiither to the drivers or to this
>>> translation table. It should of course be an abstacted shared table,
>>> preferrably contained under the i2c source directories since several
>>> platforms and architectures might share them.
>> I could think of a mixture between 2. and 3.:
>>
>> Using the compatible attribute with the manufacturer stripped off as I2c name by default
>> and using an exception table. For now, the struct i2c_driver_device would currently only
>> need one entry ("dallas,ds1374", "rtc-ds1374").
>
> You still need the translation table, you're just flattening the
> namespace to one string instead of two, the same information still has
> to be encoded. I can't see what the benefit of this approach compared to
> the other one is. "dallas,ds1374" already only has one translation entry
> in the table?
As soon as http://lists.lm-sensors.org/pipermail/i2c/2008-January/002752.html has been
applied, one could get rid of all entries where the I2c (alias) name can be obtained from
the OF name just by stripping the manufacturer.
Thanks,
Jochen
^ permalink raw reply
* Re: E500 linux : are the 64-bit GPRs context-switched ?
From: Scott Wood @ 2008-02-25 16:58 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080225144722.GA5011@ingate.macqel>
On Mon, Feb 25, 2008 at 03:47:22PM +0100, Philippe De Muyter wrote:
> Searching around, I learned that the E500 GPR registers are 64-bits wide,
> and gcc targetted for powerpc-linuxspe uses them sometimes. In the other
> PPC32 targets, those registers are 32-bits wide.
>
> The specific E500 64-bit move instructions are `evstdd' and `evldd'.
> I searched in the linux kernel sources (2.6.24) but did not find where
> those GPR registers could be saved in 64-bit mode for context-switch.
giveup_spe and load_up_spe.
-Scott
^ 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