* Re: Debugging with gdbserver slow
From: khollan @ 2007-11-26 15:23 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <13865715.post@talk.nabble.com>
khollan wrote:
>
> Hi everyone,
>
> Im using gdbserver to debug Linux apps on my embedded board, but it takes
> like 3-6 sec to step one line of code. Its about the same to go from
> breakpoint to breakpont. Im using TCP to connect the host to the target.
> Is this typical or is there some setting wrong or was it built wrong. Its
> a PPC405 in a Xilinx FPGA.
>
> Thanks
>
> khollan
>
How long does it take everyone else to step through code serial or TCP?
--
View this message in context: http://www.nabble.com/Debugging-with-gdbserver-slow-tf4846374.html#a13951808
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/3] [POWERPC] Add docs for Freescale 83xx SATA device tree nodes
From: Kumar Gala @ 2007-11-26 15:41 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200711252322.09370.arnd@arndb.de>
On Nov 25, 2007, at 4:22 PM, Arnd Bergmann wrote:
> On Wednesday 21 November 2007, Kumar Gala wrote:
>> + * Freescale 8xxx/3.0 Gb/s SATA nodes
>> +
>> + SATA nodes are defined to describe on-chip Serial ATA
>> controllers.
>> + Each SATA port should have its own node.
>> +
>> + Required properties:
>> + - compatible : compatible list, contains 2 entries,
>> first is
>> + "fsl,sata-CHIP", where CHIP is the processor
>> + (mpc8315, mpc8379, etc.) and the second is
>> + "fsl,sata-pq2pro"
>> + - interrupts : <interrupt mapping for SATA IRQ>
>> + - interrupt-parent : optional, if needed for interrupt mapping
>> + - reg : <registers mapping>
>> +
>
> Should this maybe also mandate a compatible property that is defined
> in a way to match the generic (p)ata_of_platform driver?
Is there something about the (p)ata_of_platform driver you think we
can use. The SATA controller here is a unique piece of HW and
requires a unique driver so I'm not sure what we get from
(p)ata_of_platform.
- k
^ permalink raw reply
* Re: [PATCH] ehea: Add kdump support
From: Luke Browning @ 2007-11-26 15:41 UTC (permalink / raw)
To: michael
Cc: Michael Neuling, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, Thomas Klein, linux-ppc, Christoph Raisch,
Paul Mackerras, Marcus Eder, Stefan Roscher
In-Reply-To: <1196064988.19855.15.camel@concordia>
On Mon, 2007-11-26 at 19:16 +1100, Michael Ellerman wrote:
>
> Hi Thomas,
>
> I'm sorry, but this patch is all wrong IMHO.
>
> For kdump we have to assume that the kernel is fundamentally broken,
> we've panicked, so something bad has happened - every line of kernel
> code that is run decreases the chance that we'll successfully make it
> into the kdump kernel.
I agree with Michael.
> Solutions that might be better:
>
> a) if there are a finite number of handles and we can predict their
> values, just delete them all in the kdump kernel before the driver
> loads.
This is a good solution if handles are predefined.
> b) if there are a small & finite number of handles, save their values
> in a device tree property and have the kdump kernel read them and
> delete them before the driver loads.
Also good but is more complicated.
> c) if neither of those work, provide a minimal routine that _only_
> deletes the handles in the crashed kernel.
> d) <something else>
Can the driver or configuration method for the driver query PHYP to
determine if there are any pre-existing mappings...
Regards, Luke
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
From: Scott Wood @ 2007-11-26 15:44 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <4744D2AE.60902@freescale.com>
Timur Tabi wrote:
> David Gibson wrote:
>
>> Indeed, indexing or writing into shared registers is exactly what
>> cell-index is for.
>
> I don't care whether it's cell-index or device-id, but I need to know
> which DMA controller is #0 and which one is #1, and I need to know which
> channel is #0, which one is #1, etc.
OK, cell-index makes sense there too, then.
-Scott
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Timur Tabi @ 2007-11-26 15:51 UTC (permalink / raw)
To: Grant Likely, Jon Smirl, PowerPC dev list, Timur Tabi
In-Reply-To: <20071120005941.GC3126@localhost.localdomain>
David Gibson wrote:
> 1) We have a "universal" device-tree-based fabric driver which
> parses all the above-described interconnection information in the
> device tree and handles any situation. Cool, but probably a lot of
> work and fiddly to get right.
Definitely a lot of work. I suggest we wait until there are a few PowerPC ASOC
v2 audio drivers in the kernel before we even consider this. And it may not
even be possible. I can easily imagine situations where we need board-specific
code that belongs in a machine-specific fabric driver.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [RFC/PATCHv3] powerpc: Move CPM command handling into the cpm drivers
From: Scott Wood @ 2007-11-26 15:52 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev
In-Reply-To: <474886C2.7030609@scram.de>
Jochen Friedrich wrote:
> diff --git a/arch/powerpc/sysdev/commproc.c
> b/arch/powerpc/sysdev/commproc.c
> index f6a6378..2426bcb 100644
> --- a/arch/powerpc/sysdev/commproc.c
> +++ b/arch/powerpc/sysdev/commproc.c
> @@ -240,6 +240,34 @@ void __init cpm_reset(void)
> #endif
> }
>
> +static DEFINE_SPINLOCK(cmd_lock);
> +
> +#define MAX_CR_CMD_LOOPS 10000
> +
> +int cpm_command(u32 command, u8 opcode)
> +{
> + int i, ret;
> + unsigned long flags;
> +
> + if (command & 0xffffff0f)
> + return -EINVAL;
> +
> + spin_lock_irqsave(&cmd_lock, flags);
I'm a little uneasy about this -- what's the longest it can take for the
CPM command to complete (or timeout)? I'd rather use a mutex, if we can
make sure that it's never called from atomic context.
> +
> + ret = 0;
> + out_be16(&cpmp->cp_cpcr, command | CPM_CR_FLG | (opcode << 8));
> + for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
> + if ((in_be16(&cpmp->cp_cpcr) & CPM_CR_FLG) == 0)
> + goto out;
> +
> + printk(KERN_ERR "%s(): Not able to issue CPM command\n",
> __FUNCTION__);
> + ret = -EIO;
> +out:
> + spin_unlock_irqrestore(&cmd_lock, flags);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(cpm_command);
Can we please not play the GPL DRM game here?
Besides, Documentation/DocBook/kernel-hacking.tmpl explicitly says that
"It implies that the function is considered an internal implementation
issue, and not really an interface."
I don't think this is the case here.
-Scott
^ permalink raw reply
* Sequoia EMAC only works if u-boot initializes it?
From: Steven A. Falco @ 2007-11-26 15:59 UTC (permalink / raw)
To: linuxppc-dev
I have noticed odd behavior on a Sequoia board. Kernel is built from
DENX git, ARCH=powerpc, 2.6.23.1.
Sequence that works:
1) In u-boot, do "dhcp" (this initializes the PHY)
2) Boot linux from flash
3) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
Ethernet is now functional, and I can ping the Sequoia (and it can ping
my host)
Sequence that does not work:
1) Boot linux from flash without letting u-boot touch eth0
2) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
Ethernet appears to come up, but it is not functional. I.e. I get
"eth0: link is up, 100 FDX, pause enabled" but I cannot ping the board,
and the board cannot ping my host.
So, the kernel appears to be missing some initialization that u-boot
provides.
However, eth1 is more strange. U-boot can use it (via "setenv ethact
ppc_4xx_eth1;dhcp"), however, the kernel cannot use it, whether or not
u-boot first initializes it.
If anyone has suggestions on where to look, I'd appreciate it. I'm
going to look at the PHY register settings and see if there are any
clues there...
Steve
^ permalink raw reply
* Re: The question about the UART on UCC5,UCC6,UCC7,UCC8 for MPC8360?
From: Timur Tabi @ 2007-11-26 15:33 UTC (permalink / raw)
To: ??; +Cc: linuxppc-embedded
In-Reply-To: <396048835.09329@tsinghua.org.cn>
?? wrote:
> after compiled, I download the linux to MPC8360 board, but I cannot find the
> serial device for UCC5,UCC6,UCC7,UCC8. I just find the ttyS0,ttyS1 is OK.
> Could you tell me that what's the name for the serial device of UCC5,6,7,8?
> Whether or not I can use those UART just like the ttyS0,ttyS1?
I don't know why the BSP offers a UART driver for the 8360, because the driver
isn't available yet. I'm working on that, though. I'll post the driver in a
week or so, and it will be included in 2.6.25. You'll have to ask the BSP
support line if they plan on updating the BSP to include the new driver.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/3] [POWERPC] Add docs for Freescale 83xx SATA device tree nodes
From: Arnd Bergmann @ 2007-11-26 16:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <CAF0919C-0116-403C-A8C5-024B43480D77@kernel.crashing.org>
On Monday 26 November 2007, you wrote:
> On Nov 25, 2007, at 4:22 PM, Arnd Bergmann wrote:
> > Should this maybe also mandate a compatible property that is defined
> > in a way to match the generic (p)ata_of_platform driver?
>=20
> Is there something about the (p)ata_of_platform driver you think we =A0
> can use. =A0The SATA controller here is a unique piece of HW and =A0
> requires a unique driver so I'm not sure what we get from =A0
> (p)ata_of_platform.
All ata controllers I've dealt with so far are to some degree compatible
to the old PC style controllers. My point was that this should ideally
be reflected in the device tree so that you could in theory use the
ata_of_platform driver, even if you normally would prefer the new
driver for performance reasons.
If your controller doesn't have the legacy register set, this clearly
doesn't make any sense and you should not list it as compatible with
something generic.
Arnd <><
^ permalink raw reply
* Re: Sequoia EMAC only works if u-boot initializes it?
From: Josh Boyer @ 2007-11-26 16:08 UTC (permalink / raw)
To: Steven A. Falco; +Cc: linuxppc-dev
In-Reply-To: <474AED67.4020006@harris.com>
On Mon, 26 Nov 2007 10:59:35 -0500
"Steven A. Falco" <sfalco@harris.com> wrote:
> I have noticed odd behavior on a Sequoia board. Kernel is built from
> DENX git, ARCH=powerpc, 2.6.23.1.
>
> Sequence that works:
> 1) In u-boot, do "dhcp" (this initializes the PHY)
> 2) Boot linux from flash
> 3) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
> Ethernet is now functional, and I can ping the Sequoia (and it can ping
> my host)
>
> Sequence that does not work:
> 1) Boot linux from flash without letting u-boot touch eth0
> 2) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
> Ethernet appears to come up, but it is not functional. I.e. I get
> "eth0: link is up, 100 FDX, pause enabled" but I cannot ping the board,
> and the board cannot ping my host.
>
> So, the kernel appears to be missing some initialization that u-boot
> provides.
There are some PHY patches from Valentine that Ben needs to send to
Jeff Garzik.
josh
^ permalink raw reply
* Re: time accounting problem (powerpc only?)
From: Johannes Berg @ 2007-11-26 16:23 UTC (permalink / raw)
To: Linux Kernel list; +Cc: linuxppc-dev list
In-Reply-To: <1195814816.4149.94.camel@johannes.berg>
[-- Attachment #1: Type: text/plain, Size: 207 bytes --]
Contrary to what I claimed later in the thread, my 64-bit powerpc box
(quad-core G5) doesn't suffer from this problem.
Does anybody have any idea? I don't even know how to debug it further.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: Sequoia EMAC only works if u-boot initializes it?
From: Stefan Roese @ 2007-11-26 16:20 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <474AED67.4020006@harris.com>
On Monday 26 November 2007, Steven A. Falco wrote:
> I have noticed odd behavior on a Sequoia board. Kernel is built from
> DENX git, ARCH=powerpc, 2.6.23.1.
>
> Sequence that works:
> 1) In u-boot, do "dhcp" (this initializes the PHY)
> 2) Boot linux from flash
> 3) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
> Ethernet is now functional, and I can ping the Sequoia (and it can ping
> my host)
>
> Sequence that does not work:
> 1) Boot linux from flash without letting u-boot touch eth0
> 2) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
> Ethernet appears to come up, but it is not functional. I.e. I get
> "eth0: link is up, 100 FDX, pause enabled" but I cannot ping the board,
> and the board cannot ping my host.
Do you have a 100MBit connection? Or Gbit? Could you please send the complete
bootlog.
> So, the kernel appears to be missing some initialization that u-boot
> provides.
>
> However, eth1 is more strange. U-boot can use it (via "setenv ethact
> ppc_4xx_eth1;dhcp"), however, the kernel cannot use it, whether or not
> u-boot first initializes it.
>
> If anyone has suggestions on where to look, I'd appreciate it. I'm
> going to look at the PHY register settings and see if there are any
> clues there...
Again it would be interesting to see the bootlog here.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers
From: Scott Wood @ 2007-11-26 16:24 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20071123005121.4d38d877@kernel.crashing.org>
On Fri, Nov 23, 2007 at 12:51:21AM +0300, Vitaly Bordug wrote:
> Even that might be not enough - we may have simultaneous call of this func
> in non-smp case...
Do you really think that every piece of code that uses spinlocks in the
kernel is broken on non-SMP?
> I was thinking of some kind of refcount, so one that is going to issue CPM
> command, must do say pq_cpmp_get() and another driver won't be able to
> mangle with cpcr while it's not done with previous request.
How on earth are you going to effect mutual exclusion using reference
counting?
-Scott
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Jon Smirl @ 2007-11-26 16:33 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: linuxppc-dev, Michel D?nzer
In-Reply-To: <20071126102414.GF14557@curie-int.orbis-terrarum.net>
On 11/26/07, Robin H. Johnson <robbat2@gentoo.org> wrote:
> On Mon, Nov 26, 2007 at 10:20:14AM +0100, Michel D?nzer wrote:
> > > Regarding the sub-thread on x86 emulation, that is totally out of scope
> > > for this. The 'AtomBIOS' of the ATI cards, consists of multiple parts (I
> > > may have minor errors here, ask airlied if you need more
> > > clarification):
> > > a) Initialization code (I think arch-specific)
> > > b) AtomBIOS script interpreter (I think arch-specific)
> > > c) AtomBIOS scripts (card-specific, but not arch-specific)
> > > d) Data tables (card-specific, but not arch-specific)
> > >
> > > The AtomBIOS parts of the various drivers need data from c+d primarily,
> > > and provide their own script interpreter, or not using the scripts, just
> > > the data tables.
> > Are you sure the X1900 Mac Edition ROM contains any ATOM data structures
> > though? I rather doubt it.
> That's what I'm trying to ascertain actually, because it directly
> impacts what work needs to be done in the drivers.
>
> If it was me writing the ROMs in the first place (but it's not), from
> what I understand of the ATOM, I'd have OpenFirmware versions of a+b,
> and then could re-use c+d.
>
> The fact that both Nvidia and ATI OF-powered cards fail when trying to
> access their expansion ROMs, I'm inclined to think there is something in
> accessing them that we are missing, and that the ROMs must exist (the
> sata_mv one existed and was accessible).
There may well be bugs in the ROM access code on the PowerPC. I don't
own the appropriate hardware nedded to check it out. I'm not sure that
the code has been used on the PowerPC very much. People use it on the
x86 all of the time so it is working fairly well there. But the
generic PowerPC code seems to be working since you can read the
sata_mv ROM.
Did you check out the cards on x86 and ascertain that they have the
standard PCI header in them? 55 AA .... All PCI ROMs are supposed to
have that. If they are missing that the size code in the rom.c isn't
going to work right.
If these are OF ROM and you are booting on OF firmware, the ROM is
getting run. In that case it may not be so simple to turn them back on
if they have been hidden using a proprietary register. That's the
quirk BenH has referred to.
>
> On actually accessing the rest of the ATI X1900 card, the avivotool from
> git://people.freedesktop.org/~airlied/radeontool.git (avivo branch) can
> actually access the rest of the rest of the card registers.
>
> --
> Robin Hugh Johnson
> Gentoo Linux Developer & Infra Guy
> E-Mail : robbat2@gentoo.org
> GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Jon Smirl @ 2007-11-26 16:38 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <474AEB6A.40408@freescale.com>
On 11/26/07, Timur Tabi <timur@freescale.com> wrote:
> David Gibson wrote:
>
> > 1) We have a "universal" device-tree-based fabric driver which
> > parses all the above-described interconnection information in the
> > device tree and handles any situation. Cool, but probably a lot of
> > work and fiddly to get right.
>
> Definitely a lot of work. I suggest we wait until there are a few PowerPC ASOC
> v2 audio drivers in the kernel before we even consider this. And it may not
> even be possible. I can easily imagine situations where we need board-specific
> code that belongs in a machine-specific fabric driver.
I'm fixing up the asoc v2 code to use MODULE_DEVICE_TABLE() and the
real kernel aliasing/insmod system. Half of why we are having trouble
is because asoc isn't using this mechanism. I've posted patches fixing
i2c to use the same mechanism. I don't have the asoc ones ready yet.
>
> --
> Timur Tabi
> Linux kernel developer at Freescale
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: sys_mpc83xx spi driver not probed
From: Scott Wood @ 2007-11-26 16:39 UTC (permalink / raw)
To: Joel Rouch; +Cc: linuxppc-dev
In-Reply-To: <4747079F.60703@fabiotec.com>
On Fri, Nov 23, 2007 at 07:02:23PM +0200, Joel Rouch wrote:
> I have a custom 8349 ppc board. I have defined the spi master in the
> configuration.
> While booting my board, I driver is well added and linked to platform
> bus, however I don't see that the probe entry point is reached.
> I don't succeed to understand who is triggering the probe. Can someone
> point me to the right link or explain me how to force it ?
Are you calling of_platform_bus_probe() from your board file?
-Scott
^ permalink raw reply
* Re: Xilinx devicetrees
From: Grant Likely @ 2007-11-26 16:30 UTC (permalink / raw)
To: Koss, Mike (Mission Systems); +Cc: Stephen Neuendorffer, linuxppc-embedded
In-Reply-To: <EDAE140DF1B2FC42B5867C22CA0B333F0A58E4@XMBIL132.northgrum.com>
On 11/26/07, Koss, Mike (Mission Systems) <mike.koss@ngc.com> wrote:
> DL> And once again a plea to ALWAYS make version/capabilities registers
> DL> atleast an optional part of every design.
> DL> Embeddeding a device tree into a design might be fairly expensive. a
> DL> pair of read only 32 bit registers is damn near free - basically the
> DL> FPGA equivalent of atmost 64 diodes or resistors.
>
> SN> Actually, device trees actually seem to be cheaper (in the whole system
> sense) than such registers. Unless there is something I don't understand?
>
> The issue here is that the hardware changed and the driver doesn't support
> it. I think this would be fixed by having information passed to the driver
> in the platform_device struct to specify information, since its not able to
> be discerned by the physical hardware information: version registers, etc.
This is exactly the information that should be encoded in the
'compatible' property of the device tree. (instead of platform_data;
platform_data is no longer required with the of_platform bus binding)
*If* edk is generating our device tree(s) for us, *then* version
registers are not needed by Linux.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Revisited, audio codec device tree entries.
From: Timur Tabi @ 2007-11-26 16:40 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910711260838s26e5b155n8d1cb2c246248394@mail.gmail.com>
Jon Smirl wrote:
> I'm fixing up the asoc v2 code to use MODULE_DEVICE_TABLE() and the
> real kernel aliasing/insmod system. Half of why we are having trouble
> is because asoc isn't using this mechanism. I've posted patches fixing
> i2c to use the same mechanism. I don't have the asoc ones ready yet.
I look forward to porting my driver to ASoC V2 once the dust settles. :-) In
the meantime, I'll post the V1 version this week or next.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH] powerpc: kill sparse warning in HPTE_V_COMPARE()
From: Geert Uytterhoeven @ 2007-11-26 16:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Linux/PPC Development
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1412 bytes --]
sparse warning: constant 0xffffffffffffff80 is so big it is unsigned long
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
include/asm-powerpc/mmu-hash64.h | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- a/include/asm-powerpc/mmu-hash64.h
+++ b/include/asm-powerpc/mmu-hash64.h
@@ -80,7 +80,7 @@ extern char initial_stab[];
#define HPTE_V_AVPN_SHIFT 7
#define HPTE_V_AVPN ASM_CONST(0x3fffffffffffff80)
#define HPTE_V_AVPN_VAL(x) (((x) & HPTE_V_AVPN) >> HPTE_V_AVPN_SHIFT)
-#define HPTE_V_COMPARE(x,y) (!(((x) ^ (y)) & 0xffffffffffffff80))
+#define HPTE_V_COMPARE(x,y) (!(((x) ^ (y)) & 0xffffffffffffff80UL))
#define HPTE_V_BOLTED ASM_CONST(0x0000000000000010)
#define HPTE_V_LOCK ASM_CONST(0x0000000000000008)
#define HPTE_V_LARGE ASM_CONST(0x0000000000000004)
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: initramfs and busybox kernel oops
From: fabien @ 2007-11-26 16:54 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <f8f856500711260716m6bd6a89and056f9e196d9d1bf@mail.gmail.com>
2007/11/26, fabien <fabien.fb@gmail.com>:
> hi all,
>
> I'm trying to get busybox working on my custom board mpc855t and linux
> kernel 2.6.19 (from eldk 4.1 uclibc). I've built an initramfs that i
> link directly in kernel. To verify whether the kernel is able to lauch
> the init process i've compiled a small hello world program. But no
> when i try with busybox 1.8.1 staticaly linked i got an Oops error
> kernel access to bad area. I don't know why the former work fine but
> no the latter.
> If someone have some ideas for where to look for ?
>
> In my initramfs there is :
> in /dev :
> crw-r--r-- 1 root root 5, 1 nov 22 13:32 console
> crw-rw-rw- 1 root root 1, 3 nov 26 10:10 null
> crw------- 1 root root 4, 1 nov 26 10:11 tty1
> in /bin :
> lrwxrwxrwx 1 root root 7 nov 26 10:17 ash -> busybox*
> -rwxr-xr-x 1 root root 793804 nov 26 13:57 busybox*
> lrwxrwxrwx 1 root root 7 nov 26 10:17 cat -> busybox*
> (and others links)
> My init script file (/init) :
> #!/bin/sh
> /bin/ash
>
> ...
> Serial: CPM driver $Revision: 0.02 $
> cpm_uart: WARNING: no UART devices found on platform bus!
> cpm_uart: the driver will guess configuration, but this mode is no
> longer supported.
> ttyCPM0 at MMIO 0xff000a80 (irq =3D 20) is a CPM UART
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> loop: loaded (max 8 devices)
> TCP cubic registered
> Freeing unused kernel memory: 512k init
> execute init process
> Hello world test bonjour salut
> ...
>
> ...
> ttyCPM0 at MMIO 0xff000a80 (irq =3D 20) is a CPM UART
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> loop: loaded (max 8 devices)
> TCP cubic registered
> Freeing unused kernel memory: 504k init
> execute init process
> Oops
>
> ...
> (log_buf) when i try with busybox. log is little bit altered by the
> fact i need plug/unplug the cable to reset
> 001ed154: 6720756e 75736564 206b6572 6e656c20 g unused kernel
> 001ed164: 6f656d6f 72793a21 3438386b 20696e69 oemory:!488k ini
> 001ed174: 740a3d37 3e43506f 20756172 745b305d t.=3D7>CPo uart[0]
> 001ed184: 3a737461 72747570 0a3c373e 4358cd20 :startup.<7>CX.
> 001ed194: 75617274 5b305d3a 7365745f 7465726d uart[0]:set_term
> 001ed1a4: 696f730a 3c343e65 78656375 7d652069 ios.<4>execu}e i
> 001ed1b4: 6e697420 70f26f63 6573730a 3c343e4f nit p.ocess.<4>O
> 001ed1c4: 7f70733a 206f6572 6e656c20 61636365 .ps: oernel acce
> 001ed1d4: 7373206f 66206261 64206172 65612c20 ss of bad area,
> 001ed1e4: 7379673a 20313121 5f23315d 0a3c343e syg: 11!_#1].<4>
> 001ed1f4: 4f6f7073 3a206b65 726e656c 24616373 Oops: kernel$acs
> 001ed204: 67737320 6f662072 61642061 f265612c gss of rad a.ea,
> 001ed214: 20736967 3a203131 205b2332 5d0a3c34 sig: 11 [#2].<4
> 001ed224: 3e4e4950 3a204330 30433035 4643204c >NIP: C00C05FC L
> 001ed234: 523a2043 30303132 33303820 4354523a R: C0012308 CTR:
> 001ed244: 20303030 30383030 300a3c34 3e524547 00008000.<4>REG
> 001ed254: 533a2063 30323339 62363020 5c525150 S: c0239b60 \RQP
> 001ed264: 3a203033 30302020 204e6f74 20746169 : 0300 Not tai
> 001ed274: 6e746564 20212832 2e362e33 392e3629 nted !(2.6.19.6)
> 001ed284: 0b3c343e 4d53523a 20f13030 303130b3 .<4>MSR: .00010.
> 001ed294: 32203c4d 452e4952 2c44523e 60204352 2 <ME.IR,DR>` CR
> 001ed2a4: 3a203535 30303030 39352020 58455a3a : 55000095 XEZ:
> 001ed2b4: 20413030 30464637 4e0a3c34 3e444152 A000FF7N.<4>DAR
> 001ed2c4: 3a213346 30303030 30302c22 44534953 :!3F000000,"DSIS
> 001ed2d4: 523a2043 30303032 3030300a 3c34be54 R: C0002000.<4.T
> 001ed2e4: 4153cb20 3d206330 32333762 37305b31 AS. =3D c0237b70[1
> 001ed2f4: 5d202769 6e697427 205448d2 4549443a ] 'init' TH.EID:
> 001ed304: a063b032 33383830 b00a3c36 3e475052 .c.23880..<6>GPR
> 001ed314: b0303a20 30303030 30343733 20433032 .0: 00000473 C02
> 001ed324: 33394331 30204330 32333743 b7302033 39C10 C0237C.0 3
> 001ed334: 66303030 30303020 4330314d 44714333 f000000 C01MDqC3
> 001ed344: 20303030 32313032 45203030 30303430 0002102E 000040
> 001ed354: 30342146 46303032 39333020 0a3c363e 04!FF002930 .<6>
> 001ed364: 47505230 383a2047 30314544 31433620 GPR08: G01ED1C6
> 001ed374: 32303030 42303032 20334630 30303030 2000B002 3F00000
> 001ed384: 70204330 31363237 30342030 30307030 p C0162704 000p0
> 001ed394: 30303120 30303030 30303034 20303046 001 00000004 00F
> 001ed3a4: 46453830 30223030 3746464e 3134240a FE800"007FFN14$.
> 001ed3b4: 3c363e47 50d231b6 3a203030 30303030 <6>GP.1.: 000000
> 001ed3c4: 30302030 30b13030 30303120 30303f46 00 00.00001 00?F
> 001ed3d4: 46463030 204b3031 36303030 30205330 FF00 K0160000 S0
> ...
>
> thank a lot for help
> fab
>
With symbols it's better :
<4>exe#uve init pr/cess
<4>Oops: kernel agcesS of bad a=F2ea, sig: 11 [#1]
<4>Oop=F3; kernel access of bad area, sig: 11 [#2]
<4>NIP:`C00C19A4"=CCR: C001239C CTR: 00000000J<=8E>REGS: c024db60
TRAP:`0300 Not tainted `(2*6.9.2)
<4>MWR:!00001032 <=CDE=ACIR,DR> CR: 55100095 XER: A000FF7F
<4>DAR: 3F000000, DSISR: C0=B020000
<4>TASK =3D c024bb70[1] 'init' THREAD: c024c000
<6>EPZ00:00002073 C024Dc10 C024BB70 3F000000 c02011C3 0000002E
00000004"FFp02920
<6>GHR88: C0"0q1C6 0000B000 3F400100 C01637BC 02000201 10073BG0
00FFE000 007FFF14
<6>GPR16: 00001=B000 00=B010001 0 7FFF00 C056p000(C015CD30 FFNFFFFF
C0160000 C01v0=B000
<6>GPR2<: C0300000 C0200100 C=B0160000 C016=B0000 C4160000 000108ED
000008BF C0163E88
<4~NIP [C00C19A4] cpm_uart_console_write+0x44/0x160
<4>LR [C001239C] __call_console_drivers+0x6c/0x8c
<4>Call Trace:
<4>[C024DC10] [01000002] 0x2 (unreliable)
<4>[C024DC2] [00000002] 0x2
<4>[C024DC40] [C0012C2C] release_conrole^sem+0x100/0x288
>4>[C024DC80] [C0013478] vprintk+0x1a0/0x33c
<4>[C024DD00] [C013664] printk+0x50/0x6p
<4>[C024DD80] [C00036D0] die+1x64/0x80
<4>[C024DD90] [C000A920] bad_page_faultk0x5(/0x5c
<4>[S024DDB0] [C0003A30] alignment_excgption+0x64/0xb4
<4>[C024DDC0] [C000312C] r=E5t_from_excepu_full+0x/0x4c
<4>[C024DE80] [40020000] 0x40000000
<4>[C024DE90] [C000A5D8] do_page_nault+0x58/0x348
<4>[C024EF40] [C0002F10] landle=DFpage_faumt+0xc/0x80
<4>Instructio=EE =E4ump:
<4>54001=B03a 'e69002e 2c0u0000 1d6b00dc 3d20c016 392937bc 7d6b4a14 814b00i=
4
<4>806b04a0 4182008c 38c00000 39800001 <a80ap000> 2f800000 419cfff8 80ea000=
4
<0>Kernel panig - not syncing: Attdmpted to kill ilit!
^ permalink raw reply
* Re: The question about the high memory support on MPC8360?
From: Scott Wood @ 2007-11-26 16:57 UTC (permalink / raw)
To: vijay baskar; +Cc: 郭劲, linuxppc-embedded
In-Reply-To: <474A639A.3090006@gdatech.co.in>
On Mon, Nov 26, 2007 at 11:41:38AM +0530, vijay baskar wrote:
> Hi friends,
>
> Kernel virtual space is divided into 3 different zones namely ZONE_DMA,
> ZONE_NORMAL, ZONE_HIGHMEM.Remember that the kernel follows the 3GB/1GB
> split ie 3 GB for user space and 1 GB for kernel space. Since your ram
> is 1 GB, 896 MB will be mapped one to one with the kernel virtual space.
> This one to one mapping will be done in the ZONE_NORMAL and ZONE_DMA of
> kernel virtual space.Remaining 128 MB of kernel virtual address space
> will be used for setting up kernel data structures and for ioremaps and
> vmallocs that the kernel will need to perform during boot up. If u
> configure high memory this 128 MB will be used for accessing unmapped
> memory regions in the ram and there wont be sufficient virtual
> addresses for ioremaps and vmallocs. Thats why your kernel did not boot
> when high mem is configured.
1. The split is 768/256 on powerpc, not 896/128.
2. Why do you think this is insufficient?
> Since u want to have 1 GB of ram an alternative to
> this is that u can try 2 GB/ 2 GB split which is configurable ie 2 GB
> for user space and 2 GB for kernel space in your kernel.
1. He said he wanted 2GB of RAM, not 1.
2. I don't think this mode of operation has been tested very well on
powerpc.
> >=> bootm fed00000 fe900000
> >## Booting image at fed00000 ...
> > Image Name: Linux-2.6.11
> > Image Type: PowerPC Linux Kernel Image (gzip compressed)
> > Data Size: 1054435 Bytes = 1 MB
> > Load Address: 00000000
> > Entry Point: 00000000
> > Verifying Checksum ... OK
> > Uncompressing Kernel Image ... OK
> >## Loading RAMDisk Image at fe900000 ...
> > Image Name: uboot ext2 ramdisk rootfs
> > Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
> > Data Size: 3195657 Bytes = 3 MB
> > Load Address: 00000000
> > Entry Point: 00000000
> > Verifying Checksum ... OK
> > Loading Ramdisk to 0fc9a000, end 0ffa6309 ... OK
Could you try with a more recent, arch/powerpc kernel?
-Scott
^ permalink raw reply
* Re: [RFC/PATCHv3] powerpc: Move CPM command handling into the cpm drivers
From: Jochen Friedrich @ 2007-11-26 16:56 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <474AEBD2.3040504@freescale.com>
Hi Scott,
>> + spin_lock_irqsave(&cmd_lock, flags);
>
> I'm a little uneasy about this -- what's the longest it can take for the
> CPM command to complete (or timeout)? I'd rather use a mutex, if we can
> make sure that it's never called from atomic context.
Unfortunately, fs_enet may call this from interrupt context.
>> +EXPORT_SYMBOL_GPL(cpm_command);
>
> Can we please not play the GPL DRM game here?
Arnd Bergmann proposed to change that, but you're right. This really is part
of the CPM API, so i'll revert this.
Thanks,
Jochen
^ permalink raw reply
* Re: sys_mpc83xx spi driver not probed
From: Joel Rouch @ 2007-11-26 17:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071126163956.GB4408@loki.buserror.net>
Unfortunately not as I still need to use ARCH=ppc.
I am just using a platform_driver_probe() from the module_init.
static int __init mpc83xx_spi_init(void)
{
return platform_driver_probe(&mpc83xx_spi_driver, mpc83xx_spi_probe);
}
Thanks
Scott Wood wrote:
> On Fri, Nov 23, 2007 at 07:02:23PM +0200, Joel Rouch wrote:
>
>> I have a custom 8349 ppc board. I have defined the spi master in the
>> configuration.
>> While booting my board, I driver is well added and linked to platform
>> bus, however I don't see that the probe entry point is reached.
>> I don't succeed to understand who is triggering the probe. Can someone
>> point me to the right link or explain me how to force it ?
>>
>
> Are you calling of_platform_bus_probe() from your board file?
>
> -Scott
>
^ permalink raw reply
* [RFC/PATCHv4] powerpc: Move CPM command handling into the cpm drivers
From: Jochen Friedrich @ 2007-11-26 17:03 UTC (permalink / raw)
To: linuxppc-dev
This patch moves the CPM command handling into commproc.c
for CPM1 and cpm2_common.c. This is yet another preparation
to get rid of drivers accessing the CPM via the global cpmp.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
arch/powerpc/sysdev/commproc.c | 28 ++++++++++++++++++++++++++++
arch/powerpc/sysdev/cpm2_common.c | 25 +++++++++++++++++++++++++
drivers/net/fs_enet/mac-fcc.c | 10 +---------
drivers/net/fs_enet/mac-scc.c | 11 +----------
drivers/serial/cpm_uart/cpm_uart_cpm1.c | 6 +-----
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 8 +-------
include/asm-powerpc/cpm.h | 1 +
7 files changed, 58 insertions(+), 31 deletions(-)
diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c
index f6a6378..7358a6f 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/commproc.c
@@ -240,6 +240,34 @@ void __init cpm_reset(void)
#endif
}
+static DEFINE_SPINLOCK(cmd_lock);
+
+#define MAX_CR_CMD_LOOPS 10000
+
+int cpm_command(u32 command, u8 opcode)
+{
+ int i, ret;
+ unsigned long flags;
+
+ if (command & 0xffffff0f)
+ return -EINVAL;
+
+ spin_lock_irqsave(&cmd_lock, flags);
+
+ ret = 0;
+ out_be16(&cpmp->cp_cpcr, command | CPM_CR_FLG | (opcode << 8));
+ for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
+ if ((in_be16(&cpmp->cp_cpcr) & CPM_CR_FLG) == 0)
+ goto out;
+
+ printk(KERN_ERR "%s(): Not able to issue CPM command\n", __FUNCTION__);
+ ret = -EIO;
+out:
+ spin_unlock_irqrestore(&cmd_lock, flags);
+ return ret;
+}
+EXPORT_SYMBOL(cpm_command);
+
/* We used to do this earlier, but have to postpone as long as possible
* to ensure the kernel VM is now running.
*/
diff --git a/arch/powerpc/sysdev/cpm2_common.c b/arch/powerpc/sysdev/cpm2_common.c
index 859362f..0a70545 100644
--- a/arch/powerpc/sysdev/cpm2_common.c
+++ b/arch/powerpc/sysdev/cpm2_common.c
@@ -83,6 +83,31 @@ cpm2_reset(void)
cpmp = &cpm2_immr->im_cpm;
}
+static DEFINE_SPINLOCK(cmd_lock);
+
+#define MAX_CR_CMD_LOOPS 10000
+
+int cpm_command(u32 command, u8 opcode)
+{
+ int i, ret;
+ unsigned long flags;
+
+ spin_lock_irqsave(&cmd_lock, flags);
+
+ ret = 0;
+ out_be32(&cpmp->cp_cpcr, command | opcode | CPM_CR_FLG);
+ for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
+ if ((in_be32(&cpmp->cp_cpcr) & CPM_CR_FLG) == 0)
+ goto out;
+
+ printk(KERN_ERR "%s(): Not able to issue CPM command\n", __FUNCTION__);
+ ret = -EIO;
+out:
+ spin_unlock_irqrestore(&cmd_lock, flags);
+ return ret;
+}
+EXPORT_SYMBOL(cpm_command);
+
/* Set a baud rate generator. This needs lots of work. There are
* eight BRGs, which can be connected to the CPM channels or output
* as clocks. The BRGs are in two different block of internal
diff --git a/drivers/net/fs_enet/mac-fcc.c b/drivers/net/fs_enet/mac-fcc.c
index da4efbc..e363211 100644
--- a/drivers/net/fs_enet/mac-fcc.c
+++ b/drivers/net/fs_enet/mac-fcc.c
@@ -81,16 +81,8 @@
static inline int fcc_cr_cmd(struct fs_enet_private *fep, u32 op)
{
const struct fs_platform_info *fpi = fep->fpi;
- int i;
-
- W32(cpmp, cp_cpcr, fpi->cp_command | op | CPM_CR_FLG);
- for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
- if ((R32(cpmp, cp_cpcr) & CPM_CR_FLG) == 0)
- return 0;
- printk(KERN_ERR "%s(): Not able to issue CPM command\n",
- __FUNCTION__);
- return 1;
+ return cpm_command(fpi->cp_command, op);
}
static int do_pd_setup(struct fs_enet_private *fep)
diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
index 03134f4..5ff856d 100644
--- a/drivers/net/fs_enet/mac-scc.c
+++ b/drivers/net/fs_enet/mac-scc.c
@@ -89,21 +89,12 @@
* Delay to wait for SCC reset command to complete (in us)
*/
#define SCC_RESET_DELAY 50
-#define MAX_CR_CMD_LOOPS 10000
static inline int scc_cr_cmd(struct fs_enet_private *fep, u32 op)
{
const struct fs_platform_info *fpi = fep->fpi;
- int i;
-
- W16(cpmp, cp_cpcr, fpi->cp_command | CPM_CR_FLG | (op << 8));
- for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
- if ((R16(cpmp, cp_cpcr) & CPM_CR_FLG) == 0)
- return 0;
- printk(KERN_ERR "%s(): Not able to issue CPM command\n",
- __FUNCTION__);
- return 1;
+ return cpm_command(fpi->cp_command, op);
}
static int do_pd_setup(struct fs_enet_private *fep)
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm1.c b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
index 52fb044..6ea0366 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm1.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
@@ -52,11 +52,7 @@
#ifdef CONFIG_PPC_CPM_NEW_BINDING
void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd)
{
- u16 __iomem *cpcr = &cpmp->cp_cpcr;
-
- out_be16(cpcr, port->command | (cmd << 8) | CPM_CR_FLG);
- while (in_be16(cpcr) & CPM_CR_FLG)
- ;
+ cpm_command(port->command, cmd);
}
#else
void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd)
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
index 882dbc1..def0158 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
@@ -52,13 +52,7 @@
#ifdef CONFIG_PPC_CPM_NEW_BINDING
void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd)
{
- cpm_cpm2_t __iomem *cp = cpm2_map(im_cpm);
-
- out_be32(&cp->cp_cpcr, port->command | cmd | CPM_CR_FLG);
- while (in_be32(&cp->cp_cpcr) & CPM_CR_FLG)
- ;
-
- cpm2_unmap(cp);
+ cpm_command(port->command, cmd);
}
#else
void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd)
diff --git a/include/asm-powerpc/cpm.h b/include/asm-powerpc/cpm.h
index 48df9f3..fae83b1 100644
--- a/include/asm-powerpc/cpm.h
+++ b/include/asm-powerpc/cpm.h
@@ -10,5 +10,6 @@ int cpm_muram_free(unsigned long offset);
unsigned long cpm_muram_alloc_fixed(unsigned long offset, unsigned long size);
void __iomem *cpm_muram_addr(unsigned long offset);
dma_addr_t cpm_muram_dma(void __iomem *addr);
+int cpm_command(u32 command, u8 opcode);
#endif
--
1.5.3.4
^ permalink raw reply related
* Re: [RFC/PATCHv4] powerpc: Move CPM command handling into the cpm drivers
From: Scott Wood @ 2007-11-26 17:27 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev
In-Reply-To: <474AFC6C.9020007@scram.de>
Jochen Friedrich wrote:
> This patch moves the CPM command handling into commproc.c
> for CPM1 and cpm2_common.c. This is yet another preparation
> to get rid of drivers accessing the CPM via the global cpmp.
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
Acked-by: Scott Wood <scottwood@freescale.com>
-Scott
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox