* Re: fs_enet segfaults when adding network interface to bridge
From: Vitaly Bordug @ 2006-05-30 13:27 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200605301351.11967.laurent.pinchart@tbox.biz>
On Tue, 30 May 2006 13:51:11 +0200
Laurent Pinchart <laurent.pinchart@tbox.biz> 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?
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [Alsa-devel] [RFC 4/7] snd-aoa: add codecs
From: Takashi Iwai @ 2006-05-30 13:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <1148995575.4372.5.camel@johannes>
At Tue, 30 May 2006 15:26:10 +0200,
Johannes Berg wrote:
>
> > > > > + return 1;
> > > >
> > > > The put callback is supposed to return 0 if the values are unchanged
> > > > (although most apps ignore the return value).
> > >
> > > Does it have to? This way there's an event, but...
> >
> > Yes, in principle. As mentioned, it works even without the check,
> > though.
>
> Hmm. I thought it worked like this:
> 0 -> no change
> 1 -> change applied, and other apps are notified, 0 returned to the app
> -err -> error returned to app
>
> Is that wrong?
It's correct.
And I thought the put callbacks in your code always return either 1 or
-err?
Takashi
^ permalink raw reply
* Re: fs_enet segfaults when adding network interface to bridge
From: Laurent Pinchart @ 2006-05-30 13:39 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <20060530172700.198bba36@vitb.ru.mvista.com>
> > 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 ?
Laurent Pinchart
^ permalink raw reply
* Re: [Alsa-devel] [RFC 4/7] snd-aoa: add codecs
From: Johannes Berg @ 2006-05-30 13:39 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <s5hmzczbpps.wl%tiwai@suse.de>
[-- Attachment #1: Type: text/plain, Size: 394 bytes --]
On Tue, 2006-05-30 at 15:35 +0200, Takashi Iwai wrote:
> And I thought the put callbacks in your code always return either 1 or
> -err?
Yeah, they return 1 if the change was applied (or no change) and -err if
there's an error about the change (only in very few cases).
I figured the extra notification wouldn't hurt, and to the application
there wouldn't be a problem.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [Alsa-devel] [RFC 4/7] snd-aoa: add codecs
From: Takashi Iwai @ 2006-05-30 13:48 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <1148996349.4372.7.camel@johannes>
At Tue, 30 May 2006 15:39:09 +0200,
Johannes Berg wrote:
>
> On Tue, 2006-05-30 at 15:35 +0200, Takashi Iwai wrote:
>
> > And I thought the put callbacks in your code always return either 1 or
> > -err?
>
> Yeah, they return 1 if the change was applied (or no change) and -err if
> there's an error about the change (only in very few cases).
>
> I figured the extra notification wouldn't hurt, and to the application
> there wouldn't be a problem.
Actually the extra notification won't hurt much in practice.
I've seen that some drivers also don't check the unchanged case and
return always 1, so apparently the apps work. But, it's of course
better to check the state on the driver side.
Takashi
^ permalink raw reply
* Re: [patch] fix RTC/NVRAM accesses on Maple
From: jfaslist @ 2006-05-30 13:49 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <ecea6f4aafae5a453662340020d4cc88@kernel.crashing.org>
> 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.
>
> Segher
>
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?
Thanks,
-jfs
___________________________________________________________________________
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com
^ permalink raw reply
* Re: [Alsa-devel] [RFC 4/7] snd-aoa: add codecs
From: Johannes Berg @ 2006-05-30 13:53 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <s5hpshvfwta.wl%tiwai@suse.de>
[-- Attachment #1: Type: text/plain, Size: 581 bytes --]
On Tue, 2006-05-30 at 15:48 +0200, Takashi Iwai wrote:
> Actually the extra notification won't hurt much in practice.
> I've seen that some drivers also don't check the unchanged case and
> return always 1, so apparently the apps work. But, it's of course
> better to check the state on the driver side.
Yeah, agreed. I'll fix it.
How about making alsamixer actually handle the error cases? In the onyx
codec, there's some things that prohibit changing the s/pdif output if
you dno't use a bitrate that can handle, but alsamixer 'changes' it
anyway...
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH 0/8] Overhaul of virt IRQ configuration. / Kill ppc64_interrupt_controller.
From: Michal Ostrowski @ 2006-05-30 13:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1148938117.5959.24.camel@localhost.localdomain>
On Tue, 2006-05-30 at 07:28 +1000, Benjamin Herrenschmidt wrote:
> Hi ! Interesting.. I've start looking at reworking that with a slightly
> different approach though...
>
> We need irq controller instances (which we get from the genirq patch
> from Ingo & Thomas Gleixner), and we decided that interrupt controller
> nodes are mandatory in the device-tree thus we can do something like:
>
The genirq patches were not available until this morning, but now that
I've got them here are some more thought as to what can be done.
> - Each interrupt controller instance, when allocated, requests a certain
> number of interrupts and gets that allocated (gets an offset allocated).
> It can locally use the virtual irq remapping too, I'm still toying with
> the best way to deal with that. This interrupt controller structure is
> associated to the device-node of the controller (or the root node of the
> tree if no controller node is found)
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.
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.
>
> - 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.
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.
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).
> 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()?
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.
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.
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,
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.
--
Michal Ostrowski <mostrows@watson.ibm.com>
^ permalink raw reply
* Re: [Alsa-devel] [RFC 4/7] snd-aoa: add codecs
From: Takashi Iwai @ 2006-05-30 13:56 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <1148997206.4372.13.camel@johannes>
At Tue, 30 May 2006 15:53:25 +0200,
Johannes Berg wrote:
>
> On Tue, 2006-05-30 at 15:48 +0200, Takashi Iwai wrote:
>
> > Actually the extra notification won't hurt much in practice.
> > I've seen that some drivers also don't check the unchanged case and
> > return always 1, so apparently the apps work. But, it's of course
> > better to check the state on the driver side.
>
> Yeah, agreed. I'll fix it.
>
> How about making alsamixer actually handle the error cases? In the onyx
> codec, there's some things that prohibit changing the s/pdif output if
> you dno't use a bitrate that can handle, but alsamixer 'changes' it
> anyway...
Oh, it should be called as a "bug"... ;)
Takashi
^ permalink raw reply
* regarding mvme6100 on kernel 2.6.13
From: Kiran Kumar.A @ 2006-05-30 14:09 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'm porting mvme6100 for 2.6.13.=20
But its hanging after "Now Booting the kernel.."
Can anybody guide me in this regard.
thanks and regards
--=20
_______________________________________________
Search for businesses by name, location, or phone number. -Lycos Yellow Pa=
ges
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.as=
p?SRC=3Dlycos10
^ permalink raw reply
* Re: [SOLVED] LXT973 support (dual PHY with single MDIO)
From: Vitaly Bordug @ 2006-05-30 14:22 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200605301128.48580.laurent.pinchart@tbox.biz>
On Tue, 30 May 2006 11:28:48 +0200
Laurent Pinchart <laurent.pinchart@tbox.biz> wrote:
> Hi,
>
> once again, posting to a mailing list helped me solving my problem. It should
> have been obvious that the MDIO bus is really a bus, and can as such support
> several devices. The issue was that the drivers/net/fs_enet driver set
> bus->phy_mask to ~0x9, and the LXT973 uses addresses 0 and 1. Address 1 thus
> never got probed. What's the reason for probing addresses 0 and 3 only ?
The reason is obvious: bitbang read of PHY id with not-existent PHY, does not return expected (0, iirc), that confuse mdio bus device-driver bound (it assumes error and returns -1), and prevents from probing other phys. So, as that seems to be a "feature" on CPM2 only, we are working that around specifying phy_mask to prevent probing inexistent phys w/over bitbang thing.
--
Sincerely,
Vitaly
^ permalink raw reply
* 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
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