From owner-freebsd-arm@FreeBSD.ORG Sun Aug 17 03:45:01 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 71AFC642 for ; Sun, 17 Aug 2014 03:45:01 +0000 (UTC) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (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 0CF50201D for ; Sun, 17 Aug 2014 03:45:00 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id b13so3648622wgh.18 for ; Sat, 16 Aug 2014 20:44:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=qcC87aibfnJTor/Pn7+fu36Q8BnuEZNuBcGyDs4zsUA=; b=V9C35GSjVP+5dE/ffsOeP5bxhJMXuyTGYXWXpIikfXaPhdc7hsnYZqoYU8n+G/8CSh FUZqoebnBr6SOs8GtkX0jOi+/7hwxw2krnwcPVKZ7/bQwrDXEAth61YqqNAqg9LlEYdj +lvXjFoq0P8GMGNSgBhaT+gnnqmxYd7K1ux51h20s0eAx2zC2Q45WDiFE5Fo6rlu3vO1 nq2hOJ9RBhAl2/l0wGLQSc6sLDIkT4QvkO5ZBbT0CokfzNgGzpsCTiIE7XiA4oKmi1tU ZM9OIVwCb4zrO+/dloMQF8xDv4lyp3+M1R8d/YIInwM4s67rVF2J3f4YojnCH3a34Pkf nl5w== X-Gm-Message-State: ALoCoQnOXt/EpPXSNsSXabyYR/I26clLopTGGq2Of+uqc49pwM+GglGIE+JSgGBoewCNZpaA20nJ MIME-Version: 1.0 X-Received: by 10.180.206.134 with SMTP id lo6mr59942250wic.1.1408247092701; Sat, 16 Aug 2014 20:44:52 -0700 (PDT) Received: by 10.216.68.6 with HTTP; Sat, 16 Aug 2014 20:44:52 -0700 (PDT) Date: Sat, 16 Aug 2014 21:44:52 -0600 Message-ID: Subject: chromebook help From: Tom Everett To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Sun, 17 Aug 2014 03:45:01 -0000 Is there anyone on the list who has a chromebook, who would be willing to try a simple experiment with an SD card? -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Sun Aug 17 17:28:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4B3A609 for ; Sun, 17 Aug 2014 17:28:40 +0000 (UTC) Received: from poczta.toomeek.waw.pl (unknown [IPv6:2001:67c:232c:1000::fd9b:4fb4]) by mx1.freebsd.org (Postfix) with ESMTP id 90C212121 for ; Sun, 17 Aug 2014 17:28:40 +0000 (UTC) Received: from [192.168.137.1] (afmx150.neoplus.adsl.tpnet.pl [178.42.75.150]) by poczta.toomeek.waw.pl (Postfix) with ESMTPSA id 3FBADC601DD for ; Sun, 17 Aug 2014 13:28:33 -0400 (EDT) Message-ID: <53F0E640.5030506@toomeek.waw.pl> Date: Sun, 17 Aug 2014 19:28:32 +0200 From: TooMeeK Admin User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: U-boot for Banana Pi References: <53EE0F93.6060407@toomeek.waw.pl> <53EE23B1.2020403@toomeek.waw.pl> <53EE402D.8000204@toomeek.waw.pl> <20140815214416.GJ60808@cicely7.cicely.de> <53EFCD6C.5000601@toomeek.waw.pl> <53EFD5D5.7010406@toomeek.waw.pl> In-Reply-To: <53EFD5D5.7010406@toomeek.waw.pl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.9 (poczta.toomeek.waw.pl [0.0.0.0]); Sun, 17 Aug 2014 13:28:34 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.98.1 at a8d2ba546e X-Virus-Status: Clean 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, 17 Aug 2014 17:28:40 -0000 If I take u-boot-sunxi from: git clone https://github.com/linux-sunxi/u-boot-sunxi.git Make it: cd u-boot-sunxi gmake -j4 ARCH=arm CROSS_COMPILE=arm-eabi- HOSTCC=cc USE_PRIVATE_LIBGCC=yes clean gmake -j4 ARCH=arm CROSS_COMPILE=arm-eabi- HOSTCC=cc USE_PRIVATE_LIBGCC=yes Bananapi_config gmake -j4 ARCH=arm CROSS_COMPILE=arm-eabi- HOSTCC=cc USE_PRIVATE_LIBGCC=yes And then make bootable SD image (after adding partitions, copying kernel etc..) dd if=/usr/src/u-boot-sunxi/spl/sunxi-spl.bin conv=notrunc of=banana.img bs=1024 seek=8 dd if=/usr/src/u-boot-sunxi/u-boot.bin conv=notrunc of=banana.img bs=1024 seek=32 It ends with: U-Boot SPL 2014.04-10704-gf625d1d (Aug 16 2014 - 23:44:23) Board: Bananapi DRAM: 1024 MiB CPU: 960000000Hz, AXI/AHB/APB: 3/2/2 spl: not an uImage at 1600 spl: not an uImage at 80 ### ERROR ### Please RESET the board ### Why these files for Cubieboard2 works and for Bananapi not? Maybe I should try again with U-boot-sunxi from Lemaker's GIT? Unfortunately, this is my last free day when I have time to investigate this issue.. Cheers, TooMeeK From owner-freebsd-arm@FreeBSD.ORG Mon Aug 18 15:16:38 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85C28156; Mon, 18 Aug 2014 15:16:38 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 CE5B93335; Mon, 18 Aug 2014 15:16:37 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id n3so3845221wiv.0 for ; Mon, 18 Aug 2014 08:16:36 -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=El/lM4rpKik+e8SOBVEm32i6STq3PEwzZSlhG3eRRL4=; b=lRR5smH6tf7pouG1/G7UefyndWJjiLop00lkYCTPSM31vT7Ik4AdRXbrRSKPu3b/Ga PTiR0lGxl2BRbpS3ls0mAdgTI1VXnamhfWu8UAHnDGXuoR9JZ97ACVL4zajgMQg0xT5H hqYc+OdOZnVXUyW0XU1+0tNmUPGUwl7jszC89/3LyJOx8bgUeQA3wsNOS8vXjuvJGJcY Dc6Lq3+ixKL/iFVkz1fJ870KetEcz9myHP8+u7dqMrFsqIRqRK/Ijw1P3QrxfFbCSvBs 6QjHbQB/hphwjNSJ3GDS3DCtxujkrVqknb4pz4aUC2frloxCxORn7VjV3aTNiAKv/ogd p2DA== MIME-Version: 1.0 X-Received: by 10.180.91.111 with SMTP id cd15mr74306736wib.69.1408374995958; Mon, 18 Aug 2014 08:16:35 -0700 (PDT) Received: by 10.180.87.228 with HTTP; Mon, 18 Aug 2014 08:16:35 -0700 (PDT) Date: Mon, 18 Aug 2014 19:16:35 +0400 Message-ID: Subject: GSoC final status: porting FreeBSD to Android Emulator From: Alexander Tarasikov To: Gavin Atkinson , "freebsd-arm@freebsd.org" , soc-status@freebsd.org Content-Type: text/plain; charset=ISO-8859-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: Mon, 18 Aug 2014 15:16:38 -0000 Hi FreeBSD/ARM hackers! I am reporting my status on the project. At the start of the project in spring I have written the device drivers for the IRQ chip, timer and framebuffer, but I was unable to verify they work because I needed a working rootfs. I started by using an MD_ROOT ramdisk for debugging init. I have spent most of the summer debugging the random memory corruption which prevented the kernel from booting on Android Emulator. I have tried various methods, like emulating TLS/PCPU with a memory page, but none of them helped. By trying to build a kernel for VERSATILEPB and running in QEMU I have verified it's not the problem in sources/compiler. By porting board code from Android Emulator to QEMU and observing it booting I came to the conclusion that the problem was caused by something in Android Emulator which is based on a very old version of QEMU. Ultimately I decided to try a "nightly" build of emulator, and that has resolved the problem. Unfortunately, I was unable to figure out the precise difference between Linux and FreeBSD MMU management that prevented FreeBSD from booting on regular builds of the emulator, but I have decided to focus on getting device drivers working first. Today I have finished implementing the MMC driver which has allowed to boot into the userland. I have also fixed the timer driver by adding the call to cpu_initclocks_bsp initcall and fixing the timer resolution. I have verified the virtual ethernet driver is also working. I have configured a custom MAC address in qemu and verified the kernel sees it. I have currently pushed the changes against FreeBSD-10 to my git repository. Later this week I plan to clean up the drivers a bit and format the code to look like other FreeBSD driver, rebase it and then push to the GSoC SVN repository. https://github.com/astarasikov/freebsd/commits/android_goldfish_arm_10.0.0?author=astarasikov I used the SD card image for Raspberry Pi which I have obtained from http://ftp4.us.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/10.0/FreeBSD-10.0-STABLE-arm-armv6-RPI-B-20140729-r269271.img.bz2 Here is the boot log of the first successful boot into userland: http://pastebin.com/ZzReDjDH It is very verbose but in the last lines we can see that it has started init, initialized loopback device and showed and getty prompt. You can obtain the prebuilt kernel image from the following link. I have also updated the wiki page with this information. https://drive.google.com/file/d/0B7wcN-tOkdeRN0lRUDJKa2pWM0U/edit?usp=sharing Please note that the nightly builds of Android Emulator are 64-bit and work on Linux and Mac OS X. To get them working on FreeBSD it would be necessary to compile a 32-bit build. If you are interested in just running Android Emulator on FreeBSD, it works just fine once you install linux_base-f10 or some other linux library set. I will provide the emulator binary later. If anyone wants to make a port, please note that you have to use GCC, because QEMU's TCG is broken when compiled with clang :( Due to wasting a lot of time on MMU issues and debugging the MMC driver, I was unable to write the "events" driver for keyboard input. I plan to do it this week. I will also verify that framebuffer driver is working correctly. I have noticed that a new interface is being developed instead of SYSCONS, so maybe I will migrate the driver to it. My overall impression is positive. Although I have spend time debugging MMU, I have learnt about the UMA memory allocator in the process. I want to resolve the remaining issues in the next two weeks and then I plan to add the support for the OMAP5 System-on-Chip to FreeBSD because I have such board and I want to try out Xen DOMU. -- Regards, Alexander From owner-freebsd-arm@FreeBSD.ORG Mon Aug 18 21:28:17 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C0DF3CF for ; Mon, 18 Aug 2014 21:28:17 +0000 (UTC) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 1CF113955 for ; Mon, 18 Aug 2014 21:28:17 +0000 (UTC) Received: by mail-qg0-f48.google.com with SMTP id i50so5075231qgf.7 for ; Mon, 18 Aug 2014 14:28:16 -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:date:message-id:subject :from:to:cc:content-type; bh=RSsauEX2hW07XY6YVNrBNc/EHCg6CLyLN8Du4vEZ+Js=; b=P6ZAwBzqDfj68l51QSyTNZdEONa69rOFg86FZ75tXxIlTG5mi5DrpMQxqgIhS36qoN jo+H1gleCMyMNl8GbS+deHD1ZEot74PNd9vUO7/Od8PzGbGGBdAfrxA4k18/PVgBqkvA UV8JcpLgsw4NGejXniq0PKtJRl/9dCw8890Zjeq+1udsVfSbHwXmpUgWos9+cN2ONAqk 08y9H1prXVYJkjcaNbKCWb7nGPrWMe2NeRVBnSVhjL1UfD26Dc59ZW0pQ3XqLdfC1lvY SVIu9okf2wMxMbXRpxpxdWv2JYvIp9OM2PN8tGv7jZ1/qwVDR+h+YI0aU2t+0RoKLSQB jurw== MIME-Version: 1.0 X-Received: by 10.140.85.74 with SMTP id m68mr56190149qgd.50.1408397296027; Mon, 18 Aug 2014 14:28:16 -0700 (PDT) Sender: hiren.panchasara@gmail.com Received: by 10.96.170.230 with HTTP; Mon, 18 Aug 2014 14:28:15 -0700 (PDT) In-Reply-To: <20130602131611.5fd959af@bender.Home> References: <20130530091525.00b5be20@bender.Home> <3F4EA2FC-FC2D-471E-8133-1D3AF603F908@bsdimp.com> <20130602131611.5fd959af@bender.Home> Date: Mon, 18 Aug 2014 14:28:15 -0700 X-Google-Sender-Auth: 2ud4vmYl4gWqePx8fvrN6sYb-ko Message-ID: Subject: Re: Cortex A50 Series? From: hiren panchasara To: Andrew Turner 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: Mon, 18 Aug 2014 21:28:17 -0000 Hi Andrew, I see you've been committing changes in arm64 project branch. If possible, I'd like to know general status of 64bit arm on FreeBSD. Thanks for your work. Cheers, Hiren From owner-freebsd-arm@FreeBSD.ORG Mon Aug 18 22:31:37 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7902F66 for ; Mon, 18 Aug 2014 22:31:37 +0000 (UTC) Received: from poczta.toomeek.waw.pl (unknown [IPv6:2001:67c:232c:1000::fd9b:4fb4]) by mx1.freebsd.org (Postfix) with ESMTP id 5FD9F3F2A for ; Mon, 18 Aug 2014 22:31:36 +0000 (UTC) Received: from [192.168.137.1] (afnk156.neoplus.adsl.tpnet.pl [178.42.88.156]) by poczta.toomeek.waw.pl (Postfix) with ESMTPSA id 4F59DC601DD for ; Mon, 18 Aug 2014 18:31:24 -0400 (EDT) Message-ID: <53F27EB9.3090805@toomeek.waw.pl> Date: Tue, 19 Aug 2014 00:31:21 +0200 From: TooMeeK Admin User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: Re: U-boot for Banana Pi References: <53EE0F93.6060407@toomeek.waw.pl> <53EE23B1.2020403@toomeek.waw.pl> <53EE402D.8000204@toomeek.waw.pl> <20140815214416.GJ60808@cicely7.cicely.de> <53EFCD6C.5000601@toomeek.waw.pl> <53EFD5D5.7010406@toomeek.waw.pl> <53F0E640.5030506@toomeek.waw.pl> <53F14BD7.1050007@fukaumi.org> <53F1A126.1020408@toomeek.waw.pl> <53F1D8FD.9010903@fukaumi.org> In-Reply-To: <53F1D8FD.9010903@fukaumi.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.9 (poczta.toomeek.waw.pl [0.0.0.0]); Mon, 18 Aug 2014 18:31:25 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.98.1 at a8d2ba546e X-Virus-Status: Clean 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, 18 Aug 2014 22:31:37 -0000 Hello, thanks Naoki, but.. this is my script's header for SD booting image: #!/bin/bash cd /root/banana rm /root/banana/banana.img truncate -s 940M banana.img mdconfig -f banana.img -u0 gpart create -s mbr md0 gpart add -b 1m -s 64m -t fat16 md0 gpart set -a active -i 1 md0 gpart add -t freebsd md0 newfs_msdos -F 16 /dev/md0s1 newfs /dev/md0s2 mount_msdosfs /dev/md0s1 /mnt cp /usr/obj/arm.armv6/usr/src/sys/BANANAPI/kernel /mnt cd /usr/src/sunxi-tools echo "fatload mmc 0 0x40200000 kernel; go 0x40200100" > boot.cmd /usr/src/u-boot-bananapi/tools/mkimage -C none -A arm -T script -d boot.cmd boot.scr cp boot.scr /mnt umount /mnt mdconfig -d -u0 cd /root/banana # Original Banana Pi U-boot loader #dd if=/usr/src/u-boot-sunxi/spl/sunxi-spl.bin conv=notrunc of=banana.img bs=1024 seek=8 #dd if=/usr/src/u-boot-sunxi/u-boot.bin conv=notrunc of=banana.img bs=1024 seek=40 # Lemaker's U-boot loader dd if=/usr/src/u-boot-bananapi/spl/sunxi-spl.bin conv=notrunc of=banana.img bs=1024 seek=8 dd if=/usr/src/u-boot-bananapi/u-boot.bin conv=notrunc of=banana.img bs=1024 seek=40 The script output is similar to this: root@freebsd:~/banana # bash prepare_boot.sh md0 created md0s1 added active set on md0s1 md0s2 added /dev/md0s1: 130888 sectors in 16361 FAT16 clusters (4096 bytes/cluster) BytesPerSec=512 SecPerClust=8 ResSectors=1 FATs=2 RootDirEnts=512 Media=0xf0 FATsecs=64 SecPerTrack=17 Heads=255 HiddenSecs=0 HugeSectors=131053 /dev/md0s2: 875.0MB (1792000 sectors) block size 32768, fragment size 4096 using 4 cylinder groups of 218.78MB, 7001 blks, 28032 inodes. super-block backups (for fsck -b #) at: 192, 448256, 896320, 1344384 Image Name: Created: Tue Aug 19 02:20:04 2014 Image Type: ARM Linux Script (uncompressed) Data Size: 55 Bytes = 0.05 kB = 0.00 MB Load Address: 00000000 Entry Point: 00000000 Contents: Image 0: 47 Bytes = 0.05 kB = 0.00 MB 23+1 records in 23+1 records out 24064 bytes transferred in 0.003972 secs (6058691 bytes/sec) 235+1 records in 235+1 records out 241544 bytes transferred in 0.003128 secs (77224557 bytes/sec) Original Banana Pi U-boot loader output: U-Boot SPL 2014.04-10704-gf625d1d (Aug 16 2014 - 23:44:23) Board: Bananapi DRAM: 1024 MiB CPU: 960000000Hz, AXI/AHB/APB: 3/2/2 spl: not an uImage at 1600 spl: not an uImage at 80 ### ERROR ### Please RESET the board ### And Lemaker's: U-Boot SPL 2014.04-10693-gf954935 (Aug 17 2014 - 21:41:27) Board: Bananapi DRAM: 1024 MiB CPU: 960000000Hz, AXI/AHB/APB: 3/2/2 spl: not an uImage at 1600 spl: not an uImage at 80 ### ERROR ### Please RESET the board ### The only way it works is: # Cubieboard's 2 U-boot loader from FreeBSD Wiki dd if=sunxi-spl.bin conv=notrunc of=banana.img bs=1024 seek=8 dd if=u-boot.bin conv=notrunc of=banana.img bs=1024 seek=32 And according to https://github.com/linux-sunxi/u-boot-sunxi/wiki "If using v2013.07 or earlier then the procedure is slightly different dd if=spl/sunxi-spl.bin of=/dev/sdX bs=1024 seek=8 dd if=u-boot.bin of=/dev/sdX bs=1024 seek=32" So it SHOULD be seek=40 and it's not working anyway.. I suspect wrong U-boot may cause these memory problems too (kernel not booting with 1024MB nad 768MB addressed). Cheers, TooMeeK W dniu 2014-08-18 12:44, FUKAUMI Naoki pisze: > > On 08/18/2014 03:45 PM, TooMeeK Admin wrote: >> I'm working on image, not raw device. >> So "conv=notrun" is needed to avoid destroying it completly.. >> >> Note that partitions start outside bootloader, so ~1MB after this data. > > please see the number after *seek=* > >>>> dd if=/usr/src/u-boot-sunxi/spl/sunxi-spl.bin conv=notrunc >>>> of=banana.img >>>> bs=1024 seek=8 >>>> dd if=/usr/src/u-boot-sunxi/u-boot.bin conv=notrunc of=banana.img >>>> bs=1024 seek=32 >>> >>> from https://github.com/linux-sunxi/u-boot-sunxi/wiki >>> >>> dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX bs=1024 seek=8 >>> >>> or >>> >>> dd if=spl/sunxi-spl.bin of=/dev/sdX bs=1024 seek=8 >>> dd if=u-boot.img of=/dev/sdX bs=1024 seek=40 > From owner-freebsd-arm@FreeBSD.ORG Tue Aug 19 02:51:04 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54734F40 for ; Tue, 19 Aug 2014 02:51:04 +0000 (UTC) Received: from mail.naobsd.org (7c294571.i-revonet.jp [124.41.69.113]) (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 DF33933DD for ; Tue, 19 Aug 2014 02:51:03 +0000 (UTC) Received: from [192.168.1.135] ([192.168.1.135]) (authenticated bits=0) by mail.naobsd.org (8.13.6.20060614/8.13.6) with ESMTP id s7J2cqRR004390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 19 Aug 2014 11:38:53 +0900 (JST) Message-ID: <53F2B8BC.3000403@naobsd.org> Date: Tue, 19 Aug 2014 11:38:52 +0900 From: FUKAUMI Naoki User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: Re: U-boot for Banana Pi References: <53EE0F93.6060407@toomeek.waw.pl> <53EE23B1.2020403@toomeek.waw.pl> <53EE402D.8000204@toomeek.waw.pl> <20140815214416.GJ60808@cicely7.cicely.de> <53EFCD6C.5000601@toomeek.waw.pl> <53EFD5D5.7010406@toomeek.waw.pl> <53F0E640.5030506@toomeek.waw.pl> <53F14BD7.1050007@fukaumi.org> <53F1A126.1020408@toomeek.waw.pl> <53F1D8FD.9010903@fukaumi.org> <53F27EB9.3090805@toomeek.waw.pl> In-Reply-To: <53F27EB9.3090805@toomeek.waw.pl> Content-Type: text/plain; charset=windows-1252; format=flowed 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, 19 Aug 2014 02:51:04 -0000 hi (sorry, forgot to sent to ML) On 08/19/2014 07:31 AM, TooMeeK Admin wrote: > # Original Banana Pi U-boot loader > #dd if=/usr/src/u-boot-sunxi/spl/sunxi-spl.bin conv=notrunc > of=banana.img bs=1024 seek=8 > #dd if=/usr/src/u-boot-sunxi/u-boot.bin conv=notrunc of=banana.img > bs=1024 seek=40 > # Lemaker's U-boot loader > dd if=/usr/src/u-boot-bananapi/spl/sunxi-spl.bin conv=notrunc > of=banana.img bs=1024 seek=8 > dd if=/usr/src/u-boot-bananapi/u-boot.bin conv=notrunc of=banana.img > bs=1024 seek=40 : > And according to https://github.com/linux-sunxi/u-boot-sunxi/wiki > "If using v2013.07 or earlier then the procedure is slightly different > dd if=spl/sunxi-spl.bin of=/dev/sdX bs=1024 seek=8 > dd if=u-boot.bin of=/dev/sdX bs=1024 seek=32" > > So it SHOULD be seek=40 and it's not working anyway.. sorry, I misunderstood about you're using of=(file) and conv=notrunc. as you said, seek=32 should be correct... > The only way it works is: > # Cubieboard's 2 U-boot loader from FreeBSD Wiki > dd if=sunxi-spl.bin conv=notrunc of=banana.img bs=1024 seek=8 > dd if=u-boot.bin conv=notrunc of=banana.img bs=1024 seek=32 did you download these files from my site? (androtab.info) -- FUKAUMI Naoki From owner-freebsd-arm@FreeBSD.ORG Tue Aug 19 06:05:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D72E37EF for ; Tue, 19 Aug 2014 06:05:15 +0000 (UTC) Received: from mail.naobsd.org (7c294571.i-revonet.jp [124.41.69.113]) (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 6BA6A3336 for ; Tue, 19 Aug 2014 06:05:14 +0000 (UTC) Received: from [192.168.1.135] ([192.168.1.135]) (authenticated bits=0) by mail.naobsd.org (8.13.6.20060614/8.13.6) with ESMTP id s7J65BMR005685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 19 Aug 2014 15:05:11 +0900 (JST) Message-ID: <53F2E917.3010809@naobsd.org> Date: Tue, 19 Aug 2014 15:05:11 +0900 From: FUKAUMI Naoki User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: u-boot images for cubieboard2 Content-Type: text/plain; charset=utf-8; format=flowed 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, 19 Aug 2014 06:05:15 -0000 Hi, on wiki, there are links to my site(files.androtab.info) for u-boot binaries for cubieboard2. these binaries are old, I'm trying latest u-boot from upstream http://git.denx.de/?p=u-boot/u-boot-sunxi.git;a=summary I'll prepare new u-boot binaries and remove old one soon. I cannot edit wiki, so I'll send e-mail to this ML when it's ready. Regards, (if someone at freebsd.org can make/put official u-boot binary on *.freebsd.org, it will be better) -- FUKAUMI Naoki From owner-freebsd-arm@FreeBSD.ORG Tue Aug 19 17:41: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0573CEAF; Tue, 19 Aug 2014 17:41:03 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (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 526C53AFA; Tue, 19 Aug 2014 17:41:02 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id l4so5772154lbv.2 for ; Tue, 19 Aug 2014 10:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KcLvJ0fWZXNUlN8aaO0iyvzErsEKtnwJpQvdpZZBN8U=; b=f/2LYFzz3Mo13hrV5wMOataXf9XMC5WQbse2vKsd0F+lcYvlY4uIdBIh4f8nmZwRM5 CQcbJAbre1f40CFw+5y7ffrI1jXNiQErBPt32+tetFcC71NLGbzUmoTN6j4z1YG2G13u MjWYO6MU380rjZYnreZPX/ONsV80GYWIzKuLilh1ITeU2d2XFv5wPEyXgSV/CnLibx3U i79PL1rK5z+MRSjMdCMH22dsomZVDnW/LhK7c3GG1/TKXcAUYsDNK9zFZqwRm7uTbo+G 1QLtVHSPOi19VwJOLRDbo2YeRccwzu1DX4mVo8wqWA/ul6f3pt77xbjupRize6gKcW5g D4Pg== X-Received: by 10.152.206.98 with SMTP id ln2mr37896204lac.45.1408470060234; Tue, 19 Aug 2014 10:41:00 -0700 (PDT) Received: from [192.168.1.105] (c-d135e155.556-1-64736c11.cust.bredbandsbolaget.se. [85.225.53.209]) by mx.google.com with ESMTPSA id dm6sm33039781lbc.31.2014.08.19.10.40.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 10:40:59 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Olavi Kumpulainen In-Reply-To: <53D2CFBE.3040207@fgznet.ch> Date: Tue, 19 Aug 2014 19:40:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <834BA562-84ED-425C-9D61-0A235A28A94A@gmail.com> References: <1405809318.85788.35.camel@revolution.hippie.lan> <1406063473.71975.8.camel@revolution.hippie.lan> <53D2CFBE.3040207@fgznet.ch> To: Ian Lepore 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, 19 Aug 2014 17:41:03 -0000 On 25 Jul 2014, at 23:44 , Andreas Tobler = wrote: > On 22.07.14 23:11, Ian Lepore wrote: >> On Sat, 2014-07-19 at 16:35 -0600, Ian Lepore wrote: >>> On Sat, 2014-06-07 at 14:12 +0200, Olavi Kumpulainen wrote: >>>> [c++ exceptions don't work and related discussion] >>>=20 >>> I checked in a partial fix for c++ exception handling in r268893. = It >>> fixes the specific problem you detailed above, which was essentially >>> that the __gnu_Unwind_Find_exidx() function was not available in any >>> shared library, making the unwinder fall back to using the = __exidx_start >>> and end symbols, which are only valid in a statically-linked app. >>>=20 >>> With the new function in place, exceptions are closer to working = with >>> gcc 4.2.1, but still don't work with clang. With gcc, some things = work >>> and some things don't. For example if you throw an exception and in = the >>> same function have a catch with the right specific type it = segfaults, >>> but a catch(...) will catch it without problems. But you can catch = an >>> exception by type if the catch is in a function higher up the call = chain >>> from the place it was thrown. >>>=20 >>> We're continuing to debug this at $work, and welcome any input if = anyone >>> else makes progress with it. Right now we still don't know whether = the >>> segfaults are because of bad unwinder library code or bad unwind = data >>> emitted by gcc. (I sure hope it's the library, because that's = easier to >>> fix.) >>>=20 >>> On the clang front, it has been said that c++ exceptions work in = clang >>> 3.5, so we tried the clang-devel port, and it didn't just work. But = it >>> turns out that port hasn't been updated for quite a while, so we may = not >>> have tested the code that's supposed to work right. While trying = that I >>> discovered that clang 3.5 isn't scheduled for release for about = another >>> year, so that really isn't a viable solution for anyone with = near-term >>> needs, unless the required changes can be cherry-picked and brought = into >>> our version of 3.4. >>>=20 >>> -- Ian >>=20 >> Another update to this... today I committed r268993 and r268994, and = now >> I believe arm eabi c++ exceptions are fully working with gcc. I = haven't >> run an extensive test suite, but all the test cases we've been using = at >> $work to debug this now work correctly. >=20 > Thank you! Confirmed. My test cases which are working with gcc-4.10 = are now also working with the system gcc, 4.2.1. > I totally forgot about this change. I have it in my local gcc tree = since a while but I forgot about..... >=20 > Andreas >=20 >=20 Please excuse my late reply. I=92ve been away from keyboard for a while. I back-ported r268893, r268993 and r268994 to stable/10 for beaglebone. = C++ exceptions works for static builds, but not for binaries linked to = shared libs. Since this seems to work ok in HEAD, I=92m obviously missing something. = Do any of you guys have any ideas? Cheers /Olavi From owner-freebsd-arm@FreeBSD.ORG Tue Aug 19 18:22:00 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FF72D4C for ; Tue, 19 Aug 2014 18:22:00 +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 3F7A83FF6 for ; Tue, 19 Aug 2014 18:21:59 +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 1XJo2g-0001y8-NV; Tue, 19 Aug 2014 18:21:58 +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 s7JILvgf051789; Tue, 19 Aug 2014 12:21:57 -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+rIXIrOEWskVk1bjqs4OCb X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Ian Lepore To: Olavi Kumpulainen In-Reply-To: <834BA562-84ED-425C-9D61-0A235A28A94A@gmail.com> References: <1405809318.85788.35.camel@revolution.hippie.lan> <1406063473.71975.8.camel@revolution.hippie.lan> <53D2CFBE.3040207@fgznet.ch> <834BA562-84ED-425C-9D61-0A235A28A94A@gmail.com> Content-Type: text/plain; charset="iso-8859-7" Date: Tue, 19 Aug 2014 12:21:57 -0600 Message-ID: <1408472517.56408.659.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 s7JILvgf051789 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, 19 Aug 2014 18:22:00 -0000 On Tue, 2014-08-19 at 19:40 +0200, Olavi Kumpulainen wrote: > On 25 Jul 2014, at 23:44 , Andreas Tobler wro= te: >=20 > > On 22.07.14 23:11, Ian Lepore wrote: > >> On Sat, 2014-07-19 at 16:35 -0600, Ian Lepore wrote: > >>> On Sat, 2014-06-07 at 14:12 +0200, Olavi Kumpulainen wrote: > >>>> [c++ exceptions don't work and related discussion] > >>>=20 > >>> I checked in a partial fix for c++ exception handling in r268893. = It > >>> fixes the specific problem you detailed above, which was essentiall= y > >>> that the __gnu_Unwind_Find_exidx() function was not available in an= y > >>> shared library, making the unwinder fall back to using the __exidx_= start > >>> and end symbols, which are only valid in a statically-linked app. > >>>=20 > >>> With the new function in place, exceptions are closer to working wi= th > >>> gcc 4.2.1, but still don't work with clang. With gcc, some things = work > >>> and some things don't. For example if you throw an exception and i= n the > >>> same function have a catch with the right specific type it segfault= s, > >>> but a catch(...) will catch it without problems. But you can catch= an > >>> exception by type if the catch is in a function higher up the call = chain > >>> from the place it was thrown. > >>>=20 > >>> We're continuing to debug this at $work, and welcome any input if a= nyone > >>> else makes progress with it. Right now we still don't know whether= the > >>> segfaults are because of bad unwinder library code or bad unwind da= ta > >>> emitted by gcc. (I sure hope it's the library, because that's easi= er to > >>> fix.) > >>>=20 > >>> On the clang front, it has been said that c++ exceptions work in cl= ang > >>> 3.5, so we tried the clang-devel port, and it didn't just work. Bu= t it > >>> turns out that port hasn't been updated for quite a while, so we ma= y not > >>> have tested the code that's supposed to work right. While trying t= hat I > >>> discovered that clang 3.5 isn't scheduled for release for about ano= ther > >>> year, so that really isn't a viable solution for anyone with near-t= erm > >>> needs, unless the required changes can be cherry-picked and brought= into > >>> our version of 3.4. > >>>=20 > >>> -- Ian > >>=20 > >> Another update to this... today I committed r268993 and r268994, and= now > >> I believe arm eabi c++ exceptions are fully working with gcc. I hav= en't > >> run an extensive test suite, but all the test cases we've been using= at > >> $work to debug this now work correctly. > >=20 > > Thank you! Confirmed. My test cases which are working with gcc-4.10 a= re now also working with the system gcc, 4.2.1. > > I totally forgot about this change. I have it in my local gcc tree si= nce a while but I forgot about..... > >=20 > > Andreas > >=20 > >=20 >=20 > Please excuse my late reply. I=A2ve been away from keyboard for a while. >=20 > I back-ported r268893, r268993 and r268994 to stable/10 for beaglebone= . C++ exceptions works for static builds, but not for binaries linked to = shared libs. >=20 > Since this seems to work ok in HEAD, I=A2m obviously missing something.= Do any of you guys have any ideas? >=20 > Cheers >=20 I'm not sure what you mean by "backported to stable/10", I merged all the necessary changes to stable-10 as r269792 on Aug 10. Are you working with a checkout from earlier than that? If so, just updating should fix it for you. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Aug 19 20:04:13 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68D9A55C; Tue, 19 Aug 2014 20:04:13 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (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 B308F39F2; Tue, 19 Aug 2014 20:04:12 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id l4so5921689lbv.2 for ; Tue, 19 Aug 2014 13:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HZC2W+u8etfq6i1aQGwxZvQIbMrwtox53jrb+1p7nUY=; b=i1yg8Ez8utPVP3CIBAsZBfYFS4Q3tQEcMn3jZbrRiEN6JRJthbVxsqarXgNqFrxBmS LM2/yoaL0jCwtNKUlZN9ZX8siZf/ntjbbvqx5r8kR56e7HXYOHOerZ2vEa8U8xAq7Fej Vgb4Y/uXoMkUzR4EC7PMblAP31CXHUnSxqCCXWJSunlJYhNVnHS3a68tLbf7xLJZRYnM sI3fBdUxJCqZ2UVlwO2sN3bEv0FrDBu3xy62TKrR0hlucqV/lO1LehX6c+iSH7lbc/F2 zxXu3wwFWyhAyn9C5kBe7kxVVaz5XlJE0+8XCtocTaP5oW/7CgVyklV036iLj39HtcIp PsPw== X-Received: by 10.152.5.102 with SMTP id r6mr37180749lar.81.1408478650731; Tue, 19 Aug 2014 13:04:10 -0700 (PDT) Received: from [192.168.1.105] (c-d135e155.556-1-64736c11.cust.bredbandsbolaget.se. [85.225.53.209]) by mx.google.com with ESMTPSA id d4sm19911454lbe.47.2014.08.19.13.04.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 13:04:09 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-7 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Olavi Kumpulainen In-Reply-To: <1408472517.56408.659.camel@revolution.hippie.lan> Date: Tue, 19 Aug 2014 22:04:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <365DD1BA-0282-4DBC-BF20-125C1EEADA82@gmail.com> References: <1405809318.85788.35.camel@revolution.hippie.lan> <1406063473.71975.8.camel@revolution.hippie.lan> <53D2CFBE.3040207@fgznet.ch> <834BA562-84ED-425C-9D61-0A235A28A94A@gmail.com> <1408472517.56408.659.camel@revolution.hippie.lan> To: Ian Lepore 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, 19 Aug 2014 20:04:13 -0000 On 19 Aug 2014, at 20:21 , Ian Lepore wrote: > On Tue, 2014-08-19 at 19:40 +0200, Olavi Kumpulainen wrote: >> On 25 Jul 2014, at 23:44 , Andreas Tobler = wrote: >>=20 >>> On 22.07.14 23:11, Ian Lepore wrote: >>>> On Sat, 2014-07-19 at 16:35 -0600, Ian Lepore wrote: >>>>> On Sat, 2014-06-07 at 14:12 +0200, Olavi Kumpulainen wrote: >>>>>> [c++ exceptions don't work and related discussion] >>>>>=20 >>>>> I checked in a partial fix for c++ exception handling in r268893. = It >>>>> fixes the specific problem you detailed above, which was = essentially >>>>> that the __gnu_Unwind_Find_exidx() function was not available in = any >>>>> shared library, making the unwinder fall back to using the = __exidx_start >>>>> and end symbols, which are only valid in a statically-linked app. >>>>>=20 >>>>> With the new function in place, exceptions are closer to working = with >>>>> gcc 4.2.1, but still don't work with clang. With gcc, some things = work >>>>> and some things don't. For example if you throw an exception and = in the >>>>> same function have a catch with the right specific type it = segfaults, >>>>> but a catch(...) will catch it without problems. But you can = catch an >>>>> exception by type if the catch is in a function higher up the call = chain >>>>> from the place it was thrown. >>>>>=20 >>>>> We're continuing to debug this at $work, and welcome any input if = anyone >>>>> else makes progress with it. Right now we still don't know = whether the >>>>> segfaults are because of bad unwinder library code or bad unwind = data >>>>> emitted by gcc. (I sure hope it's the library, because that's = easier to >>>>> fix.) >>>>>=20 >>>>> On the clang front, it has been said that c++ exceptions work in = clang >>>>> 3.5, so we tried the clang-devel port, and it didn't just work. = But it >>>>> turns out that port hasn't been updated for quite a while, so we = may not >>>>> have tested the code that's supposed to work right. While trying = that I >>>>> discovered that clang 3.5 isn't scheduled for release for about = another >>>>> year, so that really isn't a viable solution for anyone with = near-term >>>>> needs, unless the required changes can be cherry-picked and = brought into >>>>> our version of 3.4. >>>>>=20 >>>>> -- Ian >>>>=20 >>>> Another update to this... today I committed r268993 and r268994, = and now >>>> I believe arm eabi c++ exceptions are fully working with gcc. I = haven't >>>> run an extensive test suite, but all the test cases we've been = using at >>>> $work to debug this now work correctly. >>>=20 >>> Thank you! Confirmed. My test cases which are working with gcc-4.10 = are now also working with the system gcc, 4.2.1. >>> I totally forgot about this change. I have it in my local gcc tree = since a while but I forgot about..... >>>=20 >>> Andreas >>>=20 >>>=20 >>=20 >> Please excuse my late reply. I=A2ve been away from keyboard for a = while. >>=20 >> I back-ported r268893, r268993 and r268994 to stable/10 for = beaglebone. C++ exceptions works for static builds, but not for binaries = linked to shared libs. >>=20 >> Since this seems to work ok in HEAD, I=A2m obviously missing = something. Do any of you guys have any ideas? >>=20 >> Cheers >>=20 >=20 > I'm not sure what you mean by "backported to stable/10", I merged all > the necessary changes to stable-10 as r269792 on Aug 10. Are you > working with a checkout from earlier than that? If so, just updating > should fix it for you. >=20 > -- Ian >=20 >=20 I pulled from github on the 8th of August which is why I missed r269792. = My "backport patches" seems identical to yours though. But better safe than sorry, I=A2ll sync with stable-10 tomorrow. Thanks - /Olavi From owner-freebsd-arm@FreeBSD.ORG Wed Aug 20 01:35: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 165D8CC7 for ; Wed, 20 Aug 2014 01:35:16 +0000 (UTC) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) (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 DDEF03758 for ; Wed, 20 Aug 2014 01:35:15 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id w10so10672404pde.23 for ; Tue, 19 Aug 2014 18:35:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=nTSYZLBbvQxFBNV9x9EiSm5JBeiooEUg3iNZ5pqjFAw=; b=UbWd2Zn5ykUrsXI5mOyzTWKP4SU76Sb9XJwsertqc8W3FmQlUYEKrdw6x9VqesN9LN x0j4LKCEX/mGekqvxaMk7DKX95OUYICIqL4grJyk7zJ6OSa6scwvcFHUVJTH5u0N00QA r5YDNIrZSf5fLwaerGcjGtDU/FLyVffmGionRMJgoqsOxazeP7W0wisl8jn9pbIrq+jE BVy7d3g5C5m5gxloAhk9KpnXqQ30PEbfNjinNZ2QVLtzPJ5ZmrDGigr3liqc0XXxqgwS PkdWJWMgYuUu3NK7jbz+JfOyETCeTIS78gtQf71iqZA0uog23wl6qoZk2VLRjfTK4iml zo3A== X-Gm-Message-State: ALoCoQkAetK6u5npZqwTHEj0DN/Qt65aQMwULEV6Vk/Z2o0IVxuEutcOt4X3fxqjdRKzauKzKGm+ X-Received: by 10.70.10.100 with SMTP id h4mr23625397pdb.162.1408498509448; Tue, 19 Aug 2014 18:35:09 -0700 (PDT) Received: from [192.168.1.100] (c-24-6-220-224.hsd1.ca.comcast.net. [24.6.220.224]) by mx.google.com with ESMTPSA id mz8sm31535065pdb.62.2014.08.19.18.35.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 18:35:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: u-boot images for cubieboard2 From: Tim Kientzle In-Reply-To: <53F2E917.3010809@naobsd.org> Date: Tue, 19 Aug 2014 18:35:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8DBFBC14-FF79-4748-A6AB-0CC21C364875@kientzle.com> References: <53F2E917.3010809@naobsd.org> To: FUKAUMI Naoki 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, 20 Aug 2014 01:35:16 -0000 On Aug 18, 2014, at 11:05 PM, FUKAUMI Naoki wrote: > Hi, >=20 > on wiki, there are links to my site(files.androtab.info) for u-boot = binaries for cubieboard2. >=20 > these binaries are old, I'm trying latest u-boot from upstream > http://git.denx.de/?p=3Du-boot/u-boot-sunxi.git;a=3Dsummary >=20 > I'll prepare new u-boot binaries and remove old one soon. I cannot = edit wiki, so I'll send e-mail to this ML when it's ready. >=20 > Regards, >=20 > (if someone at freebsd.org can make/put official u-boot binary on = *.freebsd.org, it will be better) The best way to do this is to create and submit a new port. You can copy sysutils/u-boot-beaglebone-eabi to get started. Tim From owner-freebsd-arm@FreeBSD.ORG Wed Aug 20 06:12:45 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48CAD3A3 for ; Wed, 20 Aug 2014 06:12:45 +0000 (UTC) Received: from mail.naobsd.org (7c294571.i-revonet.jp [124.41.69.113]) (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 DB4173F56 for ; Wed, 20 Aug 2014 06:12:43 +0000 (UTC) Received: from [192.168.1.135] ([192.168.1.135]) (authenticated bits=0) by mail.naobsd.org (8.13.6.20060614/8.13.6) with ESMTP id s7K6CYdX029594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 20 Aug 2014 15:12:35 +0900 (JST) Message-ID: <53F43C52.30101@naobsd.org> Date: Wed, 20 Aug 2014 15:12:34 +0900 From: FUKAUMI Naoki User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Tim Kientzle Subject: Re: u-boot images for cubieboard2 References: <53F2E917.3010809@naobsd.org> <8DBFBC14-FF79-4748-A6AB-0CC21C364875@kientzle.com> In-Reply-To: <8DBFBC14-FF79-4748-A6AB-0CC21C364875@kientzle.com> Content-Type: text/plain; charset=windows-1252; format=flowed 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: Wed, 20 Aug 2014 06:12:45 -0000 hi On 08/20/2014 10:35 AM, Tim Kientzle wrote: >> (if someone at freebsd.org can make/put official u-boot binary on *.freebsd.org, it will be better) > > The best way to do this is to create and submit a new port. > > You can copy sysutils/u-boot-beaglebone-eabi to get started. thank you for your information! I'll try it when I can get working FreeBSD machine and some free time :) -- FUKAUMI Naoki From owner-freebsd-arm@FreeBSD.ORG Wed Aug 20 16:09: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75B2888A; Wed, 20 Aug 2014 16:09:14 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 536853226; Wed, 20 Aug 2014 16:09:13 +0000 (UTC) Received: from bender.lan (97e07ab1.skybroadband.com [151.224.122.177]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id DB42A5DF06; Wed, 20 Aug 2014 16:09:06 +0000 (UTC) Date: Wed, 20 Aug 2014 17:07:54 +0100 From: Andrew Turner To: hiren panchasara Subject: Re: Cortex A50 Series? Message-ID: <20140820170754.1f582a17@bender.lan> In-Reply-To: References: <20130530091525.00b5be20@bender.Home> <3F4EA2FC-FC2D-471E-8133-1D3AF603F908@bsdimp.com> <20130602131611.5fd959af@bender.Home> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Wed, 20 Aug 2014 16:09:14 -0000 On Mon, 18 Aug 2014 14:28:15 -0700 hiren panchasara wrote: > Hi Andrew, > > I see you've been committing changes in arm64 project branch. If > possible, I'd like to know general status of 64bit arm on FreeBSD. It boots on the ARM Foundation Model to the mountroot prompt. I'm currently working on initial userland support. Andrew From owner-freebsd-arm@FreeBSD.ORG Wed Aug 20 17:19:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB863FF6; Wed, 20 Aug 2014 17:19:49 +0000 (UTC) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (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 0F5E539E0; Wed, 20 Aug 2014 17:19:48 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id b8so7423820lan.5 for ; Wed, 20 Aug 2014 10:19:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yQ11qGcTR2GCedzydwFi3dFKhnRoGzDyaJEBTrt4r+s=; b=t/z6l5wEP/SK8WL45OU9k+4aQtDduU1vn7rTvTDfjkRHe1S+ln2QvvfwtPIggbxrBp XFTRqDs9CWT7LQKi099OUmm1XWCe1jg4hRm7hQuj5vW6r7dT2f5Z7eHDJX9aqcgVRw1g hObp4luoGk0vQMdBH6PHWhob7IyYSZIBYcKDe1UtoDbwHDyTH+qNKLjQW2gU+fzVJFUu c2uwLRJazZCREQUybIBftSfT1DWezgfW1+mI0oi9cdbGMF6JwV3MygsJP+dH7nRZNLfZ BGAhRJihlzJudA9NwPaAXkJC4uXZl4Ma5DOaIKfoVLiEM3sYflPcFElgemBd3S4J3ekn sxHA== X-Received: by 10.112.165.68 with SMTP id yw4mr42463698lbb.5.1408555186938; Wed, 20 Aug 2014 10:19:46 -0700 (PDT) Received: from [192.168.1.105] (c-d135e155.556-1-64736c11.cust.bredbandsbolaget.se. [85.225.53.209]) by mx.google.com with ESMTPSA id wv7sm14768286lac.30.2014.08.20.10.19.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Aug 2014 10:19:45 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-7 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Olavi Kumpulainen In-Reply-To: <1408472517.56408.659.camel@revolution.hippie.lan> Date: Wed, 20 Aug 2014 19:19:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1405809318.85788.35.camel@revolution.hippie.lan> <1406063473.71975.8.camel@revolution.hippie.lan> <53D2CFBE.3040207@fgznet.ch> <834BA562-84ED-425C-9D61-0A235A28A94A@gmail.com> <1408472517.56408.659.camel@revolution.hippie.lan> To: Ian Lepore 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, 20 Aug 2014 17:19:49 -0000 On 19 Aug 2014, at 20:21 , Ian Lepore wrote: > On Tue, 2014-08-19 at 19:40 +0200, Olavi Kumpulainen wrote: >> On 25 Jul 2014, at 23:44 , Andreas Tobler = wrote: >>=20 >>> On 22.07.14 23:11, Ian Lepore wrote: >>>> On Sat, 2014-07-19 at 16:35 -0600, Ian Lepore wrote: >>>>> On Sat, 2014-06-07 at 14:12 +0200, Olavi Kumpulainen wrote: >>>>>> [c++ exceptions don't work and related discussion] >>>>>=20 >>>>> I checked in a partial fix for c++ exception handling in r268893. = It >>>>> fixes the specific problem you detailed above, which was = essentially >>>>> that the __gnu_Unwind_Find_exidx() function was not available in = any >>>>> shared library, making the unwinder fall back to using the = __exidx_start >>>>> and end symbols, which are only valid in a statically-linked app. >>>>>=20 >>>>> With the new function in place, exceptions are closer to working = with >>>>> gcc 4.2.1, but still don't work with clang. With gcc, some things = work >>>>> and some things don't. For example if you throw an exception and = in the >>>>> same function have a catch with the right specific type it = segfaults, >>>>> but a catch(...) will catch it without problems. But you can = catch an >>>>> exception by type if the catch is in a function higher up the call = chain >>>>> from the place it was thrown. >>>>>=20 >>>>> We're continuing to debug this at $work, and welcome any input if = anyone >>>>> else makes progress with it. Right now we still don't know = whether the >>>>> segfaults are because of bad unwinder library code or bad unwind = data >>>>> emitted by gcc. (I sure hope it's the library, because that's = easier to >>>>> fix.) >>>>>=20 >>>>> On the clang front, it has been said that c++ exceptions work in = clang >>>>> 3.5, so we tried the clang-devel port, and it didn't just work. = But it >>>>> turns out that port hasn't been updated for quite a while, so we = may not >>>>> have tested the code that's supposed to work right. While trying = that I >>>>> discovered that clang 3.5 isn't scheduled for release for about = another >>>>> year, so that really isn't a viable solution for anyone with = near-term >>>>> needs, unless the required changes can be cherry-picked and = brought into >>>>> our version of 3.4. >>>>>=20 >>>>> -- Ian >>>>=20 >>>> Another update to this... today I committed r268993 and r268994, = and now >>>> I believe arm eabi c++ exceptions are fully working with gcc. I = haven't >>>> run an extensive test suite, but all the test cases we've been = using at >>>> $work to debug this now work correctly. >>>=20 >>> Thank you! Confirmed. My test cases which are working with gcc-4.10 = are now also working with the system gcc, 4.2.1. >>> I totally forgot about this change. I have it in my local gcc tree = since a while but I forgot about..... >>>=20 >>> Andreas >>>=20 >>>=20 >>=20 >> Please excuse my late reply. I=A2ve been away from keyboard for a = while. >>=20 >> I back-ported r268893, r268993 and r268994 to stable/10 for = beaglebone. C++ exceptions works for static builds, but not for binaries = linked to shared libs. >>=20 >> Since this seems to work ok in HEAD, I=A2m obviously missing = something. Do any of you guys have any ideas? >>=20 >> Cheers >>=20 >=20 > I'm not sure what you mean by "backported to stable/10", I merged all > the necessary changes to stable-10 as r269792 on Aug 10. Are you > working with a checkout from earlier than that? If so, just updating > should fix it for you. >=20 > -- Ian >=20 >=20 Updating to stable-10 as of today didn=A2t help. I=A2m running a clean = checkout except for a couple of drivers in the kernel. This makes me think I have a bad src.conf - How shall I configure the = build for this to work? /Olavi From owner-freebsd-arm@FreeBSD.ORG Wed Aug 20 19:19:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 174BC7C1 for ; Wed, 20 Aug 2014 19:19:56 +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 C765E3BC8 for ; Wed, 20 Aug 2014 19:19:55 +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 1XKBQH-000IIu-Ng; Wed, 20 Aug 2014 19:19: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 s7KJJq15054150; Wed, 20 Aug 2014 13:19:52 -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+mmhKEKuhlp5cuC6fQRBu5 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Ian Lepore To: Olavi Kumpulainen In-Reply-To: References: <1405809318.85788.35.camel@revolution.hippie.lan> <1406063473.71975.8.camel@revolution.hippie.lan> <53D2CFBE.3040207@fgznet.ch> <834BA562-84ED-425C-9D61-0A235A28A94A@gmail.com> <1408472517.56408.659.camel@revolution.hippie.lan> Content-Type: text/plain; charset="iso-8859-7" Date: Wed, 20 Aug 2014 13:19:52 -0600 Message-ID: <1408562392.1150.4.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 s7KJJq15054150 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, 20 Aug 2014 19:19:56 -0000 On Wed, 2014-08-20 at 19:19 +0200, Olavi Kumpulainen wrote: > On 19 Aug 2014, at 20:21 , Ian Lepore wrote: >=20 > > On Tue, 2014-08-19 at 19:40 +0200, Olavi Kumpulainen wrote: > >> On 25 Jul 2014, at 23:44 , Andreas Tobler = wrote: > >>=20 > >>> On 22.07.14 23:11, Ian Lepore wrote: > >>>> On Sat, 2014-07-19 at 16:35 -0600, Ian Lepore wrote: > >>>>> On Sat, 2014-06-07 at 14:12 +0200, Olavi Kumpulainen wrote: > >>>>>> [c++ exceptions don't work and related discussion] > >>>>>=20 > >>>>> I checked in a partial fix for c++ exception handling in r268893.= It > >>>>> fixes the specific problem you detailed above, which was essentia= lly > >>>>> that the __gnu_Unwind_Find_exidx() function was not available in = any > >>>>> shared library, making the unwinder fall back to using the __exid= x_start > >>>>> and end symbols, which are only valid in a statically-linked app. > >>>>>=20 > >>>>> With the new function in place, exceptions are closer to working = with > >>>>> gcc 4.2.1, but still don't work with clang. With gcc, some thing= s work > >>>>> and some things don't. For example if you throw an exception and= in the > >>>>> same function have a catch with the right specific type it segfau= lts, > >>>>> but a catch(...) will catch it without problems. But you can cat= ch an > >>>>> exception by type if the catch is in a function higher up the cal= l chain > >>>>> from the place it was thrown. > >>>>>=20 > >>>>> We're continuing to debug this at $work, and welcome any input if= anyone > >>>>> else makes progress with it. Right now we still don't know wheth= er the > >>>>> segfaults are because of bad unwinder library code or bad unwind = data > >>>>> emitted by gcc. (I sure hope it's the library, because that's ea= sier to > >>>>> fix.) > >>>>>=20 > >>>>> On the clang front, it has been said that c++ exceptions work in = clang > >>>>> 3.5, so we tried the clang-devel port, and it didn't just work. = But it > >>>>> turns out that port hasn't been updated for quite a while, so we = may not > >>>>> have tested the code that's supposed to work right. While trying= that I > >>>>> discovered that clang 3.5 isn't scheduled for release for about a= nother > >>>>> year, so that really isn't a viable solution for anyone with near= -term > >>>>> needs, unless the required changes can be cherry-picked and broug= ht into > >>>>> our version of 3.4. > >>>>>=20 > >>>>> -- Ian > >>>>=20 > >>>> Another update to this... today I committed r268993 and r268994, a= nd now > >>>> I believe arm eabi c++ exceptions are fully working with gcc. I h= aven't > >>>> run an extensive test suite, but all the test cases we've been usi= ng at > >>>> $work to debug this now work correctly. > >>>=20 > >>> Thank you! Confirmed. My test cases which are working with gcc-4.10= are now also working with the system gcc, 4.2.1. > >>> I totally forgot about this change. I have it in my local gcc tree = since a while but I forgot about..... > >>>=20 > >>> Andreas > >>>=20 > >>>=20 > >>=20 > >> Please excuse my late reply. I=A2ve been away from keyboard for a wh= ile. > >>=20 > >> I back-ported r268893, r268993 and r268994 to stable/10 for beagleb= one. C++ exceptions works for static builds, but not for binaries linked = to shared libs. > >>=20 > >> Since this seems to work ok in HEAD, I=A2m obviously missing somethi= ng. Do any of you guys have any ideas? > >>=20 > >> Cheers > >>=20 > >=20 > > I'm not sure what you mean by "backported to stable/10", I merged all > > the necessary changes to stable-10 as r269792 on Aug 10. Are you > > working with a checkout from earlier than that? If so, just updating > > should fix it for you. > >=20 > > -- Ian > >=20 > >=20 >=20 >=20 > Updating to stable-10 as of today didn=A2t help. I=A2m running a clean = checkout except for a couple of drivers in the kernel. > This makes me think I have a bad src.conf - How shall I configure the b= uild for this to work? >=20 > /Olavi >=20 >=20 >=20 >=20 You need to use GCC, not clang, as the compiler. Exceptions are just broken on clang 3.4, so we're waiting for 3.5 (should be released any time now I think). To compile with gcc, put this in your /etc/make.conf: WITH_GCC=3Dyes WITH_GNUCXX=3Dyes WITH_GCC_BOOTSTRAP=3Dyes WITHOUT_CLANG=3Dyes WITHOUT_CLANG_IS_CC=3Dyes WITHOUT_CLANG_BOOTSTRAP=3Dyes -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 21 04:48:59 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66426ABA for ; Thu, 21 Aug 2014 04:48:59 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 035F633DD for ; Thu, 21 Aug 2014 04:48:58 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hi2so8071948wib.10 for ; Wed, 20 Aug 2014 21:48:56 -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=HkAH2wv/awPEJSwUrQJld8r+Pt/KOMiJ6AoeOx2jEqo=; b=EA79ruz/xJqKiTfWCl4MNSqR1rRjVIXNBmiH1jnqr51sCR3JXq+ZI8hLmGO2D7eMvf aIhpzlKpPpx+xakK/DNfHUhC2orN541E+k/JmqWHxRIK1gUWgEbPwJ43ULq449mO3LW+ IYYmQmXfSsBzCZT2l2eFGRZhJCB37hY+b/dZiHVatuU2EuQkGLxNA1pXiBQAo0JCi/sn XKewhCQuJMoIT9Z+JN6UWQvYpXd2gju/l1usV+fftNaxWc82y8nwukwVvJoVUfp4CmQF Nurg364r/TzW978pd74Fb61ejLIcZtMwnN2Dx1HoanFToDyUo7Ep2GvlRR2URpcC6ek7 vZeA== MIME-Version: 1.0 X-Received: by 10.180.104.42 with SMTP id gb10mr20087132wib.65.1408596536613; Wed, 20 Aug 2014 21:48:56 -0700 (PDT) Received: by 10.217.125.66 with HTTP; Wed, 20 Aug 2014 21:48:56 -0700 (PDT) Date: Thu, 21 Aug 2014 01:48:56 -0300 Message-ID: Subject: HC-SR04 and FreeBSD From: Evandro Nunes To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 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, 21 Aug 2014 04:48:59 -0000 hello, ive got a ultrasonic sensor model HC-SR04 and a beaglebone black as well as a cubieboard2, both running FreeBSD 11 built from crochet and wiki instructions thanks to the help from loos@ I could manage to use a 5v relay with BBB now, how can I read data from HC-SR04 sensor? do we have any library available? or do we have any GPIO utility to do that? btw how can I read values from GPIO pins when they are set to input? thank you all in advance From owner-freebsd-arm@FreeBSD.ORG Thu Aug 21 04:51:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50244B03 for ; Thu, 21 Aug 2014 04:51:11 +0000 (UTC) Received: from felyko.com (felyko.com [IPv6:2001:470:1:2d5:26:3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 381F833E5 for ; Thu, 21 Aug 2014 04:51:11 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 3DB6134A9E4; Wed, 20 Aug 2014 21:51:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: HC-SR04 and FreeBSD From: Rui Paulo In-Reply-To: Date: Wed, 20 Aug 2014 21:51:08 -0700 Content-Transfer-Encoding: 7bit Message-Id: <5D802942-2D0F-4324-8212-C2871EEB6327@FreeBSD.org> References: To: Evandro Nunes 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: Thu, 21 Aug 2014 04:51:11 -0000 On Aug 20, 2014, at 21:48, Evandro Nunes wrote: > hello, > > ive got a ultrasonic sensor model HC-SR04 and a beaglebone black as well as > a cubieboard2, both running FreeBSD 11 built from crochet and wiki > instructions > > thanks to the help from loos@ I could manage to use a 5v relay with BBB > now, how can I read data from HC-SR04 sensor? do we have any library > available? or do we have any GPIO utility to do that? > btw how can I read values from GPIO pins when they are set to input? I wrote a library to handle GPIO on FreeBSD: https://bitbucket.org/rpaulo/libgpio You can also use the gpioctl utility in FreeBSD to read values. -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Thu Aug 21 11:24:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D78D845 for ; Thu, 21 Aug 2014 11:24:06 +0000 (UTC) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (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 255CD3912 for ; Thu, 21 Aug 2014 11:24:05 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id b8so8479038lan.19 for ; Thu, 21 Aug 2014 04:24:04 -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=cnVKUfFxwgaWu09TOkT5ojfH0Tn3kI6fYiyuhA95dek=; b=GyOIrEMX6WF2vsDQYowTvo0n793HUmY3w7FRUsczWkRguNAcpaYx6GmcJCxjEMpchD nMeBWUG3aoNZTJR99wiqYxYvYeikq0jbzRAU5ew51fYtzgd5A+T2KuD2ZxXmN4Gtryiv KcerPL54Cb+nsZz/tw1QGHBQwrVP4qxEIiIdph8kAwZOMUG7LGt0hZ4wksVlB5/nXS6I QOOFWa7g2HphlqpNQUuXrLG4ScRH6lIpbiFhG9Hz258crNFDpLeS47h7/o3DDvdY7TV8 ULW4EGjelMWJHthgS9EiVU7+x3gJFscm00uOEddEv6nTzfGhlXvPSKjxOQbc/wxOxJrz UrEA== X-Received: by 10.112.52.225 with SMTP id w1mr46536245lbo.44.1408620244011; Thu, 21 Aug 2014 04:24:04 -0700 (PDT) Received: from ?IPv6:2001:1620:ff0:c51:434:a679:7428:2e35? ([2001:1620:ff0:c51:434:a679:7428:2e35]) by mx.google.com with ESMTPSA id as3sm41598262lbc.7.2014.08.21.04.24.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Aug 2014 04:24:03 -0700 (PDT) Message-ID: <53F5D6D2.50309@gmail.com> Date: Thu, 21 Aug 2014 13:24:02 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm Subject: Building pkg-1.3.6 fails Content-Type: text/plain; charset=ISO-8859-15; format=flowed 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, 21 Aug 2014 11:24:06 -0000 Hi, does anyone else get this issue when trying to build pkg 1.3.6 on arm? ===> Building for pkg-1.3.6 /usr/bin/make all-recursive Making all in external ./libelf/native-elf-format > libelf/native-elf-format.h /usr/bin/make all-am CC libucl/src/libucl_static_la-ucl_emitter.lo CC libucl/src/libucl_static_la-ucl_emitter_utils.lo CC libucl/src/libucl_static_la-ucl_emitter_streamline.lo CC libucl/src/libucl_static_la-ucl_hash.lo CC libucl/src/libucl_static_la-ucl_parser.lo CC libucl/src/libucl_static_la-ucl_schema.lo CC libucl/src/libucl_static_la-ucl_util.lo CC libucl/src/libucl_static_la-xxhash.lo CC sqlite/libsqlite_static_la-sqlite3.lo sqlite/sqlite3.c:53835:12: warning: unused variable 'pBlock' [-Wunused-variable] sqlite3 *pBlock = 0; ^ sqlite/sqlite3.c:57860:13: warning: unused variable 'key' [-Wunused-variable] u32 key = get4byte(&apNew[i]->aData[8]); ^ sqlite/sqlite3.c:8542:26: warning: unused variable 'sqlite3one' [-Wunused-const- SQLITE_PRIVATE const int sqlite3one = 1; ^ fatal error: error in backend: IO failure on output stream. *** [sqlite/libsqlite_static_la-sqlite3.lo] Error code 1 make[5]: stopped in /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6/external 1 error make[5]: stopped in /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6/external *** [all] Error code 2 make[4]: stopped in /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6/external 1 error make[4]: stopped in /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6/external *** [all-recursive] Error code 1 make[3]: stopped in /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6 1 error make[3]: stopped in /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6 *** [all] Error code 2 make[2]: stopped in /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6 1 error make[2]: stopped in /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6 ===> Compilation failed unexpectedly. It's not related to permissions or filesystem stuff. On i386 it throws the same warning and hangs for a bit (1 or 2 seconds) there, but then continues wihtout problems and builds completely. Anyone having an idea what's going on here? Cheers, Mat From owner-freebsd-arm@FreeBSD.ORG Thu Aug 21 15:01:04 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFCD7B0A for ; Thu, 21 Aug 2014 15:01:04 +0000 (UTC) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 848B83020 for ; Thu, 21 Aug 2014 15:01:04 +0000 (UTC) Received: from pmather.tower.lib.vt.edu (pmather.tower.lib.vt.edu [128.173.51.28]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id C70B64A3; Thu, 21 Aug 2014 10:55:05 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Building pkg-1.3.6 fails From: Paul Mather In-Reply-To: <53F5D6D2.50309@gmail.com> Date: Thu, 21 Aug 2014 10:55:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4896998C-814F-499E-95B5-FC2CF611CA53@gromit.dlib.vt.edu> References: <53F5D6D2.50309@gmail.com> To: Mattia Rossi X-Mailer: Apple Mail (2.1878.6) 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: Thu, 21 Aug 2014 15:01:04 -0000 On Aug 21, 2014, at 7:24 AM, Mattia Rossi = wrote: > Hi, >=20 > does anyone else get this issue when trying to build pkg 1.3.6 on arm? >=20 > =3D=3D=3D> Building for pkg-1.3.6 > /usr/bin/make all-recursive > Making all in external > ./libelf/native-elf-format > libelf/native-elf-format.h > /usr/bin/make all-am > CC libucl/src/libucl_static_la-ucl_emitter.lo > CC libucl/src/libucl_static_la-ucl_emitter_utils.lo > CC libucl/src/libucl_static_la-ucl_emitter_streamline.lo > CC libucl/src/libucl_static_la-ucl_hash.lo > CC libucl/src/libucl_static_la-ucl_parser.lo > CC libucl/src/libucl_static_la-ucl_schema.lo > CC libucl/src/libucl_static_la-ucl_util.lo > CC libucl/src/libucl_static_la-xxhash.lo > CC sqlite/libsqlite_static_la-sqlite3.lo > sqlite/sqlite3.c:53835:12: warning: unused variable 'pBlock' = [-Wunused-variable] > sqlite3 *pBlock =3D 0; > ^ > sqlite/sqlite3.c:57860:13: warning: unused variable 'key' = [-Wunused-variable] > u32 key =3D get4byte(&apNew[i]->aData[8]); > ^ > sqlite/sqlite3.c:8542:26: warning: unused variable 'sqlite3one' = [-Wunused-const- > SQLITE_PRIVATE const int sqlite3one =3D 1; > ^ > fatal error: error in backend: IO failure on output stream. > *** [sqlite/libsqlite_static_la-sqlite3.lo] Error code 1 >=20 > make[5]: stopped in = /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6/external > 1 error >=20 > make[5]: stopped in = /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6/external > *** [all] Error code 2 >=20 > make[4]: stopped in = /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6/external > 1 error >=20 > make[4]: stopped in = /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6/external > *** [all-recursive] Error code 1 >=20 > make[3]: stopped in /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6 > 1 error >=20 > make[3]: stopped in /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6 > *** [all] Error code 2 >=20 > make[2]: stopped in /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6 > 1 error >=20 > make[2]: stopped in /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6 > =3D=3D=3D> Compilation failed unexpectedly. >=20 > It's not related to permissions or filesystem stuff. On i386 it throws = the same warning and hangs for a bit (1 or 2 seconds) there, but then = continues wihtout problems and builds completely. > Anyone having an idea what's going on here? I don't know what's causing your error, but, FWIW, I successfully built=20= pkg-1.3.6 on my BBB and R-PI quite recently: pmather@beaglebone:~ % pkg info pkg pkg-1.3.6 Name : pkg Version : 1.3.6 Installed on : Thu Aug 14 18:07:21 EDT 2014 Origin : ports-mgmt/pkg Architecture : freebsd:11:armv6:32:el:eabi:softfp Prefix : /usr/local Categories : ports-mgmt Licenses : BSD2CLAUSE Maintainer : portmgr@FreeBSD.org WWW : http://wiki.freebsd.org/pkgng Comment : Package manager Flat size : 8.68MiB Description : Package management tool WWW: http://wiki.freebsd.org/pkgng This is on -CURRENT with clang: pmather@beaglebone:~ % uname -a FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r270100: Sun Aug = 17 10:50:42 EDT 2014 = paul@chumby.chumby.lan:/build/obj/bbb/arm.armv6/build/src/head/sys/BEAGLEB= ONE-NO_WITNESS arm pmather@beaglebone:~ % cc -v FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: armv6--freebsd11.0-gnueabi Thread model: posix Selected GCC installation:=20 I suspect the "fatal error: error in backend: IO failure on output=20 stream." might mean that you ran out of space in /tmp or that your SD=20 card is going bad? That point in the build takes quite a few minutes for me on ARM but=20 gets past it. I just started a make and this is what I got: =3D=3D=3D=3D=3D [[...]] =3D=3D=3D> Building for pkg-1.3.6 /usr/bin/make all-recursive Making all in external ./libelf/native-elf-format > libelf/native-elf-format.h /usr/bin/make all-am CC libucl/src/libucl_static_la-ucl_emitter.lo CC libucl/src/libucl_static_la-ucl_emitter_utils.lo CC libucl/src/libucl_static_la-ucl_emitter_streamline.lo CC libucl/src/libucl_static_la-ucl_hash.lo CC libucl/src/libucl_static_la-ucl_parser.lo CC libucl/src/libucl_static_la-ucl_schema.lo CC libucl/src/libucl_static_la-ucl_util.lo CC libucl/src/libucl_static_la-xxhash.lo CC sqlite/libsqlite_static_la-sqlite3.lo sqlite/sqlite3.c:53835:12: warning: unused variable 'pBlock' = [-Wunused-variable] sqlite3 *pBlock =3D 0; ^ sqlite/sqlite3.c:57860:13: warning: unused variable 'key' = [-Wunused-variable] u32 key =3D get4byte(&apNew[i]->aData[8]); ^ sqlite/sqlite3.c:8542:26: warning: unused variable 'sqlite3one' = [-Wunused-const-variable] SQLITE_PRIVATE const int sqlite3one =3D 1; ^ 3 warnings generated. CC sqlite/libsqlite_static_la-shell.lo CC libyaml/src/libyaml_static_la-api.lo CC libyaml/src/libyaml_static_la-loader.lo CC libyaml/src/libyaml_static_la-parser.lo CC libyaml/src/libyaml_static_la-reader.lo [[...]] =3D=3D=3D=3D=3D The build is still running, but it is past the point it failed for you.=20= If it helps, I have /usr/ports and /tmp on an external USB drive. By=20= default, /tmp is on an md device, so may be consuming resources needed=20= to compile this file. Cheers, Paul.= From owner-freebsd-arm@FreeBSD.ORG Thu Aug 21 15:33:42 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E0BAD28 for ; Thu, 21 Aug 2014 15:33:42 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (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 D731C33FB for ; Thu, 21 Aug 2014 15:33:41 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id b17so8701866lan.39 for ; Thu, 21 Aug 2014 08:33:39 -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=WDnciYKXwCOes5Fd0E9J1NPKeM6ISPfeXoc+bOVNIFA=; b=CmkXGhCkvppkHj+0wE2wI3vjv55ZgSldrHq8oM+oCIeb/Ss5338N4SxVvZzf+mmKPD iB/MoW3GGOB2qV1ii1MeINm5b7XJMGEF/q2/+8+901EVKKb2/Ah7kj2c0/TLPcA+pSPY Vk+SJZPR/H11XVhjVcD7lXZwF5O9xdy1IRlxZ+YkG+qTxTV/RSBCQcRo0BFNFW3NRfcv FXMe1q2hHDTtUnBb1PnjZvTzLBm/6jgFzACKU9VT+OA3QhevI/LZr8zZbKXQywEs7fbH OkYi1zzDAtEr2xHYf+pjvWhqVynS2/ArKM8BF09UYGBckaeBQl9QA5wS3rtiS3MHkQRA EIVg== X-Received: by 10.112.255.36 with SMTP id an4mr47582385lbd.31.1408635219599; Thu, 21 Aug 2014 08:33:39 -0700 (PDT) Received: from ?IPv6:2001:1620:ff0:c51:434:a679:7428:2e35? ([2001:1620:ff0:c51:434:a679:7428:2e35]) by mx.google.com with ESMTPSA id bz10sm38906522lbb.10.2014.08.21.08.33.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Aug 2014 08:33:38 -0700 (PDT) Message-ID: <53F61151.50801@gmail.com> Date: Thu, 21 Aug 2014 17:33:37 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Mather Subject: Re: Building pkg-1.3.6 fails References: <53F5D6D2.50309@gmail.com> <4896998C-814F-499E-95B5-FC2CF611CA53@gromit.dlib.vt.edu> In-Reply-To: <4896998C-814F-499E-95B5-FC2CF611CA53@gromit.dlib.vt.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 21 Aug 2014 15:33:42 -0000 Hi Paul, Top posting for easier readability. You gave me the right hint. /tmp is on a tmpfs and it was too small thanks to a typo (1M instead of 10M). Would have never thought of that. Now fixing. Should work. Thanks! Am 21.08.2014 16:55, schrieb Paul Mather: > On Aug 21, 2014, at 7:24 AM, Mattia Rossi wrote: > >> Hi, >> >> does anyone else get this issue when trying to build pkg 1.3.6 on arm? >> >> ===> Building for pkg-1.3.6 >> /usr/bin/make all-recursive >> Making all in external >> ./libelf/native-elf-format > libelf/native-elf-format.h >> /usr/bin/make all-am >> CC libucl/src/libucl_static_la-ucl_emitter.lo >> CC libucl/src/libucl_static_la-ucl_emitter_utils.lo >> CC libucl/src/libucl_static_la-ucl_emitter_streamline.lo >> CC libucl/src/libucl_static_la-ucl_hash.lo >> CC libucl/src/libucl_static_la-ucl_parser.lo >> CC libucl/src/libucl_static_la-ucl_schema.lo >> CC libucl/src/libucl_static_la-ucl_util.lo >> CC libucl/src/libucl_static_la-xxhash.lo >> CC sqlite/libsqlite_static_la-sqlite3.lo >> sqlite/sqlite3.c:53835:12: warning: unused variable 'pBlock' [-Wunused-variable] >> sqlite3 *pBlock = 0; >> ^ >> sqlite/sqlite3.c:57860:13: warning: unused variable 'key' [-Wunused-variable] >> u32 key = get4byte(&apNew[i]->aData[8]); >> ^ >> sqlite/sqlite3.c:8542:26: warning: unused variable 'sqlite3one' [-Wunused-const- >> SQLITE_PRIVATE const int sqlite3one = 1; >> ^ >> fatal error: error in backend: IO failure on output stream. >> *** [sqlite/libsqlite_static_la-sqlite3.lo] Error code 1 >> >> make[5]: stopped in /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6/external >> 1 error >> >> make[5]: stopped in /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6/external >> *** [all] Error code 2 >> >> make[4]: stopped in /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6/external >> 1 error >> >> make[4]: stopped in /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6/external >> *** [all-recursive] Error code 1 >> >> make[3]: stopped in /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6 >> 1 error >> >> make[3]: stopped in /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6 >> *** [all] Error code 2 >> >> make[2]: stopped in /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6 >> 1 error >> >> make[2]: stopped in /root/usr/ports/ports-mgmt/pkg/work/pkg-1.3.6 >> ===> Compilation failed unexpectedly. >> >> It's not related to permissions or filesystem stuff. On i386 it throws the same warning and hangs for a bit (1 or 2 seconds) there, but then continues wihtout problems and builds completely. >> Anyone having an idea what's going on here? > > I don't know what's causing your error, but, FWIW, I successfully built > pkg-1.3.6 on my BBB and R-PI quite recently: > > pmather@beaglebone:~ % pkg info pkg > pkg-1.3.6 > Name : pkg > Version : 1.3.6 > Installed on : Thu Aug 14 18:07:21 EDT 2014 > Origin : ports-mgmt/pkg > Architecture : freebsd:11:armv6:32:el:eabi:softfp > Prefix : /usr/local > Categories : ports-mgmt > Licenses : BSD2CLAUSE > Maintainer : portmgr@FreeBSD.org > WWW : http://wiki.freebsd.org/pkgng > Comment : Package manager > Flat size : 8.68MiB > Description : > Package management tool > > WWW: http://wiki.freebsd.org/pkgng > > > This is on -CURRENT with clang: > > pmather@beaglebone:~ % uname -a > FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r270100: Sun Aug 17 10:50:42 EDT 2014 paul@chumby.chumby.lan:/build/obj/bbb/arm.armv6/build/src/head/sys/BEAGLEBONE-NO_WITNESS arm > > pmather@beaglebone:~ % cc -v > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > Target: armv6--freebsd11.0-gnueabi > Thread model: posix > Selected GCC installation: > > > I suspect the "fatal error: error in backend: IO failure on output > stream." might mean that you ran out of space in /tmp or that your SD > card is going bad? > > That point in the build takes quite a few minutes for me on ARM but > gets past it. I just started a make and this is what I got: > > ===== > [[...]] > ===> Building for pkg-1.3.6 > /usr/bin/make all-recursive > Making all in external > ./libelf/native-elf-format > libelf/native-elf-format.h > /usr/bin/make all-am > CC libucl/src/libucl_static_la-ucl_emitter.lo > CC libucl/src/libucl_static_la-ucl_emitter_utils.lo > CC libucl/src/libucl_static_la-ucl_emitter_streamline.lo > CC libucl/src/libucl_static_la-ucl_hash.lo > CC libucl/src/libucl_static_la-ucl_parser.lo > CC libucl/src/libucl_static_la-ucl_schema.lo > CC libucl/src/libucl_static_la-ucl_util.lo > CC libucl/src/libucl_static_la-xxhash.lo > CC sqlite/libsqlite_static_la-sqlite3.lo > sqlite/sqlite3.c:53835:12: warning: unused variable 'pBlock' [-Wunused-variable] > sqlite3 *pBlock = 0; > ^ > sqlite/sqlite3.c:57860:13: warning: unused variable 'key' [-Wunused-variable] > u32 key = get4byte(&apNew[i]->aData[8]); > ^ > sqlite/sqlite3.c:8542:26: warning: unused variable 'sqlite3one' [-Wunused-const-variable] > SQLITE_PRIVATE const int sqlite3one = 1; > ^ > 3 warnings generated. > CC sqlite/libsqlite_static_la-shell.lo > CC libyaml/src/libyaml_static_la-api.lo > CC libyaml/src/libyaml_static_la-loader.lo > CC libyaml/src/libyaml_static_la-parser.lo > CC libyaml/src/libyaml_static_la-reader.lo > [[...]] > ===== > > The build is still running, but it is past the point it failed for you. > If it helps, I have /usr/ports and /tmp on an external USB drive. By > default, /tmp is on an md device, so may be consuming resources needed > to compile this file. > > Cheers, > > Paul. From owner-freebsd-arm@FreeBSD.ORG Thu Aug 21 16:54:56 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78379778; Thu, 21 Aug 2014 16:54:56 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (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 C16DE3C5A; Thu, 21 Aug 2014 16:54:55 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id s7so8452084lbd.0 for ; Thu, 21 Aug 2014 09:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aaiSe+1DBAXIMSvFC0rmkiS07nhUU7qJ5Mw+L7EhC0I=; b=zo+pKLxciQdPZzgOCpQR5Ayzc4+y6sl7O54RmFrqj0dyabxDm6+7LsGiHSlQsD2EJ+ uPFpo9Kk2wdLkuxobxq1efMbZKfuhMIj2iVyjl2yenGTm2SSpUw87NMUe4XPbK1IxUkP 4xoJgvd3ALQrFGmYZnb/0qt+PTpv3gZ+Wy0AJULb+X/zVtyEyY2d8wMz+tduK6aRkreX FQPBg/HdHZBOB9WsZLv6Umo2xFUjoHS00lFnpduxxWEQEhrz9WA+dOjiLzwDCzakFa9p HszBmjfx1/Fkt2+okBi3e4ClvDjJgJ/CyS5J3Fi4SCzzHtarFIH+LH55/HT30BCL42rn QeqQ== X-Received: by 10.112.50.230 with SMTP id f6mr47372905lbo.56.1408640093718; Thu, 21 Aug 2014 09:54:53 -0700 (PDT) Received: from [192.168.1.101] (c-d135e155.556-1-64736c11.cust.bredbandsbolaget.se. [85.225.53.209]) by mx.google.com with ESMTPSA id a12sm38785949lbq.0.2014.08.21.09.54.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Aug 2014 09:54:52 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-7 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Olavi Kumpulainen In-Reply-To: <1408562392.1150.4.camel@revolution.hippie.lan> Date: Thu, 21 Aug 2014 18:54:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2C97B126-91FE-4E93-920F-6ED5045666A6@gmail.com> References: <1405809318.85788.35.camel@revolution.hippie.lan> <1406063473.71975.8.camel@revolution.hippie.lan> <53D2CFBE.3040207@fgznet.ch> <834BA562-84ED-425C-9D61-0A235A28A94A@gmail.com> <1408472517.56408.659.camel@revolution.hippie.lan> <1408562392.1150.4.camel@revolution.hippie.lan> To: Ian Lepore 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: Thu, 21 Aug 2014 16:54:56 -0000 On 20 Aug 2014, at 21:19 , Ian Lepore wrote: > On Wed, 2014-08-20 at 19:19 +0200, Olavi Kumpulainen wrote: >> On 19 Aug 2014, at 20:21 , Ian Lepore wrote: >>=20 >>> On Tue, 2014-08-19 at 19:40 +0200, Olavi Kumpulainen wrote: >>>> On 25 Jul 2014, at 23:44 , Andreas Tobler = wrote: >>>>=20 >>>>> On 22.07.14 23:11, Ian Lepore wrote: >>>>>> On Sat, 2014-07-19 at 16:35 -0600, Ian Lepore wrote: >>>>>>> On Sat, 2014-06-07 at 14:12 +0200, Olavi Kumpulainen wrote: >>>>>>>> [c++ exceptions don't work and related discussion] >>>>>>>=20 >>>>>>> I checked in a partial fix for c++ exception handling in = r268893. It >>>>>>> fixes the specific problem you detailed above, which was = essentially >>>>>>> that the __gnu_Unwind_Find_exidx() function was not available in = any >>>>>>> shared library, making the unwinder fall back to using the = __exidx_start >>>>>>> and end symbols, which are only valid in a statically-linked = app. >>>>>>>=20 >>>>>>> With the new function in place, exceptions are closer to working = with >>>>>>> gcc 4.2.1, but still don't work with clang. With gcc, some = things work >>>>>>> and some things don't. For example if you throw an exception = and in the >>>>>>> same function have a catch with the right specific type it = segfaults, >>>>>>> but a catch(...) will catch it without problems. But you can = catch an >>>>>>> exception by type if the catch is in a function higher up the = call chain >>>>>>> from the place it was thrown. >>>>>>>=20 >>>>>>> We're continuing to debug this at $work, and welcome any input = if anyone >>>>>>> else makes progress with it. Right now we still don't know = whether the >>>>>>> segfaults are because of bad unwinder library code or bad unwind = data >>>>>>> emitted by gcc. (I sure hope it's the library, because that's = easier to >>>>>>> fix.) >>>>>>>=20 >>>>>>> On the clang front, it has been said that c++ exceptions work in = clang >>>>>>> 3.5, so we tried the clang-devel port, and it didn't just work. = But it >>>>>>> turns out that port hasn't been updated for quite a while, so we = may not >>>>>>> have tested the code that's supposed to work right. While = trying that I >>>>>>> discovered that clang 3.5 isn't scheduled for release for about = another >>>>>>> year, so that really isn't a viable solution for anyone with = near-term >>>>>>> needs, unless the required changes can be cherry-picked and = brought into >>>>>>> our version of 3.4. >>>>>>>=20 >>>>>>> -- Ian >>>>>>=20 >>>>>> Another update to this... today I committed r268993 and r268994, = and now >>>>>> I believe arm eabi c++ exceptions are fully working with gcc. I = haven't >>>>>> run an extensive test suite, but all the test cases we've been = using at >>>>>> $work to debug this now work correctly. >>>>>=20 >>>>> Thank you! Confirmed. My test cases which are working with = gcc-4.10 are now also working with the system gcc, 4.2.1. >>>>> I totally forgot about this change. I have it in my local gcc tree = since a while but I forgot about..... >>>>>=20 >>>>> Andreas >>>>>=20 >>>>>=20 >>>>=20 >>>> Please excuse my late reply. I=A2ve been away from keyboard for a = while. >>>>=20 >>>> I back-ported r268893, r268993 and r268994 to stable/10 for = beaglebone. C++ exceptions works for static builds, but not for binaries = linked to shared libs. >>>>=20 >>>> Since this seems to work ok in HEAD, I=A2m obviously missing = something. Do any of you guys have any ideas? >>>>=20 >>>> Cheers >>>>=20 >>>=20 >>> I'm not sure what you mean by "backported to stable/10", I merged = all >>> the necessary changes to stable-10 as r269792 on Aug 10. Are you >>> working with a checkout from earlier than that? If so, just = updating >>> should fix it for you. >>>=20 >>> -- Ian >>>=20 >>>=20 >>=20 >>=20 >> Updating to stable-10 as of today didn=A2t help. I=A2m running a = clean checkout except for a couple of drivers in the kernel. >> This makes me think I have a bad src.conf - How shall I configure the = build for this to work? >>=20 >> /Olavi >>=20 >>=20 >>=20 >>=20 >=20 > You need to use GCC, not clang, as the compiler. Exceptions are just > broken on clang 3.4, so we're waiting for 3.5 (should be released any > time now I think). >=20 > To compile with gcc, put this in your /etc/make.conf: >=20 > WITH_GCC=3Dyes > WITH_GNUCXX=3Dyes > WITH_GCC_BOOTSTRAP=3Dyes > WITHOUT_CLANG=3Dyes > WITHOUT_CLANG_IS_CC=3Dyes > WITHOUT_CLANG_BOOTSTRAP=3Dyes >=20 > -- Ian >=20 >=20 Thank you. It turned out that I already used these with the exception of = WITHOUT_CLANG_BOOTSTRAP. However, c++ exceptions in stable/10 is still defunct when I build it.=20= So instead I pulled master, built and installed that instead. And voila = - Exceptions do work!=20 Therefore it seems my build method, flags and environment is ok after = all. I glanced the commit logs in master but didn=A2t find anything = obvious, but still; something related seems missing in stable/10 if you = ask me. /Olavi From owner-freebsd-arm@FreeBSD.ORG Thu Aug 21 18: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4DF9C8F; Thu, 21 Aug 2014 18:44:38 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (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 1F49938C0; Thu, 21 Aug 2014 18:44:37 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id k48so9793065wev.27 for ; Thu, 21 Aug 2014 11:44:36 -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=B1/ewZ1OdJFJh8Vv2nWLI0I0GdhLUzqG/Jl7DJGbUn0=; b=RYBA5pTHPIj5AnQY6XS6R8VdFV1fK8ZZMNd2Nj3ibhhoSbwQgeuvYAE1HwForKzJn0 nu/1qh3TZGeBpr7BiToyofymL9A9hOqRTjTZkiEvRw9WNPeDLlag6iAxPcdbRD/MJ47i m+D9DqwFHe9Khg6oVMGeF2zU/GaAsUanFBv3rpmPyxCxjNtoDbMuMPU3Z2kAMFRwG7vP Yk5AfE47rOJtgpyi1yo/ZcQn1MHGF8WyHJHsjnvENusOKyIXDigoaTGQ9hefc83Rl5hx VYokTCtq8llJoE+jLBnjkRtVQll/C9wZ3IJ8QL+XHn4kgZbZEzaucQBhIjNb7jRlfw2B Yn2Q== MIME-Version: 1.0 X-Received: by 10.194.119.98 with SMTP id kt2mr380293wjb.96.1408646676371; Thu, 21 Aug 2014 11:44:36 -0700 (PDT) Received: by 10.217.125.66 with HTTP; Thu, 21 Aug 2014 11:44:36 -0700 (PDT) In-Reply-To: References: <5D802942-2D0F-4324-8212-C2871EEB6327@FreeBSD.org> <01562FB1-32C6-45AF-AB77-5BB80526E18C@FreeBSD.org> Date: Thu, 21 Aug 2014 15:44:36 -0300 Message-ID: Subject: Re: HC-SR04 and FreeBSD From: Evandro Nunes To: Rui Paulo , freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 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, 21 Aug 2014 18:44:38 -0000 On Thu, Aug 21, 2014 at 1:24 PM, Rui Paulo wrote: > On Aug 20, 2014, at 22:34, Evandro Nunes wrote: > > > On Thu, Aug 21, 2014 at 2:05 AM, Rui Paulo wrote: > > On Aug 20, 2014, at 21:52, Evandro Nunes > wrote: > > > > > On Thu, Aug 21, 2014 at 1:51 AM, Rui Paulo wrote: > > > On Aug 20, 2014, at 21:48, Evandro Nunes > wrote: > > > > > > > hello, > > > > > > > > ive got a ultrasonic sensor model HC-SR04 and a beaglebone black as > well as > > > > a cubieboard2, both running FreeBSD 11 built from crochet and wiki > > > > instructions > > > > > > > > thanks to the help from loos@ I could manage to use a 5v relay with > BBB > > > > now, how can I read data from HC-SR04 sensor? do we have any library > > > > available? or do we have any GPIO utility to do that? > > > > btw how can I read values from GPIO pins when they are set to input? > > > > > > I wrote a library to handle GPIO on FreeBSD: > > > > > > https://bitbucket.org/rpaulo/libgpio > > > > > > very good :-) I will play with that > > > > > > You can also use the gpioctl utility in FreeBSD to read values. > > > > > > how? can you point me to any further reading, blog entry, or examples? > > > > There's a man page, but "gpioctl -c IN" will set the pin in input > mode. Then, "gpioctl " will read the value. > > > > so this way I should read something from HC-SR04 echo pin on BBB? > > I am using another gpio pin in output mode as a trigger, according to > what I've read, 3.3v is OK as a trigger for this sonar > > > > but when I read the GPIO pin in input mode just as you mentioned, I > always get a 0 value... > > I am using BBB's P9_1 and P9_5 for +5v and ground, P9_21 as a trigger > and P9_23 as echo; set GPIO 3 (P9_21) as output and GPIO 49 (P9_23) as input > > I made a loop to read GPIO 49 every 100ms and another loop to trigger > (gpioctl -t 3; sleep .100; gpioctl -t 3) every 2 seconds. > > > > what I am doing wrong? feeding 3.3v for 0.1 seconds as a trigger > should't cause something to echo? > > Don't you have a multimeter? Have you measured the voltage on the output > pin when you switch it to 0 and then back to 1? > no, I don't have a working multimeter, mine is dead. I will buy another one and test it as suggested, yes you are right, although I dont have an idea on what value it should be expected but for curiosity, will gpioctl 49 show values anyhow equivalent to what a multimeter would display? or I should not expect anything similar? sorry for that question if this is too dummy, yes I completely lack on GPIO basics, it's my first experience rss > -- > Rui Paulo > > > > From owner-freebsd-arm@FreeBSD.ORG Thu Aug 21 21:20:57 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15B8C9F1 for ; Thu, 21 Aug 2014 21:20:57 +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 C525F3879 for ; Thu, 21 Aug 2014 21:20:56 +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 1XKZmx-000Irr-3q; Thu, 21 Aug 2014 21:20:55 +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 s7LLKsGY056984; Thu, 21 Aug 2014 15:20:54 -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+hEjH55El9um3wln3xR/lZ X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Ian Lepore To: Olavi Kumpulainen In-Reply-To: <2C97B126-91FE-4E93-920F-6ED5045666A6@gmail.com> References: <1405809318.85788.35.camel@revolution.hippie.lan> <1406063473.71975.8.camel@revolution.hippie.lan> <53D2CFBE.3040207@fgznet.ch> <834BA562-84ED-425C-9D61-0A235A28A94A@gmail.com> <1408472517.56408.659.camel@revolution.hippie.lan> <1408562392.1150.4.camel@revolution.hippie.lan> <2C97B126-91FE-4E93-920F-6ED5045666A6@gmail.com> Content-Type: text/plain; charset="iso-8859-7" Date: Thu, 21 Aug 2014 15:20:53 -0600 Message-ID: <1408656053.1150.34.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 s7LLKsGY056984 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, 21 Aug 2014 21:20:57 -0000 On Thu, 2014-08-21 at 18:54 +0200, Olavi Kumpulainen wrote: > On 20 Aug 2014, at 21:19 , Ian Lepore wrote: >=20 > > On Wed, 2014-08-20 at 19:19 +0200, Olavi Kumpulainen wrote: > >> On 19 Aug 2014, at 20:21 , Ian Lepore wrote: > >>=20 > >>> On Tue, 2014-08-19 at 19:40 +0200, Olavi Kumpulainen wrote: > >>>> On 25 Jul 2014, at 23:44 , Andreas Tobler wrote: > >>>>=20 > >>>>> On 22.07.14 23:11, Ian Lepore wrote: > >>>>>> On Sat, 2014-07-19 at 16:35 -0600, Ian Lepore wrote: > >>>>>>> On Sat, 2014-06-07 at 14:12 +0200, Olavi Kumpulainen wrote: > >>>>>>>> [c++ exceptions don't work and related discussion] > >>>>>>>=20 > >>>>>>> I checked in a partial fix for c++ exception handling in r26889= 3. It > >>>>>>> fixes the specific problem you detailed above, which was essent= ially > >>>>>>> that the __gnu_Unwind_Find_exidx() function was not available i= n any > >>>>>>> shared library, making the unwinder fall back to using the __ex= idx_start > >>>>>>> and end symbols, which are only valid in a statically-linked ap= p. > >>>>>>>=20 > >>>>>>> With the new function in place, exceptions are closer to workin= g with > >>>>>>> gcc 4.2.1, but still don't work with clang. With gcc, some thi= ngs work > >>>>>>> and some things don't. For example if you throw an exception a= nd in the > >>>>>>> same function have a catch with the right specific type it segf= aults, > >>>>>>> but a catch(...) will catch it without problems. But you can c= atch an > >>>>>>> exception by type if the catch is in a function higher up the c= all chain > >>>>>>> from the place it was thrown. > >>>>>>>=20 > >>>>>>> We're continuing to debug this at $work, and welcome any input = if anyone > >>>>>>> else makes progress with it. Right now we still don't know whe= ther the > >>>>>>> segfaults are because of bad unwinder library code or bad unwin= d data > >>>>>>> emitted by gcc. (I sure hope it's the library, because that's = easier to > >>>>>>> fix.) > >>>>>>>=20 > >>>>>>> On the clang front, it has been said that c++ exceptions work i= n clang > >>>>>>> 3.5, so we tried the clang-devel port, and it didn't just work.= But it > >>>>>>> turns out that port hasn't been updated for quite a while, so w= e may not > >>>>>>> have tested the code that's supposed to work right. While tryi= ng that I > >>>>>>> discovered that clang 3.5 isn't scheduled for release for about= another > >>>>>>> year, so that really isn't a viable solution for anyone with ne= ar-term > >>>>>>> needs, unless the required changes can be cherry-picked and bro= ught into > >>>>>>> our version of 3.4. > >>>>>>>=20 > >>>>>>> -- Ian > >>>>>>=20 > >>>>>> Another update to this... today I committed r268993 and r268994,= and now > >>>>>> I believe arm eabi c++ exceptions are fully working with gcc. I= haven't > >>>>>> run an extensive test suite, but all the test cases we've been u= sing at > >>>>>> $work to debug this now work correctly. > >>>>>=20 > >>>>> Thank you! Confirmed. My test cases which are working with gcc-4.= 10 are now also working with the system gcc, 4.2.1. > >>>>> I totally forgot about this change. I have it in my local gcc tre= e since a while but I forgot about..... > >>>>>=20 > >>>>> Andreas > >>>>>=20 > >>>>>=20 > >>>>=20 > >>>> Please excuse my late reply. I=A2ve been away from keyboard for a = while. > >>>>=20 > >>>> I back-ported r268893, r268993 and r268994 to stable/10 for beagl= ebone. C++ exceptions works for static builds, but not for binaries linke= d to shared libs. > >>>>=20 > >>>> Since this seems to work ok in HEAD, I=A2m obviously missing somet= hing. Do any of you guys have any ideas? > >>>>=20 > >>>> Cheers > >>>>=20 > >>>=20 > >>> I'm not sure what you mean by "backported to stable/10", I merged a= ll > >>> the necessary changes to stable-10 as r269792 on Aug 10. Are you > >>> working with a checkout from earlier than that? If so, just updati= ng > >>> should fix it for you. > >>>=20 > >>> -- Ian > >>>=20 > >>>=20 > >>=20 > >>=20 > >> Updating to stable-10 as of today didn=A2t help. I=A2m running a cle= an checkout except for a couple of drivers in the kernel. > >> This makes me think I have a bad src.conf - How shall I configure th= e build for this to work? > >>=20 > >> /Olavi > >>=20 > >>=20 > >>=20 > >>=20 > >=20 > > You need to use GCC, not clang, as the compiler. Exceptions are just > > broken on clang 3.4, so we're waiting for 3.5 (should be released any > > time now I think). > >=20 > > To compile with gcc, put this in your /etc/make.conf: > >=20 > > WITH_GCC=3Dyes > > WITH_GNUCXX=3Dyes > > WITH_GCC_BOOTSTRAP=3Dyes > > WITHOUT_CLANG=3Dyes > > WITHOUT_CLANG_IS_CC=3Dyes > > WITHOUT_CLANG_BOOTSTRAP=3Dyes > >=20 > > -- Ian > >=20 > >=20 >=20 >=20 > Thank you. It turned out that I already used these with the exception o= f WITHOUT_CLANG_BOOTSTRAP. >=20 > However, c++ exceptions in stable/10 is still defunct when I build it.=20 >=20 > So instead I pulled master, built and installed that instead. And voila= - Exceptions do work!=20 >=20 > Therefore it seems my build method, flags and environment is ok after a= ll. I glanced the commit logs in master but didn=A2t find anything obviou= s, but still; something related seems missing in stable/10 if you ask me. >=20 > /Olavi I've confirmed this on my systems here... it works fine on our private 10-stable repo at $work, but not the 10-stable branch of freebsd, so I guess I missed a change that needs merging. I'll try to figure out which one and get it fixed. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Aug 22 03:43:48 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 349D7756 for ; Fri, 22 Aug 2014 03:43:48 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 AEE503D90 for ; Fri, 22 Aug 2014 03:43:47 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id d1so9331916wiv.3 for ; Thu, 21 Aug 2014 20:43:45 -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=CfDVLrJsCnEFtjpUd6GZyh4aaCuL95hIDk+LcS0sr20=; b=SsUaOTXFHeHqYybAlysqAP3NB95DmiedCUdNT/2RAoeTWq9YRT41HBMENgcAizQE+F sqavw7EAm0pmU7I37NjUKxZvvi1aXQ5jXjVgtr5SJORV2aP27fXFs6zn0ZHC2/lNBY3O UdSu9vsI3LAMTNieJSt6L9WKcQphBp4jWvLDD4kbfKRihKCVGydov+Z7Hh3zjeWmag59 SAPL4cC+BIoOsnq0g3UDCocntsBR7MoT3y/tmKZU5xOYi/hlNfjFetDpz/leIuM5abeB 22cmRd+eBCXNkX13x5xEv+azFiss4r/HvqIFp/Vj0FxK9HjBEgKK/lldxUvNLfjqRxCe rAVw== MIME-Version: 1.0 X-Received: by 10.180.35.134 with SMTP id h6mr8381495wij.0.1408679025717; Thu, 21 Aug 2014 20:43:45 -0700 (PDT) Received: by 10.217.125.66 with HTTP; Thu, 21 Aug 2014 20:43:45 -0700 (PDT) In-Reply-To: References: <5D802942-2D0F-4324-8212-C2871EEB6327@FreeBSD.org> <01562FB1-32C6-45AF-AB77-5BB80526E18C@FreeBSD.org> Date: Fri, 22 Aug 2014 00:43:45 -0300 Message-ID: Subject: Re: HC-SR04 and FreeBSD From: Evandro Nunes To: Rui Paulo , freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 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: Fri, 22 Aug 2014 03:43:48 -0000 On Thu, Aug 21, 2014 at 4:13 PM, Rui Paulo wrote: > You can use an led instead of a multimeter. The point I'm trying to make > is to make sure the gpio number really corresponds to that port number. > still no success, but just an update... ok I added two led: pin 02: 0 gpio_2 ===> echo (orange LED) pin 03: 0 gpio_3 ===> trigger (blue LED) pin 49: 0 gpio_49 ===> previous echo and I have the two simple loops below. when I run loop1, BLUE LED blinks every second; when I run loop2 while loop1 stills run, ORANGE LED won't blink, and loop2 value still shows 0 value if I "gpioctl -c 2 OUT ; gpioctl -t 2", ORANGE LED will light, confirming LED is OK; thoses leds will light with 2-5v input... however I have no idea if the sonar output will range 2-5 or if it will be below 2 (i tried adding my hand very close and far away from the sensor but led was never lit) so I'd better use a multimeter for sure... loop1: while true ; do gpioctl -t 3; sleep .200; gpioctl -t 3 #gpioctl 3 sleep 1 done loop2: while true ; do gpioctl 2 sleep .500 done > > -- > Rui Paulo > > On 21 Aug 2014, at 11:44, Evandro Nunes wrote: > > On Thu, Aug 21, 2014 at 1:24 PM, Rui Paulo wrote: > >> On Aug 20, 2014, at 22:34, Evandro Nunes >> wrote: >> >> > On Thu, Aug 21, 2014 at 2:05 AM, Rui Paulo wrote: >> > On Aug 20, 2014, at 21:52, Evandro Nunes >> wrote: >> > >> > > On Thu, Aug 21, 2014 at 1:51 AM, Rui Paulo >> wrote: >> > > On Aug 20, 2014, at 21:48, Evandro Nunes >> wrote: >> > > >> > > > hello, >> > > > >> > > > ive got a ultrasonic sensor model HC-SR04 and a beaglebone black as >> well as >> > > > a cubieboard2, both running FreeBSD 11 built from crochet and wiki >> > > > instructions >> > > > >> > > > thanks to the help from loos@ I could manage to use a 5v relay >> with BBB >> > > > now, how can I read data from HC-SR04 sensor? do we have any library >> > > > available? or do we have any GPIO utility to do that? >> > > > btw how can I read values from GPIO pins when they are set to input? >> > > >> > > I wrote a library to handle GPIO on FreeBSD: >> > > >> > > https://bitbucket.org/rpaulo/libgpio >> > > >> > > very good :-) I will play with that >> > > >> > > You can also use the gpioctl utility in FreeBSD to read values. >> > > >> > > how? can you point me to any further reading, blog entry, or examples? >> > >> > There's a man page, but "gpioctl -c IN" will set the pin in input >> mode. Then, "gpioctl " will read the value. >> > >> > so this way I should read something from HC-SR04 echo pin on BBB? >> > I am using another gpio pin in output mode as a trigger, according to >> what I've read, 3.3v is OK as a trigger for this sonar >> > >> > but when I read the GPIO pin in input mode just as you mentioned, I >> always get a 0 value... >> > I am using BBB's P9_1 and P9_5 for +5v and ground, P9_21 as a trigger >> and P9_23 as echo; set GPIO 3 (P9_21) as output and GPIO 49 (P9_23) as input >> > I made a loop to read GPIO 49 every 100ms and another loop to trigger >> (gpioctl -t 3; sleep .100; gpioctl -t 3) every 2 seconds. >> > >> > what I am doing wrong? feeding 3.3v for 0.1 seconds as a trigger >> should't cause something to echo? >> >> Don't you have a multimeter? Have you measured the voltage on the output >> pin when you switch it to 0 and then back to 1? >> > > no, I don't have a working multimeter, mine is dead. I will buy another > one and test it as suggested, yes you are right, although I dont have an > idea on what value it should be expected > > but for curiosity, will gpioctl 49 show values anyhow equivalent to what a > multimeter would display? or I should not expect anything similar? > sorry for that question if this is too dummy, yes I completely lack on > GPIO basics, it's my first experience rss > > > > > >> -- >> Rui Paulo >> >> >> >> > From owner-freebsd-arm@FreeBSD.ORG Fri Aug 22 19:55: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96DF1D69 for ; Fri, 22 Aug 2014 19:55:16 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (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 2BEBA3D33 for ; Fri, 22 Aug 2014 19:55:16 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id m15so10870494wgh.5 for ; Fri, 22 Aug 2014 12:55:14 -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=+XRkNSiLM4SkOK8g6X+jGNfKmc40V6hf5IWSgRy1t6k=; b=ZTeLpliiFnk9Mhn37OxwE6XDMV5E5pmTsnGx9HbzuJsv45FxOEgfPJLi/3AawdWLO8 mLoOjWinyN21Eeyg4DyFABnJ4fvASgwp6buV2kZ+NoanvNRsLaVux+FZuaQbos1APPuu g9HiQblctoXbBOqqS1yGh+7EeZIKxypi068hM5e0tSn+IL4jtWQ0uJzdpl2NIPoZz194 jORnJzWrfok29m3xJBA6wY8/exqHtLIORr/Qwx1XS1r5lZlByA8/ZcNukjCNPh53fEQA MNq/2Sl4VSQkoPGDsjf+H6qQRGRZ7eaebOkaSa4maon47QuOEHgBNl79xtogHTCE/ELN LI9A== MIME-Version: 1.0 X-Received: by 10.180.106.8 with SMTP id gq8mr577618wib.56.1408737314327; Fri, 22 Aug 2014 12:55:14 -0700 (PDT) Received: by 10.216.199.70 with HTTP; Fri, 22 Aug 2014 12:55:14 -0700 (PDT) In-Reply-To: References: <5D802942-2D0F-4324-8212-C2871EEB6327@FreeBSD.org> <01562FB1-32C6-45AF-AB77-5BB80526E18C@FreeBSD.org> Date: Fri, 22 Aug 2014 16:55:14 -0300 Message-ID: Subject: Re: HC-SR04 and FreeBSD From: Luiz Otavio O Souza To: Evandro Nunes Content-Type: text/plain; charset=UTF-8 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: Fri, 22 Aug 2014 19:55:16 -0000 On 22 August 2014 00:43, Evandro Nunes wrote: > On Thu, Aug 21, 2014 at 4:13 PM, Rui Paulo wrote: > >> You can use an led instead of a multimeter. The point I'm trying to make >> is to make sure the gpio number really corresponds to that port number. >> > > still no success, but just an update... > > ok I added two led: > > pin 02: 0 gpio_2 ===> echo (orange LED) > pin 03: 0 gpio_3 ===> trigger (blue LED) > pin 49: 0 gpio_49 ===> previous echo > > and I have the two simple loops below. > > when I run loop1, BLUE LED blinks every second; > when I run loop2 while loop1 stills run, ORANGE LED won't blink, and loop2 > value still shows 0 value > > if I "gpioctl -c 2 OUT ; gpioctl -t 2", ORANGE LED will light, confirming > LED is OK; thoses leds will light with 2-5v input... however I have no idea > if the sonar output will range 2-5 or if it will be below 2 (i tried adding > my hand very close and far away from the sensor but led was never lit) Probably the echo output doesn't provide enough current to drive the LED (LEDs are driven by current and not by voltage). Be aware that you also need to limit the voltage on the sensor output to be within the 3.3V limit: https://www.modmypi.com/blog/hc-sr04-ultrasonic-range-sensor-on-the-raspberry-pi (you can can follow the explanation and the schematics) > > so I'd better use a multimeter for sure... You'd be better with a logic analyser, this kind of short pulses can't be seen on a multimeter. > > loop1: > while true ; do > gpioctl -t 3; sleep .200; gpioctl -t 3 > #gpioctl 3 > sleep 1 > done > > loop2: > while true ; do > gpioctl 2 > sleep .500 > done > The sensor output pulse will be active for a period of 116us ~ 23200us (2cm ~ 400cm, given the formula from data sheet: cm = us / 58). I'm not sure you can reliably measure such short periods from userland (but as the RPi link says it works... let's try it). You can try to remove the LED from the echo pin (to reduce its load) and reduce the sleep time on loop2 to see if you can read the sensor output. I'll see if i can get my hands on HC-SR04 so i can try it out. Luiz From owner-freebsd-arm@FreeBSD.ORG Sat Aug 23 21:00:31 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1027D59E for ; Sat, 23 Aug 2014 21:00:31 +0000 (UTC) Received: from capeta.freebsdbrasil.com.br (capeta.freebsdbrasil.com.br [177.10.156.3]) by mx1.freebsd.org (Postfix) with SMTP id C6F7A3D0C for ; Sat, 23 Aug 2014 21:00:29 +0000 (UTC) Received: (qmail 57377 invoked from network); 23 Aug 2014 17:53:30 -0300 Received: by simscan 1.4.0 ppid: 57371, pid: 57375, t: 0.2124s scanners:none Received: from unknown (HELO caterwaul.bh.freebsdbrasil.com.br) (eksffa@freebsdbrasil.com.br@187.104.54.6) by capeta.freebsdbrasil.com.br with ESMTPA; 23 Aug 2014 17:53:30 -0300 Message-ID: <53F8FED8.6030409@freebsdbrasil.com.br> Date: Sat, 23 Aug 2014 17:51:36 -0300 From: Patrick Tracanelli User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Evandro Nunes Subject: Re: HC-SR04 and FreeBSD References: <5D802942-2D0F-4324-8212-C2871EEB6327@FreeBSD.org> <01562FB1-32C6-45AF-AB77-5BB80526E18C@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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: Sat, 23 Aug 2014 21:00:31 -0000 On 08/22/14 16:55, Luiz Otavio O Souza wrote: > On 22 August 2014 00:43, Evandro Nunes wrote: >> On Thu, Aug 21, 2014 at 4:13 PM, Rui Paulo wrote: >> >>> You can use an led instead of a multimeter. The point I'm trying to make >>> is to make sure the gpio number really corresponds to that port number. >>> >> >> still no success, but just an update... >> >> ok I added two led: >> >> pin 02: 0 gpio_2 ===> echo (orange LED) >> pin 03: 0 gpio_3 ===> trigger (blue LED) >> pin 49: 0 gpio_49 ===> previous echo >> >> and I have the two simple loops below. >> >> when I run loop1, BLUE LED blinks every second; >> when I run loop2 while loop1 stills run, ORANGE LED won't blink, and loop2 >> value still shows 0 value >> >> if I "gpioctl -c 2 OUT ; gpioctl -t 2", ORANGE LED will light, confirming >> LED is OK; thoses leds will light with 2-5v input... however I have no idea >> if the sonar output will range 2-5 or if it will be below 2 (i tried adding >> my hand very close and far away from the sensor but led was never lit) Hello, As far as I know, for this specific ultrasonic sensor, you are missing to set the echo GPIO pin to high. This sonar sensor will bring it back to 0 when the triggered sound get back to the sensor (round-trip). So the correct sequence should be, in a loop: 1 - Set echo pin to HIGH 2 - Trigger the sensor for 10us (it means your 100ms is more than you need, but no, it won’t cause a problem) 3 - Wait until echo in is LOW When the sound come back to sensor, the device will LOW the GPIO pin again. So what you have to do is to measure how long it took from step 1 to 3. This is your duration. And it means a sound-speed duration from 0 (your transmitter) until the object and back. We are talking about a 58.22 sound speed. Therefore, what you want is to determine the duration of a pulse with microsecond accuracy, to measure the duration of HIGH or LOW pulse on a pin. How to do this? I don’t know how you can get this with in the command line. First of, date(1) won’t display the time with enough precision. I believe date “+%s” is the best precision you have and it’s epoch (1 full second, not a fraction). You can use some code, however, to get a usec precision “now”. Example code below I have used in the past will do the trick. But how will you “wait” from 1 to 0 on your GPIO echo pin, on a shell script, without using almost all CPU you’ve got in your BeagleBone (and this is not much CPU), I have no idea. I would test some loop similar to this: #/bin/sh gpioctl -c 2 IN gpioctl -c 3 OUT gpioctl 3 0 gpioctl 2 0 while true ; do gpioctl 3 1 ; sleep .10; gpioctl 3 0 # trigger gpioctl 2 1 # set echo HIGH inicio=$(/root/date-precisao) # what time is it? while [ $(gpioctl 2 | tail -1) -gt 0 ] ; do echo "...” #does nothing, because the pin is still HIGH done fim=$(/root/date-precisao) # pin is now LOW, what time is it? dura=$(( $fim - $inicio )) # echo duration (HIGH to LOW usec duration) dura2=$(( $dura * 10 )) # sh doesn’t like X.Y precision, make it integer dist=$(( $dura2 / 582 )) # 58.22 should be the number but 58.2 is OK echo "Distance: $dist” # this is your not much precise distance sleep 1 done The above code is untested, I just wrote it on this e-mail. Your CPU will be insanely high because this is not something that should be done on shell script, and therefore, your distance precision won’t be reliable. However, you will have a relative reference. Meaning, add an object 10cm from the sensor and you will have a number. Add an object 100cm from the and you will have another number, hopefully a 10 times higher number — maybe 9, maybe 12, expect imprecision caused by high CPU usage and a big latency on shell commands getting executed to do a math that should be done somehow else. Good luck with your experiments. FreeBSD/arm with a BeagleBone is a HELL of a FUN ]:-) /* * Dummy code to print date with usec precision * Patrick Tracanelli * * clang date-precisao.c -o date-precisao (should cleanly compile) * */ #include #include #include int main(void) { struct timeval agora; struct tm *t; char time[9]; int ret; ret = gettimeofday(&agora, 0); t = localtime(&agora.tv_sec); ret = strftime(time, sizeof(time), "%H%M%S", t); // xunxo 999 pq as vezes em armv6 fica zerado... printf("999%s%06ld\n", time, agora.tv_usec); return 0; } > > Probably the echo output doesn't provide enough current to drive the > LED (LEDs are driven by current and not by voltage). > > Be aware that you also need to limit the voltage on the sensor output > to be within the 3.3V limit: > > https://www.modmypi.com/blog/hc-sr04-ultrasonic-range-sensor-on-the-raspberry-pi > > (you can can follow the explanation and the schematics) > >> >> so I'd better use a multimeter for sure... > > You'd be better with a logic analyser, this kind of short pulses can't > be seen on a multimeter. > >> >> loop1: >> while true ; do >> gpioctl -t 3; sleep .200; gpioctl -t 3 >> #gpioctl 3 >> sleep 1 >> done >> >> loop2: >> while true ; do >> gpioctl 2 >> sleep .500 >> done >> > > The sensor output pulse will be active for a period of 116us ~ 23200us > (2cm ~ 400cm, given the formula from data sheet: cm = us / 58). > > I'm not sure you can reliably measure such short periods from userland > (but as the RPi link says it works... let's try it). > > You can try to remove the LED from the echo pin (to reduce its load) > and reduce the sleep time on loop2 to see if you can read the sensor > output. > > I'll see if i can get my hands on HC-SR04 so i can try it out. > > Luiz > _______________________________________________ > 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" >