From owner-freebsd-arm@FreeBSD.ORG Sun Oct 5 09:04:58 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3CD396F6; Sun, 5 Oct 2014 09:04:58 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F0EB994B; Sun, 5 Oct 2014 09:04:57 +0000 (UTC) Received: from [192.168.1.104] (p54818A88.dip0.t-ipconnect.de [84.129.138.136]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 2486A1C104D9C; Sun, 5 Oct 2014 11:04:53 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [Bug 193981] panic: vtbuf_fill_locked begin.tp_row 0 must be < screen height 0 on Raspberry PI From: Michael Tuexen In-Reply-To: Date: Sun, 5 Oct 2014 11:04:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: dumbbell@FreeBSD.org X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@FreeBSD.org, danilo@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 09:04:58 -0000 On 04 Oct 2014, at 19:42, bugzilla-noreply@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193981 >=20 > --- Comment #8 from Danilo Egea Gondolfo --- > At this moment I have just a usb/serial cable. I can test with a = monitor but > just on next Monday. Maybe someone in freebsd-arm@ can do it. I can confirm that r272537 boots fine and displays boot messages on the = HDMI output. Best regards Michael >=20 > --=20 > You are receiving this mail because: > You are the assignee for the bug. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 From owner-freebsd-arm@FreeBSD.ORG Sun Oct 5 18:05:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7286D124; Sun, 5 Oct 2014 18:05:23 +0000 (UTC) Received: from mail-gw12.york.ac.uk (mail-gw12.york.ac.uk [144.32.129.162]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 36BD7759; Sun, 5 Oct 2014 18:05:22 +0000 (UTC) Received: from ury.york.ac.uk ([144.32.64.162]:32602) by mail-gw12.york.ac.uk with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1Xaq56-0004yU-F4; Sun, 05 Oct 2014 18:58:52 +0100 Date: Sun, 5 Oct 2014 18:58:51 +0100 (BST) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Alexander Tarasikov Subject: Re: Android Emulator for FreeBSD + FreeBSD/ARM port In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-hackers@freebsd.org, "freebsd-arm@freebsd.org" , freebsd-emulation@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 18:05:23 -0000 On Sun, 7 Sep 2014, Alexander Tarasikov wrote: > During summer as part of GSoC program I was working on porting FreeBSD > to the Android Emulator. > Besides, I have ported Android Emulator to run natively on x86_64 as opposed to > using linuxulator for 32-bit support. > > As for the kernel side, I have implemented the support for the > following hardware: > *IRQ, Timer, UART > *MMC > *Ethernet > *Framebuffer (using NEWCONS) > > It allows to mount rootfs and boot up to login prompt with raspberry > pi sd card image. I'm now in a position where I'm starting to look at getting this in shape ready to push it into the main tree. > As for the emulator, it's a bit complicated. FreeBSD boots fine if you > launch the emulator on Linux or Mac OS X. I have fixed some parts of > the build system and headers to make it compile and pass the tests on > FreeBSD. Unfortunately, the GUI doesn't work right now and only > console output (virtual UART) works. Firstly, I'd like to get the emulator into the ports tree. I was originally planning on using the Linux binary (I've been doing all of my testing so far with the Linux binary) but if you have patches for FreeBSD I think that's likely the best way forward, or it may make sense to import both? Then, I'd like to get the Goldfish code into the main FreeBSD tree. It would be nice to get at least bidirectional UART working before we can do that, are there any issues with the emulator that would prevent this? I've also not managed to get ethernet or the framebuffer working, though I've not looked deep into this and especially for the network interface it may be related to how I'm running the emulator - I guess you have been passing through a device into the emulator? I think once we can get the bidirectional UART fully functional, we can push this into the tree. Also, goldfish_mmc.c is missing a copyright statement - can you add one please? Thanks, Gavin From owner-freebsd-arm@FreeBSD.ORG Mon Oct 6 04:58:53 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34395917 for ; Mon, 6 Oct 2014 04:58:53 +0000 (UTC) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4A3FBBE for ; Mon, 6 Oct 2014 04:58:52 +0000 (UTC) Received: by mail-yh0-f48.google.com with SMTP id v1so1709191yhn.7 for ; Sun, 05 Oct 2014 21:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EIdgXZEL7Jxmo4CrM/A9TLrvrZnOQG0QOY0eJFAchQg=; b=L0kwGG+R1cj34EFoYEo9PqY7ViBBYq0pp2k9clxQ2l+1Ovo9mGu2tqpp46oAQ+/nBA eNlA3Afle/4m27P6qwaKBYf2F82Vf+cyapWsbON8dJWWwfMfpQMNUiJbZzMW9/OhS0Ez Q3FMVez1rR2qjbtA5whcS/oXJzgd+sPimf/OP56qXT9Ab+X32bN4nsUOSJUpclpcXe3U sJz0lCPD/kaf9ctbYJ36tcwo1y8WMEDTi0vl50Z0ehR6yvoug1VpeZ23oyxEU6kgp0A7 i3rOaSRRB1SsOD1X/kE3izhlnBw/zRxyN4q1gLPnYQfBSgYqJqDnDjNN9JxI08wRGn4H JoYg== MIME-Version: 1.0 X-Received: by 10.236.145.66 with SMTP id o42mr35145318yhj.74.1412571531898; Sun, 05 Oct 2014 21:58:51 -0700 (PDT) Received: by 10.170.186.141 with HTTP; Sun, 5 Oct 2014 21:58:51 -0700 (PDT) In-Reply-To: References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> Date: Sun, 5 Oct 2014 21:58:51 -0700 Message-ID: Subject: Re: Digi CCWMX53 From: Russell Haley To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@freebsd.org, Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 04:58:53 -0000 Alright, well night one of my crash course in C and it wasn't quite as painful as I thought. For shits and giggles I started looking in the /sys/dev/nand directory. Nand.h then led me to ../../sys/bus.h and then back to some nfc classes where, EUREKA, I found nfc_91.h/c. I have been reading up on the atmel board support package so I recognized the at91 moniker. (pretty pleased with myself for that one...) So what I can tell is someone needs to write a mx53/mx6 nand flash controller that works in roughly the same way as the at91 "prototype". It would implement various functions and then assign them using: static device_method_t at91_nand_methods[] =3D { DEVMETHOD(device_probe, at91_nand_probe), DEVMETHOD(device_attach, at91_nand_attach), DEVMETHOD(nfc_send_command, at91_nand_send_command), DEVMETHOD(nfc_send_address, at91_nand_send_address), DEVMETHOD(nfc_read_byte, at91_nand_read_byte), DEVMETHOD(nfc_read_buf, at91_nand_read_buf), DEVMETHOD(nfc_write_buf, at91_nand_write_buf), DEVMETHOD(nfc_select_cs, at91_nand_select_cs), DEVMETHOD(nfc_read_rnb, at91_nand_read_rnb), DEVMETHOD_END }; Or some rough order of magnitude in that direction? That would be where some of the "pre-canded jobs" mentioned in the spec would come in handy? Thanks, Russ On Sat, Oct 4, 2014 at 4:15 PM, Russell Haley wrote: > Warner, > That's great news! I had a scan and it seemed pretty thorough (albiet > from a novice point of view). The pre-canned jobs looked promising. > > As much as I'm hoping your intention is to fix this FOR me, could you > point me towards the code for the mtd support? > > Many thanks to everyone for helping. I've had more progress in the > last two weeks than I have in the previous six months. lolz > > Russ > > > On Sat, Oct 4, 2014 at 11:05 AM, Warner Losh wrote: >> Hey Russ, >> >> A quick read suggests all, or nearly all, of the data needed to write a = full NFC for this chip is present. The programming and read sequences and i= nformation about ECC error rates appear to be readily available. The exact = ECC used, however, appears opaque. This may or may not be a problem. It eve= n appears to have command sequencing built into the controller. This is a g= reat feature, but one the current code doesn=E2=80=99t make use of. >> >> Warner >> >> On Oct 2, 2014, at 10:44 PM, Russell Haley wrote: >> >>> Warner, >>> >>> I was looking for a Digi reference but it turns out the Nand Flash Cont= roller is part of the Freescale Processor. Here is the link to the Referenc= e Manual: >>> >>> cache.freescale.com/files/32bit/doc/ref_manual/iMX53RM.pdf >>> >>> The NAND Flash Controller is in Chapter 51 page 3571 to page 3647. >>> >>> Is this relevant to what you are looking at doing? https://wiki.freebsd= .org/NAND >>> >>> I also found something called CHFS for NetBSD that looks interesting: h= ttp://chewiefs.sed.hu/home >>> >>> Thanks, >>> Russ >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Oct 2, 2014 at 2:34 PM, Warner Losh wrote: >>> >>> On Oct 1, 2014, at 12:48 AM, Russell Haley wrote= : >>> >>> > Warner, >>> > >>> > First, I was just watching your 2010 talk on supporting FreeBSD in a = commercial environment. Has there been any updates in the process of mainta= ining a commercial branch in the last 4 years (not that I have any commerci= al ventures yet! lolz)? >>> > >>> > Anyway, I talked to an Engineer about the NAND controller spec and he= chided me for being naive (poor little software developer, in way over his= head. tisk tisk). He mentioned a FIVE THOUSAND page reference manual, whic= h I have yet to find on the Digi site. >>> >>> URL + section number. 5k pages doesn=E2=80=99t necessarily mean it will= be useful, though. :( >>> >>> > I have however found this hardware reference: >>> > >>> > http://ftp1.digi.com/support/documentation/90001270_E.pdf >>> > >>> > From Page 41: >>> > >>> > NAND flash memory >>> > The ConnectCore for i.MX53 module provides 8GB of NAND flash memory. = On the module in >>> > the development kits a 512MByte, 2Kbyte page, NAND flash chip is used= . This NAND flash >>> > device is connected to NAND flash Chip Select 0. >>> > The NAND flash controller signals are available on the module connect= ors. >>> >>> This basically says nothing more useful than =E2=80=9CThere=E2=80=99s N= AND on this board that=E2=80=99s 4Gbits on CS0.=E2=80=9D which is useful, b= ut far from sufficient. How do I program the DMA so that ECC is added to th= e OOB areas of that NAND? How do I set different ECC tables? How do I do EC= C error correction and detection? If you can=E2=80=99t answer that sort of = question from the docs you have, then they aren=E2=80=99t helpful enough. >>> >>> > There are pin references to NAND further down in the section "GPIO mu= ltiplexing table in the ConnectCore for i.MX53 module" on page 44 and 49. >>> > >>> > I fear this is not the information we are looking for. >>> >>> Not really. The GPIO info might be mildly helpful in a few cases >>> >>> > I have found another u-boot fork for the CCWMX53 on github here: http= s://github.com/Varcain/uboot-ccwmx53-digi >>> > >>> > With what seems to be the information about booting from NAND here: h= ttps://github.com/Varcain/uboot-ccwmx53-digi/tree/master/nand_spl >>> > >>> > If you can let me know what I am looking for I can both ask a more di= rected question at work and also perform a better search. >>> > >>> > I have also started looking over the Architecture handbook as well be= cause I have a feeling there is going to be lots of driver code in my futur= e. >>> >>> A good first step would be to get a URL or search string to get the URL= for that big spec. It is of the right size to possibly be useful, but some= times really long specs have 1-2 page descriptions of things like the SD co= ntroller or the NAND controller that you need special NDAs + business arran= gements to get, so it is hard to say=E2=80=A6 >>> >>> Warner >>> >>> > >>> > On Sun, Sep 28, 2014 at 12:12 AM, Warner Losh wrote: >>> > >>> > On Sep 27, 2014, at 9:49 PM, Russell Haley wro= te: >>> > >>> > > I will attempt to load the kernel from tftp as soon as I can. I wil= l need >>> > > to figure out how to get ethernet to the unit. >>> > > >>> > > I know nothing about u-boot so forgive my ignorance but I was hopin= g to >>> > > modify the Arndale configuration to work such as: >>> > > >>> > > # mmc read 1 0x70800000 0x800 0x1800; >>> > > #go 0x70800000; >>> > > >>> > > and then point the rootfs to /dev/da1s1 >>> > > >>> > > On another note, do you know where I could find out more about the = missing >>> > > MTD support? >>> > >>> > A spec for the NAND controller is needed to make that work=E2=80=A6 = Is one about? >>> > >>> > Warner >>> > >>> > >>> > > BTW, I thought your wireless mesh stuff was pretty cool. Ah, so man= y cool >>> > > projects, so little time... >>> > > >>> > > Thanks, >>> > > >>> > > Russ >>> > > >>> > > On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo wrote: >>> > > >>> > >> On Sep 27, 2014, at 13:31, Russell Haley wr= ote: >>> > >>> >>> > >>> Rui, >>> > >>> >>> > >>> So no MTD means the NAND on the SOM is out, but can I boot the ke= rnel >>> > >> and load rootfs from the microSD, like in this example: >>> > >>> =E2=80=A2 >>> > >>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kernel.b= in; go >>> > >> 0x40f00000" >>> > >>> >>> > >>> ARNDALE5250 # saveenv >>> > >>> >>> > >>> ARNDALE5250 # boot >>> > >> >>> > >> You can't use the Arndale config since the load addresses are diff= erent. >>> > >> You should be able to load a kernel from the network. Can you do = that? >>> > >> >>> > >> -- >>> > >> Rui Paulo >>> > >> >>> > >> >>> > >> >>> > >> >>> > > _______________________________________________ >>> > > freebsd-arm@freebsd.org mailing list >>> > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>> > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.o= rg" >>> > >>> > >>> >>> >> From owner-freebsd-arm@FreeBSD.ORG Mon Oct 6 12:46:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74FBFAF7 for ; Mon, 6 Oct 2014 12:46:41 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 4E10B664 for ; Mon, 6 Oct 2014 12:46:41 +0000 (UTC) Received: from bender.lan (97e07ab1.skybroadband.com [151.224.122.177]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 1975C5C0B9 for ; Mon, 6 Oct 2014 12:46:33 +0000 (UTC) Date: Mon, 6 Oct 2014 13:46:26 +0100 From: Andrew Turner To: freebsd-arm@freebsd.org Subject: [RFC] Add and armv7hf TARGET_ARCH Message-ID: <20141006134626.59cc5573@bender.lan> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/zm6LfqDX0bxY7WsUXeQjGKV" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 12:46:41 -0000 --MP_/zm6LfqDX0bxY7WsUXeQjGKV Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm interested in peoples opinion on creating a new TARGET_ARCH to target ARMv7 SoCs. This will target all the current Cortex-A chips we support but not the Raspberry Pi. My intention with this is to have it become the tier 1 arm platform. This platform will support 32-bit Cortex-A based SoCs with a VFP unit. As it would be targeting ARMv7 we could look at supporting Thumb-2. As the VFP unit is optional and future SoCs without it will only be supported by the armv6 TARGET_ARCH, however I would expect almost all ARMv7 designs to include it. There is a downside to this, and as far as I know the problems are: * It could be confusing to figure out which TARGET_ARCH you need. * The Raspberry Pi will not be supported as its core is too old. I've attached my patch to build as armv7hf. It has been tested on a Wandboard Quad. Comments? Andrew --MP_/zm6LfqDX0bxY7WsUXeQjGKV Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=armv7hf.diff Index: Makefile =================================================================== --- Makefile (revision 272619) +++ Makefile (working copy) @@ -168,7 +168,7 @@ _TARGET_ARCH= ${TARGET:S/pc98/i386/} .elif !defined(TARGET) && defined(TARGET_ARCH) && \ ${TARGET_ARCH} != ${MACHINE_ARCH} -_TARGET= ${TARGET_ARCH:C/mips(n32|64)?(el)?/mips/:C/arm(v6)?(eb|hf)?/arm/} +_TARGET= ${TARGET_ARCH:C/mips(n32|64)?(el)?/mips/:C/arm(v6|v7)?(eb|hf)?/arm/} .endif .if defined(TARGET) && !defined(_TARGET) _TARGET=${TARGET} @@ -374,7 +374,7 @@ # .if make(universe) || make(universe_kernels) || make(tinderbox) || make(targets) TARGETS?=amd64 arm i386 mips pc98 powerpc sparc64 -TARGET_ARCHES_arm?= arm armeb armv6 armv6hf +TARGET_ARCHES_arm?= arm armeb armv6 armv7hf TARGET_ARCHES_mips?= mipsel mips mips64el mips64 mipsn32 TARGET_ARCHES_powerpc?= powerpc powerpc64 TARGET_ARCHES_pc98?= i386 Index: Makefile.inc1 =================================================================== --- Makefile.inc1 (revision 272619) +++ Makefile.inc1 (working copy) @@ -140,7 +140,7 @@ VERSION= FreeBSD ${REVISION}-${BRANCH:C/-p[0-9]+$//} ${TARGET_ARCH} ${SRCRELDATE} .endif -KNOWN_ARCHES?= amd64 arm armeb/arm armv6/arm armv6hf/arm i386 i386/pc98 mips mipsel/mips mips64el/mips mips64/mips mipsn32el/mips mipsn32/mips powerpc powerpc64/powerpc sparc64 +KNOWN_ARCHES?= amd64 arm armeb/arm armv6/arm armv7hf/arm i386 i386/pc98 mips mipsel/mips mips64el/mips mips64/mips mipsn32el/mips mipsn32/mips powerpc powerpc64/powerpc sparc64 .if ${TARGET} == ${TARGET_ARCH} _t= ${TARGET} .else Index: contrib/llvm/lib/Target/ARM/ARMISelLowering.cpp =================================================================== --- contrib/llvm/lib/Target/ARM/ARMISelLowering.cpp (revision 272619) +++ contrib/llvm/lib/Target/ARM/ARMISelLowering.cpp (working copy) @@ -2516,7 +2516,9 @@ // If we have T2 ops, we can materialize the address directly via movt/movw // pair. This is always cheaper. - if (Subtarget->useMovt()) { + if (Subtarget->useMovt() && + (Subtarget->getTargetTriple().getOS() != Triple::FreeBSD || + getTargetMachine().getRelocationModel() != Reloc::Static)) { ++NumMovwMovt; // FIXME: Once remat is capable of dealing with instructions with register // operands, expand this into two nodes. Index: gnu/usr.bin/binutils/Makefile.inc0 =================================================================== --- gnu/usr.bin/binutils/Makefile.inc0 (revision 272619) +++ gnu/usr.bin/binutils/Makefile.inc0 (working copy) @@ -7,7 +7,7 @@ VERSION= "2.17.50 [FreeBSD] 2007-07-03" .if defined(TARGET_ARCH) -TARGET_CPUARCH=${TARGET_ARCH:C/mips(n32|64)?(el)?/mips/:C/arm(v6)?(eb|hf)?/arm/:C/powerpc64/powerpc/} +TARGET_CPUARCH=${TARGET_ARCH:C/mips(n32|64)?(el)?/mips/:C/arm(v6|v7)?(eb|hf)?/arm/:C/powerpc64/powerpc/} .else TARGET_CPUARCH=${MACHINE_CPUARCH} .endif Index: gnu/usr.bin/cc/Makefile.tgt =================================================================== --- gnu/usr.bin/cc/Makefile.tgt (revision 272619) +++ gnu/usr.bin/cc/Makefile.tgt (working copy) @@ -4,7 +4,7 @@ # MACHINE_CPUARCH, but there's no easy way to export make functions... .if defined(TARGET_ARCH) -TARGET_CPUARCH=${TARGET_ARCH:C/mips(n32|64)?(el)?/mips/:C/arm(v6)?(eb|hf)?/arm/:C/powerpc64/powerpc/} +TARGET_CPUARCH=${TARGET_ARCH:C/mips(n32|64)?(el)?/mips/:C/arm(v6|v7)?(eb|hf)?/arm/:C/powerpc64/powerpc/} .else TARGET_CPUARCH=${MACHINE_CPUARCH} .endif Index: gnu/usr.bin/gdb/Makefile.inc =================================================================== --- gnu/usr.bin/gdb/Makefile.inc (revision 272619) +++ gnu/usr.bin/gdb/Makefile.inc (working copy) @@ -21,7 +21,7 @@ # MACHINE_CPUARCH, but there's no easy way to export make functions... .if defined(TARGET_ARCH) -TARGET_CPUARCH=${TARGET_ARCH:C/mips(n32|64)?(el)?/mips/:C/arm(v6)?(eb|hf)?/arm/:C/powerpc64/powerpc/} +TARGET_CPUARCH=${TARGET_ARCH:C/mips(n32|64)?(el)?/mips/:C/arm(v6|v7)?(eb|hf)?/arm/:C/powerpc64/powerpc/} .else TARGET_CPUARCH=${MACHINE_CPUARCH} .endif Index: gnu/usr.bin/gdb/libgdb/Makefile =================================================================== --- gnu/usr.bin/gdb/libgdb/Makefile (revision 272619) +++ gnu/usr.bin/gdb/libgdb/Makefile (working copy) @@ -4,7 +4,7 @@ # MACHINE_CPUARCH, but there's no easy way to export make functions... .if defined(TARGET_ARCH) -TARGET_CPUARCH=${TARGET_ARCH:C/mips(n32|64)?(el)?/mips/:C/arm(v6)?(eb|hf)?/arm/:C/powerpc64/powerpc/} +TARGET_CPUARCH=${TARGET_ARCH:C/mips(n32|64)?(el)?/mips/:C/arm(v6|v7)?(eb|hf)?/arm/:C/powerpc64/powerpc/} .else TARGET_CPUARCH=${MACHINE_CPUARCH} .endif Index: lib/clang/clang.build.mk =================================================================== --- lib/clang/clang.build.mk (revision 272619) +++ lib/clang/clang.build.mk (working copy) @@ -30,8 +30,8 @@ TARGET_ABI= unknown .endif -TARGET_TRIPLE?= ${TARGET_ARCH:C/amd64/x86_64/:C/armv6hf/armv6/}-${TARGET_ABI}-freebsd11.0 -BUILD_TRIPLE?= ${BUILD_ARCH:C/amd64/x86_64/:C/armv6hf/armv6/}-unknown-freebsd11.0 +TARGET_TRIPLE?= ${TARGET_ARCH:C/amd64/x86_64/:C/armv7hf/armv7/}-${TARGET_ABI}-freebsd11.0 +BUILD_TRIPLE?= ${BUILD_ARCH:C/amd64/x86_64/:C/armv7hf/armv7/}-unknown-freebsd11.0 CFLAGS+= -DLLVM_DEFAULT_TARGET_TRIPLE=\"${TARGET_TRIPLE}\" \ -DLLVM_HOST_TRIPLE=\"${BUILD_TRIPLE}\" \ -DDEFAULT_SYSROOT=\"${TOOLS_PREFIX}\" Index: lib/libc/arm/aeabi/Makefile.inc =================================================================== --- lib/libc/arm/aeabi/Makefile.inc (revision 272619) +++ lib/libc/arm/aeabi/Makefile.inc (working copy) @@ -9,7 +9,7 @@ SRCS+= aeabi_double.c \ aeabi_float.c .endif -.if ${MACHINE_ARCH:Marmv6*} +.if ${MACHINE_ARCH:Marmv[67]*} SRCS+= aeabi_vfp_double.S \ aeabi_vfp_float.S .endif Index: lib/libkvm/Makefile =================================================================== --- lib/libkvm/Makefile (revision 272619) +++ lib/libkvm/Makefile (working copy) @@ -3,7 +3,7 @@ .if defined(TARGET_ARCH) && !defined(COMPAT_32BIT) KVM_XARCH=${TARGET_ARCH} -KVM_XCPUARCH=${KVM_XARCH:C/mips(n32|64)?(el)?/mips/:C/arm(v6)?(eb|hf)?/arm/:C/powerpc64/powerpc/} +KVM_XCPUARCH=${KVM_XARCH:C/mips(n32|64)?(el)?/mips/:C/arm(v6|v7)?(eb|hf)?/arm/:C/powerpc64/powerpc/} .else KVM_XARCH=${MACHINE_ARCH} KVM_XCPUARCH=${MACHINE_CPUARCH} Index: share/mk/sys.mk =================================================================== --- share/mk/sys.mk (revision 272619) +++ share/mk/sys.mk (working copy) @@ -13,7 +13,7 @@ # and/or endian. This is called MACHINE_CPU in NetBSD, but that's used # for something different in FreeBSD. # -MACHINE_CPUARCH=${MACHINE_ARCH:C/mips(n32|64)?(el)?/mips/:C/arm(v6)?(eb|hf)?/arm/:C/powerpc64/powerpc/} +MACHINE_CPUARCH=${MACHINE_ARCH:C/mips(n32|64)?(el)?/mips/:C/arm(v6|v7)?(eb|hf)?/arm/:C/powerpc64/powerpc/} .endif # If the special target .POSIX appears (without prerequisites or Index: usr.bin/xlint/Makefile.inc =================================================================== --- usr.bin/xlint/Makefile.inc (revision 272619) +++ usr.bin/xlint/Makefile.inc (working copy) @@ -8,7 +8,7 @@ # These assignments duplicate much of the functionality of # MACHINE_CPUARCH, but there's no easy way to export make functions... .if defined(TARGET_ARCH) -TARGET_CPUARCH= ${TARGET_ARCH:C/mips(n32|64)?(el)?/mips/:C/arm(v6)?(eb|hf)?/arm/} +TARGET_CPUARCH= ${TARGET_ARCH:C/mips(n32|64)?(el)?/mips/:C/arm(v6|v7)?(eb|hf)?/arm/} .else TARGET_CPUARCH= ${MACHINE_CPUARCH} TARGET_ARCH= ${MACHINE_ARCH} --MP_/zm6LfqDX0bxY7WsUXeQjGKV-- From owner-freebsd-arm@FreeBSD.ORG Mon Oct 6 14:05:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2452CB23 for ; Mon, 6 Oct 2014 14:05:49 +0000 (UTC) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF199F8F for ; Mon, 6 Oct 2014 14:05:48 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id p10so3344086pdj.15 for ; Mon, 06 Oct 2014 07:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=xaHax69Ww9sRF/Lai3BLCcdRQdMo1SbtnDUtHx102Wc=; b=g5F8nZWuw8UgQZdQ3AciBDAWm9TtVLSHtgjFWzIqg6P+WgzQ7f/e4iIxWuF3wFv3l0 tS9nIS8mcJu9R7zdILrbKBMm4U8j0dT9UxTKfL3GAkB6BnZSNJCThuEmdMjzxr0Ga8Fp nRNFQnBVFUbK+RSdX4fTKvzK95ofXXenJ3M7uQ5dBeHyhvFh9rtYpYFY9ayRv8YPWVRb zDC+Txtf9QZCxl39fU41QP2TAl50C20cNUr8amuroZDCm6L1GxPl6ysxkKGhdaCN6L6J zz/xOEnHaIgv4Jg23WVOBFfC5A1JMgTFOsU6sAdC9pD4ytoyb5mi4LsEEYJy8TNNmD76 A9jw== X-Received: by 10.66.163.33 with SMTP id yf1mr3854991pab.96.1412604348315; Mon, 06 Oct 2014 07:05:48 -0700 (PDT) Received: from [172.30.1.26] ([112.168.75.52]) by mx.google.com with ESMTPSA id z15sm4169038pdi.6.2014.10.06.07.05.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Oct 2014 07:05:47 -0700 (PDT) Message-ID: <5432A1B5.30406@gmail.com> Date: Mon, 06 Oct 2014 23:05:41 +0900 From: Jaemin Yoo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Q: linking method for armv8 kernel build Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 14:05:49 -0000 Hello, I just began to download and build kernel for armv8 according to the following howto page. (https://wiki.freebsd.org/arm64) I could create the kernel image without problem. But 'file' says it's dynamically linked. I expected statically linked image to load it on dram using uboot. Is it meant to be? or am I missing some configuration? Thanks, Jaemin From owner-freebsd-arm@FreeBSD.ORG Mon Oct 6 14:28:38 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82C33F8E for ; Mon, 6 Oct 2014 14:28:38 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 68B6C23E for ; Mon, 6 Oct 2014 14:28:38 +0000 (UTC) Received: from bender.lan (97e07ab1.skybroadband.com [151.224.122.177]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 37F435C0B9 for ; Mon, 6 Oct 2014 14:28:37 +0000 (UTC) Date: Mon, 6 Oct 2014 15:28:32 +0100 From: Andrew Turner To: freebsd-arm@freebsd.org Subject: OMAP3 support Message-ID: <20141006152832.60c96640@bender.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 14:28:38 -0000 A few months ago I proposed removing OMAP3 support. At the time there was interest in keeping it in the tree as it was being worked on. I'm interested in the status of this. Is it the case that there is active development to support OMAP3? If so is there a tree somewhere for people with hardware to test? Or can we look are removing it due to lack of interest. Andrew From owner-freebsd-arm@FreeBSD.ORG Mon Oct 6 14:43:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54ECD716 for ; Mon, 6 Oct 2014 14:43:22 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 39439646 for ; Mon, 6 Oct 2014 14:43:21 +0000 (UTC) Received: from bender.lan (97e07ab1.skybroadband.com [151.224.122.177]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id CAAFE5CC08; Mon, 6 Oct 2014 14:43:20 +0000 (UTC) Date: Mon, 6 Oct 2014 15:43:14 +0100 From: Andrew Turner To: Jaemin Yoo Subject: Re: Q: linking method for armv8 kernel build Message-ID: <20141006154314.1b909772@bender.lan> In-Reply-To: <5432A1B5.30406@gmail.com> References: <5432A1B5.30406@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 14:43:22 -0000 On Mon, 06 Oct 2014 23:05:41 +0900 Jaemin Yoo wrote: > Hello, I just began to download and build kernel for armv8 according > to the following howto page. (https://wiki.freebsd.org/arm64) > > I could create the kernel image without problem. But 'file' says > it's dynamically linked. I expected statically linked image to load > it on dram using uboot. > > Is it meant to be? or am I missing some configuration? All examples of the FreeBSD kernel I've looked at say they are dynamically linked. The requirement is the kernel needs to be loaded at a 2MiB aligned address for the VA->PA translation to work. It will create the page table so the kernel base points to the load address. You may have problems loading it with U-Boot. It expects to be loaded by the loader as it passes in the device tree. U-Boot has been found to be difficult to support on 32-bit arm. Is there a reason to prefer it over UEFI? Andrew From owner-freebsd-arm@FreeBSD.ORG Mon Oct 6 16:41:24 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E627959 for ; Mon, 6 Oct 2014 16:41:24 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EE3C7E4 for ; Mon, 6 Oct 2014 16:41:23 +0000 (UTC) Received: from [192.168.200.200] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 505F31928D6; Mon, 6 Oct 2014 16:41:22 +0000 (UTC) Subject: Re: ARMv6 ports status From: Sean Bruno Reply-To: sbruno@freebsd.org To: Maxim V FIlimonov In-Reply-To: <1411403641.4191.17.camel@bruno> References: <1411367875.4191.13.camel@bruno> <1477814.BUZ47FdRvh@quad> <1411403641.4191.17.camel@bruno> Content-Type: text/plain; charset="us-ascii" Date: Mon, 06 Oct 2014 09:41:20 -0700 Message-ID: <1412613680.12078.9.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 16:41:24 -0000 On Mon, 2014-09-22 at 09:34 -0700, Sean Bruno wrote: > On Mon, 2014-09-22 at 20:20 +0400, Maxim V FIlimonov wrote: > > On Sunday 21 September 2014 23:37:55 Sean Bruno wrote: > > > I thought I'd actually subscribe here and post some status for your > > > entertainment. > > > > > > http://chips.ysv.freebsd.org/index.html is the current host building > > > FreeBSD ARMv6 ports for Current in the cluster. As you can see, it has > > > a good chunk of packages built already. > > > > > > This machine is also acting as a pkg repo at the moment: > > > http://chips.ysv.freebsd.org/packages/11armv632-default/ > > > > Good to hear that again. But there's a problem: pkg doesn't see any packages > > in this repo. I add it to pkg's repo configs, run pkg update, it downloads the > > .txz files and says that 0 packages added and 0 packages found. > > > Hrm, confirmed. Opened PR here: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193840 > This turned out to be a bug in qemu and I have squashed it. Feel free to poke and pull packages now at your leisure. Seems to work for me. sean From owner-freebsd-arm@FreeBSD.ORG Mon Oct 6 16:43:55 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30794A28 for ; Mon, 6 Oct 2014 16:43:55 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E121C809 for ; Mon, 6 Oct 2014 16:43:54 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XbBO4-000Aba-QJ; Mon, 06 Oct 2014 16:43:53 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s96GhpHR028577; Mon, 6 Oct 2014 10:43:51 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX198H/EKTq+IHQZgPcshNEPA X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Digi CCWMX53 From: Ian Lepore To: Russell Haley In-Reply-To: References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> Content-Type: text/plain; charset="windows-1251" Date: Mon, 06 Oct 2014 10:43:50 -0600 Message-ID: <1412613830.12052.121.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id s96GhpHR028577 Cc: freebsd-arm@freebsd.org, Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 16:43:55 -0000 On Sun, 2014-10-05 at 21:58 -0700, Russell Haley wrote: > Alright, well night one of my crash course in C and it wasn't quite as > painful as I thought. For shits and giggles I started looking in the > /sys/dev/nand directory. Nand.h then led me to ../../sys/bus.h and > then back to some nfc classes where, EUREKA, I found nfc_91.h/c. I > have been reading up on the atmel board support package so I > recognized the at91 moniker. (pretty pleased with myself for that > one...) >=20 > So what I can tell is someone needs to write a mx53/mx6 nand flash > controller that works in roughly the same way as the at91 "prototype". > It would implement various functions and then assign them using: >=20 > static device_method_t at91_nand_methods[] =3D { > DEVMETHOD(device_probe, at91_nand_probe), > DEVMETHOD(device_attach, at91_nand_attach), >=20 > DEVMETHOD(nfc_send_command, at91_nand_send_command), > DEVMETHOD(nfc_send_address, at91_nand_send_address), > DEVMETHOD(nfc_read_byte, at91_nand_read_byte), > DEVMETHOD(nfc_read_buf, at91_nand_read_buf), > DEVMETHOD(nfc_write_buf, at91_nand_write_buf), > DEVMETHOD(nfc_select_cs, at91_nand_select_cs), > DEVMETHOD(nfc_read_rnb, at91_nand_read_rnb), >=20 > DEVMETHOD_END > }; >=20 >=20 > Or some rough order of magnitude in that direction? That would be > where some of the "pre-canded jobs" mentioned in the spec would come > in handy? >=20 > Thanks, >=20 > Russ >=20 If the flash parts in use on your board can use 1-bit Hamming code for ECC, all you need to do is write a nearly-trivial nfc driver similar to at91_nfc. If the flash chips are modern and require multi-bit BCH code, we don't have a software implementation of that, and the current NFC interface has no provisions for using the hardware accellerator on the imx chip. I can't find any definitive info on what chips that board uses, but I will mention that 1-bit ECC was used on old chips with small capacities long ago and probably isn't used on any modern boards. -- Ian >=20 >=20 > On Sat, Oct 4, 2014 at 4:15 PM, Russell Haley wr= ote: > > Warner, > > That's great news! I had a scan and it seemed pretty thorough (albiet > > from a novice point of view). The pre-canned jobs looked promising. > > > > As much as I'm hoping your intention is to fix this FOR me, could you > > point me towards the code for the mtd support? > > > > Many thanks to everyone for helping. I've had more progress in the > > last two weeks than I have in the previous six months. lolz > > > > Russ > > > > > > On Sat, Oct 4, 2014 at 11:05 AM, Warner Losh wrote: > >> Hey Russ, > >> > >> A quick read suggests all, or nearly all, of the data needed to writ= e a full NFC for this chip is present. The programming and read sequences= and information about ECC error rates appear to be readily available. Th= e exact ECC used, however, appears opaque. This may or may not be a probl= em. It even appears to have command sequencing built into the controller.= This is a great feature, but one the current code doesn=92t make use of. > >> > >> Warner > >> > >> On Oct 2, 2014, at 10:44 PM, Russell Haley wr= ote: > >> > >>> Warner, > >>> > >>> I was looking for a Digi reference but it turns out the Nand Flash = Controller is part of the Freescale Processor. Here is the link to the Re= ference Manual: > >>> > >>> cache.freescale.com/files/32bit/doc/ref_manual/iMX53RM.pdf > >>> > >>> The NAND Flash Controller is in Chapter 51 page 3571 to page 3647. > >>> > >>> Is this relevant to what you are looking at doing? https://wiki.fre= ebsd.org/NAND > >>> > >>> I also found something called CHFS for NetBSD that looks interestin= g: http://chewiefs.sed.hu/home > >>> > >>> Thanks, > >>> Russ > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> On Thu, Oct 2, 2014 at 2:34 PM, Warner Losh wrote: > >>> > >>> On Oct 1, 2014, at 12:48 AM, Russell Haley w= rote: > >>> > >>> > Warner, > >>> > > >>> > First, I was just watching your 2010 talk on supporting FreeBSD i= n a commercial environment. Has there been any updates in the process of = maintaining a commercial branch in the last 4 years (not that I have any = commercial ventures yet! lolz)? > >>> > > >>> > Anyway, I talked to an Engineer about the NAND controller spec an= d he chided me for being naive (poor little software developer, in way ov= er his head. tisk tisk). He mentioned a FIVE THOUSAND page reference manu= al, which I have yet to find on the Digi site. > >>> > >>> URL + section number. 5k pages doesn=92t necessarily mean it will b= e useful, though. :( > >>> > >>> > I have however found this hardware reference: > >>> > > >>> > http://ftp1.digi.com/support/documentation/90001270_E.pdf > >>> > > >>> > From Page 41: > >>> > > >>> > NAND flash memory > >>> > The ConnectCore for i.MX53 module provides 8GB of NAND flash memo= ry. On the module in > >>> > the development kits a 512MByte, 2Kbyte page, NAND flash chip is = used. This NAND flash > >>> > device is connected to NAND flash Chip Select 0. > >>> > The NAND flash controller signals are available on the module con= nectors. > >>> > >>> This basically says nothing more useful than =93There=92s NAND on t= his board that=92s 4Gbits on CS0.=94 which is useful, but far from suffic= ient. How do I program the DMA so that ECC is added to the OOB areas of t= hat NAND? How do I set different ECC tables? How do I do ECC error correc= tion and detection? If you can=92t answer that sort of question from the = docs you have, then they aren=92t helpful enough. > >>> > >>> > There are pin references to NAND further down in the section "GPI= O multiplexing table in the ConnectCore for i.MX53 module" on page 44 and= 49. > >>> > > >>> > I fear this is not the information we are looking for. > >>> > >>> Not really. The GPIO info might be mildly helpful in a few cases > >>> > >>> > I have found another u-boot fork for the CCWMX53 on github here: = https://github.com/Varcain/uboot-ccwmx53-digi > >>> > > >>> > With what seems to be the information about booting from NAND her= e: https://github.com/Varcain/uboot-ccwmx53-digi/tree/master/nand_spl > >>> > > >>> > If you can let me know what I am looking for I can both ask a mor= e directed question at work and also perform a better search. > >>> > > >>> > I have also started looking over the Architecture handbook as wel= l because I have a feeling there is going to be lots of driver code in my= future. > >>> > >>> A good first step would be to get a URL or search string to get the= URL for that big spec. It is of the right size to possibly be useful, bu= t sometimes really long specs have 1-2 page descriptions of things like t= he SD controller or the NAND controller that you need special NDAs + busi= ness arrangements to get, so it is hard to say=85 > >>> > >>> Warner > >>> > >>> > > >>> > On Sun, Sep 28, 2014 at 12:12 AM, Warner Losh wr= ote: > >>> > > >>> > On Sep 27, 2014, at 9:49 PM, Russell Haley = wrote: > >>> > > >>> > > I will attempt to load the kernel from tftp as soon as I can. I= will need > >>> > > to figure out how to get ethernet to the unit. > >>> > > > >>> > > I know nothing about u-boot so forgive my ignorance but I was h= oping to > >>> > > modify the Arndale configuration to work such as: > >>> > > > >>> > > # mmc read 1 0x70800000 0x800 0x1800; > >>> > > #go 0x70800000; > >>> > > > >>> > > and then point the rootfs to /dev/da1s1 > >>> > > > >>> > > On another note, do you know where I could find out more about = the missing > >>> > > MTD support? > >>> > > >>> > A spec for the NAND controller is needed to make that work=85 Is= one about? > >>> > > >>> > Warner > >>> > > >>> > > >>> > > BTW, I thought your wireless mesh stuff was pretty cool. Ah, so= many cool > >>> > > projects, so little time... > >>> > > > >>> > > Thanks, > >>> > > > >>> > > Russ > >>> > > > >>> > > On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo wrot= e: > >>> > > > >>> > >> On Sep 27, 2014, at 13:31, Russell Haley wrote: > >>> > >>> > >>> > >>> Rui, > >>> > >>> > >>> > >>> So no MTD means the NAND on the SOM is out, but can I boot th= e kernel > >>> > >> and load rootfs from the microSD, like in this example: > >>> > >>> =95 > >>> > >>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kern= el.bin; go > >>> > >> 0x40f00000" > >>> > >>> > >>> > >>> ARNDALE5250 # saveenv > >>> > >>> > >>> > >>> ARNDALE5250 # boot > >>> > >> > >>> > >> You can't use the Arndale config since the load addresses are = different. > >>> > >> You should be able to load a kernel from the network. Can you= do that? > >>> > >> > >>> > >> -- > >>> > >> Rui Paulo > >>> > >> > >>> > >> > >>> > >> > >>> > >> > >>> > > _______________________________________________ > >>> > > freebsd-arm@freebsd.org mailing list > >>> > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > >>> > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freeb= sd.org" > >>> > > >>> > > >>> > >>> > >> > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 From owner-freebsd-arm@FreeBSD.ORG Mon Oct 6 17:30:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15C29C0B for ; Mon, 6 Oct 2014 17:30:54 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C3973D79 for ; Mon, 6 Oct 2014 17:30:53 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s96HUjPc010988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Oct 2014 10:30:46 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s96HUjMH010987; Mon, 6 Oct 2014 10:30:45 -0700 (PDT) (envelope-from jmg) Date: Mon, 6 Oct 2014 10:30:45 -0700 From: John-Mark Gurney To: Andrew Turner Subject: Re: [RFC] Add and armv7hf TARGET_ARCH Message-ID: <20141006173045.GE1852@funkthat.com> Mail-Followup-To: Andrew Turner , freebsd-arm@freebsd.org References: <20141006134626.59cc5573@bender.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141006134626.59cc5573@bender.lan> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 06 Oct 2014 10:30:46 -0700 (PDT) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 17:30:54 -0000 Andrew Turner wrote this message on Mon, Oct 06, 2014 at 13:46 +0100: > I'm interested in peoples opinion on creating a new TARGET_ARCH to > target ARMv7 SoCs. This will target all the current Cortex-A chips we > support but not the Raspberry Pi. My intention with this is to have it > become the tier 1 arm platform. > > This platform will support 32-bit Cortex-A based SoCs with a VFP > unit. As it would be targeting ARMv7 we could look at supporting > Thumb-2. > > As the VFP unit is optional and future SoCs without it will only be > supported by the armv6 TARGET_ARCH, however I would expect almost all > ARMv7 designs to include it. So, what are the specific pros of having a new arch? I see you talk about Thumb-2 support, but are there other advantages? Will we get significant performance boosts? What? Also, what impact will this have on trying to get binary packages for other arm archs? i.e. will this significantly take away resources? If we do this split, why would we want to build binary packages for RPI? > There is a downside to this, and as far as I know the problems are: > * It could be confusing to figure out which TARGET_ARCH you need. > * The Raspberry Pi will not be supported as its core is too old. > > I've attached my patch to build as armv7hf. It has been tested on a > Wandboard Quad. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon Oct 6 19:35:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 925A5E08; Mon, 6 Oct 2014 19:35:03 +0000 (UTC) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F1FFD83; Mon, 6 Oct 2014 19:35:03 +0000 (UTC) Received: by mail-yh0-f51.google.com with SMTP id 29so2329952yhl.38 for ; Mon, 06 Oct 2014 12:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LFF8U1fNZrN9srVhQLNWgRqn/R4Ge2lg1rK/uR3+zy4=; b=M3Npp5iX9bw1wkNMYmO9EhpJ0pEMIGNoS6BAwUqFIgtPAKF/YP+7Q3HII/a305xfnm bK25pQfXxdZovKEwAziloosT25Eo/JDEhSHh+vHBlPI2ldD6gD3987mjx73rk+2kjT8z hENkxwvT9ljcu22w3LOBobVnhMyd+hYpHhOdhWKt12ammtT3GC21nYrXi+HD0oJCalLg duZwhfggFHaDkoOr+wwIYOQME79DFVDBZ3/34ahBIFc/78QxDHoKC7UI06p3a9zRo0ND 0p1aieqSpsfGVZ2GJx9Eb1BdrArH4r1tlSCGBiEG9rhQn9LbK4QHVyTUvHSaMnzMwRbd hV+w== MIME-Version: 1.0 X-Received: by 10.236.70.229 with SMTP id p65mr39712005yhd.50.1412624102319; Mon, 06 Oct 2014 12:35:02 -0700 (PDT) Received: by 10.170.186.141 with HTTP; Mon, 6 Oct 2014 12:35:02 -0700 (PDT) In-Reply-To: <1412613830.12052.121.camel@revolution.hippie.lan> References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> <1412613830.12052.121.camel@revolution.hippie.lan> Date: Mon, 6 Oct 2014 12:35:02 -0700 Message-ID: Subject: Re: Digi CCWMX53 From: Russell Haley To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@freebsd.org, Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 19:35:03 -0000 I have been pinging some of the engineers here about ECC. I *might* be able to get someone to help me with a BCH implementation. The recommendation was to start by checking the Linux or Android source code that comes with the Jump starter Kit. I suspect however they used the build in hardware implementation but will verify that. Do you want me to look at writing a BSD ECC or implement something that can leverage a hardware implementation (which road should I take)? I guess another factor would be if the iMX6 and next gen Freescale stuff uses the same/similar controllers or if it's something different altogether? Also, I was wondering how closely the CWMX53 board support has followed the guidelines here: https://wiki.freebsd.org/FreeBSDArmBoards? On Mon, Oct 6, 2014 at 9:43 AM, Ian Lepore wrote: > On Sun, 2014-10-05 at 21:58 -0700, Russell Haley wrote: >> Alright, well night one of my crash course in C and it wasn't quite as >> painful as I thought. For shits and giggles I started looking in the >> /sys/dev/nand directory. Nand.h then led me to ../../sys/bus.h and >> then back to some nfc classes where, EUREKA, I found nfc_91.h/c. I >> have been reading up on the atmel board support package so I >> recognized the at91 moniker. (pretty pleased with myself for that >> one...) >> >> So what I can tell is someone needs to write a mx53/mx6 nand flash >> controller that works in roughly the same way as the at91 "prototype". >> It would implement various functions and then assign them using: >> >> static device_method_t at91_nand_methods[] =3D { >> DEVMETHOD(device_probe, at91_nand_probe), >> DEVMETHOD(device_attach, at91_nand_attach), >> >> DEVMETHOD(nfc_send_command, at91_nand_send_command), >> DEVMETHOD(nfc_send_address, at91_nand_send_address), >> DEVMETHOD(nfc_read_byte, at91_nand_read_byte), >> DEVMETHOD(nfc_read_buf, at91_nand_read_buf), >> DEVMETHOD(nfc_write_buf, at91_nand_write_buf), >> DEVMETHOD(nfc_select_cs, at91_nand_select_cs), >> DEVMETHOD(nfc_read_rnb, at91_nand_read_rnb), >> >> DEVMETHOD_END >> }; >> >> >> Or some rough order of magnitude in that direction? That would be >> where some of the "pre-canded jobs" mentioned in the spec would come >> in handy? >> >> Thanks, >> >> Russ >> > > If the flash parts in use on your board can use 1-bit Hamming code for > ECC, all you need to do is write a nearly-trivial nfc driver similar to > at91_nfc. If the flash chips are modern and require multi-bit BCH code, > we don't have a software implementation of that, and the current NFC > interface has no provisions for using the hardware accellerator on the > imx chip. > > I can't find any definitive info on what chips that board uses, but I > will mention that 1-bit ECC was used on old chips with small capacities > long ago and probably isn't used on any modern boards. > > -- Ian > > >> >> >> On Sat, Oct 4, 2014 at 4:15 PM, Russell Haley wro= te: >> > Warner, >> > That's great news! I had a scan and it seemed pretty thorough (albiet >> > from a novice point of view). The pre-canned jobs looked promising. >> > >> > As much as I'm hoping your intention is to fix this FOR me, could you >> > point me towards the code for the mtd support? >> > >> > Many thanks to everyone for helping. I've had more progress in the >> > last two weeks than I have in the previous six months. lolz >> > >> > Russ >> > >> > >> > On Sat, Oct 4, 2014 at 11:05 AM, Warner Losh wrote: >> >> Hey Russ, >> >> >> >> A quick read suggests all, or nearly all, of the data needed to write= a full NFC for this chip is present. The programming and read sequences an= d information about ECC error rates appear to be readily available. The exa= ct ECC used, however, appears opaque. This may or may not be a problem. It = even appears to have command sequencing built into the controller. This is = a great feature, but one the current code doesn=E2=80=99t make use of. >> >> >> >> Warner >> >> >> >> On Oct 2, 2014, at 10:44 PM, Russell Haley wro= te: >> >> >> >>> Warner, >> >>> >> >>> I was looking for a Digi reference but it turns out the Nand Flash C= ontroller is part of the Freescale Processor. Here is the link to the Refer= ence Manual: >> >>> >> >>> cache.freescale.com/files/32bit/doc/ref_manual/iMX53RM.pdf >> >>> >> >>> The NAND Flash Controller is in Chapter 51 page 3571 to page 3647. >> >>> >> >>> Is this relevant to what you are looking at doing? https://wiki.free= bsd.org/NAND >> >>> >> >>> I also found something called CHFS for NetBSD that looks interesting= : http://chewiefs.sed.hu/home >> >>> >> >>> Thanks, >> >>> Russ >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> On Thu, Oct 2, 2014 at 2:34 PM, Warner Losh wrote: >> >>> >> >>> On Oct 1, 2014, at 12:48 AM, Russell Haley wr= ote: >> >>> >> >>> > Warner, >> >>> > >> >>> > First, I was just watching your 2010 talk on supporting FreeBSD in= a commercial environment. Has there been any updates in the process of mai= ntaining a commercial branch in the last 4 years (not that I have any comme= rcial ventures yet! lolz)? >> >>> > >> >>> > Anyway, I talked to an Engineer about the NAND controller spec and= he chided me for being naive (poor little software developer, in way over = his head. tisk tisk). He mentioned a FIVE THOUSAND page reference manual, w= hich I have yet to find on the Digi site. >> >>> >> >>> URL + section number. 5k pages doesn=E2=80=99t necessarily mean it w= ill be useful, though. :( >> >>> >> >>> > I have however found this hardware reference: >> >>> > >> >>> > http://ftp1.digi.com/support/documentation/90001270_E.pdf >> >>> > >> >>> > From Page 41: >> >>> > >> >>> > NAND flash memory >> >>> > The ConnectCore for i.MX53 module provides 8GB of NAND flash memor= y. On the module in >> >>> > the development kits a 512MByte, 2Kbyte page, NAND flash chip is u= sed. This NAND flash >> >>> > device is connected to NAND flash Chip Select 0. >> >>> > The NAND flash controller signals are available on the module conn= ectors. >> >>> >> >>> This basically says nothing more useful than =E2=80=9CThere=E2=80=99= s NAND on this board that=E2=80=99s 4Gbits on CS0.=E2=80=9D which is useful= , but far from sufficient. How do I program the DMA so that ECC is added to= the OOB areas of that NAND? How do I set different ECC tables? How do I do= ECC error correction and detection? If you can=E2=80=99t answer that sort = of question from the docs you have, then they aren=E2=80=99t helpful enough= . >> >>> >> >>> > There are pin references to NAND further down in the section "GPIO= multiplexing table in the ConnectCore for i.MX53 module" on page 44 and 49= . >> >>> > >> >>> > I fear this is not the information we are looking for. >> >>> >> >>> Not really. The GPIO info might be mildly helpful in a few cases >> >>> >> >>> > I have found another u-boot fork for the CCWMX53 on github here: h= ttps://github.com/Varcain/uboot-ccwmx53-digi >> >>> > >> >>> > With what seems to be the information about booting from NAND here= : https://github.com/Varcain/uboot-ccwmx53-digi/tree/master/nand_spl >> >>> > >> >>> > If you can let me know what I am looking for I can both ask a more= directed question at work and also perform a better search. >> >>> > >> >>> > I have also started looking over the Architecture handbook as well= because I have a feeling there is going to be lots of driver code in my fu= ture. >> >>> >> >>> A good first step would be to get a URL or search string to get the = URL for that big spec. It is of the right size to possibly be useful, but s= ometimes really long specs have 1-2 page descriptions of things like the SD= controller or the NAND controller that you need special NDAs + business ar= rangements to get, so it is hard to say=E2=80=A6 >> >>> >> >>> Warner >> >>> >> >>> > >> >>> > On Sun, Sep 28, 2014 at 12:12 AM, Warner Losh wro= te: >> >>> > >> >>> > On Sep 27, 2014, at 9:49 PM, Russell Haley = wrote: >> >>> > >> >>> > > I will attempt to load the kernel from tftp as soon as I can. I = will need >> >>> > > to figure out how to get ethernet to the unit. >> >>> > > >> >>> > > I know nothing about u-boot so forgive my ignorance but I was ho= ping to >> >>> > > modify the Arndale configuration to work such as: >> >>> > > >> >>> > > # mmc read 1 0x70800000 0x800 0x1800; >> >>> > > #go 0x70800000; >> >>> > > >> >>> > > and then point the rootfs to /dev/da1s1 >> >>> > > >> >>> > > On another note, do you know where I could find out more about t= he missing >> >>> > > MTD support? >> >>> > >> >>> > A spec for the NAND controller is needed to make that work=E2=80= =A6 Is one about? >> >>> > >> >>> > Warner >> >>> > >> >>> > >> >>> > > BTW, I thought your wireless mesh stuff was pretty cool. Ah, so = many cool >> >>> > > projects, so little time... >> >>> > > >> >>> > > Thanks, >> >>> > > >> >>> > > Russ >> >>> > > >> >>> > > On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo wrote= : >> >>> > > >> >>> > >> On Sep 27, 2014, at 13:31, Russell Haley = wrote: >> >>> > >>> >> >>> > >>> Rui, >> >>> > >>> >> >>> > >>> So no MTD means the NAND on the SOM is out, but can I boot the= kernel >> >>> > >> and load rootfs from the microSD, like in this example: >> >>> > >>> =E2=80=A2 >> >>> > >>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kerne= l.bin; go >> >>> > >> 0x40f00000" >> >>> > >>> >> >>> > >>> ARNDALE5250 # saveenv >> >>> > >>> >> >>> > >>> ARNDALE5250 # boot >> >>> > >> >> >>> > >> You can't use the Arndale config since the load addresses are d= ifferent. >> >>> > >> You should be able to load a kernel from the network. Can you = do that? >> >>> > >> >> >>> > >> -- >> >>> > >> Rui Paulo >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > > _______________________________________________ >> >>> > > freebsd-arm@freebsd.org mailing list >> >>> > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> >>> > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebs= d.org" >> >>> > >> >>> > >> >>> >> >>> >> >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> > > From owner-freebsd-arm@FreeBSD.ORG Mon Oct 6 21:30:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6729C6A8 for ; Mon, 6 Oct 2014 21:30:40 +0000 (UTC) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E261CA8 for ; Mon, 6 Oct 2014 21:30:39 +0000 (UTC) Received: by mail-oi0-f45.google.com with SMTP id i138so4259528oig.18 for ; Mon, 06 Oct 2014 14:30:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=qNn0UCB1/p7+cXlBFa8HxlZWtCj7WStBgnW3J6KzyxA=; b=QihPd9LF5wnsy4IeE3QBIkA3kRS6zPhiqRu1xLPtUxjnKCtTeKQkXgui3t158FOi6J B9yAay4zN+KiI3p9hKchKWrrIPishE+MHQn4MslINhXlWn1sTwPVNjlT4l4eKQ3BYcSj NfXx/gF3zGBznretZ9BWzEhOMGthccF/jA/yXvmeWtmvR5mFreGIStQ8F8IVUHonuma8 nsRrPVr3mP3GSDPdOnH8h2tpMPtYRXQlha0xhc33/2nXYpA9F7sCmRRlYvPCdPbwAz0w tZdh+ELbaqsSYHyrlZT0xswxcYkolOTBDQSEKRA1rQ8anPMugVr/cRAfHWmxtxopvYj4 Hk+Q== X-Gm-Message-State: ALoCoQkJ3je98gmja8iYkQqWjzqJhEL6u70o8GvtlD72rrogP6zk3Td2rPIOHlTHyoeyhno1cUvW X-Received: by 10.182.40.234 with SMTP id a10mr30581543obl.8.1412631038370; Mon, 06 Oct 2014 14:30:38 -0700 (PDT) Received: from bsdimp.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id i1sm10797314oew.6.2014.10.06.14.30.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Oct 2014 14:30:37 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_DFDB8F3A-1AAD-4A2B-BA6B-006FC242B602"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Digi CCWMX53 From: Warner Losh In-Reply-To: Date: Mon, 6 Oct 2014 15:30:35 -0600 Message-Id: References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> <1412613830.12052.121.camel@revolution.hippie.lan> To: Russell Haley X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm , Ian Lepore , Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 21:30:40 -0000 --Apple-Mail=_DFDB8F3A-1AAD-4A2B-BA6B-006FC242B602 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 6, 2014, at 1:35 PM, Russell Haley wrote: > I have been pinging some of the engineers here about ECC. I *might* be > able to get someone to help me with a BCH implementation. The > recommendation was to start by checking the Linux or Android source > code that comes with the Jump starter Kit. I suspect however they used > the build in hardware implementation but will verify that. Do you > want me to look at writing a BSD ECC or implement something that can > leverage a hardware implementation (which road should I take)? >=20 > I guess another factor would be if the iMX6 and next gen Freescale > stuff uses the same/similar controllers or if it's something different > altogether? >=20 > Also, I was wondering how closely the CWMX53 board support has > followed the guidelines here: > https://wiki.freebsd.org/FreeBSDArmBoards? I don=92t think our current 1-bit ECC is enough. The problem with most = of the SoCs implement strong ECC, but they are all different. They use different parameters for BCH to achieve the same ECC strength that different NAND vendors recommend. You absolutely have to do this in hardware. Software ECC is too slow by a factor of 10 or 100, especially as the codes get more complex (some recent parts require like 39 bits over 1k). 1-bit hamming code is bad = enough. Ideally, we can accept a divergence of ECC in the details, and instead = allow for full and partial hardware offload for ECC generation and correction. Warner > On Mon, Oct 6, 2014 at 9:43 AM, Ian Lepore wrote: >> On Sun, 2014-10-05 at 21:58 -0700, Russell Haley wrote: >>> Alright, well night one of my crash course in C and it wasn't quite = as >>> painful as I thought. For shits and giggles I started looking in the >>> /sys/dev/nand directory. Nand.h then led me to ../../sys/bus.h and >>> then back to some nfc classes where, EUREKA, I found nfc_91.h/c. I >>> have been reading up on the atmel board support package so I >>> recognized the at91 moniker. (pretty pleased with myself for that >>> one...) >>>=20 >>> So what I can tell is someone needs to write a mx53/mx6 nand flash >>> controller that works in roughly the same way as the at91 = "prototype". >>> It would implement various functions and then assign them using: >>>=20 >>> static device_method_t at91_nand_methods[] =3D { >>> DEVMETHOD(device_probe, at91_nand_probe), >>> DEVMETHOD(device_attach, at91_nand_attach), >>>=20 >>> DEVMETHOD(nfc_send_command, at91_nand_send_command), >>> DEVMETHOD(nfc_send_address, at91_nand_send_address), >>> DEVMETHOD(nfc_read_byte, at91_nand_read_byte), >>> DEVMETHOD(nfc_read_buf, at91_nand_read_buf), >>> DEVMETHOD(nfc_write_buf, at91_nand_write_buf), >>> DEVMETHOD(nfc_select_cs, at91_nand_select_cs), >>> DEVMETHOD(nfc_read_rnb, at91_nand_read_rnb), >>>=20 >>> DEVMETHOD_END >>> }; >>>=20 >>>=20 >>> Or some rough order of magnitude in that direction? That would be >>> where some of the "pre-canded jobs" mentioned in the spec would come >>> in handy? >>>=20 >>> Thanks, >>>=20 >>> Russ >>>=20 >>=20 >> If the flash parts in use on your board can use 1-bit Hamming code = for >> ECC, all you need to do is write a nearly-trivial nfc driver similar = to >> at91_nfc. If the flash chips are modern and require multi-bit BCH = code, >> we don't have a software implementation of that, and the current NFC >> interface has no provisions for using the hardware accellerator on = the >> imx chip. >>=20 >> I can't find any definitive info on what chips that board uses, but I >> will mention that 1-bit ECC was used on old chips with small = capacities >> long ago and probably isn't used on any modern boards. >>=20 >> -- Ian >>=20 >>=20 >>>=20 >>>=20 >>> On Sat, Oct 4, 2014 at 4:15 PM, Russell Haley = wrote: >>>> Warner, >>>> That's great news! I had a scan and it seemed pretty thorough = (albiet >>>> from a novice point of view). The pre-canned jobs looked promising. >>>>=20 >>>> As much as I'm hoping your intention is to fix this FOR me, could = you >>>> point me towards the code for the mtd support? >>>>=20 >>>> Many thanks to everyone for helping. I've had more progress in the >>>> last two weeks than I have in the previous six months. lolz >>>>=20 >>>> Russ >>>>=20 >>>>=20 >>>> On Sat, Oct 4, 2014 at 11:05 AM, Warner Losh = wrote: >>>>> Hey Russ, >>>>>=20 >>>>> A quick read suggests all, or nearly all, of the data needed to = write a full NFC for this chip is present. The programming and read = sequences and information about ECC error rates appear to be readily = available. The exact ECC used, however, appears opaque. This may or may = not be a problem. It even appears to have command sequencing built into = the controller. This is a great feature, but one the current code = doesn=92t make use of. >>>>>=20 >>>>> Warner >>>>>=20 >>>>> On Oct 2, 2014, at 10:44 PM, Russell Haley = wrote: >>>>>=20 >>>>>> Warner, >>>>>>=20 >>>>>> I was looking for a Digi reference but it turns out the Nand = Flash Controller is part of the Freescale Processor. Here is the link to = the Reference Manual: >>>>>>=20 >>>>>> cache.freescale.com/files/32bit/doc/ref_manual/iMX53RM.pdf >>>>>>=20 >>>>>> The NAND Flash Controller is in Chapter 51 page 3571 to page = 3647. >>>>>>=20 >>>>>> Is this relevant to what you are looking at doing? = https://wiki.freebsd.org/NAND >>>>>>=20 >>>>>> I also found something called CHFS for NetBSD that looks = interesting: http://chewiefs.sed.hu/home >>>>>>=20 >>>>>> Thanks, >>>>>> Russ >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Thu, Oct 2, 2014 at 2:34 PM, Warner Losh = wrote: >>>>>>=20 >>>>>> On Oct 1, 2014, at 12:48 AM, Russell Haley = wrote: >>>>>>=20 >>>>>>> Warner, >>>>>>>=20 >>>>>>> First, I was just watching your 2010 talk on supporting FreeBSD = in a commercial environment. Has there been any updates in the process = of maintaining a commercial branch in the last 4 years (not that I have = any commercial ventures yet! lolz)? >>>>>>>=20 >>>>>>> Anyway, I talked to an Engineer about the NAND controller spec = and he chided me for being naive (poor little software developer, in way = over his head. tisk tisk). He mentioned a FIVE THOUSAND page reference = manual, which I have yet to find on the Digi site. >>>>>>=20 >>>>>> URL + section number. 5k pages doesn=92t necessarily mean it will = be useful, though. :( >>>>>>=20 >>>>>>> I have however found this hardware reference: >>>>>>>=20 >>>>>>> http://ftp1.digi.com/support/documentation/90001270_E.pdf >>>>>>>=20 >>>>>>> =46rom Page 41: >>>>>>>=20 >>>>>>> NAND flash memory >>>>>>> The ConnectCore for i.MX53 module provides 8GB of NAND flash = memory. On the module in >>>>>>> the development kits a 512MByte, 2Kbyte page, NAND flash chip is = used. This NAND flash >>>>>>> device is connected to NAND flash Chip Select 0. >>>>>>> The NAND flash controller signals are available on the module = connectors. >>>>>>=20 >>>>>> This basically says nothing more useful than =93There=92s NAND on = this board that=92s 4Gbits on CS0.=94 which is useful, but far from = sufficient. How do I program the DMA so that ECC is added to the OOB = areas of that NAND? How do I set different ECC tables? How do I do ECC = error correction and detection? If you can=92t answer that sort of = question from the docs you have, then they aren=92t helpful enough. >>>>>>=20 >>>>>>> There are pin references to NAND further down in the section = "GPIO multiplexing table in the ConnectCore for i.MX53 module" on page = 44 and 49. >>>>>>>=20 >>>>>>> I fear this is not the information we are looking for. >>>>>>=20 >>>>>> Not really. The GPIO info might be mildly helpful in a few cases >>>>>>=20 >>>>>>> I have found another u-boot fork for the CCWMX53 on github here: = https://github.com/Varcain/uboot-ccwmx53-digi >>>>>>>=20 >>>>>>> With what seems to be the information about booting from NAND = here: https://github.com/Varcain/uboot-ccwmx53-digi/tree/master/nand_spl >>>>>>>=20 >>>>>>> If you can let me know what I am looking for I can both ask a = more directed question at work and also perform a better search. >>>>>>>=20 >>>>>>> I have also started looking over the Architecture handbook as = well because I have a feeling there is going to be lots of driver code = in my future. >>>>>>=20 >>>>>> A good first step would be to get a URL or search string to get = the URL for that big spec. It is of the right size to possibly be = useful, but sometimes really long specs have 1-2 page descriptions of = things like the SD controller or the NAND controller that you need = special NDAs + business arrangements to get, so it is hard to say=85 >>>>>>=20 >>>>>> Warner >>>>>>=20 >>>>>>>=20 >>>>>>> On Sun, Sep 28, 2014 at 12:12 AM, Warner Losh = wrote: >>>>>>>=20 >>>>>>> On Sep 27, 2014, at 9:49 PM, Russell Haley = wrote: >>>>>>>=20 >>>>>>>> I will attempt to load the kernel from tftp as soon as I can. I = will need >>>>>>>> to figure out how to get ethernet to the unit. >>>>>>>>=20 >>>>>>>> I know nothing about u-boot so forgive my ignorance but I was = hoping to >>>>>>>> modify the Arndale configuration to work such as: >>>>>>>>=20 >>>>>>>> # mmc read 1 0x70800000 0x800 0x1800; >>>>>>>> #go 0x70800000; >>>>>>>>=20 >>>>>>>> and then point the rootfs to /dev/da1s1 >>>>>>>>=20 >>>>>>>> On another note, do you know where I could find out more about = the missing >>>>>>>> MTD support? >>>>>>>=20 >>>>>>> A spec for the NAND controller is needed to make that work=85 = Is one about? >>>>>>>=20 >>>>>>> Warner >>>>>>>=20 >>>>>>>=20 >>>>>>>> BTW, I thought your wireless mesh stuff was pretty cool. Ah, so = many cool >>>>>>>> projects, so little time... >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>>=20 >>>>>>>> Russ >>>>>>>>=20 >>>>>>>> On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo = wrote: >>>>>>>>=20 >>>>>>>>> On Sep 27, 2014, at 13:31, Russell Haley = wrote: >>>>>>>>>>=20 >>>>>>>>>> Rui, >>>>>>>>>>=20 >>>>>>>>>> So no MTD means the NAND on the SOM is out, but can I boot = the kernel >>>>>>>>> and load rootfs from the microSD, like in this example: >>>>>>>>>> =95 >>>>>>>>>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 = kernel.bin; go >>>>>>>>> 0x40f00000" >>>>>>>>>>=20 >>>>>>>>>> ARNDALE5250 # saveenv >>>>>>>>>>=20 >>>>>>>>>> ARNDALE5250 # boot >>>>>>>>>=20 >>>>>>>>> You can't use the Arndale config since the load addresses are = different. >>>>>>>>> You should be able to load a kernel from the network. Can you = do that? >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Rui Paulo >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> freebsd-arm@freebsd.org mailing list >>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>>>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>> _______________________________________________ >>> freebsd-arm@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >>>=20 >>=20 >>=20 --Apple-Mail=_DFDB8F3A-1AAD-4A2B-BA6B-006FC242B602 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUMwn7AAoJEGwc0Sh9sBEA7aQP/0FokXHQ5sbYagwZuyr4gV8y qyE501kgYAwfBC6KxJN7ORKoAMkJ5B3nyMuHEnSUVo0kfzyeIxVMC6VEok1hCryt XweZIwjduwR1Nmrl7R0mbaUNNKPfYRFQfYbcGLITShGAq5i4YX4cBLbkE4oorYpC 5dvRO7QJ8JdIYnh3oaQkQvkLdxLlJjdDdOvSlT8HYC2obvpdDkTUnOz5tQFZzLmj WWlO8QhNJynMeM25SkHDqXvUXE2iqG1F5PNVzZcHh8ebr9EGM+ophSv0R4IfXFKo slgEEE32F1oYnzeJVc6dRdZ8ziyiIh3+mqq8WqV0KRV9E38ctkeagrQ0onZhDCkQ 0NpQWiErCJRXOno49nqQJCU3ZdMXRfpM0o1AVbsf2Ah7vE1Nt08/c6XM90ddTI84 BzwaYbTQZ6z7XbppnGBddnVSfP+WBREP2Dnt6XTY635DCbM3VoQQ0ZfwtIs6xH5W tj4kLYIZxHAJl6vvXPgzPhxEKB7ChRIb5I1N9pnJ5a5TR8dKEdKKDmI+ha40tP3q ELtgKNfHngeGjnl5GhdlwFgSVp1yUodLZclSC1H0sm7QH31uZDjfxJfT/ItOTaVg nGS4mHjTc2L4Oj8ijPvbBaqIhT9Bap9ga0D2puYSuPlSM2E+YtNvLdfmkcUztNQ0 ZTEYmraPrcKnROxo4CRS =Woui -----END PGP SIGNATURE----- --Apple-Mail=_DFDB8F3A-1AAD-4A2B-BA6B-006FC242B602-- From owner-freebsd-arm@FreeBSD.ORG Mon Oct 6 21:41:32 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B576F7DC for ; Mon, 6 Oct 2014 21:41:32 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 9A27EE25 for ; Mon, 6 Oct 2014 21:41:32 +0000 (UTC) Received: from bender.lan (97e07ab1.skybroadband.com [151.224.122.177]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id DE48F5C0B9; Mon, 6 Oct 2014 21:41:30 +0000 (UTC) Date: Mon, 6 Oct 2014 22:41:24 +0100 From: Andrew Turner To: John-Mark Gurney Subject: Re: [RFC] Add and armv7hf TARGET_ARCH Message-ID: <20141006224124.494267e0@bender.lan> In-Reply-To: <20141006173045.GE1852@funkthat.com> References: <20141006134626.59cc5573@bender.lan> <20141006173045.GE1852@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 21:41:32 -0000 On Mon, 6 Oct 2014 10:30:45 -0700 John-Mark Gurney wrote: > Andrew Turner wrote this message on Mon, Oct 06, 2014 at 13:46 +0100: > > I'm interested in peoples opinion on creating a new TARGET_ARCH to > > target ARMv7 SoCs. This will target all the current Cortex-A chips > > we support but not the Raspberry Pi. My intention with this is to > > have it become the tier 1 arm platform. > > > > This platform will support 32-bit Cortex-A based SoCs with a VFP > > unit. As it would be targeting ARMv7 we could look at supporting > > Thumb-2. > > > > As the VFP unit is optional and future SoCs without it will only be > > supported by the armv6 TARGET_ARCH, however I would expect almost > > all ARMv7 designs to include it. > > So, what are the specific pros of having a new arch? I see you talk > about Thumb-2 support, but are there other advantages? Will we get > significant performance boosts? What? We would get a significant speed improvement for anything that uses floating-point. I haven't done extensive tests, but Ian was getting around 30x-34x improvement by using the vfp on one benchmark [1]. I've seen a sight improvement of around 3-5 MFlops on his numbers on my board. I expect there to be a slight performance improvement from being able to use the newer ARMv7 instructions, however this will be less pronounced than the above floating-point improvement. There are also a number of NEON optimised libc functions we could make use of, for example [2]. While we may be able to use them on armv6 it becomes simpler if we can assume we have a NEON unit. > Also, what impact will this have on trying to get binary packages > for other arm archs? i.e. will this significantly take away > resources? If we do this split, why would we want to build binary > packages for RPI? This would depend on how we expect to build them. If the packages are cross built it would mean having two machines to build packages on rather than one. If we have native package building I could see managing two clusters could be difficult. Andrew [1] https://lists.freebsd.org/pipermail/freebsd-arm/2014-February/007555.html [2] https://android.googlesource.com/platform/bionic/+/master/libc/arch-arm/bionic/memcpy.S From owner-freebsd-arm@FreeBSD.ORG Mon Oct 6 21:52:14 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC87BC7A for ; Mon, 6 Oct 2014 21:52:14 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 524BAF1A for ; Mon, 6 Oct 2014 21:52:13 +0000 (UTC) Received: from [192.168.225.11] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id s96LpxhF060495; Mon, 6 Oct 2014 23:52:03 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <54330F01.4050108@fgznet.ch> Date: Mon, 06 Oct 2014 23:52:01 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Andrew Turner , freebsd-arm@freebsd.org Subject: Re: [RFC] Add and armv7hf TARGET_ARCH References: <20141006134626.59cc5573@bender.lan> In-Reply-To: <20141006134626.59cc5573@bender.lan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 21:52:14 -0000 On 06.10.14 14:46, Andrew Turner wrote: > I'm interested in peoples opinion on creating a new TARGET_ARCH to > target ARMv7 SoCs. This will target all the current Cortex-A chips we > support but not the Raspberry Pi. My intention with this is to have it > become the tier 1 arm platform. > > This platform will support 32-bit Cortex-A based SoCs with a VFP > unit. As it would be targeting ARMv7 we could look at supporting > Thumb-2. > > As the VFP unit is optional and future SoCs without it will only be > supported by the armv6 TARGET_ARCH, however I would expect almost all > ARMv7 designs to include it. > > There is a downside to this, and as far as I know the problems are: > * It could be confusing to figure out which TARGET_ARCH you need. > * The Raspberry Pi will not be supported as its core is too old. > > I've attached my patch to build as armv7hf. It has been tested on a > Wandboard Quad. > > Comments? Here the patch does not apply. Manually applied. Configuring math/gmp shows a segfaulting clang++. Investigating later. Went back to clang built v6hf, since gcc built pkg on v6 segfaults too. Sigh. I need more such board to test in parallel... I think something like this part would also be needed, no? Thanks, Andreas Index: sys/arm/include/param.h =================================================================== --- sys/arm/include/param.h (revision 272668) +++ sys/arm/include/param.h (working copy) @@ -53,9 +53,13 @@ #define __PCI_REROUTE_INTERRUPT -#if __ARM_ARCH >= 6 +#if __ARM_ARCH >= 7 +#define _V6_SUFFIX "v7" +#endif +#if __ARM_ARCH == 6 #define _V6_SUFFIX "v6" -#else +#endif +#if __ARM_ARCH <= 5 #define _V6_SUFFIX "" #endif From owner-freebsd-arm@FreeBSD.ORG Mon Oct 6 22:05:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C9C09E for ; Mon, 6 Oct 2014 22:05:43 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1FD18B8 for ; Mon, 6 Oct 2014 22:05:42 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XbGPV-000KND-QP; Mon, 06 Oct 2014 22:05:42 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s96M5dwV029025; Mon, 6 Oct 2014 16:05:39 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+ZGiI++o6dvzD3gne5WOn9 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [RFC] Add and armv7hf TARGET_ARCH From: Ian Lepore To: Andrew Turner In-Reply-To: <20141006224124.494267e0@bender.lan> References: <20141006134626.59cc5573@bender.lan> <20141006173045.GE1852@funkthat.com> <20141006224124.494267e0@bender.lan> Content-Type: text/plain; charset="us-ascii" Date: Mon, 06 Oct 2014 16:05:38 -0600 Message-ID: <1412633138.12052.180.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 22:05:43 -0000 On Mon, 2014-10-06 at 22:41 +0100, Andrew Turner wrote: > On Mon, 6 Oct 2014 10:30:45 -0700 > John-Mark Gurney wrote: > > > Andrew Turner wrote this message on Mon, Oct 06, 2014 at 13:46 +0100: > > > I'm interested in peoples opinion on creating a new TARGET_ARCH to > > > target ARMv7 SoCs. This will target all the current Cortex-A chips > > > we support but not the Raspberry Pi. My intention with this is to > > > have it become the tier 1 arm platform. > > > > > > This platform will support 32-bit Cortex-A based SoCs with a VFP > > > unit. As it would be targeting ARMv7 we could look at supporting > > > Thumb-2. > > > > > > As the VFP unit is optional and future SoCs without it will only be > > > supported by the armv6 TARGET_ARCH, however I would expect almost > > > all ARMv7 designs to include it. > > > > So, what are the specific pros of having a new arch? I see you talk > > about Thumb-2 support, but are there other advantages? Will we get > > significant performance boosts? What? > > We would get a significant speed improvement for anything that uses > floating-point. I haven't done extensive tests, but Ian was getting > around 30x-34x improvement by using the vfp on one benchmark [1]. I've > seen a sight improvement of around 3-5 MFlops on his numbers on my > board. > The improvement from softfloat to softfp (hardware floating point with function-call arguments passed in integer registers) was huge. I would expect the improvement from softfp to full hardfloat to be a small increment on top of that. I have a vague memory of testing that and not seeing a dramatic difference, but I can't find any notes or test results. -- Ian > I expect there to be a slight performance improvement from being able > to use the newer ARMv7 instructions, however this will be less > pronounced than the above floating-point improvement. > > There are also a number of NEON optimised libc functions we could make > use of, for example [2]. While we may be able to use them on armv6 it > becomes simpler if we can assume we have a NEON unit. > > > Also, what impact will this have on trying to get binary packages > > for other arm archs? i.e. will this significantly take away > > resources? If we do this split, why would we want to build binary > > packages for RPI? > > This would depend on how we expect to build them. If the packages are > cross built it would mean having two machines to build packages on > rather than one. If we have native package building I could see > managing two clusters could be difficult. > > Andrew > > [1] > https://lists.freebsd.org/pipermail/freebsd-arm/2014-February/007555.html > [2] > https://android.googlesource.com/platform/bionic/+/master/libc/arch-arm/bionic/memcpy.S > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Mon Oct 6 22:11:14 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A69E316; Mon, 6 Oct 2014 22:11:14 +0000 (UTC) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0CB18196; Mon, 6 Oct 2014 22:11:13 +0000 (UTC) Received: by mail-yh0-f49.google.com with SMTP id a41so2458379yho.36 for ; Mon, 06 Oct 2014 15:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=O0uMnSV25NsFbFyKMI6elcTr6Tzoq4WoyH2KuWjffZQ=; b=UeZqzEaXPPuVp78A09V6avyBjtXnx8Yj1RnCCthsMTWImyqPMKiMM3xxYpsrvqjEDm CIJ8dVqbji7OdHB5IpR9KteVRRJOyktuUljMOTFmqg0NrOdllQ74k+OTdL0vecR3mBVb gqF+Ez5LxczKw6s5jdi0ChlB07II7A9JguqnPN/WaLlstPtgt8wn5ZWrGWmKE1Brr25n HsG6tJdHXzegkMico5FpbVA1AzIwmLCZQ6TzBpL+uPNtpmTUkr/4LVfVqkJLfgrd4qkx rV02+6i0Mq24RrX+P9Nn7lHti3mJAzUfbAh2+YFEYtudGyBcZAcFEUntMFvkd6ntW96I LDkQ== MIME-Version: 1.0 X-Received: by 10.236.2.164 with SMTP id 24mr9052000yhf.126.1412633472649; Mon, 06 Oct 2014 15:11:12 -0700 (PDT) Received: by 10.170.186.141 with HTTP; Mon, 6 Oct 2014 15:11:12 -0700 (PDT) In-Reply-To: References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> <1412613830.12052.121.camel@revolution.hippie.lan> Date: Mon, 6 Oct 2014 15:11:12 -0700 Message-ID: Subject: Re: Digi CCWMX53 From: Russell Haley To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm , Ian Lepore , Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 22:11:14 -0000 Okay, that's both great and too bad. I had wondered about the performance of ECC in software. However, it turns out one of the Senior Engineers did his masters on ECC so I had a line on an implementation. Anyway, I won't get to anything for a couple of days but will look into this further on the weekend. Wow. Did I really just get sucked into writing a NFC driver? lolz On Mon, Oct 6, 2014 at 2:30 PM, Warner Losh wrote: > > On Oct 6, 2014, at 1:35 PM, Russell Haley wrote: > >> I have been pinging some of the engineers here about ECC. I *might* be >> able to get someone to help me with a BCH implementation. The >> recommendation was to start by checking the Linux or Android source >> code that comes with the Jump starter Kit. I suspect however they used >> the build in hardware implementation but will verify that. Do you >> want me to look at writing a BSD ECC or implement something that can >> leverage a hardware implementation (which road should I take)? >> >> I guess another factor would be if the iMX6 and next gen Freescale >> stuff uses the same/similar controllers or if it's something different >> altogether? >> >> Also, I was wondering how closely the CWMX53 board support has >> followed the guidelines here: >> https://wiki.freebsd.org/FreeBSDArmBoards? > > I don=E2=80=99t think our current 1-bit ECC is enough. The problem with m= ost of > the SoCs implement strong ECC, but they are all different. They use > different parameters for BCH to achieve the same ECC strength that > different NAND vendors recommend. > > You absolutely have to do this in hardware. Software ECC is too slow by > a factor of 10 or 100, especially as the codes get more complex (some > recent parts require like 39 bits over 1k). 1-bit hamming code is bad eno= ugh. > > Ideally, we can accept a divergence of ECC in the details, and instead al= low > for full and partial hardware offload for ECC generation and correction. > > Warner > > >> On Mon, Oct 6, 2014 at 9:43 AM, Ian Lepore wrote: >>> On Sun, 2014-10-05 at 21:58 -0700, Russell Haley wrote: >>>> Alright, well night one of my crash course in C and it wasn't quite as >>>> painful as I thought. For shits and giggles I started looking in the >>>> /sys/dev/nand directory. Nand.h then led me to ../../sys/bus.h and >>>> then back to some nfc classes where, EUREKA, I found nfc_91.h/c. I >>>> have been reading up on the atmel board support package so I >>>> recognized the at91 moniker. (pretty pleased with myself for that >>>> one...) >>>> >>>> So what I can tell is someone needs to write a mx53/mx6 nand flash >>>> controller that works in roughly the same way as the at91 "prototype". >>>> It would implement various functions and then assign them using: >>>> >>>> static device_method_t at91_nand_methods[] =3D { >>>> DEVMETHOD(device_probe, at91_nand_probe), >>>> DEVMETHOD(device_attach, at91_nand_attach), >>>> >>>> DEVMETHOD(nfc_send_command, at91_nand_send_command), >>>> DEVMETHOD(nfc_send_address, at91_nand_send_address), >>>> DEVMETHOD(nfc_read_byte, at91_nand_read_byte), >>>> DEVMETHOD(nfc_read_buf, at91_nand_read_buf), >>>> DEVMETHOD(nfc_write_buf, at91_nand_write_buf), >>>> DEVMETHOD(nfc_select_cs, at91_nand_select_cs), >>>> DEVMETHOD(nfc_read_rnb, at91_nand_read_rnb), >>>> >>>> DEVMETHOD_END >>>> }; >>>> >>>> >>>> Or some rough order of magnitude in that direction? That would be >>>> where some of the "pre-canded jobs" mentioned in the spec would come >>>> in handy? >>>> >>>> Thanks, >>>> >>>> Russ >>>> >>> >>> If the flash parts in use on your board can use 1-bit Hamming code for >>> ECC, all you need to do is write a nearly-trivial nfc driver similar to >>> at91_nfc. If the flash chips are modern and require multi-bit BCH code= , >>> we don't have a software implementation of that, and the current NFC >>> interface has no provisions for using the hardware accellerator on the >>> imx chip. >>> >>> I can't find any definitive info on what chips that board uses, but I >>> will mention that 1-bit ECC was used on old chips with small capacities >>> long ago and probably isn't used on any modern boards. >>> >>> -- Ian >>> >>> >>>> >>>> >>>> On Sat, Oct 4, 2014 at 4:15 PM, Russell Haley w= rote: >>>>> Warner, >>>>> That's great news! I had a scan and it seemed pretty thorough (albiet >>>>> from a novice point of view). The pre-canned jobs looked promising. >>>>> >>>>> As much as I'm hoping your intention is to fix this FOR me, could you >>>>> point me towards the code for the mtd support? >>>>> >>>>> Many thanks to everyone for helping. I've had more progress in the >>>>> last two weeks than I have in the previous six months. lolz >>>>> >>>>> Russ >>>>> >>>>> >>>>> On Sat, Oct 4, 2014 at 11:05 AM, Warner Losh wrote: >>>>>> Hey Russ, >>>>>> >>>>>> A quick read suggests all, or nearly all, of the data needed to writ= e a full NFC for this chip is present. The programming and read sequences a= nd information about ECC error rates appear to be readily available. The ex= act ECC used, however, appears opaque. This may or may not be a problem. It= even appears to have command sequencing built into the controller. This is= a great feature, but one the current code doesn=E2=80=99t make use of. >>>>>> >>>>>> Warner >>>>>> >>>>>> On Oct 2, 2014, at 10:44 PM, Russell Haley wr= ote: >>>>>> >>>>>>> Warner, >>>>>>> >>>>>>> I was looking for a Digi reference but it turns out the Nand Flash = Controller is part of the Freescale Processor. Here is the link to the Refe= rence Manual: >>>>>>> >>>>>>> cache.freescale.com/files/32bit/doc/ref_manual/iMX53RM.pdf >>>>>>> >>>>>>> The NAND Flash Controller is in Chapter 51 page 3571 to page 3647. >>>>>>> >>>>>>> Is this relevant to what you are looking at doing? https://wiki.fre= ebsd.org/NAND >>>>>>> >>>>>>> I also found something called CHFS for NetBSD that looks interestin= g: http://chewiefs.sed.hu/home >>>>>>> >>>>>>> Thanks, >>>>>>> Russ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Oct 2, 2014 at 2:34 PM, Warner Losh wrote: >>>>>>> >>>>>>> On Oct 1, 2014, at 12:48 AM, Russell Haley w= rote: >>>>>>> >>>>>>>> Warner, >>>>>>>> >>>>>>>> First, I was just watching your 2010 talk on supporting FreeBSD in= a commercial environment. Has there been any updates in the process of mai= ntaining a commercial branch in the last 4 years (not that I have any comme= rcial ventures yet! lolz)? >>>>>>>> >>>>>>>> Anyway, I talked to an Engineer about the NAND controller spec and= he chided me for being naive (poor little software developer, in way over = his head. tisk tisk). He mentioned a FIVE THOUSAND page reference manual, w= hich I have yet to find on the Digi site. >>>>>>> >>>>>>> URL + section number. 5k pages doesn=E2=80=99t necessarily mean it = will be useful, though. :( >>>>>>> >>>>>>>> I have however found this hardware reference: >>>>>>>> >>>>>>>> http://ftp1.digi.com/support/documentation/90001270_E.pdf >>>>>>>> >>>>>>>> From Page 41: >>>>>>>> >>>>>>>> NAND flash memory >>>>>>>> The ConnectCore for i.MX53 module provides 8GB of NAND flash memor= y. On the module in >>>>>>>> the development kits a 512MByte, 2Kbyte page, NAND flash chip is u= sed. This NAND flash >>>>>>>> device is connected to NAND flash Chip Select 0. >>>>>>>> The NAND flash controller signals are available on the module conn= ectors. >>>>>>> >>>>>>> This basically says nothing more useful than =E2=80=9CThere=E2=80= =99s NAND on this board that=E2=80=99s 4Gbits on CS0.=E2=80=9D which is use= ful, but far from sufficient. How do I program the DMA so that ECC is added= to the OOB areas of that NAND? How do I set different ECC tables? How do I= do ECC error correction and detection? If you can=E2=80=99t answer that so= rt of question from the docs you have, then they aren=E2=80=99t helpful eno= ugh. >>>>>>> >>>>>>>> There are pin references to NAND further down in the section "GPIO= multiplexing table in the ConnectCore for i.MX53 module" on page 44 and 49= . >>>>>>>> >>>>>>>> I fear this is not the information we are looking for. >>>>>>> >>>>>>> Not really. The GPIO info might be mildly helpful in a few cases >>>>>>> >>>>>>>> I have found another u-boot fork for the CCWMX53 on github here: h= ttps://github.com/Varcain/uboot-ccwmx53-digi >>>>>>>> >>>>>>>> With what seems to be the information about booting from NAND here= : https://github.com/Varcain/uboot-ccwmx53-digi/tree/master/nand_spl >>>>>>>> >>>>>>>> If you can let me know what I am looking for I can both ask a more= directed question at work and also perform a better search. >>>>>>>> >>>>>>>> I have also started looking over the Architecture handbook as well= because I have a feeling there is going to be lots of driver code in my fu= ture. >>>>>>> >>>>>>> A good first step would be to get a URL or search string to get the= URL for that big spec. It is of the right size to possibly be useful, but = sometimes really long specs have 1-2 page descriptions of things like the S= D controller or the NAND controller that you need special NDAs + business a= rrangements to get, so it is hard to say=E2=80=A6 >>>>>>> >>>>>>> Warner >>>>>>> >>>>>>>> >>>>>>>> On Sun, Sep 28, 2014 at 12:12 AM, Warner Losh wro= te: >>>>>>>> >>>>>>>> On Sep 27, 2014, at 9:49 PM, Russell Haley = wrote: >>>>>>>> >>>>>>>>> I will attempt to load the kernel from tftp as soon as I can. I w= ill need >>>>>>>>> to figure out how to get ethernet to the unit. >>>>>>>>> >>>>>>>>> I know nothing about u-boot so forgive my ignorance but I was hop= ing to >>>>>>>>> modify the Arndale configuration to work such as: >>>>>>>>> >>>>>>>>> # mmc read 1 0x70800000 0x800 0x1800; >>>>>>>>> #go 0x70800000; >>>>>>>>> >>>>>>>>> and then point the rootfs to /dev/da1s1 >>>>>>>>> >>>>>>>>> On another note, do you know where I could find out more about th= e missing >>>>>>>>> MTD support? >>>>>>>> >>>>>>>> A spec for the NAND controller is needed to make that work=E2=80= =A6 Is one about? >>>>>>>> >>>>>>>> Warner >>>>>>>> >>>>>>>> >>>>>>>>> BTW, I thought your wireless mesh stuff was pretty cool. Ah, so m= any cool >>>>>>>>> projects, so little time... >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Russ >>>>>>>>> >>>>>>>>> On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo wrote: >>>>>>>>> >>>>>>>>>> On Sep 27, 2014, at 13:31, Russell Haley = wrote: >>>>>>>>>>> >>>>>>>>>>> Rui, >>>>>>>>>>> >>>>>>>>>>> So no MTD means the NAND on the SOM is out, but can I boot the = kernel >>>>>>>>>> and load rootfs from the microSD, like in this example: >>>>>>>>>>> =E2=80=A2 >>>>>>>>>>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kernel= .bin; go >>>>>>>>>> 0x40f00000" >>>>>>>>>>> >>>>>>>>>>> ARNDALE5250 # saveenv >>>>>>>>>>> >>>>>>>>>>> ARNDALE5250 # boot >>>>>>>>>> >>>>>>>>>> You can't use the Arndale config since the load addresses are di= fferent. >>>>>>>>>> You should be able to load a kernel from the network. Can you d= o that? >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Rui Paulo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> freebsd-arm@freebsd.org mailing list >>>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>>>>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd= .org" >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> _______________________________________________ >>>> freebsd-arm@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >>>> >>> >>> > From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 01:05:32 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5490F867 for ; Tue, 7 Oct 2014 01:05:32 +0000 (UTC) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23ECC77F for ; Tue, 7 Oct 2014 01:05:31 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id eu11so6223436pac.14 for ; Mon, 06 Oct 2014 18:05:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ScBz1YTqoPD5V9bXlZfkFPjWd7ptqfNeCzeOutMbynU=; b=kLWBgQJgWL7WM+brYhLQere5BP8ubNdTNE5jGEOQN0js+hUmLdifrMPRs5guyazGaf k37rO8g0wAuamfIMkWP4FPvGQcWeVK1r7vJRf4a+LbJ5MaufmSNagE88oQjJOg2db8GX TLCgRFHwe3P2wWJ0J0cmaADh/BSc/WMlcv14ht5kaKttLKX4nu64L1uy8xuhAT2DbbQX I90ATZEJ3kjaFqcnI07lmszjAZHfWtvnHUTtnu4hxRQ7N3FOnmEjurBdsGgjL6vxZFE4 JYDXNtSm/6xoGx9r4h9FtyEHP6LYBxWbL92hosXqeyjR7s5nFRqxaYCMTSYqP8lW6MGO LbPg== X-Gm-Message-State: ALoCoQmxPVd1pDiFLTn5JuMgSTpKySTulCFTI/Vcd0QUBMTCaNvi1mIgii3tEYXSUlxl2vcAl0TD X-Received: by 10.70.37.208 with SMTP id a16mr251853pdk.147.1412643924841; Mon, 06 Oct 2014 18:05:24 -0700 (PDT) Received: from [10.64.24.174] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id qs4sm14283630pbb.90.2014.10.06.18.05.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Oct 2014 18:05:24 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_6DE1E3B5-466D-4586-ACCE-6DE5181F465C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [RFC] Add and armv7hf TARGET_ARCH From: Warner Losh In-Reply-To: <54330F01.4050108@fgznet.ch> Date: Mon, 6 Oct 2014 19:05:21 -0600 Message-Id: References: <20141006134626.59cc5573@bender.lan> <54330F01.4050108@fgznet.ch> To: Andreas Tobler X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 01:05:32 -0000 --Apple-Mail=_6DE1E3B5-466D-4586-ACCE-6DE5181F465C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Oct 6, 2014, at 3:52 PM, Andreas Tobler wrote: > On 06.10.14 14:46, Andrew Turner wrote: >> I'm interested in peoples opinion on creating a new TARGET_ARCH to >> target ARMv7 SoCs. This will target all the current Cortex-A chips we >> support but not the Raspberry Pi. My intention with this is to have it >> become the tier 1 arm platform. >> >> This platform will support 32-bit Cortex-A based SoCs with a VFP >> unit. As it would be targeting ARMv7 we could look at supporting >> Thumb-2. >> >> As the VFP unit is optional and future SoCs without it will only be >> supported by the armv6 TARGET_ARCH, however I would expect almost all >> ARMv7 designs to include it. >> >> There is a downside to this, and as far as I know the problems are: >> * It could be confusing to figure out which TARGET_ARCH you need. >> * The Raspberry Pi will not be supported as its core is too old. >> >> I've attached my patch to build as armv7hf. It has been tested on a >> Wandboard Quad. >> >> Comments? > > Here the patch does not apply. Manually applied. > > Configuring math/gmp shows a segfaulting clang++. > > Investigating later. > > Went back to clang built v6hf, since gcc built pkg on v6 segfaults too. > Sigh. I need more such board to test in parallel... > > I think something like this part would also be needed, no? > > Thanks, > Andreas > > Index: sys/arm/include/param.h > =================================================================== > --- sys/arm/include/param.h (revision 272668) > +++ sys/arm/include/param.h (working copy) > @@ -53,9 +53,13 @@ > > #define __PCI_REROUTE_INTERRUPT > > -#if __ARM_ARCH >= 6 > +#if __ARM_ARCH >= 7 > +#define _V6_SUFFIX "v7" > +#endif Does the fact that arm64 is armv8 matter? Warner > +#if __ARM_ARCH == 6 > #define _V6_SUFFIX "v6" > -#else > +#endif > +#if __ARM_ARCH <= 5 > #define _V6_SUFFIX "" > #endif > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --Apple-Mail=_6DE1E3B5-466D-4586-ACCE-6DE5181F465C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUMzxRAAoJEGwc0Sh9sBEAR2oQAMcNvExS6MvNxc1AwRyI5mTe yiZXPkka3CFm6DoPbT2gcU5mmvvjBNoyfXhQJFWGdSU4kRs0d26CTsOO4Jmxg9Le uzbnqATbP6COqiYwDPabZ3cp8uDO+oYUDenwkIPm8SL/nvpuj6T1iVeaH214w0jx /JfG0mV9V+rtMYdFXzXaamjAR1EfILY1PaeMFq/xL8WLodZDUvGHipCTIgK9/2ZU MIzSyBHUoJkgooHuHLJpWgyhKvzUqLxPnL8xJ9W8UwSkzqhrbQDSeWNd9f3ibExK pJNhE2eiM6nguyhrfmZ4ZthaZpsUOGojJ5MsXtjJie3QxGaffGmZ30Pt2ZZ8wWtU uMn/A1FwgekNpNN0L3cq9FO4JUyS6+ox+IYJvklb+ufrgolif0tCBDxqHS8Ca2b1 Ui+xOspHL4XE3Cm80a4Wj8YqtE+Uj4OGgLieSlCwAoC5/p3OP+46+n/yWTFmFlDG puEmYCTdYIqSUHlixGnPO1SAatxWy699pDnJgltVq7wDrB2kjttZzSY5Tb5d/V2p FAq5EazgtE3Ix+Uyw9JttcSQp22qWSd17buqjsOxkA7kH96X9EVj5mlTmAktcF4Z ETCXwMNyMUfo57GXa95WGQ/Rk7ZBkb+Cog0KMfEQr8ZjL73DyT+1y4HIEEdOoW5j YU+cp0VFtOC6YUcFjqsH =ImGi -----END PGP SIGNATURE----- --Apple-Mail=_6DE1E3B5-466D-4586-ACCE-6DE5181F465C-- From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 04:24:33 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0009EEB for ; Tue, 7 Oct 2014 04:24:33 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 90D34C90 for ; Tue, 7 Oct 2014 04:24:32 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s974OVKg017315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Oct 2014 21:24:32 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s974OUiD017314; Mon, 6 Oct 2014 21:24:30 -0700 (PDT) (envelope-from jmg) Date: Mon, 6 Oct 2014 21:24:30 -0700 From: John-Mark Gurney To: Andrew Turner Subject: Re: [RFC] Add and armv7hf TARGET_ARCH Message-ID: <20141007042430.GH1852@funkthat.com> Mail-Followup-To: Andrew Turner , freebsd-arm@freebsd.org References: <20141006134626.59cc5573@bender.lan> <20141006173045.GE1852@funkthat.com> <20141006224124.494267e0@bender.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141006224124.494267e0@bender.lan> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 06 Oct 2014 21:24:32 -0700 (PDT) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 04:24:33 -0000 Andrew Turner wrote this message on Mon, Oct 06, 2014 at 22:41 +0100: > On Mon, 6 Oct 2014 10:30:45 -0700 > John-Mark Gurney wrote: > > > Andrew Turner wrote this message on Mon, Oct 06, 2014 at 13:46 +0100: > > > I'm interested in peoples opinion on creating a new TARGET_ARCH to > > > target ARMv7 SoCs. This will target all the current Cortex-A chips > > > we support but not the Raspberry Pi. My intention with this is to > > > have it become the tier 1 arm platform. > > > > > > This platform will support 32-bit Cortex-A based SoCs with a VFP > > > unit. As it would be targeting ARMv7 we could look at supporting > > > Thumb-2. > > > > > > As the VFP unit is optional and future SoCs without it will only be > > > supported by the armv6 TARGET_ARCH, however I would expect almost > > > all ARMv7 designs to include it. > > > > So, what are the specific pros of having a new arch? I see you talk > > about Thumb-2 support, but are there other advantages? Will we get > > significant performance boosts? What? > > We would get a significant speed improvement for anything that uses > floating-point. I haven't done extensive tests, but Ian was getting > around 30x-34x improvement by using the vfp on one benchmark [1]. I've > seen a sight improvement of around 3-5 MFlops on his numbers on my > board. > > I expect there to be a slight performance improvement from being able > to use the newer ARMv7 instructions, however this will be less > pronounced than the above floating-point improvement. > > There are also a number of NEON optimised libc functions we could make > use of, for example [2]. While we may be able to use them on armv6 it > becomes simpler if we can assume we have a NEON unit. Don't we already have armv6hf for hardware float? What is the difference between armv6hf and armv7hf? or is this 30x-34x improvement over armv6hf? > > Also, what impact will this have on trying to get binary packages > > for other arm archs? i.e. will this significantly take away > > resources? If we do this split, why would we want to build binary > > packages for RPI? > > This would depend on how we expect to build them. If the packages are > cross built it would mean having two machines to build packages on > rather than one. If we have native package building I could see > managing two clusters could be difficult. > > Andrew > > [1] > https://lists.freebsd.org/pipermail/freebsd-arm/2014-February/007555.html > [2] > https://android.googlesource.com/platform/bionic/+/master/libc/arch-arm/bionic/memcpy.S -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 04:41:42 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A699B2F1; Tue, 7 Oct 2014 04:41:42 +0000 (UTC) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 510E2E99; Tue, 7 Oct 2014 04:41:42 +0000 (UTC) Received: by mail-yk0-f181.google.com with SMTP id q200so2556830ykb.12 for ; Mon, 06 Oct 2014 21:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=DepDNcraGv7q+1Zzgyfhe1sLwFWcpEiNyv6pttSyZyo=; b=sTyoBjfOh4Ev5IcpvCEe3K2k4pLbBKQIh4nHhAoKtTGhi6iP9qD9a4RIg1OmKy+x/W IabDpPZfC491kTCy44+WHE0MPj/3S54U67xc3v0CNzN4snIydn45Kmzg3Uvr/mFshuNM Bh7dosk/X9lJiI4dAuLEu1mlCg9XKhyc9lDDk3RZAjgZt0K72luS3bxHFNEkGGK8ZtAH DxnNM5gVJJwm8mot/ZSIdVw3HYc8WUPmfdlnpwWoG1/OqBoGgZim+h7si7GeOZfnCapq LPS7y4E+5KHwTqV2SrQJy0lBDvYsV80jstVxBnrqDM/ApDrAnUzd0dnI2lKUfkkOyZwL DNWw== MIME-Version: 1.0 X-Received: by 10.236.39.177 with SMTP id d37mr1920540yhb.121.1412656901403; Mon, 06 Oct 2014 21:41:41 -0700 (PDT) Received: by 10.170.186.141 with HTTP; Mon, 6 Oct 2014 21:41:41 -0700 (PDT) In-Reply-To: References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> <1412613830.12052.121.camel@revolution.hippie.lan> Date: Mon, 6 Oct 2014 21:41:41 -0700 Message-ID: Subject: Re: Digi CCWMX53 From: Russell Haley To: Warner Losh , Ian Lepore , freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 04:41:42 -0000 Hey, Okay, I lied about waiting till the weekend. I am looking at the atmel files. Should I be replacing the at91 moniker with imx (processor class) or mx53 (implementation)? Thanks, Russ On Mon, Oct 6, 2014 at 3:11 PM, Russell Haley wrote: > Okay, that's both great and too bad. I had wondered about the > performance of ECC in software. However, it turns out one of the > Senior Engineers did his masters on ECC so I had a line on an > implementation. > > Anyway, I won't get to anything for a couple of days but will look > into this further on the weekend. Wow. Did I really just get sucked > into writing a NFC driver? lolz > > On Mon, Oct 6, 2014 at 2:30 PM, Warner Losh wrote: >> >> On Oct 6, 2014, at 1:35 PM, Russell Haley wrote: >> >>> I have been pinging some of the engineers here about ECC. I *might* be >>> able to get someone to help me with a BCH implementation. The >>> recommendation was to start by checking the Linux or Android source >>> code that comes with the Jump starter Kit. I suspect however they used >>> the build in hardware implementation but will verify that. Do you >>> want me to look at writing a BSD ECC or implement something that can >>> leverage a hardware implementation (which road should I take)? >>> >>> I guess another factor would be if the iMX6 and next gen Freescale >>> stuff uses the same/similar controllers or if it's something different >>> altogether? >>> >>> Also, I was wondering how closely the CWMX53 board support has >>> followed the guidelines here: >>> https://wiki.freebsd.org/FreeBSDArmBoards? >> >> I don=E2=80=99t think our current 1-bit ECC is enough. The problem with = most of >> the SoCs implement strong ECC, but they are all different. They use >> different parameters for BCH to achieve the same ECC strength that >> different NAND vendors recommend. >> >> You absolutely have to do this in hardware. Software ECC is too slow by >> a factor of 10 or 100, especially as the codes get more complex (some >> recent parts require like 39 bits over 1k). 1-bit hamming code is bad en= ough. >> >> Ideally, we can accept a divergence of ECC in the details, and instead a= llow >> for full and partial hardware offload for ECC generation and correction. >> >> Warner >> >> >>> On Mon, Oct 6, 2014 at 9:43 AM, Ian Lepore wrote: >>>> On Sun, 2014-10-05 at 21:58 -0700, Russell Haley wrote: >>>>> Alright, well night one of my crash course in C and it wasn't quite a= s >>>>> painful as I thought. For shits and giggles I started looking in the >>>>> /sys/dev/nand directory. Nand.h then led me to ../../sys/bus.h and >>>>> then back to some nfc classes where, EUREKA, I found nfc_91.h/c. I >>>>> have been reading up on the atmel board support package so I >>>>> recognized the at91 moniker. (pretty pleased with myself for that >>>>> one...) >>>>> >>>>> So what I can tell is someone needs to write a mx53/mx6 nand flash >>>>> controller that works in roughly the same way as the at91 "prototype"= . >>>>> It would implement various functions and then assign them using: >>>>> >>>>> static device_method_t at91_nand_methods[] =3D { >>>>> DEVMETHOD(device_probe, at91_nand_probe), >>>>> DEVMETHOD(device_attach, at91_nand_attach), >>>>> >>>>> DEVMETHOD(nfc_send_command, at91_nand_send_command), >>>>> DEVMETHOD(nfc_send_address, at91_nand_send_address), >>>>> DEVMETHOD(nfc_read_byte, at91_nand_read_byte), >>>>> DEVMETHOD(nfc_read_buf, at91_nand_read_buf), >>>>> DEVMETHOD(nfc_write_buf, at91_nand_write_buf), >>>>> DEVMETHOD(nfc_select_cs, at91_nand_select_cs), >>>>> DEVMETHOD(nfc_read_rnb, at91_nand_read_rnb), >>>>> >>>>> DEVMETHOD_END >>>>> }; >>>>> >>>>> >>>>> Or some rough order of magnitude in that direction? That would be >>>>> where some of the "pre-canded jobs" mentioned in the spec would come >>>>> in handy? >>>>> >>>>> Thanks, >>>>> >>>>> Russ >>>>> >>>> >>>> If the flash parts in use on your board can use 1-bit Hamming code for >>>> ECC, all you need to do is write a nearly-trivial nfc driver similar t= o >>>> at91_nfc. If the flash chips are modern and require multi-bit BCH cod= e, >>>> we don't have a software implementation of that, and the current NFC >>>> interface has no provisions for using the hardware accellerator on the >>>> imx chip. >>>> >>>> I can't find any definitive info on what chips that board uses, but I >>>> will mention that 1-bit ECC was used on old chips with small capacitie= s >>>> long ago and probably isn't used on any modern boards. >>>> >>>> -- Ian >>>> >>>> >>>>> >>>>> >>>>> On Sat, Oct 4, 2014 at 4:15 PM, Russell Haley = wrote: >>>>>> Warner, >>>>>> That's great news! I had a scan and it seemed pretty thorough (albie= t >>>>>> from a novice point of view). The pre-canned jobs looked promising. >>>>>> >>>>>> As much as I'm hoping your intention is to fix this FOR me, could yo= u >>>>>> point me towards the code for the mtd support? >>>>>> >>>>>> Many thanks to everyone for helping. I've had more progress in the >>>>>> last two weeks than I have in the previous six months. lolz >>>>>> >>>>>> Russ >>>>>> >>>>>> >>>>>> On Sat, Oct 4, 2014 at 11:05 AM, Warner Losh wrote: >>>>>>> Hey Russ, >>>>>>> >>>>>>> A quick read suggests all, or nearly all, of the data needed to wri= te a full NFC for this chip is present. The programming and read sequences = and information about ECC error rates appear to be readily available. The e= xact ECC used, however, appears opaque. This may or may not be a problem. I= t even appears to have command sequencing built into the controller. This i= s a great feature, but one the current code doesn=E2=80=99t make use of. >>>>>>> >>>>>>> Warner >>>>>>> >>>>>>> On Oct 2, 2014, at 10:44 PM, Russell Haley w= rote: >>>>>>> >>>>>>>> Warner, >>>>>>>> >>>>>>>> I was looking for a Digi reference but it turns out the Nand Flash= Controller is part of the Freescale Processor. Here is the link to the Ref= erence Manual: >>>>>>>> >>>>>>>> cache.freescale.com/files/32bit/doc/ref_manual/iMX53RM.pdf >>>>>>>> >>>>>>>> The NAND Flash Controller is in Chapter 51 page 3571 to page 3647. >>>>>>>> >>>>>>>> Is this relevant to what you are looking at doing? https://wiki.fr= eebsd.org/NAND >>>>>>>> >>>>>>>> I also found something called CHFS for NetBSD that looks interesti= ng: http://chewiefs.sed.hu/home >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Russ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Oct 2, 2014 at 2:34 PM, Warner Losh wrote= : >>>>>>>> >>>>>>>> On Oct 1, 2014, at 12:48 AM, Russell Haley = wrote: >>>>>>>> >>>>>>>>> Warner, >>>>>>>>> >>>>>>>>> First, I was just watching your 2010 talk on supporting FreeBSD i= n a commercial environment. Has there been any updates in the process of ma= intaining a commercial branch in the last 4 years (not that I have any comm= ercial ventures yet! lolz)? >>>>>>>>> >>>>>>>>> Anyway, I talked to an Engineer about the NAND controller spec an= d he chided me for being naive (poor little software developer, in way over= his head. tisk tisk). He mentioned a FIVE THOUSAND page reference manual, = which I have yet to find on the Digi site. >>>>>>>> >>>>>>>> URL + section number. 5k pages doesn=E2=80=99t necessarily mean it= will be useful, though. :( >>>>>>>> >>>>>>>>> I have however found this hardware reference: >>>>>>>>> >>>>>>>>> http://ftp1.digi.com/support/documentation/90001270_E.pdf >>>>>>>>> >>>>>>>>> From Page 41: >>>>>>>>> >>>>>>>>> NAND flash memory >>>>>>>>> The ConnectCore for i.MX53 module provides 8GB of NAND flash memo= ry. On the module in >>>>>>>>> the development kits a 512MByte, 2Kbyte page, NAND flash chip is = used. This NAND flash >>>>>>>>> device is connected to NAND flash Chip Select 0. >>>>>>>>> The NAND flash controller signals are available on the module con= nectors. >>>>>>>> >>>>>>>> This basically says nothing more useful than =E2=80=9CThere=E2=80= =99s NAND on this board that=E2=80=99s 4Gbits on CS0.=E2=80=9D which is use= ful, but far from sufficient. How do I program the DMA so that ECC is added= to the OOB areas of that NAND? How do I set different ECC tables? How do I= do ECC error correction and detection? If you can=E2=80=99t answer that so= rt of question from the docs you have, then they aren=E2=80=99t helpful eno= ugh. >>>>>>>> >>>>>>>>> There are pin references to NAND further down in the section "GPI= O multiplexing table in the ConnectCore for i.MX53 module" on page 44 and 4= 9. >>>>>>>>> >>>>>>>>> I fear this is not the information we are looking for. >>>>>>>> >>>>>>>> Not really. The GPIO info might be mildly helpful in a few cases >>>>>>>> >>>>>>>>> I have found another u-boot fork for the CCWMX53 on github here: = https://github.com/Varcain/uboot-ccwmx53-digi >>>>>>>>> >>>>>>>>> With what seems to be the information about booting from NAND her= e: https://github.com/Varcain/uboot-ccwmx53-digi/tree/master/nand_spl >>>>>>>>> >>>>>>>>> If you can let me know what I am looking for I can both ask a mor= e directed question at work and also perform a better search. >>>>>>>>> >>>>>>>>> I have also started looking over the Architecture handbook as wel= l because I have a feeling there is going to be lots of driver code in my f= uture. >>>>>>>> >>>>>>>> A good first step would be to get a URL or search string to get th= e URL for that big spec. It is of the right size to possibly be useful, but= sometimes really long specs have 1-2 page descriptions of things like the = SD controller or the NAND controller that you need special NDAs + business = arrangements to get, so it is hard to say=E2=80=A6 >>>>>>>> >>>>>>>> Warner >>>>>>>> >>>>>>>>> >>>>>>>>> On Sun, Sep 28, 2014 at 12:12 AM, Warner Losh wr= ote: >>>>>>>>> >>>>>>>>> On Sep 27, 2014, at 9:49 PM, Russell Haley = wrote: >>>>>>>>> >>>>>>>>>> I will attempt to load the kernel from tftp as soon as I can. I = will need >>>>>>>>>> to figure out how to get ethernet to the unit. >>>>>>>>>> >>>>>>>>>> I know nothing about u-boot so forgive my ignorance but I was ho= ping to >>>>>>>>>> modify the Arndale configuration to work such as: >>>>>>>>>> >>>>>>>>>> # mmc read 1 0x70800000 0x800 0x1800; >>>>>>>>>> #go 0x70800000; >>>>>>>>>> >>>>>>>>>> and then point the rootfs to /dev/da1s1 >>>>>>>>>> >>>>>>>>>> On another note, do you know where I could find out more about t= he missing >>>>>>>>>> MTD support? >>>>>>>>> >>>>>>>>> A spec for the NAND controller is needed to make that work=E2=80= =A6 Is one about? >>>>>>>>> >>>>>>>>> Warner >>>>>>>>> >>>>>>>>> >>>>>>>>>> BTW, I thought your wireless mesh stuff was pretty cool. Ah, so = many cool >>>>>>>>>> projects, so little time... >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Russ >>>>>>>>>> >>>>>>>>>> On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo wrote= : >>>>>>>>>> >>>>>>>>>>> On Sep 27, 2014, at 13:31, Russell Haley = wrote: >>>>>>>>>>>> >>>>>>>>>>>> Rui, >>>>>>>>>>>> >>>>>>>>>>>> So no MTD means the NAND on the SOM is out, but can I boot the= kernel >>>>>>>>>>> and load rootfs from the microSD, like in this example: >>>>>>>>>>>> =E2=80=A2 >>>>>>>>>>>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kerne= l.bin; go >>>>>>>>>>> 0x40f00000" >>>>>>>>>>>> >>>>>>>>>>>> ARNDALE5250 # saveenv >>>>>>>>>>>> >>>>>>>>>>>> ARNDALE5250 # boot >>>>>>>>>>> >>>>>>>>>>> You can't use the Arndale config since the load addresses are d= ifferent. >>>>>>>>>>> You should be able to load a kernel from the network. Can you = do that? >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Rui Paulo >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> freebsd-arm@freebsd.org mailing list >>>>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>>>>>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebs= d.org" >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> freebsd-arm@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org= " >>>>> >>>> >>>> >> From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 08:20:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2373E6F7 for ; Tue, 7 Oct 2014 08:20:15 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 084FA9C7 for ; Tue, 7 Oct 2014 08:20:14 +0000 (UTC) Received: from bender.lan (97e07ab1.skybroadband.com [151.224.122.177]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 9F7EE5C0B9; Tue, 7 Oct 2014 08:20:12 +0000 (UTC) Date: Tue, 7 Oct 2014 09:20:03 +0100 From: Andrew Turner To: Andreas Tobler Subject: Re: [RFC] Add and armv7hf TARGET_ARCH Message-ID: <20141007092003.6cb99027@bender.lan> In-Reply-To: <54330F01.4050108@fgznet.ch> References: <20141006134626.59cc5573@bender.lan> <54330F01.4050108@fgznet.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 08:20:15 -0000 On Mon, 06 Oct 2014 23:52:01 +0200 Andreas Tobler wrote: > On 06.10.14 14:46, Andrew Turner wrote: > > I'm interested in peoples opinion on creating a new TARGET_ARCH to > > target ARMv7 SoCs. This will target all the current Cortex-A chips > > we support but not the Raspberry Pi. My intention with this is to > > have it become the tier 1 arm platform. > > > > This platform will support 32-bit Cortex-A based SoCs with a VFP > > unit. As it would be targeting ARMv7 we could look at supporting > > Thumb-2. > > > > As the VFP unit is optional and future SoCs without it will only be > > supported by the armv6 TARGET_ARCH, however I would expect almost > > all ARMv7 designs to include it. > > > > There is a downside to this, and as far as I know the problems are: > > * It could be confusing to figure out which TARGET_ARCH you need. > > * The Raspberry Pi will not be supported as its core is too old. > > > > I've attached my patch to build as armv7hf. It has been tested on a > > Wandboard Quad. > > > > Comments? > > Here the patch does not apply. Manually applied. It will need you to be on a recent revision as I've been committing various fixes as I find them. > > Configuring math/gmp shows a segfaulting clang++. All I've worked on so far is getting base to compile and run, no ports as yet. I'm planning on testing a few with poudriere later. > Investigating later. > > Went back to clang built v6hf, since gcc built pkg on v6 segfaults > too. Sigh. I need more such board to test in parallel... > > I think something like this part would also be needed, no? Yes, I missed that. Andrew From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 08:44:38 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1307CEB8 for ; Tue, 7 Oct 2014 08:44:38 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id EA5D7CB9 for ; Tue, 7 Oct 2014 08:44:37 +0000 (UTC) Received: from bender.lan (97e07ab1.skybroadband.com [151.224.122.177]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 792EA5C0B9; Tue, 7 Oct 2014 08:44:36 +0000 (UTC) Date: Tue, 7 Oct 2014 09:44:31 +0100 From: Andrew Turner To: John-Mark Gurney Subject: Re: [RFC] Add and armv7hf TARGET_ARCH Message-ID: <20141007094431.09600b56@bender.lan> In-Reply-To: <20141007042430.GH1852@funkthat.com> References: <20141006134626.59cc5573@bender.lan> <20141006173045.GE1852@funkthat.com> <20141006224124.494267e0@bender.lan> <20141007042430.GH1852@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 08:44:38 -0000 On Mon, 6 Oct 2014 21:24:30 -0700 John-Mark Gurney wrote: > Andrew Turner wrote this message on Mon, Oct 06, 2014 at 22:41 +0100: > > On Mon, 6 Oct 2014 10:30:45 -0700 > > John-Mark Gurney wrote: > > > > > Andrew Turner wrote this message on Mon, Oct 06, 2014 at 13:46 > > > +0100: > > > > I'm interested in peoples opinion on creating a new TARGET_ARCH > > > > to target ARMv7 SoCs. This will target all the current Cortex-A > > > > chips we support but not the Raspberry Pi. My intention with > > > > this is to have it become the tier 1 arm platform. > > > > > > > > This platform will support 32-bit Cortex-A based SoCs with a VFP > > > > unit. As it would be targeting ARMv7 we could look at supporting > > > > Thumb-2. > > > > > > > > As the VFP unit is optional and future SoCs without it will > > > > only be supported by the armv6 TARGET_ARCH, however I would > > > > expect almost all ARMv7 designs to include it. > > > > > > So, what are the specific pros of having a new arch? I see you > > > talk about Thumb-2 support, but are there other advantages? Will > > > we get significant performance boosts? What? > > > > We would get a significant speed improvement for anything that uses > > floating-point. I haven't done extensive tests, but Ian was getting > > around 30x-34x improvement by using the vfp on one benchmark [1]. > > I've seen a sight improvement of around 3-5 MFlops on his numbers > > on my board. > > > > I expect there to be a slight performance improvement from being > > able to use the newer ARMv7 instructions, however this will be less > > pronounced than the above floating-point improvement. > > > > There are also a number of NEON optimised libc functions we could > > make use of, for example [2]. While we may be able to use them on > > armv6 it becomes simpler if we can assume we have a NEON unit. > > Don't we already have armv6hf for hardware float? What is the > difference between armv6hf and armv7hf? or is this 30x-34x > improvement over armv6hf? My plan is to replace the armv6hf with armv7hf. The difference between the two is, on armv7hf we can assume newer floating-point instructions including the NEON SIMD instructions. The performance improvement above was changing from the soft to softfp ABI. Softfp allows the compiler to generate vfp code, but will pass floating-point data between functions in the integer registers. It has been reported on some cores moving data between the vfp and arm registers can cause both to stall for at least 20 cycles [1]. While armv7hf doesn't remove the need to move between groups of registers completely it will reduce the need due to the calling convention. Andrew [1] http://pandorawiki.org/Floating_Point_Optimization From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 09:44:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87312B2B for ; Tue, 7 Oct 2014 09:44:54 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 6A759325 for ; Tue, 7 Oct 2014 09:44:53 +0000 (UTC) Received: from bender.lan (97e07ab1.skybroadband.com [151.224.122.177]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id D92FE5CC08; Tue, 7 Oct 2014 09:44:52 +0000 (UTC) Date: Tue, 7 Oct 2014 10:44:41 +0100 From: Andrew Turner To: Warner Losh Subject: Re: [RFC] Add and armv7hf TARGET_ARCH Message-ID: <20141007104441.6f779866@bender.lan> In-Reply-To: References: <20141006134626.59cc5573@bender.lan> <54330F01.4050108@fgznet.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 09:44:54 -0000 On Mon, 6 Oct 2014 19:05:21 -0600 Warner Losh wrote: > On Oct 6, 2014, at 3:52 PM, Andreas Tobler > wrote: > > I think something like this part would also be needed, no? > > > > Thanks, > > Andreas > > > > Index: sys/arm/include/param.h > > =================================================================== > > --- sys/arm/include/param.h (revision 272668) > > +++ sys/arm/include/param.h (working copy) > > @@ -53,9 +53,13 @@ > > > > #define __PCI_REROUTE_INTERRUPT > > > > -#if __ARM_ARCH >= 6 > > +#if __ARM_ARCH >= 7 > > +#define _V6_SUFFIX "v7" > > +#endif > > Does the fact that arm64 is armv8 matter? Not really, armv8 is able to execute in both AArch64 (arm64) and AArch32 (armv6, armv7hf) modes. I would expect arm64 to report it being and armv7hf when executing a 32-bit application. Andrew From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 12:31:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0D4FD9C for ; Tue, 7 Oct 2014 12:31:47 +0000 (UTC) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C622D936 for ; Tue, 7 Oct 2014 12:31:47 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id kx10so7206225pab.9 for ; Tue, 07 Oct 2014 05:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=yGhNSfP5nGPLCLUHI36JdrmVnWaWelPodYcViF43EhY=; b=LJDIVE/M69klXYjTAWUpcp2M0SOSyGGdhPvei3qahK1D7QLHrsq4LM7XMFVFwKNOyi MttnOsnb8yE7R4+hN7xIdlZUSIyoTx9v+ANYcQfQTm7kxQ+nOQp6lZz9JjavPnqYEI6K bV1pSFAYSnmHkz1FeEQvywRdB+E5l6zsZYZ7j4tMOvcN/W0K9pUl2JNfh0FR8GDGSWDF 4EREf453z94W5OBPmj1r8YgT0jZ2pFo/e0OKesMyrFlHR2zZH1izZJbDZf//GFs77CI+ s1OQ0KXRH16gnxLlGxDu4+DZBvQYSE11F0zdOMrGqSxR5ihWvQSzlhgPh59WQQ5o5+LU 7kRA== X-Received: by 10.68.132.225 with SMTP id ox1mr3410695pbb.71.1412685107406; Tue, 07 Oct 2014 05:31:47 -0700 (PDT) Received: from [172.30.1.41] ([112.168.75.52]) by mx.google.com with ESMTPSA id qs4sm15839419pbb.90.2014.10.07.05.31.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Oct 2014 05:31:46 -0700 (PDT) Message-ID: <5433DD2E.1050807@gmail.com> Date: Tue, 07 Oct 2014 21:31:42 +0900 From: Jaemin Yoo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Q: linking method for armv8 kernel build References: <5432A1B5.30406@gmail.com> <20141006154314.1b909772@bender.lan> In-Reply-To: <20141006154314.1b909772@bender.lan> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 12:31:48 -0000 2014-10-06 PM 11:43, Andrew Turner wrote: > On Mon, 06 Oct 2014 23:05:41 +0900 > Jaemin Yoo wrote: > >> Hello, I just began to download and build kernel for armv8 according >> to the following howto page. (https://wiki.freebsd.org/arm64) >> >> I could create the kernel image without problem. But 'file' says >> it's dynamically linked. I expected statically linked image to load >> it on dram using uboot. >> >> Is it meant to be? or am I missing some configuration? > > All examples of the FreeBSD kernel I've looked at say they are > dynamically linked. The requirement is the kernel needs to be loaded at > a 2MiB aligned address for the VA->PA translation to work. It will > create the page table so the kernel base points to the load address. > > You may have problems loading it with U-Boot. It expects to be loaded > by the loader as it passes in the device tree. U-Boot has been found to > be difficult to support on 32-bit arm. Is there a reason to prefer it > over UEFI? > > Andrew > Thanks. I'm doing most work at linux and vmlinux is mostly(?) statically linked. So I thought same goes for freebsd too. There are some 'UND' functions in kernel but I guess it's okay if they are not used. I got a 64bit arm board which runs linux from APM. It came with binary and source codes of u-boot. So I planned to enable bootelf and load kernel on dram after adding uart driver for the board. I just want to see freebsd kernel boot on arm64 with minimal changes. Best Regards, Jaemin ps. I hope to contribute for enabling freebsd on arm64. :) From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 13:16:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BEBA0D2F for ; Tue, 7 Oct 2014 13:16:49 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8F8C5D83 for ; Tue, 7 Oct 2014 13:16:49 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XbUdD-0005ph-KC; Tue, 07 Oct 2014 13:16:47 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s97DGkPf030412; Tue, 7 Oct 2014 07:16:46 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19vqqERSvqgumzZrzA64fr0 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Digi CCWMX53 From: Ian Lepore To: Russell Haley In-Reply-To: References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> <1412613830.12052.121.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Tue, 07 Oct 2014 07:16:45 -0600 Message-ID: <1412687805.12052.199.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 13:16:49 -0000 On Mon, 2014-10-06 at 21:41 -0700, Russell Haley wrote: > Hey, > > Okay, I lied about waiting till the weekend. I am looking at the atmel > files. Should I be replacing the at91 moniker with imx (processor > class) or mx53 (implementation)? > > Thanks, > > Russ With a quick glance at the manuals, it appears imx51 and imx53 have the same nand controller hardware, but imx6 is completely different, so 'imx5' would be the right prefix for file and function/data names. That said, I want to point out that there's a huge difference between the simplistic memory controller for accessing nand in the at91 hardware and the much more complex nand hardware in the imx5 series. I don't think you're going to get far by trying to copy the at91 driver. In fact, I think you're going to find it impossible to make the imx5 BCH hardware work with the upper layers of the nand software in freebsd without some serious redesign of the upper layers (and then of course the associated rewriting of existing low-level nfc drivers). It's not that I want to discourage you from trying, I just want to be realistic here. What you're embarking on isn't a couple days of converting an existing driver -- in my estimation, you're looking at weeks of work. I don't mean 3 calendar weeks of a couple hours each evening hobbyist work, I'm talking hundreds of hours of development time. The harsh reality is that freebsd doesn't have adequate nand flash support for modern hardware. We don't even have the framework of a design that can accomodate things like hardware offload of ECC. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 15:12:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D49BE4BD for ; Tue, 7 Oct 2014 15:12:12 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 976FBDE7 for ; Tue, 7 Oct 2014 15:12:12 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1XbWC2-0004yJ-G1 for freebsd-arm@freebsd.org; Tue, 07 Oct 2014 16:56:55 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Date: Tue, 07 Oct 2014 16:56:49 +0200 Subject: Why are arm libs branded as SYSV? MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: User-Agent: Opera Mail/12.17 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: -- X-Spam-Score: -2.9 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=disabled version=3.3.1 X-Scan-Signature: 919fae14bc17c74543a025539baad412 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 15:12:12 -0000 On my ARM Sheevaplug: # file /usr/local/lib/libpcre.so.3 /usr/local/lib/libpcre.so.3: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, stripped On my amd64 computer: file /usr/local/lib/libpcre.so.3 /usr/local/lib/libpcre.so.3: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, stripped Because of this I can not run ldd on a shared library on my ARM system. # ldd -a /usr/local/lib/libpcre.so.3 ldd: /usr/local/lib/libpcre.so.3: not a FreeBSD ELF shared object Is that on purpose? I am curious why that is. My ARM machine runs: # uname -a FreeBSD sheeva.klop.ws 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r272028M: Tue Sep 23 17:11:45 CEST 2014 root@sjakie.klop.ws:/usr/obj-arm/arm.arm/usr/src-arm/sys/SHEEVAPLUG arm While the amd64 runs 10-RC1. Regards, Ronald. From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 15:34:55 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0276BF8E for ; Tue, 7 Oct 2014 15:34:55 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id DA6F916A for ; Tue, 7 Oct 2014 15:34:54 +0000 (UTC) Received: from bender.lan (97e07ab1.skybroadband.com [151.224.122.177]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 458AA5C0B9; Tue, 7 Oct 2014 15:34:47 +0000 (UTC) Date: Tue, 7 Oct 2014 16:34:40 +0100 From: Andrew Turner To: "Ronald Klop" Subject: Re: Why are arm libs branded as SYSV? Message-ID: <20141007163440.02a402f8@bender.lan> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 15:34:55 -0000 On Tue, 07 Oct 2014 16:56:49 +0200 "Ronald Klop" wrote: > > On my ARM Sheevaplug: > # file /usr/local/lib/libpcre.so.3 > /usr/local/lib/libpcre.so.3: ELF 32-bit LSB shared object, ARM, > EABI5 version 1 (SYSV), dynamically linked, stripped > > On my amd64 computer: > file /usr/local/lib/libpcre.so.3 > /usr/local/lib/libpcre.so.3: ELF 64-bit LSB shared object, x86-64, > version 1 (FreeBSD), dynamically linked, stripped > > Because of this I can not run ldd on a shared library on my ARM > system. # ldd -a /usr/local/lib/libpcre.so.3 > ldd: /usr/local/lib/libpcre.so.3: not a FreeBSD ELF shared object > > > Is that on purpose? I am curious why that is. Because the EI_OSABI field, where this value comes from, is documented to be zero in the ARM AAELF spec. Andrew From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 15:45:07 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57A30339 for ; Tue, 7 Oct 2014 15:45:07 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2AC7428D for ; Tue, 7 Oct 2014 15:45:06 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XbWwj-000Jcf-7J; Tue, 07 Oct 2014 15:45:05 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s97Fj2vM030718; Tue, 7 Oct 2014 09:45:02 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX187SH6JIHjuVb2uTUqLKtaA X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Why are arm libs branded as SYSV? From: Ian Lepore To: Andrew Turner In-Reply-To: <20141007163440.02a402f8@bender.lan> References: <20141007163440.02a402f8@bender.lan> Content-Type: text/plain; charset="us-ascii" Date: Tue, 07 Oct 2014 09:45:01 -0600 Message-ID: <1412696701.12052.203.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 15:45:07 -0000 On Tue, 2014-10-07 at 16:34 +0100, Andrew Turner wrote: > On Tue, 07 Oct 2014 16:56:49 +0200 > "Ronald Klop" wrote: > > > > > On my ARM Sheevaplug: > > # file /usr/local/lib/libpcre.so.3 > > /usr/local/lib/libpcre.so.3: ELF 32-bit LSB shared object, ARM, > > EABI5 version 1 (SYSV), dynamically linked, stripped > > > > On my amd64 computer: > > file /usr/local/lib/libpcre.so.3 > > /usr/local/lib/libpcre.so.3: ELF 64-bit LSB shared object, x86-64, > > version 1 (FreeBSD), dynamically linked, stripped > > > > Because of this I can not run ldd on a shared library on my ARM > > system. # ldd -a /usr/local/lib/libpcre.so.3 > > ldd: /usr/local/lib/libpcre.so.3: not a FreeBSD ELF shared object > > > > > > Is that on purpose? I am curious why that is. > > Because the EI_OSABI field, where this value comes from, is documented > to be zero in the ARM AAELF spec. > > Andrew Does this imply we have to update our elf tools to recognize the freebsd-ness of arm eabi objects in some other way? -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 16:24:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2471F9AA for ; Tue, 7 Oct 2014 16:24:35 +0000 (UTC) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id EE1989BE for ; Tue, 7 Oct 2014 16:24:34 +0000 (UTC) Received: from localhost (w142149.ppp.asahi-net.or.jp [121.1.142.149]) by mailssl.asahi-net.or.jp (Postfix) with ESMTP id F17C2C77C5; Wed, 8 Oct 2014 01:24:26 +0900 (JST) Date: Wed, 08 Oct 2014 01:24:23 +0900 (JST) Message-Id: <20141008.012423.1241777167968112759.shigeru@os-hackers.jp> To: ronald-lists@klop.ws Subject: Re: Why are arm libs branded as SYSV? From: YAMAMOTO Shigeru In-Reply-To: References: X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 16:24:35 -0000 Hi, >>>>> "Ronald" == Ronald Klop writes: > On my ARM Sheevaplug: > # file /usr/local/lib/libpcre.so.3 > /usr/local/lib/libpcre.so.3: ELF 32-bit LSB shared object, ARM, > EABI5 version 1 (SYSV), dynamically linked, stripped > On my amd64 computer: file /usr/local/lib/libpcre.so.3 > /usr/local/lib/libpcre.so.3: ELF 64-bit LSB shared object, x86-64, > version 1 (FreeBSD), dynamically linked, stripped > Because of this I can not run ldd on a shared library on my ARM > system. > # ldd -a /usr/local/lib/libpcre.so.3 ldd: > /usr/local/lib/libpcre.so.3: not a FreeBSD ELF shared object I modify src for RaspberryPi. # uname -a FreeBSD rpi.devel.os-hackers.jp 11.0-CURRENT FreeBSD 11.0-CURRENT #0 2b4736f34c78 (shigeru_raspberry_pi) tip: Sun Oct 5 12:18:07 JST 2014 root@nemesis.os-hackers.jp:/root/rpi/build/work/obj/arm.armv6/root/rpi/build/work/src.hg/sys/RPI-B-VIMAGE arm # ldd /usr/local/lib/libpcre.so.3 /usr/local/lib/libpcre.so.3: libthr.so.3 => /lib/libthr.so.3 (0x20297000) libc.so.7 => /lib/libc.so.7 (0x20100000) I change src follows, - 1. copy contrib/binutils/bfd/elf32-arm.c to gnu/usr.bin/binutils/libbfd/elf32-arm.c - 2. change gnu/usr.bin/binutils/libbfd/elf32-arm.c by following diff, diff -u contrib/binutils/bfd/elf32-arm.c - gnu/usr.bin/binutils/libbfd/elf32-arm.c --- contrib/binutils/bfd/elf32-arm.c 2014-10-05 03:00:54.100351377 +0900 +++ gnu/usr.bin/binutils/libbfd/elf32-arm.c 2014-10-05 - 03:00:54.147901348 +0900 @@ -9343,7 +9343,8 @@ i_ehdrp = elf_elfheader (abfd); - if (EF_ARM_EABI_VERSION (i_ehdrp->e_flags) == EF_ARM_EABI_UNKNOWN) + if (EF_ARM_EABI_VERSION (i_ehdrp->e_flags) == EF_ARM_EABI_UNKNOWN + || EF_ARM_EABI_VERSION (i_ehdrp->e_flags) == EF_ARM_EABI_VER5) i_ehdrp->e_ident[EI_OSABI] = ARM_ELF_OS_ABI_VERSION; else i_ehdrp->e_ident[EI_OSABI] = 0; --- YAMAMOTO Shigeru From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 16:40:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F1BAF2E; Tue, 7 Oct 2014 16:40:40 +0000 (UTC) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE1AAB9E; Tue, 7 Oct 2014 16:40:39 +0000 (UTC) Received: by mail-yh0-f50.google.com with SMTP id a41so3157516yho.9 for ; Tue, 07 Oct 2014 09:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q1ZriWbefiRSuDcNKnoWUUaxNeOuaYwExu6ayxmyUjk=; b=Xig+IkonyI0L2fxWAz3mAP4Sjj32DEpgq2794d02KiwkmAdFr/jMUGE99FFETdsX+m wJ02mAobvtZXuhb/ofJHa3aqb7ih+9xOsIzYOdbCKeYMRuZ1qCLZRtsQR3KTDedrkblo yHLQ+5c6tXD0vdWFG2pf9saH7UU8DAznIYP8rJ0DCpjwo3z9iu0hgFnTaZku60UJTXJg UYRhVSb9DFYU53dsXsuCKyuNcABA/IXJLbuuYLZVbt/O9GRcFB4Mdu03MvIiuPEGOXDF kjQviTvZUmaFSSK3Jbth806Pz5y29ciCFj3EPmP0wVU6XYoSUETHHm5lzPjAf0wH43jn p6/w== MIME-Version: 1.0 X-Received: by 10.236.78.200 with SMTP id g48mr6779988yhe.17.1412700039094; Tue, 07 Oct 2014 09:40:39 -0700 (PDT) Received: by 10.170.186.141 with HTTP; Tue, 7 Oct 2014 09:40:38 -0700 (PDT) In-Reply-To: <1412687805.12052.199.camel@revolution.hippie.lan> References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> <1412613830.12052.121.camel@revolution.hippie.lan> <1412687805.12052.199.camel@revolution.hippie.lan> Date: Tue, 7 Oct 2014 09:40:38 -0700 Message-ID: Subject: Re: Digi CCWMX53 From: Russell Haley To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 16:40:40 -0000 Ian, Thanks for your candid response. I was waiting for this shoe to drop. I would not say I am discouraged, I would say that my expectations have been tempered. Let me evaluate what you have said and I will consider my options. Thanks, Russ On Tue, Oct 7, 2014 at 6:16 AM, Ian Lepore wrote: > On Mon, 2014-10-06 at 21:41 -0700, Russell Haley wrote: >> Hey, >> >> Okay, I lied about waiting till the weekend. I am looking at the atmel >> files. Should I be replacing the at91 moniker with imx (processor >> class) or mx53 (implementation)? >> >> Thanks, >> >> Russ > > With a quick glance at the manuals, it appears imx51 and imx53 have the > same nand controller hardware, but imx6 is completely different, so > 'imx5' would be the right prefix for file and function/data names. > > That said, I want to point out that there's a huge difference between > the simplistic memory controller for accessing nand in the at91 hardware > and the much more complex nand hardware in the imx5 series. I don't > think you're going to get far by trying to copy the at91 driver. In > fact, I think you're going to find it impossible to make the imx5 BCH > hardware work with the upper layers of the nand software in freebsd > without some serious redesign of the upper layers (and then of course > the associated rewriting of existing low-level nfc drivers). > > It's not that I want to discourage you from trying, I just want to be > realistic here. What you're embarking on isn't a couple days of > converting an existing driver -- in my estimation, you're looking at > weeks of work. I don't mean 3 calendar weeks of a couple hours each > evening hobbyist work, I'm talking hundreds of hours of development > time. The harsh reality is that freebsd doesn't have adequate nand > flash support for modern hardware. We don't even have the framework of > a design that can accomodate things like hardware offload of ECC. > > -- Ian > > From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 16:51:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB4A170C for ; Tue, 7 Oct 2014 16:51:40 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id BE43CD6A for ; Tue, 7 Oct 2014 16:51:40 +0000 (UTC) Received: from bender.lan (97e07ab1.skybroadband.com [151.224.122.177]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id BC1745C0B9; Tue, 7 Oct 2014 16:51:39 +0000 (UTC) Date: Tue, 7 Oct 2014 17:51:33 +0100 From: Andrew Turner To: Jaemin Yoo Subject: Re: Q: linking method for armv8 kernel build Message-ID: <20141007175133.6a26bcc5@bender.lan> In-Reply-To: <5433DD2E.1050807@gmail.com> References: <5432A1B5.30406@gmail.com> <20141006154314.1b909772@bender.lan> <5433DD2E.1050807@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 16:51:41 -0000 On Tue, 07 Oct 2014 21:31:42 +0900 Jaemin Yoo wrote: > 2014-10-06 PM 11:43, Andrew Turner wrote: > > On Mon, 06 Oct 2014 23:05:41 +0900 > > Jaemin Yoo wrote: > > > >> Hello, I just began to download and build kernel for armv8 > >> according to the following howto page. > >> (https://wiki.freebsd.org/arm64) > >> > >> I could create the kernel image without problem. But 'file' says > >> it's dynamically linked. I expected statically linked image to load > >> it on dram using uboot. > >> > >> Is it meant to be? or am I missing some configuration? > > > > All examples of the FreeBSD kernel I've looked at say they are > > dynamically linked. The requirement is the kernel needs to be > > loaded at a 2MiB aligned address for the VA->PA translation to > > work. It will create the page table so the kernel base points to > > the load address. > > > > You may have problems loading it with U-Boot. It expects to be > > loaded by the loader as it passes in the device tree. U-Boot has > > been found to be difficult to support on 32-bit arm. Is there a > > reason to prefer it over UEFI? > > > > Andrew > > > > Thanks. I'm doing most work at linux and vmlinux is mostly(?) > statically linked. So I thought same goes for freebsd too. There are > some 'UND' functions in kernel but I guess it's okay if they are not > used. The only undefined data I get in my arm64 kernel is for uart data. These are specifically set up like this to simplify the code. > I got a 64bit arm board which runs linux from APM. It came with binary > and source codes of u-boot. So I planned to enable bootelf and load > kernel on dram after adding uart driver for the board. I just want to > see freebsd kernel boot on arm64 with minimal changes. You will have issues as the kernel expects to read the dtb from the data provided by the loader. In the short term you could use a static DTB in the kernel however the code to do so has not been written as the kernel should work on all supported hardware. If you go down this route you don't need to use the bootelf command, instead you can either create a U-Boot image using mkimage, or have U-Boot jump to the entry point directly using the go command. Note that the go command may leave the d-cache on causing issues. In the long term the loader should be ported to work on U-Boot. Some of the existing work to have it run on 32-bit ARM can be reused. You will also need to change the early putc function in arm64/arm64/machdep.c. It appears from [1] and [2] the UART is mapped at 0x1c020000. This is within the range set up for the Foundation Model so you should only need up update the early_putc function. It's written for a pl011 with the assumption we will never overflow the fifo. You will need to change this as the APM SoC appears to have an ns16550. At this point you should start to get kernel messages on the serial port, this includes any panic messages if something got missed. Andrew [1] https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/apm-mustang.dts [2] https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/apm-storm.dtsi From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 17:16:17 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C94FB715; Tue, 7 Oct 2014 17:16:17 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id AB4C582; Tue, 7 Oct 2014 17:16:17 +0000 (UTC) Received: from bender.lan (97e07ab1.skybroadband.com [151.224.122.177]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 949275C0B9; Tue, 7 Oct 2014 17:16:16 +0000 (UTC) Date: Tue, 7 Oct 2014 18:16:10 +0100 From: Andrew Turner To: Ian Lepore Subject: Re: Why are arm libs branded as SYSV? Message-ID: <20141007181610.6193947f@bender.lan> In-Reply-To: <1412696701.12052.203.camel@revolution.hippie.lan> References: <20141007163440.02a402f8@bender.lan> <1412696701.12052.203.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 17:16:17 -0000 On Tue, 07 Oct 2014 09:45:01 -0600 Ian Lepore wrote: > On Tue, 2014-10-07 at 16:34 +0100, Andrew Turner wrote: > > On Tue, 07 Oct 2014 16:56:49 +0200 > > "Ronald Klop" wrote: > > > > > > > > On my ARM Sheevaplug: > > > # file /usr/local/lib/libpcre.so.3 > > > /usr/local/lib/libpcre.so.3: ELF 32-bit LSB shared object, ARM, > > > EABI5 version 1 (SYSV), dynamically linked, stripped > > > > > > On my amd64 computer: > > > file /usr/local/lib/libpcre.so.3 > > > /usr/local/lib/libpcre.so.3: ELF 64-bit LSB shared object, x86-64, > > > version 1 (FreeBSD), dynamically linked, stripped > > > > > > Because of this I can not run ldd on a shared library on my ARM > > > system. # ldd -a /usr/local/lib/libpcre.so.3 > > > ldd: /usr/local/lib/libpcre.so.3: not a FreeBSD ELF shared object > > > > > > > > > Is that on purpose? I am curious why that is. > > > > Because the EI_OSABI field, where this value comes from, is > > documented to be zero in the ARM AAELF spec. > > > > Andrew > > Does this imply we have to update our elf tools to recognize the > freebsd-ness of arm eabi objects in some other way? The only one we had issues with was gdb. It inspects the elf notes to find which target operating system to handle. This was added early last year, with a fix earlier this year for armeb. Andrew From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 17:21:28 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA54998A for ; Tue, 7 Oct 2014 17:21:28 +0000 (UTC) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7AB7316E for ; Tue, 7 Oct 2014 17:21:27 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id w10so5445267pde.0 for ; Tue, 07 Oct 2014 10:21:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=tDNfUsmzDINKcCqY8NVEasn0r5ydOedBzipfTP80GhA=; b=NESEUXiJ+DdipIGXvV2rV6FjmXBY9Q6O+wkimWWKjhyiCiLW1M4W9K/HMKQbX/7C2k O3OUyoyJSPCODGUrSej/K20a3+bGL0w7le6Q5XqTHv1VY7rqDeUBWDcij5H6bEnpCngf mbIwRQ+tcWIId8/P7b770dsi2qnYfHcKnKk1qCjl5wB7efK3F9DQc8rByGZJitelAAPT LnS8S3R6E5xWq7V/rtj6cVgdSZClV5XmJA69FNe7ATkigVIVSs7y1W3LVuPKe5GqE+x7 1uop7i+Atj+6Kndm7vUsHfR4ggf1vyDWyKdubVqWa40c1yF/4fQ2WcwN5MMH5YzYWJSd NUAQ== X-Gm-Message-State: ALoCoQlGz/zlOFTVZkVD3HcnH40cpYNm5aK37nGs85JVAQ0GL6iCxHvyBaZkq07TXpF7hjMD4nBD X-Received: by 10.68.248.9 with SMTP id yi9mr4979371pbc.118.1412702480728; Tue, 07 Oct 2014 10:21:20 -0700 (PDT) Received: from [10.64.26.130] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id g13sm16789225pat.45.2014.10.07.10.21.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 10:21:20 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_589FFBF7-787E-4889-984D-22A9F9065726"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Digi CCWMX53 From: Warner Losh In-Reply-To: Date: Tue, 7 Oct 2014 11:21:16 -0600 Message-Id: <2C5A1F77-C3DD-4146-9A08-93625B7B8291@bsdimp.com> References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> <1412613830.12052.121.camel@revolution.hippie.lan> To: Russell Haley X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm , Ian Lepore , Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 17:21:28 -0000 --Apple-Mail=_589FFBF7-787E-4889-984D-22A9F9065726 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 6, 2014, at 4:11 PM, Russell Haley wrote: > Okay, that's both great and too bad. I had wondered about the > performance of ECC in software. However, it turns out one of the > Senior Engineers did his masters on ECC so I had a line on an > implementation. It wouldn=92t hurt to have a good implementation, since most of the time = they can be parameterized, but it likely is going to be on the slow side... > Anyway, I won't get to anything for a couple of days but will look > into this further on the weekend. Wow. Did I really just get sucked > into writing a NFC driver? lolz :) Warner > On Mon, Oct 6, 2014 at 2:30 PM, Warner Losh wrote: >>=20 >> On Oct 6, 2014, at 1:35 PM, Russell Haley = wrote: >>=20 >>> I have been pinging some of the engineers here about ECC. I *might* = be >>> able to get someone to help me with a BCH implementation. The >>> recommendation was to start by checking the Linux or Android source >>> code that comes with the Jump starter Kit. I suspect however they = used >>> the build in hardware implementation but will verify that. Do you >>> want me to look at writing a BSD ECC or implement something that can >>> leverage a hardware implementation (which road should I take)? >>>=20 >>> I guess another factor would be if the iMX6 and next gen Freescale >>> stuff uses the same/similar controllers or if it's something = different >>> altogether? >>>=20 >>> Also, I was wondering how closely the CWMX53 board support has >>> followed the guidelines here: >>> https://wiki.freebsd.org/FreeBSDArmBoards? >>=20 >> I don=92t think our current 1-bit ECC is enough. The problem with = most of >> the SoCs implement strong ECC, but they are all different. They use >> different parameters for BCH to achieve the same ECC strength that >> different NAND vendors recommend. >>=20 >> You absolutely have to do this in hardware. Software ECC is too slow = by >> a factor of 10 or 100, especially as the codes get more complex (some >> recent parts require like 39 bits over 1k). 1-bit hamming code is bad = enough. >>=20 >> Ideally, we can accept a divergence of ECC in the details, and = instead allow >> for full and partial hardware offload for ECC generation and = correction. >>=20 >> Warner >>=20 >>=20 >>> On Mon, Oct 6, 2014 at 9:43 AM, Ian Lepore wrote: >>>> On Sun, 2014-10-05 at 21:58 -0700, Russell Haley wrote: >>>>> Alright, well night one of my crash course in C and it wasn't = quite as >>>>> painful as I thought. For shits and giggles I started looking in = the >>>>> /sys/dev/nand directory. Nand.h then led me to ../../sys/bus.h and >>>>> then back to some nfc classes where, EUREKA, I found nfc_91.h/c. I >>>>> have been reading up on the atmel board support package so I >>>>> recognized the at91 moniker. (pretty pleased with myself for that >>>>> one...) >>>>>=20 >>>>> So what I can tell is someone needs to write a mx53/mx6 nand flash >>>>> controller that works in roughly the same way as the at91 = "prototype". >>>>> It would implement various functions and then assign them using: >>>>>=20 >>>>> static device_method_t at91_nand_methods[] =3D { >>>>> DEVMETHOD(device_probe, at91_nand_probe), >>>>> DEVMETHOD(device_attach, at91_nand_attach), >>>>>=20 >>>>> DEVMETHOD(nfc_send_command, at91_nand_send_command), >>>>> DEVMETHOD(nfc_send_address, at91_nand_send_address), >>>>> DEVMETHOD(nfc_read_byte, at91_nand_read_byte), >>>>> DEVMETHOD(nfc_read_buf, at91_nand_read_buf), >>>>> DEVMETHOD(nfc_write_buf, at91_nand_write_buf), >>>>> DEVMETHOD(nfc_select_cs, at91_nand_select_cs), >>>>> DEVMETHOD(nfc_read_rnb, at91_nand_read_rnb), >>>>>=20 >>>>> DEVMETHOD_END >>>>> }; >>>>>=20 >>>>>=20 >>>>> Or some rough order of magnitude in that direction? That would be >>>>> where some of the "pre-canded jobs" mentioned in the spec would = come >>>>> in handy? >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Russ >>>>>=20 >>>>=20 >>>> If the flash parts in use on your board can use 1-bit Hamming code = for >>>> ECC, all you need to do is write a nearly-trivial nfc driver = similar to >>>> at91_nfc. If the flash chips are modern and require multi-bit BCH = code, >>>> we don't have a software implementation of that, and the current = NFC >>>> interface has no provisions for using the hardware accellerator on = the >>>> imx chip. >>>>=20 >>>> I can't find any definitive info on what chips that board uses, but = I >>>> will mention that 1-bit ECC was used on old chips with small = capacities >>>> long ago and probably isn't used on any modern boards. >>>>=20 >>>> -- Ian >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>> On Sat, Oct 4, 2014 at 4:15 PM, Russell Haley = wrote: >>>>>> Warner, >>>>>> That's great news! I had a scan and it seemed pretty thorough = (albiet >>>>>> from a novice point of view). The pre-canned jobs looked = promising. >>>>>>=20 >>>>>> As much as I'm hoping your intention is to fix this FOR me, could = you >>>>>> point me towards the code for the mtd support? >>>>>>=20 >>>>>> Many thanks to everyone for helping. I've had more progress in = the >>>>>> last two weeks than I have in the previous six months. lolz >>>>>>=20 >>>>>> Russ >>>>>>=20 >>>>>>=20 >>>>>> On Sat, Oct 4, 2014 at 11:05 AM, Warner Losh = wrote: >>>>>>> Hey Russ, >>>>>>>=20 >>>>>>> A quick read suggests all, or nearly all, of the data needed to = write a full NFC for this chip is present. The programming and read = sequences and information about ECC error rates appear to be readily = available. The exact ECC used, however, appears opaque. This may or may = not be a problem. It even appears to have command sequencing built into = the controller. This is a great feature, but one the current code = doesn=92t make use of. >>>>>>>=20 >>>>>>> Warner >>>>>>>=20 >>>>>>> On Oct 2, 2014, at 10:44 PM, Russell Haley = wrote: >>>>>>>=20 >>>>>>>> Warner, >>>>>>>>=20 >>>>>>>> I was looking for a Digi reference but it turns out the Nand = Flash Controller is part of the Freescale Processor. Here is the link to = the Reference Manual: >>>>>>>>=20 >>>>>>>> cache.freescale.com/files/32bit/doc/ref_manual/iMX53RM.pdf >>>>>>>>=20 >>>>>>>> The NAND Flash Controller is in Chapter 51 page 3571 to page = 3647. >>>>>>>>=20 >>>>>>>> Is this relevant to what you are looking at doing? = https://wiki.freebsd.org/NAND >>>>>>>>=20 >>>>>>>> I also found something called CHFS for NetBSD that looks = interesting: http://chewiefs.sed.hu/home >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>> Russ >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Thu, Oct 2, 2014 at 2:34 PM, Warner Losh = wrote: >>>>>>>>=20 >>>>>>>> On Oct 1, 2014, at 12:48 AM, Russell Haley = wrote: >>>>>>>>=20 >>>>>>>>> Warner, >>>>>>>>>=20 >>>>>>>>> First, I was just watching your 2010 talk on supporting = FreeBSD in a commercial environment. Has there been any updates in the = process of maintaining a commercial branch in the last 4 years (not that = I have any commercial ventures yet! lolz)? >>>>>>>>>=20 >>>>>>>>> Anyway, I talked to an Engineer about the NAND controller spec = and he chided me for being naive (poor little software developer, in way = over his head. tisk tisk). He mentioned a FIVE THOUSAND page reference = manual, which I have yet to find on the Digi site. >>>>>>>>=20 >>>>>>>> URL + section number. 5k pages doesn=92t necessarily mean it = will be useful, though. :( >>>>>>>>=20 >>>>>>>>> I have however found this hardware reference: >>>>>>>>>=20 >>>>>>>>> http://ftp1.digi.com/support/documentation/90001270_E.pdf >>>>>>>>>=20 >>>>>>>>> =46rom Page 41: >>>>>>>>>=20 >>>>>>>>> NAND flash memory >>>>>>>>> The ConnectCore for i.MX53 module provides 8GB of NAND flash = memory. On the module in >>>>>>>>> the development kits a 512MByte, 2Kbyte page, NAND flash chip = is used. This NAND flash >>>>>>>>> device is connected to NAND flash Chip Select 0. >>>>>>>>> The NAND flash controller signals are available on the module = connectors. >>>>>>>>=20 >>>>>>>> This basically says nothing more useful than =93There=92s NAND = on this board that=92s 4Gbits on CS0.=94 which is useful, but far from = sufficient. How do I program the DMA so that ECC is added to the OOB = areas of that NAND? How do I set different ECC tables? How do I do ECC = error correction and detection? If you can=92t answer that sort of = question from the docs you have, then they aren=92t helpful enough. >>>>>>>>=20 >>>>>>>>> There are pin references to NAND further down in the section = "GPIO multiplexing table in the ConnectCore for i.MX53 module" on page = 44 and 49. >>>>>>>>>=20 >>>>>>>>> I fear this is not the information we are looking for. >>>>>>>>=20 >>>>>>>> Not really. The GPIO info might be mildly helpful in a few = cases >>>>>>>>=20 >>>>>>>>> I have found another u-boot fork for the CCWMX53 on github = here: https://github.com/Varcain/uboot-ccwmx53-digi >>>>>>>>>=20 >>>>>>>>> With what seems to be the information about booting from NAND = here: https://github.com/Varcain/uboot-ccwmx53-digi/tree/master/nand_spl >>>>>>>>>=20 >>>>>>>>> If you can let me know what I am looking for I can both ask a = more directed question at work and also perform a better search. >>>>>>>>>=20 >>>>>>>>> I have also started looking over the Architecture handbook as = well because I have a feeling there is going to be lots of driver code = in my future. >>>>>>>>=20 >>>>>>>> A good first step would be to get a URL or search string to get = the URL for that big spec. It is of the right size to possibly be = useful, but sometimes really long specs have 1-2 page descriptions of = things like the SD controller or the NAND controller that you need = special NDAs + business arrangements to get, so it is hard to say=85 >>>>>>>>=20 >>>>>>>> Warner >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Sun, Sep 28, 2014 at 12:12 AM, Warner Losh = wrote: >>>>>>>>>=20 >>>>>>>>> On Sep 27, 2014, at 9:49 PM, Russell Haley = wrote: >>>>>>>>>=20 >>>>>>>>>> I will attempt to load the kernel from tftp as soon as I can. = I will need >>>>>>>>>> to figure out how to get ethernet to the unit. >>>>>>>>>>=20 >>>>>>>>>> I know nothing about u-boot so forgive my ignorance but I was = hoping to >>>>>>>>>> modify the Arndale configuration to work such as: >>>>>>>>>>=20 >>>>>>>>>> # mmc read 1 0x70800000 0x800 0x1800; >>>>>>>>>> #go 0x70800000; >>>>>>>>>>=20 >>>>>>>>>> and then point the rootfs to /dev/da1s1 >>>>>>>>>>=20 >>>>>>>>>> On another note, do you know where I could find out more = about the missing >>>>>>>>>> MTD support? >>>>>>>>>=20 >>>>>>>>> A spec for the NAND controller is needed to make that work=85 = Is one about? >>>>>>>>>=20 >>>>>>>>> Warner >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> BTW, I thought your wireless mesh stuff was pretty cool. Ah, = so many cool >>>>>>>>>> projects, so little time... >>>>>>>>>>=20 >>>>>>>>>> Thanks, >>>>>>>>>>=20 >>>>>>>>>> Russ >>>>>>>>>>=20 >>>>>>>>>> On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo = wrote: >>>>>>>>>>=20 >>>>>>>>>>> On Sep 27, 2014, at 13:31, Russell Haley = wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Rui, >>>>>>>>>>>>=20 >>>>>>>>>>>> So no MTD means the NAND on the SOM is out, but can I boot = the kernel >>>>>>>>>>> and load rootfs from the microSD, like in this example: >>>>>>>>>>>> =95 >>>>>>>>>>>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 = kernel.bin; go >>>>>>>>>>> 0x40f00000" >>>>>>>>>>>>=20 >>>>>>>>>>>> ARNDALE5250 # saveenv >>>>>>>>>>>>=20 >>>>>>>>>>>> ARNDALE5250 # boot >>>>>>>>>>>=20 >>>>>>>>>>> You can't use the Arndale config since the load addresses = are different. >>>>>>>>>>> You should be able to load a kernel from the network. Can = you do that? >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Rui Paulo >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> freebsd-arm@freebsd.org mailing list >>>>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>>>>>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>> _______________________________________________ >>>>> freebsd-arm@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >>>>>=20 >>>>=20 >>>>=20 >>=20 --Apple-Mail=_589FFBF7-787E-4889-984D-22A9F9065726 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUNCENAAoJEGwc0Sh9sBEA2kMP+wRql87x2zpw+rgq3pmJZSli BclQQs2UpM1K/4NWotggDC70Hl1ZBe4DNfJWxYAuYUj7qH72qqLz7Obql1d/N741 V7zCQUFUjDQYHUAYqJHOkQYbWJG9GH2zI+ImLVqVfQZGPY1zuTjCOZ1ZLDt5vKUJ TU/15b01wwk0pib6xTuYcYHDptd6bxWj9AmiDtkX3EununxraFwSiB0E4uCEdWtW sS42PGi2LHVR5X4AXCwuEsnIHHSg3k6qEn2vXCvznRAs4GGfCFkOI7n2XHlTHSQr LariOExZLnefusS6KDKpG9xjNTENp3Q+f6TojFcVGOjCLmm0Jh1W55dPAazSBHCK twsgVgtHflYJ12dGx3wfa1lFz9OJj7z4aumWn4DzRaQcvI5KI5KoeKVbCYoFQ6d1 kt61dAmTtUpGPAL/tRXk/eVC6gHPR9OTWkd04eGkTN2YJIgtNvXLzSenF9WJYoxc ABCt+l4d62QOhy7Q7i7oHaP6qa3Vo9rWuKAPSyFCNLLDakFLGr5J19IrDolW6a0P TpCPNyxCPTA/NyvwGF6w2yLr9+YxxzJzuijOaMrsg8UoR7Ss2SljSXPhxGZFFor/ Gg5pzgSu+Mjr0r9McR6Wj3VTksDZcMxcICrfwTgAa+bpuv6WhL2nzmuDZeEbxfpi G1uGn9f1JNu8nnOR7bjj =LKtN -----END PGP SIGNATURE----- --Apple-Mail=_589FFBF7-787E-4889-984D-22A9F9065726-- From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 17:30:00 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93551BA0 for ; Tue, 7 Oct 2014 17:30:00 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6513B1ED for ; Tue, 7 Oct 2014 17:30:00 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XbYa9-000Kbl-DD; Tue, 07 Oct 2014 17:29:53 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s97HTpRr030911; Tue, 7 Oct 2014 11:29:51 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19N2tqIMS7FPa/VBFnqWvzQ X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Why are arm libs branded as SYSV? From: Ian Lepore To: Andrew Turner In-Reply-To: <20141007181610.6193947f@bender.lan> References: <20141007163440.02a402f8@bender.lan> <1412696701.12052.203.camel@revolution.hippie.lan> <20141007181610.6193947f@bender.lan> Content-Type: text/plain; charset="us-ascii" Date: Tue, 07 Oct 2014 11:29:50 -0600 Message-ID: <1412702990.12052.224.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 17:30:00 -0000 On Tue, 2014-10-07 at 18:16 +0100, Andrew Turner wrote: > On Tue, 07 Oct 2014 09:45:01 -0600 > Ian Lepore wrote: > > > On Tue, 2014-10-07 at 16:34 +0100, Andrew Turner wrote: > > > On Tue, 07 Oct 2014 16:56:49 +0200 > > > "Ronald Klop" wrote: > > > > > > > > > > > On my ARM Sheevaplug: > > > > # file /usr/local/lib/libpcre.so.3 > > > > /usr/local/lib/libpcre.so.3: ELF 32-bit LSB shared object, ARM, > > > > EABI5 version 1 (SYSV), dynamically linked, stripped > > > > > > > > On my amd64 computer: > > > > file /usr/local/lib/libpcre.so.3 > > > > /usr/local/lib/libpcre.so.3: ELF 64-bit LSB shared object, x86-64, > > > > version 1 (FreeBSD), dynamically linked, stripped > > > > > > > > Because of this I can not run ldd on a shared library on my ARM > > > > system. # ldd -a /usr/local/lib/libpcre.so.3 > > > > ldd: /usr/local/lib/libpcre.so.3: not a FreeBSD ELF shared object > > > > > > > > > > > > Is that on purpose? I am curious why that is. > > > > > > Because the EI_OSABI field, where this value comes from, is > > > documented to be zero in the ARM AAELF spec. > > > > > > Andrew > > > > Does this imply we have to update our elf tools to recognize the > > freebsd-ness of arm eabi objects in some other way? > > The only one we had issues with was gdb. It inspects the elf notes to > find which target operating system to handle. This was added early last > year, with a fix earlier this year for armeb. > Well there's also the trouble quoted at the top of this email. :) -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 17:30:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52014BE5 for ; Tue, 7 Oct 2014 17:30:50 +0000 (UTC) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 11E591F5 for ; Tue, 7 Oct 2014 17:30:49 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id eu11so7538218pac.21 for ; Tue, 07 Oct 2014 10:30:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=SmmOhPijMR4Q6sSnlO09VBn2OIat4S+PY0raCbLwm8I=; b=QlqZHTliIUAvv2iGNlSQhb3uCy3+a+EvJW+pJAbw0miNF2Y+1rso15DCIQwlMuAP7A tDWVXgaXAuw7Eh0jEFtsJGcFKSEiSA3p9HoQQ5snVX+DNDC1cfajyHkIxY/6sAGuWSef iB2vfisaHQly1cEfrpZhhLixBo/57mepBARb1YV9wJkbyQXtvPcUHJbRmHu4dwP0gbY5 rcbmDkjY0Eb7aAAh9/MctuMpx2pkQJZ56M0TYx+ZzRg4nJSpyA4AxLuv56RKrBAyIABR mCv7iIvE1bVUCLHe/afUk5BzrLULVBl4DEiNUSFDWFtKc6Igq9q8fMxzBD/9sW9tUn7O 00yw== X-Gm-Message-State: ALoCoQl5PCi+9Q2l+K60s1s5FeycV9eVZXFNh1oplEG11X4/sR4RoCIfIP1XkW6f+ctP4iVCkRTS X-Received: by 10.70.55.232 with SMTP id v8mr5337059pdp.93.1412702701279; Tue, 07 Oct 2014 10:25:01 -0700 (PDT) Received: from [10.64.26.130] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id fn4sm16802129pab.39.2014.10.07.10.24.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 10:25:00 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_D459FBB6-794D-4E3A-AC0C-AACCC2419D98"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Digi CCWMX53 From: Warner Losh In-Reply-To: Date: Tue, 7 Oct 2014 11:24:57 -0600 Message-Id: <0D4A5ED2-B033-40ED-AA64-312E95B02F11@bsdimp.com> References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> <1412613830.12052.121.camel@revolution.hippie.lan> To: Russell Haley X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 17:30:50 -0000 --Apple-Mail=_D459FBB6-794D-4E3A-AC0C-AACCC2419D98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 6, 2014, at 10:41 PM, Russell Haley wrote: > Hey, >=20 > Okay, I lied about waiting till the weekend. I am looking at the atmel > files. Should I be replacing the at91 moniker with imx (processor > class) or mx53 (implementation)? Well, there=92s a third possibility. Is this used across all freescale = products? if so, then you=92d want to use that moniker. Arguably the Atmel one = should be named atmel, not at91. Changing everything though is just churn for = no benefit. Use the most general moniker you can and still be accurate. If = the imx6 is the same as the imx53, then go with imx. If it is the same chip = they use in the MIPS SoCs or the PowerPC SoCs, then go with the most common freecsale abbreviation. Warner > Thanks, >=20 > Russ >=20 > On Mon, Oct 6, 2014 at 3:11 PM, Russell Haley = wrote: >> Okay, that's both great and too bad. I had wondered about the >> performance of ECC in software. However, it turns out one of the >> Senior Engineers did his masters on ECC so I had a line on an >> implementation. >>=20 >> Anyway, I won't get to anything for a couple of days but will look >> into this further on the weekend. Wow. Did I really just get sucked >> into writing a NFC driver? lolz >>=20 >> On Mon, Oct 6, 2014 at 2:30 PM, Warner Losh wrote: >>>=20 >>> On Oct 6, 2014, at 1:35 PM, Russell Haley = wrote: >>>=20 >>>> I have been pinging some of the engineers here about ECC. I *might* = be >>>> able to get someone to help me with a BCH implementation. The >>>> recommendation was to start by checking the Linux or Android source >>>> code that comes with the Jump starter Kit. I suspect however they = used >>>> the build in hardware implementation but will verify that. Do you >>>> want me to look at writing a BSD ECC or implement something that = can >>>> leverage a hardware implementation (which road should I take)? >>>>=20 >>>> I guess another factor would be if the iMX6 and next gen Freescale >>>> stuff uses the same/similar controllers or if it's something = different >>>> altogether? >>>>=20 >>>> Also, I was wondering how closely the CWMX53 board support has >>>> followed the guidelines here: >>>> https://wiki.freebsd.org/FreeBSDArmBoards? >>>=20 >>> I don=92t think our current 1-bit ECC is enough. The problem with = most of >>> the SoCs implement strong ECC, but they are all different. They use >>> different parameters for BCH to achieve the same ECC strength that >>> different NAND vendors recommend. >>>=20 >>> You absolutely have to do this in hardware. Software ECC is too slow = by >>> a factor of 10 or 100, especially as the codes get more complex = (some >>> recent parts require like 39 bits over 1k). 1-bit hamming code is = bad enough. >>>=20 >>> Ideally, we can accept a divergence of ECC in the details, and = instead allow >>> for full and partial hardware offload for ECC generation and = correction. >>>=20 >>> Warner >>>=20 >>>=20 >>>> On Mon, Oct 6, 2014 at 9:43 AM, Ian Lepore wrote: >>>>> On Sun, 2014-10-05 at 21:58 -0700, Russell Haley wrote: >>>>>> Alright, well night one of my crash course in C and it wasn't = quite as >>>>>> painful as I thought. For shits and giggles I started looking in = the >>>>>> /sys/dev/nand directory. Nand.h then led me to ../../sys/bus.h = and >>>>>> then back to some nfc classes where, EUREKA, I found nfc_91.h/c. = I >>>>>> have been reading up on the atmel board support package so I >>>>>> recognized the at91 moniker. (pretty pleased with myself for = that >>>>>> one...) >>>>>>=20 >>>>>> So what I can tell is someone needs to write a mx53/mx6 nand = flash >>>>>> controller that works in roughly the same way as the at91 = "prototype". >>>>>> It would implement various functions and then assign them using: >>>>>>=20 >>>>>> static device_method_t at91_nand_methods[] =3D { >>>>>> DEVMETHOD(device_probe, at91_nand_probe), >>>>>> DEVMETHOD(device_attach, at91_nand_attach), >>>>>>=20 >>>>>> DEVMETHOD(nfc_send_command, at91_nand_send_command), >>>>>> DEVMETHOD(nfc_send_address, at91_nand_send_address), >>>>>> DEVMETHOD(nfc_read_byte, at91_nand_read_byte), >>>>>> DEVMETHOD(nfc_read_buf, at91_nand_read_buf), >>>>>> DEVMETHOD(nfc_write_buf, at91_nand_write_buf), >>>>>> DEVMETHOD(nfc_select_cs, at91_nand_select_cs), >>>>>> DEVMETHOD(nfc_read_rnb, at91_nand_read_rnb), >>>>>>=20 >>>>>> DEVMETHOD_END >>>>>> }; >>>>>>=20 >>>>>>=20 >>>>>> Or some rough order of magnitude in that direction? That would be >>>>>> where some of the "pre-canded jobs" mentioned in the spec would = come >>>>>> in handy? >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Russ >>>>>>=20 >>>>>=20 >>>>> If the flash parts in use on your board can use 1-bit Hamming code = for >>>>> ECC, all you need to do is write a nearly-trivial nfc driver = similar to >>>>> at91_nfc. If the flash chips are modern and require multi-bit BCH = code, >>>>> we don't have a software implementation of that, and the current = NFC >>>>> interface has no provisions for using the hardware accellerator on = the >>>>> imx chip. >>>>>=20 >>>>> I can't find any definitive info on what chips that board uses, = but I >>>>> will mention that 1-bit ECC was used on old chips with small = capacities >>>>> long ago and probably isn't used on any modern boards. >>>>>=20 >>>>> -- Ian >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Sat, Oct 4, 2014 at 4:15 PM, Russell Haley = wrote: >>>>>>> Warner, >>>>>>> That's great news! I had a scan and it seemed pretty thorough = (albiet >>>>>>> from a novice point of view). The pre-canned jobs looked = promising. >>>>>>>=20 >>>>>>> As much as I'm hoping your intention is to fix this FOR me, = could you >>>>>>> point me towards the code for the mtd support? >>>>>>>=20 >>>>>>> Many thanks to everyone for helping. I've had more progress in = the >>>>>>> last two weeks than I have in the previous six months. lolz >>>>>>>=20 >>>>>>> Russ >>>>>>>=20 >>>>>>>=20 >>>>>>> On Sat, Oct 4, 2014 at 11:05 AM, Warner Losh = wrote: >>>>>>>> Hey Russ, >>>>>>>>=20 >>>>>>>> A quick read suggests all, or nearly all, of the data needed to = write a full NFC for this chip is present. The programming and read = sequences and information about ECC error rates appear to be readily = available. The exact ECC used, however, appears opaque. This may or may = not be a problem. It even appears to have command sequencing built into = the controller. This is a great feature, but one the current code = doesn=92t make use of. >>>>>>>>=20 >>>>>>>> Warner >>>>>>>>=20 >>>>>>>> On Oct 2, 2014, at 10:44 PM, Russell Haley = wrote: >>>>>>>>=20 >>>>>>>>> Warner, >>>>>>>>>=20 >>>>>>>>> I was looking for a Digi reference but it turns out the Nand = Flash Controller is part of the Freescale Processor. Here is the link to = the Reference Manual: >>>>>>>>>=20 >>>>>>>>> cache.freescale.com/files/32bit/doc/ref_manual/iMX53RM.pdf >>>>>>>>>=20 >>>>>>>>> The NAND Flash Controller is in Chapter 51 page 3571 to page = 3647. >>>>>>>>>=20 >>>>>>>>> Is this relevant to what you are looking at doing? = https://wiki.freebsd.org/NAND >>>>>>>>>=20 >>>>>>>>> I also found something called CHFS for NetBSD that looks = interesting: http://chewiefs.sed.hu/home >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Russ >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Thu, Oct 2, 2014 at 2:34 PM, Warner Losh = wrote: >>>>>>>>>=20 >>>>>>>>> On Oct 1, 2014, at 12:48 AM, Russell Haley = wrote: >>>>>>>>>=20 >>>>>>>>>> Warner, >>>>>>>>>>=20 >>>>>>>>>> First, I was just watching your 2010 talk on supporting = FreeBSD in a commercial environment. Has there been any updates in the = process of maintaining a commercial branch in the last 4 years (not that = I have any commercial ventures yet! lolz)? >>>>>>>>>>=20 >>>>>>>>>> Anyway, I talked to an Engineer about the NAND controller = spec and he chided me for being naive (poor little software developer, = in way over his head. tisk tisk). He mentioned a FIVE THOUSAND page = reference manual, which I have yet to find on the Digi site. >>>>>>>>>=20 >>>>>>>>> URL + section number. 5k pages doesn=92t necessarily mean it = will be useful, though. :( >>>>>>>>>=20 >>>>>>>>>> I have however found this hardware reference: >>>>>>>>>>=20 >>>>>>>>>> http://ftp1.digi.com/support/documentation/90001270_E.pdf >>>>>>>>>>=20 >>>>>>>>>> =46rom Page 41: >>>>>>>>>>=20 >>>>>>>>>> NAND flash memory >>>>>>>>>> The ConnectCore for i.MX53 module provides 8GB of NAND flash = memory. On the module in >>>>>>>>>> the development kits a 512MByte, 2Kbyte page, NAND flash chip = is used. This NAND flash >>>>>>>>>> device is connected to NAND flash Chip Select 0. >>>>>>>>>> The NAND flash controller signals are available on the module = connectors. >>>>>>>>>=20 >>>>>>>>> This basically says nothing more useful than =93There=92s NAND = on this board that=92s 4Gbits on CS0.=94 which is useful, but far from = sufficient. How do I program the DMA so that ECC is added to the OOB = areas of that NAND? How do I set different ECC tables? How do I do ECC = error correction and detection? If you can=92t answer that sort of = question from the docs you have, then they aren=92t helpful enough. >>>>>>>>>=20 >>>>>>>>>> There are pin references to NAND further down in the section = "GPIO multiplexing table in the ConnectCore for i.MX53 module" on page = 44 and 49. >>>>>>>>>>=20 >>>>>>>>>> I fear this is not the information we are looking for. >>>>>>>>>=20 >>>>>>>>> Not really. The GPIO info might be mildly helpful in a few = cases >>>>>>>>>=20 >>>>>>>>>> I have found another u-boot fork for the CCWMX53 on github = here: https://github.com/Varcain/uboot-ccwmx53-digi >>>>>>>>>>=20 >>>>>>>>>> With what seems to be the information about booting from NAND = here: https://github.com/Varcain/uboot-ccwmx53-digi/tree/master/nand_spl >>>>>>>>>>=20 >>>>>>>>>> If you can let me know what I am looking for I can both ask a = more directed question at work and also perform a better search. >>>>>>>>>>=20 >>>>>>>>>> I have also started looking over the Architecture handbook as = well because I have a feeling there is going to be lots of driver code = in my future. >>>>>>>>>=20 >>>>>>>>> A good first step would be to get a URL or search string to = get the URL for that big spec. It is of the right size to possibly be = useful, but sometimes really long specs have 1-2 page descriptions of = things like the SD controller or the NAND controller that you need = special NDAs + business arrangements to get, so it is hard to say=85 >>>>>>>>>=20 >>>>>>>>> Warner >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Sun, Sep 28, 2014 at 12:12 AM, Warner Losh = wrote: >>>>>>>>>>=20 >>>>>>>>>> On Sep 27, 2014, at 9:49 PM, Russell Haley = wrote: >>>>>>>>>>=20 >>>>>>>>>>> I will attempt to load the kernel from tftp as soon as I = can. I will need >>>>>>>>>>> to figure out how to get ethernet to the unit. >>>>>>>>>>>=20 >>>>>>>>>>> I know nothing about u-boot so forgive my ignorance but I = was hoping to >>>>>>>>>>> modify the Arndale configuration to work such as: >>>>>>>>>>>=20 >>>>>>>>>>> # mmc read 1 0x70800000 0x800 0x1800; >>>>>>>>>>> #go 0x70800000; >>>>>>>>>>>=20 >>>>>>>>>>> and then point the rootfs to /dev/da1s1 >>>>>>>>>>>=20 >>>>>>>>>>> On another note, do you know where I could find out more = about the missing >>>>>>>>>>> MTD support? >>>>>>>>>>=20 >>>>>>>>>> A spec for the NAND controller is needed to make that work=85 = Is one about? >>>>>>>>>>=20 >>>>>>>>>> Warner >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> BTW, I thought your wireless mesh stuff was pretty cool. Ah, = so many cool >>>>>>>>>>> projects, so little time... >>>>>>>>>>>=20 >>>>>>>>>>> Thanks, >>>>>>>>>>>=20 >>>>>>>>>>> Russ >>>>>>>>>>>=20 >>>>>>>>>>> On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo = wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 27, 2014, at 13:31, Russell Haley = wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Rui, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> So no MTD means the NAND on the SOM is out, but can I boot = the kernel >>>>>>>>>>>> and load rootfs from the microSD, like in this example: >>>>>>>>>>>>> =95 >>>>>>>>>>>>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 = kernel.bin; go >>>>>>>>>>>> 0x40f00000" >>>>>>>>>>>>>=20 >>>>>>>>>>>>> ARNDALE5250 # saveenv >>>>>>>>>>>>>=20 >>>>>>>>>>>>> ARNDALE5250 # boot >>>>>>>>>>>>=20 >>>>>>>>>>>> You can't use the Arndale config since the load addresses = are different. >>>>>>>>>>>> You should be able to load a kernel from the network. Can = you do that? >>>>>>>>>>>>=20 >>>>>>>>>>>> -- >>>>>>>>>>>> Rui Paulo >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> freebsd-arm@freebsd.org mailing list >>>>>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>>>>>>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>> _______________________________________________ >>>>>> freebsd-arm@freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >>>>>>=20 >>>>>=20 >>>>>=20 >>>=20 --Apple-Mail=_D459FBB6-794D-4E3A-AC0C-AACCC2419D98 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUNCHpAAoJEGwc0Sh9sBEAyhwP/AjFLAi0DvVrhwtRN58scAJO jl790cClEmtwSn3ojzvxf3dChLEZuBY9SGhyVDpGA+HZnCrEXkzkc1/VSFgQglvM xJlApcx1B9hju640i9SdHATZ1/YmUDPRRdYIUGXxYWj3DJazf9ZrTCOBKKDm/Ph7 BMhHShr3caM5OwXSVvnSaCDSsgQ5Ha1a+ecAfu6iqUJWhLnDM/BbOqrgAq9novNG hlNkroA/WHHXqLuUHnn82abIrrhFT61RIPOWjSucaJmbCORIIu7CBKHoq2U3Y37+ xeZ0VeWs/ErsYmwi2eIZBe139vU5j0Lz26HSG6im6C09Oa7n9nJi1FNP6Qsv+97i ZlMqqD6n85i6HgAdUNLqXZb32JImYQLpJPX+Dvcw27NbaA8W+fMhYjBNYJBNfqwR lys1CcxKh/SCsMs99QLMenq7Xew/N+iax+g07tL0kb2xA63h3bterP8QUggdjuMA 7NGA/g6EfWHs+HrtCyzyvmCSuuRpfgAQi/V67NoYn+KpItyRQZHEWqtWiI7c4/9X skE767dHNnL+0WVb4MuBnl0Ul3THv6Q/EHJgpqQ1jtpuQin2YyiWT3HOAQOEnibM UIiWcUhLVyMGLfRJUMnyx+SJmiQeMPfCUxuwh0gw2chmeMt7V81PJmh6laVJiZgT IM6wfExClI/dxNcuB6DI =TOQl -----END PGP SIGNATURE----- --Apple-Mail=_D459FBB6-794D-4E3A-AC0C-AACCC2419D98-- From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 20:09:10 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E07FF25D for ; Tue, 7 Oct 2014 20:09:10 +0000 (UTC) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B004C8FF for ; Tue, 7 Oct 2014 20:09:10 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id h18so4920897igc.6 for ; Tue, 07 Oct 2014 13:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=RiwI5CDseZ4grjZV+h4Axhj/9LFoTTcCJJDVOlmv0yc=; b=nfhkLDCtQppYm/cyJPhTpFXLI0TdZDiV+xttrg3NiHlnby9lV5fecEBrEy8v7khvJs 8/tcfkllrZGThJoQLtCoCSD0LmypLtUH8QyxbkxYOtFLm2RmCN+sqvamsRL+7JM9zXE2 7JivBVRKkbJTDLFYD08QPjXB6f+TUga6von04sGXczxHkD8dxI0k9QhXJ6qLhzXUyRYS qFfMSrfT4gVjMz8zFYiySMMdRHia6LjgPFjUp4czQHXs9oDtwu2gEPBtK2oaUXhU8Zf5 dA2Ky0doWMsgySjEdnNg38kXB2/ekZvLTKHQvXFJrvikwPEIwsRu0cqnpQz9zvt/iSmn k/5w== X-Received: by 10.43.68.206 with SMTP id xz14mr4579588icb.33.1412712550180; Tue, 07 Oct 2014 13:09:10 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.29.132 with HTTP; Tue, 7 Oct 2014 13:08:50 -0700 (PDT) In-Reply-To: <20141007163440.02a402f8@bender.lan> References: <20141007163440.02a402f8@bender.lan> From: Ed Maste Date: Tue, 7 Oct 2014 16:08:50 -0400 X-Google-Sender-Auth: Z8RKM-JMIUqN-H0_y9oVcupDO0Q Message-ID: Subject: Re: Why are arm libs branded as SYSV? To: Andrew Turner Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 20:09:11 -0000 On 7 October 2014 11:34, Andrew Turner wrote: >> On my ARM Sheevaplug: >> # file /usr/local/lib/libpcre.so.3 >> /usr/local/lib/libpcre.so.3: ELF 32-bit LSB shared object, ARM, >> EABI5 version 1 (SYSV), dynamically linked, stripped >> ... > > Because the EI_OSABI field, where this value comes from, is documented > to be zero in the ARM AAELF spec. It's somewhat confusing for file to report SYSV, since both ELFOSABI_SYSV and ELFOSABI_NONE are 0. It could perhaps output "SYSV/NONE", although I'm not sure that would be less confusing. I looked for references to EI_OSABI in the source tree. Aside from ldd the only tool I found that might need a change is gcore, which sets the field to ELFOSABI_FREEBSD in generated core files. I'm not sure that this will actually cause trouble in practice though. From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 20:45:34 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2DDDD7A for ; Tue, 7 Oct 2014 20:45:34 +0000 (UTC) Received: from smtprelay-b22.telenor.se (smtprelay-b22.telenor.se [195.54.99.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 82338D09 for ; Tue, 7 Oct 2014 20:45:32 +0000 (UTC) Received: from ipb5.telenor.se (ipb5.telenor.se [195.54.127.168]) by smtprelay-b22.telenor.se (Postfix) with ESMTP id 6EF7916807 for ; Tue, 7 Oct 2014 22:19:06 +0200 (CEST) X-SENDER-IP: [85.229.94.62] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoGAM1JNFRV5V4+/2dsb2JhbABJFoMOU1gExDaILhkMh0uBEhcBAXqEBwMBAhcBDC4BaTwHBQweGQmIIQMVAQidcp0eDYcsjhKBRQMSCiwdhFcFix6EPoIaXYEvgU1lhAoyQYM+ESuDCIMshCwaglOEeIFag2U7LwEBgQSBRAEBAQ X-IPAS-Result: AnoGAM1JNFRV5V4+/2dsb2JhbABJFoMOU1gExDaILhkMh0uBEhcBAXqEBwMBAhcBDC4BaTwHBQweGQmIIQMVAQidcp0eDYcsjhKBRQMSCiwdhFcFix6EPoIaXYEvgU1lhAoyQYM+ESuDCIMshCwaglOEeIFag2U7LwEBgQSBRAEBAQ X-IronPort-AV: E=Sophos;i="5.04,672,1406584800"; d="scan'208";a="788520837" Received: from c-3e5ee555.06-11-73746f31.cust.bredbandsbolaget.se (HELO sigyn.alvermark.net) ([85.229.94.62]) by ipb5.telenor.se with ESMTP; 07 Oct 2014 22:19:04 +0200 Received: from localhost ([127.0.0.1] helo=webmail.alvermark.net) by sigyn.alvermark.net with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1XbbDg-000BMa-Bm for freebsd-arm@freebsd.org; Tue, 07 Oct 2014 22:18:52 +0200 Received: from 85.229.95.175 (SquirrelMail authenticated user alvis) by webmail.alvermark.net with HTTP; Tue, 7 Oct 2014 22:18:52 +0200 (CEST) Message-ID: <18234.85.229.95.175.1412713132.squirrel@webmail.alvermark.net> Date: Tue, 7 Oct 2014 22:18:52 +0200 (CEST) Subject: Allwinner A13 support (patches attached) From: "Jakob Alvermark" To: freebsd-arm@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20141007221852_56350" References: In-Reply-To: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 20:45:34 -0000 ------=_20141007221852_56350 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hello people! I have been sitting on this for too long now. (Thanks Arun Thomas for encouraging me to send this!) I have this Allwinner A13 board from Olimex, https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino/open-source-hardware I have made it boot FreeBSD-current, and here are the patches. Hoping anyone (committers?) might be interrested in looking at this. It boots from the SD card, using this U-boot: https://github.com/linux-sunxi/u-boot-sunxi Adding CONFIG_CMD_ELF and CONFIG_API to allow ubldr to work. It can boot to multi user, with root on a USB stick. Wanting to get rid of the USB stick I added Alexander Fedorov's MMC-driver, http://lists.freebsd.org/pipermail/freebsd-arm/2013-June/005913.html but it fails: a10_mmc0: mem 0x1c0f000-0x1c0ffff irq 32 on simplebus0 MMC0 MODE_CLK: 0x04dd1e00 mmc0: on a10_mmc0 vm_fault(0xc066ff50, 3197000, 1, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xc07cecd8 FSR=00000005, FAR=03197500, spsr=800001d3 r0 =c26bd400, r1 =03197500, r2 =00000400, r3 =c26bd409 r4 =00000000, r5 =00000008, r6 =c2674680, r7 =c2674b80 r8 =00000400, r9 =c26e2020, r10=c26bd800, r11=c07ced30 r12=c26bd408, ssp=c07ced28, slr=c0261810, pc =c0419ae0 [ thread pid 0 tid 100000 ] Stopped at strlcat+0x54: ldrb r4, [r1] I am not an experienced kernel hacker, so I don't know how to debug this. I also wanted to blink the onboard LED, so this is in the dts file: --- leds { compatible = "gpio-leds"; led1 { label = "led1"; gpios = <&gpio 201 1>; }; }; --- I do not get a /dev/led/led1 as I expected, manually toggling the LED with 'gpioctl -t 201' works fine... Thanks, Jakob ------=_20141007221852_56350 Content-Type: text/x-patch; name="a13.patch" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="a13.patch" Index: sys/arm/allwinner/a10_clk.c =================================================================== --- sys/arm/allwinner/a10_clk.c (revision 272713) +++ sys/arm/allwinner/a10_clk.c (working copy) @@ -148,6 +148,39 @@ } int +a10_clk_mmc_activate(void) +{ + struct a10_ccm_softc *sc = a10_ccm_sc; + uint32_t reg_value; + unsigned int pll5_clk; + unsigned int divider; + unsigned int n, k, p; + + if (sc == NULL) + return ENXIO; + + /* Gating AHB clock for SDMMC0 */ + reg_value = ccm_read_4(sc, CCM_AHB_GATING0); + reg_value |= CCM_AHB_GATING_SDMMC0; + ccm_write_4(sc, CCM_AHB_GATING0, reg_value); + + /* config mod clock */ + reg_value = ccm_read_4(sc, CCM_PLL5_CFG); + n = (reg_value >> 8) & 0x1f; + k = ((reg_value >> 4) & 3) + 1; + p = 1 << ((reg_value >> 16) & 3); + pll5_clk = 24000000 * n * k / p; + if (pll5_clk > 400000000) + divider = 4; + else + divider = 3; + ccm_write_4(sc, CCM_MMC0_SCLK_CFG, (1U << 31) | (2U << 24) | divider); + printf("MMC0 MODE_CLK: 0x%08x\n", pll5_clk / (divider + 1)); + + return 0; +} + +int a10_clk_usb_deactivate(void) { struct a10_ccm_softc *sc = a10_ccm_sc; Index: sys/arm/allwinner/a10_clk.h =================================================================== --- sys/arm/allwinner/a10_clk.h (revision 272713) +++ sys/arm/allwinner/a10_clk.h (working copy) @@ -103,6 +103,7 @@ #define CCM_AHB_GATING_USB0 (1 << 0) #define CCM_AHB_GATING_EHCI0 (1 << 1) #define CCM_AHB_GATING_EHCI1 (1 << 3) +#define CCM_AHB_GATING_SDMMC0 (1 << 8) #define CCM_AHB_GATING_EMAC (1 << 17) #define CCM_USB_PHY (1 << 8) @@ -112,6 +113,7 @@ int a10_clk_usb_activate(void); int a10_clk_usb_deactivate(void); +int a10_clk_mmc_activate(void); int a10_clk_emac_activate(void); #endif /* _A10_CLK_H_ */ Index: sys/arm/allwinner/a10_ehci.c =================================================================== --- sys/arm/allwinner/a10_ehci.c (revision 272713) +++ sys/arm/allwinner/a10_ehci.c (working copy) @@ -75,8 +75,8 @@ #define SW_AHB_INCRX_ALIGN (1 << 8) #define SW_AHB_INCR4 (1 << 9) #define SW_AHB_INCR8 (1 << 10) -#define GPIO_USB1_PWR 230 -#define GPIO_USB2_PWR 227 +#define GPIO_USB1_PWR 230 /* For Cubieboard */ +#define GPIO_USB2_PWR 227 /* For Cubieboard */ #define A10_READ_4(sc, reg) \ bus_space_read_4((sc)->sc_io_tag, (sc)->sc_io_hdl, reg) @@ -110,7 +110,9 @@ { ehci_softc_t *sc = device_get_softc(self); bus_space_handle_t bsh; +#if 0 /* XXX For Cubieboard */ device_t sc_gpio_dev; +#endif int err; int rid; uint32_t reg_value = 0; @@ -163,6 +165,7 @@ sprintf(sc->sc_vendor, "Allwinner"); +#if 0 /* XXX For Cubieboard */ /* Get the GPIO device, we need this to give power to USB */ sc_gpio_dev = devclass_get_device(devclass_find("gpio"), 0); if (sc_gpio_dev == NULL) { @@ -169,6 +172,7 @@ device_printf(self, "Error: failed to get the GPIO device\n"); goto error; } +#endif err = bus_setup_intr(self, sc->sc_irq_res, INTR_TYPE_BIO | INTR_MPSAFE, NULL, (driver_intr_t *)ehci_interrupt, sc, &sc->sc_intr_hdl); @@ -183,6 +187,7 @@ /* Enable clock for USB */ a10_clk_usb_activate(); +#if 0 /* XXX For Cubieboard */ /* Give power to USB */ GPIO_PIN_SETFLAGS(sc_gpio_dev, GPIO_USB2_PWR, GPIO_PIN_OUTPUT); GPIO_PIN_SET(sc_gpio_dev, GPIO_USB2_PWR, GPIO_PIN_HIGH); @@ -190,6 +195,7 @@ /* Give power to USB */ GPIO_PIN_SETFLAGS(sc_gpio_dev, GPIO_USB1_PWR, GPIO_PIN_OUTPUT); GPIO_PIN_SET(sc_gpio_dev, GPIO_USB1_PWR, GPIO_PIN_HIGH); +#endif /* Enable passby */ reg_value = A10_READ_4(sc, SW_USB_PMU_IRQ_ENABLE); Index: sys/arm/allwinner/a10_mmc.c =================================================================== --- sys/arm/allwinner/a10_mmc.c (revision 0) +++ sys/arm/allwinner/a10_mmc.c (working copy) @@ -0,0 +1,653 @@ +/*- + * Copyright (c) 2013 Alexander Fedorov + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + */ +#include +__FBSDID("$FreeBSD: head/sys/arm/lpc/lpc_mmc.c 239278 2012-08-15 05:37:10Z gonzo $"); + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include +#include +#include +#include +#include +#include + +#include +#include + +#include +#include +#include + +#include +#include + +struct a10_mmc_softc { + device_t a10_dev; + struct mtx a10_mtx; + struct resource * a10_mem_res; + struct resource * a10_irq_res; + bus_space_tag_t a10_bst; + bus_space_handle_t a10_bsh; + void * a10_intrhand; + struct mmc_host a10_host; + struct mmc_request * a10_req; + int a10_bus_busy; + uint8_t wait; + uint32_t error; + enum{ + A10_MMC_ST_UNK = 0, + A10_MMC_ST_WAIT_CMD_DONE, + A10_MMC_ST_WAIT_DATA_DONE + }state; +}; + +static int a10_mmc_probe(device_t); +static int a10_mmc_attach(device_t); +static int a10_mmc_detach(device_t); +static void a10_mmc_intr(void *); + +static int a10_mmc_update_ios(device_t, device_t); +static int a10_mmc_request(device_t, device_t, struct mmc_request *); +static int a10_mmc_get_ro(device_t, device_t); +static int a10_mmc_acquire_host(device_t, device_t); +static int a10_mmc_release_host(device_t, device_t); + +#define a10_mmc_lock(_sc) \ + mtx_lock(&_sc->a10_mtx); +#define a10_mmc_unlock(_sc) \ + mtx_unlock(&_sc->a10_mtx); +#define a10_mmc_read_4(_sc, _reg) \ + bus_space_read_4(_sc->a10_bst, _sc->a10_bsh, _reg) +#define a10_mmc_write_4(_sc, _reg, _value) \ + bus_space_write_4(_sc->a10_bst, _sc->a10_bsh, _reg, _value) + +static int +a10_mmc_reset(struct a10_mmc_softc *sc) +{ + uint32_t rval = a10_mmc_read_4(sc, MMC_GCTRL) | MMC_SOFT_RESET_B | MMC_FIFO_RESET_B | MMC_DMA_RESET_B; + int time = 0xffff; + + a10_mmc_write_4(sc, MMC_GCTRL, rval); + while((a10_mmc_read_4(sc, MMC_GCTRL) & (MMC_SOFT_RESET_B | MMC_FIFO_RESET_B | MMC_DMA_RESET_B)) && time--); + if (time <= 0){ + device_printf(sc->a10_dev, "Reset failed\n"); + return -1; + } + return 0; +} + +static void +a10_mmc_int_enable(struct a10_mmc_softc *sc) +{ + a10_mmc_write_4(sc, MMC_GCTRL, a10_mmc_read_4(sc, MMC_GCTRL)|MMC_INT_ENABLE_B); +} + +static int +a10_mmc_update_clk(struct a10_mmc_softc *sc) +{ + unsigned int cmd; + unsigned timeout = 0xfffff; + + cmd = MMC_Start | MMC_UPCLKOnly | MMC_WaitPreOver; + a10_mmc_write_4(sc, MMC_CMDR, cmd); + while((a10_mmc_read_4(sc, MMC_CMDR) & MMC_Start) && timeout--); + if (!timeout) + return -1; + + return 0; +} + +static int +a10_mmc_config_clock(struct a10_mmc_softc *sc, unsigned div) +{ + unsigned rval = a10_mmc_read_4(sc, MMC_CLKCR); + + /* + * CLKCREG[7:0]: divider + * CLKCREG[16]: on/off + * CLKCREG[17]: power save + */ + + /* Disable Clock */ + rval &= ~MMC_CARD_CLK_ON; + a10_mmc_write_4(sc, MMC_CLKCR, rval); + if(a10_mmc_update_clk(sc)) + return -1; + + /* Change Divider Factor */ + rval &= ~(0xFF); + rval |= div; + a10_mmc_write_4(sc, MMC_CLKCR, rval); + if(a10_mmc_update_clk(sc)) + return -1; + + /* Enable Clock */ + rval |= MMC_CARD_CLK_ON; + a10_mmc_write_4(sc, MMC_CLKCR, rval); + if(a10_mmc_update_clk(sc)) + return -1; + + return 0; +} + +static int +a10_mmc_probe(device_t dev) +{ + if (!ofw_bus_is_compatible(dev, "allwinner,sun4i-mmc")) + return (ENXIO); + + device_set_desc(dev, "Allwinner Integrated MMC/SD controller"); + return (BUS_PROBE_DEFAULT); +} + +static int +a10_mmc_attach(device_t dev) +{ + struct a10_mmc_softc *sc = device_get_softc(dev); + device_t child; + int rid; + + sc->a10_dev = dev; + sc->a10_req = NULL; + + mtx_init(&sc->a10_mtx, device_get_nameunit(sc->a10_dev), "a10_mmc", MTX_DEF); + + rid = 0; + sc->a10_mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, + RF_ACTIVE); + if (!sc->a10_mem_res) { + device_printf(dev, "cannot allocate memory window\n"); + return (ENXIO); + } + + sc->a10_bst = rman_get_bustag(sc->a10_mem_res); + sc->a10_bsh = rman_get_bushandle(sc->a10_mem_res); + + rid = 0; + sc->a10_irq_res = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid, + RF_ACTIVE | RF_SHAREABLE); + if (!sc->a10_irq_res) { + device_printf(dev, "cannot allocate interrupt\n"); + bus_release_resource(dev, SYS_RES_MEMORY, 0, sc->a10_mem_res); + return (ENXIO); + } + + if (bus_setup_intr(dev, sc->a10_irq_res, INTR_TYPE_MISC | INTR_MPSAFE, + NULL, a10_mmc_intr, sc, &sc->a10_intrhand)) + { + bus_release_resource(dev, SYS_RES_MEMORY, 0, sc->a10_mem_res); + bus_release_resource(dev, SYS_RES_IRQ, 0, sc->a10_irq_res); + device_printf(dev, "cannot setup interrupt handler\n"); + return (ENXIO); + } + + a10_clk_mmc_activate(); + + /* Reset controller */ + a10_mmc_reset(sc); + + /* config DMA/Interrupt Trigger threshold */ + // a10_mmc_write_4(sc, MMC_FTRGL, 0x70008); + + /* config timeout register */ + a10_mmc_write_4(sc, MMC_TMOUT, 0xffffffff); + + /* clear interrupt flags */ + a10_mmc_write_4(sc, MMC_RINTR, 0xffffffff); + + a10_mmc_write_4(sc, MMC_DBGC, 0xdeb); + a10_mmc_write_4(sc, MMC_FUNS, 0xceaa0000); + + sc->a10_host.f_min = 400000; + sc->a10_host.f_max = 52000000; + sc->a10_host.host_ocr = MMC_OCR_320_330 | MMC_OCR_330_340; + sc->a10_host.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_HSPEED; + sc->a10_host.mode = mode_sd; + + /* device_set_ivars(dev, &sc->a10_host); */ + + child = device_add_child(dev, "mmc", 0); + if (!child) { + device_printf(dev, "attaching MMC bus failed!\n"); + bus_teardown_intr(dev, sc->a10_irq_res, sc->a10_intrhand); + bus_release_resource(dev, SYS_RES_MEMORY, 0, sc->a10_mem_res); + bus_release_resource(dev, SYS_RES_IRQ, 0, sc->a10_irq_res); + return (ENXIO); + } + + device_set_ivars(dev, &sc->a10_host); + return (bus_generic_attach(dev)); + +} + +static int +a10_mmc_detach(device_t dev) +{ + return (EBUSY); +} + +static int +mmc_trans_data_by_cpu(struct a10_mmc_softc *sc, struct mmc_data *data) +{ + unsigned i; + unsigned byte_cnt = data->len; + unsigned *buff; + unsigned timeout = 0xfffff; + + if (data->flags & MMC_DATA_READ) { + buff = (unsigned int *)data->data; + for (i=0; i<(byte_cnt>>2); i++) { + while(--timeout && (a10_mmc_read_4(sc, MMC_STAS) & MMC_FIFOEmpty)); + if (timeout <= 0) + goto out; + buff[i] = a10_mmc_read_4(sc, MMC_FIFO); + timeout = 0xfffff; + } + } else { + buff = (unsigned int *)data->data; + for (i=0; i<(byte_cnt>>2); i++) { + while(--timeout && (a10_mmc_read_4(sc, MMC_STAS) & MMC_FIFOFull)); + if (timeout <= 0) + goto out; + a10_mmc_write_4(sc, MMC_FIFO, buff[i]); + timeout = 0xfffff; + } + } + +out: + if (timeout <= 0) + return -1; + + return 0; +} + +static void +a10_req_ok(struct a10_mmc_softc *sc) +{ + struct mmc_command *cmd = sc->a10_req->cmd; + uint32_t resp_status;; + + do{ + resp_status = a10_mmc_read_4(sc, MMC_STAS); + }while(resp_status & MMC_CardDataBusy); + + if (cmd->flags & MMC_RSP_136) { + cmd->resp[0] = a10_mmc_read_4(sc, MMC_RESP3); + cmd->resp[1] = a10_mmc_read_4(sc, MMC_RESP2); + cmd->resp[2] = a10_mmc_read_4(sc, MMC_RESP1); + cmd->resp[3] = a10_mmc_read_4(sc, MMC_RESP0); + } else { + cmd->resp[0] = a10_mmc_read_4(sc, MMC_RESP0); + } + + sc->a10_req->cmd->error = MMC_ERR_NONE; + sc->a10_req->done(sc->a10_req); + sc->a10_req = NULL; +} + +static void +a10_req_err(struct a10_mmc_softc *sc) +{ + struct mmc_command *cmd = sc->a10_req->cmd; + device_printf(sc->a10_dev, "req error\n"); + cmd->error = MMC_ERR_TIMEOUT; + sc->a10_req->done(sc->a10_req); + sc->a10_req = NULL; +} + +static void +a10_mmc_intr(void *arg) +{ + struct a10_mmc_softc *sc = (struct a10_mmc_softc *)arg; + uint32_t rint = a10_mmc_read_4(sc, MMC_RINTR); + uint32_t imask = a10_mmc_read_4(sc, MMC_IMASK); + + imask &= ~rint; + a10_mmc_write_4(sc, MMC_IMASK, imask); + a10_mmc_write_4(sc, MMC_RINTR, rint); + + if(sc->a10_req == NULL){ + device_printf(sc->a10_dev, "req == NULL, rint: 0x%08X\n", rint); + } + + struct mmc_command *cmd = sc->a10_req->cmd; + +// if (cmd->data) { +// if (cmd->data->flags & MMC_DATA_WRITE){ +// device_printf(sc->a10_dev, "rint: 0x%08X, imask: 0x%08X\n", rint, imask); +// } +// } + + if(rint & MMC_IntErrBit){ + device_printf(sc->a10_dev, "error rint: 0x%08X\n", rint); + a10_req_err(sc); + return; + } + + if(!cmd->data && (rint & MMC_CmdDone)){ + a10_req_ok(sc); + return; + } + + if(cmd->data && (rint & MMC_DataOver)){ + a10_req_ok(sc); + return; + } + + if(cmd->data->flags & MMC_DATA_READ){ + int ret = mmc_trans_data_by_cpu(sc, cmd->data); + if(ret){ + device_printf(sc->a10_dev, "data read error, rint: 0x%08X\n", rint); + a10_req_err(sc); + + } + } + + if(cmd->data->flags & MMC_DATA_WRITE){ + if(rint & MMC_TxDataReq){ + int ret = mmc_trans_data_by_cpu(sc, cmd->data); + if(ret){ + device_printf(sc->a10_dev, "data write error, rint: 0x%08X\n", rint); + a10_req_err(sc); + } + } + } +} + +static int +a10_mmc_request(device_t bus, device_t child, struct mmc_request *req) +{ + unsigned int cmdreg = 0x80000000; + struct a10_mmc_softc *sc = device_get_softc(bus); + struct mmc_command *cmd = req->cmd; + uint32_t imask = MMC_CmdDone | MMC_IntErrBit; + + a10_mmc_lock(sc); + if (sc->a10_req){ + a10_mmc_unlock(sc); + return (EBUSY); + } + + sc->a10_req = req; + + if (cmd->opcode == MMC_GO_IDLE_STATE) + cmdreg |= MMC_SendInitSeq; + if (cmd->flags & MMC_RSP_PRESENT) + cmdreg |= MMC_RspExp; + if (cmd->flags & MMC_RSP_136) + cmdreg |= MMC_LongRsp; + if (cmd->flags & MMC_RSP_CRC) + cmdreg |= MMC_CheckRspCRC; + + if (cmd->data) { + cmdreg |= MMC_DataExp | MMC_WaitPreOver; + imask |= MMC_DataOver; + if (cmd->data->flags & MMC_DATA_WRITE){ + cmdreg |= MMC_Write; + imask |= MMC_TxDataReq; + }else{ + imask |= MMC_RxDataReq; + } + +// if (data->blocks > 1) +// cmdreg |= MMC_SendAutoStop; + + a10_mmc_write_4(sc, MMC_BLKSZ, cmd->data->len); + a10_mmc_write_4(sc, MMC_BCNTR, cmd->data->len); + + /* Choose access by AHB */ + a10_mmc_write_4(sc, MMC_GCTRL, a10_mmc_read_4(sc, MMC_GCTRL)|0x80000000); + } + + if (cmd->flags & MMC_RSP_BUSY) { + imask |= MMC_DataTimeout; + } + + /* Enable interrupts and set IMASK */ + a10_mmc_write_4(sc, MMC_IMASK, imask); + a10_mmc_int_enable(sc); + + a10_mmc_write_4(sc, MMC_CARG, cmd->arg); + a10_mmc_write_4(sc, MMC_CMDR, cmdreg|cmd->opcode); + sc->state = A10_MMC_ST_WAIT_CMD_DONE; + + a10_mmc_unlock(sc); + return 0; +} + +static int +a10_mmc_read_ivar(device_t bus, device_t child, int which, + uintptr_t *result) +{ + struct a10_mmc_softc *sc = device_get_softc(bus); + + switch (which) { + default: + return (EINVAL); + case MMCBR_IVAR_BUS_MODE: + *(int *)result = sc->a10_host.ios.bus_mode; + break; + case MMCBR_IVAR_BUS_WIDTH: + *(int *)result = sc->a10_host.ios.bus_width; + break; + case MMCBR_IVAR_CHIP_SELECT: + *(int *)result = sc->a10_host.ios.chip_select; + break; + case MMCBR_IVAR_CLOCK: + *(int *)result = sc->a10_host.ios.clock; + break; + case MMCBR_IVAR_F_MIN: + *(int *)result = sc->a10_host.f_min; + break; + case MMCBR_IVAR_F_MAX: + *(int *)result = sc->a10_host.f_max; + break; + case MMCBR_IVAR_HOST_OCR: + *(int *)result = sc->a10_host.host_ocr; + break; + case MMCBR_IVAR_MODE: + *(int *)result = sc->a10_host.mode; + break; + case MMCBR_IVAR_OCR: + *(int *)result = sc->a10_host.ocr; + break; + case MMCBR_IVAR_POWER_MODE: + *(int *)result = sc->a10_host.ios.power_mode; + break; + case MMCBR_IVAR_VDD: + *(int *)result = sc->a10_host.ios.vdd; + break; + case MMCBR_IVAR_CAPS: + *(int *)result = sc->a10_host.caps; + break; + case MMCBR_IVAR_MAX_DATA: + *(int *)result = 1; + break; + } + + return (0); +} + +static int +a10_mmc_write_ivar(device_t bus, device_t child, int which, + uintptr_t value) +{ + struct a10_mmc_softc *sc = device_get_softc(bus); + + switch (which) { + default: + return (EINVAL); + case MMCBR_IVAR_BUS_MODE: + sc->a10_host.ios.bus_mode = value; + break; + case MMCBR_IVAR_BUS_WIDTH: + sc->a10_host.ios.bus_width = value; + break; + case MMCBR_IVAR_CHIP_SELECT: + sc->a10_host.ios.chip_select = value; + break; + case MMCBR_IVAR_CLOCK: + sc->a10_host.ios.clock = value; + break; + case MMCBR_IVAR_MODE: + sc->a10_host.mode = value; + break; + case MMCBR_IVAR_OCR: + sc->a10_host.ocr = value; + break; + case MMCBR_IVAR_POWER_MODE: + sc->a10_host.ios.power_mode = value; + break; + case MMCBR_IVAR_VDD: + sc->a10_host.ios.vdd = value; + break; + /* These are read-only */ + case MMCBR_IVAR_CAPS: + case MMCBR_IVAR_HOST_OCR: + case MMCBR_IVAR_F_MIN: + case MMCBR_IVAR_F_MAX: + case MMCBR_IVAR_MAX_DATA: + return (EINVAL); + } + return (0); +} + +static int +a10_mmc_update_ios(device_t bus, device_t child) +{ + struct a10_mmc_softc *sc = device_get_softc(bus); + struct mmc_ios *ios = &sc->a10_host.ios; + unsigned int clkdiv = 0; + + /* Change clock first */ + clkdiv = (0x04dd1e00 + (ios->clock>>1))/ios->clock/2; + if (ios->clock) { + if (a10_mmc_config_clock(sc, clkdiv)) { + return -1; + } + } + + /* Set the bus width */ + switch (ios->bus_width) { + case bus_width_1: + a10_mmc_write_4(sc, MMC_WIDTH, MMC_WIDTH1); + break; + case bus_width_4: + a10_mmc_write_4(sc, MMC_WIDTH, MMC_WIDTH4); + break; + case bus_width_8: + a10_mmc_write_4(sc, MMC_WIDTH, MMC_WIDTH8); + break; + } + + return (0); +} + +static int +a10_mmc_get_ro(device_t bus, device_t child) +{ + return (0); +} + +static int +a10_mmc_acquire_host(device_t bus, device_t child) +{ + struct a10_mmc_softc *sc = device_get_softc(bus); + int error = 0; + + a10_mmc_lock(sc); + while (sc->a10_bus_busy) + error = mtx_sleep(sc, &sc->a10_mtx, PZERO, "mmcah", 0); + + sc->a10_bus_busy++; + a10_mmc_unlock(sc); + return (error); +} + +static int +a10_mmc_release_host(device_t bus, device_t child) +{ + struct a10_mmc_softc *sc = device_get_softc(bus); + + a10_mmc_lock(sc); + sc->a10_bus_busy--; + wakeup(sc); + a10_mmc_unlock(sc); + return (0); +} + +static device_method_t a10_mmc_methods[] = { + /* Device interface */ + DEVMETHOD(device_probe, a10_mmc_probe), + DEVMETHOD(device_attach, a10_mmc_attach), + DEVMETHOD(device_detach, a10_mmc_detach), + + /* Bus interface */ + DEVMETHOD(bus_read_ivar, a10_mmc_read_ivar), + DEVMETHOD(bus_write_ivar, a10_mmc_write_ivar), + /* DEVMETHOD(bus_print_child, bus_generic_print_child), */ + + /* MMC bridge interface */ + DEVMETHOD(mmcbr_update_ios, a10_mmc_update_ios), + DEVMETHOD(mmcbr_request, a10_mmc_request), + DEVMETHOD(mmcbr_get_ro, a10_mmc_get_ro), + DEVMETHOD(mmcbr_acquire_host, a10_mmc_acquire_host), + DEVMETHOD(mmcbr_release_host, a10_mmc_release_host), + + { 0, 0 } +}; + +static devclass_t a10_mmc_devclass; + +static driver_t a10_mmc_driver = { + .name = "a10_mmc", + .methods = a10_mmc_methods, + .size = sizeof(struct a10_mmc_softc), +}; + +DRIVER_MODULE(a10_mmc, simplebus, a10_mmc_driver, a10_mmc_devclass, 0, 0); + Index: sys/arm/allwinner/a10_mmc.h =================================================================== --- sys/arm/allwinner/a10_mmc.h (revision 0) +++ sys/arm/allwinner/a10_mmc.h (working copy) @@ -0,0 +1,177 @@ +/*- + * Copyright (c) 2013 Alexander Fedorov + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + */ + +#ifndef _A10_MMC_H_ +#define _A10_MMC_H_ + +#define MMC_GCTRL 0x00 // SMC Global Control Register +#define MMC_CLKCR 0x04 // SMC Clock Control Register +#define MMC_TMOUT 0x08 // SMC Time Out Register +#define MMC_WIDTH 0x0C // SMC Bus Width Register +#define MMC_BLKSZ 0x10 // SMC Block Size Register +#define MMC_BCNTR 0x14 // SMC Byte Count Register +#define MMC_CMDR 0x18 // SMC Command Register +#define MMC_CARG 0x1C // SMC Argument Register +#define MMC_RESP0 0x20 // SMC Response Register 0 +#define MMC_RESP1 0x24 // SMC Response Register 1 +#define MMC_RESP2 0x28 // SMC Response Register 2 +#define MMC_RESP3 0x2C // SMC Response Register 3 +#define MMC_IMASK 0x30 // SMC Interrupt Mask Register +#define MMC_MISTA 0x34 // SMC Masked Interrupt Status Register +#define MMC_RINTR 0x38 // SMC Raw Interrupt Status Register +#define MMC_STAS 0x3C // SMC Status Register +#define MMC_FTRGL 0x40 // SMC FIFO Threshold Watermark Register +#define MMC_FUNS 0x44 // SMC Function Select Register +#define MMC_CBCR 0x48 // SMC CIU Byte Count Register +#define MMC_BBCR 0x4C // SMC BIU Byte Count Register +#define MMC_DBGC 0x50 // SMC Debug Enable Register +#define MMC_DMAC 0x80 // SMC IDMAC Control Register +#define MMC_DLBA 0x84 // SMC IDMAC Descriptor List Base Address Register +#define MMC_IDST 0x88 // SMC IDMAC Status Register +#define MMC_IDIE 0x8C // SMC IDMAC Interrupt Enable Register +#define MMC_CHDA 0x90 +#define MMC_CBDA 0x94 +#define MMC_FIFO 0x100 // SMC FIFO Access Address + +/* MMC_GCTRL */ +#define MMC_SOFT_RESET_B (1 << 0) +#define MMC_FIFO_RESET_B (1 << 1) +#define MMC_DMA_RESET_B (1 << 2) +#define MMC_INT_ENABLE_B (1 << 4) +#define MMC_DMA_ENABLE_B (1 << 5) +#define MMC_DEBOUNCE_ENABLE_B (1 << 8) +#define MMC_PosedgeLatchData (1 << 9) +#define MMC_NegedgeLatchData (0 << 9) +#define MMC_DDR_MODE (1 << 10) +#define MMC_ACCESS_BY_AHB (1 << 31) +#define MMC_ACCESS_BY_DMA (0 << 31) + +/* CLKCR */ +#define MMC_CARD_CLK_ON (1 << 16) +#define MMC_LOW_POWER_ON (1 << 17) + +/* MMC_WIDTH */ +#define MMC_WIDTH1 (0) +#define MMC_WIDTH4 (1) +#define MMC_WIDTH8 (2) + +/* MMC_CMDR */ +#define MMC_RspExp (1 << 6) //0x40 +#define MMC_LongRsp (1 << 7) //0x80 +#define MMC_CheckRspCRC (1 << 8) //0x100 +#define MMC_DataExp (1 << 9) //0x200 +#define MMC_Read (0 << 10) //0x000 +#define MMC_Write (1 << 10) //0x400 +#define MMC_Blockmod (0 << 11) //0x000 +#define MMC_Seqmod (1 << 11) //0x800 +#define MMC_SendAutoStop (1 << 12) //0x1000 +#define MMC_WaitPreOver (1 << 13) //0x2000 +#define MMC_StopAbortCMD (1 << 14) //0x4000 +#define MMC_SendInitSeq (1 << 15) //0x8000 +#define MMC_UPCLKOnly (1 << 21) //0x200000 +#define MMC_RdCEATADev (1 << 22) //0x400000 +#define MMC_CCSExp (1 << 23) //0x800000 +#define MMC_EnbBoot (1 << 24) //0x1000000 +#define MMC_AltBootOpt (1 << 25) //0x2000000 +#define MMC_MandBootOpt (0 << 25) //0x0000000 +#define MMC_BootACKExp (1 << 26) //0x4000000 +#define MMC_DisableBoot (1 << 27) //0x8000000 +#define MMC_VolSwitch (1 << 28) //0x10000000 +#define MMC_Start (1 << 31) //0x80000000 + +/* Struct for Intrrrupt Information */ +#define MMC_RespErr (1 << 1) //0x2 +#define MMC_CmdDone (1 << 2) //0x4 +#define MMC_DataOver (1 << 3) //0x8 +#define MMC_TxDataReq (1 << 4) //0x10 +#define MMC_RxDataReq (1 << 5) //0x20 +#define MMC_RespCRCErr (1 << 6) //0x40 +#define MMC_DataCRCErr (1 << 7) //0x80 +#define MMC_RespTimeout (1 << 8) //0x100 +#define MMC_ACKRcv (1 << 8) //0x100 +#define MMC_DataTimeout (1 << 9) //0x200 +#define MMC_BootStart (1 << 9) //0x200 +#define MMC_DataStarve (1 << 10) //0x400 +#define MMC_VolChgDone (1 << 10) //0x400 +#define MMC_FIFORunErr (1 << 11) //0x800 +#define MMC_HardWLocked (1 << 12) //0x1000 +#define MMC_StartBitErr (1 << 13) //0x2000 +#define MMC_AutoCMDDone (1 << 14) //0x4000 +#define MMC_EndBitErr (1 << 15) //0x8000 +#define MMC_SDIOInt (1 << 16) //0x10000 +#define MMC_CardInsert (1 << 30) //0x40000000 +#define MMC_CardRemove (1 << 31) //0x80000000 +#define MMC_IntErrBit (MMC_RespErr | MMC_RespCRCErr | MMC_DataCRCErr | MMC_RespTimeout | MMC_DataTimeout \ + | MMC_FIFORunErr | MMC_HardWLocked | MMC_StartBitErr | MMC_EndBitErr) //0xbfc2 +/* status */ +#define MMC_RXWLFlag (1 << 0) +#define MMC_TXWLFlag (1 << 1) +#define MMC_FIFOEmpty (1 << 2) +#define MMC_FIFOFull (1 << 3) +#define MMC_CardPresent (1 << 8) +#define MMC_CardDataBusy (1 << 9) +#define MMC_DataFSMBusy (1 << 10) +#define MMC_DMAReq (1 << 31) +#define MMC_FIFO_SIZE (16) +/* Function select */ +#define MMC_CEATAOn (0xceaaU<< 16) +#define MMC_SendIrqRsp (1 << 0) +#define MMC_SDIORdWait (1 << 1) +#define MMC_AbtRdData (1 << 2) +#define MMC_SendCCSD (1 << 8) +#define MMC_SendAutoStopCCSD (1 << 9) +#define MMC_CEATADevIntEnb (1 << 10) +/* IDMA controller bus mod bit field */ +#define MMC_IDMACSoftRST (1 << 0) +#define MMC_IDMACFixBurst (1 << 1) +#define MMC_IDMACIDMAOn (1 << 7) +#define MMC_IDMACRefetchDES (1 << 31) +/* IDMA status bit field */ +#define MMC_IDMACTransmitInt (1 << 0) +#define MMC_IDMACReceiveInt (1 << 1) +#define MMC_IDMACFatalBusErr (1 << 2) +#define MMC_IDMACDesInvalid (1 << 4) +#define MMC_IDMACCardErrSum (1 << 5) +#define MMC_IDMACNormalIntSum (1 << 8) +#define MMC_IDMACAbnormalIntSum (1 << 9) +#define MMC_IDMACHostAbtInTx (1 << 10) +#define MMC_IDMACHostAbtInRx (1 << 10) +#define MMC_IDMACIdle (0 << 13) +#define MMC_IDMACSuspend (1 << 13) +#define MMC_IDMACDESCRd (0x2U<< 13) +#define MMC_IDMACDESCCheck (0x3U<< 13) +#define MMC_IDMACRdReqWait (0x4U<< 13) +#define MMC_IDMACWrReqWait (0x5U<< 13) +#define MMC_IDMACRd (0x6U<< 13) +#define MMC_IDMACWr (0x7U<< 13) +#define MMC_IDMACDESCClose (0x8U<< 13) + +#define MMC_IDMA_OVER (MMC_IDMACTransmitInt|MMC_IDMACReceiveInt|MMC_IDMACNormalIntSum) +#define MMC_IDMA_ERR (MMC_IDMACFatalBusErr|MMC_IDMACDesInvalid|MMC_IDMACCardErrSum|MMC_IDMACAbnormalIntSum) + +#endif /* _A10_MMC_H_ */ + Index: sys/arm/allwinner/a13_gpio.c =================================================================== --- sys/arm/allwinner/a13_gpio.c (revision 0) +++ sys/arm/allwinner/a13_gpio.c (working copy) @@ -0,0 +1,521 @@ +/*- + * Copyright (c) 2013 Ganbold Tsagaankhuu + * Copyright (c) 2012 Oleksandr Tymoshenko + * Copyright (c) 2012 Luiz Otavio O Souza. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + */ +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include "gpio_if.h" + +/* + * A13 have 7 banks of gpio, but PA is not used, meaning in reality there + * are only 6! + * 32 pins per bank, but not all to them usable: + * PB0 - PB4 + PB10 + PB15 - PB18 (10) + * PC0 - PC15 + PC19 (17) + * PD2 - PD7 + PD10 - PD27 (22) + * PE0 - PE11 (12) + * PF0 - PF5 (6) + * PG0 - PG4 + PG9 - PG12 (9) + */ + +#define A13_GPIO_PINS 224 +#define A13_GPIO_DEFAULT_CAPS (GPIO_PIN_INPUT | GPIO_PIN_OUTPUT | \ + GPIO_PIN_PULLUP | GPIO_PIN_PULLDOWN) + +#define A13_GPIO_NONE 0 +#define A13_GPIO_PULLUP 1 +#define A13_GPIO_PULLDOWN 2 + +#define A13_GPIO_INPUT 0 +#define A13_GPIO_OUTPUT 1 + +struct a13_gpio_softc { + device_t sc_dev; + struct mtx sc_mtx; + struct resource * sc_mem_res; + struct resource * sc_irq_res; + bus_space_tag_t sc_bst; + bus_space_handle_t sc_bsh; + void * sc_intrhand; + int sc_gpio_npins; + struct gpio_pin sc_gpio_pins[A13_GPIO_PINS]; +}; + +#define A13_GPIO_LOCK(_sc) mtx_lock(&_sc->sc_mtx) +#define A13_GPIO_UNLOCK(_sc) mtx_unlock(&_sc->sc_mtx) +#define A13_GPIO_LOCK_ASSERT(_sc) mtx_assert(&_sc->sc_mtx, MA_OWNED) + +#define A13_GPIO_GP_CFG(_bank, _pin) 0x00 + ((_bank) * 0x24) + ((_pin)<<2) +#define A13_GPIO_GP_DAT(_bank) 0x10 + ((_bank) * 0x24) +#define A13_GPIO_GP_DRV(_bank, _pin) 0x14 + ((_bank) * 0x24) + ((_pin)<<2) +#define A13_GPIO_GP_PUL(_bank, _pin) 0x1c + ((_bank) * 0x24) + ((_pin)<<2) + +#define A13_GPIO_GP_INT_CFG0 0x200 +#define A13_GPIO_GP_INT_CFG1 0x204 +#define A13_GPIO_GP_INT_CFG2 0x208 +#define A13_GPIO_GP_INT_CFG3 0x20c + +#define A13_GPIO_GP_INT_CTL 0x210 +#define A13_GPIO_GP_INT_STA 0x214 +#define A13_GPIO_GP_INT_DEB 0x218 + +#define A13_GPIO_WRITE(_sc, _off, _val) \ + bus_space_write_4(_sc->sc_bst, _sc->sc_bsh, _off, _val) +#define A13_GPIO_READ(_sc, _off) \ + bus_space_read_4(_sc->sc_bst, _sc->sc_bsh, _off) + +static uint32_t +a13_gpio_get_function(struct a13_gpio_softc *sc, uint32_t pin) +{ + uint32_t bank, func, offset; + + bank = pin / 32; + pin = pin - 32 * bank; + func = pin >> 3; + offset = ((pin & 0x07) << 2); + + A13_GPIO_LOCK(sc); + func = (A13_GPIO_READ(sc, A13_GPIO_GP_CFG(bank, func)) >> offset) & 7; + A13_GPIO_UNLOCK(sc); + + return (func); +} + +static uint32_t +a13_gpio_func_flag(uint32_t nfunc) +{ + + switch (nfunc) { + case A13_GPIO_INPUT: + return (GPIO_PIN_INPUT); + case A13_GPIO_OUTPUT: + return (GPIO_PIN_OUTPUT); + } + return (0); +} + +static void +a13_gpio_set_function(struct a13_gpio_softc *sc, uint32_t pin, uint32_t f) +{ + uint32_t bank, func, data, offset; + + /* Must be called with lock held. */ + A13_GPIO_LOCK_ASSERT(sc); + + bank = pin / 32; + pin = pin - 32 * bank; + func = pin >> 3; + offset = ((pin & 0x07) << 2); + + data = A13_GPIO_READ(sc, A13_GPIO_GP_CFG(bank, func)); + data &= ~(7 << offset); + data |= (f << offset); + A13_GPIO_WRITE(sc, A13_GPIO_GP_CFG(bank, func), data); +} + +static void +a13_gpio_set_pud(struct a13_gpio_softc *sc, uint32_t pin, uint32_t state) +{ + uint32_t bank, offset, pull, val; + + /* Must be called with lock held. */ + A13_GPIO_LOCK_ASSERT(sc); + + bank = pin / 32; + pin = pin - 32 * bank; + pull = pin >> 4; + offset = ((pin & 0x0f) << 1); + + val = A13_GPIO_READ(sc, A13_GPIO_GP_PUL(bank, pull)); + val &= ~(0x03 << offset); + val |= (state << offset); + A13_GPIO_WRITE(sc, A13_GPIO_GP_PUL(bank, pull), val); +} + +static void +a13_gpio_pin_configure(struct a13_gpio_softc *sc, struct gpio_pin *pin, + unsigned int flags) +{ + + A13_GPIO_LOCK(sc); + + /* + * Manage input/output. + */ + if (flags & (GPIO_PIN_INPUT|GPIO_PIN_OUTPUT)) { + pin->gp_flags &= ~(GPIO_PIN_INPUT|GPIO_PIN_OUTPUT); + if (flags & GPIO_PIN_OUTPUT) { + pin->gp_flags |= GPIO_PIN_OUTPUT; + a13_gpio_set_function(sc, pin->gp_pin, + A13_GPIO_OUTPUT); + } else { + pin->gp_flags |= GPIO_PIN_INPUT; + a13_gpio_set_function(sc, pin->gp_pin, + A13_GPIO_INPUT); + } + } + + /* Manage Pull-up/pull-down. */ + pin->gp_flags &= ~(GPIO_PIN_PULLUP|GPIO_PIN_PULLDOWN); + if (flags & (GPIO_PIN_PULLUP|GPIO_PIN_PULLDOWN)) { + if (flags & GPIO_PIN_PULLUP) { + pin->gp_flags |= GPIO_PIN_PULLUP; + a13_gpio_set_pud(sc, pin->gp_pin, A13_GPIO_PULLUP); + } else { + pin->gp_flags |= GPIO_PIN_PULLDOWN; + a13_gpio_set_pud(sc, pin->gp_pin, A13_GPIO_PULLDOWN); + } + } else + a13_gpio_set_pud(sc, pin->gp_pin, A13_GPIO_NONE); + + A13_GPIO_UNLOCK(sc); +} + +static int +a13_gpio_pin_max(device_t dev, int *maxpin) +{ + + *maxpin = A13_GPIO_PINS - 1; + return (0); +} + +static int +a13_gpio_pin_getcaps(device_t dev, uint32_t pin, uint32_t *caps) +{ + struct a13_gpio_softc *sc = device_get_softc(dev); + int i; + + for (i = 0; i < sc->sc_gpio_npins; i++) { + if (sc->sc_gpio_pins[i].gp_pin == pin) + break; + } + + if (i >= sc->sc_gpio_npins) + return (EINVAL); + + A13_GPIO_LOCK(sc); + *caps = sc->sc_gpio_pins[i].gp_caps; + A13_GPIO_UNLOCK(sc); + + return (0); +} + +static int +a13_gpio_pin_getflags(device_t dev, uint32_t pin, uint32_t *flags) +{ + struct a13_gpio_softc *sc = device_get_softc(dev); + int i; + + for (i = 0; i < sc->sc_gpio_npins; i++) { + if (sc->sc_gpio_pins[i].gp_pin == pin) + break; + } + + if (i >= sc->sc_gpio_npins) + return (EINVAL); + + A13_GPIO_LOCK(sc); + *flags = sc->sc_gpio_pins[i].gp_flags; + A13_GPIO_UNLOCK(sc); + + return (0); +} + +static int +a13_gpio_pin_getname(device_t dev, uint32_t pin, char *name) +{ + struct a13_gpio_softc *sc = device_get_softc(dev); + int i; + + for (i = 0; i < sc->sc_gpio_npins; i++) { + if (sc->sc_gpio_pins[i].gp_pin == pin) + break; + } + + if (i >= sc->sc_gpio_npins) + return (EINVAL); + + A13_GPIO_LOCK(sc); + memcpy(name, sc->sc_gpio_pins[i].gp_name, GPIOMAXNAME); + A13_GPIO_UNLOCK(sc); + + return (0); +} + +static int +a13_gpio_pin_setflags(device_t dev, uint32_t pin, uint32_t flags) +{ + struct a13_gpio_softc *sc = device_get_softc(dev); + int i; + + for (i = 0; i < sc->sc_gpio_npins; i++) { + if (sc->sc_gpio_pins[i].gp_pin == pin) + break; + } + + if (i >= sc->sc_gpio_npins) + return (EINVAL); + + /* Check for unwanted flags. */ + if ((flags & sc->sc_gpio_pins[i].gp_caps) != flags) + return (EINVAL); + + /* Can't mix input/output together. */ + if ((flags & (GPIO_PIN_INPUT|GPIO_PIN_OUTPUT)) == + (GPIO_PIN_INPUT|GPIO_PIN_OUTPUT)) + return (EINVAL); + + /* Can't mix pull-up/pull-down together. */ + if ((flags & (GPIO_PIN_PULLUP|GPIO_PIN_PULLDOWN)) == + (GPIO_PIN_PULLUP|GPIO_PIN_PULLDOWN)) + return (EINVAL); + + a13_gpio_pin_configure(sc, &sc->sc_gpio_pins[i], flags); + + return (0); +} + +static int +a13_gpio_pin_set(device_t dev, uint32_t pin, unsigned int value) +{ + struct a13_gpio_softc *sc = device_get_softc(dev); + uint32_t bank, offset, data; + int i; + + for (i = 0; i < sc->sc_gpio_npins; i++) { + if (sc->sc_gpio_pins[i].gp_pin == pin) + break; + } + + if (i >= sc->sc_gpio_npins) + return (EINVAL); + + bank = pin / 32; + pin = pin - 32 * bank; + offset = pin & 0x1f; + + A13_GPIO_LOCK(sc); + data = A13_GPIO_READ(sc, A13_GPIO_GP_DAT(bank)); + if (value) + data |= (1 << offset); + else + data &= ~(1 << offset); + A13_GPIO_WRITE(sc, A13_GPIO_GP_DAT(bank), data); + A13_GPIO_UNLOCK(sc); + + return (0); +} + +static int +a13_gpio_pin_get(device_t dev, uint32_t pin, unsigned int *val) +{ + struct a13_gpio_softc *sc = device_get_softc(dev); + uint32_t bank, offset, reg_data; + int i; + + for (i = 0; i < sc->sc_gpio_npins; i++) { + if (sc->sc_gpio_pins[i].gp_pin == pin) + break; + } + + if (i >= sc->sc_gpio_npins) + return (EINVAL); + + bank = pin / 32; + pin = pin - 32 * bank; + offset = pin & 0x1f; + + A13_GPIO_LOCK(sc); + reg_data = A13_GPIO_READ(sc, A13_GPIO_GP_DAT(bank)); + A13_GPIO_UNLOCK(sc); + *val = (reg_data & (1 << offset)) ? 1 : 0; + + return (0); +} + +static int +a13_gpio_pin_toggle(device_t dev, uint32_t pin) +{ + struct a13_gpio_softc *sc = device_get_softc(dev); + uint32_t bank, data, offset; + int i; + + for (i = 0; i < sc->sc_gpio_npins; i++) { + if (sc->sc_gpio_pins[i].gp_pin == pin) + break; + } + + if (i >= sc->sc_gpio_npins) + return (EINVAL); + + bank = pin / 32; + pin = pin - 32 * bank; + offset = pin & 0x1f; + + A13_GPIO_LOCK(sc); + data = A13_GPIO_READ(sc, A13_GPIO_GP_DAT(bank)); + if (data & (1 << offset)) + data &= ~(1 << offset); + else + data |= (1 << offset); + A13_GPIO_WRITE(sc, A13_GPIO_GP_DAT(bank), data); + A13_GPIO_UNLOCK(sc); + + return (0); +} + +static int +a13_gpio_probe(device_t dev) +{ + if (!ofw_bus_is_compatible(dev, "allwinner,sun5i-gpio")) + return (ENXIO); + + device_set_desc(dev, "Allwinner GPIO controller"); + return (BUS_PROBE_DEFAULT); +} + +static int +a13_gpio_attach(device_t dev) +{ + struct a13_gpio_softc *sc = device_get_softc(dev); + uint32_t func; + int i, rid; + phandle_t gpio; + + sc->sc_dev = dev; + + mtx_init(&sc->sc_mtx, "a13 gpio", "gpio", MTX_DEF); + + rid = 0; + sc->sc_mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, + RF_ACTIVE); + if (!sc->sc_mem_res) { + device_printf(dev, "cannot allocate memory window\n"); + return (ENXIO); + } + + sc->sc_bst = rman_get_bustag(sc->sc_mem_res); + sc->sc_bsh = rman_get_bushandle(sc->sc_mem_res); + + rid = 0; + sc->sc_irq_res = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid, + RF_ACTIVE); + if (!sc->sc_irq_res) { + bus_release_resource(dev, SYS_RES_MEMORY, 0, sc->sc_mem_res); + device_printf(dev, "cannot allocate interrupt\n"); + return (ENXIO); + } + + /* Find our node. */ + gpio = ofw_bus_get_node(sc->sc_dev); + + if (!OF_hasprop(gpio, "gpio-controller")) + /* Node is not a GPIO controller. */ + goto fail; + + /* Initialize the software controlled pins. */ + for (i = 0; i < A13_GPIO_PINS; i++) { + snprintf(sc->sc_gpio_pins[i].gp_name, GPIOMAXNAME, + "pin %d", i); + func = a13_gpio_get_function(sc, i); + sc->sc_gpio_pins[i].gp_pin = i; + sc->sc_gpio_pins[i].gp_caps = A13_GPIO_DEFAULT_CAPS; + sc->sc_gpio_pins[i].gp_flags = a13_gpio_func_flag(func); + } + sc->sc_gpio_npins = i; + + device_add_child(dev, "gpioc", device_get_unit(dev)); + device_add_child(dev, "gpiobus", device_get_unit(dev)); + return (bus_generic_attach(dev)); + +fail: + if (sc->sc_irq_res) + bus_release_resource(dev, SYS_RES_IRQ, 0, sc->sc_irq_res); + if (sc->sc_mem_res) + bus_release_resource(dev, SYS_RES_MEMORY, 0, sc->sc_mem_res); + return (ENXIO); +} + +static int +a13_gpio_detach(device_t dev) +{ + + return (EBUSY); +} + +static device_method_t a13_gpio_methods[] = { + /* Device interface */ + DEVMETHOD(device_probe, a13_gpio_probe), + DEVMETHOD(device_attach, a13_gpio_attach), + DEVMETHOD(device_detach, a13_gpio_detach), + + /* GPIO protocol */ + DEVMETHOD(gpio_pin_max, a13_gpio_pin_max), + DEVMETHOD(gpio_pin_getname, a13_gpio_pin_getname), + DEVMETHOD(gpio_pin_getflags, a13_gpio_pin_getflags), + DEVMETHOD(gpio_pin_getcaps, a13_gpio_pin_getcaps), + DEVMETHOD(gpio_pin_setflags, a13_gpio_pin_setflags), + DEVMETHOD(gpio_pin_get, a13_gpio_pin_get), + DEVMETHOD(gpio_pin_set, a13_gpio_pin_set), + DEVMETHOD(gpio_pin_toggle, a13_gpio_pin_toggle), + + DEVMETHOD_END +}; + +static devclass_t a13_gpio_devclass; + +static driver_t a13_gpio_driver = { + "gpio", + a13_gpio_methods, + sizeof(struct a13_gpio_softc), +}; + +DRIVER_MODULE(a13_gpio, simplebus, a13_gpio_driver, a13_gpio_devclass, 0, 0); Property changes on: sys/arm/allwinner/a13_gpio.c ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Index: sys/arm/allwinner/files.a13 =================================================================== --- sys/arm/allwinner/files.a13 (revision 0) +++ sys/arm/allwinner/files.a13 (working copy) @@ -0,0 +1,24 @@ +# $FreeBSD: head/sys/arm/allwinner/files.a10 262979 2014-03-10 18:10:09Z ian $ +kern/kern_clocksource.c standard + +arm/arm/bus_space_asm_generic.S standard +arm/arm/bus_space_generic.c standard +arm/arm/cpufunc_asm_armv5.S standard +arm/arm/cpufunc_asm_arm10.S standard +arm/arm/cpufunc_asm_arm11.S standard +arm/arm/cpufunc_asm_armv7.S standard + +arm/allwinner/a10_clk.c standard +arm/allwinner/a10_common.c standard +arm/allwinner/a13_gpio.c optional gpio +arm/allwinner/a10_ehci.c optional ehci +arm/allwinner/a10_mmc.c optional mmc +arm/allwinner/a10_machdep.c standard +arm/allwinner/a10_sramc.c standard +arm/allwinner/a10_wdog.c standard +arm/allwinner/a20/a20_cpu_cfg.c standard +arm/allwinner/aintc.c standard +arm/allwinner/timer.c standard +arm/arm/bus_space-v6.c standard +#arm/allwinner/console.c standard + Index: sys/arm/allwinner/std.a13 =================================================================== --- sys/arm/allwinner/std.a13 (revision 0) +++ sys/arm/allwinner/std.a13 (working copy) @@ -0,0 +1,19 @@ +# Allwinner A13 common options +#$FreeBSD: head/sys/arm/allwinner/std.a10 245450 2013-01-15 08:26:16Z ganbold $ + +cpu CPU_CORTEXA +machine arm armv6 +makeoption ARM_LITTLE_ENDIAN + +# Physical memory starts at 0x40200000. We assume images are loaded at +# 0x40200000, e.g. from u-boot with 'fatload mmc 0 0x40200000 kernel' +# +# +options PHYSADDR=0x40000000 + +makeoptions KERNPHYSADDR=0x40200000 +options KERNPHYSADDR=0x40200000 +makeoptions KERNVIRTADDR=0xc0200000 +options KERNVIRTADDR=0xc0200000 + +files "../allwinner/files.a13" Index: sys/arm/conf/A13_OLINUXINO =================================================================== --- sys/arm/conf/A13_OLINUXINO (revision 0) +++ sys/arm/conf/A13_OLINUXINO (working copy) @@ -0,0 +1,134 @@ +# A13 -- Custom configuration for the A13 ARM Olinuxino +# platform, check out http://www.olimex.com +# +# For more information on this file, please read the handbook section on +# Kernel Configuration Files: +# +# http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html +# +# The handbook is also available locally in /usr/share/doc/handbook +# if you've installed the doc distribution, otherwise always see the +# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the +# latest information. +# +# An exhaustive list of options and more detailed explanations of the +# device lines is also present in the ../../conf/NOTES and NOTES files. +# If you are in doubt as to the purpose or necessity of a line, check first +# in NOTES. +# +# $FreeBSD: head/sys/arm/conf/CUBIEBOARD 249083 2013-04-04 07:12:24Z mav $ + +ident A13_OLINUXINO + +include "../allwinner/std.a13" + +makeoptions MODULES_OVERRIDE="" +makeoptions WITHOUT_MODULES="ahc" + +options HZ=100 +options SCHED_4BSD # 4BSD scheduler +options INET # InterNETworking +options INET6 # IPv6 communications protocols +options GEOM_PART_BSD # BSD partition scheme +options GEOM_PART_MBR # MBR partition scheme +options TMPFS # Efficient memory filesystem +options FFS # Berkeley Fast Filesystem +options SOFTUPDATES # Enable FFS soft updates support +options UFS_ACL # Support for access control lists +options UFS_DIRHASH # Improve performance on big directories +options MSDOSFS # MSDOS Filesystem +options CD9660 # ISO 9660 Filesystem +options PROCFS # Process filesystem (requires PSEUDOFS) +options PSEUDOFS # Pseudo-filesystem framework +options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] +options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI +options KTRACE # ktrace(1) support +options SYSVSHM # SYSV-style shared memory +options SYSVMSG # SYSV-style message queues +options SYSVSEM # SYSV-style semaphores +options _KPOSIX_PRIORITY_SCHEDULING # Posix P1003_1B real-time extensions +options KBD_INSTALL_CDEV # install a CDEV entry in /dev +options PREEMPTION +options FREEBSD_BOOT_LOADER +options VFP # vfp/neon + +# Debugging +makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols +options BREAK_TO_DEBUGGER +#options VERBOSE_SYSINIT # Enable verbose sysinit messages +options KDB +options DDB # Enable the kernel debugger +#options INVARIANTS # Enable calls of extra sanity checking +#options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS +#options WITNESS # Enable checks to detect deadlocks and cycles +#options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed +#options DIAGNOSTIC + +options ARM_DEVICE_MULTIPASS + +# NFS support +#options NFSCL +#options NFSSERVER # Network Filesystem Server +#options NFSCLIENT # Network Filesystem Client + +# Uncomment this for NFS root +#options NFS_ROOT # NFS usable as /, requires NFSCLIENT +#options BOOTP_NFSROOT +#options BOOTP_COMPAT +#options BOOTP +#options BOOTP_NFSV3 +#options BOOTP_WIRED_TO=cpsw0 + +# MMC/SD/SDIO card slot support (currently broken) +#device mmc # mmc/sd bus +#device mmcsd # mmc/sd flash cards + +# Boot device is 2nd slice on MMC/SD card +options ROOTDEVNAME=\"ufs:/dev/da0s2\" + +# Console and misc +device uart +device uart_ns8250 +device pty +device snp +device md +device random # Entropy device + +# I2C support +#device iicbus +#device iic + +# GPIO +device gpio +device gpioled + +device scbus # SCSI bus (required for SCSI) +device da # Direct Access (disks) +device pass + +# USB support +options USB_HOST_ALIGN=64 # Align usb buffers to cache line size. +device usb +options USB_DEBUG +#options USB_REQ_DEBUG +#options USB_VERBOSE +#device uhci +#device ohci +device ehci + +device umass + +# Ethernet +device loop +device ether +device mii +device bpf + +# USB ethernet support, requires miibus +device miibus + +# Flattened Device Tree +options FDT +options FDT_DTB_STATIC +makeoptions FDT_DTS_FILE=a13_olinuxino.dts + Index: sys/boot/fdt/dts/arm/a13_olinuxino.dts =================================================================== --- sys/boot/fdt/dts/arm/a13_olinuxino.dts (revision 0) +++ sys/boot/fdt/dts/arm/a13_olinuxino.dts (working copy) @@ -0,0 +1,80 @@ +/*- + * Copyright (c) 2012 Ganbold Tsagaankhuu + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +/dts-v1/; + +/include/ "sun5i-a13.dtsi" + +/ { + model = "Olimex Olinuxino A13"; + + memory { + device_type = "memory"; + reg = < 0x40000000 0x20000000 >; /* 512MB RAM */ + }; + + aliases { + soc = &SOC; + UART1 = &UART1; + }; + + SOC: a13 { + + usb1: usb@01c14000 { + status = "okay"; + }; + + UART1: serial@01c28400 { + status = "okay"; + }; + + mmc@01c0f000 { + compatible = "allwinner,sun4i-mmc"; + reg = <0x01c0f000 0x1000>; + interrupts = <32>; + interrupt-parent = <&AINTC>; + }; + + }; + + leds { + compatible = "gpio-leds"; + + led1 { + label = "led1"; + gpios = <&gpio 201 1>; + }; + }; + + chosen { + bootargs = "-v"; + stdin = "UART1"; + stdout = "UART1"; + }; +}; + Property changes on: sys/boot/fdt/dts/arm/a13_olinuxino.dts ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Index: sys/boot/fdt/dts/arm/sun5i-a13.dtsi =================================================================== --- sys/boot/fdt/dts/arm/sun5i-a13.dtsi (revision 0) +++ sys/boot/fdt/dts/arm/sun5i-a13.dtsi (working copy) @@ -0,0 +1,113 @@ +/*- + * Copyright (c) 2014 Ganbold Tsagaankhuu + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +/ { + compatible = "allwinner,sun4i-a10"; + #address-cells = <1>; + #size-cells = <1>; + + interrupt-parent = <&AINTC>; + + aliases { + soc = &SOC; + }; + + SOC: a13 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "simple-bus"; + ranges; + bus-frequency = <0>; + + AINTC: interrupt-controller@01c20400 { + compatible = "allwinner,sun4i-ic"; + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + reg = < 0x01c20400 0x400 >; + }; + + sramc@01c00000 { + compatible = "allwinner,sun4i-sramc"; + #address-cells = <1>; + #size-cells = <1>; + reg = < 0x01c00000 0x1000 >; + }; + + ccm@01c20000 { + compatible = "allwinner,sun4i-ccm"; + #address-cells = <1>; + #size-cells = <1>; + reg = < 0x01c20000 0x400 >; + }; + + timer@01c20c00 { + compatible = "allwinner,sun4i-timer"; + reg = <0x01c20c00 0x90>; + interrupts = < 22 >; + interrupt-parent = <&AINTC>; + clock-frequency = < 24000000 >; + }; + + watchdog@01c20c90 { + compatible = "allwinner,sun4i-wdt"; + reg = <0x01c20c90 0x08>; + }; + + + gpio: gpio@01c20800 { + #gpio-cells = <3>; + compatible = "allwinner,sun5i-gpio"; + gpio-controller; + reg =< 0x01c20800 0x400 >; + interrupts = < 28 >; + interrupt-parent = <&AINTC>; + }; + + usb1: usb@01c14000 { + compatible = "allwinner,usb-ehci", "usb-ehci"; + reg = <0x01c14000 0x1000>; + interrupts = < 39 >; + interrupt-parent = <&AINTC>; + }; + + UART1: serial@01c28400 { + compatible = "ns16550"; + reg = <0x01c28400 0x400>; + reg-shift = <2>; + interrupts = <2>; + interrupt-parent = <&AINTC>; + current-speed = <115200>; + clock-frequency = < 24000000 >; + busy-detect = <1>; + broken-txfifo = <1>; + }; + + }; +}; + Property changes on: sys/boot/fdt/dts/arm/sun5i-a13.dtsi ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Index: sys/dev/mmc/mmc.c =================================================================== --- sys/dev/mmc/mmc.c (revision 272713) +++ sys/dev/mmc/mmc.c (working copy) @@ -1774,4 +1774,5 @@ DRIVER_MODULE(mmc, sdhci_ti, mmc_driver, mmc_devclass, NULL, NULL); DRIVER_MODULE(mmc, ti_mmchs, mmc_driver, mmc_devclass, NULL, NULL); DRIVER_MODULE(mmc, dwmmc, mmc_driver, mmc_devclass, NULL, NULL); +DRIVER_MODULE(mmc, a10_mmc, mmc_driver, mmc_devclass, NULL, NULL); ------=_20141007221852_56350-- From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 21:05:13 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA1923C0 for ; Tue, 7 Oct 2014 21:05:13 +0000 (UTC) Received: from mail.neu.net (neu.net [162.217.113.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gaq5.x.rootbsd.net", Issuer "gaq5.x.rootbsd.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B19DAEF3 for ; Tue, 7 Oct 2014 21:05:13 +0000 (UTC) Received: from neu.net (neu.net [162.217.113.162]) by mail.neu.net (8.14.9/8.14.7) with ESMTP id s97L5AO9014201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Oct 2014 17:05:10 -0400 (EDT) (envelope-from andy@neu.net) Date: Tue, 7 Oct 2014 17:05:10 -0400 (EDT) From: AN To: freebsd-arm@freebsd.org Subject: FreeBSD on BeagleBone Black Message-ID: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.98.4 at my.mail.server.name X-Virus-Status: Clean X-Spam-Status: No, score=-0.7 required=4.1 tests=RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.neu.net X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 21:05:14 -0000 Hi List: I have been using FreeBSD current on amd64 for many years. I now have a project that I want to try to run on FreeBSD. I'm trying to boot a FreeBSD image on a BeagleBone Black Rev C without success. FreeBSD-11.0-CURRENT-arm-armv6-BEAGLEBONE-20140903-r270990.img FreeBSD-arm-10.0-BEAGLEBONE.img The above images fail to boot. Here is info from the Beaglebone that is currently running Arch linux booted from the sd card: [root@bbb-allstar ~]# uname -a Linux bbb-allstar 3.8.13-35-ARCH #1 SMP Thu Sep 25 20:15:28 MDT 2014 armv7l GNU/Linux [root@bbb-allstar ~]# dmesg [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.8.13-35-ARCH (nobody@root-chroot-copy) (gcc version 4.8.2 20131219 (prerelease) (GCC) ) #1 SMP Thu Sep 25 20:15:28 MDT 2014 [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone ... [ 0.000000] AM335X ES2.1 (l2cache sgx neon ) [ 0.000000] PERCPU: Embedded 9 pages/cpu @c0e64000 s14016 r8192 d14656 u36864 [ 0.000000] pcpu-alloc: s14016 r8192 d14656 u36864 alloc=9*4096 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129792 [ 0.000000] Kernel command line: console=ttyO0,115200n8 coherent_pool=1M root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait [ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes) [ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] __ex_table already sorted, skipping sort [ 0.000000] allocated 1048576 bytes of page_cgroup [ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups [ 0.000000] Memory: 511MB = 511MB total [ 0.000000] Memory: 507028k/507028k available, 17260k reserved, 0K highmem I saw discussion on the list previously discussing: Re: [RFC] Add and armv7hf TARGET_ARCH (Andrew Turner) So, would someone please explain the status of FreeBSD on the BeagleBone Black REV C, does it work now, are there plans to make it work, what is the general timeframe? I would appreciate any feedback. If there are any testing versions available I would be happy to try and report the results and try to help debug. I look forward to hearing your responses. Thanks in advance. Andy From owner-freebsd-arm@FreeBSD.ORG Tue Oct 7 23:41:39 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44FF6457 for ; Tue, 7 Oct 2014 23:41:39 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2223D241 for ; Tue, 7 Oct 2014 23:41:38 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s97NfbAh032209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Oct 2014 16:41:37 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s97NfbgC032208; Tue, 7 Oct 2014 16:41:37 -0700 (PDT) (envelope-from jmg) Date: Tue, 7 Oct 2014 16:41:37 -0700 From: John-Mark Gurney To: Andrew Turner Subject: Re: [RFC] Add and armv7hf TARGET_ARCH Message-ID: <20141007234136.GS1852@funkthat.com> Mail-Followup-To: Andrew Turner , freebsd-arm@freebsd.org References: <20141006134626.59cc5573@bender.lan> <20141006173045.GE1852@funkthat.com> <20141006224124.494267e0@bender.lan> <20141007042430.GH1852@funkthat.com> <20141007094431.09600b56@bender.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141007094431.09600b56@bender.lan> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 07 Oct 2014 16:41:37 -0700 (PDT) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 23:41:39 -0000 Andrew Turner wrote this message on Tue, Oct 07, 2014 at 09:44 +0100: > On Mon, 6 Oct 2014 21:24:30 -0700 > John-Mark Gurney wrote: > > > Andrew Turner wrote this message on Mon, Oct 06, 2014 at 22:41 +0100: > > > On Mon, 6 Oct 2014 10:30:45 -0700 > > > John-Mark Gurney wrote: > > > > > > > Andrew Turner wrote this message on Mon, Oct 06, 2014 at 13:46 > > > > +0100: > > > > > I'm interested in peoples opinion on creating a new TARGET_ARCH > > > > > to target ARMv7 SoCs. This will target all the current Cortex-A > > > > > chips we support but not the Raspberry Pi. My intention with > > > > > this is to have it become the tier 1 arm platform. > > > > > > > > > > This platform will support 32-bit Cortex-A based SoCs with a VFP > > > > > unit. As it would be targeting ARMv7 we could look at supporting > > > > > Thumb-2. > > > > > > > > > > As the VFP unit is optional and future SoCs without it will > > > > > only be supported by the armv6 TARGET_ARCH, however I would > > > > > expect almost all ARMv7 designs to include it. > > > > > > > > So, what are the specific pros of having a new arch? I see you > > > > talk about Thumb-2 support, but are there other advantages? Will > > > > we get significant performance boosts? What? > > > > > > We would get a significant speed improvement for anything that uses > > > floating-point. I haven't done extensive tests, but Ian was getting > > > around 30x-34x improvement by using the vfp on one benchmark [1]. > > > I've seen a sight improvement of around 3-5 MFlops on his numbers > > > on my board. > > > > > > I expect there to be a slight performance improvement from being > > > able to use the newer ARMv7 instructions, however this will be less > > > pronounced than the above floating-point improvement. > > > > > > There are also a number of NEON optimised libc functions we could > > > make use of, for example [2]. While we may be able to use them on > > > armv6 it becomes simpler if we can assume we have a NEON unit. > > > > Don't we already have armv6hf for hardware float? What is the > > difference between armv6hf and armv7hf? or is this 30x-34x > > improvement over armv6hf? > > My plan is to replace the armv6hf with armv7hf. The difference between > the two is, on armv7hf we can assume newer floating-point instructions > including the NEON SIMD instructions. Ahh, ok. this makes more sense then... If we really only loose the RPI, I don't think that it's that big of a loss... Considering how many other boards would get a boost... So, the real move is switching to armv7hf is the new requirement that NEON be present, correct? From my understanding, NEON is common on SoCs now, isn't it? > The performance improvement above was changing from the soft to softfp > ABI. Softfp allows the compiler to generate vfp code, but will pass > floating-point data between functions in the integer registers. > > It has been reported on some cores moving data between the vfp and arm > registers can cause both to stall for at least 20 cycles [1]. While > armv7hf doesn't remove the need to move between groups of registers > completely it will reduce the need due to the calling convention. Yeh, sounds like it's good to move to armv7hf considering the number of platforms... We could possibly leave armv6hf in the tree, but make sure people realize that it's not a "supported" option... So, do you envision armv7hf being the main Tier 1 arm platform? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Wed Oct 8 01:30:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6956F9D5 for ; Wed, 8 Oct 2014 01:30:51 +0000 (UTC) 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 D352DDF7 for ; Wed, 8 Oct 2014 01:30:50 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s9814qfh061439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 8 Oct 2014 03:04:53 +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 s9814bEA076379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Oct 2014 03:04:37 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id s9814bno016146; Wed, 8 Oct 2014 03:04:37 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s9814aWl016145; Wed, 8 Oct 2014 03:04:36 +0200 (CEST) (envelope-from ticso) Date: Wed, 8 Oct 2014 03:04:36 +0200 From: Bernd Walter To: AN Subject: Re: FreeBSD on BeagleBone Black Message-ID: <20141008010436.GA12125@cicely7.cicely.de> Reply-To: ticso@cicely.de References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 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=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 01:30:51 -0000 On Tue, Oct 07, 2014 at 05:05:10PM -0400, AN wrote: > Hi List: > > I have been using FreeBSD current on amd64 for many years. I now have a > project that I want to try to run on FreeBSD. I'm trying to boot a > FreeBSD image on a BeagleBone Black Rev C without success. > > FreeBSD-11.0-CURRENT-arm-armv6-BEAGLEBONE-20140903-r270990.img > FreeBSD-arm-10.0-BEAGLEBONE.img > > The above images fail to boot. Basicly the BBB works very well under FreeBSD. Did you check the uart output? I'm not sure if those images are build with grafic support and there will be nothing on HDMI or attached LCD without it. To be honest: I don't even know if we have support for that output already with the BBB. Most people use the boards with uart console. Unfortunately with the Beaglebone, as well as with many others, the uart is only available as pin header using a 3.3V TTL uart. Most people use USB uarts for that, which are available at many electronic shops these days. At best you should hook up to the console uart to see what's going on. As a workaround you can mount the SD card on your amd64 and setup rc.conf and sshd for your network and ssh to the BBB. But in the end you realy want to have console access if anything goes wrong. Maybe someone else can say something definitive about BBB LCD and HDMI support in FreeBSD. > I saw discussion on the list previously discussing: Re: [RFC] Add and > armv7hf TARGET_ARCH (Andrew Turner) > > So, would someone please explain the status of FreeBSD on the BeagleBone > Black REV C, does it work now, are there plans to make it work, what is > the general timeframe? This is purely about some speed optimization by compiling with features not available on lower ARM cores. Since this changes function call convetions it has to be done that way for every single code, therefor it is a decision at OS installation time. The BBB runs fine with the current state. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Wed Oct 8 03:06:33 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BAED4EC for ; Wed, 8 Oct 2014 03:06:33 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 50B009D0 for ; Wed, 8 Oct 2014 03:06:32 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s9836LV6034237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Oct 2014 20:06:22 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s9836Lco034236; Tue, 7 Oct 2014 20:06:21 -0700 (PDT) (envelope-from jmg) Date: Tue, 7 Oct 2014 20:06:21 -0700 From: John-Mark Gurney To: ticso@cicely.de Subject: Re: FreeBSD on BeagleBone Black Message-ID: <20141008030621.GU1852@funkthat.com> Mail-Followup-To: ticso@cicely.de, AN , freebsd-arm@freebsd.org References: <20141008010436.GA12125@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141008010436.GA12125@cicely7.cicely.de> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 07 Oct 2014 20:06:22 -0700 (PDT) Cc: freebsd-arm@freebsd.org, AN X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 03:06:33 -0000 Bernd Walter wrote this message on Wed, Oct 08, 2014 at 03:04 +0200: > On Tue, Oct 07, 2014 at 05:05:10PM -0400, AN wrote: > > Hi List: > > > > I have been using FreeBSD current on amd64 for many years. I now have a > > project that I want to try to run on FreeBSD. I'm trying to boot a > > FreeBSD image on a BeagleBone Black Rev C without success. > > > > FreeBSD-11.0-CURRENT-arm-armv6-BEAGLEBONE-20140903-r270990.img > > FreeBSD-arm-10.0-BEAGLEBONE.img > > > > The above images fail to boot. > > Basicly the BBB works very well under FreeBSD. > Did you check the uart output? > I'm not sure if those images are build with grafic support and > there will be nothing on HDMI or attached LCD without it. > To be honest: I don't even know if we have support for that output > already with the BBB. We definately do not support output on HDMI... I'm trying to get the datasheet so I can get HDMI output working... > Most people use the boards with uart console. > Unfortunately with the Beaglebone, as well as with many others, > the uart is only available as pin header using a 3.3V TTL uart. > Most people use USB uarts for that, which are available at many > electronic shops these days. The original BeagleBone White has an onboard USB<->uart chip which didn't require an extra cable... > At best you should hook up to the console uart to see what's going > on. > As a workaround you can mount the SD card on your amd64 and setup > rc.conf and sshd for your network and ssh to the BBB. > But in the end you realy want to have console access if anything goes > wrong. > Maybe someone else can say something definitive about BBB LCD and HDMI > support in FreeBSD. > > > I saw discussion on the list previously discussing: Re: [RFC] Add and > > armv7hf TARGET_ARCH (Andrew Turner) > > > > So, would someone please explain the status of FreeBSD on the BeagleBone > > Black REV C, does it work now, are there plans to make it work, what is > > the general timeframe? > > This is purely about some speed optimization by compiling with features > not available on lower ARM cores. > Since this changes function call convetions it has to be done that way > for every single code, therefor it is a decision at OS installation time. > The BBB runs fine with the current state. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Wed Oct 8 04:07:36 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 350CFC51 for ; Wed, 8 Oct 2014 04:07:36 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB0DFEB4 for ; Wed, 8 Oct 2014 04:07:35 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id b6so7344998lbj.17 for ; Tue, 07 Oct 2014 21:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OaUWo5ilFTbFdw5LDC1YNlE0AtlUIpDTkKX9TcS7RM0=; b=VaZlXr7mSf0O7T010H1tsIkMjI9B8KF5VS0BhoQAYVHEcwR8ovm2WEUluFoCXBVi2r rLliPY2M++8d5nenNiA2pyc/wo7bqpW56iNCDpLONyflVomBo2DL4/d99w6h9y+mcaFd nD+ygL4ayBOEyK434w6p1V57PThb2yOBRbmy4LZ3DibjlmzDS4O6q4CZC0ZFRkaGbr5H ZMpaypNXJN3+vDi2kFdc9bt7mUF9G9vJOw65isS/9jNtUdC9+xepAw76S3Rt6Iy0qrxd 5mgEh4PFgKMY0JfDTYcOGt47JqjPgKN5uaigjXRwBK7ZiAbVhU39j0Bkl2zdhqn0o81b 3DEA== MIME-Version: 1.0 X-Received: by 10.112.52.165 with SMTP id u5mr7967506lbo.80.1412741253642; Tue, 07 Oct 2014 21:07:33 -0700 (PDT) Received: by 10.112.126.39 with HTTP; Tue, 7 Oct 2014 21:07:33 -0700 (PDT) In-Reply-To: <20141008030621.GU1852@funkthat.com> References: <20141008010436.GA12125@cicely7.cicely.de> <20141008030621.GU1852@funkthat.com> Date: Wed, 8 Oct 2014 01:07:33 -0300 Message-ID: Subject: Re: FreeBSD on BeagleBone Black From: Luiz Otavio O Souza To: ticso@cicely.de, AN , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 04:07:36 -0000 On 8 October 2014 00:06, John-Mark Gurney wrote: > Bernd Walter wrote this message on Wed, Oct 08, 2014 at 03:04 +0200: >> On Tue, Oct 07, 2014 at 05:05:10PM -0400, AN wrote: >> > Hi List: >> > >> > I have been using FreeBSD current on amd64 for many years. I now have a >> > project that I want to try to run on FreeBSD. I'm trying to boot a >> > FreeBSD image on a BeagleBone Black Rev C without success. >> > >> > FreeBSD-11.0-CURRENT-arm-armv6-BEAGLEBONE-20140903-r270990.img >> > FreeBSD-arm-10.0-BEAGLEBONE.img >> > >> > The above images fail to boot. >> >> Basicly the BBB works very well under FreeBSD. >> Did you check the uart output? >> I'm not sure if those images are build with grafic support and >> there will be nothing on HDMI or attached LCD without it. >> To be honest: I don't even know if we have support for that output >> already with the BBB. > > We definately do not support output on HDMI... I'm trying to get the > datasheet so I can get HDMI output working... Please, see: https://lists.freebsd.org/pipermail/freebsd-arm/2014-March/007822.html Gonzo did the LCD driver (which feed data into HDMI framer) and tried to port the TDA19988 HDMI framer driver. I've fixed the i2c controller issues on -head so you can skip that part from gonzo's patch. I also see some GPIO pins on schematics (like GPIO0_19 and GPIO1_27 on page 3) which may need to be set for the HDMI support and i did not check the gonzo's code to verify if they are properly set. Luiz From owner-freebsd-arm@FreeBSD.ORG Wed Oct 8 05:35:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A9DC21C for ; Wed, 8 Oct 2014 05:35:03 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5DD848DC for ; Wed, 8 Oct 2014 05:35:02 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s985YqRM035605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Oct 2014 22:34:52 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s985Yp6r035604; Tue, 7 Oct 2014 22:34:51 -0700 (PDT) (envelope-from jmg) Date: Tue, 7 Oct 2014 22:34:51 -0700 From: John-Mark Gurney To: Luiz Otavio O Souza Subject: Re: FreeBSD on BeagleBone Black Message-ID: <20141008053451.GV1852@funkthat.com> Mail-Followup-To: Luiz Otavio O Souza , ticso@cicely.de, AN , "freebsd-arm@freebsd.org" References: <20141008010436.GA12125@cicely7.cicely.de> <20141008030621.GU1852@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 07 Oct 2014 22:34:53 -0700 (PDT) Cc: "freebsd-arm@freebsd.org" , AN , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 05:35:03 -0000 Luiz Otavio O Souza wrote this message on Wed, Oct 08, 2014 at 01:07 -0300: > On 8 October 2014 00:06, John-Mark Gurney wrote: > > Bernd Walter wrote this message on Wed, Oct 08, 2014 at 03:04 +0200: > >> On Tue, Oct 07, 2014 at 05:05:10PM -0400, AN wrote: > >> > Hi List: > >> > > >> > I have been using FreeBSD current on amd64 for many years. I now have a > >> > project that I want to try to run on FreeBSD. I'm trying to boot a > >> > FreeBSD image on a BeagleBone Black Rev C without success. > >> > > >> > FreeBSD-11.0-CURRENT-arm-armv6-BEAGLEBONE-20140903-r270990.img > >> > FreeBSD-arm-10.0-BEAGLEBONE.img > >> > > >> > The above images fail to boot. > >> > >> Basicly the BBB works very well under FreeBSD. > >> Did you check the uart output? > >> I'm not sure if those images are build with grafic support and > >> there will be nothing on HDMI or attached LCD without it. > >> To be honest: I don't even know if we have support for that output > >> already with the BBB. > > > > We definately do not support output on HDMI... I'm trying to get the > > datasheet so I can get HDMI output working... > > Please, see: https://lists.freebsd.org/pipermail/freebsd-arm/2014-March/007822.html > > Gonzo did the LCD driver (which feed data into HDMI framer) and tried > to port the TDA19988 HDMI framer driver. Yeh, I got patches from him recently for this, but he said he was still having issues... I'm waiting for the Foundation to get a proper spec sheet from NXP for the TDA19988... I really don't like working blind.. > I've fixed the i2c controller issues on -head so you can skip that > part from gonzo's patch. Cool, thanks for the help.... > I also see some GPIO pins on schematics (like GPIO0_19 and GPIO1_27 on > page 3) which may need to be set for the HDMI support and i did not > check the gonzo's code to verify if they are properly set. Yeh, GPIO1_27 is the one that enables the clock to the HDMI chip and when I was looking over his patch, I didn't see anything for enabling it... This is mentioned in the SRM... Looks like GPIO0_19 isn't necessary as that is the clock for CEC, and we don't need that till later (say use the TV remote as an input device)... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Wed Oct 8 14:00:36 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5DD09C4 for ; Wed, 8 Oct 2014 14:00:36 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5210A25E for ; Wed, 8 Oct 2014 14:00:36 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id m15so11819776wgh.16 for ; Wed, 08 Oct 2014 07:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=RhaXr9/v+1JMsN4deEGxbKowJcDCAq50+nHiQJkM524=; b=HUnagwU+9bGcmI/N4vYTpjqm5SRc2fUgVs6vIk4xYvTVyjlYia0uOHWCDgoB80UgGt 8uz70yTivQ6oLKDqHCxi1acUsJzYtcY2ngNQdcqedFH7sN3Fs2QcNgsaCkYltW1Eys5Q DG0275UJ9Of4z+K6sqHEZiNJIVsZVWMMdDILYqtD33O2W2V4wAR4bTFqMiusFgVWRBoS R1gcvaTN2esbDMfo8eQ/pd2INJQb9/xrBL1barJ8appJC3rx7+PsQFqtSKa8jtvMoBkK Z0mMHWTxZU6MTC5jOGbvT9yKpa5r4SYi8nHXi1mZpGvcVtm+b9MKAVJhvI7VZuJ4MZP6 GVJw== X-Received: by 10.194.236.102 with SMTP id ut6mr11453759wjc.19.1412776834403; Wed, 08 Oct 2014 07:00:34 -0700 (PDT) Received: from ketas-laptop.mydomain (ketas-laptop6.si.pri.ee. [2001:ad0:91f:0:21a:6bff:fe66:2ad3]) by mx.google.com with ESMTPSA id dc9sm18653693wib.5.2014.10.08.07.00.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Oct 2014 07:00:32 -0700 (PDT) Sender: Sulev-Madis Silber Message-ID: <5435437B.4090803@hot.ee> Date: Wed, 08 Oct 2014 17:00:27 +0300 From: "Sulev-Madis Silber (ketas)" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Luiz Otavio O Souza , ticso@cicely.de, AN , "freebsd-arm@freebsd.org" Subject: Re: FreeBSD on BeagleBone Black References: <20141008010436.GA12125@cicely7.cicely.de> <20141008030621.GU1852@funkthat.com> <20141008053451.GV1852@funkthat.com> In-Reply-To: <20141008053451.GV1852@funkthat.com> X-TagToolbar-Keys: D20141008170026154 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 14:00:37 -0000 On 2014-10-08 08:34, John-Mark Gurney wrote: > Luiz Otavio O Souza wrote this message on Wed, Oct 08, 2014 at 01:07 -0300: >> On 8 October 2014 00:06, John-Mark Gurney wrote: >>> Bernd Walter wrote this message on Wed, Oct 08, 2014 at 03:04 +0200: >>>> On Tue, Oct 07, 2014 at 05:05:10PM -0400, AN wrote: >>>>> Hi List: >>>>> >>>>> I have been using FreeBSD current on amd64 for many years. I now have a >>>>> project that I want to try to run on FreeBSD. I'm trying to boot a >>>>> FreeBSD image on a BeagleBone Black Rev C without success. >>>>> >>>>> FreeBSD-11.0-CURRENT-arm-armv6-BEAGLEBONE-20140903-r270990.img >>>>> FreeBSD-arm-10.0-BEAGLEBONE.img >>>>> >>>>> The above images fail to boot. >>>> >>>> Basicly the BBB works very well under FreeBSD. >>>> Did you check the uart output? >>>> I'm not sure if those images are build with grafic support and >>>> there will be nothing on HDMI or attached LCD without it. >>>> To be honest: I don't even know if we have support for that output >>>> already with the BBB. >>> >>> We definately do not support output on HDMI... I'm trying to get the >>> datasheet so I can get HDMI output working... >> >> Please, see: https://lists.freebsd.org/pipermail/freebsd-arm/2014-March/007822.html >> >> Gonzo did the LCD driver (which feed data into HDMI framer) and tried >> to port the TDA19988 HDMI framer driver. > > Yeh, I got patches from him recently for this, but he said he was still > having issues... I'm waiting for the Foundation to get a proper spec > sheet from NXP for the TDA19988... I really don't like working blind.. > >> I've fixed the i2c controller issues on -head so you can skip that >> part from gonzo's patch. > > Cool, thanks for the help.... > >> I also see some GPIO pins on schematics (like GPIO0_19 and GPIO1_27 on >> page 3) which may need to be set for the HDMI support and i did not >> check the gonzo's code to verify if they are properly set. > > Yeh, GPIO1_27 is the one that enables the clock to the HDMI chip and > when I was looking over his patch, I didn't see anything for enabling > it... This is mentioned in the SRM... > > Looks like GPIO0_19 isn't necessary as that is the clock for CEC, > and we don't need that till later (say use the TV remote as an input > device)... > Oh, I would like to get HDMI working. I know LCD should work somewhat, showing console. I never looked what does it take to get X or even non-X graphics working. But BBB definitely works. CPU runs at 1GHz, board boots from eMMC. Ethernet, ADC, GPIO, I2C, UART works. There are few glitches related to booting. Maybe some others. And I don't deny that you need certain amount of hackerness to use it right now. From owner-freebsd-arm@FreeBSD.ORG Wed Oct 8 15:02:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70ECFE3F for ; Wed, 8 Oct 2014 15:02:22 +0000 (UTC) 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 C7249BF9 for ; Wed, 8 Oct 2014 15:02:21 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s98F1wHW073101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 8 Oct 2014 17:01: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 s98F1qbC082943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Oct 2014 17:01:52 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id s98F1qe6019633; Wed, 8 Oct 2014 17:01:52 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s98F1q3X019632; Wed, 8 Oct 2014 17:01:52 +0200 (CEST) (envelope-from ticso) Date: Wed, 8 Oct 2014 17:01:51 +0200 From: Bernd Walter To: Luiz Otavio O Souza , ticso@cicely.de, AN , "freebsd-arm@freebsd.org" Subject: Re: FreeBSD on BeagleBone Black Message-ID: <20141008150151.GA19131@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20141008010436.GA12125@cicely7.cicely.de> <20141008030621.GU1852@funkthat.com> <20141008053451.GV1852@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141008053451.GV1852@funkthat.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 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.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 15:02:22 -0000 On Tue, Oct 07, 2014 at 10:34:51PM -0700, John-Mark Gurney wrote: > Luiz Otavio O Souza wrote this message on Wed, Oct 08, 2014 at 01:07 -0300: > > On 8 October 2014 00:06, John-Mark Gurney wrote: > > > Bernd Walter wrote this message on Wed, Oct 08, 2014 at 03:04 +0200: > > >> On Tue, Oct 07, 2014 at 05:05:10PM -0400, AN wrote: > > >> > Hi List: > > >> > > > >> > I have been using FreeBSD current on amd64 for many years. I now have a > > >> > project that I want to try to run on FreeBSD. I'm trying to boot a > > >> > FreeBSD image on a BeagleBone Black Rev C without success. > > >> > > > >> > FreeBSD-11.0-CURRENT-arm-armv6-BEAGLEBONE-20140903-r270990.img > > >> > FreeBSD-arm-10.0-BEAGLEBONE.img > > >> > > > >> > The above images fail to boot. > > >> > > >> Basicly the BBB works very well under FreeBSD. > > >> Did you check the uart output? > > >> I'm not sure if those images are build with grafic support and > > >> there will be nothing on HDMI or attached LCD without it. > > >> To be honest: I don't even know if we have support for that output > > >> already with the BBB. > > > > > > We definately do not support output on HDMI... I'm trying to get the > > > datasheet so I can get HDMI output working... > > > > Please, see: https://lists.freebsd.org/pipermail/freebsd-arm/2014-March/007822.html > > > > Gonzo did the LCD driver (which feed data into HDMI framer) and tried > > to port the TDA19988 HDMI framer driver. > > Yeh, I got patches from him recently for this, but he said he was still > having issues... I'm waiting for the Foundation to get a proper spec > sheet from NXP for the TDA19988... I really don't like working blind.. Wasn't aware there is an NXP chip used, but I'm not surprised about the datasheet completeness :-( A quick look into the TDA19988 datasheet seems to leave out many programming details. This already had been a problem when they were named Philips. Wouldn't be surprised if there is a separate programming PDF. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Wed Oct 8 15:56:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75679868 for ; Wed, 8 Oct 2014 15:56:46 +0000 (UTC) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4199B27B for ; Wed, 8 Oct 2014 15:56:45 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id eu11so9314736pac.14 for ; Wed, 08 Oct 2014 08:56:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=p3BrMFlteyzxzqGwYJFxABvTjtfKYRQLaX3y+ESpnr4=; b=Mz8Z9MFfGDl5B9tJTzQll4E6M59wlwxSquseNGws2zTvMO4Zb0WA16rLkyrjPkGas2 JyEEKQareT4RawDGgaLHD+M9XEJ0raqtNjY1BTNswj9hpvtdId2im1bjO0t82rAbeWIK Fv13fTWXZBVytFSHta8Sk+jN1QAJ0a249xHqhz4YtNu6d0TfB7GDD2nV+zKvubUEB9dS +7q2Cl3c3AUW1t3FdN+MCNq7BKd/YfyTay3ONOL329tqoHpsyylxtYhomFPbOPu3y3nd ypQWb6L7fXJU/hcz/iHvHfoVwYBKRdbkQfWMUFZ0+1vgjoSIhjILPzUiFiTbzTs2ndFJ 6byA== X-Gm-Message-State: ALoCoQngOkcmEtEeWhdCK3qC+t/JoIgUl/MyVvr49TdJcOPM5GKqzPcZsAqPBrxvN90ra+M/WhpR X-Received: by 10.66.141.165 with SMTP id rp5mr11507173pab.115.1412782087219; Wed, 08 Oct 2014 08:28:07 -0700 (PDT) Received: from [10.64.26.130] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id qn11sm1401419pdb.1.2014.10.08.08.28.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Oct 2014 08:28:06 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_BBA02A9D-6D8E-4B80-950D-5F5D25EC6E44"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [RFC] Add and armv7hf TARGET_ARCH From: Warner Losh In-Reply-To: <20141007234136.GS1852@funkthat.com> Date: Wed, 8 Oct 2014 09:28:03 -0600 Message-Id: <66C40BCC-C829-4540-A19E-C9EFA64191F6@bsdimp.com> References: <20141006134626.59cc5573@bender.lan> <20141006173045.GE1852@funkthat.com> <20141006224124.494267e0@bender.lan> <20141007042430.GH1852@funkthat.com> <20141007094431.09600b56@bender.lan> <20141007234136.GS1852@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 15:56:46 -0000 --Apple-Mail=_BBA02A9D-6D8E-4B80-950D-5F5D25EC6E44 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 7, 2014, at 5:41 PM, John-Mark Gurney wrote: > Andrew Turner wrote this message on Tue, Oct 07, 2014 at 09:44 +0100: >> On Mon, 6 Oct 2014 21:24:30 -0700 >> John-Mark Gurney wrote: >>=20 >>> Andrew Turner wrote this message on Mon, Oct 06, 2014 at 22:41 = +0100: >>>> On Mon, 6 Oct 2014 10:30:45 -0700 >>>> John-Mark Gurney wrote: >>>>=20 >>>>> Andrew Turner wrote this message on Mon, Oct 06, 2014 at 13:46 >>>>> +0100: >>>>>> I'm interested in peoples opinion on creating a new TARGET_ARCH >>>>>> to target ARMv7 SoCs. This will target all the current Cortex-A >>>>>> chips we support but not the Raspberry Pi. My intention with >>>>>> this is to have it become the tier 1 arm platform. >>>>>>=20 >>>>>> This platform will support 32-bit Cortex-A based SoCs with a VFP >>>>>> unit. As it would be targeting ARMv7 we could look at supporting >>>>>> Thumb-2. >>>>>>=20 >>>>>> As the VFP unit is optional and future SoCs without it will >>>>>> only be supported by the armv6 TARGET_ARCH, however I would >>>>>> expect almost all ARMv7 designs to include it. >>>>>=20 >>>>> So, what are the specific pros of having a new arch? I see you >>>>> talk about Thumb-2 support, but are there other advantages? Will >>>>> we get significant performance boosts? What? >>>>=20 >>>> We would get a significant speed improvement for anything that uses >>>> floating-point. I haven't done extensive tests, but Ian was getting >>>> around 30x-34x improvement by using the vfp on one benchmark [1]. >>>> I've seen a sight improvement of around 3-5 MFlops on his numbers >>>> on my board. >>>>=20 >>>> I expect there to be a slight performance improvement from being >>>> able to use the newer ARMv7 instructions, however this will be less >>>> pronounced than the above floating-point improvement. >>>>=20 >>>> There are also a number of NEON optimised libc functions we could >>>> make use of, for example [2]. While we may be able to use them on >>>> armv6 it becomes simpler if we can assume we have a NEON unit. >>>=20 >>> Don't we already have armv6hf for hardware float? What is the >>> difference between armv6hf and armv7hf? or is this 30x-34x >>> improvement over armv6hf? >>=20 >> My plan is to replace the armv6hf with armv7hf. The difference = between >> the two is, on armv7hf we can assume newer floating-point = instructions >> including the NEON SIMD instructions. >=20 > Ahh, ok. this makes more sense then... If we really only loose the > RPI, I don't think that it's that big of a loss... Considering how > many other boards would get a boost.. But the RPi is arguably our best supported platform on ARM ATM. > So, the real move is switching to armv7hf is the new requirement that > NEON be present, correct? =46rom my understanding, NEON is common on > SoCs now, isn't it? The more I=92ve thought about it, the more we need to seriously consider = treating this as a MACHINE_CPUTYPE rather than a MACHINE_ARCH. Unless there=92s a really really compelling win from the NEON architecture, in general, = we should consider doing this like we did i486 vs i686 for years on the i386 = platform. Users can build for higher models, and use newer instructions on those models, = but the base retained compatibility. There=92s no difference between the = current armv6hf and your proposed armv7hf except for allowing a few additional = instructions to be used. There=92s no calling differences, there=92s nothing apart from = using NEON (unless I=92ve missed something). This seems completely analogous to the = MMX instructions before. >> The performance improvement above was changing from the soft to = softfp >> ABI. Softfp allows the compiler to generate vfp code, but will pass >> floating-point data between functions in the integer registers. >>=20 >> It has been reported on some cores moving data between the vfp and = arm >> registers can cause both to stall for at least 20 cycles [1]. While >> armv7hf doesn't remove the need to move between groups of registers >> completely it will reduce the need due to the calling convention. >=20 > Yeh, sounds like it's good to move to armv7hf considering the number = of > platforms... We could possibly leave armv6hf in the tree, but make > sure people realize that it's not a "supported" option... >=20 > So, do you envision armv7hf being the main Tier 1 arm platform? I think the separate MACHINE_ARCH isn=92t the way to go. I would support creating the proper CPUTYPE here. I might support the v7 variant being the default if there was a big enough win, since having the v6 variant = default would let RPi folks get hard float by default (and I just checked: the = RPi does support hard float, just not the latest NEON stuff v7 does). Coments? Warner --Apple-Mail=_BBA02A9D-6D8E-4B80-950D-5F5D25EC6E44 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUNVgDAAoJEGwc0Sh9sBEAKyYQANYMbQlissjIetK8jroaFTc/ sMDPvTAB0qfAf1wEjXMei5dFhjfpC99LfM0bijcOWheswvBGxlyyVIUfl2kYIm0J Dh8b7MiHTzGN5XVCsPzVSlbQuXjRYHx9ZEDDHuiaZMXWVv0cProXkmpwmoZ+c6cU mKQoSha3QtHahmgy+UoRkIWuYIYDo1f+5lOkGeJoQemDoNHqo00GcjPFxnseHo3S nVVueP4HLNqRLW53IC6aFZbojsabLR8OotJGea9diIPeY4Oz1axjlv4FIyB/f6Na PRde47cDhDnICALnYRnbm2IutAXQXKHX2uEVxjdUlmqLTnxh8fJerayyYOXa/tvE MQRygctECqlw6MIduejH6AsF2Y9zBTHaIOZFjRNedgZkxXk4daAdeyIsWP3OZg6R 2X1bFspWpiaw9zSa9A+9cUbE7CnPDEPhEpYN1vrMppQYvxoxnqqEakMXU1HZtFsz bWatQOxtVgnYuYq06Z16UHXec+i3yBGoScMO4r+BtfDNyZTAvhW6D3kmRafE+Rot wyOsHRYhLgEjXgT+fGZs/YH/rt9GqN8hs1fGXZ+wWkopRYBa0SdXGStP1MP7J5xG wbTqId1zbWeh8ehOOZkObScw/R90YpO6WKo21Z3Nn6XeN0K9vOVF47dTa4s/0OrA P52tTe9NFgOkTQodwtMf =mQU9 -----END PGP SIGNATURE----- --Apple-Mail=_BBA02A9D-6D8E-4B80-950D-5F5D25EC6E44-- From owner-freebsd-arm@FreeBSD.ORG Wed Oct 8 17:43:31 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D1B7252 for ; Wed, 8 Oct 2014 17:43:31 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7284140 for ; Wed, 8 Oct 2014 17:43:30 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id q1so8988232lam.32 for ; Wed, 08 Oct 2014 10:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zmdkQcwXxbGLKmeWI7bC710DyfpoMyV1VJrfXryyCFw=; b=cRmiWGxLJiHt3TwPAnth9Cb4606cUwoy3URfOyH5FCQfw7+V6KMsPLizcjKn3hzmbK iF5NoSTVdH39tmaG1X9awo8X+cWiKuqrPbIy6/84RdgBrFZcvAOiOtCYbhro7IFHWRQM By+QwC8Oc8/Z76C1YCNMq+OgKp8qpW6Vsd8GeKDULiHG4yLSISEmJlZ4AYXcK4KIs/ig IeC6OrAh2GfkWg9pPcneuv4QLLZCTf2qyD++P4QOAJ3d/RX6xnztIQxREHcvF6YBXSFz TmnIW3KUaEPZJaupy8gk7lGPfOfx4glXLxow/LNxEVV/cdONQd59HFWTZZDPPH0CKE/B /ouA== MIME-Version: 1.0 X-Received: by 10.152.5.40 with SMTP id p8mr13231083lap.32.1412790208664; Wed, 08 Oct 2014 10:43:28 -0700 (PDT) Received: by 10.112.126.39 with HTTP; Wed, 8 Oct 2014 10:43:28 -0700 (PDT) In-Reply-To: <20141008053451.GV1852@funkthat.com> References: <20141008010436.GA12125@cicely7.cicely.de> <20141008030621.GU1852@funkthat.com> <20141008053451.GV1852@funkthat.com> Date: Wed, 8 Oct 2014 14:43:28 -0300 Message-ID: Subject: Re: FreeBSD on BeagleBone Black From: Luiz Otavio O Souza To: Luiz Otavio O Souza , ticso@cicely.de, AN , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 17:43:31 -0000 On 8 October 2014 02:34, John-Mark Gurney wrote: > Luiz Otavio O Souza wrote this message on Wed, Oct 08, 2014 at 01:07 -0300: > [...] >> I also see some GPIO pins on schematics (like GPIO0_19 and GPIO1_27 on >> page 3) which may need to be set for the HDMI support and i did not >> check the gonzo's code to verify if they are properly set. > > Yeh, GPIO1_27 is the one that enables the clock to the HDMI chip and > when I was looking over his patch, I didn't see anything for enabling > it... This is mentioned in the SRM... > > Looks like GPIO0_19 isn't necessary as that is the clock for CEC, > and we don't need that till later (say use the TV remote as an input > device)... Well, you'll find that the BBB documentation is... confusing... GPIO1_27 enable the 24.576MHz clock used on McASP (multichannel audio serial port). This clock is connected back to GPIO3_21 (McASP clock input). It can be disabled to allow the use of GPIO3_21, to reduce the power drain or to allow an external McASP clock. GPIO0_19 enable the 12MHz clock which is actually used by TDA19988. I hope it make sense. /me looking forward for the HDMI support (and then, audio ?!? :) Luiz From owner-freebsd-arm@FreeBSD.ORG Wed Oct 8 17:47:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A6034C5 for ; Wed, 8 Oct 2014 17:47:15 +0000 (UTC) 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 8C366189 for ; Wed, 8 Oct 2014 17:47:14 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s98HkmiD074367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 8 Oct 2014 19:46:48 +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 s98Hkhqb084224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Oct 2014 19:46:43 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id s98HkhYc020317; Wed, 8 Oct 2014 19:46:43 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s98Hkg2A020316; Wed, 8 Oct 2014 19:46:42 +0200 (CEST) (envelope-from ticso) Date: Wed, 8 Oct 2014 19:46:42 +0200 From: Bernd Walter To: Warner Losh Subject: Re: [RFC] Add and armv7hf TARGET_ARCH Message-ID: <20141008174642.GA19893@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20141006134626.59cc5573@bender.lan> <20141006173045.GE1852@funkthat.com> <20141006224124.494267e0@bender.lan> <20141007042430.GH1852@funkthat.com> <20141007094431.09600b56@bender.lan> <20141007234136.GS1852@funkthat.com> <66C40BCC-C829-4540-A19E-C9EFA64191F6@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66C40BCC-C829-4540-A19E-C9EFA64191F6@bsdimp.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 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 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 17:47:15 -0000 On Wed, Oct 08, 2014 at 09:28:03AM -0600, Warner Losh wrote: > > On Oct 7, 2014, at 5:41 PM, John-Mark Gurney wrote: > > > Andrew Turner wrote this message on Tue, Oct 07, 2014 at 09:44 +0100: > >> On Mon, 6 Oct 2014 21:24:30 -0700 > >> John-Mark Gurney wrote: > >> > >>> Andrew Turner wrote this message on Mon, Oct 06, 2014 at 22:41 +0100: > >>>> On Mon, 6 Oct 2014 10:30:45 -0700 > >>>> John-Mark Gurney wrote: > >>>> > >>>>> Andrew Turner wrote this message on Mon, Oct 06, 2014 at 13:46 > >>>>> +0100: > >>>>>> I'm interested in peoples opinion on creating a new TARGET_ARCH > >>>>>> to target ARMv7 SoCs. This will target all the current Cortex-A > >>>>>> chips we support but not the Raspberry Pi. My intention with > >>>>>> this is to have it become the tier 1 arm platform. > >>>>>> > >>>>>> This platform will support 32-bit Cortex-A based SoCs with a VFP > >>>>>> unit. As it would be targeting ARMv7 we could look at supporting > >>>>>> Thumb-2. > >>>>>> > >>>>>> As the VFP unit is optional and future SoCs without it will > >>>>>> only be supported by the armv6 TARGET_ARCH, however I would > >>>>>> expect almost all ARMv7 designs to include it. > >>>>> > >>>>> So, what are the specific pros of having a new arch? I see you > >>>>> talk about Thumb-2 support, but are there other advantages? Will > >>>>> we get significant performance boosts? What? > >>>> > >>>> We would get a significant speed improvement for anything that uses > >>>> floating-point. I haven't done extensive tests, but Ian was getting > >>>> around 30x-34x improvement by using the vfp on one benchmark [1]. > >>>> I've seen a sight improvement of around 3-5 MFlops on his numbers > >>>> on my board. > >>>> > >>>> I expect there to be a slight performance improvement from being > >>>> able to use the newer ARMv7 instructions, however this will be less > >>>> pronounced than the above floating-point improvement. > >>>> > >>>> There are also a number of NEON optimised libc functions we could > >>>> make use of, for example [2]. While we may be able to use them on > >>>> armv6 it becomes simpler if we can assume we have a NEON unit. > >>> > >>> Don't we already have armv6hf for hardware float? What is the > >>> difference between armv6hf and armv7hf? or is this 30x-34x > >>> improvement over armv6hf? > >> > >> My plan is to replace the armv6hf with armv7hf. The difference between > >> the two is, on armv7hf we can assume newer floating-point instructions > >> including the NEON SIMD instructions. > > > > Ahh, ok. this makes more sense then... If we really only loose the > > RPI, I don't think that it's that big of a loss... Considering how > > many other boards would get a boost.. > > But the RPi is arguably our best supported platform on ARM ATM. The BBB and Wandboard works much better for me. Granted: there is HDMI support for the RPi, but then the pro section ends. Last time I tried the RPi is still was picky about the SD cards used. And it had problems with my test-LCD resolution not being a plain HDMI resolution, which Linux hadn't. I will surely retry it in a few weeks and I also have a few B+ boards to test. Nevertheless I also have some Hummingboards to test and I like the iMX6 way more. But having packages for the RPi a requirement for mainstream users, since it is a very popular platform. > > So, the real move is switching to armv7hf is the new requirement that > > NEON be present, correct? From my understanding, NEON is common on > > SoCs now, isn't it? > > The more I?ve thought about it, the more we need to seriously consider treating > this as a MACHINE_CPUTYPE rather than a MACHINE_ARCH. Unless there?s > a really really compelling win from the NEON architecture, in general, we should > consider doing this like we did i486 vs i686 for years on the i386 platform. Users > can build for higher models, and use newer instructions on those models, but > the base retained compatibility. There?s no difference between the current armv6hf > and your proposed armv7hf except for allowing a few additional instructions to > be used. There?s no calling differences, there?s nothing apart from using NEON > (unless I?ve missed something). This seems completely analogous to the MMX > instructions before. My understanding is that NEON shouldn't be a problem as CPU_TYPE. But the big winner is the different function call semantic for floatingpoint. > >> The performance improvement above was changing from the soft to softfp > >> ABI. Softfp allows the compiler to generate vfp code, but will pass > >> floating-point data between functions in the integer registers. > >> > >> It has been reported on some cores moving data between the vfp and arm > >> registers can cause both to stall for at least 20 cycles [1]. While > >> armv7hf doesn't remove the need to move between groups of registers > >> completely it will reduce the need due to the calling convention. > > > > Yeh, sounds like it's good to move to armv7hf considering the number of > > platforms... We could possibly leave armv6hf in the tree, but make > > sure people realize that it's not a "supported" option... > > > > So, do you envision armv7hf being the main Tier 1 arm platform? > > I think the separate MACHINE_ARCH isn?t the way to go. I would support > creating the proper CPUTYPE here. I might support the v7 variant being > the default if there was a big enough win, since having the v6 variant default > would let RPi folks get hard float by default (and I just checked: the RPi does > support hard float, just not the latest NEON stuff v7 does). -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Wed Oct 8 19:25:38 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D6C2EE1 for ; Wed, 8 Oct 2014 19:25:38 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 357ABE42 for ; Wed, 8 Oct 2014 19:25:38 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s98JPco6005854 for ; Wed, 8 Oct 2014 19:25:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 194251] New: Efika MX Smartbook (imx51) WiFi does not work anymore Date: Wed, 08 Oct 2014 19:25:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: yom@iaelu.net X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:25:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194251 Bug ID: 194251 Summary: Efika MX Smartbook (imx51) WiFi does not work anymore Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: yom@iaelu.net I had compiled a 11-CURRENT FreeBSD for Efika MX during August 2014, and most things and especially the Wireless Network Interface was working nice at that time. I've just compiled a new pull of 11-CURRENT for the same hardware and have installed it, and now the WiFi does not work anymore. It was using the if_run driver. But even if I load the driver, nothing happens at all. I can see that during september 2014 there were some refactor of the imx IOMUX code in the sys/arm/freescale/imx tree and I'm thinking it may be linked to that. It seems the commiter is 'ian'. Could someone look into this please ? I'd like my Efika MX Smartbook not to become useless :) -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Thu Oct 9 02:46:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DABC3559 for ; Thu, 9 Oct 2014 02:46:12 +0000 (UTC) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A1FE7263 for ; Thu, 9 Oct 2014 02:46:12 +0000 (UTC) Received: by mail-oi0-f47.google.com with SMTP id a141so830967oig.20 for ; Wed, 08 Oct 2014 19:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=C2+xPJ73i9MnkEH1cBoe06BRpoDw0uSe9lVLR5P7TBw=; b=XtZeRc1ENwbAWXhNHL/QKjCTCbPjszjHPxJIJwxAQlBwGv1+FOaXHSbah91S6UUMQb 3n2W8QjCV9yT44eqLLeO47lercoAkWZd2lrd9O2NlzuCNmC/CpTwP7TK8njaHN+GiZg2 wFkzAVSRY3pTxtyE7nd3Whts52TVlYdhTLGXKBOgVe9Y1TqIaK04UczLkv7QqZEIggQm 9oJPKHiA4F2QysFLoVDF1t7GVThBzyRzgbwCzjrn0dzg7rLk2o1IBIGsCDJd6ylJa+yk JxHIILxN15mYMBSxa3E4zlR/+WEodBlmcatvDkeK+EOwK2LNox0V62t07uoCfTcq0T8i 2+vw== X-Received: by 10.60.158.199 with SMTP id ww7mr16875846oeb.76.1412822772017; Wed, 08 Oct 2014 19:46:12 -0700 (PDT) Received: from [172.30.1.14] ([112.168.75.52]) by mx.google.com with ESMTPSA id ix8sm1808350obc.11.2014.10.08.19.46.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Oct 2014 19:46:11 -0700 (PDT) Message-ID: <5435F6EB.1080605@gmail.com> Date: Thu, 09 Oct 2014 11:46:03 +0900 From: Jaemin Yoo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Andrew Turner Subject: Re: Q: linking method for armv8 kernel build References: <5432A1B5.30406@gmail.com> <20141006154314.1b909772@bender.lan> <5433DD2E.1050807@gmail.com> <20141007175133.6a26bcc5@bender.lan> In-Reply-To: <20141007175133.6a26bcc5@bender.lan> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 02:46:12 -0000 2014-10-08 AM 1:51에 Andrew Turner wrote: > On Tue, 07 Oct 2014 21:31:42 +0900 > Jaemin Yoo wrote: > >> 2014-10-06 PM 11:43, Andrew Turner wrote: >>> On Mon, 06 Oct 2014 23:05:41 +0900 >>> Jaemin Yoo wrote: >>> >>>> Hello, I just began to download and build kernel for armv8 >>>> according to the following howto page. >>>> (https://wiki.freebsd.org/arm64) >>>> >>>> I could create the kernel image without problem. But 'file' says >>>> it's dynamically linked. I expected statically linked image to load >>>> it on dram using uboot. >>>> >>>> Is it meant to be? or am I missing some configuration? >>> >>> All examples of the FreeBSD kernel I've looked at say they are >>> dynamically linked. The requirement is the kernel needs to be >>> loaded at a 2MiB aligned address for the VA->PA translation to >>> work. It will create the page table so the kernel base points to >>> the load address. >>> >>> You may have problems loading it with U-Boot. It expects to be >>> loaded by the loader as it passes in the device tree. U-Boot has >>> been found to be difficult to support on 32-bit arm. Is there a >>> reason to prefer it over UEFI? >>> >>> Andrew >>> >> >> Thanks. I'm doing most work at linux and vmlinux is mostly(?) >> statically linked. So I thought same goes for freebsd too. There are >> some 'UND' functions in kernel but I guess it's okay if they are not >> used. > > The only undefined data I get in my arm64 kernel is for uart data. > These are specifically set up like this to simplify the code. > >> I got a 64bit arm board which runs linux from APM. It came with binary >> and source codes of u-boot. So I planned to enable bootelf and load >> kernel on dram after adding uart driver for the board. I just want to >> see freebsd kernel boot on arm64 with minimal changes. > > You will have issues as the kernel expects to read the dtb from the > data provided by the loader. In the short term you could use a static > DTB in the kernel however the code to do so has not been written as the > kernel should work on all supported hardware. If you go down this route > you don't need to use the bootelf command, instead you can either > create a U-Boot image using mkimage, or have U-Boot jump to the > entry point directly using the go command. Note that the go command may > leave the d-cache on causing issues. > > In the long term the loader should be ported to work on U-Boot. Some of > the existing work to have it run on 32-bit ARM can be reused. > I found uefi code and binary runs on x-gene board. I'll use it to leverage for booting freebsd. > You will also need to change the early putc function in > arm64/arm64/machdep.c. It appears from [1] and [2] the UART is mapped at > 0x1c020000. This is within the range set up for the Foundation Model so > you should only need up update the early_putc function. It's written > for a pl011 with the assumption we will never overflow the fifo. You > will need to change this as the APM SoC appears to have an ns16550. > So, putc is like early_printk of linux? Wondered how it works but it looks bootloader enables uart and early_putc just put char on output register. Hope to see boot log soon! :) > At this point you should start to get kernel messages on the serial > port, this includes any panic messages if something got missed. > > Andrew > > [1] > https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/apm-mustang.dts > [2] > https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/apm-storm.dtsi > Thanks, Jaemin From owner-freebsd-arm@FreeBSD.ORG Thu Oct 9 03:34:14 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3924E27D for ; Thu, 9 Oct 2014 03:34:14 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 205B99E6 for ; Thu, 9 Oct 2014 03:34:14 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s993YDCw095026 for ; Thu, 9 Oct 2014 03:34:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 194251] Efika MX Smartbook (imx51) WiFi does not work anymore Date: Thu, 09 Oct 2014 03:34:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 03:34:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194251 Ian Lepore changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |In Discussion CC| |ian@FreeBSD.org --- Comment #1 from Ian Lepore --- The old imx51 iomux code wasn't so much refactored as just plain deleted because it was completely unused. There is no pinmux data in the efikamx.dts or imx51.dtsi files, and no drivers or other code ever called the imx51 iomux functions. To my understanding, we have always relied on using a "usb start" command in u-boot to configure the clocks and pins for usb. The usb on my imx53 system has never worked unless I do "usb start" in u-boot first. Does the usbconfig command show any devices besides the root hub after you've booted? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Thu Oct 9 04:46:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0E15F2B for ; Thu, 9 Oct 2014 04:46:41 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E936FCD for ; Thu, 9 Oct 2014 04:46:41 +0000 (UTC) Received: by mail-ig0-f177.google.com with SMTP id a13so1999271igq.10 for ; Wed, 08 Oct 2014 21:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4aLnUsH+WYL/VfU4GT8oLZI49cwfQybSo0MWIzmpB64=; b=vysn1zfTrdaGS7QJaJuFNLCiF4VGqI5nTcI3X1QwMMJFxFzoTFU2RPwhMK5nF0W54F op7usNUFv3si7qYijU25oKV13vvJAg2ghN/tvghx8rWASbh7O20BVidyudrtUcEZWdee AIZxZYmBUn0SBG6odgY6MpTl2AFbDh2t25wTsKUYFRQAL0N31Mhmap35xhd0oOwvVNKa nZuXrIhhbj3qACxwaCobbgYCJ1eqR9z09naph94UrllqbIC7N2X3sC6MankXgwAk05WC QCkSzZs/1Apk6IszZR0RCMzGAHwaB+GueVlcDuol1AD+vu6JPzl5WTiVcIo3OtM+E+v7 80ZQ== MIME-Version: 1.0 X-Received: by 10.50.154.6 with SMTP id vk6mr4785882igb.28.1412830000332; Wed, 08 Oct 2014 21:46:40 -0700 (PDT) Received: by 10.64.119.193 with HTTP; Wed, 8 Oct 2014 21:46:40 -0700 (PDT) In-Reply-To: <18234.85.229.95.175.1412713132.squirrel@webmail.alvermark.net> References: <18234.85.229.95.175.1412713132.squirrel@webmail.alvermark.net> Date: Thu, 9 Oct 2014 12:46:40 +0800 Message-ID: Subject: Re: Allwinner A13 support (patches attached) From: Ganbold Tsagaankhuu To: Jakob Alvermark Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 04:46:41 -0000 Jakob, On Wed, Oct 8, 2014 at 4:18 AM, Jakob Alvermark wrote: > Hello people! > > I have been sitting on this for too long now. (Thanks Arun Thomas for > encouraging me to send this!) > I have this Allwinner A13 board from Olimex, > > https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino/open-source-hardware > > I have made it boot FreeBSD-current, and here are the patches. Hoping > anyone (committers?) might be interrested in looking at this. > > It boots from the SD card, using this U-boot: > https://github.com/linux-sunxi/u-boot-sunxi > Adding CONFIG_CMD_ELF and CONFIG_API to allow ubldr to work. > > It can boot to multi user, with root on a USB stick. > > Wanting to get rid of the USB stick I added Alexander Fedorov's > MMC-driver, > http://lists.freebsd.org/pipermail/freebsd-arm/2013-June/005913.html > but it fails: > > a10_mmc0: mem 0x1c0f000-0x1c0ffff > irq 32 on simplebus0 > MMC0 MODE_CLK: 0x04dd1e00 > mmc0: on a10_mmc0 > > vm_fault(0xc066ff50, 3197000, 1, 0) -> 1 > Fatal kernel mode data abort: 'Translation Fault (S)' > trapframe: 0xc07cecd8 > FSR=00000005, FAR=03197500, spsr=800001d3 > r0 =c26bd400, r1 =03197500, r2 =00000400, r3 =c26bd409 > r4 =00000000, r5 =00000008, r6 =c2674680, r7 =c2674b80 > r8 =00000400, r9 =c26e2020, r10=c26bd800, r11=c07ced30 > r12=c26bd408, ssp=c07ced28, slr=c0261810, pc =c0419ae0 > > [ thread pid 0 tid 100000 ] > Stopped at strlcat+0x54: ldrb r4, [r1] > > I am not an experienced kernel hacker, so I don't know how to debug this. > > I also wanted to blink the onboard LED, so this is in the dts file: > --- > leds { > compatible = "gpio-leds"; > > led1 { > label = "led1"; > gpios = <&gpio 201 1>; > }; > }; > --- > I do not get a /dev/led/led1 as I expected, manually toggling the LED with > 'gpioctl -t 201' works fine... > Cool. Can a10_gpio.c and a13_gpio.c combined into one? Also you disabled some gpio settings in a10_ehci.c I guess olinuxino has u-boot and u-boot sets that, or maybe different pins. I think instead of disabling better make it work for both cubieboard and olinuxino. As for mmc I think Martin Galvan is also working on it so I think we can add that later when it is in good shape. thanks, Ganbold > > Thanks, > Jakob > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Thu Oct 9 06:17:17 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E52409DB for ; Thu, 9 Oct 2014 06:17:17 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CC4F0A7D for ; Thu, 9 Oct 2014 06:17:17 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s996HH1O041587 for ; Thu, 9 Oct 2014 06:17:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 194251] Efika MX Smartbook (imx51) WiFi does not work anymore Date: Thu, 09 Oct 2014 06:17:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: yom@iaelu.net X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 06:17:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194251 --- Comment #2 from yom@iaelu.net --- Created attachment 148127 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148127&action=edit usbconfig output There is no ethernet device in the usbconfig output, while the wifi switch is on. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Thu Oct 9 06:21:14 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 289C8BE0 for ; Thu, 9 Oct 2014 06:21:14 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 101B6B1D for ; Thu, 9 Oct 2014 06:21:14 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s996LDHH039118 for ; Thu, 9 Oct 2014 06:21:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 194251] Efika MX Smartbook (imx51) WiFi does not work anymore Date: Thu, 09 Oct 2014 06:21:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: yom@iaelu.net X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 06:21:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194251 --- Comment #3 from yom@iaelu.net --- Also when I'm on the u-boot cli a 'usb start' tells me it didn't find ethernet device while the wifi switch is on. I'm now wondering sadly if it is not hardware related. the 'usb tree' only shows a keyboard attached. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Thu Oct 9 13:42:38 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 520DE7A7 for ; Thu, 9 Oct 2014 13:42:38 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 39B87EBD for ; Thu, 9 Oct 2014 13:42:38 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s99DgcUC081228 for ; Thu, 9 Oct 2014 13:42:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 194251] Efika MX Smartbook (imx51) WiFi does not work anymore Date: Thu, 09 Oct 2014 13:42:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 13:42:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194251 --- Comment #4 from Ian Lepore --- Given that other usb devices are working and only the wifi device is not, it does sound like it may be a problem with the device. Can you try the device on another system? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Thu Oct 9 15:08:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFDD988D for ; Thu, 9 Oct 2014 15:08:18 +0000 (UTC) Received: from mail-wi0-x242.google.com (mail-wi0-x242.google.com [IPv6:2a00:1450:400c:c05::242]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 38D2AB55 for ; Thu, 9 Oct 2014 15:08:18 +0000 (UTC) Received: by mail-wi0-f194.google.com with SMTP id fb4so769709wid.9 for ; Thu, 09 Oct 2014 08:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gPemX3R9FznYjCNd2NzBfP1MKXt4muTN1EpQNLj0mPE=; b=kreT1ByvJ3yn7tvUfOg1IopMWN8Dt2AaG5ePDXwBw75xuMN8TKigLi8OBDo1aFaJ2k sqRchlWKzhiT2xs3r6I1Af4mccurpm0qx3cG/X8b7XOtinW5eIVh7fbpO6ABsf4fsKvc F0AxZKlbjtmP6DgR3D/TOjkBCO4RmfivyO8bkkImgrvBo5rL3IksADnV1BdgX6H4M3qg GdO+YMNph+9GspcQv/NjvAWKA6Ql3PEsCm8N5x/6go00Pj/HqxwH6y8DjB/E8WksSeok /nNqcJBIUkUtP2J5B6tM1zK1N9CHpScXh/TlxNCewltiJJ4PeufXE/KLO8Ap+d1548AW /zNg== MIME-Version: 1.0 X-Received: by 10.180.149.130 with SMTP id ua2mr40261966wib.68.1412867296539; Thu, 09 Oct 2014 08:08:16 -0700 (PDT) Received: by 10.217.125.198 with HTTP; Thu, 9 Oct 2014 08:08:16 -0700 (PDT) Received: by 10.217.125.198 with HTTP; Thu, 9 Oct 2014 08:08:16 -0700 (PDT) Date: Thu, 9 Oct 2014 08:08:16 -0700 Message-ID: Subject: From: Damien Dayzien To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 15:08:18 -0000 From owner-freebsd-arm@FreeBSD.ORG Thu Oct 9 16:51:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67280DC5 for ; Thu, 9 Oct 2014 16:51:30 +0000 (UTC) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F198ACD for ; Thu, 9 Oct 2014 16:51:30 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id p10so89512pdj.29 for ; Thu, 09 Oct 2014 09:51:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=tbDhhEMHwk4Ko59Kly9TiEfQ6Y9v5v8c+HUx45lOG+o=; b=q5Wbd2ABJ3K3AO/clVQ2JFnUkIyXPHCrNoO+mElMTJhmwMHcmId+jZBzPvC2gnC7DD y0KXS5wQ5gRSEd+cCMrU9LR/M+WQOIV8di/0KrSPb2gZ19mGbwfrFajcOSLeA1ck33vu 2XkfyG/MLE8m9DFvWeUtqxVC+flBV9ZVT6QkBOvHQj3vPzlzm1PhxQWYmqOWxfjLx+TR +XMb/VxxgP3mQL9yUzuuwW8QGPFd5myQefPnVmyPrmqb25zQf5AMaXSXMkoWD8IFo7i7 jgEl2KpMtvUqQKbZMXzWlRnqvBEBl/PXlFt0CwnWIXYuLGGVnb3IWtQF3nYTmehQe9xL BVvA== X-Received: by 10.70.65.34 with SMTP id u2mr842607pds.58.1412873489358; Thu, 09 Oct 2014 09:51:29 -0700 (PDT) Received: from [172.30.1.13] ([112.168.75.52]) by mx.google.com with ESMTPSA id a1sm996925pdc.68.2014.10.09.09.51.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Oct 2014 09:51:28 -0700 (PDT) Message-ID: <5436BD08.20403@gmail.com> Date: Fri, 10 Oct 2014 01:51:20 +0900 From: Jaemin Yoo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Q: looking up 'kernel' on loader.efi of arm64 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 16:51:30 -0000 Thanks for the help from Andrew. I could execute loader.efi for arm64 from efi loader of my board(x-gene). Now the problem is loader can't find 'kernel'. loader.efi is located at part1 disk. The disk is usb removable one and formatted as fat32 since x-gene efi loader requires it. I have some questions... 1) What's the scheme for looking up 'kernel' from loader.efi? 2) Is there any restriction for looking up 'kernel'? Thanks, Jaemin == Here is log for efi loading.. == Start: 2 Consoles: EFI console Image base: 0x43fa93a000 EFI version: 2.40 EFI Firmware: X-Gene Mustang Board EFI Aug 25 2014 14:20:27 (rev 0.00) FreeBSD/arm64 EFI loader, Revision 1.0 (jmin@maui, Thu Oct 9 22:03:51 KST 2014) can't load 'kernel' ~~~~~~~~~~~~~~~~~~~~~~ OK show console=efi currdev=part1: interpret=OK loaddev=part1: prompt=${interpret} OK load kernel load: can't find 'kernel' OK lsdev part devices: part0: 976771120 blocks <=== SATA part1: 248799 blocks (removable) <=== USB (here is kernel) net devices: net0: simplefs? devices: efisfs_print From owner-freebsd-arm@FreeBSD.ORG Thu Oct 9 17:31:36 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9238F6DA for ; Thu, 9 Oct 2014 17:31:36 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 76BD1F70 for ; Thu, 9 Oct 2014 17:31:36 +0000 (UTC) Received: from bender.lan (97e07ab1.skybroadband.com [151.224.122.177]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 8655A5C0B9; Thu, 9 Oct 2014 17:31:28 +0000 (UTC) Date: Thu, 9 Oct 2014 18:31:20 +0100 From: Andrew Turner To: Jaemin Yoo Subject: Re: Q: looking up 'kernel' on loader.efi of arm64 Message-ID: <20141009183120.73ff549d@bender.lan> In-Reply-To: <5436BD08.20403@gmail.com> References: <5436BD08.20403@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 17:31:36 -0000 On Fri, 10 Oct 2014 01:51:20 +0900 Jaemin Yoo wrote: > > Thanks for the help from Andrew. I could execute loader.efi for arm64 > from efi loader of my board(x-gene). Now the problem is loader can't > find 'kernel'. > > loader.efi is located at part1 disk. The disk is usb removable one and > formatted as fat32 since x-gene efi loader requires it. > > I have some questions... > > 1) What's the scheme for looking up 'kernel' from loader.efi? > 2) Is there any restriction for looking up 'kernel'? loader.efi should try to read the fat filesystem. The problem is I've only enabled the simpefs as it is all I've had to test. You can enable FAT by uncommenting the dosfs_fsops entry in sys/boot/arm64/efi/conf.c and rebuilding. For the full kernel to work you will also need to provide a dtb. Currently it tries to load /foundation.dtb. I'm planning on fixing this, however until recently the copy of UEFI I have been using didn't support passing the dtb to the loader. You should be able to skip loading the dtb to begin with to check if you can start executing the kernel. Andrew From owner-freebsd-arm@FreeBSD.ORG Thu Oct 9 19:15:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3570C2B5 for ; Thu, 9 Oct 2014 19:15:46 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C5066CDC for ; Thu, 9 Oct 2014 19:15:45 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id x13so2133867wgg.6 for ; Thu, 09 Oct 2014 12:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TNClKtaieOvIGLzeuypxBRbaXFxa2gTCQsEx5W8U5AQ=; b=QUZtjH/d2f2iatV+iPDhpPB56mzgB/Qi4eCqat1cTH+zkBZXa18C+bZHBt5Biz0Rvz /hm8iHmE4O347vjgVbPiaIFeOsK1FL8Jd200hQuvCN8fUd89BA9h+Yeo/9RBlHci0810 f5FzNL3D8xSK1SRV1bO6hYXcKNteLg7jC5SzbGZHAzAAwFyJQHlenxUiYeWo9nL7niyB ++/og1efJZer4WR3Fv0+i+Sw2l/36qpvX21jPtgrFwLduCaAatf/3EDv2jNJfMIhhCv4 8eiiPb5laI3KHnkmeneMiy71xsbS69ZiTmgyrlzQyBpcCYtY3wMSkYxpIWrNO449ewWi yrjw== MIME-Version: 1.0 X-Received: by 10.194.246.166 with SMTP id xx6mr20500565wjc.37.1412882143867; Thu, 09 Oct 2014 12:15:43 -0700 (PDT) Received: by 10.216.127.72 with HTTP; Thu, 9 Oct 2014 12:15:43 -0700 (PDT) In-Reply-To: References: <18234.85.229.95.175.1412713132.squirrel@webmail.alvermark.net> Date: Thu, 9 Oct 2014 16:15:43 -0300 Message-ID: Subject: Re: Allwinner A13 support (patches attached) From: Luiz Otavio O Souza To: Ganbold Tsagaankhuu Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 19:15:46 -0000 On 9 October 2014 01:46, Ganbold Tsagaankhuu wrote: > On Wed, Oct 8, 2014 at 4:18 AM, Jakob Alvermark wrote: > >> Hello people! Hello Jakob, >> >> I have been sitting on this for too long now. (Thanks Arun Thomas for >> encouraging me to send this!) >> I have this Allwinner A13 board from Olimex, >> >> https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino/open-source-hardware >> >> I have made it boot FreeBSD-current, and here are the patches. Hoping >> anyone (committers?) might be interrested in looking at this. >> Yay, nice work! >> I also wanted to blink the onboard LED, so this is in the dts file:) >> --- >> leds { >> compatible = "gpio-leds"; >> >> led1 { >> label = "led1"; >> gpios = <&gpio 201 1>; >> }; >> }; >> --- >> I do not get a /dev/led/led1 as I expected, manually toggling the LED with >> 'gpioctl -t 201' works fine... The gpio node from the DTS you are using (sun5i-a13.dtsi) uses '3' as #gpio-cells: gpio: gpio@01c20800 { #gpio-cells = <3>; compatible = "allwinner,sun5i-gpio"; gpio-controller; reg =< 0x01c20800 0x400 >; interrupts = < 28 >; interrupt-parent = <&AINTC>; }; So you need to adjust the gpios property for led and add a third value (in this case: pin number, not used, pin flags): leds { compatible = "gpio-leds"; led1 { name = "led1"; gpios = <&gpio 201 0 1>; }; }; Changing the #gpio-cells back to 2 would also work. >> > > Cool. > > Can a10_gpio.c and a13_gpio.c combined into one? > Also you disabled some gpio settings in a10_ehci.c I guess olinuxino has > u-boot and u-boot sets that, or maybe different pins. > I think instead of disabling better make it work for both cubieboard and > olinuxino. Yes, they can. I've checked and the only differences are the number of available banks and pins. We have a similar situation with ti_gpio.c. You could use the DTS to pass the gpio pin (or pins) we need to tweak at boot to enable the onboard devices. Luiz From owner-freebsd-arm@FreeBSD.ORG Thu Oct 9 20:44:01 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFD15793 for ; Thu, 9 Oct 2014 20:44:01 +0000 (UTC) Received: from smtprelay-b21.telenor.se (smtprelay-b21.telenor.se [195.54.99.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3714789B for ; Thu, 9 Oct 2014 20:44:00 +0000 (UTC) Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-b21.telenor.se (Postfix) with ESMTP id DEA1CEC1A for ; Thu, 9 Oct 2014 22:25:15 +0200 (CEST) X-SENDER-IP: [85.229.94.62] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikMAAbuNlRV5V4+PGdsb2JhbABggw5TXMARgxSHcIdNAoEIFwEBBQEBAQE4OYQDAQEBAQIBMgEjIwULCxguLQwKFAaISQwBCMJ6ARMEj3ZOB4RLBZF5XZdCGodQhT87gnkBAQE X-IPAS-Result: AikMAAbuNlRV5V4+PGdsb2JhbABggw5TXMARgxSHcIdNAoEIFwEBBQEBAQE4OYQDAQEBAQIBMgEjIwULCxguLQwKFAaISQwBCMJ6ARMEj3ZOB4RLBZF5XZdCGodQhT87gnkBAQE X-IronPort-AV: E=Sophos;i="5.04,687,1406584800"; d="scan'208";a="90107968" Received: from c-3e5ee555.06-11-73746f31.cust.bredbandsbolaget.se (HELO sigyn.alvermark.net) ([85.229.94.62]) by ipb2.telenor.se with ESMTP; 09 Oct 2014 22:25:15 +0200 Received: from localhost ([127.0.0.1] helo=webmail.alvermark.net) by sigyn.alvermark.net with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1XcKGw-0003aL-Fs; Thu, 09 Oct 2014 22:25:14 +0200 Received: from 85.229.95.175 (SquirrelMail authenticated user alvis) by webmail.alvermark.net with HTTP; Thu, 9 Oct 2014 22:25:14 +0200 (CEST) Message-ID: <22856.85.229.95.175.1412886314.squirrel@webmail.alvermark.net> Date: Thu, 9 Oct 2014 22:25:14 +0200 (CEST) Subject: Re: Allwinner A13 support (patches attached) From: "Jakob Alvermark" To: "Luiz Otavio O Souza" User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit References: <18234.85.229.95.175.1412713132.squirrel@webmail.alvermark.net> In-Reply-To: Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 20:44:01 -0000 On Thu, October 9, 2014 21:15, Luiz Otavio O Souza wrote: > On 9 October 2014 01:46, Ganbold Tsagaankhuu wrote: > >> On Wed, Oct 8, 2014 at 4:18 AM, Jakob Alvermark wrote: >> >> >>> Hello people! >>> > > Hello Jakob, > > >>> >>> I have been sitting on this for too long now. (Thanks Arun Thomas for >>> encouraging me to send this!) I have this Allwinner A13 board from >>> Olimex, >>> >>> >>> https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino/open-sour >>> ce-hardware >>> >>> I have made it boot FreeBSD-current, and here are the patches. Hoping >>> anyone (committers?) might be interrested in looking at this. >>> > > Yay, nice work! > > >>> I also wanted to blink the onboard LED, so this is in the dts file:) >>> --- >>> leds { compatible = "gpio-leds"; >>> >>> led1 { label = "led1"; gpios = <&gpio 201 1>; }; >>> }; >>> --- >>> I do not get a /dev/led/led1 as I expected, manually toggling the LED >>> with 'gpioctl -t 201' works fine... >>> > > The gpio node from the DTS you are using (sun5i-a13.dtsi) uses '3' as > #gpio-cells: > > > gpio: gpio@01c20800 { > #gpio-cells = <3>; > compatible = "allwinner,sun5i-gpio"; gpio-controller; reg =< 0x01c20800 > 0x400 >; > interrupts = < 28 >; interrupt-parent = <&AINTC>; }; > > > So you need to adjust the gpios property for led and add a third value > (in this case: pin number, not used, pin flags): > > > leds { compatible = "gpio-leds"; > > led1 { name = "led1"; gpios = <&gpio 201 0 1>; }; > }; OK, cool, I see. I will try that. (I have to learn more about DTS) > Changing the #gpio-cells back to 2 would also work. > > >>> >> >> Cool. >> >> >> Can a10_gpio.c and a13_gpio.c combined into one? >> Also you disabled some gpio settings in a10_ehci.c I guess olinuxino has >> u-boot and u-boot sets that, or maybe different pins. I think instead >> of disabling better make it work for both cubieboard and olinuxino. > > Yes, they can. I've checked and the only differences are the number of > available banks and pins. We have a similar situation with ti_gpio.c. I will do that, I don't know what I was thinking there. As you say, the only difference is that the A13 has less ports. > You could use the DTS to pass the gpio pin (or pins) we need to tweak > at boot to enable the onboard devices. I guess the initial A10 support was done with a Cubieboard. It has USB power controlled by the GPIO pins. My board does not have that, the default is that USB power is always on (although you could set a jumper, and you would be able to control the power to all 3 USB ports with one pin). I believe this should not be hardcoded as it is now. Other boards with these SOC's could have those pins wired to something completely different. How would you do it using the DTS? Thanks for you help, Jakob From owner-freebsd-arm@FreeBSD.ORG Fri Oct 10 06:49:58 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AEACCFC4 for ; Fri, 10 Oct 2014 06:49:58 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9349DB9D for ; Fri, 10 Oct 2014 06:49:58 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9A6nwkI080608 for ; Fri, 10 Oct 2014 06:49:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 194251] Efika MX Smartbook (imx51) WiFi does not work anymore Date: Fri, 10 Oct 2014 06:49:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ray@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 06:49:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194251 Aleksandr Rybalko changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ray@FreeBSD.org --- Comment #5 from Aleksandr Rybalko --- hi yom@! (sorry, I don't know your name :) ) Can you, please, submit dmesg(1) output too? Thanks! -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Oct 10 12:04:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95FB21AE for ; Fri, 10 Oct 2014 12:04:52 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 7B4E2E68 for ; Fri, 10 Oct 2014 12:04:52 +0000 (UTC) Received: from bender.lan (97e07ab1.skybroadband.com [151.224.122.177]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id F1E365CC29 for ; Fri, 10 Oct 2014 12:04:50 +0000 (UTC) Date: Fri, 10 Oct 2014 13:04:44 +0100 From: Andrew Turner To: freebsd-arm@freebsd.org Subject: Re: OMAP3 support Message-ID: <20141010130444.50645e1d@bender.lan> In-Reply-To: <20141006152832.60c96640@bender.lan> References: <20141006152832.60c96640@bender.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 12:04:52 -0000 On Mon, 6 Oct 2014 15:28:32 +0100 Andrew Turner wrote: > A few months ago I proposed removing OMAP3 support. At the time there > was interest in keeping it in the tree as it was being worked on. I'm > interested in the status of this. > > Is it the case that there is active development to support OMAP3? If > so is there a tree somewhere for people with hardware to test? Or can > we look are removing it due to lack of interest. I've had no feedback on this. I can only assume nobody is interested in supporting OMAP3. Due to the lack of interest I'm planning on removing any code we have that is complicating the other Ti platforms we do support in the next few days. Andrew From owner-freebsd-arm@FreeBSD.ORG Fri Oct 10 17:18:05 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4EE6C9D for ; Fri, 10 Oct 2014 17:18:05 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 369877CA for ; Fri, 10 Oct 2014 17:18:05 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9AHI5bK090290 for ; Fri, 10 Oct 2014 17:18:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 194251] Efika MX Smartbook (imx51) WiFi does not work anymore Date: Fri, 10 Oct 2014 17:18:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: yom@iaelu.net X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 17:18:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194251 --- Comment #6 from Guillaume Bibaut --- (In reply to Ian Lepore from comment #4) > Given that other usb devices are working and only the wifi device is not, it > does sound like it may be a problem with the device. Can you try the device > on another system? I'm going to try to install a downgraded version of 11-CURRENT in August when it was still working, not sure if it would be enough. What do you think about it ? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Oct 10 17:19:20 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54819136 for ; Fri, 10 Oct 2014 17:19:20 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3C17E7E1 for ; Fri, 10 Oct 2014 17:19:20 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9AHJKbe090841 for ; Fri, 10 Oct 2014 17:19:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 194251] Efika MX Smartbook (imx51) WiFi does not work anymore Date: Fri, 10 Oct 2014 17:19:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: yom@iaelu.net X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 17:19:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194251 --- Comment #7 from Guillaume Bibaut --- (In reply to Aleksandr Rybalko from comment #5) > hi yom@! (sorry, I don't know your name :) ) > > Can you, please, submit dmesg(1) output too? > > Thanks! Hello :) I'm attaching the dmesg.boot. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Oct 10 17:20:16 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09FF518E for ; Fri, 10 Oct 2014 17:20:16 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5CA17EF for ; Fri, 10 Oct 2014 17:20:15 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9AHKFae091765 for ; Fri, 10 Oct 2014 17:20:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 194251] Efika MX Smartbook (imx51) WiFi does not work anymore Date: Fri, 10 Oct 2014 17:20:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: yom@iaelu.net X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 17:20:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194251 --- Comment #8 from Guillaume Bibaut --- Created attachment 148174 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148174&action=edit dmesg.boot this is the /var/run/dmesg.boot file on the Efika MX -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sat Oct 11 19:38:12 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD0823AB for ; Sat, 11 Oct 2014 19:38:12 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ADC4EEB8 for ; Sat, 11 Oct 2014 19:38:12 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9BJcCR6031275 for ; Sat, 11 Oct 2014 19:38:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 194251] Efika MX Smartbook (imx51) WiFi does not work anymore Date: Sat, 11 Oct 2014 19:38:12 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ray@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 19:38:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194251 --- Comment #9 from Aleksandr Rybalko --- Hi Guillaume! so, looks like ehci core works fine, at least it attach t.pad and keyboard. since it so, we have to find: 1. if wireless card is alive; 2. if GPIO pin give us required value. To make test simple, you can try to test wireless card somewhere else. For example: I use that card in my laptop. Are you able to do that? Ian, do we write some default values to pinmux? If so, it is bad idea. Not always possible to get all required information about board, but pinmux is not so simple to test it by hand and get things which is left. Thanks! -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sat Oct 11 20:44:29 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 596B077E for ; Sat, 11 Oct 2014 20:44:29 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 41E7674F for ; Sat, 11 Oct 2014 20:44:29 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9BKiTQ6013182 for ; Sat, 11 Oct 2014 20:44:29 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 194251] Efika MX Smartbook (imx51) WiFi does not work anymore Date: Sat, 11 Oct 2014 20:44:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 20:44:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194251 --- Comment #10 from Ian Lepore --- The new pinmux driver is purely fdt data-driven. If there are pinctrl-0 properties on enabled devices, then the pinmux driver configures the pins as directed by those properties, when the pinmux driver attaches. None of our imx5 or imx6 dts files have any pinctrl-0 properties in them yet, so the driver is really doing nothing at all (which is what the old driver did, since nothing called its functions). -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sat Oct 11 20:47:23 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66830945 for ; Sat, 11 Oct 2014 20:47:23 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4E84D76A for ; Sat, 11 Oct 2014 20:47:23 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9BKlNhp014681 for ; Sat, 11 Oct 2014 20:47:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 194251] Efika MX Smartbook (imx51) WiFi does not work anymore Date: Sat, 11 Oct 2014 20:47:23 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ray@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 20:47:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194251 --- Comment #11 from Aleksandr Rybalko --- Aha, got it. Thanks, Ian! -- You are receiving this mail because: You are the assignee for the bug.