* Re: regarding mvme6100 on kernel 2.6.13
From: Brent Cook @ 2006-05-30 15:12 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Kiran Kumar.A
In-Reply-To: <20060530140929.88FBD3384B@ws7-3.us4.outblaze.com>
On Tuesday 30 May 2006 09:09, Kiran Kumar.A wrote:
> Hi all,
>
> I'm porting mvme6100 for 2.6.13.
> But its hanging after "Now Booting the kernel.."
>
> Can anybody guide me in this regard.
>
> thanks and regards
Eh, it's probably not hanging at all - you're just not seeing anything because
the device naming scheme changed and the serial console not getting
initialized correctly. Be sure that in your platform_notify function has
a '.' in the platform device name - this was added around 2.6.11 or so.
An example from another board I have:
static int xes_mv64x60_platform_notify(struct device *dev)
{
static struct {
char *bus_id;
void ((*rtn) (struct platform_device * pdev));
} dev_map[] = {
#ifdef CONFIG_SERIAL_MPSC
{
MPSC_CTLR_NAME ".0", xes_mv64x60_fixup_mpsc_pdata}, {
MPSC_CTLR_NAME ".1", xes_mv64x60_fixup_mpsc_pdata},
#endif
}
Also, be sure to enable early boot messages - they help a lot. Also, don't
overlook setting console=ttyMM0,9600 in the kernel args.
- Brent
^ permalink raw reply
* Re: Setting I&D cache enable in the same mtspr instruction
From: Mark A. Greer @ 2006-05-30 18:27 UTC (permalink / raw)
To: Roger Larsson; +Cc: linuxppc-embedded
In-Reply-To: <200605291415.14908.roger.larsson@norran.net>
On Mon, May 29, 2006 at 02:15:14PM +0200, Roger Larsson wrote:
> Is the patch reversed?
Sure looks like it.
> diff -Naur old new > patch
>
> And what about comments, are they all still valid?
> "enable and invalidate caches" is now only Data cache...
>
> In cases when I am writing code like this I try to
> include the reason why it is not "optimized" together
> in one write... (or soon someone will do that optimization).
Good point.
> /RogerL
Also, please send the patches *inline*.
Mark
^ permalink raw reply
* [PATCH] fix of_parse_dma_window. was: Re: [PATCH 1/2] powerpc: Add of_parse_dma_window()
From: Will Schmidt @ 2006-05-30 18:38 UTC (permalink / raw)
To: Olof Johansson, jk; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060518231306.GG8220@pb15.lixom.net>
On Thu, 2006-05-18 at 18:13 -0500, Olof Johansson wrote:
> On Fri, May 19, 2006 at 01:11:51AM +0200, Segher Boessenkool wrote:
> > > Acked-by: Olof Johansson <olof@lixom.net>
> > >
> > > (I'm assuming you've booted it on POWER4 LPAR and JS20, I don't
> > > have access to either to make sure it doesn't break there. Main worry
> > > would be if it lacked ibm,#dma*-properties for some reason.)
> >
> > The code seems to be resilient against that. Haven't tested though.
>
> Well, yes. I should have said: if it lacks the ibm,#dma- and the
> normal addr-cells properties aren't the same as we assumed before.
My js20 appears to lack the ibm,#dma- properties, and boot fails with a
"Kernel panic - not syncing: iommu_init_table: Can't allocate 0 bytes"
message.
This adds a fallback to the "#address-cells" property in case the
"#ibm,dma-address-cells" property is missing. Tested on js20 and
power5 lpar.
Unless there is a more elegant solution... :-)
Signed-off-by: Will Schmidt <willschm@us.ibm.com>
diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse.c
index 23bb060..45df420 100644
--- a/arch/powerpc/kernel/prom_parse.c
+++ b/arch/powerpc/kernel/prom_parse.c
@@ -561,6 +561,9 @@ void of_parse_dma_window(struct device_n
*busno = *(dma_window++);
prop = get_property(dn, "ibm,#dma-address-cells", NULL);
+ if (!prop)
+ prop = get_property(dn, "#address-cells", NULL);
+
cells = prop ? *(u32 *)prop : prom_n_addr_cells(dn);
*phys = of_read_addr(dma_window, cells);
^ permalink raw reply related
* Re: [PATCH 1/2] powerpc: Add of_parse_dma_window()
From: Kumar Gala @ 2006-05-30 18:55 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev
In-Reply-To: <1147933251.463191.267166640873.qpush@pokey>
On May 18, 2006, at 1:20 AM, Jeremy Kerr wrote:
> Add a function for generic parsing of dma-window properties (ie,
> ibm,dma-window and ibm,my-dma-window) of pci and virtual device nodes.
>
> This function will also be used by cell.
Any possibly of renaming this to of_parse_ibm_dma_window() since it
handle an IBM specific attribute?
- kumar
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
>
> arch/powerpc/kernel/prom_parse.c | 23 +++++++++++++++++++++++
> include/asm-powerpc/prom.h | 6 ++++++
> 2 files changed, 29 insertions(+)
>
> Index: linux-2.6/arch/powerpc/kernel/prom_parse.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/kernel/prom_parse.c
> +++ linux-2.6/arch/powerpc/kernel/prom_parse.c
> @@ -548,3 +548,26 @@ int of_pci_address_to_resource(struct de
> return __of_address_to_resource(dev, addrp, size, flags, r);
> }
> EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
> +
> +void of_parse_dma_window(struct device_node *dn, unsigned char
> *dma_window_prop,
> + unsigned long *busno, unsigned long *phys, unsigned long *size)
> +{
> + u32 *dma_window, cells;
> + unsigned char *prop;
> +
> + dma_window = (u32 *)dma_window_prop;
> +
> + /* busno is always one cell */
> + *busno = *(dma_window++);
> +
> + prop = get_property(dn, "ibm,#dma-address-cells", NULL);
> + cells = prop ? *(u32 *)prop : prom_n_addr_cells(dn);
> + *phys = of_read_addr(dma_window, cells);
> +
> + dma_window += cells;
> +
> + prop = get_property(dn, "ibm,#dma-size-cells", NULL);
> + cells = prop ? *(u32 *)prop : prom_n_size_cells(dn);
> + *size = of_read_addr(dma_window, cells);
> +}
> +EXPORT_SYMBOL_GPL(of_parse_dma_window);
> Index: linux-2.6/include/asm-powerpc/prom.h
> ===================================================================
> --- linux-2.6.orig/include/asm-powerpc/prom.h
> +++ linux-2.6/include/asm-powerpc/prom.h
> @@ -230,6 +230,12 @@ extern int of_address_to_resource(struct
> extern int of_pci_address_to_resource(struct device_node *dev, int
> bar,
> struct resource *r);
>
> +/* Parse the ibm,dma-window property of an OF node into the busno,
> phys and
> + * size parameters.
> + */
> +void of_parse_dma_window(struct device_node *dn, unsigned char
> *dma_window_prop,
> + unsigned long *busno, unsigned long *phys, unsigned long *size);
> +
> extern void kdump_move_device_tree(void);
>
> #endif /* __KERNEL__ */
>
> To: linuxppc-dev@ozlabs.org
> From: Jeremy Kerr <jk@ozlabs.org>
> Date: Thu, 18 May 2006 16:20:51 +1000
> Subject: [PATCH 2/2] powerpc: pseries: Use generic dma-window
> parsing function
> Message-Id: <1147933251.472945.297063284077.qpush@pokey>
>
> Change the pseries iommu init code to use the new
> of_parse_dma_window()
> to parse the ibm,dma-window and ibm,my-dma-window properties of pci
> and
> virtual device nodes.
>
> Also, clean up vio_build_iommu_table() a little.
>
> Tested on pseries, with both vio and pci devices.
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
>
> arch/powerpc/platforms/pseries/iommu.c | 29 +++++++++
> +-------------------
> arch/powerpc/platforms/pseries/vio.c | 32 +++++++++++++
> +------------------
> 2 files changed, 24 insertions(+), 37 deletions(-)
>
> Index: linux-2.6/arch/powerpc/platforms/pseries/iommu.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/platforms/pseries/iommu.c
> +++ linux-2.6/arch/powerpc/platforms/pseries/iommu.c
> @@ -299,30 +299,22 @@ static void iommu_table_setparms(struct
> * iommu_table_setparms_lpar
> *
> * Function: On pSeries LPAR systems, return TCE table info, given
> a pci bus.
> - *
> - * ToDo: properly interpret the ibm,dma-window property. The
> definition is:
> - * logical-bus-number (1 word)
> - * phys-address (#address-cells words)
> - * size (#cell-size words)
> - *
> - * Currently we hard code these sizes (more or less).
> */
> static void iommu_table_setparms_lpar(struct pci_controller *phb,
> struct device_node *dn,
> struct iommu_table *tbl,
> - unsigned int *dma_window)
> + unsigned char *dma_window)
> {
> + unsigned long offset, size;
> +
> tbl->it_busno = PCI_DN(dn)->bussubno;
> + of_parse_dma_window(dn, dma_window, &tbl->it_index, &offset, &size);
>
> - /* TODO: Parse field size properties properly. */
> - tbl->it_size = (((unsigned long)dma_window[4] << 32) |
> - (unsigned long)dma_window[5]) >> PAGE_SHIFT;
> - tbl->it_offset = (((unsigned long)dma_window[2] << 32) |
> - (unsigned long)dma_window[3]) >> PAGE_SHIFT;
> tbl->it_base = 0;
> - tbl->it_index = dma_window[0];
> tbl->it_blocksize = 16;
> tbl->it_type = TCE_PCI;
> + tbl->it_offset = offset >> PAGE_SHIFT;
> + tbl->it_size = size >> PAGE_SHIFT;
> }
>
> static void iommu_bus_setup_pSeries(struct pci_bus *bus)
> @@ -414,7 +406,7 @@ static void iommu_bus_setup_pSeriesLP(st
> struct iommu_table *tbl;
> struct device_node *dn, *pdn;
> struct pci_dn *ppci;
> - unsigned int *dma_window = NULL;
> + unsigned char *dma_window = NULL;
>
> DBG("iommu_bus_setup_pSeriesLP, bus %p, bus->self %p\n", bus, bus-
> >self);
>
> @@ -422,7 +414,7 @@ static void iommu_bus_setup_pSeriesLP(st
>
> /* Find nearest ibm,dma-window, walking up the device tree */
> for (pdn = dn; pdn != NULL; pdn = pdn->parent) {
> - dma_window = (unsigned int *)get_property(pdn, "ibm,dma-window",
> NULL);
> + dma_window = get_property(pdn, "ibm,dma-window", NULL);
> if (dma_window != NULL)
> break;
> }
> @@ -516,7 +508,7 @@ static void iommu_dev_setup_pSeriesLP(st
> {
> struct device_node *pdn, *dn;
> struct iommu_table *tbl;
> - int *dma_window = NULL;
> + unsigned char *dma_window = NULL;
> struct pci_dn *pci;
>
> DBG("iommu_dev_setup_pSeriesLP, dev %p (%s)\n", dev, pci_name(dev));
> @@ -531,8 +523,7 @@ static void iommu_dev_setup_pSeriesLP(st
>
> for (pdn = dn; pdn && PCI_DN(pdn) && !PCI_DN(pdn)->iommu_table;
> pdn = pdn->parent) {
> - dma_window = (unsigned int *)
> - get_property(pdn, "ibm,dma-window", NULL);
> + dma_window = get_property(pdn, "ibm,dma-window", NULL);
> if (dma_window)
> break;
> }
> Index: linux-2.6/arch/powerpc/platforms/pseries/vio.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/platforms/pseries/vio.c
> +++ linux-2.6/arch/powerpc/platforms/pseries/vio.c
> @@ -108,32 +108,28 @@ __initcall(vio_bus_init_pseries);
> */
> static struct iommu_table *vio_build_iommu_table(struct vio_dev *dev)
> {
> - unsigned int *dma_window;
> - struct iommu_table *newTceTable;
> - unsigned long offset;
> - int dma_window_property_size;
> + unsigned char *dma_window;
> + struct iommu_table *tbl;
> + unsigned long offset, size;
>
> - dma_window = (unsigned int *) get_property(dev-
> >dev.platform_data, "ibm,my-dma-window", &dma_window_property_size);
> - if(!dma_window) {
> + dma_window = get_property(dev->dev.platform_data,
> + "ibm,my-dma-window", NULL);
> + if (!dma_window)
> return NULL;
> - }
>
> - newTceTable = (struct iommu_table *) kmalloc(sizeof(struct
> iommu_table), GFP_KERNEL);
> + tbl = (struct iommu_table *)kmalloc(sizeof(*tbl), GFP_KERNEL);
>
> - /* There should be some code to extract the phys-encoded offset
> - using prom_n_addr_cells(). However, according to a comment
> - on earlier versions, it's always zero, so we don't bother */
> - offset = dma_window[1] >> PAGE_SHIFT;
> + of_parse_dma_window(dev->dev.platform_data, dma_window,
> + &tbl->it_index, &offset, &size);
>
> /* TCE table size - measured in tce entries */
> - newTceTable->it_size = dma_window[4] >> PAGE_SHIFT;
> + tbl->it_size = size >> PAGE_SHIFT;
> /* offset for VIO should always be 0 */
> - newTceTable->it_offset = offset;
> - newTceTable->it_busno = 0;
> - newTceTable->it_index = (unsigned long)dma_window[0];
> - newTceTable->it_type = TCE_VB;
> + tbl->it_offset = offset >> PAGE_SHIFT;
> + tbl->it_busno = 0;
> + tbl->it_type = TCE_VB;
>
> - return iommu_init_table(newTceTable);
> + return iommu_init_table(tbl);
> }
>
> /**
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 4/10]Powerpc: Add tsi108 pic support
From: Kumar Gala @ 2006-05-30 19:18 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: Yang Xin-Xin-r48390, Paul Mackerras, Alexandre.Bounine,
linuxppc-dev list
In-Reply-To: <9FCDBA58F226D911B202000BDBAD467306585F22@zch01exm40.ap.freescale.net>
On May 29, 2006, at 10:28 PM, Zang Roy-r61911 wrote:
>>
>> On Wed, 2006-05-17 at 18:14 +0800, Zang Roy-r61911 wrote:
>>> Add Tundra Semiconductor tsi108 host bridge interrupt
>> controller support.
>>
>> It looks a bit like an hacked up MPIC... Is it different
>> enough to justify a separate driver ? Or would it be possible
>> to define a TSI108 flag to pass the current mpic driver and
>> add the necessary bits to it ?
>>
>
> Tsi108 implementation of MPIC has many differences form the
> original one, the following
> code implements it with mpic. Any comment? The following patch is
> just based on
> my previous send out patches.
In the future please provide it against the base, much easier to read.
> Integrate Tundra Semiconductor tsi108 host bridge interrupt controller
> to mpic arch.
>
> Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
>
[snip]
>
> --- linux-2.6.17-rc4-tun/arch/powerpc/sysdev/mpic.c 2006-03-20
> 00:53:29.000000000 -0500
> +++ linux-2.6.17-rc4-hpc2/arch/powerpc/sysdev/mpic.c 2006-05-29
> 16:07:03.000000000 -0400
> @@ -81,7 +81,7 @@ static inline void _mpic_write(unsigned
> static inline u32 _mpic_ipi_read(struct mpic *mpic, unsigned int ipi)
> {
> unsigned int be = (mpic->flags & MPIC_BIG_ENDIAN) != 0;
> - unsigned int offset = MPIC_GREG_IPI_VECTOR_PRI_0 + (ipi * 0x10);
> + unsigned int offset = MPIC_GREG_IPI_VECTOR_PRI_0 + (ipi *
> MPIC_GREG_IPI_STRIDE);
>
> if (mpic->flags & MPIC_BROKEN_IPI)
> be = !be;
> @@ -90,7 +90,7 @@ static inline u32 _mpic_ipi_read(struct
>
> static inline void _mpic_ipi_write(struct mpic *mpic, unsigned int
> ipi, u32 value)
> {
> - unsigned int offset = MPIC_GREG_IPI_VECTOR_PRI_0 + (ipi * 0x10);
> + unsigned int offset = MPIC_GREG_IPI_VECTOR_PRI_0 + (ipi *
> MPIC_GREG_IPI_STRIDE);
>
> _mpic_write(mpic->flags & MPIC_BIG_ENDIAN, mpic->gregs, offset,
> value);
> }
> @@ -393,7 +393,11 @@ static inline struct mpic * mpic_from_ir
> static inline void mpic_eoi(struct mpic *mpic)
> {
> mpic_cpu_write(MPIC_CPU_EOI, 0);
> +#ifndef CONFIG_TSI108_BRIDGE
> (void)mpic_cpu_read(MPIC_CPU_WHOAMI);
> +#else
> + (void)mpic_cpu_read(MPIC_CPU_OUTPUT);
> +#endif
> }
>
> #ifdef CONFIG_SMP
> @@ -514,9 +518,26 @@ static void mpic_end_irq(unsigned int ir
> }
> #endif /* CONFIG_MPIC_BROKEN_U3 */
>
> +#ifdef CONFIG_TSI108_BRIDGE
> + if ((irq_desc[irq].status & IRQ_LEVEL) != 0)
> +#endif
Why do you have to check if its a LEVEL irq?
> mpic_eoi(mpic);
> }
>
> +#ifdef CONFIG_TSI108_BRIDGE
> +static void mpic_ack_irq(unsigned int irq)
> +{
> + struct mpic *mpic = mpic_from_irq(irq);
> +
> +#ifdef DEBUG_IRQ
> + DBG("%s: ack_irq: %d\n", mpic->name, irq);
> +#endif
> +
> + if ((irq_desc[irq].status & IRQ_LEVEL) == 0)
> + mpic_eoi(mpic);
> +}
> +#endif /* CONFIG_TSI108_BRIDGE */
> +
if the PIC works like other openpic's you dont need an 'ack' we
handle it via 'end'
> #ifdef CONFIG_SMP
>
> static void mpic_enable_ipi(unsigned int irq)
> @@ -596,6 +617,9 @@ struct mpic * __init mpic_alloc(unsigned
> mpic->hc_irq.enable = mpic_enable_irq;
> mpic->hc_irq.disable = mpic_disable_irq;
> mpic->hc_irq.end = mpic_end_irq;
> +#ifdef CONFIG_TSI108_BRIDGE
> + mpic->hc_irq.ack = mpic_ack_irq;
> +#endif
> if (flags & MPIC_PRIMARY)
> mpic->hc_irq.set_affinity = mpic_set_affinity;
> #ifdef CONFIG_SMP
> @@ -955,8 +979,13 @@ void mpic_send_ipi(unsigned int ipi_no,
> DBG("%s: send_ipi(ipi_no: %d)\n", mpic->name, ipi_no);
> #endif
>
> +#ifndef CONFIG_TSI108_BRIDGE
> mpic_cpu_write(MPIC_CPU_IPI_DISPATCH_0 + ipi_no * 0x10,
> mpic_physmask(cpu_mask & cpus_addr(cpu_online_map)[0]));
> +#else /* CONFIG_TSI108_BRIDGE */
> + mpic_write(mpic->gregs, MPIC_CPU_IPI_DISPATCH,
> + mpic_physmask(cpu_mask & cpus_addr(cpu_online_map)[0]));
> +#endif /* !CONFIG_TSI108_BRIDGE */
> }
>
> int mpic_get_one_irq(struct mpic *mpic, struct pt_regs *regs)
> @@ -972,11 +1001,20 @@ int mpic_get_one_irq(struct mpic *mpic,
> DBG("%s: cascading ...\n", mpic->name);
> #endif
> irq = mpic->cascade(regs, mpic->cascade_data);
> +#ifdef DEBUG_LOW
> + DBG("%s: cascaded irq: %d\n", mpic->name, irq);
> +#endif
> +#ifndef CONFIG_TSI108_BRIDGE
> mpic_eoi(mpic);
> +#endif
> return irq;
> }
> - if (unlikely(irq == MPIC_VEC_SPURRIOUS))
> + if (unlikely(irq == MPIC_VEC_SPURRIOUS)) {
> +#ifdef CONFIG_TSI108_BRIDGE
> + mpic_eoi(mpic);
> +#endif
> return -1;
> + }
why the changes to where we do mpic_eoi for TSI108?
> if (irq < MPIC_VEC_IPI_0) {
> #ifdef DEBUG_IRQ
> DBG("%s: irq %d\n", mpic->name, irq + mpic->irq_offset);
[snip]
^ permalink raw reply
* Re: [patch] fix RTC/NVRAM accesses on Maple
From: Hollis Blanchard @ 2006-05-30 19:21 UTC (permalink / raw)
To: jfaslist; +Cc: linuxppc-dev
In-Reply-To: <447C4D4F.2020808@yahoo.fr>
[resend from the correct email address]
On Tue, 2006-05-30 at 15:49 +0200, jfaslist wrote:
> > Hollis' latest patch is needed still. We agreed not to solve it
> > completely correctly yet, as we'll need more surgery in other parts
> > of the PowerPC kernel first.
> I am trying to apply it on a 2.6.16.18 kernel but the two hunks of it
> are rejected. Any specific version to use?
You could look at the file to see why you're getting rejects. The patch
wasn't committed until 26 May, and 2.6.16.18 was released on 22 May, so
it's more likely you've done something on your side like try to apply
the patch twice (e.g. the original version and then the final version).
-Hollis
^ permalink raw reply
* execve of /sbin/init fails
From: Anantharaman Chetan-W16155 @ 2006-05-30 19:59 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 951 bytes --]
Hi,
I am trying to bring up a custom board with a PPC405 processor running
Linux 2.4.20 (MontaVista Release) and am having problems with the call
to execve("/sbin/init", argv_init, envp_init) not returning in the file
main.c. The processor just hangs and there is no output on the terminal.
I have tried to see if I can run "bin/sh" and even this execve call does
not return. Some things about the board are, the networking option has
been disabled in the Linux .config file. I am running U-Boot 1.1.1 as
the bootloader and am downloading the uImage (compressed kernel) and the
initrd.boot (filesystem) into RAM and accessing the filesystem in RAM.
Any help as to what could be causing this to happen or how to debug this
issue would be appreciated. Also, I've tried to capture the return value
of the execve call but since the call does not return, this has not
helped any.
Thanks,
Chetan Anantharaman
[-- Attachment #2: Type: text/html, Size: 3069 bytes --]
^ permalink raw reply
* Re: Can't get CoralP drivers to work
From: Wolfgang Denk @ 2006-05-30 20:32 UTC (permalink / raw)
To: jourdan; +Cc: linuxppc-embedded
In-Reply-To: <1664.194.3.133.184.1148981963.squirrel@webmail.enib.fr>
In message <1664.194.3.133.184.1148981963.squirrel@webmail.enib.fr> you wrote:
>
> This is the first time I try to use framebuffer graphics, so I'm new with
> it. Can the framebuffer work from a serial console on a platform without
> keyboard ?
Yes, it can. We used it on a couple of MPC5200 systems; usually these
were used without keyboard.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
On a clear disk you can seek forever.
^ permalink raw reply
* Re: [PATCH] Provide mechanism for editing builtin command-line in zImage binary.
From: Mark A. Greer @ 2006-05-30 20:41 UTC (permalink / raw)
To: mostrows; +Cc: linuxppc-dev
In-Reply-To: <11489544631499-git-send-email-mostrows@watson.ibm.com>
On Mon, May 29, 2006 at 10:01:03PM -0400, mostrows@watson.ibm.com wrote:
> zImage will store the builtin command-line in a dedicated section, allowing
> it to be easily identified and edited with user-space tools.
>
> zImage will set /chosen/bootargs to the stored builtin command-line setting,
> if /chosen/bootargs is empty (emulating the behavior in prom_init.c).
>
> Use of this mechanism avoids the need to modify firmware or rely on a
> bootloader to customize kernel arguments (and overall system
> behavior). The command line can be edited as needed when a zImage is
> copied to a TFTP staging area for download by firmware.
Why do this? Why not get rid of storing the cmdline in the zImage altogether?
We already have equivalent functionality by storing it in the dt's
/chosen/bootargs so why this unnecessary complexity?
Add some code to edit the /chosen/bootargs at zImage runtime (just like
arch/ppc used to) and we're covered. AFAICT, we're already adding a tool
to tack on flat dt's to an already existing zImage so you're not doing
anything we can't--or won't--do already.
Agree?
Mark
^ permalink raw reply
* Re: MPC8270 on Microsys PM827 Kernel 2.6 Oops: kernel access of bad area, sig: 11 [#1]
From: Wolfgang Denk @ 2006-05-30 20:43 UTC (permalink / raw)
To: Behre, Frederik - LT; +Cc: linuxppc-embedded
In-Reply-To: <CC692F5386B0AA47A62B7484A7CA2B6D02B52CB0@frmx1.litef.de>
In message <CC692F5386B0AA47A62B7484A7CA2B6D02B52CB0@frmx1.litef.de> you wrote:
>
> I compile my kernel with
> pm82x_deconfig and PCI disabled.
...
> MPC8260 Reset Status: External Soft, External Hard
Why do you use pm82x_deconfig with a MPC8260 processor? You should
use pm826_deconfig instead.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
That's the thing about people who think they hate computers. What
they really hate is lousy programmers.
- Larry Niven and Jerry Pournelle in "Oath of Fealty"
^ permalink raw reply
* Re: execve of /sbin/init fails
From: Jeff.Fellin @ 2006-05-30 20:54 UTC (permalink / raw)
To: Chetan.S.Anantharaman
Cc: linuxppc-embedded-bounces+jeff.fellin=rflelect.com,
linuxppc-embedded
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgIkFuYW50aGFy
YW1hbiBDaGV0YW4tVzE2MTU1IiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAg
ICAgICAgICAgICAgICAgICA8Q2hldGFuLlMuQW5hbnRoYXJhbWFuQG1vdG9yb2xhLmNvbT4gICAg
ICAgICAgICAgICAgICAgICAgVG86ICAgICAgIDxsaW51eHBwYy1lbWJlZGRlZEBvemxhYnMub3Jn
PiAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIFNlbnQgYnk6ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjYzogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAg
ICAgICAgICAgICAgbGludXhwcGMtZW1iZWRkZWQtYm91bmNlcytqZWZmLmZlbGxpbj1yZmxlbGVj
dC5jb20gICAgICAgIFN1YmplY3Q6ICBleGVjdmUgb2YgL3NiaW4vaW5pdCBmYWlscyAgICAgICAg
ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICBAb3psYWJzLm9yZyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAg
ICAwNS8zMC8yMDA2IDE1OjU5ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN
Cg0KDQoNCg0KDQoNCg0KDQo+SGksDQo+SSBhbSB0cnlpbmcgdG8gYnJpbmcgdXAgYSBjdXN0b20g
Ym9hcmQgd2l0aCBhIFBQQzQwNSBwcm9jZXNzb3IgcnVubmluZw0KTGludXggMi40LjIwIChNb250
YVZpc3RhIFJlbGVhc2UpIGFuZCBhbSA+aGF2aW5nIHByb2JsZW1zIHdpdGggdGhlIGNhbGwgdG8N
CmV4ZWN2ZSjigJwvc2Jpbi9pbml04oCdLCBhcmd2X2luaXQsIGVudnBfaW5pdCkgbm90IHJldHVy
bmluZyBpbiB0aGUgZmlsZQ0KbWFpbi5jLiBUaGUgcHJvY2Vzc29yID5qdXN0IGhhbmdzIGFuZCB0
aGVyZSBpcyBubyBvdXRwdXQgb24gdGhlIHRlcm1pbmFsLiBJDQpoYXZlIHRyaWVkIHRvIHNlZSBp
ZiBJIGNhbiBydW4g4oCcYmluL3No4oCdIGFuZCBldmVuIHRoaXMgZXhlY3ZlIGNhbGwgZG9lcyA+
bm90DQpyZXR1cm4uIFNvbWUgdGhpbmdzIGFib3V0IHRoZSBib2FyZCBhcmUsIHRoZSBuZXR3b3Jr
aW5nIG9wdGlvbiBoYXMgYmVlbg0KZGlzYWJsZWQgaW4gdGhlIExpbnV4IC5jb25maWcgZmlsZS4g
SSBhbSA+cnVubmluZyBVLUJvb3QgMS4xLjEgYXMgdGhlDQpib290bG9hZGVyIGFuZCBhbSBkb3du
bG9hZGluZyB0aGUgdUltYWdlIChjb21wcmVzc2VkIGtlcm5lbCkgYW5kIHRoZQ0KaW5pdHJkLmJv
b3QgPihmaWxlc3lzdGVtKSBpbnRvIFJBTSBhbmQgYWNjZXNzaW5nIHRoZSBmaWxlc3lzdGVtIGlu
IFJBTS4NCiBDaGV0YW4sIEkgd291bGQgY2hlY2sgdGhlIGNvbnRlbnRzIG9mIHRoZSBpbml0cmQg
ZmlsZXN5c3RlbSB5b3UgY3JlYXRlZCB0bw0KdmVyaWZ5IHRoZSBmaWxlcyBhcmUgaW4gdGhlIGlt
YWdlLiBJZiB0aGV5IGFyZSBtb25pdG9yIHRoZSBjb25zb2xlIG91dHB1dA0KdG8gdmVyZml5IHRo
ZSByYW1kaXNrIGZpbGVzeXN0ZW0gaXMgZm91bmQgYW5kIGluc3RhbGxlZCBpbnRvIHJhbS4NCkpl
ZmYgRmVsbGluDQoNCj5BbnkgaGVscCBhcyB0byB3aGF0IGNvdWxkIGJlIGNhdXNpbmcgdGhpcyB0
byBoYXBwZW4gb3IgaG93IHRvIGRlYnVnIHRoaXMNCmlzc3VlIHdvdWxkIGJlIGFwcHJlY2lhdGVk
LiBBbHNvLCBJ4oCZdmUgdHJpZWQgPnRvIGNhcHR1cmUgdGhlIHJldHVybiB2YWx1ZQ0Kb2YgdGhl
IGV4ZWN2ZSBjYWxsIGJ1dCBzaW5jZSB0aGUgY2FsbCBkb2VzIG5vdCByZXR1cm4sIHRoaXMgaGFz
IG5vdCBoZWxwZWQNCmFueS4NCg0KVGhhbmtzLA0KQ2hldGFuIEFuYW50aGFyYW1hbg0KDQogX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkxpbnV4cHBjLWVt
YmVkZGVkIG1haWxpbmcgbGlzdA0KTGludXhwcGMtZW1iZWRkZWRAb3psYWJzLm9yZw0KaHR0cHM6
Ly9vemxhYnMub3JnL21haWxtYW4vbGlzdGluZm8vbGludXhwcGMtZW1iZWRkZWQNCg==
^ permalink raw reply
* Re: [PATCH] powerpc: add dmesg command to xmon
From: Linas Vepstas @ 2006-05-30 16:58 UTC (permalink / raw)
To: Olaf Hering; +Cc: Andrew Morton, linuxppc-dev, Linus Torvalds, Arnd Bergmann
In-Reply-To: <20060529175834.GA31082@suse.de>
On Mon, May 29, 2006 at 07:58:34PM +0200, Olaf Hering wrote:
> On Sun, May 28, Arnd Bergmann wrote:
>
> > On Sunday 28 May 2006 14:07, Olaf Hering wrote:
> > > > This whole function looks fishy to me. It seems unnecessarily rude to me to
> > > > use kallsyms_lookup_name in order to get at a static variable from another
> > > > file. Can't you instead add a global function to kernel/printk.c to return
> > > > the buffer?
> > >
> > > Its possible, but it wont end up in Linus tree.
> >
> > Hmm, so the idea is that because Linus doesn't like kernel debuggers, we just
> > obfuscate the code for any improvements to xmon and hope he doesn't notice?
>
> So lets just ask again for support in generic code for a dmesg command in xmon:
>
> http://lkml.org/lkml/2004/10/28/32
I'd been planning to pester Torvalds/LKML on a regular basis until the
patch (or something else suitable) went in. Clearly, I'd failed to do
this.
--linas
p.s. Belated apologies for failing to mention KDB; I assumed it would be
"obvious" to those who know, and that by not mentioning KDB explicitly,
I thought that the patch would have a better chance of acceptance (which
I expected to be low). Silly me.
^ permalink raw reply
* Re: [PATCH] Provide mechanism for editing builtin command-line in zImage binary.
From: Michal Ostrowski @ 2006-05-30 21:12 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060530204151.GA31567@mag.az.mvista.com>
On Tue, 2006-05-30 at 13:41 -0700, Mark A. Greer wrote:
> On Mon, May 29, 2006 at 10:01:03PM -0400, mostrows@watson.ibm.com wrote:
> > zImage will store the builtin command-line in a dedicated section, allowing
> > it to be easily identified and edited with user-space tools.
> >
> > zImage will set /chosen/bootargs to the stored builtin command-line setting,
> > if /chosen/bootargs is empty (emulating the behavior in prom_init.c).
> >
> > Use of this mechanism avoids the need to modify firmware or rely on a
> > bootloader to customize kernel arguments (and overall system
> > behavior). The command line can be edited as needed when a zImage is
> > copied to a TFTP staging area for download by firmware.
> Why do this? Why not get rid of storing the cmdline in the zImage altogether?
>
The CONFIG_CMDLINE that we have now is very useful if I want the
behavior of the system to be dependent on the kernel/command line I
specify that it used (particularly in BOOTP/TFTP scenarios). For such
systems I configure their firmware to not provide any arguments and to
always download via TFTP a designated kernel image.
What this scenario does, is it allows me to specify system behavior by
putting the right kernel with the right command line in the magic
location from where it will be downloaded.
The problem is, that if I have some large number of machines and I want
to use the same kernel for all of them (and simply change the command
line between them) then I have to effectively build a custom kernel for
each. This patch allows me to build one kernel and then simply edit the
command line embedded within it.
The key point is that the command line changes and I don't want to have
to require a firmware interaction every time I change it.
> We already have equivalent functionality by storing it in the dt's
> /chosen/bootargs so why this unnecessary complexity?
>
> Add some code to edit the /chosen/bootargs at zImage runtime (just like
> arch/ppc used to) and we're covered.
That is what this patch is doing.
> AFAICT, we're already adding a tool
> to tack on flat dt's to an already existing zImage so you're not doing
> anything we can't--or won't--do already.
>
Can you please point me at this code so that I can evaluate it in
detail?
I'm curious how the tacked-on dt is expected to interact with the real
FW dt, and in particular how you would expect the interrogation
of /chosen/bootargs in prom_init.c (using prom_getprop()) to pick up the
command line value I specify in the tacked-on dt.
--
Michal Ostrowski <mostrows@watson.ibm.com>
^ permalink raw reply
* Re: execve of /sbin/init fails
From: Andy Gospodarek @ 2006-05-30 21:15 UTC (permalink / raw)
To: Anantharaman Chetan-W16155; +Cc: linuxppc-embedded
In-Reply-To: <EDF27F298D4B03498AE0C249A941DFF803D6DE@de01exm68.ds.mot.com>
You could also try compiling init statically. I've had success with
that in the past until I figured out what the actual problem was.
On 5/30/06, Anantharaman Chetan-W16155
<Chetan.S.Anantharaman@motorola.com> wrote:
>
>
>
>
> Hi,
>
> I am trying to bring up a custom board with a PPC405 processor running Linux
> 2.4.20 (MontaVista Release) and am having problems with the call to
> execve("/sbin/init", argv_init, envp_init) not returning in the file main.c.
> The processor just hangs and there is no output on the terminal. I have
> tried to see if I can run "bin/sh" and even this execve call does not
> return. Some things about the board are, the networking option has been
> disabled in the Linux .config file. I am running U-Boot 1.1.1 as the
> bootloader and am downloading the uImage (compressed kernel) and the
> initrd.boot (filesystem) into RAM and accessing the filesystem in RAM.
>
>
>
> Any help as to what could be causing this to happen or how to debug this
> issue would be appreciated. Also, I've tried to capture the return value of
> the execve call but since the call does not return, this has not helped any.
>
>
>
> Thanks,
>
> Chetan Anantharaman
>
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* Re: execve of /sbin/init fails
From: Steve Iribarne (GMail) @ 2006-05-30 21:29 UTC (permalink / raw)
To: Anantharaman Chetan-W16155; +Cc: linuxppc-embedded
In-Reply-To: <EDF27F298D4B03498AE0C249A941DFF803D6DE@de01exm68.ds.mot.com>
On 5/30/06, Anantharaman Chetan-W16155
<Chetan.S.Anantharaman@motorola.com> wrote:
>
>
>
>
> Hi,
>
> I am trying to bring up a custom board with a PPC405 processor running Linux
> 2.4.20 (MontaVista Release) and am having problems with the call to
> execve("/sbin/init", argv_init, envp_init) not returning in the file main.c.
Hmm.. Ok.. so I've read the other suggestions all good, but I think we
are missing some info. Are you running Busybox? If you are using
Busybox, what version? Also, what init are you using? Are you using
busyboxes?
The ramdisk suggestion was a good one. First off, check what is in
your ramdisk. Also check the rights of the files in the ramdisk.
Make sure you have the execute bit set. I've seen exactly what you
are seeing when my rights on the file init were messed up.
Also I think I've seen a hang with an older version of Busybox using
their version of init. I just got sysinit and that seemed to fix it,
(Although I had to reconfig Busybox to not use their version of init)
> The processor just hangs and there is no output on the terminal.
When you say the process just "hangs", where are you in the boot
cycle? Is it before you see the linux kernel starting to load? Or do
you see any kernel messages start to spew out?
Hope this helps a little.
-stv
^ permalink raw reply
* Re: fs_enet segfaults when adding network interface to bridge
From: Andy Fleming @ 2006-05-30 21:54 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200605301539.55319.laurent.pinchart@tbox.biz>
On May 30, 2006, at 08:39, Laurent Pinchart wrote:
>>> Hi everybody,
>>>
>>> I ran into a segfault in the fs_enet driver when adding the network
>>> interface to an ethernet bridge. This only happens when the
>>> interface is
>>> down.
>>>
>>> ----- Kernel version -----
>>> Linux tbox-cp11 2.6.17-rc3-g7f02f290-dirty #549 Tue May 30
>>> 13:25:37 CEST
>>> 2006 ppc unknown
>>> (from main linux-2.6 git repository)
>>> ----- End of kernel version -----
>>>
>>> ----- Oops report -----
>>> Oops: kernel access of bad area, sig: 11 [#1]
>>> NIP: C0109884 LR: C010D420 CTR: 00000000
>>> REGS: c027d7f0 TRAP: 0300 Tainted: P (2.6.17-rc3-
>>> g7f02f290-dirty)
>>> MSR: 00009032 <EE,ME,IR,DR> CR: 24000222 XER: 00000000
>>> DAR: 00000140, DSISR: 20000000
>>> TASK = c0851090[42] 'brctl' THREAD: c027c000
>>> GPR00: C010D414 C027D8A0 C0851090 00000000 C027D8D0 FFFFFFFF
>>> F00000A0
>>> EFFFFFFF GPR08: C026E380 C0210000 00000000 C0230000 C0210000
>>> 1001D150
>>> 00FFE000 00000001 GPR16: FFFFFFFF 00000000 007FFF00 7FDD0AC0
>>> 00000000
>>> 10072C94 7FDD0AD8 10072CA4 GPR24: 00000000 10000A48 00000000
>>> C027D8D0
>>> C027D8D0 C08A1A60 C027DC50 C08A1800 NIP [C0109884]
>>> phy_ethtool_gset+0x0/0x48
>>> LR [C010D420] fs_get_settings+0x34/0x48
>>> Call Trace:
>>> [C027D8A0] [C010D414] fs_get_settings+0x28/0x48 (unreliable)
>>> [C027D8C0] [C013DDC0] dev_ethtool+0x9bc/0x13c8
>>> [C027DC40] [C018CBC0] port_cost+0x58/0x108
>>> [C027DCB0] [C018D3E8] br_add_if+0x174/0x2f4
>>> [C027DCE0] [C018D9AC] add_del_if+0x94/0x98
>>> [C027DD00] [C018DD68] br_dev_ioctl+0x70/0xae4
>>> [C027DE00] [C013B42C] dev_ifsioc+0x17c/0x404
>>> [C027DE20] [C013BA4C] dev_ioctl+0x398/0x4e8
>>> [C027DEB0] [C012EEFC] sock_ioctl+0x154/0x220
>>> [C027DEE0] [C0067164] do_ioctl+0x88/0x9c
>>> [C027DEF0] [C0067230] vfs_ioctl+0xb8/0x3f0
>>> [C027DF10] [C00675A8] sys_ioctl+0x40/0x74
>>> [C027DF40] [C00040E0] ret_from_syscall+0x0/0x38
>>> Instruction dump:
>>> 7c0803a6 4e800020 2f800000 409eff78 4bffffb8 8804000e 2b800001
>>> 40bdff70
>>> 3860ffea 4bffffd4 61200040 4bffff84 <81230140> 91240004 80030144
>>> 90040008
>>> ----- End of oops report -----
>>>
>>> ----- Source lines -----
>>> [C0109884] phy_ethtool_gset+0x0/0x48 (drivers/net/phy/phy.c:290)
>>> [C010D414] fs_get_settings+0x28/0x48
>>> (drivers/net/fs_enet/fs_enet-main.c:885) [C013DDC0]
>>> dev_ethtool+0x9bc/0x13c8 (net/core/ethtool.c:122)
>>> [C018CBC0] port_cost+0x58/0x108 (net/bridge/br_if.c:54)
>>> ----- End of source lines -----
>>>
>>> phy_ethtool_gset segfaults when trying to access phydev->supported
>>> because phydev is NULL.
>>>
>>> As I'm not familiar with the fs_enet driver, I'm looking for advices
>>> regarding what to fix and how to fix it.
>>
>> IIRC, fs_enet got bound to phydev only being ->up. So in down
>> state, phydev
>> may be either null, or last assigned (need to have a look into
>> source to
>> tell for certain). So what is the proper behavior from your point
>> of view?
>
> I have no idea :-) What I know is that the driver should not
> segfault when
> asked to report the port speed. Either we should return an error or
> have the
> phy device bound to fs_enet at all time. It might also be a bridge
> issue,
> maybe the bridge code should turn the interface up before reading
> its speed.
> How do other ethernet drivers proceed ?
Well, gianfar only invokes phy_ethtool_gset() after checking to see
that phydev is not NULL. fs_enet should do this as well. It may be
preferable to move that check into phy_ethtool_gset(). Certainly a
workable solution, though I'm inclined to feel that the PHY layer
should be able to assume that a given PHY exists. The sort of
problem also exists if you try to use ethtool to find the ring sizes
before the device has been opened.
Anyway, the easy fix is for fs_enet to check for NULL before calling
phy_ethtool_gset().
Andy
^ permalink raw reply
* Re: Linux kernel thread with Linux 2.6.x
From: Andy Fleming @ 2006-05-30 22:10 UTC (permalink / raw)
To: Laurent Lagrange; +Cc: linuxppc-embedded
In-Reply-To: <000201c68335$7c594b90$5201a8c0@GEG2400>
Couldn't you use a work_queue? For the PHY Layer, the MDIO
transactions can't occur at interrupt time (they need to be
interruptible), so the interrupt handler calls schedule_work() to get
the interrupt handled. I'm not sure how much faster it is (if at
all), but it's another method, and sounds less complicated than
waiting on a semaphore.
Of course, I would suggest trying to avoid the buffer allocation
functions you are using, or defer the work using NAPI, but it's
impossible for me to tell whether that's a reasonable solution for you.
On May 29, 2006, at 10:35, Laurent Lagrange wrote:
>
> Hello everybody,
>
> I'm writing a custom network driver based on a MPC8260 FCC device
> for a
> 2.6.9 linux kernel.
> In this driver, I need to use specific buffer allocation functions
> which use
> down and up semaphore functions.
>
> As the interrupt handler can't be scheduled, I have made a kernel
> thread
> which waits forever on a semaphore.
> This semaphore is set when a received packet interrupt occured. All
> that
> mechanism works but the performances
> are very poor.
>
> Is there any solution to increase the kthread priority in the
> scheduler ?
> Is there another solution than the semaphore to quickly wake up a
> kthread ?
>
> Thanks a lot for your help.
> Laurent
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [RFC/PATCH 0/8] Overhaul of virt IRQ configuration. / Kill ppc64_interrupt_controller.
From: Benjamin Herrenschmidt @ 2006-05-30 22:13 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: linuxppc-dev
In-Reply-To: <1148997289.25048.153.camel@brick>
> A PIC would not need to reserve anything is when it is allocated. Only
> when interrupt numbers need to be presented to generic kernel code is a
> virq number required.
We could have completely sparse allocation indeed and any virt number
matching any PIC but I don't like that too much. Complicates things
unnecessarily don't you think ? I like irq numbers to be somewhat stable
on a given platform :) Helps debugging & diagnosing problems...
> One can use irq_desc->chip_data to easily go from virq -> (PIC, line).
> The PIC then maintains an array to map each of it's lines to virq.
> This allows for all re-mappings to always be arbitrary in nature and
> still allows for O(1) look-up in either direction.
I'll think about it, but I'm really tempted to keep simple ranges for
now... we'll see.
> > - Interrupt 0..15 are reserved. 0 is always invalid. Only ISA PICs that
> > carry legacy devices can request those (by passing a special flag to the
> > allocation routine).
>
> Always create an ISA PIC that immediately requests lines 0..15.
Well, if we use your suggested "sparse" allocation method, then yes, we
need to request them right away before anything else. But I'd like to
start with the range allocation in which case simply reserving that
range for use by whatever PIC says "I'm the legacy ISA PIC" is enough.
> Should one actually exists, we can associate the ISA PIC with the
> appropriate device node. Should ISA devices exist, once they request
> interrupts (using (PIC,line) as arguments) we'll short-circuit virq
> allocation since all ISA PIC mappings already exists.
I'm not sure I understand there. ISA devices don't "request interrupts
using (PCI,line)" or whatever... we don't necessarily know in advance.
Part of the reasoning here is to also make sure that if no ISA PIC
allocated 0...15 then a stupid legacy driver loaded by the user will
fail it's call to request_irq()
> Then there's no need to special case anything (and all other interrupts
> are forced to be remapped out of the 0..15 range, without an explicit
> "offset" concept).
/me is a bit dubious...
> > Any other gets remapped (including powermac MPICs).
> > That will avoid endless problems that we never properly solved with
> > legacy drivers and the fact that Linus decided that 0 should be the
> > invalid interrupt number on all platforms
> >
> > - Provide in prom_parse.c functions for obtaining the PIC node and
> > local interrupt number of a given device based on a passed-in array
> > matching the semantics of an "interrupts" property and a parent node.
> > Along with a helper that may just take a child node. The former is
> > needed for PCI devices that have no device node. Provide a
> > pci_ppc_map_interrupt() that takes a pci_dev and does the interrupt
> > mapping, either by using the standard OF approach if a device-node is
> > present, or walking up the PCI tree while doing standard swizzling until
> > it reaches a device node
>
> How is this different from the current use of map_interrupt() in
> finish_node_interrupts()?
Slightly... basically cleaned up version of it.
> It seems to me that it would be better to have the struct device_node
> store the raw interrupt vector data as presented in the dev tree
> (without remapping) along with a pointer to the struct device_node for
> the appropriate PIC.
I don't understand what you have in mind. Remember we are working with
cases where devices may not have a node. There is no such thing as "an
interrupt == a node" anyway. Beside, I want to _remove_ anything in
struct device_node that isn't specifically the node linkage and property
list. All the pre-parsed junk has to go.
> Later on, when we need to provide interrupt lines to the PCI device
> structures (e.g. pci_read_irq_line()) we have the PIC and the raw
> interrupt vectors identified and we ask the PIC to provide us with a
> kernel/virt IRQ.
Yah, well, in order to have the PIC and the raw IRQ identified, we have
to do the algorithm I described :) Not sure how your scheme differs
except maybe by putting things in the device node itself... We do have a
void * there though we can use for non-PCI devices, thus if the PIC node
is always guaranteed _not_ to be a PCI device, we can use that to get
the PIC quickly but old MPICs are PCI devices afaik, and beside, that is
not a performance critical path.
> Deferring the remapping of the interrupt vectors to this later time
> should allow for some simplification opportunities. All code that
> handles device nodes would not need to deal with offsets or remapping,
I still don't see what you mean here.... the only things that has to
deal with offset and/or remapping are the PIC code itself when it gets
called with virtual numbers and the binding of a device to an irq when
going from the raw number to the virtual number.
> only when IRQ information crosses the boundary between powerpc and
> generic code would one need to be aware of the need to re-map (i.e.
> dev->irq = ??? and ppc_md.get_irq(regs);/ __do_IRQ() interactions ).
> Since arbitrary re-mappings need to be supported, the reservation of
> vectors 0..15 can be hidden as a re-mapping implementation detail.
> Consequently one could eliminate irq_offset_up() and irq_offset_down()
> altogether.
I'm not sure how your scheme differs from what I have in mind at this
point except from the fact that you'll shuffle interrupt numbers way
more than I intend to. I suppose it _might_ be simpler to go through the
virt irq remapper once rather than having both a set of ranges +
eventually the remapper, and I've thought about using the remapper for
everything too, but I'd still like to keep the concept of ranges, thus
I'm tempted to still allocate all irqs for a given controller
continuously in the remapper when instanciating the PIC rather than when
actually looking for IRQs....
Ben.
^ permalink raw reply
* Re: execve of /sbin/init fails
From: Andy Gospodarek @ 2006-05-30 22:15 UTC (permalink / raw)
To: Steve Iribarne (GMail); +Cc: Anantharaman Chetan-W16155, linuxppc-embedded
In-Reply-To: <b4b98b690605301429q4f474ec4g9545005de192e1d6@mail.gmail.com>
On 5/30/06, Steve Iribarne (GMail) <netstv@gmail.com> wrote:
> On 5/30/06, Anantharaman Chetan-W16155
> <Chetan.S.Anantharaman@motorola.com> wrote:
> >
> >
> >
> >
> > Hi,
> >
> > I am trying to bring up a custom board with a PPC405 processor running Linux
> > 2.4.20 (MontaVista Release) and am having problems with the call to
> > execve("/sbin/init", argv_init, envp_init) not returning in the file main.c.
>
>
> Hmm.. Ok.. so I've read the other suggestions all good, but I think we
> are missing some info. Are you running Busybox? If you are using
> Busybox, what version? Also, what init are you using? Are you using
> busyboxes?
>
> The ramdisk suggestion was a good one. First off, check what is in
> your ramdisk. Also check the rights of the files in the ramdisk.
> Make sure you have the execute bit set. I've seen exactly what you
> are seeing when my rights on the file init were messed up.
>
> Also I think I've seen a hang with an older version of Busybox using
> their version of init. I just got sysinit and that seemed to fix it,
> (Although I had to reconfig Busybox to not use their version of init)
>
I guess I totally assumed busybox was being used, so good suggestion.
I too saw this with an older version of busybox (0.60 maybe?) and I
ended up editing the config to contain only init and then compiled it
statically and placed it on the rootfs. It turned out to be just the
right size and functionality for my needs. I think I later updated to
a 1.0 or 1.1-series and didn't have to use the same hack.
>
>
>
> > The processor just hangs and there is no output on the terminal.
>
>
> When you say the process just "hangs", where are you in the boot
> cycle? Is it before you see the linux kernel starting to load? Or do
> you see any kernel messages start to spew out?
>
> Hope this helps a little.
>
> -stv
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* RE: execve of /sbin/init fails
From: Anantharaman Chetan-W16155 @ 2006-05-30 22:16 UTC (permalink / raw)
To: Jeff.Fellin, Steve Iribarne (GMail), adgospod
Cc: linuxppc-embedded-bounces+jeff.fellin=rflelect.com,
linuxppc-embedded
In-Reply-To: <OF32D825BB.6DBF6685-ON8525717E.0072AF23@teal.com>
Thanks for your reply. Yes, the file /sbin/init is in the ramdisk file
system with execute permissions on it. I am running Busybox (how can I
check the version?), but my /sbin/init is not Busybox's init.
One thing I'd like to mention is, I have used the same ramdisk
filesystem and the same version of Linux 2.4 kernel and U-Boot
bootloader and have been able to successfully execute the /sbin/init.
This board has a Xilinx Virtex 2 Pro FPGA with a PPC405. On my new
board, with a Xilinx Virtex 4 FX100 FPGA, with the kernel running on a
PPC405 and the same filesystem, the execve of /sbin/init "hangs". By
hangs, I mean there is no output on the console after the below output
and it does not return (which indicates that it has not encountered an
error of some sort, since execve returns on error only). So, I am not
sure where it is stuck and is there any way to tell where it's stuck at?
Hope this above info and below screen capture provide a bit more
background to the issue.
Below is a capture of the screen output:
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
OCP uart ver 1.6.2 init complete
LSP Revision 42
ikconfig 0.5 with /proc/ikconfig
Starting kswapd
Disabling the Out Of Memory Killer
Journalled Block Device driver loaded
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with no serial options enabled
ttyS00 at 0xfdfff003 (irq =3D 22) is a 16550A
xgpio #0 at 0x50000000 mapped to 0xC5000000
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
Tracer: Initialization complete
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 5104k freed
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Mounted devfs on /dev
Freeing unused kernel memory: 40k init
-----Original Message-----
From: Jeff.Fellin@rflelect.com [mailto:Jeff.Fellin@rflelect.com]=20
Sent: Tuesday, May 30, 2006 3:55 PM
To: Anantharaman Chetan-W16155
Cc: linuxppc-embedded@ozlabs.org;
linuxppc-embedded-bounces+jeff.fellin=3Drflelect.com@ozlabs.org
Subject: Re: execve of /sbin/init fails
=20
"Anantharaman Chetan-W16155"
<Chetan.S.Anantharaman@motorola.com>
To: <linuxppc-embedded@ozlabs.org> =20
Sent by:
cc: =20
=
linuxppc-embedded-bounces+jeff.fellin=3Drflelect.com
Subject: execve of /sbin/init fails =20
@ozlabs.org
=20
=20
05/30/2006 15:59
=20
=20
>Hi,
>I am trying to bring up a custom board with a PPC405 processor running
Linux 2.4.20 (MontaVista Release) and am >having problems with the call
to
execve("/sbin/init", argv_init, envp_init) not returning in the file
main.c. The processor >just hangs and there is no output on the
terminal. I
have tried to see if I can run "bin/sh" and even this execve call does
>not
return. Some things about the board are, the networking option has been
disabled in the Linux .config file. I am >running U-Boot 1.1.1 as the
bootloader and am downloading the uImage (compressed kernel) and the
initrd.boot >(filesystem) into RAM and accessing the filesystem in RAM.
Chetan, I would check the contents of the initrd filesystem you created
to
verify the files are in the image. If they are monitor the console
output
to verfiy the ramdisk filesystem is found and installed into ram.
Jeff Fellin
>Any help as to what could be causing this to happen or how to debug
this
issue would be appreciated. Also, I've tried >to capture the return
value
of the execve call but since the call does not return, this has not
helped
any.
Thanks,
Chetan Anantharaman
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] dtc: add setting of physical boot cpu
From: Michael Neuling @ 2006-05-30 22:31 UTC (permalink / raw)
To: linuxppc-dev, Jon Loeliger
In-Reply-To: <20060518170017.B15E367A6C@ozlabs.org>
dtc always sets the physical boot CPU to 0xfeedbeef. Add a -b option to
set this. Also add warnings when using the wrong property with the
wrong blob version.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Retransmission with updated warnings after discussion with Jimi.
dtc.c | 14 ++++++++++----
dtc.h | 8 +++++---
flattree.c | 16 ++++++++++------
livetree.c | 17 ++++++++++++-----
4 files changed, 37 insertions(+), 18 deletions(-)
Index: dtc/dtc.c
===================================================================
--- dtc.orig/dtc.c
+++ dtc/dtc.c
@@ -95,6 +95,8 @@ static void usage(void)
fprintf(stderr, "\t\tBlob version to produce, defaults to 3 (relevant for dtb\n\t\tand asm output only)\n");
fprintf(stderr, "\t-R <number>\n");
fprintf(stderr, "\t\tMake space for <number> reserve map entries (relevant for \n\t\tdtb and asm output only)\n");
+ fprintf(stderr, "\t-b <number>\n");
+ fprintf(stderr, "\t\tSet the physical boot cpu\n");
fprintf(stderr, "\t-f\n");
fprintf(stderr, "\t\tForce - try to produce output even if the input tree has errors\n");
exit(2);
@@ -113,8 +115,9 @@ int main(int argc, char *argv[])
FILE *outf = NULL;
int outversion = 3;
int reservenum = 1;
+ int boot_cpuid_phys = 0xfeedbeef;
- while ((opt = getopt(argc, argv, "I:O:o:V:R:f")) != EOF) {
+ while ((opt = getopt(argc, argv, "I:O:o:V:R:fb:")) != EOF) {
switch (opt) {
case 'I':
inform = optarg;
@@ -134,6 +137,9 @@ int main(int argc, char *argv[])
case 'f':
force = 1;
break;
+ case 'b':
+ boot_cpuid_phys = strtol(optarg, NULL, 0);
+ break;
default:
usage();
}
@@ -167,7 +173,7 @@ int main(int argc, char *argv[])
if (! bi || ! bi->dt)
die("Couldn't read input tree\n");
- if (! check_device_tree(bi->dt)) {
+ if (! check_device_tree(bi->dt, outversion, boot_cpuid_phys)) {
fprintf(stderr, "Input tree has errors\n");
if (! force)
exit(1);
@@ -185,9 +191,9 @@ int main(int argc, char *argv[])
if (streq(outform, "dts")) {
dt_to_source(outf, bi);
} else if (streq(outform, "dtb")) {
- dt_to_blob(outf, bi, outversion);
+ dt_to_blob(outf, bi, outversion, boot_cpuid_phys);
} else if (streq(outform, "asm")) {
- dt_to_asm(outf, bi, outversion);
+ dt_to_asm(outf, bi, outversion, boot_cpuid_phys);
} else if (streq(outform, "null")) {
/* do nothing */
} else {
Index: dtc/dtc.h
===================================================================
--- dtc.orig/dtc.h
+++ dtc/dtc.h
@@ -178,7 +178,7 @@ struct node *chain_node(struct node *fir
void add_property(struct node *node, struct property *prop);
void add_child(struct node *parent, struct node *child);
-int check_device_tree(struct node *dt);
+int check_device_tree(struct node *dt, int outversion, int boot_cpuid_phys);
/* Boot info (tree plus memreserve information */
@@ -207,8 +207,10 @@ struct boot_info *build_boot_info(struct
/* Flattened trees */
-void dt_to_blob(FILE *f, struct boot_info *bi, int version);
-void dt_to_asm(FILE *f, struct boot_info *bi, int version);
+void dt_to_blob(FILE *f, struct boot_info *bi, int version,
+ int boot_cpuid_phys);
+void dt_to_asm(FILE *f, struct boot_info *bi, int version,
+ int boot_cpuid_phys);
struct boot_info *dt_from_blob(FILE *f);
Index: dtc/flattree.c
===================================================================
--- dtc.orig/flattree.c
+++ dtc/flattree.c
@@ -301,7 +301,8 @@ static struct data flatten_reserve_list(
}
static void make_bph(struct boot_param_header *bph,
struct version_info *vi,
- int reservesize, int dtsize, int strsize)
+ int reservesize, int dtsize, int strsize,
+ int boot_cpuid_phys)
{
int reserve_off;
@@ -324,12 +325,13 @@ static void make_bph(struct boot_param_h
+ dtsize + strsize);
if (vi->flags & FTF_BOOTCPUID)
- bph->boot_cpuid_phys = 0xfeedbeef;
+ bph->boot_cpuid_phys = cpu_to_be32(boot_cpuid_phys);
if (vi->flags & FTF_STRTABSIZE)
bph->size_dt_strings = cpu_to_be32(strsize);
}
-void dt_to_blob(FILE *f, struct boot_info *bi, int version)
+void dt_to_blob(FILE *f, struct boot_info *bi, int version,
+ int boot_cpuid_phys)
{
struct version_info *vi = NULL;
int i;
@@ -355,7 +357,8 @@ void dt_to_blob(FILE *f, struct boot_inf
reservebuf = flatten_reserve_list(bi->reservelist, vi);
/* Make header */
- make_bph(&bph, vi, reservebuf.len, dtbuf.len, strbuf.len);
+ make_bph(&bph, vi, reservebuf.len, dtbuf.len, strbuf.len,
+ boot_cpuid_phys);
fwrite(&bph, vi->hdr_size, 1, f);
@@ -395,7 +398,7 @@ static void dump_stringtable_asm(FILE *f
}
}
-void dt_to_asm(FILE *f, struct boot_info *bi, int version)
+void dt_to_asm(FILE *f, struct boot_info *bi, int version, int boot_cpuid_phys)
{
struct version_info *vi = NULL;
int i;
@@ -434,7 +437,8 @@ void dt_to_asm(FILE *f, struct boot_info
vi->last_comp_version);
if (vi->flags & FTF_BOOTCPUID)
- fprintf(f, "\t.long\t0xdeadbeef\t/*boot_cpuid_phys*/\n");
+ fprintf(f, "\t.long\t%i\t/*boot_cpuid_phys*/\n",
+ boot_cpuid_phys);
if (vi->flags & FTF_STRTABSIZE)
fprintf(f, "\t.long\t_%s_strings_end - _%s_strings_start\t/* size_dt_strings */\n",
Index: dtc/livetree.c
===================================================================
--- dtc.orig/livetree.c
+++ dtc/livetree.c
@@ -456,7 +456,7 @@ static int check_root(struct node *root)
return ok;
}
-static int check_cpus(struct node *root)
+static int check_cpus(struct node *root, int outversion, int boot_cpuid_phys)
{
struct node *cpus, *cpu;
struct property *prop;
@@ -518,8 +518,15 @@ static int check_cpus(struct node *root)
}
}
- if (! bootcpu)
- WARNMSG("No cpu has \"linux,boot-cpu\" property\n");
+ if (outversion < 2) {
+ if (! bootcpu)
+ WARNMSG("No cpu has \"linux,boot-cpu\" property\n");
+ } else {
+ if (bootcpu)
+ WARNMSG("\"linux,boot-cpu\" property is deprecated in blob version 2 or higher\n");
+ if (boot_cpuid_phys == 0xfeedbeef)
+ WARNMSG("physical boot CPU not set. Use -b option to set\n");
+ }
return ok;
}
@@ -697,7 +704,7 @@ static void fixup_phandles(struct node *
fixup_phandles(root, child);
}
-int check_device_tree(struct node *dt)
+int check_device_tree(struct node *dt, int outversion, int boot_cpuid_phys)
{
int ok = 1;
@@ -713,7 +720,7 @@ int check_device_tree(struct node *dt)
return 0;
ok = ok && check_root(dt);
- ok = ok && check_cpus(dt);
+ ok = ok && check_cpus(dt, outversion, boot_cpuid_phys);
ok = ok && check_memory(dt);
ok = ok && check_chosen(dt);
if (! ok)
^ permalink raw reply
* Re: [RFC/PATCH 0/8] Overhaul of virt IRQ configuration. / Kill ppc64_interrupt_controller.
From: Michal Ostrowski @ 2006-05-30 22:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1149027185.9986.46.camel@localhost.localdomain>
On Wed, 2006-05-31 at 08:13 +1000, Benjamin Herrenschmidt wrote:
> > A PIC would not need to reserve anything is when it is allocated. Only
> > when interrupt numbers need to be presented to generic kernel code is a
> > virq number required.
>
> We could have completely sparse allocation indeed and any virt number
> matching any PIC but I don't like that too much. Complicates things
> unnecessarily don't you think ? I like irq numbers to be somewhat stable
> on a given platform :) Helps debugging & diagnosing problems...
>
The fact that the allocation may be sparse does not mean it actually
will be. As long as code expects arbitrary remappings it will have a
degree of robustness; but that does not mean that the mechanism by which
remappings are done cannot instantiate simple mappings. In other words,
I'd like to see the concept of "irq offsets" being banished, but having
re-mapping code be smart enough so that, for example, an MPIC that must
deal with interrupt vectors 0..127 has these vectors made visible to the
system at 16..143.
I think that the current virt irq remapping algorithm would provide you
with exactly this behavior.
> > One can use irq_desc->chip_data to easily go from virq -> (PIC, line).
> > The PIC then maintains an array to map each of it's lines to virq.
> > This allows for all re-mappings to always be arbitrary in nature and
> > still allows for O(1) look-up in either direction.
>
> I'll think about it, but I'm really tempted to keep simple ranges for
> now... we'll see.
>
> > > - Interrupt 0..15 are reserved. 0 is always invalid. Only ISA PICs that
> > > carry legacy devices can request those (by passing a special flag to the
> > > allocation routine).
> >
> > > Any other gets remapped (including powermac MPICs).
> > > That will avoid endless problems that we never properly solved with
> > > legacy drivers and the fact that Linus decided that 0 should be the
> > > invalid interrupt number on all platforms
> > >
> > > - Provide in prom_parse.c functions for obtaining the PIC node and
> > > local interrupt number of a given device based on a passed-in array
> > > matching the semantics of an "interrupts" property and a parent node.
> > > Along with a helper that may just take a child node. The former is
> > > needed for PCI devices that have no device node. Provide a
> > > pci_ppc_map_interrupt() that takes a pci_dev and does the interrupt
> > > mapping, either by using the standard OF approach if a device-node is
> > > present, or walking up the PCI tree while doing standard swizzling until
> > > it reaches a device node
> >
> > How is this different from the current use of map_interrupt() in
> > finish_node_interrupts()?
>
> Slightly... basically cleaned up version of it.
>
> > It seems to me that it would be better to have the struct device_node
> > store the raw interrupt vector data as presented in the dev tree
> > (without remapping) along with a pointer to the struct device_node for
> > the appropriate PIC.
>
> I don't understand what you have in mind. Remember we are working with
> cases where devices may not have a node. There is no such thing as "an
> interrupt == a node" anyway. Beside, I want to _remove_ anything in
> struct device_node that isn't specifically the node linkage and property
> list. All the pre-parsed junk has to go.
>
In cases where we have a struct device_node, the struct device_node
should have a pointer to the PIC (or the PIC's device_node), and the
raw, unmodified interrupt line values. When one wants to present an
irq to generic code, we use the (PIC,line) information from the
device_node to instantiate a virq.
If there is no struct device_node, you still have to come up with a
(PIC,line) pair in order to get a virq.
virt_irq_create_mapping() (or whatever replaces it) should take the
physical line and a PIC identifier/pointer as arguments so that it can
inform the PIC about a mapping it has instantiated (in case we really
have to make an arbitrary re-mapping) and so that it can try to
instantiate an identity or offset-only translation if possible. In the
latter case, the PIC object will tell the remapper what offset range to
use.
> I'm not sure how your scheme differs from what I have in mind at this
> point except from the fact that you'll shuffle interrupt numbers way
> more than I intend to. I suppose it _might_ be simpler to go through the
> virt irq remapper once rather than having both a set of ranges +
> eventually the remapper, and I've thought about using the remapper for
> everything too, but I'd still like to keep the concept of ranges, thus
> I'm tempted to still allocate all irqs for a given controller
> continuously in the remapper when instanciating the PIC rather than when
> actually looking for IRQs....
I think our thoughts on this differ only on the aspect of whether the
remapper is considered to be an arbitrary remapper, a smart
implementation of which results in IRQ being remapped via offsets,
versus multi-level remapping, with offsets first followed by arbitrary
remappings as necessary (and the distinction between offsets and
arbitrary remapping being visible beyond the remapper function).
--
Michal Ostrowski <mostrows@watson.ibm.com>
^ permalink raw reply
* Re: [RFC/PATCH 0/8] Overhaul of virt IRQ configuration. / Kill ppc64_interrupt_controller.
From: Benjamin Herrenschmidt @ 2006-05-30 23:10 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: linuxppc-dev
In-Reply-To: <1149029585.6507.39.camel@brick>
> The fact that the allocation may be sparse does not mean it actually
> will be. As long as code expects arbitrary remappings it will have a
> degree of robustness; but that does not mean that the mechanism by which
> remappings are done cannot instantiate simple mappings. In other words,
> I'd like to see the concept of "irq offsets" being banished, but having
> re-mapping code be smart enough so that, for example, an MPIC that must
> deal with interrupt vectors 0..127 has these vectors made visible to the
> system at 16..143.
>
> I think that the current virt irq remapping algorithm would provide you
> with exactly this behavior.
The current virt irq remapper is not very efficient. It's especially
slow in the critical path of real -> virt translation which is probably
why xics locally has a radix tree version. I suppose we could generalize
that in a "better" remapper using both the array and the radix tree
though.
Offsets sounded like a simpler thing, specially for platforms that don't
need arbitrary remappings, and less code/memory hungry (embedded
platformns would like that for example).
> In cases where we have a struct device_node, the struct device_node
> should have a pointer to the PIC (or the PIC's device_node), and the
> raw, unmodified interrupt line values. When one wants to present an
> irq to generic code, we use the (PIC,line) information from the
> device_node to instantiate a virq.
>
> If there is no struct device_node, you still have to come up with a
> (PIC,line) pair in order to get a virq.
I won't add anything to struct device node. Only remove from it. The
device node is only used initially when binding a given device to an
irq, no need to "cache" that in the struct device node or whatever. The
generic code will provide means for walking the interrupt tree along the
lines I described to obtain a line,PIC pair, which will then be looked
up in a table of PICs so an offset can be obtained or a remapping of
the line into a global virq.
> virt_irq_create_mapping() (or whatever replaces it) should take the
> physical line and a PIC identifier/pointer as arguments so that it can
> inform the PIC about a mapping it has instantiated (in case we really
> have to make an arbitrary re-mapping) and so that it can try to
> instantiate an identity or offset-only translation if possible. In the
> latter case, the PIC object will tell the remapper what offset range to
> use.
Sounds over complicated to me.
> I think our thoughts on this differ only on the aspect of whether the
> remapper is considered to be an arbitrary remapper, a smart
> implementation of which results in IRQ being remapped via offsets,
> versus multi-level remapping, with offsets first followed by arbitrary
> remappings as necessary (and the distinction between offsets and
> arbitrary remapping being visible beyond the remapper function).
Beware of over engineering :)
Ben.
^ permalink raw reply
* Re: fs_enet segfaults when adding network interface to bridge
From: Vitaly Bordug @ 2006-05-31 0:58 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-embedded
In-Reply-To: <C7B65358-8BEF-42E7-A11C-3FBC501BB324@freescale.com>
On Tue, 30 May 2006 16:54:42 -0500
Andy Fleming <afleming@freescale.com> wrote:
>
> On May 30, 2006, at 08:39, Laurent Pinchart wrote:
>
> >>> Hi everybody,
> >>>
> >>> I ran into a segfault in the fs_enet driver when adding the
> >>> network interface to an ethernet bridge. This only happens when
> >>> the interface is
> >>> down.
> >>>
> >>> ----- Kernel version -----
> >>> Linux tbox-cp11 2.6.17-rc3-g7f02f290-dirty #549 Tue May 30
> >>> 13:25:37 CEST
> >>> 2006 ppc unknown
> >>> (from main linux-2.6 git repository)
> >>> ----- End of kernel version -----
> >>>
> >>> ----- Oops report -----
> >>> Oops: kernel access of bad area, sig: 11 [#1]
> >>> NIP: C0109884 LR: C010D420 CTR: 00000000
> >>> REGS: c027d7f0 TRAP: 0300 Tainted: P (2.6.17-rc3-
> >>> g7f02f290-dirty)
> >>> MSR: 00009032 <EE,ME,IR,DR> CR: 24000222 XER: 00000000
> >>> DAR: 00000140, DSISR: 20000000
> >>> TASK = c0851090[42] 'brctl' THREAD: c027c000
> >>> GPR00: C010D414 C027D8A0 C0851090 00000000 C027D8D0 FFFFFFFF
> >>> F00000A0
> >>> EFFFFFFF GPR08: C026E380 C0210000 00000000 C0230000 C0210000
> >>> 1001D150
> >>> 00FFE000 00000001 GPR16: FFFFFFFF 00000000 007FFF00 7FDD0AC0
> >>> 00000000
> >>> 10072C94 7FDD0AD8 10072CA4 GPR24: 00000000 10000A48 00000000
> >>> C027D8D0
> >>> C027D8D0 C08A1A60 C027DC50 C08A1800 NIP [C0109884]
> >>> phy_ethtool_gset+0x0/0x48
> >>> LR [C010D420] fs_get_settings+0x34/0x48
> >>> Call Trace:
> >>> [C027D8A0] [C010D414] fs_get_settings+0x28/0x48 (unreliable)
> >>> [C027D8C0] [C013DDC0] dev_ethtool+0x9bc/0x13c8
> >>> [C027DC40] [C018CBC0] port_cost+0x58/0x108
> >>> [C027DCB0] [C018D3E8] br_add_if+0x174/0x2f4
> >>> [C027DCE0] [C018D9AC] add_del_if+0x94/0x98
> >>> [C027DD00] [C018DD68] br_dev_ioctl+0x70/0xae4
> >>> [C027DE00] [C013B42C] dev_ifsioc+0x17c/0x404
> >>> [C027DE20] [C013BA4C] dev_ioctl+0x398/0x4e8
> >>> [C027DEB0] [C012EEFC] sock_ioctl+0x154/0x220
> >>> [C027DEE0] [C0067164] do_ioctl+0x88/0x9c
> >>> [C027DEF0] [C0067230] vfs_ioctl+0xb8/0x3f0
> >>> [C027DF10] [C00675A8] sys_ioctl+0x40/0x74
> >>> [C027DF40] [C00040E0] ret_from_syscall+0x0/0x38
> >>> Instruction dump:
> >>> 7c0803a6 4e800020 2f800000 409eff78 4bffffb8 8804000e 2b800001
> >>> 40bdff70
> >>> 3860ffea 4bffffd4 61200040 4bffff84 <81230140> 91240004 80030144
> >>> 90040008
> >>> ----- End of oops report -----
> >>>
> >>> ----- Source lines -----
> >>> [C0109884] phy_ethtool_gset+0x0/0x48 (drivers/net/phy/phy.c:290)
> >>> [C010D414] fs_get_settings+0x28/0x48
> >>> (drivers/net/fs_enet/fs_enet-main.c:885) [C013DDC0]
> >>> dev_ethtool+0x9bc/0x13c8 (net/core/ethtool.c:122)
> >>> [C018CBC0] port_cost+0x58/0x108 (net/bridge/br_if.c:54)
> >>> ----- End of source lines -----
> >>>
> >>> phy_ethtool_gset segfaults when trying to access phydev->supported
> >>> because phydev is NULL.
> >>>
> >>> As I'm not familiar with the fs_enet driver, I'm looking for
> >>> advices regarding what to fix and how to fix it.
> >>
> >> IIRC, fs_enet got bound to phydev only being ->up. So in down
> >> state, phydev
> >> may be either null, or last assigned (need to have a look into
> >> source to
> >> tell for certain). So what is the proper behavior from your point
> >> of view?
> >
> > I have no idea :-) What I know is that the driver should not
> > segfault when
> > asked to report the port speed. Either we should return an error
> > or have the
> > phy device bound to fs_enet at all time. It might also be a bridge
> > issue,
> > maybe the bridge code should turn the interface up before reading
> > its speed.
> > How do other ethernet drivers proceed ?
>
>
> Well, gianfar only invokes phy_ethtool_gset() after checking to see
> that phydev is not NULL. fs_enet should do this as well. It may be
> preferable to move that check into phy_ethtool_gset(). Certainly a
> workable solution, though I'm inclined to feel that the PHY layer
> should be able to assume that a given PHY exists. The sort of
> problem also exists if you try to use ethtool to find the ring sizes
> before the device has been opened.
>
> Anyway, the easy fix is for fs_enet to check for NULL before calling
> phy_ethtool_gset().
>
Andy,
Thanks for pointing it out, I was just going to seek into gianfar
behavior.
That issue seems not the only problem - there are plenty of cases I
saw, where if initially PHY got failed to be bound, fs_enet seems to
be really unhappy with phydev == NULL and direct dereferences of the
latter.
I'll try to address that stuff as time permits...
-Vitaly
^ permalink raw reply
* Re: [PATCH] fix of_parse_dma_window. was: Re: [PATCH 1/2] powerpc: Add of_parse_dma_window()
From: Jeremy Kerr @ 2006-05-31 4:17 UTC (permalink / raw)
To: will_schmidt; +Cc: linuxppc-dev
In-Reply-To: <1149014320.23168.11.camel@localhost.localdomain>
> Unless there is a more elegant solution... :-)
>
> Signed-off-by: Will Schmidt <willschm@us.ibm.com>
Ack, for a temporary fix. I'm working on a nicer solution at the moment.
Jeremy
^ 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