* Re: [PATCH] powerpc: Instrument Hypervisor Calls
From: Mike Kravetz @ 2006-08-15 2:32 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060815110319.5f34417a.sfr@canb.auug.org.au>
On Tue, Aug 15, 2006 at 11:03:19AM +1000, Stephen Rothwell wrote:
> On Mon, 14 Aug 2006 16:21:44 -0700 Mike Kravetz <kravetz@us.ibm.com> wrote:
> > +#define HCALL_INST_POSTCALL \
> > + /* get time and PURR snapshots after hcall */ \
> > + mftb r7; /* timebase after */ \
> > +BEGIN_FTR_SECTION; \
> > + mfspr r8,SPRN_PURR; /* PURR after */ \
> > +END_FTR_SECTION_IFSET(CPU_FTR_PURR); \
> > + \
> > + /* calculate time and PURR deltas for call */ \
> > + ld r5,STK_PARM(r5)(r1); /* timebase before */ \
> > + subf r5,r5,r7; \
> > + ld r6,STK_PARM(r6)(r1); /* PURR before */ \
> > + subf r6,r6,r8; \
>
> But here, if we have no PURR we produce random numbers. Maybe you should
> reuse the TB value so the values reported may make some sense.
Good catch!
My intention was to detect the presence of PURR in the display (debugfs)
code. If there is no PURR, then no PURR values are displayed. My thought
is that it doesn't matter what values are in the field if we don't display
them.
Unfortunately, I left that bit of code out of the patch.
How does that sound? Suppose I can also put all the 'calculate PURR delta'
code in the FTR_SECTION to save a few cycles.
--
Mike
^ permalink raw reply
* Re: [PATCH] powerpc: Instrument Hypervisor Calls
From: Mike Kravetz @ 2006-08-15 2:34 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <44E12B03.6020503@am.sony.com>
On Mon, Aug 14, 2006 at 07:01:39PM -0700, Geoff Levand wrote:
> I want to hook my instrumentation into this config option also, but my
> platform dosn't have PURR, so I would like you to remove the mention
> of '(based on PURR)' in the description of the option. This way we
> can have a generic 'Hypervisor call instrumentation' option for users,
> on whatever platform they are using.
>
> Does it make sense?
Makes sense. No problem. I'll include this update in a revised edition
of the patch.
Thanks,
--
Mike
^ permalink raw reply
* Re: [PATCH] powerpc: Instrument Hypervisor Calls
From: Stephen Rothwell @ 2006-08-15 3:12 UTC (permalink / raw)
To: Mike Kravetz; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060815023224.GA3622@monkey.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 692 bytes --]
On Mon, 14 Aug 2006 19:32:24 -0700 Mike Kravetz <kravetz@us.ibm.com> wrote:
>
> My intention was to detect the presence of PURR in the display (debugfs)
> code. If there is no PURR, then no PURR values are displayed. My thought
> is that it doesn't matter what values are in the field if we don't display
> them.
>
> Unfortunately, I left that bit of code out of the patch.
>
> How does that sound? Suppose I can also put all the 'calculate PURR delta'
> code in the FTR_SECTION to save a few cycles.
That sounds good (as long as you also suppress the display).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: PowerPC paxtest results w/ gcc-4.1
From: Paul Mackerras @ 2006-08-15 3:59 UTC (permalink / raw)
To: matt; +Cc: 'Albert Cahalan', linuxppc-dev, debian-powerpc
In-Reply-To: <000301c6bf97$e9151e00$99dfdfdf@bakuhatsu.net>
Matt Sealey writes:
> Book I compatible PowerPC's have had a "no-executable" bit in
> the page protection flags since the dark ages.. see page 7-38
> and 7-39 of the 'Programming Environments Manual for 32-Bit
> Microprocessors'.. this document predates even the G3.
What are you referring to? I have a copy of the PEM from pre-G3 days,
and a copy that I downloaded just now, and neither of them have an N
bit in the PTE (and yes I just looked carefully through pages 7-38 and
7-39).
There is an N bit in the segment register format, and that's what
Albert is using.
> As far as the documentation goes, you can make the page
> readable and writable to the LSU, but the N bit causes the
> instruction fetch to cause a machine check. That's pretty
> "not-executable" to me at least :)
A machine check is nasty, because it may not be recoverable...
Paul.
^ permalink raw reply
* [PATCH] powerpc: Instrument Hypervisor Calls
From: Dave Boutcher @ 2006-08-15 3:32 UTC (permalink / raw)
To: Mike Kravetz; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060814232144.GG3213@w-mikek2.ibm.com>
On Mon, 14 Aug 2006 16:21:44 -0700, Mike Kravetz <kravetz@us.ibm.com> said:
> Here is an updated version of the patch to instrument hypervisor
> calls. In this version, all statistic updates are performed in
> assembly code. Statistics are made available via debugfs.
> Instrumentation is enabled via a config option and there is zero
> cost if not enabled.
...
> +#define HCALL_INST_POSTCALL \
> + /* get time and PURR snapshots after hcall */ \
> + mftb r7; /* timebase after */ \
if you just add a "mr r8,r7" here you will get consistent
behaviour (either TB and PURR if PURR is supported, or TB
everywhere.) The processor will pretty much optimize that
away if the FTR section is not no-op-ed.
> +BEGIN_FTR_SECTION; \
> + mfspr r8,SPRN_PURR; /* PURR after */ \
> +END_FTR_SECTION_IFSET(CPU_FTR_PURR); \
Dave B
^ permalink raw reply
* Re: ehea debug output discussion
From: Paul Mackerras @ 2006-08-15 5:10 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, roland, netdev, Thomas Klein,
linux-ppc, Christoph Raisch, Anton Blanchard, Marcus Eder
In-Reply-To: <44E06EDA.6040404@de.ibm.com>
Jan-Bernd Themann writes:
> The outcome of some internal discussions was that it is not acceptable for
> our enterprise users of this type of driver on this target system to need a
> recompile / reload of the driver for error analysis, so we need a mechanism
> that allows us to switch on / off debug output at runtime. Therefore, we'd
> introduce a stripped down version of EDEB.
This is precisely what kprobes is for. There is no need for
EDEB-style debug code in the source given that kprobes gives you the
ability to add logging in at (almost) arbitrary points at runtime. In
fact kprobes is more powerful because you don't have to specify the
set of points of interest when the kernel is built--you can do it
later, at the time of debugging.
Please look into providing a kprobes module and/or a systemtap script
for the debugging points you want rather than cluttering up the source
code with EDEB statements.
Paul.
^ permalink raw reply
* BDI2000 and MPC8272
From: Artur Barkhudaryan @ 2006-08-15 6:35 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am trying to use a BDI2000 debugger for a custom MPC8272 board. The
debugger reports support for MPC8xx processors and the following
information
BDI Type : BDI2000 Rev.C
Loader : V1.05
Firmware : V1.10
Logic : V1.02
It does not seem to have support for MPC8272 and I was not able to
find any information about how to enable that. I guess I need new
firmware, right ? How can I obtain that and where ?
I know that this is probably not the best place to ask this question,
but I was unable to find any answer anywhere else...
Thanks a lot,
Artur Barkhudaryan
^ permalink raw reply
* Re: BDI2000 and MPC8272
From: Yanjun Luo @ 2006-08-15 7:34 UTC (permalink / raw)
To: Artur Barkhudaryan, linuxppc-embedded
In-Reply-To: <824771033.20060815113555@epygiarm.am>
Hi Artur,
> It does not seem to have support for MPC8272 and I was not able to
> find any information about how to enable that. I guess I need new
> firmware, right ? How can I obtain that and where ?
What message do you see when BDI2000 connect to the board?
Maybe you should update your firmware of BDI2000.
Regards,
Yanjun Luo.
^ permalink raw reply
* Re: [PATCH 1/7] ehea: interface to network stack
From: Heiko Carstens @ 2006-08-15 7:39 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Thomas Klein, linux-ppc, Christoph Raisch, Marcus Eder
In-Reply-To: <44E0A4CC.4090705@de.ibm.com>
> +int __init ehea_module_init(void)
> +{
> + int ret = -EINVAL;
> +
> + EDEB_EN(7, "");
> +
> + printk(KERN_INFO "IBM eHEA Ethernet Device Driver (Release %s)\n",
> + DRV_VERSION);
> +
> +
> + ret = ibmebus_register_driver(&ehea_driver);
> + if (ret) {
> + EDEB_ERR(4, "Failed registering eHEA device driver on ebus");
> + return -EINVAL;
> + }
> +
> + EDEB_EX(7, "");
> + return 0;
> +}
Function should be static and could be shortened to the single line
return ibmebus_register_driver(&ehea_driver);
, I guess :)
^ permalink raw reply
* Re: BDI2000 and MPC8272
From: Artur Barkhudaryan @ 2006-08-15 7:49 UTC (permalink / raw)
To: Yanjun Luo; +Cc: linuxppc-embedded
In-Reply-To: <002201c6c03d$368769e0$9e00a8c0@embed>
> Hi Artur,
Hello,
>> It does not seem to have support for MPC8272 and I was not able to
>> find any information about how to enable that. I guess I need new
>> firmware, right ? How can I obtain that and where ?
> What message do you see when BDI2000 connect to the board?
Umm, no message, it does not understand any of the CPU types
PPC600/PPC700/MPC8200.
> Maybe you should update your firmware of BDI2000.
I think so... Do you happen to know where one can obtain new firmware
for BDI2000 ?
> Regards,
> Yanjun Luo.
Thanks,
Artur Barkhudaryan
^ permalink raw reply
* Re: BDI2000 and MPC8272
From: Yanjun Luo @ 2006-08-15 8:09 UTC (permalink / raw)
To: Artur Barkhudaryan; +Cc: linuxppc-embedded
In-Reply-To: <1005941084.20060815124945@epygiarm.am>
Hi,
> Umm, no message, it does not understand any of the CPU types
> PPC600/PPC700/MPC8200.
No message? I remember it should display some message that
doesn't support the current CPU.
> I think so... Do you happen to know where one can obtain new firmware
> for BDI2000 ?
Of course you should get it from www.abatron.ch, or their distributors.
I think contact the one who sold the BDI2000 to you is a good idea.
Regards,
Yanjun Luo.
^ permalink raw reply
* eldk4.0 ppc_85xx-gdb failure while debugging with BDI2000
From: emre kara @ 2006-08-15 8:41 UTC (permalink / raw)
To: linuxppc-embedded
Dear All;
Is there any one use BDI2000 ppc_85xx-gdb (coming with
ELDK4.0 dist). Please examine the log below.
Target is waiting in start_kernel func.
ppc_85xx-gdb vmlinux
......
......
(gdb) target remote 192.168.101.101:2001
Remote debugging using 192.168.101.101:2001
0x00000000 in ?? ()
(gdb) q
gdb can not display correct addr and debug anything.
but at this state, older version toolchain (eldk3.1)
is working properly.
Second problem, I have check denx web site for an gdb
update and found
gdb-ppc_85xx-6.3.0.0-1.21_3.ppc.rpm,but instalation
fails with the error below.
-----------------------------------------
ppc_85xx-rpm -U gdb-ppc_85xx-6.3.0.0-1.21_3.ppc.rpm
error: Failed dependencies:
info-ppc_85xx is needed by
gdb-ppc_85xx-6.3.0.0-1.21_3.ppc
------------------------------------------
Here is my bdi configuration file:
--------------------------------------------------
;bdiGDB configuration file for MPC8540ADS
;----------------------------------------
[INIT]
WM32 0x000000f0 0x00000000 ;invalidate page table
base
[TARGET]
CPUTYPE 8540 ;the CPU type
JTAGCLOCK 0 ;use 16 MHz JTAG clock
STARTUP STOP 100 ;halt core while HRESET is
asserted
BREAKMODE SOFT ;SOFT or HARD, HARD uses PPC
hardware breakpoint
STEPMODE HWBP ;JTAG or HWBP, HWBP uses a hardware
breakpoint
MMU XLAT; for kernel debug
PTBASE 0xf0;for kernel debug
WAKEUP 500 ;give reset time to complete
POWERUP 5000 ;start delay after power-up detected
in ms
[HOST]
PROMPT 8540_KRNL>
[REGS]
FILE $reg8560.def
How can I solve this problems?
Thanks.
Emre
___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html
^ permalink raw reply
* Re: BDI2000 and MPC8272
From: Artur Barkhudaryan @ 2006-08-15 9:41 UTC (permalink / raw)
To: Yanjun Luo; +Cc: linuxppc-embedded
In-Reply-To: <002c01c6c042$19445140$9e00a8c0@embed>
Hello,
> Of course you should get it from www.abatron.ch, or their distributors.
> I think contact the one who sold the BDI2000 to you is a good idea.
I will try to contact them directly, thanks for your time.
Best regards,
Artur Barkhudaryan
^ permalink raw reply
* Re: [PATCH 4/6] ehea: header files
From: Jan-Bernd Themann @ 2006-08-15 9:44 UTC (permalink / raw)
To: michael
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <1155600499.9047.13.camel@localhost.localdomain>
Michael Ellerman wrote:
> On Mon, 2006-08-14 at 14:53 +0200, Jan-Bernd Themann wrote:
>> Michael Ellerman wrote:
>>>> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea.h 1969-12-31 16:00:00.000000000 -0800
>>>> +++ kernel/drivers/net/ehea/ehea.h 2006-08-08 23:59:39.927452928 -0700
>>>> +
>>>> +#define EHEA_PAGESHIFT 12
>>>> +#define EHEA_PAGESIZE 4096UL
>>>> +#define EHEA_CACHE_LINE 128
>>> This looks like a very bad idea, what happens if you're running on a
>>> machine with 64K pages?
>>>
>> The EHEA_PAGESIZE define is needed for queue management to hardware side.
>
> You mean the eHEA has its own concept of page size? Separate from the
> page size used by the MMU?
>
yes, the eHEA currently supports only 4K pages for queues
>>>> +/*
>>>> + * h_galpa:
>>>> + * for pSeries this is a 64bit memory address where
>>>> + * I/O memory is mapped into CPU address space
>>>> + */
>>>> +
>>>> +struct h_galpa {
>>>> + u64 fw_handle;
>>>> +};
>>> What is a h_galpa? And why does it need a struct if it's just a u64?
>>>
>> The eHEA chip is not PCI attached but directly connected to a proprietary
>> bus. Currently, we can access it by a simple 64 bit address, but this is not
>> true in all cases. Having a struct here allows us to encapsulate the chip
>> register access and to respond to changes to system hardware.
>>
>> We'll change the name to h_epa meaning "ehea physical address"
>
> Hmm, I'm not convinced. Having the struct doesn't really encapsulate
> much, because most of the places where you use the h_galpa struct just
> pull out the fw_handle anyway. So if you change the layout of the struct
> you're going to have to change most of the code anyway. And in the
> meantime it makes the code a lot less readable, most people understand
> what "u64 addr" is about, whereas "struct h_galpa" is much less
> meaningful. </2c>
>
> cheers
>
We already use the h_galpa struct for simulation purposes where we use
this encapsulation to add further required fields to be able to access
the registers (h_galpa has been renamed to h_epa). The name of the
fw_handle element will be changed. Instead of fw_handle, we'll call it
ebus_addr which will make it more readable.
Regards,
Jan-Bernd
^ permalink raw reply
* RE: [PATCH 4/6] ehea: header files
From: Christoph Raisch @ 2006-08-15 11:07 UTC (permalink / raw)
To: Jenkins, Clive
Cc: Thomas Q Klein, netdev, linux-kernel, linux-ppc, Marcus Eder
In-Reply-To: <35786B99AB3FDC45A821572461791973AC87D3@gbrwgceumf01.eu.xerox.net>
"Jenkins, Clive" wrote on 15.08.2006 12:53:05:
> > > You mean the eHEA has its own concept of page size? Separate from
> the
> > > page size used by the MMU?
> > >
> >
> > yes, the eHEA currently supports only 4K pages for queues
>
> In that case, I suggest use the kernel's page size, but add a
> compile-time
> check, and quit with an error message if driver does not support it.
eHEA does support other page sizes than 4k, but the HW interface expects to
see 4k pages
The adaption is done in the device driver, therefore we have a seperate 4k
define.
Regards . . . Christoph R.
^ permalink raw reply
* edlk4.0 ppc_85xx gdb problems
From: emre kara @ 2006-08-15 11:09 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <OF8C6BA147.30EE53F8-ONC12571CB.003C7748-C12571CB.003CBAA4@de.ibm.com>
Dear All;
Is there any one used BDI2000 ppc_85xx-gdb (coming
with
ELDK4.0 dist). Please examine the log below.
Target is waiting in start_kernel func.
ppc_85xx-gdb vmlinux
......
......
(gdb) target remote 192.168.101.101:2001
Remote debugging using 192.168.101.101:2001
0x00000000 in ?? ()
(gdb) q
gdb can not display correct addr and debug anything.
but at this state, older version toolchain (eldk3.1)
is working properly.
Second problem, I have check denx web site for an gdb
update and found
gdb-ppc_85xx-6.3.0.0-1.21_3.ppc.rpm,but instalation
fails with the error below.
-----------------------------------------
ppc_85xx-rpm -U gdb-ppc_85xx-6.3.0.0-1.21_3.ppc.rpm
error: Failed dependencies:
info-ppc_85xx is needed by
gdb-ppc_85xx-6.3.0.0-1.21_3.ppc
------------------------------------------
Here is my bdi configuration file:
--------------------------------------------------
;bdiGDB configuration file for MPC8540ADS
;----------------------------------------
[INIT]
WM32 0x000000f0 0x00000000 ;invalidate page table
base
[TARGET]
CPUTYPE 8540 ;the CPU type
JTAGCLOCK 0 ;use 16 MHz JTAG clock
STARTUP STOP 100 ;halt core while HRESET is
asserted
BREAKMODE SOFT ;SOFT or HARD, HARD uses PPC
hardware breakpoint
STEPMODE HWBP ;JTAG or HWBP, HWBP uses a hardware
breakpoint
MMU XLAT; for kernel debug
PTBASE 0xf0;for kernel debug
WAKEUP 500 ;give reset time to complete
POWERUP 5000 ;start delay after power-up detected
in ms
[HOST]
PROMPT 8540_KRNL>
[REGS]
FILE $reg8560.def
How can I solve this problems?
Thanks.
Emre
___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html
^ permalink raw reply
* RE: [PATCH 4/6] ehea: header files
From: Jenkins, Clive @ 2006-08-15 10:53 UTC (permalink / raw)
To: Jan-Bernd Themann, michael
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <44E19765.7030301@de.ibm.com>
> > You mean the eHEA has its own concept of page size? Separate from
the
> > page size used by the MMU?
> >=20
>=20
> yes, the eHEA currently supports only 4K pages for queues
In that case, I suggest use the kernel's page size, but add a
compile-time
check, and quit with an error message if driver does not support it.
Regards,
Clive
^ permalink raw reply
* RE: edlk4.0 ppc_85xx gdb problems
From: Jenkins, Clive @ 2006-08-15 11:46 UTC (permalink / raw)
To: emre kara, linuxppc-dev
In-Reply-To: <20060815110933.135.qmail@web25911.mail.ukl.yahoo.com>
> ppc_85xx-gdb vmlinux
> ......
> ......
> (gdb) target remote 192.168.101.101:2001
> Remote debugging using 192.168.101.101:2001
> 0x00000000 in ?? ()
> (gdb) q
When I had this problem (actually using KGDB not BDI2000),
I found that GDB defaulted to e500 architecture (=3Dprocessor)
but it only worked with the less processor-specific
"common" architecture setting:
(gdb) show architecture
The target architecture is set automatically (currently=20
powerpc:e500)
(gdb) set architecture powerpc:common
See also:
http://www.ultsol.com/faq_p311.htm
Regards,
Clive
^ permalink raw reply
* 2.6.18-rc3->rc4 hugetlbfs regression
From: Dave Hansen @ 2006-08-15 15:22 UTC (permalink / raw)
To: Linux Kernel Mailing List, linux-mm
Cc: Suzuki Kp, PPC External List, Yao Fei Zhu, lge,
Nishanth Aravamudan
kernel BUG in cache_free_debugcheck at mm/slab.c:2748!
This is from a ppc64 machine running 2.6.18-rc4. It didn't apparently
happen with 2.6.18-rc3, but I don't see anything particularly suspect in
the changelogs, so it might be a wee bit more intermittent than it first
appeared.
You can get libhugetlbfs from here: http://libhugetlbfs.sourceforge.net/
Steps to reproduce:
1. boot kernel 2.6.18-rc4 with "hugepages=20"
2. mount none -t hugetlbfs /mnt/hugetlbfs
3. run libhugetlbfs, "make check" trigger xmon.
apple-lp1:/kernel/libhugetlbfs.git # make check
zero_filesize_segment (32): obj32/zero_filesize_segment:
obj32/zero_filesize_segment: cannot execute binary file
zero_filesize_segment (64): obj64/zero_filesize_segment:
obj64/zero_filesize_segment: cannot execute binary file
test_root (32): PASS
test_root (64): PASS
meminfo_nohuge (32): PASS
meminfo_nohuge (64): PASS
gethugepagesize (32): PASS
gethugepagesize (64): PASS
empty_mounts (32): PASS
empty_mounts (64): PASS
find_path (32): PASS
find_path (64): PASS
unlinked_fd (32): PASS
unlinked_fd (64): PASS
readback (32): PASS
Additional info:
0:mon> e
cpu 0x0: Vector: 700 (Program Check) at [c0000001cf6e3530]
pc: c0000000000c7458: .cache_free_debugcheck+0x1d0/0x2b0
lr: c0000000000c7410: .cache_free_debugcheck+0x188/0x2b0
sp: c0000001cf6e37b0
msr: 8000000000021032
current = 0xc0000001ccaf94e0
paca = 0xc000000000622300
pid = 6714, comm = readback
kernel BUG in cache_free_debugcheck at mm/slab.c:2748!
0:mon> t
[c0000001cf6e37b0] c0000000000c73cc .cache_free_debugcheck+0x144/0x2b0 (unreliable)
[c0000001cf6e3860] c0000000000c7a04 .kmem_cache_free+0xd8/0x164
[c0000001cf6e3900] c00000000002f630 .pgtable_free_tlb+0xd4/0x144
[c0000001cf6e39a0] c000000000032648 .hugetlb_free_pgd_range+0x1b8/0x26c
[c0000001cf6e3a70] c0000000000b4f68 .free_pgtables+0x90/0x134
[c0000001cf6e3b20] c0000000000b61ac .exit_mmap+0xcc/0x180
[c0000001cf6e3bd0] c00000000006209c .mmput+0x70/0x148
[c0000001cf6e3c60] c000000000067288 .exit_mm+0x118/0x138
[c0000001cf6e3cf0] c0000000000692c4 .do_exit+0x21c/0x958
[c0000001cf6e3da0] c000000000069aa8 .sys_exit_group+0x0/0x8
[c0000001cf6e3e30] c00000000000871c syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000000000feb0b78
SP (ffcc4090) is in userspace
0:mon> r
R00 = 000000000000018f R16 = 00000000100a0000
R01 = c0000001cf6e37b0 R17 = 00000000100b2eb0
R02 = c000000000849ce0 R18 = 00000000100a0000
R03 = c0000001cfe90a08 R19 = 0000000000000000
R04 = c0000001cfe90a10 R20 = 0000000000000000
R05 = ffffffffffffffff R21 = 00000000e0ffffff
R06 = 0000000000000000 R22 = c0000001cf6e3b90
R07 = c000000000648c38 R23 = 00000000e0ffffff
R08 = 000000000001ffff R24 = 00000000e1000000
R09 = 0000000000000001 R25 = c00000000002f630
R10 = 0000000000000019 R26 = c0000001cfe90000
R11 = 0000000000000850 R27 = 0000000000000000
R12 = 0000000000000001 R28 = c0000001cfe90978
R13 = c000000000622300 R29 = 000000000000000e
R14 = 0000000010080000 R30 = c00000000065f098
R15 = 0000000000000000 R31 = c000000002b14380
pc = c0000000000c7458 .cache_free_debugcheck+0x1d0/0x2b0
lr = c0000000000c7410 .cache_free_debugcheck+0x188/0x2b0
msr = 8000000000021032 cr = 44000424
ctr = 0000000000000001 xer = 000000002000001a trap = 700
0:mon> di c0000000000c7458
c0000000000c7458 0b090000 tdnei r9,0
c0000000000c745c 801f0118 lwz r0,280(r31)
c0000000000c7460 7809bfe3 rldicl. r9,r0,55,63
c0000000000c7464 41820034 beq c0000000000c7498 #
.cache_free_debugcheck+0x210/0x2b0
c0000000000c7468 e93f0148 ld r9,328(r31)
c0000000000c746c e87f01d2 lwa r3,464(r31)
c0000000000c7470 7fe4fb78 mr r4,r31
c0000000000c7474 38a00005 li r5,5
c0000000000c7478 e9690000 ld r11,0(r9)
c0000000000c747c f8410028 std r2,40(r1)
c0000000000c7480 7c7c1a14 add r3,r28,r3
c0000000000c7484 7d6903a6 mtctr r11
c0000000000c7488 e8490008 ld r2,8(r9)
c0000000000c748c e9690010 ld r11,16(r9)
c0000000000c7490 4e800421 bctrl
c0000000000c7494 e8410028 ld r2,40(r1)
The BUG() hit here :
*dbg_redzone1(cachep, objp) = RED_INACTIVE;
*dbg_redzone2(cachep, objp) = RED_INACTIVE;
}
if (cachep->flags & SLAB_STORE_USER)
*dbg_userword(cachep, objp) = caller;
objnr = obj_to_index(cachep, slabp, objp);
BUG_ON(objnr >= cachep->num);
BUG_ON(objp != index_to_obj(cachep, slabp, objnr)); <---- Hit here.
if (cachep->flags & SLAB_DEBUG_INITIAL) {
/*
-- Dave
^ permalink raw reply
* No Clock on SPI
From: GSM909 @ 2006-08-15 16:45 UTC (permalink / raw)
To: linuxppc-embedded
Hi
I´m writing a Driver for SPI. That is not working now.
I have a MPC8260 using Linux 2.6.14 (rheap patch).
Did someone else write a driver for SPI on this µC or an other driver? So I can see what i did wrong?
My SPCOM[STR] flag isn´t cleared automatically after one clock cycle.
What here going wrong ? ( I know this register is write only)
There is also no Clock on my SPICLK.
How I have to allocate the Memory for the BD´s and the buffer for the BD´s?
Is there something special when I allocate Memory for my Parameter Ram?
Is something wrong with the 2.6 Kernel so i have to use the 2.4 Kernel ?
I hope somebody could help. Thx
Regards
Fred
--
"Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
^ permalink raw reply
* A working SPI driver in linux
From: Purvis, Craig @ 2006-08-15 18:22 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 159 bytes --]
Hello Navin,
Could I have a copy of your SPI driver files.
Thanks!
Craig Purvis
HW Drivers Team Lead
Mentor Graphics, Embedded Systems Division
[-- Attachment #2: Type: text/html, Size: 917 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4]: powerpc/cell spidernet ethtool -i version number info.
From: Olof Johansson @ 2006-08-15 19:05 UTC (permalink / raw)
To: James K Lewis
Cc: Arnd Bergmann, Jens Osterkamp, linux-kernel, linuxppc-dev, netdev,
Olof Johansson
In-Reply-To: <OF934FE4E3.EEC44FDD-ON872571C7.00668651-862571C7.00677A44@us.ibm.com>
On Fri, Aug 11, 2006 at 01:50:19PM -0500, James K Lewis wrote:
> Hi Olof,
>
> There are several reasons why an Ethernet driver should have an up to
> date version number:
>
> 1. Customers like to see they are really getting a new version.
>
> 2. It makes it easier for support personnel (me in this case) to see which
> driver they have. Sure, sometimes I can talk them thru doing a "sum" on
> the .ko and all that, but why not just use the version number? That's what
> it is for. And no, you can't just assume they have the version that came
> with the kernel they are running. It doesn't work that way.
>
> 3. It makes bug reporting easier.
>
> 4. I have already run into too many problems and wasted too much time
> working with drivers when the number was NOT getting updated.
Thanks for the info, Jim.
Sounds like it's most useful if a customer (or distro) takes the driver
out of the tree and run it with a different kernel, i.e. when kernel
and driver versions no longer go together. Makes sense.
-Olof
^ permalink raw reply
* Re: [PATCH 0/6] bootwrapper: arch/powerpc/boot code reorg patches
From: Hollis Blanchard @ 2006-08-15 19:37 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060808191450.GA10108@mag.az.mvista.com>
On Tue, 2006-08-08 at 12:14 -0700, Mark A. Greer wrote:
> Just a note that I will respin my patches to address all of your
> comments. However, it looks like the fdt code is going to change
> to use code from a common source base. I'm going to wait until
> that has settled and then I'll modify the code and repost the patches.
By the way, I don't expect the (ft_build.h) interface to change much
from what I emailed last week. So I think it's safe to build on top of
those.
The only addition I'd like to make is creating an ft_set_prop() that
will handle resizing the tree for you. With that change, you wouldn't
ft_get_prop() and then write directly to that pointer (as is done
currently).
I'm still waiting to hear the outcome of Matt's patches. I don't need
them, but if u-boot does then I'll have to merge them into the
standalone code.
-Hollis
^ permalink raw reply
* CPM2 UARTs: Won't work under low (<= 1200BD) baudrates?
From: David Tao @ 2006-08-15 19:52 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 484 bytes --]
Hello, guys,
I found that MPC8270 CPM UARTs, both SMCs and SCCs won't work under low baudrate.
Under 2400 baud or above the UARTs work fine, but once the baudrate set to 1200 or below, there is NO data can be sent out or received even programed to do so.
I am using Linux kernel 2.6.15 (from Denx ELDK4.0).
Can anybody help on this? Thanks in advance.
David
---------------------------------
How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call rates.
[-- Attachment #2: Type: text/html, Size: 623 bytes --]
^ permalink raw reply
* [RFC] Updated cuImage target
From: Matthew McClintock @ 2006-08-15 20:00 UTC (permalink / raw)
To: linuxppc-dev
Hello all,
I have mostly completed reworking a new cuImage target based off the
previous discussion. There are several changes from the version I
presented previously. So to summarize these changes, the cuImage
consists of the following:
1) A copy of the kernel is the first section in the cuImage target.
Furthermore, it is now a binary section (vs. elf for the zImage target).
More on this later.
2) The bootwrapper follows the kernel section.
3) The cuImage target automatically creates the 'uImage' which is
bootable by u-boot. The correct offset to the bootwrapper is set as the
entry point, and the load address is 0x0 to prevent excessive copying of
the data.
So now, when u-boot attempts to load the cuImage with the 'bootm'
command it now extracts the image (the decompression is handled by
u-boot) to the 0x0, and then jumps to the bootwrapper start address
located after the kernel image.
The bootwrapper code executes and fixes up a flat device tree for use by
the kernel proper, and then jumps the 0x0 and the kernel starts up. The
patch below consists of two things:
1) Makefile, Linker script, Config changes to allow the new cuImage
target
2) Beginning of work to allow the boot wrapper to create a correct flat
device tree for a Sandpoint board based off information passed to via
the board device structure.
Mark's boot wrapper patches and Sandpoint patches are required for this
to work.
-Matthew
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 01667d1..cf7b7e0 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -146,7 +146,7 @@ all: $(KBUILD_IMAGE)
CPPFLAGS_vmlinux.lds := -Upowerpc
-BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd vmlinux.sm
uImage vmlinux.bin
+BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd vmlinux.sm
uImage vmlinux.bin cuImage
PHONY += $(BOOT_TARGETS)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index daad857..77a0eb7 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -223,3 +223,53 @@ install: $(CONFIGURE) $(BOOTIMAGE)
sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux
System.map "$(INSTALL_PATH)" "$(BOOTIMAGE)"
clean-files += $(addprefix $(objtree)/, $(obj-boot) vmlinux.strip)
+
+#-----------------------------------------------------------
+# build compatiblity u-boot images
+#-----------------------------------------------------------
+
+targets += cuImage
+
+quiet_cmd_cobjbin = OBJCOPY $@
+ cmd_cobjbin = $(OBJCOPY) --set-section-flags=.bss=$(OBJCOPYFLAGS)
--gap-fill=0xff -O binary $< $@
+
+uiet_cmd_cuimage = UIMAGE $@
+ cmd_cuimage = $(CONFIG_SHELL) $(MKIMAGE) -A ppc -O linux -T
kernel \
+ -C gzip -a 0x0 -e $2 -n 'Linux-$(KERNELRELEASE)' -d $< $@
+
+quiet_cmd_addsection_cuimage = ADDSEC $@
+ cmd_addsection_cuimage = $(CROSS32OBJCOPY) $@ \
+ --add-section=.kernel:vmlinux.bin=$(obj)/vmlinux-cuimage.bin \
+ --set-section-flags=.kernel:vmlinux.bin=$(OBJCOPYFLAGS)
+
+$(obj)/vmlinux-cuimage.bin: vmlinux FORCE
+ $(call if_changed,cobjbin)
+
+$(obj)/kernel-compat.c:
+ @touch $@
+
+$(obj)/kernel-compat.o: $(obj)/kernel-compat.c
$(obj)/vmlinux-cuimage.bin
+ $(call if_changed_dep,bootcc)
+ $(call cmd,addsection_cuimage)
+
+$(obj)/vmlinux-compat.elf: $(obj-boot) $(obj)/kernel-compat.o
+ $(call cmd,bootld,$(obj-boot) $(obj)/kernel-compat.o,cuImage.lds)
+ # need a more automated way to do this
+ sh fdt_attach.sh --fdt ../sandpoint_v3.dtb
arch/powerpc/boot/vmlinux-compat.elf
+
+$(obj)/vmlinux-compat.bin: $(obj)/vmlinux-compat.elf
+ $(call if_changed,objbin)
+
+$(obj)/vmlinux-compat.gz: $(obj)/vmlinux-compat.bin
+ $(call if_changed,mygzip)
+
+ENTRY=`objdump -t arch/powerpc/boot/vmlinux-compat.elf | gawk --
'{if($$5=="_zimage_start") {print $$1;}}'`
+
+$(obj)/cuImage: $(obj)/vmlinux-compat.gz $(obj-boot)
+ $(Q)rm -f $@
+ $(call cmd,cuimage,$(ENTRY))
+ @echo -n ' Image: $@ '
+ @if [ -f $@ ]; then echo 'is ready' ; else echo 'not made'; fi
+
+clean-files += vmlinux-compat.elf vmlinux-compat.bin vmlinux-compat.gz
cuImage kernel-compat.c
+
diff --git a/arch/powerpc/boot/cuImage.lds
b/arch/powerpc/boot/cuImage.lds
new file mode 100644
index 0000000..073e19c
--- /dev/null
+++ b/arch/powerpc/boot/cuImage.lds
@@ -0,0 +1,45 @@
+OUTPUT_ARCH(powerpc:common)
+ENTRY(_zimage_start)
+SECTIONS
+{
+ . = 0;
+
+ _vmlinux_start = .;
+ .kernel:vmlinux.bin : { *(.kernel:vmlinux.bin) }
+ _vmlinux_end = .;
+
+/* initrd still needs work */
+ _initrd_start = .;
+ _initrd_end = .;
+
+ _start = .;
+ .text :
+ {
+ *(.text)
+ *(.fixup)
+ }
+ _etext = .;
+ . = ALIGN(4096);
+ .data :
+ {
+ *(.rodata*)
+ *(.data*)
+ *(.sdata*)
+ __got2_start = .;
+ *(.got2)
+ __got2_end = .;
+ }
+
+ . = ALIGN(4096);
+ _edata = .;
+
+ . = ALIGN(4096);
+ __bss_start = .;
+ .bss :
+ {
+ *(.sbss)
+ *(.bss)
+ }
+ . = ALIGN(4096);
+ _end = . ;
+}
diff --git a/arch/powerpc/boot/main.c b/arch/powerpc/boot/main.c
index 0e49f58..a67844b 100644
--- a/arch/powerpc/boot/main.c
+++ b/arch/powerpc/boot/main.c
@@ -286,7 +286,7 @@ void start(unsigned long a1, unsigned lo
memset(__bss_start, 0, _end - __bss_start);
- ops = platform_init(promptr);
+ ops = platform_init(promptr, a1);
/* Override the dt_ops if there was an fdt attached to the zImage */
if (strcmp(dt_blob_start, EMPTY_SECTION_STR))
@@ -301,7 +301,8 @@ void start(unsigned long a1, unsigned lo
if (ops->platform_ops->fixups)
ops->platform_ops->fixups();
- prep_kernel(&a1, &a2, sp);
+ if (((unsigned long)_vmlinux_start) != 0)
+ prep_kernel(&a1, &a2, sp);
/* If cmdline came from zimage wrapper or if we can edit the one
* in the dt, print it out and edit it, if possible.
diff --git a/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
index 94d97b0..354d0a6 100644
--- a/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -65,7 +65,7 @@ struct ops {
extern struct ops *ops;
-extern struct ops *platform_init(void *promptr);
+extern struct ops *platform_init(void *promptr, unsigned long a1);
extern struct fw_ops *dink_init(void);
extern struct dt_ops *fdt_init(void *dt_blob);
extern struct console_ops *ns16550_init(void);
diff --git a/arch/powerpc/boot/sandpoint.c
b/arch/powerpc/boot/sandpoint.c
index 0fe15b9..0feabbf 100644
--- a/arch/powerpc/boot/sandpoint.c
+++ b/arch/powerpc/boot/sandpoint.c
@@ -22,6 +22,8 @@ #define CPU_7XX 1
#define CPU_7457 2
#define CPU_NUM 3
+unsigned long bd_saved;
+
static u32 cpu_pll[CPU_NUM][32] = {
[CPU_824X] = { /* 824x */
5, 6, 9, 4, 4, 5, 2, 6, 6, 4, 9, 6, 5, 7, 6, 7,
@@ -84,6 +86,13 @@ #define mfspr(rn) ({unsigned long rval;
asm volatile("mfspr %0," __stringify(rn) \
: "=r" (rval)); rval;})
+#define SANDPOINT_UBOOT_LINK_ADDR 0xfff00000
+#define UBOOT_MAGIC 0x27051956
+#define UBOOT_BD_MEMSTART_OFFSET 0
+#define UBOOT_BD_MEMSIZE_OFFSET 1
+#define UBOOT_BD_CLOCKFREQ_OFFSET 11
+#define UBOOT_BD_BUSFREQ_OFFSET 12
+
static void
sandpoint_fixups(void)
{
@@ -91,7 +100,28 @@ sandpoint_fixups(void)
void *devp;
struct processor_info *pit;
extern u32 mpc10x_get_mem_size(void);
-
+ u32 *test_addr = (u32 *)SANDPOINT_UBOOT_LINK_ADDR;
+ u32 *bd = (u32 *)bd_saved;
+
+ switch (*test_addr) {
+ case UBOOT_MAGIC:
+ if ((devp = finddevice("/cpus/PowerPC,603e"))) {
+ v[0] = bd[UBOOT_BD_CLOCKFREQ_OFFSET];
+ setprop(devp, "clock-frequency", v, sizeof(v[0]));
+ v[0] = bd[UBOOT_BD_BUSFREQ_OFFSET] / 4;
+ setprop(devp, "timebase-frequency", v, sizeof(v[0]));
+ }
+ if ((devp = finddevice("/soc10x@fc000000"))) {
+ v[0] = bd[UBOOT_BD_BUSFREQ_OFFSET];
+ setprop(devp, "clock-frequency", v, sizeof(v[0]));
+ }
+ if ((devp = finddevice("/memory"))) {
+ v[0] = bd[UBOOT_BD_MEMSTART_OFFSET];
+ v[1] = bd[UBOOT_BD_MEMSIZE_OFFSET] + v[0];
+ setprop(devp, "reg", v, sizeof(v));
+ }
+ break;
+ default:
/* Update cpu's clock-frequency & timebase-frequency in fdt */
if ((pit = get_processor_info(mfspr(SPRN_PVR)))) {
if ((devp = finddevice("/cpus/PowerPC,603e"))) {
@@ -118,6 +148,8 @@ sandpoint_fixups(void)
v[1] = min(i, max_mem);
setprop(devp, "reg", v, sizeof(v));
}
+ break;
+ }
/* XXXX stuff from platforms/.../sandpoint.c should be here */
}
@@ -139,8 +171,10 @@ static struct ops sandpoint_ops;
static struct platform_ops sandpoint_platform_ops;
struct ops *
-platform_init(void *promptr)
+platform_init(void *promptr, unsigned long a1)
{
+ bd_saved = a1;
+
sandpoint_platform_ops.fixups = sandpoint_fixups;
sandpoint_platform_ops.exit = sandpoint_reset;
^ permalink raw reply related
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