* Re: [PATCH] kexec: remove memory reserve patching for powerpc device tree
From: Michael Ellerman @ 2006-09-21 1:59 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, Fastboot mailing list
In-Reply-To: <20060921011031.4BFEA67BCE@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 892 bytes --]
On Thu, 2006-09-21 at 11:10 +1000, Michael Neuling wrote:
> This code no longer needed with Jimi's auto reserve of device tree blob
> kernel patch now in 2.6.18.
>
> This patch will break Linux if you're kexecing to a kernel which doesn't
> have this patch (ie. earlier than 2.6.17). Required kernel patch is
> this one:
> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4d1f3f25d9c303d1ce63b42cc94c54ac0ab2e950
>
Although it'd be nice to get rid of that code, I'm not sure we want to
go breaking this. This will mean RHEL5 and SLES10 users can't use
upstream kexec-tools :/
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* [PATCH] kexec: remove memory reserve patching for powerpc device tree
From: Michael Neuling @ 2006-09-21 1:10 UTC (permalink / raw)
To: Fastboot mailing list, linuxppc-dev
This code no longer needed with Jimi's auto reserve of device tree blob
kernel patch now in 2.6.18.
This patch will break Linux if you're kexecing to a kernel which doesn't
have this patch (ie. earlier than 2.6.17). Required kernel patch is
this one:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4d1f3f25d9c303d1ce63b42cc94c54ac0ab2e950
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
This should be save to include now 2.6.18 has been released.
kexec/arch/ppc64/fs2dt.c | 2 --
kexec/arch/ppc64/kexec-elf-ppc64.c | 19 -------------------
2 files changed, 21 deletions(-)
Index: kexec-tools-1.101/kexec/arch/ppc64/fs2dt.c
===================================================================
--- kexec-tools-1.101.orig/kexec/arch/ppc64/fs2dt.c
+++ kexec-tools-1.101/kexec/arch/ppc64/fs2dt.c
@@ -445,8 +445,6 @@ int create_flatten_tree(struct kexec_inf
bb->version = 2;
bb->last_comp_version = 2;
- reserve(me, bb->totalsize); /* patched later in kexec_load */
-
buf = (unsigned char *) malloc(bb->totalsize);
*bufp = buf;
memcpy(buf, bb, bb->off_mem_rsvmap);
Index: kexec-tools-1.101/kexec/arch/ppc64/kexec-elf-ppc64.c
===================================================================
--- kexec-tools-1.101.orig/kexec/arch/ppc64/kexec-elf-ppc64.c
+++ kexec-tools-1.101/kexec/arch/ppc64/kexec-elf-ppc64.c
@@ -81,8 +81,6 @@ int elf_ppc64_load(int argc, char **argv
off_t seg_size = 0;
struct mem_phdr *phdr;
size_t size;
- unsigned long long *rsvmap_ptr;
- struct bootblock *bb_ptr;
unsigned int nr_segments, i;
int result, opt;
unsigned long my_kernel, my_dt_offset;
@@ -249,23 +247,6 @@ int elf_ppc64_load(int argc, char **argv
0, 0, max_addr, -1);
}
- /* patch reserve map address for flattened device-tree
- * find last entry (both 0) in the reserve mem list. Assume DT
- * entry is before this one
- */
- bb_ptr = (struct bootblock *)(
- (unsigned char *)info->segment[(info->nr_segments)-1].buf);
- rsvmap_ptr = (unsigned long long *)(
- (unsigned char *)info->segment[(info->nr_segments)-1].buf +
- bb_ptr->off_mem_rsvmap);
- while (*rsvmap_ptr || *(rsvmap_ptr+1))
- rsvmap_ptr += 2;
- rsvmap_ptr -= 2;
- *rsvmap_ptr = (unsigned long long)(
- info->segment[(info->nr_segments)-1].mem);
- rsvmap_ptr++;
- *rsvmap_ptr = (unsigned long long)bb_ptr->totalsize;
-
nr_segments = info->nr_segments;
/* Set kernel */
^ permalink raw reply
* Re: Hang with isync
From: Manoj Sharma @ 2006-09-21 0:59 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev
In-Reply-To: <20060920230406.GU29167@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 924 bytes --]
No MSR is 00029030 and user mode bit is not set here.
I had missed it in the prev mail:
\x05NIP: C0005DA4 XER: 20000000 LR: C0004FE4 SP: C01F3000\x05 REGS: c01eff30 TRAP:
1020 Not tainted
MSR: 00029030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c01f1080[0] 'swapper' Last syscall: 120
last math 00000000 last altivec 00000000
\x05PLB0: bear= 0x08000000 acr= 0xbb000000 besr= 0x00000000
On 9/20/06, Linas Vepstas <linas@austin.ibm.com> wrote:
>
> On Thu, Sep 21, 2006 at 08:38:13AM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2006-09-20 at 15:31 -0700, Manoj Sharma wrote:
> > > This is the stack trace.
> > >
> > > Registers:
> > > GPR00: 00069030
>
> This is the MSR and it has the user-mode bit set, which is surely wrong.
> This is not how one gets to user space.
>
> 00048000
>
> The MSR had this or'ed into it, which is setting the user-mode bit.
> Surely that's wrong.
>
> --linas
>
[-- Attachment #2: Type: text/html, Size: 1284 bytes --]
^ permalink raw reply
* Re: First cut of "wrapper" program
From: Geoff Levand @ 2006-09-21 0:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17681.53490.705075.155580@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> # -s tree.dts specify device-tree source file (needs dts installed)
^^^ dtc
^ permalink raw reply
* Re: [POWERPC] merge iSeries i/o operations with the rest
From: Michael Ellerman @ 2006-09-21 0:20 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus, Hollis Blanchard
In-Reply-To: <20060921100315.89d74f6f.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 988 bytes --]
On Thu, 2006-09-21 at 10:03 +1000, Stephen Rothwell wrote:
> Hi Hollis,
>
> On Wed, 20 Sep 2006 11:01:36 -0500 Hollis Blanchard <hollisb@us.ibm.com> wrote:
> >
> > On Wed, 2006-09-20 at 22:15 +1000, Stephen Rothwell wrote:
> > > + if (firmware_has_feature(FW_FEATURE_ISERIES)) {
> > > + BUG();
> > > + return;
> > > + }
> >
> > Shouldn't all these be BUG_ON(firmware_has_feature(FW_FEATURE_ISERIES))?
>
> In this case, the return helps because the compiler will not generate the
> following code in iSeries only builds. If we could tell the compiler
> that BUG() and BUG_ON() won't return, then BUG_ON() would be better.
Just put a return in the BUG_ON() macro ;D
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* MPC5200b kernel module memory mapping
From: Steven Kaiser @ 2006-09-21 0:09 UTC (permalink / raw)
To: linuxppc-embedded
In a kernel module, I am trying to iomemory map or ioport map a range of
addresses so later I can talk directly to custom external hardware. I have
tried to follow the advice of Rubini chapter 8. I think I am setting it up
correctly, but at the precise moment I try to write anything within my
range, the kernel crashes badly. My board is a Lite5200b, using a 2.4.25
kernel.
#define MALab_DEVICE_NAME "MALab"
#define MALab_MM_START 0x60000000U
#define MALab_MM_END 0x6000ffffU
#define MALab_MM_SIZE 0x00010000U
#define MPC5xxx_MM_CS2_START (MPC5xxx_MBAR + 0x0014)
#define MPC5xxx_MM_CS2_STOP (MPC5xxx_MBAR + 0x0018)
#define MPC5xxx_MM_IPBI (MPC5xxx_MBAR + 0x0054)
void *ioaddr = NULL;
// start 'em up
int init_module(void) {
register_chrdev(...
// reserve a page of memory for our hardware /proc/iomem
if ( check_region(MALab_MM_START,MALab_MM_SIZE) ) {
printk (KERN_ALERT "LED init_module: memory already in
use\n");
return -EBUSY;
}
request_region(MALab_MM_START,MALab_MM_SIZE,MALab_DEVICE_NAME);
// enable LocalBus Chip Select CS2 to hit on our address range
*(volatile u32 *)MPC5xxx_MM_IPBI &= ~0x00040000;
*(volatile u16 *)(MPC5xxx_MM_CS2_START + 2) = MALab_MM_START >> 16;
*(volatile u16 *)(MPC5xxx_MM_CS2_STOP + 2) = MALab_MM_END >> 16;
*(volatile u32 *)MPC5xxx_MM_IPBI |= 0x00040000;
// map our physical address into kernal virtual address space
// do I need this call?
ioaddr = ioremap(MALab_MM_START,MALab_MM_SIZE);
return 0;
}
Later (in a ioctrl routine), I will try and write something to the first
location in my address range. I tried these three ways:
*(volatile u16 *)MALab_MM_START = 0x5555;
outw(0x5555,MALab_MM_START);
outw(0x5555,ioaddr);
Any and all of the these calls crash the kernel so horrendously I have to
reboot. Sometimes I have to delete and mknod a new /dev entry.
I have tried the io memory map technique instead of the above io port map
technique, using request_mem_region(), with the same crashing results upon
any writew() call or direct variants. I tried things without the ioremap()
call-- I get a segmentation fault in these cases.
The request_region() or request_mem_region() seems to work ok. I can cat
/proc/iomem or /proc/ioports and see my range in there. I am pretty sure I
am setting up the LocalBus chip select registers ok.
Yet obviously I am doing something profoundly stupid. Is my error obvious?
Can someone enlighten me in my darkness?
Steven Kaiser
Chemistry Electronics Facility
University of California, Irvine
2347 Natural Sciences 2
Irvine, CA 92697-2025
(949)824-7520
^ permalink raw reply
* Re: [PATCH] Start arch/powerpc/boot code reorganization
From: Segher Boessenkool @ 2006-09-21 0:07 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <20060920215738.GC24809@mag.az.mvista.com>
>>> So please comment the nastiness with a big "HACK HACK HACK"
>>> comment and
>>> make sure it only ever gets used on systems where nothing better is
>>> available, and all should be fine.
>>
>> An option is to call it something like fw,address to avoid
>> confusion and
>> make it somewhat clearer that it's really a firmware address useable
>> within the context of the firmware...
>
> Okay. We did talk about that but then we realized that "address"
> was for vaddrs. We thought of other names like "bootwrapper-vaddr"
> etc. but "fw,address" or "fw,vaddr" are probably better--they show
> that
> the vaddr was setup by the fw.
If you use a different name than "address", you're not bound to its
semantics either. And as those semantics have some problems, please
do change-em. How about:
The "reg-virtual-address" property contains the same regions as the
"reg" property, in the same order; each entry is #address-cells from
the root node 32-bit integers wide(*); the entry describes a
contiguous area of virtual memory of the same size as the
corresponding "reg" entry, mapping that area, or 0 if the area isn't
mapped.
Any holes in this definition?
Segher
(*) This isn't strictly correct, but OF doesn't describe the size of
virtual addresses anywhere. In practice, it's the same as the size
of physical addresses always. Oh, and the name "virtual" isn't correct
in PowerPC-speak anyway, heh.
^ permalink raw reply
* Re: [POWERPC] merge iSeries i/o operations with the rest
From: Stephen Rothwell @ 2006-09-21 0:03 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: ppc-dev, paulus
In-Reply-To: <1158768096.19375.6.camel@basalt.austin.ibm.com>
Hi Hollis,
On Wed, 20 Sep 2006 11:01:36 -0500 Hollis Blanchard <hollisb@us.ibm.com> wrote:
>
> On Wed, 2006-09-20 at 22:15 +1000, Stephen Rothwell wrote:
> > + if (firmware_has_feature(FW_FEATURE_ISERIES)) {
> > + BUG();
> > + return;
> > + }
>
> Shouldn't all these be BUG_ON(firmware_has_feature(FW_FEATURE_ISERIES))?
In this case, the return helps because the compiler will not generate the
following code in iSeries only builds. If we could tell the compiler
that BUG() and BUG_ON() won't return, then BUG_ON() would be better.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* Re: Linux on custom Xilinx board with PPC405 hangs on boot
From: Linas Vepstas @ 2006-09-20 23:57 UTC (permalink / raw)
To: Peter N. Andreasen; +Cc: linuxppc-dev
In-Reply-To: <36468a5c0609200216n753d69b0hdf8ff2cb53714f90@mail.gmail.com>
On Wed, Sep 20, 2006 at 11:16:53AM +0200, Peter N. Andreasen wrote:
> I have a custom Xilinx FPGA board which is similar to ML300 but uses
> Uartllite and does not have disk or display.
> When I start the Linux kernel I end up with an exception during the probe
> for Flash - I think.
Well, its not just "an exception" its a machine check.
> (after get_mtd_chip_driver) drivers/mtd/chips/chipreg.c: do_map_probe
> (start) drivers/mtd/chips/gen_probe.c: mtd_do_chip_probe
> (start) drivers/mtd/chips/gen_probe.c: genprobe_ident_chips
> Instruction machine check in kernel mode.
> Oops: machine check, sig: 7
> NIP: C00A2960 XER: 40000000 LR: C009CBD8 SP: C04D9D90 REGS: c04d9ce0 TRAP:
> 0200 Not tainted
> MSR: 00009030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
Machine checks happen when some hunk of hardware is wired to the
machine-check pin of the cpu chip, and that bit of hardware decides to
raise the wire. I'd say the first step is to figure ou what hardware
is wired up this way, and what would make it unhappy enough to assert a
machine check.
SRR1 has bits that state what caused he machine check. -- e.g partity
error on data or address bus, "transfer error", or MC signal.
--linas
^ permalink raw reply
* First cut of "wrapper" program
From: Paul Mackerras @ 2006-09-20 23:38 UTC (permalink / raw)
To: linuxppc-dev
Here is a prototype of a "wrapper" program which will take a kernel,
and optionally an initrd image and/or a device tree blob, and create a
bootable zImage. My idea is that the Makefile in arch/powerpc/boot
will construct the files that this needs, then run it one or more
times to create whatever images are needed.
The type of zImage that is created is selected with the -p flag. This
also specifies an extra object file to be linked in that will contain
the platform_init() function. So for the xyzzy platform, we would
arrange for an xyzzy.o to be made in arch/powerpc/boot, and for the
wrapper to be invoked with "-p xyzzy".
Currently the wrapper uses the strip, objcopy and ld programs, which
need to be the powerpc cross-utilities if you are cross-building. You
can use the -C flag to specify a prefix for these programs if
necessary.
It also uses several files which it gets from a data directory, which
is by default ./arch/powerpc/boot, but which can be changed with the
-D flag. The files it needs from there are:
a platform-specific object file (of.o for OF-based platforms)
crt0.o
empty.o
wrapper.a
zImage.lds
zImage.coff.lds
addnote
hack-coff
Although this will start out in arch/powerpc/boot, my idea is that it
is a stand-alone thing that could be pulled out and built and used
quite independently of the kernel source tree. For this reason I
really want to avoid using CONFIG_* symbols in the code.
Comments?
Paul.
#!/bin/sh
# Copyright (C) 2006 Paul Mackerras, IBM Corporation <paulus@samba.org>
# This program may be used under the terms of version 2 of the GNU
# General Public License.
# This script takes a kernel binary and optionally an initrd image
# and/or a device-tree blob, and creates a bootable zImage for a
# given platform.
# Options:
# -o zImage specify output file
# -p platform specify platform (links in $platform.o)
# -i initrd specify initrd file
# -d devtree specify device-tree blob
# -s tree.dts specify device-tree source file (needs dts installed)
# -c cache $kernel.strip.gz (use if present & newer, else make)
# -C prefix specify command prefix for cross-building tools
# (strip, objcopy, ld)
# -D dir specify directory containing data files used by script
# (default ./arch/powerpc/boot)
# -W dir specify working directory for temporary files (default .)
# defaults
kernel=
ofile=zImage
platform=of
initrd=
dtb=
dts=
cacheit=
# cross-compilation prefix
CROSS=
# directory for object and other files used by this script
object=arch/powerpc/boot
# directory for working files
tmpdir=.
usage() {
echo 'Usage: wrapper [-o output] [-p platform] [-i initrd]' >&2
echo ' [-d devtree] [-s tree.dts] [-c] [-C cross-prefix]' >&2
echo ' [-D datadir] [-W workingdir] [vmlinux]' >&2
exit 1
}
while [ "$#" -gt 0 ]; do
case "$1" in
-o)
shift
[ "$#" -gt 0 ] || usage
ofile="$1"
;;
-p)
shift
[ "$#" -gt 0 ] || usage
platform="$1"
;;
-i)
shift
[ "$#" -gt 0 ] || usage
initrd="$1"
;;
-d)
shift
[ "$#" -gt 0 ] || usage
dtb="$1"
;;
-s)
shift
[ "$#" -gt 0 ] || usage
dts="$1"
;;
-c)
cacheit=y
;;
-C)
shift
[ "$#" -gt 0 ] || usage
CROSS="$1"
;;
-D)
shift
[ "$#" -gt 0 ] || usage
object="$1"
;;
-W)
shift
[ "$#" -gt 0 ] || usage
tmpdir="$1"
;;
-?)
usage
;;
*)
[ -z "$kernel" ] || usage
kernel="$1"
;;
esac
shift
done
if [ -n "$dts" ]; then
if [ -z "$dtb" ]; then
dtb="$platform.dtb"
fi
dtc -O dtb -o "$dtb" -b 0 -V 16 "$dts" || exit 1
fi
if [ -z "$kernel" ]; then
kernel=vmlinux
fi
platformo=$object/"$platform".o
lds=$object/zImage.lds
case "$platform" in
pmac|pseries)
platformo=$object/of.o
;;
pmaccoff)
platformo=$object/of.o
lds=$object/zImage.coff.lds
;;
miboot)
# this is quite different...
tmpvm=$tmpdir/vmlinux.bin.$$
${CROSS}objcopy -O binary "$kernel" $tmpvm
gzip -f -9 $tmpvm
tmpir=
if [ -n "$initrd" ]; then
tmpir=--add-section=initrd="$initrd"
fi
${CROSS}objcopy -O aixcoff-rs6000 -R .stab -R .stabstr -R .comment \
--add-section=image=$tmpvm.gz $tmpir \
$object/empty.o "$ofile"
rm $tmpvm.gz
exit 0
esac
tmp=$tmpdir/zImage.$$.o
cp $object/empty.o $tmp
addsec() {
${CROSS}objcopy $1 \
--add-section=.kernel:$3="$2" \
--set-section-flags=.kernel:$3=contents,alloc,load,readonly,data
}
if [ -n "$cacheit" ]; then
vmz="$tmpdir/`basename \"$kernel\"`.strip"
if [ ! -f "$vmz.gz" -o "$vmz.gz" -ot "$kernel" ]; then
cp "$kernel" "$vmz"
${CROSS}strip "$vmz"
gzip -f -9 "$vmz"
fi
addsec $tmp "$vmz.gz" vmlinux.strip
else
tmpvmz=$tmpdir/vmlinux.$$
cp "$kernel" $tmpvmz
${CROSS}strip $tmpvmz
gzip -f -9 $tmpvmz
addsec $tmp $tmpvmz.gz vmlinux.strip
rm $tmpvmz.gz
fi
if [ -n "$initrd" ]; then
addsec $tmp "$initrd" initrd
fi
if [ -n "$dtb" ]; then
addsec $tmp "$dtb" dtb
fi
${CROSS}ld -m elf32ppc -T $lds -o "$ofile" \
$object/crt0.o $platformo $tmp $object/wrapper.a
rm $tmp
# post-processing needed for some platforms
case "$platform" in
pseries)
$object/addnote "$ofile"
;;
pmaccoff)
${CROSS}objcopy -O aixcoff-rs6000 --set-start 0x500000 "$ofile"
$object/hack-coff "$ofile"
;;
esac
^ permalink raw reply
* Re: Hang with isync
From: Linas Vepstas @ 2006-09-20 23:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1158791893.6002.327.camel@localhost.localdomain>
On Thu, Sep 21, 2006 at 08:38:13AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2006-09-20 at 15:31 -0700, Manoj Sharma wrote:
> > This is the stack trace.
> >
> > Registers:
> > GPR00: 00069030
This is the MSR and it has the user-mode bit set, which is surely wrong.
This is not how one gets to user space.
00048000
The MSR had this or'ed into it, which is setting the user-mode bit.
Surely that's wrong.
--linas
^ permalink raw reply
* Re: Hang with isync
From: Benjamin Herrenschmidt @ 2006-09-20 22:38 UTC (permalink / raw)
To: Manoj Sharma; +Cc: linuxppc-dev
In-Reply-To: <d6dada100609201531oefd71ch8557067bbf77484e@mail.gmail.com>
On Wed, 2006-09-20 at 15:31 -0700, Manoj Sharma wrote:
> This is the stack trace.
>
> Registers:
> GPR00: 00069030 C01F3000 C01F1080 00000000 00048000 C0639F48 C01F1080
> FFFFFC18
> GPR08: C02203FC 00000020 C0638000 C01F31B0 42FEE022 1056A7F8 00FE502A
> 00000000
> GPR16: 00000000 FFC44232 00000000 00000000 FFC441EC 00080000 00010000
> 0000000A
> GPR24: 00000000 0007CD80 00000CE0 00000000 00000000 C02B0000 00000000
> C02B0000
>
> NIP; c0005da4 _<_nmask_and_or_msr+0x18/0x20 [kernel]>
> Trace; c0025328 _<check_pgt_cache+0x20/0x30 [kernel]>
> Trace; c0004f4c _<idled+0x58/0x70 [kernel]>
> Trace; c0004f74 _<cpu_idle+0x10/0x24 [kernel]>
> Trace; c00012b0 _<rest_init+0x30/0x40 [kernel]>
> Trace; c02a45a4 _<start_kernel+0x168/0x17c [kernel]>
> Trace; c0000250 _<skpinv+0x1f8/0x234 [kernel]>
Is this upstream 2.6.20 or do you have any additional patches ? (Like
Montavista stuff or RT linux or whatever ?)
It's unclear to me from just that backtrace what mask it is... it could
just be re-enabling interrupt and you have a stale IRQ line asserted....
Have you also checked the errata list for your 405 core, in case it has
a known issue ?
Ben.
>
> On 9/20/06, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Tue, 2006-09-19 at 18:16 -0700, Manoj Sharma wrote:
> > Hi,
> >
> > We use linux kernel 2.4.20 on ppc405 and the system
> hangs once
> > in a while when isync gets called in this function:
> >
> > _GLOBAL(_nmask_and_or_msr)
> > mfmsr r0 /* Get current msr */
> > andc r0,r0,r3 /* And off the bits set in
> r3 (first
> > parm) */`
> > or r0,r0,r4 /* Or on the bits in r4 (second
> parm) */
> > sync /* Some chip revs have problems
> here... */
> > isync
> > mtmsr r0 /* Update machine state */
> > isync
> > blr /* Done */
> >
> > 2.5 onwards, I find that "sync; isync" has been
> replaced by a
> > macro SYNC (defined only for 601). I don't find it
> in any
> > changelog and reason for the change.
> >
> > Can someone give some information on this change?
>
> Regardless of the change... on 2.4, _nmask_and_or_msr() was
> used for a
> number of things. We would need to know where it was called
> from with
> what values as arguments to have an idea of what's going
> wrong. It's
> probably not dying on the isync, but rather on the following
> mtmsr due
> to a problem with the values passed in....
>
> Ben.
>
>
>
>
^ permalink raw reply
* [PATCH]: Powerpc: EEH failure to mark pci slot as frozen.
From: Linas Vepstas @ 2006-09-20 22:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Paul,
Please apply and submit upstream. Shouldn't be urgent, as
none of the existing dev drivers will be subject to this bug.
--linas
Bug fix: when marking a slot as frozen, we forgot to mark
pci device itself as frozen. (we did manage to mark the
pci children, but forget the parent itself.)
This is needed so that some device drivers can check the
pci status in critical sections (e.g. in spin loops with
interrupts disabled).
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh.c | 7 +++++++
1 file changed, 7 insertions(+)
Index: linux-2.6.18-rc7-git1/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- linux-2.6.18-rc7-git1.orig/arch/powerpc/platforms/pseries/eeh.c 2006-09-20 17:18:00.000000000 -0500
+++ linux-2.6.18-rc7-git1/arch/powerpc/platforms/pseries/eeh.c 2006-09-20 17:21:04.000000000 -0500
@@ -225,6 +225,7 @@ static void __eeh_mark_slot (struct devi
void eeh_mark_slot (struct device_node *dn, int mode_flag)
{
+ struct pci_dev *dev;
dn = find_device_pe (dn);
/* Back up one, since config addrs might be shared */
@@ -232,6 +233,12 @@ void eeh_mark_slot (struct device_node *
dn = dn->parent;
PCI_DN(dn)->eeh_mode |= mode_flag;
+
+ /* Mark the pci device too */
+ dev = PCI_DN(dn)->pcidev;
+ if (dev)
+ dev->error_state = pci_channel_io_frozen;
+
__eeh_mark_slot (dn->child, mode_flag);
}
^ permalink raw reply
* Re: Hang with isync
From: Manoj Sharma @ 2006-09-20 22:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1158788111.6002.310.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]
This is the stack trace.
Registers:
GPR00: 00069030 C01F3000 C01F1080 00000000 00048000 C0639F48 C01F1080
FFFFFC18
GPR08: C02203FC 00000020 C0638000 C01F31B0 42FEE022 1056A7F8 00FE502A
00000000
GPR16: 00000000 FFC44232 00000000 00000000 FFC441EC 00080000 00010000
0000000A
GPR24: 00000000 0007CD80 00000CE0 00000000 00000000 C02B0000 00000000
C02B0000
NIP; c0005da4 _<_nmask_and_or_msr+0x18/0x20 [kernel]>
Trace; c0025328 _<check_pgt_cache+0x20/0x30 [kernel]>
Trace; c0004f4c _<idled+0x58/0x70 [kernel]>
Trace; c0004f74 _<cpu_idle+0x10/0x24 [kernel]>
Trace; c00012b0 _<rest_init+0x30/0x40 [kernel]>
Trace; c02a45a4 _<start_kernel+0x168/0x17c [kernel]>
Trace; c0000250 _<skpinv+0x1f8/0x234 [kernel]>
On 9/20/06, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Tue, 2006-09-19 at 18:16 -0700, Manoj Sharma wrote:
> > Hi,
> >
> > We use linux kernel 2.4.20 on ppc405 and the system hangs once
> > in a while when isync gets called in this function:
> >
> > _GLOBAL(_nmask_and_or_msr)
> > mfmsr r0 /* Get current msr */
> > andc r0,r0,r3 /* And off the bits set in r3 (first
> > parm) */`
> > or r0,r0,r4 /* Or on the bits in r4 (second parm) */
> > sync /* Some chip revs have problems here... */
> > isync
> > mtmsr r0 /* Update machine state */
> > isync
> > blr /* Done */
> >
> > 2.5 onwards, I find that "sync; isync" has been replaced by a
> > macro SYNC (defined only for 601). I don't find it in any
> > changelog and reason for the change.
> >
> > Can someone give some information on this change?
>
> Regardless of the change... on 2.4, _nmask_and_or_msr() was used for a
> number of things. We would need to know where it was called from with
> what values as arguments to have an idea of what's going wrong. It's
> probably not dying on the isync, but rather on the following mtmsr due
> to a problem with the values passed in....
>
> Ben.
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 3673 bytes --]
^ permalink raw reply
* Re: [PATCH] Start arch/powerpc/boot code reorganization
From: Mark A. Greer @ 2006-09-20 21:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1158787957.6002.307.camel@localhost.localdomain>
On Thu, Sep 21, 2006 at 07:32:37AM +1000, Benjamin Herrenschmidt wrote:
>
> > So please comment the nastiness with a big "HACK HACK HACK" comment and
> > make sure it only ever gets used on systems where nothing better is
> > available, and all should be fine.
>
> An option is to call it something like fw,address to avoid confusion and
> make it somewhat clearer that it's really a firmware address useable
> within the context of the firmware...
Okay. We did talk about that but then we realized that "address"
was for vaddrs. We thought of other names like "bootwrapper-vaddr"
etc. but "fw,address" or "fw,vaddr" are probably better--they show that
the vaddr was setup by the fw.
Comments?
Mark
^ permalink raw reply
* Re: Hang with isync
From: Benjamin Herrenschmidt @ 2006-09-20 21:35 UTC (permalink / raw)
To: Manoj Sharma; +Cc: linuxppc-dev
In-Reply-To: <d6dada100609191816q75d1455cobeb1e0bd21dab8a8@mail.gmail.com>
On Tue, 2006-09-19 at 18:16 -0700, Manoj Sharma wrote:
> Hi,
>
> We use linux kernel 2.4.20 on ppc405 and the system hangs once
> in a while when isync gets called in this function:
>
> _GLOBAL(_nmask_and_or_msr)
> mfmsr r0 /* Get current msr */
> andc r0,r0,r3 /* And off the bits set in r3 (first
> parm) */
> or r0,r0,r4 /* Or on the bits in r4 (second parm) */
> sync /* Some chip revs have problems here... */
> isync
> mtmsr r0 /* Update machine state */
> isync
> blr /* Done */
>
> 2.5 onwards, I find that "sync; isync" has been replaced by a
> macro SYNC (defined only for 601). I don't find it in any
> changelog and reason for the change.
>
> Can someone give some information on this change?
Regardless of the change... on 2.4, _nmask_and_or_msr() was used for a
number of things. We would need to know where it was called from with
what values as arguments to have an idea of what's going wrong. It's
probably not dying on the isync, but rather on the following mtmsr due
to a problem with the values passed in....
Ben.
^ permalink raw reply
* Re: [PATCH] Start arch/powerpc/boot code reorganization
From: Benjamin Herrenschmidt @ 2006-09-20 21:32 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <A6FD3E5E-94EF-4E12-A0FB-8700F0DF8151@kernel.crashing.org>
> So please comment the nastiness with a big "HACK HACK HACK" comment and
> make sure it only ever gets used on systems where nothing better is
> available, and all should be fine.
An option is to call it something like fw,address to avoid confusion and
make it somewhat clearer that it's really a firmware address useable
within the context of the firmware...
Ben.
^ permalink raw reply
* Re: [PATCH] Remove powerpc specific parts of 3c509 driver
From: Jeff Garzik @ 2006-09-20 21:29 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: akpm, Stephen Rothwell, ppc-dev, netdev
In-Reply-To: <82BFB659-DCB3-477C-B53D-4D8C55BAADB7@kernel.crashing.org>
Segher Boessenkool wrote:
>>>>> Sure, PCI busses are little-endian. But is readX()/writeX() for PCI
>>>>> only?
>>>>
>>>> Yes.
>>>>
>>>> For other buses, use foo_writel(), etc.
>>> Can this please be documented then? Never heard this before...
>>
>> You have come late to the party.
>
> WHat do you mean here? Could you please explain?
>
>> This has been the case for many, many years.
>
> No, it was never documented AFAICS.
A de facto standard does not need to be documented, to be a de facto
standard.
A lot of Linux "standards" are often based on emails from Linus buried
halfway down a thread. A decision gets made, and people follow.
>> And there is no point in a massive rename to pci_writel(), either.
>
> That would be really inconvenient, sure. It's also inconvenient
> that all the nice short names are PCI-only.
Only to you, a decided minority of developers.
Jeff
^ permalink raw reply
* Re: [PATCH] Start arch/powerpc/boot code reorganization
From: Josh Boyer @ 2006-09-20 21:04 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <A6FD3E5E-94EF-4E12-A0FB-8700F0DF8151@kernel.crashing.org>
On Wed, 2006-09-20 at 22:23 +0200, Segher Boessenkool wrote:
> > It was pointed out on IRC that the "address" property is defined in
> > the
> > OF spec for specifying virtual address mappings. This is exactly what
> > we need in that it allows the zImage wrapper to use the fw defined
> > UART
> > mapping, but the kernel still gets the real physical address later on.
> > And other things that don't use zImage wrappers, like u-boot, can
> > simply
> > ignore the "address" property defined within the UART node.
>
> The "address" property has several problems. An obvious one is that the
> name is too generic. A nastier one is that once you start making new
Well, I agree. But it's documented in the spec. Blame the spec
writers ;).
> MMU
> mappings, you have to keep *all* old mappings, or blow away the mapping
> for this "address" as well (you don't know the size of the mapping).
Which we do on 4xx in the kernel (the blow away part).
>
> And
> a third problem is that it can only encode 32-bit virtual addresses.
Which isn't a _current_ problem, since the use case here is the
bootwrapper and that limits itself to 32bit already anyway.
>
> Now, if it's only used for the very-early-debug UART console on machines
> that cannot accesses physical addresses directly, in things like a boot-
> wrapper that cannot be bothered to set up a MMU mapping themselves (and
> there might be good reasons not to), and only when there is no client
> interface (i.e., it uses the flat tree only); then it might be a
> reasonable
> approach. All alternatives I can think of have their own nasty
> problems.
Right, that's where we were at too.
> So please comment the nastiness with a big "HACK HACK HACK" comment and
> make sure it only ever gets used on systems where nothing better is
> available, and all should be fine.
I'll leave that to Mark ;)
josh
^ permalink raw reply
* Re: [PATCH] Start arch/powerpc/boot code reorganization
From: Mark A. Greer @ 2006-09-20 20:58 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060920012843.GA29635@mag.az.mvista.com>
On Tue, Sep 19, 2006 at 06:28:43PM -0700, Mark A. Greer wrote:
> On Tue, Sep 19, 2006 at 06:20:42PM -0700, Mark A. Greer wrote:
> > Paul,
> >
> > Regarding our earlier conversation about ft_translate_addr and
> ...
>
> BTW, the only changes to your patch would be removing translate_addr from
> dt_ops in ops.h and removing the "dt_ops.translate_addr = NULL;" line
> in of.c.
FWIW, here is a patch to do this:
diff -u b/arch/powerpc/boot/of.c b/arch/powerpc/boot/of.c
--- b/arch/powerpc/boot/of.c
+++ b/arch/powerpc/boot/of.c
@@ -270,7 +270,6 @@
dt_ops.finddevice = of_finddevice;
dt_ops.getprop = of_getprop;
dt_ops.setprop = of_setprop;
- dt_ops.translate_addr = NULL;
console_ops.open = of_console_open;
console_ops.write = of_console_write;
diff -u b/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
--- b/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -34,8 +34,6 @@
const int buflen);
int (*setprop)(const void *node, const char *name,
const void *buf, const int buflen);
- u64 (*translate_addr)(const char *path, const u32 *in_addr,
- const u32 addr_len);
unsigned long (*ft_addr)(void);
};
extern struct dt_ops dt_ops;
^ permalink raw reply
* Re: [PATCH] Start arch/powerpc/boot code reorganization
From: Segher Boessenkool @ 2006-09-20 20:23 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1158721828.3043.13.camel@vader.jdub.homelinux.org>
> It was pointed out on IRC that the "address" property is defined in
> the
> OF spec for specifying virtual address mappings. This is exactly what
> we need in that it allows the zImage wrapper to use the fw defined
> UART
> mapping, but the kernel still gets the real physical address later on.
> And other things that don't use zImage wrappers, like u-boot, can
> simply
> ignore the "address" property defined within the UART node.
The "address" property has several problems. An obvious one is that the
name is too generic. A nastier one is that once you start making new
MMU
mappings, you have to keep *all* old mappings, or blow away the mapping
for this "address" as well (you don't know the size of the mapping).
And
a third problem is that it can only encode 32-bit virtual addresses.
Now, if it's only used for the very-early-debug UART console on machines
that cannot accesses physical addresses directly, in things like a boot-
wrapper that cannot be bothered to set up a MMU mapping themselves (and
there might be good reasons not to), and only when there is no client
interface (i.e., it uses the flat tree only); then it might be a
reasonable
approach. All alternatives I can think of have their own nasty
problems.
So please comment the nastiness with a big "HACK HACK HACK" comment and
make sure it only ever gets used on systems where nothing better is
available, and all should be fine.
Segher
^ permalink raw reply
* Re: [PATCH] Remove powerpc specific parts of 3c509 driver
From: Segher Boessenkool @ 2006-09-20 20:06 UTC (permalink / raw)
To: Jeff Garzik; +Cc: akpm, Stephen Rothwell, ppc-dev, netdev
In-Reply-To: <451096FE.1000104@pobox.com>
>>>> Sure, PCI busses are little-endian. But is readX()/writeX() for
>>>> PCI
>>>> only?
>>>
>>> Yes.
>>>
>>> For other buses, use foo_writel(), etc.
>> Can this please be documented then? Never heard this before...
>
> You have come late to the party.
WHat do you mean here? Could you please explain?
> This has been the case for many, many years.
No, it was never documented AFAICS.
> And there is no point in a massive rename to pci_writel(), either.
That would be really inconvenient, sure. It's also inconvenient
that all the nice short names are PCI-only.
Segher
^ permalink raw reply
* Re: [PATCH] adbhid: make KEY_SYSRQ configurable on ADB based machines
From: Aristeu Sergio Rozanski Filho @ 2006-09-20 17:54 UTC (permalink / raw)
To: Brad Boyer; +Cc: linuxppc-dev
In-Reply-To: <20060920053656.GA28326@cynthia.pants.nu>
> On Wed, Sep 20, 2006 at 10:44:59AM -0300, Aristeu Sergio Rozanski Filho wrote:
> > > This patch adds a sysfs entry on /sys/class/adb/keyboard0/sysrq_key to
> > > configure which key will be mapped to KEY_SYSRQ. This is needed to make
> > > sysrq usable on machines which doesn't have current sysrq key. This
> > > patch and the previous two ones has been tested for some days in my
> > > machine without problems.
> > any comments on this one?
>
> The only thing I see is that each ADB keyboard device will have an entry
> in sysfs to change the sysrq key, but they will all set the same global.
> It's a little misleading, but I don't think it's a major issue. And
> before anyone asks, I have in fact had multiple ADB keyboards attached
> to a single machine. It was useful for multi-player games.
yup, I was expecting someone to show up and say it's possible :)
I'll fix this up, thanks Brad
--
Aristeu
^ permalink raw reply
* Re: [PATCH] adbhid: make KEY_SYSRQ configurable on ADB based machines
From: Brad Boyer @ 2006-09-20 5:36 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho; +Cc: linuxppc-dev
In-Reply-To: <20060920134459.GC23803@cathedrallabs.org>
On Wed, Sep 20, 2006 at 10:44:59AM -0300, Aristeu Sergio Rozanski Filho wrote:
> > This patch adds a sysfs entry on /sys/class/adb/keyboard0/sysrq_key to
> > configure which key will be mapped to KEY_SYSRQ. This is needed to make
> > sysrq usable on machines which doesn't have current sysrq key. This
> > patch and the previous two ones has been tested for some days in my
> > machine without problems.
> any comments on this one?
The only thing I see is that each ADB keyboard device will have an entry
in sysfs to change the sysrq key, but they will all set the same global.
It's a little misleading, but I don't think it's a major issue. And
before anyone asks, I have in fact had multiple ADB keyboards attached
to a single machine. It was useful for multi-player games.
Brad Boyer
flar@allandria.com
^ permalink raw reply
* Re: Couldn't find reference for i2c_smbus functinos
From: Eugene Surovegin @ 2006-09-20 17:14 UTC (permalink / raw)
To: Sachin Rane; +Cc: linuxppc-embedded
In-Reply-To: <8584FDC94AFF7640B17B8A89B23B19B34F6576@sbsserver.AlphionCorp.local>
On Wed, Sep 20, 2006 at 11:07:52AM -0400, Sachin Rane wrote:
> Hi,
>
> Following text is from "/usr/local/linux/Doumentation/dev-interface":
> ----------------------------------------------------------------------------------------------------------------------------------
> You can do SMBus level transactions (see documentation file smbus-protocol
> for details) through the following functions:
> __s32 i2c_smbus_write_quick(int file, __u8 value);
> __s32 i2c_smbus_read_byte(int file);
> __s32 i2c_smbus_write_byte(int file, __u8 value);
> __s32 i2c_smbus_read_byte_data(int file, __u8 command);
> __s32 i2c_smbus_write_byte_data(int file, __u8 command, __u8 value);
> __s32 i2c_smbus_read_word_data(int file, __u8 command);
> __s32 i2c_smbus_write_word_data(int file, __u8 command, __u16 value);
> __s32 i2c_smbus_process_call(int file, __u8 command, __u16 value);
> __s32 i2c_smbus_read_block_data(int file, __u8 command, __u8 *values);
> __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
> __u8 *values);
> ---------------------------------------------------------------------------------------
>
> I searched in the 2.6.13 version of Timesys and Suse linux, but I
> didn't find definition or declaration in file
> '/usr/include/linux/i2c-dev.h' and '/usr/include/linux/i2c.h'.
Please, look for this functions in the kernel source tree, not in
user-space headers.
--
Eugene
^ 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