* Re: Mikrotik RouterBoard 333
From: David Gibson @ 2008-07-22 3:48 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <48854C02.7000307@gmail.com>
On Mon, Jul 21, 2008 at 10:54:58PM -0400, Jerry Van Baren wrote:
> Scott Wood wrote:
>> On Sun, Jul 13, 2008 at 08:44:46PM -0400, Jerry Van Baren wrote:
>>> I'm a half-ack. ;-) I'm partial to u-boot's implementation rather
>>> than using a bootwrapper for obvious reasons. The u-boot
>>> implementation takes the blob as a boot parameter and passes it
>>> along to the kernel after doing appropriate (optional) fixups.
>>
>> And if those fixups expect a malformed device tree?
>
> Oops, very bad choice of terms on my part. :-( The fixups I referred
> to are mostly "fill in the blank" things like setting the various
> clocks, MAC information, PCI information, etc. to the correct values
> based on hardware probing or a priori knowledge. U-boot does not
> (should not / will not!) fix broken device trees. A broken tree w/ the
> u-boot methodology is fixed by loading a corrected one, not requiring a
> full rebuild and reload of the firmware.
>
> Note that the blobs are (should be) made from the *.dts files that are
> part of the linux kernel source, so having correct ones has not been a
> problem. Since replacement ones are easily loaded, broken blobs are
> fixed by replacement, not by contorted fixups a'la the start of this
> thread. Since blobs are well defined, even if some boneheaded company
> didn't release their blob source, it is trivial to dump it (e.g. "fdt
> print /"), fixed, and then replaced.
>
>>> Other than that quibble, I agree that burning the blob into the
>>> firmware so that the firmware must be recompiled and reburned to
>>> change the blob is very undesirable.
>>
>> I thought the device tree was *supposed* to be an interface between the
>> firmware and the kernel? What if the firmware produces the tree
>> dynamically? What if the firmware itself depends on having the device tree
>> in order to operate?
>>
>> -Scott
>
> Well, yes and no on dynamically generated blobs. There isn't much point
> "dynamically" generating the static parts of the blob - if you have
> static code "dynamically" generating the static parts of the blob, is it
> dynamic or static? That is probably exactly where Mikrotik has
> problems. The truly dynamic parts are a small part of the blob.
Well.. they often are, particularly for embedded boards.
If there really is a large part of the tree which is dynamic, then
certainly it makes sense for the firmware to generate it and supply a
blob to the kernel. Of course in this sort of situation it would also
make sense to have a full OF firmware. Likewise, if the firmware is
sufficiently complex to want to make substantial internal use of the
device tree, it makes sense for it to pass it to the kernel. If you
have a firmware of this sort of sophistication, though, please, please
try to get the tree *right*.
A lot of firmwares however, as gvb says just take a skeleton device
tree and do nothing more than poke a few integers into specific places
into it. Maybe either leave in or remove a subtree representing an
optional peripheral.
This is the common case for embedded systems where something in the
installed software stack has to Just Know what the hardware looks
like. In this case, in theory, it's pretty much arbitrary whether the
the devtree is bundled into the piece of the stack labelled
"firmware"/"bootloader", or the piece labelled "kernel", or even (as
with u-boot) yet another "device tree" section.
In practice however, it makes sense for the tree to be bundled with
the most-easily-updated section of the stack, because that way it's
easier to correct errors in it. And usually, that means putting it
with the kernel (using the zImage wrapper). In particular this makes
sense because the kernel is the only real user of the device tree, and
this way platform specific bugs can just be fixed in the device tree,
without needing code to deal with both broken device trees from old
firmwares and fixed device trees from newer firmwares.
> If all else fails, u-boot is GPLed and the user is able to get the
> source and fix it (well, at least for 3 years after purchasing the
> hardware).
>
> There are advantages and disadvantages to u-boot and boot-wrapper
> methods. There are nothing but disadvantages to having the blob
> physically a part of the firmware (with a double whammy if the firmware
> source is not readily available).
Well, "nothing but disadvantages" isn't strictly true. In theory
boards with this arrangement which are sufficiently similar to
existing systems could run a generic kernel without any porting work.
In practice, board firmwares get things right so exceedingly rarely
that the kernel will need workarounds anyway, so it might as well just
include the device tree itself.
--
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 01/16 v3] powerpc: Remove extraneous error reporting for hcall failures in lparcfg
From: Paul Mackerras @ 2008-07-22 3:34 UTC (permalink / raw)
To: Robert Jennings; +Cc: Brian King, linuxppc-dev, David Darrington
In-Reply-To: <20080704125106.GB1310@linux.vnet.ibm.com>
Robert Jennings writes:
> From: Nathan Fontenot <nfont@austin.ibm.com>
>
> Remove the extraneous error reporting used when a hcall made from lparcfg fails.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
> Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: gigantci pages patches
From: David Gibson @ 2008-07-22 3:34 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: npiggin, Jon Tollefson, ppc-dev, paulus, Andrew Morton
In-Reply-To: <20080711174515.1aacf83b.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]
On Fri, Jul 11, 2008 at 05:45:15PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Could people take one last look at these patches and if there are no
> issues, please send Ack-bys to Andrew who will push them to Linus for
> 2.6.27.
>
> [PATCH 1/6 v2] allow arch specific function for allocating gigantic pages
> http://patchwork.ozlabs.org/linuxppc/patch?&id=18437
> Patch: [PATCH 2/6 v2] powerpc: function for allocating gigantic pages
> http://patchwork.ozlabs.org/linuxppc/patch?&id=18438
> Patch: [PATCH 3/6 v2] powerpc: scan device tree and save gigantic page locations
> http://patchwork.ozlabs.org/linuxppc/patch?&id=18439
> Patch: [PATCH 4/6 v2] powerpc: define page support for 16G pages
> http://patchwork.ozlabs.org/linuxppc/patch?&id=18440
> Patch: [PATCH 5/6 v2] check for overflow
> http://patchwork.ozlabs.org/linuxppc/patch?&id=18441
> Patch: [PATCH 6/6] powerpc: support multiple huge page sizes
> http://patchwork.ozlabs.org/linuxppc/patch?&id=18442
Sorry, I should have looked at these properly when they went past in
May, but obviously I missed them.
They mostly look ok. I'm a bit confused on 2/6 though - it seems the
new powerpc alloc_bootmem_huge_page() function is specific to the 16G
gigantic pages. But can't that function also get called for the
normal 16M hugepages depending on how the hugepage pool is
initialized.
Or am I missing something (wouldn't surprise me given my brain's
sluggishness today)?
--
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Help required i2c-mpc driver
From: Akash Bhatnagar @ 2008-07-22 2:59 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 3280 bytes --]
Hi,
I am working on implementation of I2C driver for both MPC8540(A) & MPC8560(B) in Master Mode scenarios. The problem I am facing is given below
If I read any buffer part via I2C bus from A to B continuously,the driver is working fine. However during this processing ,if B tries to read any buffer register from A the bus will goes into low state (both SCL and SDA are low).The error that it was showing are mainly NO ACK and Remote IO errors. After this I suspect that it may be the problem form slave receive function that I implemented. The reference Manual says that you have to set I2CCR[TXAK] bit after slave receive finishes. But how does slave knows wether this will last byte of transaction.Only Master have this knowledge. The slave implementation is as follows:-
#ifdef CONFIG_MPC_I2C_SLAVE
// lost arbitration?
if ((priv->read(&priv->regs->i2csr) & MPC_I2CSR_MAL))
{
priv->write(&priv->regs->i2csr, 0, MPC_I2CSR_MAL);
if ((priv->read(&priv->regs->i2csr) & MPC_I2CSR_MAAS))
{
mpc_slave_address_match(priv);
}
}
else
{
if ((priv->read(&priv->regs->i2csr) & MPC_I2CSR_MAAS))
{
mpc_slave_address_match(priv);
}
else if ((priv->read(&priv->regs->i2ccr) & MPC_I2CCR_MTX))
{
mpc_slave_tx(priv);
}
else
{
mpc_slave_rx(priv);
}
}
#endif
}
static inline void mpc_slave_rx(struct mpc_i2c_private *priv)
{
buffer = priv->read(&priv->regs->i2cdr);
-------------Some Montavista Event Broker Part-----------
}
Since I am new in I2C functionality, Please point out any mistake I was doing.
This message and any attachment therewith is privileged, confidential and proprietary in nature and the property of the originator. It is intended solely and exclusively for use by the individual to whom it is addressed. It should not be circulated or used for any purpose other than for what is stated. If you have received this message erroneously, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message and are called upon to delete the same from your system. Any contradictory action by you may invite penal consequences. Vihaan Networks Limited accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including but not limited to damage from virus."
[-- Attachment #2: Type: text/html, Size: 16999 bytes --]
^ permalink raw reply
* Re: [PATCH] serial: fix struct uart_info change fallout
From: Stephen Rothwell @ 2008-07-22 3:01 UTC (permalink / raw)
To: Alan Cox; +Cc: ppc-dev, linux-next, Linus Torvalds, LKML
In-Reply-To: <20080722025850.0d073a5e@lxorguk.ukuu.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]
Hi Alan,
On Tue, 22 Jul 2008 02:58:50 +0100 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> Yes I know.
Indeed, you knew before you pushed the breaking patches to Linus.
> I've been trying to get the other patches merged but each of the five
> pulls of Linus tree I have done has broken the tty patch merges *AGAIN*
> so I still don't have them tested and ready to merge despite it being 3AM.
Then why weren't the fixes rolled back into the original patch or at
least submitted at the same time?
> So much for the linux-next tree. Please give it until tomorrow or you are
What is your problem with the linux-next tree. The problem was
discovered and reported when I first merged the ttydev tree into
linux-next on July 1. The fixes were in linux-next on July 2.
> just going to break the tree again and mean I have to run another set of
> tests and regressions.
Please give what until tomorrow?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Mikrotik RouterBoard 333
From: Jerry Van Baren @ 2008-07-22 2:54 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080721211344.GA13268@loki.buserror.net>
Scott Wood wrote:
> On Sun, Jul 13, 2008 at 08:44:46PM -0400, Jerry Van Baren wrote:
>> I'm a half-ack. ;-) I'm partial to u-boot's implementation rather than
>> using a bootwrapper for obvious reasons. The u-boot implementation
>> takes the blob as a boot parameter and passes it along to the kernel
>> after doing appropriate (optional) fixups.
>
> And if those fixups expect a malformed device tree?
Oops, very bad choice of terms on my part. :-( The fixups I referred
to are mostly "fill in the blank" things like setting the various
clocks, MAC information, PCI information, etc. to the correct values
based on hardware probing or a priori knowledge. U-boot does not
(should not / will not!) fix broken device trees. A broken tree w/ the
u-boot methodology is fixed by loading a corrected one, not requiring a
full rebuild and reload of the firmware.
Note that the blobs are (should be) made from the *.dts files that are
part of the linux kernel source, so having correct ones has not been a
problem. Since replacement ones are easily loaded, broken blobs are
fixed by replacement, not by contorted fixups a'la the start of this
thread. Since blobs are well defined, even if some boneheaded company
didn't release their blob source, it is trivial to dump it (e.g. "fdt
print /"), fixed, and then replaced.
>> Other than that quibble, I agree that burning the blob into the firmware
>> so that the firmware must be recompiled and reburned to change the blob
>> is very undesirable.
>
> I thought the device tree was *supposed* to be an interface between the
> firmware and the kernel? What if the firmware produces the tree
> dynamically? What if the firmware itself depends on having the device tree
> in order to operate?
>
> -Scott
Well, yes and no on dynamically generated blobs. There isn't much point
"dynamically" generating the static parts of the blob - if you have
static code "dynamically" generating the static parts of the blob, is it
dynamic or static? That is probably exactly where Mikrotik has
problems. The truly dynamic parts are a small part of the blob.
If all else fails, u-boot is GPLed and the user is able to get the
source and fix it (well, at least for 3 years after purchasing the
hardware).
There are advantages and disadvantages to u-boot and boot-wrapper
methods. There are nothing but disadvantages to having the blob
physically a part of the firmware (with a double whammy if the firmware
source is not readily available).
Best regards,
gvb
^ permalink raw reply
* Re: [PATCH] serial: fix struct uart_info change fallout
From: Alan Cox @ 2008-07-22 2:00 UTC (permalink / raw)
To: Dave Jones; +Cc: Stephen Rothwell, linux-next, Linus Torvalds, LKML, ppc-dev
In-Reply-To: <20080722003814.GA14809@redhat.com>
On Mon, 21 Jul 2008 20:38:14 -0400
Dave Jones <davej@redhat.com> wrote:
> On Tue, Jul 22, 2008 at 10:25:20AM +1000, Stephen Rothwell wrote:
> > Hi Linus, Alan,
> >
> > Today's linux-next (actually just Linus' tree) build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > drivers/serial/serial_txx9.c: In function 'receive_chars':
> > drivers/serial/serial_txx9.c:275: error: 'struct uart_info' has no member named 'tty'
> > drivers/serial/icom.c: In function 'recv_interrupt':
> > drivers/serial/icom.c:733: error: 'struct uart_info' has no member named 'tty'
>
> That's the same pair of patches I sent earlier, which apparently were
> "Already in the ttydev tree" which should be in linux-next ?
And are in Linux next, and would be in the Linus submission queue except
that everyone keeps patching tty files from other trees.
<mutter>
Alan
^ permalink raw reply
* Re: [PATCH] serial: fix struct uart_info change fallout
From: Alan Cox @ 2008-07-22 1:58 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, linux-next, Linus Torvalds, LKML
In-Reply-To: <20080722102520.ca801ab5.sfr@canb.auug.org.au>
On Tue, 22 Jul 2008 10:25:20 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Linus, Alan,
>
> Today's linux-next (actually just Linus' tree) build (powerpc
> ppc64_defconfig) failed like this:
Yes I know.
I've been trying to get the other patches merged but each of the five
pulls of Linus tree I have done has broken the tty patch merges *AGAIN*
so I still don't have them tested and ready to merge despite it being 3AM.
So much for the linux-next tree. Please give it until tomorrow or you are
just going to break the tree again and mean I have to run another set of
tests and regressions.
Alan
^ permalink raw reply
* Re: [PATCH v4] elf loader support for auxvec base platform string
From: Benjamin Herrenschmidt @ 2008-07-22 2:03 UTC (permalink / raw)
To: Nathan Lynch
Cc: John Reiser, linux-kernel, linuxppc-dev, Andrew Morton, torvalds,
roland
In-Reply-To: <20080721184846.GU9594@localdomain>
On Mon, 2008-07-21 at 13:48 -0500, Nathan Lynch wrote:
> Some IBM POWER-based platforms have the ability to run in a
> mode which mostly appears to the OS as a different processor from the
> actual hardware. For example, a Power6 system may appear to be a
> Power5+, which makes the AT_PLATFORM value "power5+". This means that
> programs are restricted to the ISA supported by Power5+;
> Power6-specific instructions are treated as illegal.
>
> However, some applications (virtual machines, optimized libraries) can
> benefit from knowledge of the underlying CPU model. A new aux vector
> entry, AT_BASE_PLATFORM, will denote the actual hardware. For
> example, on a Power6 system in Power5+ compatibility mode, AT_PLATFORM
> will be "power5+" and AT_BASE_PLATFORM will be "power6". The idea is
> that AT_PLATFORM indicates the instruction set supported, while
> AT_BASE_PLATFORM indicates the underlying microarchitecture.
>
> If the architecture has defined ELF_BASE_PLATFORM, copy that value to
> the user stack in the same manner as ELF_PLATFORM.
>
> Signed-off-by: Nathan Lynch <ntl@pobox.com>
Andrew, I'll merge that after John patch shows up if you give me your
Ack :-)
Cheers,
Ben.
> ---
>
> Andrew Morton wrote:
> > OK.
> >
> > But it conflicts directly with the already-queued
> > execve-filename-document-and-export-via-auxiliary-vector.patch (which
> > various potential reviewers blithely deleted - don't come complaining
> > to me!):
> >
>
> Rebased to -mm to resolve conflicts with
> execve-filename-document-and-export-via-auxiliary-vector.patch, and
> changed AT_BASE_PLATFORM to lowest unclaimed value (24).
>
>
> fs/binfmt_elf.c | 28 ++++++++++++++++++++++++++++
> include/linux/auxvec.h | 6 +++++-
> 2 files changed, 33 insertions(+), 1 deletions(-)
>
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index bad7d87..180f92b 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -131,6 +131,15 @@ static int padzero(unsigned long elf_bss)
> #define STACK_ALLOC(sp, len) ({ sp -= len ; sp; })
> #endif
>
> +#ifndef ELF_BASE_PLATFORM
> +/*
> + * AT_BASE_PLATFORM indicates the "real" hardware/microarchitecture.
> + * If the arch defines ELF_BASE_PLATFORM (in asm/elf.h), the value
> + * will be copied to the user stack in the same manner as AT_PLATFORM.
> + */
> +#define ELF_BASE_PLATFORM NULL
> +#endif
> +
> static int
> create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
> unsigned long load_addr, unsigned long interp_load_addr)
> @@ -142,7 +151,9 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
> elf_addr_t __user *envp;
> elf_addr_t __user *sp;
> elf_addr_t __user *u_platform;
> + elf_addr_t __user *u_base_platform;
> const char *k_platform = ELF_PLATFORM;
> + const char *k_base_platform = ELF_BASE_PLATFORM;
> int items;
> elf_addr_t *elf_info;
> int ei_index = 0;
> @@ -172,6 +183,19 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
> return -EFAULT;
> }
>
> + /*
> + * If this architecture has a "base" platform capability
> + * string, copy it to userspace.
> + */
> + u_base_platform = NULL;
> + if (k_base_platform) {
> + size_t len = strlen(k_base_platform) + 1;
> +
> + u_base_platform = (elf_addr_t __user *)STACK_ALLOC(p, len);
> + if (__copy_to_user(u_base_platform, k_base_platform, len))
> + return -EFAULT;
> + }
> +
> /* Create the ELF interpreter info */
> elf_info = (elf_addr_t *)current->mm->saved_auxv;
> /* update AT_VECTOR_SIZE_BASE if the number of NEW_AUX_ENT() changes */
> @@ -209,6 +233,10 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
> NEW_AUX_ENT(AT_PLATFORM,
> (elf_addr_t)(unsigned long)u_platform);
> }
> + if (k_base_platform) {
> + NEW_AUX_ENT(AT_BASE_PLATFORM,
> + (elf_addr_t)(unsigned long)u_base_platform);
> + }
> if (bprm->interp_flags & BINPRM_FLAGS_EXECFD) {
> NEW_AUX_ENT(AT_EXECFD, bprm->interp_data);
> }
> diff --git a/include/linux/auxvec.h b/include/linux/auxvec.h
> index 0da17d1..d7afa9d 100644
> --- a/include/linux/auxvec.h
> +++ b/include/linux/auxvec.h
> @@ -26,9 +26,13 @@
>
> #define AT_SECURE 23 /* secure mode boolean */
>
> +#define AT_BASE_PLATFORM 24 /* string identifying real platform, may
> + * differ from AT_PLATFORM. */
> +
> #define AT_EXECFN 31 /* filename of program */
> +
> #ifdef __KERNEL__
> -#define AT_VECTOR_SIZE_BASE 17 /* NEW_AUX_ENT entries in auxiliary table */
> +#define AT_VECTOR_SIZE_BASE 18 /* NEW_AUX_ENT entries in auxiliary table */
> /* number of "#define AT_.*" above, minus {AT_NULL, AT_IGNORE, AT_NOTELF} */
> #endif
>
^ permalink raw reply
* Re: [RFC v3 PATCH 6/4] Use LOAD_REG_IMMEDIATE macros
From: Paul Mackerras @ 2008-07-22 2:03 UTC (permalink / raw)
To: Mohan Kumar M; +Cc: naren, Milton Miller, ppcdev
In-Reply-To: <4884E2E9.6050108@in.ibm.com>
Mohan Kumar M writes:
@@ -714,7 +714,7 @@ _GLOBAL(enter_rtas)
std r6,PACASAVEDMSR(r13)
/* Setup our real return addr */
- LOAD_REG_ADDR(r4,.rtas_return_loc)
+ LOAD_REG_IMMEDIATE(r4,.rtas_return_loc)
If LOAD_REG_ADDR doesn't work, then how are all the TOC loads in
gcc-generated code going to work?
Paul.
^ permalink raw reply
* Re: [PATCH] serial: fix struct uart_info change fallout
From: Stephen Rothwell @ 2008-07-22 1:34 UTC (permalink / raw)
To: Dave Jones; +Cc: ppc-dev, linux-next, Linus Torvalds, LKML, Alan Cox
In-Reply-To: <20080722003814.GA14809@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 345 bytes --]
Hi Dave,
On Mon, 21 Jul 2008 20:38:14 -0400 Dave Jones <davej@redhat.com> wrote:
>
> That's the same pair of patches I sent earlier, which apparently were
> "Already in the ttydev tree" which should be in linux-next ?
Indeed.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] serial: fix struct uart_info change fallout
From: Dave Jones @ 2008-07-22 0:38 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, linux-next, Linus Torvalds, LKML, Alan Cox
In-Reply-To: <20080722102520.ca801ab5.sfr@canb.auug.org.au>
On Tue, Jul 22, 2008 at 10:25:20AM +1000, Stephen Rothwell wrote:
> Hi Linus, Alan,
>
> Today's linux-next (actually just Linus' tree) build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/serial/serial_txx9.c: In function 'receive_chars':
> drivers/serial/serial_txx9.c:275: error: 'struct uart_info' has no member named 'tty'
> drivers/serial/icom.c: In function 'recv_interrupt':
> drivers/serial/icom.c:733: error: 'struct uart_info' has no member named 'tty'
That's the same pair of patches I sent earlier, which apparently were
"Already in the ttydev tree" which should be in linux-next ?
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* [PATCH] serial: fix struct uart_info change fallout
From: Stephen Rothwell @ 2008-07-22 0:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: ppc-dev, linux-next, LKML, Alan Cox
Hi Linus, Alan,
Today's linux-next (actually just Linus' tree) build (powerpc
ppc64_defconfig) failed like this:
drivers/serial/serial_txx9.c: In function 'receive_chars':
drivers/serial/serial_txx9.c:275: error: 'struct uart_info' has no member named 'tty'
drivers/serial/icom.c: In function 'recv_interrupt':
drivers/serial/icom.c:733: error: 'struct uart_info' has no member named 'tty'
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/serial/icom.c | 2 +-
drivers/serial/serial_txx9.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/icom.c b/drivers/serial/icom.c
index 9c2df5c..2b7531d 100644
--- a/drivers/serial/icom.c
+++ b/drivers/serial/icom.c
@@ -730,7 +730,7 @@ static void xmit_interrupt(u16 port_int_reg, struct icom_port *icom_port)
static void recv_interrupt(u16 port_int_reg, struct icom_port *icom_port)
{
short int count, rcv_buff;
- struct tty_struct *tty = icom_port->uart_port.info->tty;
+ struct tty_struct *tty = icom_port->uart_port.info->port.tty;
unsigned short int status;
struct uart_icount *icount;
unsigned long offset;
diff --git a/drivers/serial/serial_txx9.c b/drivers/serial/serial_txx9.c
index 7ad2192..8fcb4c5 100644
--- a/drivers/serial/serial_txx9.c
+++ b/drivers/serial/serial_txx9.c
@@ -272,7 +272,7 @@ static void serial_txx9_initialize(struct uart_port *port)
static inline void
receive_chars(struct uart_txx9_port *up, unsigned int *status)
{
- struct tty_struct *tty = up->port.info->tty;
+ struct tty_struct *tty = up->port.info->port.tty;
unsigned char ch;
unsigned int disr = *status;
int max_count = 256;
--
1.5.6.2
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH] powerpc: Correct CMO entitlement accounting for map_sg
From: Robert Jennings @ 2008-07-22 0:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt, paulus, linuxppc-dev, Brian King,
Nathan Fontenot, David Darrington
The ibmvscsi driver maps pages via map_sg and frees the sg list by calling
unmap_single. This exposes a problem where the code had been using the
length field in the scatterlist to account for the allocation when the
mapping was created but the dma_length would be used when the mapping
was destroyed. The iommu code does coalesce the pages so the dma_length
can be smaller and would result in an entitlement accounting leak.
This patch frees up the entitlement after calling the iommu map_sg code
when pages have been coalesced so that freeing entitlement based on
dma_length is correct.
Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
---
This applies on top of the existing CMO patchset.
---
arch/powerpc/kernel/vio.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
Index: b/arch/powerpc/kernel/vio.c
===================================================================
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -571,6 +571,11 @@ static int vio_dma_iommu_map_sg(struct d
atomic_inc(&viodev->cmo.allocs_failed);
}
+ for (sgl = sglist, count = 0; count < ret; count++, sgl++)
+ alloc_size -= roundup(sgl->dma_length, PAGE_SIZE);
+ if (alloc_size)
+ vio_cmo_dealloc(viodev, alloc_size);
+
return ret;
}
@@ -584,7 +589,7 @@ static void vio_dma_iommu_unmap_sg(struc
int count = 0;
for (sgl = sglist; count < nelems; count++, sgl++)
- alloc_size += roundup(sgl->length, PAGE_SIZE);
+ alloc_size += roundup(sgl->dma_length, PAGE_SIZE);
dma_iommu_ops.unmap_sg(dev, sglist, nelems, direction);
^ permalink raw reply
* Re: Networkl problems with lastest kernel....
From: Benjamin Herrenschmidt @ 2008-07-21 23:59 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, smaclennan
In-Reply-To: <20080721.101650.181903456.davem@davemloft.net>
On Mon, 2008-07-21 at 10:16 -0700, David Miller wrote:
> From: Sean MacLennan <smaclennan@pikatech.com>
> Date: Mon, 21 Jul 2008 13:05:36 -0400
>
> > But I have attached the new OOPS anyway.
>
> The same problem is still there, this driver will
> unfortunately require quite a bit more surgery.
>
> You can instead add the following patch, it will
> warn instead of BUG on you, and try to continue.
Argh, EMAC ! I suppose I need to go have a look & fix it :-)
EMAC does some strange things such as sharing one NAPI instance for
multiple devices. Dunno if that's related to the problem. I need to dig
a bit.
Cheers,
Ben.
> >From 867d79fb9a4d5929ad8335c896fcfe11c3b2ef14 Mon Sep 17 00:00:00 2001
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Mon, 21 Jul 2008 09:54:18 -0700
> Subject: [PATCH] net: In __netif_schedule() use WARN_ON instead of BUG_ON
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> net/core/dev.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 7e2d527..cbc34c0 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1327,7 +1327,8 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
>
> void __netif_schedule(struct Qdisc *q)
> {
> - BUG_ON(q == &noop_qdisc);
> + if (WARN_ON_ONCE(q == &noop_qdisc))
> + return;
>
> if (!test_and_set_bit(__QDISC_STATE_SCHED, &q->state)) {
> struct softnet_data *sd;
^ permalink raw reply
* [PATCH] powerpc: Fix build bug with binutils < 2.18 and GCC < 4.2
From: Segher Boessenkool @ 2008-07-21 23:03 UTC (permalink / raw)
To: linuxppc-dev, benh
binutils < 2.18 has a bug that makes it misbehave when taking an
ELF file with all segments at load address 0 as input. This
happens when running "strip" on vmlinux, because of the AT() magic
in this linker script. People using GCC >= 4.2 won't run into
this problem, because the "build-id" support will put some data
into the "notes" segment (at a non-zero load address).
To work around this, we force some data into both the "dummy"
segment and the kernel segment, so the dummy segment will get a
non-zero load address. It's not enough to always create the
"notes" segment, since if nothing gets assigned to it, its load
address will be zero.
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
Tested-By: Milton Miller <miltonm@bga.com>
---
arch/powerpc/kernel/vmlinux.lds.S | 31 ++++++++++++++++++++++++++++---
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 87a72c6..a914411 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -9,6 +9,25 @@
ENTRY(_stext)
+PHDRS {
+ kernel PT_LOAD FLAGS(7); /* RWX */
+ notes PT_NOTE FLAGS(0);
+ dummy PT_NOTE FLAGS(0);
+
+ /* binutils < 2.18 has a bug that makes it misbehave when taking an
+ ELF file with all segments at load address 0 as input. This
+ happens when running "strip" on vmlinux, because of the AT() magic
+ in this linker script. People using GCC >= 4.2 won't run into
+ this problem, because the "build-id" support will put some data
+ into the "notes" segment (at a non-zero load address).
+
+ To work around this, we force some data into both the "dummy"
+ segment and the kernel segment, so the dummy segment will get a
+ non-zero load address. It's not enough to always create the
+ "notes" segment, since if nothing gets assigned to it, its load
+ address will be zero. */
+}
+
#ifdef CONFIG_PPC64
OUTPUT_ARCH(powerpc:common64)
jiffies = jiffies_64;
@@ -50,7 +69,7 @@ SECTIONS
. = ALIGN(PAGE_SIZE);
_etext = .;
PROVIDE32 (etext = .);
- }
+ } :kernel
/* Read-only data */
RODATA
@@ -62,7 +81,13 @@ SECTIONS
__stop___ex_table = .;
}
- NOTES
+ NOTES :kernel :notes
+
+ /* The dummy segment contents for the bug workaround mentioned above
+ near PHDRS. */
+ .dummy : {
+ LONG(0xf177)
+ } :kernel :dummy
/*
* Init sections discarded at runtime
@@ -74,7 +99,7 @@ SECTIONS
_sinittext = .;
INIT_TEXT
_einittext = .;
- }
+ } :kernel
/* .exit.text is discarded at runtime, not link time,
* to deal with references from __bug_table
--
1.5.6.4.gf1ba5
^ permalink raw reply related
* Linux on V4FX100
From: Koss, Mike (Mission Systems) @ 2008-07-21 22:54 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3714 bytes --]
Hopefully beating the bushes in many arenas will help me ellict some
responses.
I have a system on a V4FX100 that is using both PPC405s. Each system is
an exact clone of the other, with some minor variations like how the
other's memory controller is mapped in. (They both can't be mapped to
0x0 :P).
I have a Linux 2.6.22 image (arch/ppc) that I've built that will run on
one and not the other. And by not run, I mean it boots successfully,
gives me a console, I run the applications and then in some point in
time in the near future the system crashes, semi-gracefully. The kernel
crashes and prints out the crash, hence the gracefully part, but its
dead in the water. What can an application that doesn't interface with
any special kernel things do to cause the crash? The applications use
only 'normal' things, no specific drivers (that haven't been completely
tested ;).
If I use a different software load, it runs fine with no problems. In
fact, I currently use it for running and developing other software.
Has anyone seen anything similar when using both PPCs? From what I can
tell it looks like it may be related to timers, but that's only guessing
and inconclusive. I don't have any extra timers (plb/opb/xps_timer)
built into either system.
Thanks,
Mike
Here's the crash output:
Oops: kernel access of bad area, sig: 11 [#1]
NIP: c002c960 LR: c002c960 CTR: 00000000
REGS: c1363d90 TRAP: 0300 Not tainted (2.6.22-rc2-default)
MSR: 00021030 <ME,IR,DR> CR: 48002488 XER: 20000055
DAR: 0000029b, DSISR: 00800000
TASK = c102f7b0[496] 'mmngr.exe' THREAD: c1362000
GPR00: c002c960 c1363e40 c102f7b0 c1363eb0 c01dd9e8 00000000 00000001
00000001
GPR08: 00368044 00000001 c103c580 00000000 e7433f04 10030ea8 ffffffff
ffffffff
GPR16: 7f9d1a04 65786563 10080000 7ff907f0 00000001 00000000 7ff90808
100c09f0
GPR24: 10002830 10015068 c1363f18 c1363eb0 00000000 00000000 0000027b
c1363eb0
NIP [c002c960] __remove_hrtimer+0x3c/0x54
LR [c002c960] __remove_hrtimer+0x3c/0x54
Call Trace:
[c1363e40] [c002c960] __remove_hrtimer+0x3c/0x54 (unreliable)
[c1363e60] [c002c9d8] hrtimer_try_to_cancel+0x60/0x80
[c1363e70] [c002ca14] hrtimer_cancel+0x1c/0x3c
[c1363e80] [c0187af8] do_nanosleep+0x68/0xa4
[c1363ea0] [c002ce70] hrtimer_nanosleep+0x48/0x184
[c1363f10] [c002d044] sys_nanosleep+0x98/0xcc
[c1363f40] [c0002c30] ret_from_syscall+0x0/0x3c
Instruction dump:
90010024 7c9f2378 8004000c 7c7e1b78 7f801800 7cbd2b78 40be000c 480b0fed
907f000c 389f0008 7fc3f378 480b108d <93be0020> 80010024 bba10014
7c0803a6
Oops: kernel access of bad area, sig: 11 [#2]
NIP: c00093bc LR: c00093d0 CTR: c0077d9c
REGS: c01efef0 TRAP: 0300 Not tainted (2.6.22-rc2-default)
MSR: 00029030 <EE,ME,IR,DR> CR: 24000082 XER: 00000055
DAR: 00000027, DSISR: 00000000
TASK = c01db980[0] 'swapper' THREAD: c01ee000
GPR00: 00000000 c01effa0 c01db980 00000000 c00088d4 00000000 c020b414
00000000
GPR08: 00000002 c01ee028 28002448 00000010 8a2c8992 ffffffff ffffffff
ffffffff
GPR16: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff
GPR24: ffffffff ffffffff c0209000 c0200000 00000000 c01ee000 ffffffff
ffffffff
NIP [c00093bc] cpu_idle+0xc0/0xd8
LR [c00093d0] cpu_idle+0xd4/0xd8
Call Trace:
[c01effa0] [c00093d0] cpu_idle+0xd4/0xd8 (unreliable)
[c01effb0] [c0185f5c] rest_init+0x50/0x60
[c01effc0] [c01f09e4] start_kernel+0x2b4/0x2c8
[c01efff0] [c000225c] start_here+0x44/0xb0
Instruction dump:
60008000 7c000124 39200010 381f0028 7d600028 7d6b4b78 7c00022c 7d60012d
40a2fff0 4800000c 7c210b78 7ffffb78 <801f0028> 70090008 4182ff70
7c421378
Kernel panic - not syncing: Attempted to kill the idle task!
Rebooting in 180 seconds..<NULL>
[-- Attachment #2: Type: text/html, Size: 6172 bytes --]
^ permalink raw reply
* Re: bug: mutex_lock() in interrupt conntext via phy_stop() in gianfar
From: Nate Case @ 2008-07-21 22:57 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: netdev, linuxppc-dev, Vitaly Bordug, Li Yang
In-Reply-To: <20080718121008.GA28871@Chamillionaire.breakpoint.cc>
On Fri, 2008-07-18 at 14:10 +0200, Sebastian Siewior wrote:
> Commit 35b5f6b1a aka [PHYLIB: Locking fixes for PHY I/O potentially sleeping]
> changed the phydev->lock from spinlock into a mutex. Now, the following
> code path got triggered while NFS was unavailable:
>
[snip]
> |[ 194.864733] BUG: sleeping function called from invalid context at /home/bigeasy/git/linux-2.6-powerpc/kernel/mutex.c:87
> |[ 194.875529] in_atomic():1, irqs_disabled():0
> |[ 194.879805] Call Trace:
> |[ 194.882250] [c0383d90] [c0006dd8] show_stack+0x48/0x184 (unreliable)
> |[ 194.888649] [c0383db0] [c001e938] __might_sleep+0xe0/0xf4
> |[ 194.894069] [c0383dc0] [c025a43c] mutex_lock+0x24/0x3c
> |[ 194.899234] [c0383de0] [c019005c] phy_stop+0x20/0x70
> |[ 194.904234] [c0383df0] [c018d4ec] stop_gfar+0x28/0xf4
> |[ 194.909305] [c0383e10] [c018e8c4] gfar_timeout+0x30/0x60
> |[ 194.914638] [c0383e20] [c01fe7c0] dev_watchdog+0xa8/0x144
Hmm.. I'm not sure what the best solution is to this. Make the
stop_gfar() call happen in a workqueue, and make a similar change to
ucc_geth, fec_mpc52xx, and fs_enet? Modify phy_stop() to do the work in
a workqueue conditionally if in interrupt context? Between these two
I'd lean toward the latter.
Does anyone have any better ideas?
--
Nate Case <ncase@xes-inc.com>
^ permalink raw reply
* RE: USB-to-ehternet adapter needed...
From: Mike Timmons @ 2008-07-21 22:31 UTC (permalink / raw)
To: Mike Timmons, linuxppc-embedded
In-Reply-To: <161B3BAD77161449A144FF054231C3D60249D4D3@uss-am-xch-01.am.trimblecorp.net>
[-- Attachment #1: Type: text/plain, Size: 848 bytes --]
Found what I was looking for under, "networking". I was mistenly looking
within the USB driver section of menuconfig for USB-to-ethernet drivers.
Movin' on...
________________________________
From: linuxppc-embedded-bounces+mike_timmons=trimble.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+mike_timmons=trimble.com@ozlabs.org]
On Behalf Of Mike Timmons
Sent: Monday, July 21, 2008 2:02 PM
To: linuxppc-embedded@ozlabs.org
Subject: USB-to-ehternet adapter needed...
I'm running kernel 2.6.24 on mpc5200. I need a network interface over
the USB port.
Looking at the kernel; menuconfig I'm not sure if I have what I need to
get a USB-to-ethernet adapter working.
Can anyone advise me on what driver(s) to build, and what brand
USB-to-ethernet adapter I should buy?
Thanks!
-Mike
[-- Attachment #2: Type: text/html, Size: 4580 bytes --]
^ permalink raw reply
* RE: Antwort: RE: Migrating from 2.6.11 to 2.6.23 breaks pci-e
From: Vince Asbridge @ 2008-07-21 22:34 UTC (permalink / raw)
To: joachim.bader
Cc: 'Geary Sean-R60898', 'Dave Maruska',
'Mitul Patel', 'Hynes, Stephen',
linuxppc-embedded, 'Stephen Shirron'
In-Reply-To: <OF1467D773.502FC20D-ONC125748D.00270EDF-C125748D.0027D110@diehl-gruppe.de>
[-- Attachment #1: Type: text/plain, Size: 6070 bytes --]
Joachim,
No, we are stable now once we fixed the bus numbering issue.
Vince
_____
From: joachim.bader@diehl-aerospace.de
[mailto:joachim.bader@diehl-aerospace.de]
Sent: Monday, July 21, 2008 3:15 AM
To: vasbridge@sanblaze.com
Cc: 'Dave Maruska'; linuxppc-embedded@ozlabs.org; 'Mitul Patel'; 'Geary
Sean-R60898'; 'Stephen Shirron'; 'Hynes, Stephen'
Subject: Antwort: RE: Migrating from 2.6.11 to 2.6.23 breaks pci-e
Hello Vince,
we ran into the similar problem using U-boot version 1.1.4 and Linux kernel
2.6.23 on a Freescale MPC8641D platform.
The kernel did not scan all buses and did not recognize the connected pci-e
bridges and devices.
Your mail was very helpfull and due to the information you sent we disabled
CONFIG_PCI in U-boot and now the kernel was able to detect all connected
bridges and devices. But during allocation of the pci-e resources the kernel
runs in an address access violation. We will continue to investigate this
behavior.
Do you have some more information? regarding behavior of newer kernels?
Thank you
Joachim Bader
--
Dipl.-Ing. Joachim Bader
Research & Technology
Cockpit and Display Systems
Diehl Aerospace GmbH
An der Sandelmuehle 13
D-60439 Frankfurt
Phone +49-69-5805-1270
Fax +49-69-5805-1400
e-mail: joachim.bader@diehl-aerospace.de
http://www.diehl-aerospace.de
"Vince Asbridge" <vasbridge@sanblaze.com>
Gesendet von:
linuxppc-embedded-bounces+joachim.bader=diehl-aerospace.de@ozlabs.org
02.07.2008 23:40
An
<linuxppc-embedded@ozlabs.org>, "'Stephen Shirron'" <sshirron@sanblaze.com>,
"'Mitul Patel'" <mpatel@sanblaze.com>, "'Dave Maruska'"
<dmaruska@sanblaze.com>, "'Geary Sean-R60898'" <sean.geary@freescale.com>,
"'Hynes, Stephen'" <Stephen.Hynes@lsi.com>
Kopie
Thema
RE: Migrating from 2.6.11 to 2.6.23 breaks pci-e with LSI 1068 SAS
chip (solved!)
Solved!
Problem summary.
LSI logic devices (1068e, 1064e, fc949e) do not work with uBoot version
1.3.0 and Linux kernel 2.6.23, where they work perfectly fine in kernel
2.6.11.
Symptom is that they do not show up at all to Linux once booted (lspci shows
nothing).
We obtained a pci-e analyzer and found the following:
uBoot V1.3.0 now scans the pci configuration, and when it does it assigns
bus numbers to the pci-e devices it finds. These numbers that are assigned
are different from those that are assigned by Linux when the system boots.
It is legal to change pci-e bus numbers "on the fly" but doing so requires a
config write cycle to the pci-e device, because the pci-e spec states that
the device must register a new bus number if a config write cycle is issues
with the new bus number.
When we boot the Freescale machine with uBoot 1.3.0 and kernel 2.6.23, the
bus number under uBoot gets assigned to 1, and the bus number under Linux
gets assigned to 4. Between the change of bus numbers we do not see a
config write go to the LSI device with the new bus number, and therefore it
continues to respond on bus 1 and ignore config reads to bus 4.
We temporarily fixed the issue by defining the CONFIG_PCI_NOSCAN flag under
uBoot, which causes the LSI device not to get assigned a bus number at
uBoot, and therefore when Linux begins doing config reads at bus 4 to the
LSI device registers the bus number and responds correctly.
We will do a bit more investigation to see if this has already been fixed in
a newer kernel, but for now not scanning at uBoot fixes the issue.
It's a bit of a mystery why the LSI devices behave differently from any
other pci-e device we put in the system, but they seem to be adhering to the
letter of the specification.
Vince Asbridge
------- original post -------
All,
I'm new to this mailing list, but have not had any luck finding information
on this issue.
Please be kind if I break the forum rules on my first post.
We recently tried to upgrade our Freescale CDS 8548 look-alike module (code
name ATCA1000) from the 2.6.11 based BSP to the 2.6.23 based BSP.
The upgrade went fairly smoothly, until we tried using SOME pci-e devices
(some work fine, some don't show up to lspci).
LSI pci-e controllers no longer show up at all!
We see the ixgbe (intel 10G), SiliconImage SATA controller but do not see
LSI devices (Specifically 1068 SAS, FC949-E fibrechannel).
We're guessing it's a resource issue behind the bridge, because the LSI
devices try to allocate 1 - 3M behind the bridge, but we can't find the bug,
or where we would debug such an issue.
The devices seem to "train" correctly, because we have an LED on the pci-e
switch (PLX 8 port pci-e switch), and it's ON indicating pci-e link between
the bridge and the 1068 device).
We're totally at a loss as to why this always worked on the 2.6.11 kernel
but doesn't work on 2.6.23.
Using lspci, the LSI adapters do not show up in the list at all, as though
they are not plugged into the system.
Is there something that needs to be done with respect to PCI-E devices that
is new in the 2.6.23 based BSP that did not need to be done in the 2.6.11
based kit? For example, are pci resources allocated by a different piece of
code, that may have some issue allocating resources for the LSI adapters?
I currently do not have access to a pci-e analyzer.
Thanks for any help,
Vince Asbridge
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
____________________________________________________________________________
___________________________________________
Der Inhalt dieser E-Mail ist fC
Informieren Sie uns bitte, wenn Sie diese E-Mail fC$lschlicherweise erhalten
haben (Fax: +49-69-5805-1399). Bitte lC6schen Sie in diesem Fall die
Nachricht. Jede Form der weiteren Benutzung ist untersagt.
The content of this e-mail is not legally binding upon the sender.
If this e-mail was transmitted to you by error, then please inform us
accordingly (Fax: +49-69-5805-1399). In such case you are requested to erase
the message. Any use of such e-mail message is strictly prohibited.
[-- Attachment #2: Type: text/html, Size: 9966 bytes --]
^ permalink raw reply
* Re: Mikrotik RouterBoard 333
From: Segher Boessenkool @ 2008-07-21 22:13 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080721211344.GA13268@loki.buserror.net>
>> Other than that quibble, I agree that burning the blob into the
>> firmware
>> so that the firmware must be recompiled and reburned to change the
>> blob
>> is very undesirable.
>
> I thought the device tree was *supposed* to be an interface between the
> firmware and the kernel? What if the firmware produces the tree
> dynamically? What if the firmware itself depends on having the device
> tree
> in order to operate?
Sure. But in the case where the firmware just passes the
kernel some fixed blob, it is easier for everyone to include
that blob with the kernel instead.
Segher
^ permalink raw reply
* Re: Mikrotik RouterBoard 333
From: Scott Wood @ 2008-07-21 21:13 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev
In-Reply-To: <487AA17E.6000808@gmail.com>
On Sun, Jul 13, 2008 at 08:44:46PM -0400, Jerry Van Baren wrote:
> I'm a half-ack. ;-) I'm partial to u-boot's implementation rather than
> using a bootwrapper for obvious reasons. The u-boot implementation
> takes the blob as a boot parameter and passes it along to the kernel
> after doing appropriate (optional) fixups.
And if those fixups expect a malformed device tree?
> Other than that quibble, I agree that burning the blob into the firmware
> so that the firmware must be recompiled and reburned to change the blob
> is very undesirable.
I thought the device tree was *supposed* to be an interface between the
firmware and the kernel? What if the firmware produces the tree
dynamically? What if the firmware itself depends on having the device tree
in order to operate?
-Scott
^ permalink raw reply
* Re: PIXIS gpio controller and gpio flags
From: Trent Piepho @ 2008-07-21 21:12 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080721175357.GA1773@polina.dev.rtsoft.ru>
On Mon, 21 Jul 2008, Anton Vorontsov wrote:
> On Sat, Jul 19, 2008 at 02:08:01PM -0700, Trent Piepho wrote:
>> It doesn't look like you have any way to unset the active low flag. What if
>> I unload the leds-gpio driver (or another gpio user) and then try to use the
>> gpio with something else? The active low flag is stuck on!
>
> Why would you want to unset the flags? It is specified in the device
> tree, and can't be changed. Specifying different flags for the same GPIO
> would be an error (plus, Linux forbids shared gpios, so you simply can't
> specify one gpio for several devices).
You can't use the same gpio for two different things at the same time, but you
can load a driver, unload it, and then load another.
>> Most gpio users, including leds-gpio, can handle gpios being busy. If
>> leds-gpio can't get one of the gpios, it rolls back all the leds it did
>> create, doesn't drive the device and returns EBUSY. Except with
>> of_get_gpio() setting the flags, it will change the flags out from under
>> whatever had the gpio already allocated!
>
> You're still assuming that something was allocated. It wasn't. The flag
> was set, and it should not change. It is irrelevant if request() failed
> or not.
Another driver has requested the gpio with active low NOT set. Then the led
driver looks up the property with active low set, which changes the flags.
When it tries to request the gpio it fails since the gpio is already in use.
The led driver handles this failure. Except the active low flag is now set
and the driver that was using the gpio before will now mysteriously stop
working. Perhaps by erasing flash instead of reading it or something nasty
like that.
Is this the proper way to handle a dts mistake that has two drivers trying to
use the same gpio? Without the gpio flags getting set when looking up the
gpio, this situation is handled without any difficulty.
And is having a gpio used twice in the device tree really a mistake? What if
there are two different devices that can be attached to the gpios? For
example, an LED bank that can be unplugged and a serial console attached in
its place, sharing the same connector and gpios. Other than gpio flags
getting set when looking up a gpio, it works fine to list both devices in the
device tree as long as userspace has the correct driver loaded first.
^ permalink raw reply
* Problem with cuImage Linux entry from old U-boot
From: Stephen Horton @ 2008-07-21 20:39 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 8742 bytes --]
Hello folks,
As I have posted recently before, in a current work project, I have
inherited a compactPCI board that has an mpc7447/7448 powerpc processor
as well as a Marvell system controller, model mv64462 (stripped down
mv64460). The board has a somewhat working Gentoo Linux port running on
it from long ago and a company far far away (kernel version 2.6.9 built
using arch/ppc). To prepare for an upcoming deployment, I would like to
bring the OS up-to-date on this board with a newer kernel (targeting
2.6.24r3).
I have made great strides with help from this mailing list and its
archives. I now have a compiled cuImage ready to boot from my older
working u-boot 1.1.2. I now seem to be stuck at the kernel entry point.
I'm not sure if I'm trying to jump into the kernel at the wrong address,
or if I have a serial console issue that prevents me from seeing anymore
progress. Here is my output:
debug> bootm
## Booting image at 00800000 ...
Image Name: Linux-2.6.24-gentoo-r3
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1515921 Bytes = 1.4 MB
Load Address: 00400000
Entry Point: 0040095c
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Transferring control to Linux (at address 0040095c) ...
Memory <- <0x0 0x10000000> (256MB)
ENET0: local-mac-address <- 00:a0:d6:62:38:89
CPU clock-frequency <- 0x3b9ac9d8 (1000MHz)
CPU timebase-frequency <- 0x27bc86a (42MHz)
CPU bus-frequency <- 0x9ef21aa (167MHz)
zImage starting: loaded at 0x00400000 (sp: 0x0febfa38)
Allocating 0x35f040 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040d000:0x00735db0)...done 0x312b34 bytes
Linux/PowerPC load: ip=bootp root=/dev/nfs rw nfsroot=/opt/gentoo
console=ttyMM0,9600n8
Finalizing device tree... flat tree at 0x7423a0
------
If I run 'nm' on my elf image, I expect to find some entry point address
that corresponds to 0x7423a0, but this is not the case. See nm output
below. Does anyone know what I might be doing wrong?
[root@blade3 boot]# nm cuImage.giganew.elf
00736060 b alloc_min
00736058 b alloc_tbl
00400838 T backwards_memcpy
0073606c b bd
00736000 b bridge_base
00736000 A __bss_start
00736010 b chr1
00736014 b chr2
0040aadc d cmdline
00741ee0 B console_ops
00404620 t copy_val
00736018 b cpcr
00736004 b cpld_base
004060f4 t cpm1_cmd
00406174 t cpm2_cmd
00736028 b cpm_cmd
00405d84 T cpm_console_init
00406440 t cpm_serial_getc
00406334 t cpm_serial_open
004062c0 t cpm_serial_putc
00405d3c t cpm_serial_tstc
00405c60 T cuboot_init
00741c14 b cxt
0040a1e4 d dbase.1092
0040a1a4 d dext.1093
0073603c b disable_port
00741d30 b discard_buf.1378
00409922 d distfix.1169
004022e8 T __div64_32
00736034 b do_cmd
0040c098 A _dtb_end
0040ace0 A _dtb_start
00404c38 T dt_fixup_clock
00404cbc T dt_fixup_cpu_clocks
00404aec T dt_fixup_mac_address
00404b7c T __dt_fixup_mac_addresses
00404dec T dt_fixup_memory
00404500 T dt_get_reg_format
00404584 T dt_is_compatible
00741ef4 B dt_ops
00404684 t dt_xlate
00404a00 T dt_xlate_addr
00404a80 T dt_xlate_reg
00736000 A _edata
00736038 b enable_port
00742000 A _end
00408c98 A _etext
00400108 t exit
00401640 t exit
00402420 t exit
004044c4 t exit
00401cac t fdtm_create_node
00401c10 t fdtm_finalize
00401de4 t fdtm_finddevice
00401c54 t fdtm_find_node_by_prop_value
00401cf4 t fdtm_get_parent
00401bc0 t fdtm_get_path
00401d8c t fdtm_getprop
00401d34 t fdtm_setprop
00400000 t finddevice
00401e28 t finddevice
0040430c t finddevice
004050b8 t find_node_by_devtype
004000b0 t find_node_by_prop_value
0040446c t find_node_by_prop_value
0040092c T flush_cache
004073ac T ft_add_rsvmap
004077d4 T ft_begin
00408024 T ft_begin_node
004078b0 T ft_begin_tree
004080c4 T ft_create_node
004072d8 T ft_del_prop
004069b0 T ft_end_node
00406b7c T ft_end_tree
00407428 T ft_find_descendent
004075ec T ft_find_device
004079f0 T __ft_find_node_by_prop_value
00407af8 T ft_find_node_by_prop_value
00407b88 T __ft_get_parent
00407c74 T ft_get_parent
004078c4 T ft_get_path
00406890 t ft_get_phandle
00406ab4 t __ft_get_prop
00406e4c T ft_get_prop
00401b24 T ft_init
00406f48 t ft_make_space
004069d4 t ft_next
0040690c t ft_node_ph2node
00406938 t ft_node_update_after
004081b4 T ft_nop
00407674 T ft_open
00407cdc T ft_prop
00407f84 T ft_prop_int
00407fc8 T ft_prop_str
00406edc t ft_put_bin
00407e44 T ft_set_prop
00406c78 t ft_shuffle
00404414 t get_parent
00400058 t getprop
00401e80 t getprop
00404364 t getprop
00404fec t getprop
004057e8 t getprop
00405ce4 t getprop
0040820c t getprop
0040023c t giganew_fixups
00400530 t giganew_reset
0040aadc D __got2_end
0040a6e0 D __got2_start
004025dc T gunzip_discard
00402574 T gunzip_exactly
0040251c T gunzip_finish
0040245c T gunzip_partial
0040264c T gunzip_start
007364a4 b gzstate
00408804 T inflate_fast
00736000 A _initrd_end
00736000 A _initrd_start
0040a262 d lbase.1090
004099a2 d lenfix.1168
0040a224 d lext.1091
00741eb0 B loader_info
004008dc T memchr
00400904 T memcmp
00400780 T memcpy
00400778 T memmove
0040071c T memset
0040650c T mpc5200_psc_console_init
00736008 b mpsc_base
004058e8 T mpsc_console_init
00405a68 t mpsc_getc
00405840 t mpsc_get_virtreg_of_phandle
0073600c b mpscintr_base
00405b64 t mpsc_open
00405ae4 t mpsc_putc
00405c14 t mpsc_tstc
00736030 b muram_offset
0073602c b muram_start
0040520c T mv64x60_cfg_read
004052f8 T mv64x60_cfg_write
00405288 T mv64x60_config_cpu2pci_window
004055cc T mv64x60_config_ctlr_windows
00405408 T mv64x60_config_pci_windows
0040a4a4 d mv64x60_cpu2mem
0040a6a0 D mv64x60_cpu2pci_io
0040a6c0 D mv64x60_cpu2pci_mem
0040a59c d mv64x60_dram_selects
0040a5ac d mv64x60_enet2mem
00405134 T mv64x60_get_bridge_base
004051a0 T mv64x60_get_bridge_pbase
0040536c T mv64x60_get_mem_size
0040a60c d mv64x60_idma2mem
00405044 T mv64x60_is_coherent
0040a5dc d mv64x60_mpsc2mem
0040a564 d mv64x60_pci2mem
0040a584 d mv64x60_pci2reg
0040a4d4 d mv64x60_pci_acc
0040a63c d mv64x60_pci_cfgio
00736064 b next_base
00406980 t next_start
004082c0 T ns16550_console_init
004083f0 t ns16550_getc
00408264 t ns16550_open
00408464 t ns16550_putc
00408394 t ns16550_tstc
00400abc t number
004098fc d order.1221
0073601c b param
00402854 T parse_elf32
004027b4 T parse_elf64
00400144 T platform_init
00741ec4 B platform_ops
w _platform_stack_top
004014c8 T printf
00741db0 b prop_buf
00736048 b psc
00406614 t psc_getc
004064b0 t psc_open
004065b8 t psc_putc
004064c0 t psc_tstc
00736040 B rbdf
0073604c b reg_base
00736050 b reg_base
00736054 b reg_shift
00736024 b scc
00406258 t scc_disable_port
004061f0 t scc_enable_port
00741d1c b serial_cd
00401f84 t serial_close
00401fd4 T serial_console_init
004021a8 t serial_edit_cmdline
00401ed8 t serial_open
00401f20 t serial_write
004015e8 t setprop
004043bc t setprop
0040868c T simple_alloc_init
004085d4 t simple_find_entry
00408658 t simple_free
004084d0 t simple_malloc
00408754 t simple_realloc
00400a78 t skip_atoi
00736020 b smc
0040608c t smc_disable_port
00406024 t smc_enable_port
00736068 b space_left
007360a4 b sprint_buf
00401574 T sprintf
0040167c T start
00400000 A _start
0040aadc A __start___builtin_cmdline
0040acdc A __stop___builtin_cmdline
0040066c T strcat
00400698 T strchr
004006b8 T strcmp
00400628 T strcpy
00400704 T strlen
004006dc T strncmp
00400644 T strncpy
00400a44 T strnlen
00736044 B tbdf
0073605c b tbl_entries
0040a69c D timebase_period_ns
004066c4 T uartlite_console_init
004067d0 t uartlite_getc
00406678 t uartlite_open
00406834 t uartlite_putc
00406784 t uartlite_tstc
00402384 T udelay
004023b0 t .udelay_not_601
00735db0 A _vmlinux_end
0040d000 A _vmlinux_start
00400dd4 T vsprintf
00400968 W _zimage_start
00400968 T _zimage_start_lib
00400958 T _zimage_start_opd
004028f4 t zlib_adler32
00402dc0 T zlib_inflate
00402bb4 T zlib_inflateEnd
00402cf8 T zlib_inflateIncomp
00402b1c T zlib_inflateInit2
00402a90 T zlib_inflateReset
00403dd4 T zlib_inflate_table
00402a7c T zlib_inflate_workspacesize
00402be0 t zlib_updatewindow
[-- Attachment #2: Type: text/html, Size: 42482 bytes --]
^ permalink raw reply
* Re: going to OLS?
From: Sean MacLennan @ 2008-07-21 20:24 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <fa686aa40807211315x56d15c2cocbaa17bc16d46de3@mail.gmail.com>
On Mon, 21 Jul 2008 14:15:53 -0600
"Grant Likely" <grant.likely@secretlab.ca> wrote:
> BTW, if anyone else wants to receive the contact phone list, then send
> me your phone number ASAP. I'll be sending it out this evening.
My home phone number is 613-728-1680.
Cheers,
Sean
^ 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