Date: Wed, 3 Aug 2016 12:38:02 +0900 (JST) From: Mori Hiroki <yamori813@yahoo.co.jp> To: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: objdump patch for sbin/init Segmentation fault Message-ID: <804749.19762.qm@web101706.mail.ssk.yahoo.co.jp>
next in thread | raw e-mail | index | archive | help
Hi=0A=0AI have problem sbin/init=C2=A0disassemble by objdump command. I mak=
e path this problem.=C2=A0=0A=0Amicroserver % `find tmp/arm.arm/ -name objd=
ump -type f | head -1` -d Planex_MZK-=0AW04G_rootfs_clean/sbin/init=0A=0APl=
anex_MZK-W04G_rootfs_clean/sbin/init: =C2=A0 =C2=A0 file format elf32-littl=
earm=0A=0ADisassembly of section .init:=0A=0A00008140 <.init>:=0ASegmentati=
on fault (core dumped)=0Amicroserver % gdb `find tmp/arm.arm/ -name objdump=
-type f | head -1` objdump.co=0Are=0AGNU gdb 6.1.1 [FreeBSD]=0ACopyright 2=
004 Free Software Foundation, Inc.=0AGDB is free software, covered by the G=
NU General Public License, and you are=0Awelcome to change it and/or distri=
bute copies of it under certain conditions.=0AType "show copying" to see th=
e conditions.=0AThere is absolutely no warranty for GDB.=C2=A0 Type "show w=
arranty" for details.=0AThis GDB was configured as "amd64-marcel-freebsd"..=
.=0ACore was generated by `objdump'.=0AProgram terminated with signal 11, S=
egmentation fault.=0A#0=C2=A0 0x00000000004311a6 in print_insn (pc=3D33088,=
info=3D0x7fffffffe800, little=3D1)=0A=C2=A0 =C2=A0 at /storage/home/hiroki=
/freebsd/gnu/usr.bin/binutils/libopcodes/../../../../=0Acontrib/binutils/op=
codes/arm-dis.c:3990=0A3990=C2=A0 =C2=A0 =C2=A0 if (info->symtab !=3D NULL=
=0A(gdb) where=0A#0=C2=A0 0x00000000004311a6 in print_insn (pc=3D33088, inf=
o=3D0x7fffffffe800, little=3D1)=0A=C2=A0 =C2=A0 at /storage/home/hiroki/fre=
ebsd/gnu/usr.bin/binutils/libopcodes/../../../../=0Acontrib/binutils/opcode=
s/arm-dis.c:3990=0A#1=C2=A0 0x000000000040314e in disassemble_section (abfd=
=3D0x800c09140,=C2=A0=0A=C2=A0 =C2=A0 section=3D0x800c32140, info=3D0x7ffff=
fffe800)=0A=C2=A0 =C2=A0 at /storage/home/hiroki/freebsd/gnu/usr.bin/binuti=
ls/objdump/../../../../con=0Atrib/binutils/binutils/objdump.c:1470=0A#2=C2=
=A0 0x0000000000436d1c in uM=E7=8A=AFIH=E6=B3=A2Q0=E8=9D=9F ()=0A#3=C2=A0 0=
x0000000000401bf6 in dump_bfd (abfd=3D0x800c09140)=0A=C2=A0 =C2=A0 at /stor=
age/home/hiroki/freebsd/gnu/usr.bin/binutils/objdump/../../../../con=0Atrib=
/binutils/binutils/objdump.c:2012=0A#4=C2=A0 0x0000000000400de3 in display_=
bfd (abfd=3D<value optimized out>)=0A=C2=A0 =C2=A0 at /storage/home/hiroki/=
freebsd/gnu/usr.bin/binutils/objdump/../../../../con=0Atrib/binutils/binuti=
ls/objdump.c:2945=0A#5=C2=A0 0x0000000000400d2b in display_file (filename=
=3D<value optimized out>,=C2=A0=0A=C2=A0 =C2=A0 target=3D<value optimized o=
ut>)=0A=C2=A0 =C2=A0 at /storage/home/hiroki/freebsd/gnu/usr.bin/binutils/o=
bjdump/../../../../con=0Atrib/binutils/binutils/objdump.c:3026=0A#6=C2=A0 0=
x0000000000400adb in main (argc=3D3, argv=3D0x7fffffffea08)=0A=C2=A0 =C2=A0=
at /storage/home/hiroki/freebsd/gnu/usr.bin/binutils/objdump/../../../../c=
on=0Atrib/binutils/binutils/objdump.c:3265=0ACurrent language:=C2=A0 auto; =
currently minimal=0A(gdb) p info->symtab=0A$1 =3D (asymbol **) 0x800c30058=
=0A(gdb) p *info->symtab=0A$2 =3D (asymbol *) 0x0=0A(gdb)=C2=A0=0A=0A=0Adif=
f --git a/contrib/binutils/opcodes/arm-dis.c b/contrib/binutils/opcodes/arm=
-dis.c=0Aindex b6ce5c6..6fb6930 100644=0A--- a/contrib/binutils/opcodes/arm=
-dis.c=0A+++ b/contrib/binutils/opcodes/arm-dis.c=0A@@ -3988,6 +3988,7 @@ p=
rint_insn (bfd_vma pc, struct disassemble_info *info, bfd_boolean li=0Attle=
)=0A=C2=A0=C2=A0 /* First check the full symtab for a mapping symbol, even =
if there=0A=C2=A0 =C2=A0 =C2=A0 are no usable non-mapping symbols for this =
address.=C2=A0 */=0A=C2=A0=C2=A0 if (info->symtab !=3D NULL=0A+=C2=A0 =C2=
=A0 =C2=A0 && *info->symtab !=3D NULL=0A=C2=A0=C2=A0 =C2=A0 =C2=A0 && bfd_a=
symbol_flavour (*info->symtab) =3D=3D bfd_target_elf_flavour)=0A=C2=A0=C2=
=A0 =C2=A0 {=0A=C2=A0=C2=A0 =C2=A0 =C2=A0 bfd_vma addr;=0A=0A=0ARegards=0A=
=0AHiroki Mori
From owner-freebsd-arm@freebsd.org Wed Aug 3 03:49:13 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
Delivered-To: freebsd-arm@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60A1BBAB134
for <freebsd-arm@mailman.ysv.freebsd.org>;
Wed, 3 Aug 2016 03:49:13 +0000 (UTC)
(envelope-from ticso@cicely7.cicely.de)
Received: from raven.bwct.de (raven.bwct.de [85.159.14.73])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "raven.bwct.de", Issuer "BWCT" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id D97B5190B
for <FreeBSD-arm@freebsd.org>; Wed, 3 Aug 2016 03:49:11 +0000 (UTC)
(envelope-from ticso@cicely7.cicely.de)
Received: from mail.cicely.de ([10.1.1.37])
by raven.bwct.de (8.13.4/8.13.4) with ESMTP id u733mvwP039474
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
for <FreeBSD-arm@freebsd.org>; Wed, 3 Aug 2016 05:48:58 +0200 (CEST)
(envelope-from ticso@cicely7.cicely.de)
Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9])
by mail.cicely.de (8.14.5/8.14.4) with ESMTP id u733mqG0011218
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Wed, 3 Aug 2016 05:48:52 +0200 (CEST)
(envelope-from ticso@cicely7.cicely.de)
Received: from cicely7.cicely.de (localhost [127.0.0.1])
by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id u733mqJR021444;
Wed, 3 Aug 2016 05:48:52 +0200 (CEST)
(envelope-from ticso@cicely7.cicely.de)
Received: (from ticso@localhost)
by cicely7.cicely.de (8.15.2/8.15.2/Submit) id u733mpOM021443;
Wed, 3 Aug 2016 05:48:51 +0200 (CEST) (envelope-from ticso)
Date: Wed, 3 Aug 2016 05:48:51 +0200
From: Bernd Walter <ticso@cicely7.cicely.de>
To: FreeBSD-arm@freebsd.org
Cc: Bernd Walter <ticso@cicely7.cicely.de>
Subject: Re: SPI on Raspberry B+
Message-ID: <20160803034851.GC18406@cicely7.cicely.de>
Reply-To: ticso@cicely.de
References: <20160803032830.GB18406@cicely7.cicely.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160803032830.GB18406@cicely7.cicely.de>
X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64
User-Agent: Mutt/1.5.11
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9,
T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0
X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>;
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2016 03:49:13 -0000
On Wed, Aug 03, 2016 at 05:28:30AM +0200, Bernd Walter wrote:
> I'm currently writing a kernel driver for APA102 LEDs on 11-BETA3.
> With some help of older threads on this list I've managed to
> get my driver attached and sending data.
> However, what I didn't manged yet is setting the SPI parameters.
>
> The SPI mode seems to match fine.
>
> The byte order is unfortunately wrong.
> I need MSB first and the driver is sending LSB first.
> Of course I could rotate all the bits, but would like to avoid it
> for performance reasons.
>
> The clock is only 500kHz according to scope.
> I've heared that there is no device specific speed support, but since I'm
> not using any other SPI device setting the global speed would be fine.
I've found out about sysctl dev.spi.0.clock.
That works fine.
> I'm calling SPIBUS_TRANSFER with multiple bytes.
> There is a gap of 2 microseconds between the bytes.
> Don't know if it just skipping a full clock cycle and the gap will
> be shorter with a higher clockrate, or if the driver really needs
> 2 full microseconds between each bytes.
> I somehow believe (and hope) it is just a full cycle in the controller.
It also remains at one clock cycle gap, so with higher speed the
gap will be shorter as well.
Unfortunately there is no byteorder sysctl.
--
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?804749.19762.qm>