From owner-freebsd-arm@freebsd.org Sun Sep 27 03:30:58 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9C499D09B1 for ; Sun, 27 Sep 2015 03:30:57 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A6E0ED2F for ; Sun, 27 Sep 2015 03:30:57 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by vkgd64 with SMTP id d64so75290330vkg.0 for ; Sat, 26 Sep 2015 20:30: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=NkxASsohxvvmhXiXMuEm1B0KRSjGhZMROGON8q9GMsc=; b=ei+GJqVdoEzmRTEAK0M3HobDzRBhD3Yt25BTg15XPvRrPuC1JqvepVYdOYWEODUdv8 AQ6NlVlTB3fBlOYoasLQjFlfzxgmjmHfpRX6udmPvZbvn1w6bdVtlH7o8K8eqGY1NC+a IsyGnWXTekMUZI9jScyYQoeyXDSTIwpkLWb4QS+UG42ohEOt269DM3QjbSo1wfVh4qsh fCbPPPCsMg35Sy9/AFm9GIMWJLOWdiXeBK6dGRvb1DhB97FBu5oCH+30+pmQNq+oTr0R vIK7S+YGsKVvee2GFtTN2bcdkvYo8735hUQAFxhe4Q60dV6n3XAJ8HvOPTzhK6TTTNgS nupQ== MIME-Version: 1.0 X-Received: by 10.31.160.5 with SMTP id j5mr8513540vke.107.1443324656377; Sat, 26 Sep 2015 20:30:56 -0700 (PDT) Received: by 10.31.89.135 with HTTP; Sat, 26 Sep 2015 20:30:56 -0700 (PDT) Date: Sat, 26 Sep 2015 20:30:56 -0700 Message-ID: Subject: Dual Core Hummingboard - Fatal kernel mode data abort: 'Translation Fault (L1)' on read From: Russell Haley To: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 03:30:58 -0000 Hello, So my dual core hummingboard now loads the kernel, but I get an error stating: Fatal kernel mode data abort: 'Translation Fault (L1)' on read. The following is my output. >From power on: *U-Boot SPL 2013.10-rc4-ge4bc4c3-dirty (Jul 16 2015 - 19:15:56)Boot Device: SD1spl: error reading image u-boot.img, err - -1Load image from RAW...U-Boot 2013.10-rc4-ge4bc4c3-dirty (Jul 16 2015 - 19:15:56)CPU: Freescale i.MX6Q rev1.5 at 792 MHzReset cause: PORBoard: MX6-HummingBoardDRAM: 1 GiBMMC: FSL_SDHC: 0*** Warning - bad CRC, using default environmentIPU DMFC NORMAL mode: 1(0~1), 5B(4,5), 5F(6,7)panel size = 1024 x 768pixel clk = 64998000clk->parent->rate = 260000000[1] rounded pixel clk = 65000000[1] parent rate = 0[1] pre-div = 0[1] post-div = 0clk->parent->rate = 65000000rounded pixel clk = 65000000div = 65000000IPU DMFC DP HIGH RES: 1(0,1), 5B(2~5), 5F(6,7)In: serialOut: vgaErr: vgaNet: FEC [PRIME](Re)start USB...USB0: USB EHCI 1.00scanning bus 0 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) foundHit any key to stop autoboot: 0HummingBoard U-Boot >* >From u-boot prompt, I enter the following u-boot commands: setenv fdt_file imx6dl-hummingboard.dtb; fatload mmc 0 10800000 ubldr.bin; go 10800000; And the following happens: *Booting [/boot/kernel/kernel]... /boot/dtb/imx6dl-hummingboard.dtb size=0x6dd9Loaded DTB from file 'imx6dl-hummingboard.dtb'.Kernel entry at 0x10a00100...Kernel args: (null)KDB: debugger backends: ddbKDB: current backend: ddbCopyright (c) 1992-2015 The FreeBSD Project.Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved.FreeBSD is a registered trademark of The FreeBSD Foundation.FreeBSD 11.0-CURRENT #3 r288164M: Wed Sep 23 20:48:13 PDT 2015 rhaley@Jailbird:/usr/obj/arm.armv6/usr/src/sys/IMX6 armFreeBSD clang version 3.6.1 (tags/RELEASE_361/final 237755) 20150525VT: init without driver.CPU: Cortex A9-r2 rev 10 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabledLoUU:2 LoC:2 LoUIS:2 Cache level 1: 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc 32KB/32B 4-way instruction cache Read-Allocreal memory = 1073741824 (1024 MB)avail memory = 1039437824 (991 MB)FreeBSD/SMP: Multiprocessor System Detected: 2 CPUsrandom: entropy device external interfacekbd0 at kbdmux0ofwbus0: simplebus0: on ofwbus0simplebus1: mem 0x2000000-0x20fffff on simplebus0simplebus2: mem 0x2000000-0x203ffff on simplebus1imx6_anatop0: mem 0x20c8000-0x20c8fff irq 81,86,159 on simplebus1simplebus3: on simplebus1simplebus4: mem 0x2100000-0x21fffff on simplebus0ocotp0: mem 0x21bc000-0x21bffff on simplebus4ccm0: mem 0x20c4000-0x20c7fff irq 119,120 on simplebus1l2cache0: mem 0xa02000-0xa02fff irq 124 on simplebus0l2cache0: Part number: 0x3, release: 0x7l2cache0: L2 Cache enabled: 1024KB/32B 16 waysimx_iomux0: mem 0x20e0000-0x20e3fff on simplebus1gic0: mem 0xa01000-0xa01fff,0xa00100-0xa001ff on ofwbus0gic0: pn 0x390, arch 0x1, rev 0x2, implementer 0x43b irqs 160imx_gpt0: mem 0x2098000-0x209bfff irq 87 on simplebus1Event timer "iMXGPT" frequency 66000000 Hz quality 800Timecounter "iMXGPT" frequency 66000000 Hz quality 1000mp_tmr0: mem 0xa00600-0xa0061f irq 29 on simplebus0Event timer "MPCore" frequency 492000000 Hz quality 1000uart0: mem 0x2020000-0x2023fff irq 58 on simplebus2uart0: console (115200,n,8,1)gpio0: mem 0x209c000-0x209ffff irq 98,99 on simplebus1gpiobus0: on gpio0gpioc0: on gpio0gpio1: mem 0x20a0000-0x20a3fff irq 100,101 on simplebus1gpiobus1: on gpio1gpioc1: on gpio1gpio2: mem 0x20a4000-0x20a7fff irq 102,103 on simplebus1gpiobus2: on gpio2gpioc2: on gpio2gpio3: mem 0x20a8000-0x20abfff irq 104,105 on simplebus1gpiobus3: on gpio3gpioc3: on gpio3gpio4: mem 0x20ac000-0x20affff irq 106,107 on simplebus1gpiobus4: on gpio4gpioc4: on gpio4gpio5: mem 0x20b0000-0x20b3fff irq 108,109 on simplebus1gpiobus5: on gpio5gpioc5: on gpio5gpio6: mem 0x20b4000-0x20b7fff irq 110,111 on simplebus1gpiobus6: on gpio6gpioc6: on gpio6imx_wdog0: mem 0x20bc000-0x20bffff irq 112 on simplebus1usbphy0: mem 0x20c9000-0x20c9fff irq 76 on simplebus1usbphy1: mem 0x20ca000-0x20cafff irq 77 on simplebus1src0: mem 0x20d8000-0x20dbfff irq 123,128 on simplebus1hdmi0: mem 0x120000-0x128fff irq 147 on simplebus1hdmi0: HDMI controller 13:0a:a0:c1GPR3 0f000000 -> 0f000000ehci0: mem 0x2184000-0x21841ff irq 75 on simplebus4Fatal kernel mode data abort: 'Translation Fault (L1)' on readtrapframe: 0xc2913ae0FSR=00000005, FAR=00000004, spsr=600001d3r0 =00000000, r1 =c29600d0, r2 =00000000, r3 =c2501378r4 =c2960080, r5 =00000001, r6 =c296bdc0, r7 =00000001r8 =c2960080, r9 =00000000, r10=000000ff, r11=c2913ba8r12=c275330c, ssp=c2913b70, slr=c2501454, pc =c25010b4[ thread pid 0 tid 100000 ]Stopped at keg_fetch_slab+0x164: ldr r3, [r2, #0x004]!* Thanks, Russ From owner-freebsd-arm@freebsd.org Sun Sep 27 04:07:07 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75CA8A0AC37 for ; Sun, 27 Sep 2015 04:07:07 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32A4DFC8 for ; Sun, 27 Sep 2015 04:07:07 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by vkgd64 with SMTP id d64so75452049vkg.0 for ; Sat, 26 Sep 2015 21:07:06 -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=bkRXSqjzazXWA9hU5/89klqXcouD8FcWu3M8CFzgknE=; b=jj2x/FQpKaR38csdd3icDDODFCt5uyz4n5ChBlmK2xPcltAKoexSm+Rl0/E1VOY1Ro q5ZRt4X4T2XALkOn6bH3aI7zZm286PTEaIFvY0mEyiQDI9dDO/qmSf5Diif9dNzTWC0u rzW4fqNR7+yH0n+pBIdvLkBIqNmG9FTlTTlCW4HJByBEty95xdRwqkSqqe0tfKLIU4Eh ubMonRDyhn7ajknxJR2gO1e+k0nXqMA0x9kEUas6JtjyZZ4+J4UHUwX6i0Sxm8lqRZyS S3vZgwy5CCj+Lu5GP+YRDoeT+TNuYIueVjd21k92Pj7kevAHEATx7FCmF0KNI7HomruQ yZFQ== MIME-Version: 1.0 X-Received: by 10.31.154.131 with SMTP id c125mr8416122vke.96.1443326825911; Sat, 26 Sep 2015 21:07:05 -0700 (PDT) Received: by 10.31.89.135 with HTTP; Sat, 26 Sep 2015 21:07:05 -0700 (PDT) In-Reply-To: <1443104974.1224.269.camel@freebsd.org> References: <1443104974.1224.269.camel@freebsd.org> Date: Sat, 26 Sep 2015 21:07:05 -0700 Message-ID: Subject: Re: Building Less? From: Russell Haley To: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 04:07:07 -0000 Awesome, thanks for the src.conf files Michael, and thank you Ian for the description. It's kind of like the secret recipe! Together with the memdisk method that Ganbold has suggested I should be able to bring down my turn-around time. Cheers, Russ On Thu, Sep 24, 2015 at 7:29 AM, Ian Lepore wrote: > On Wed, 2015-09-23 at 22:15 -0700, Russell Haley wrote: > > Hi there, > > > > I've pivoted back to my ARM board again. I noticed that when I build > world, > > it builds all the man pages and languages and a whole bunch of other > stuff. > > That's not too bad because I have a decent computer, but when I run > > installworld and install onto an sd card things get really slow. > > > > Is there a way to reduce what I am building and installing onto the sd > card? > > > > > > Current process: > > make -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6 -j10 buildworld > > > > make -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6 KERNCONF=IMX6 -j10 > buildkernel > > > > sudo mount /dev/da2s2 /usr/jails/Jailbird/mnt/ufspart > > make TARGET=arm TARGET_ARCH=armv6 DESTDIR=/mnt/ufspart installworld > > distribution > > > > > > > > Thanks, > > > > Russ > > Add to your crossbuild command line "srcconf=/some/path/src.conf" and in > that src.conf file put a bunch of WITHOUT_foo commands to eliminate the > things you don't need in the target system. Iirc, you need a fully- > qualified pathname in the srcconf=. > > "man src.conf" gives you the list of WITH/WITHOUT controls you can set. > > Be sure to keep your crossbuild src.conf file(s) separate from your > main /etc/src.conf file that's used when you build the host system. > > -- Ian > > > From owner-freebsd-arm@freebsd.org Sun Sep 27 04:49:25 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD28BA0ACE2 for ; Sun, 27 Sep 2015 04:49:24 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AEABEBD0; Sun, 27 Sep 2015 04:49:24 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by vkhf67 with SMTP id f67so75537319vkh.1; Sat, 26 Sep 2015 21:49:23 -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=wep7sw3gSHxH68iiJY/y1iiZM84npaToUJibD66pxf8=; b=LmdBZqv9BAISMIED1oYYaS1g8XIM9bRbJjg13SNV0951EqqluXwn12HZfXWtNR5HLC nBDJetllpNGn3+GhquhE0T0bWGxPCWywyg+k8o8j3yavFaV9u/w2Ns8wT5MZnASGPhA7 j8xMQ3wIePg2lyO/MRG/WnlUrulSr4boiHY53lAQUxPu5PImDZAm5mrvHCMF2431HwAc tkKR3C0jdpXywhSw3++IWX/c2IuY8kIYJufTF8feVVpeev7LTKll6u0fnAHdLqFq6HJV 7uKbRL+3k+ckf+OKWpGDcwZjvlFsotKHkgdrRcRFupK+DjzSNDdPoaltpLuJGMXXU52S Z0gw== MIME-Version: 1.0 X-Received: by 10.31.142.73 with SMTP id q70mr8549228vkd.13.1443329363279; Sat, 26 Sep 2015 21:49:23 -0700 (PDT) Received: by 10.31.89.135 with HTTP; Sat, 26 Sep 2015 21:49:23 -0700 (PDT) In-Reply-To: References: <1443104974.1224.269.camel@freebsd.org> Date: Sat, 26 Sep 2015 21:49:23 -0700 Message-ID: Subject: Re: Building Less? From: Russell Haley To: freebsd-arm , Ian Lepore Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 04:49:25 -0000 Interestingly the man pages for build that are linked to the src.conf man pages don't seem to describe the srcconf variable. Or did I miss something? https://www.freebsd.org/cgi/man.cgi?query=build&sektion=7&apropos=0&manpath=FreeBSD+10.2-RELEASE Russ On Sat, Sep 26, 2015 at 9:07 PM, Russell Haley wrote: > Awesome, thanks for the src.conf files Michael, and thank you Ian for the > description. It's kind of like the secret recipe! Together with the > memdisk method that Ganbold has suggested I should be able to bring down my > turn-around time. > > Cheers, > Russ > > On Thu, Sep 24, 2015 at 7:29 AM, Ian Lepore wrote: > >> On Wed, 2015-09-23 at 22:15 -0700, Russell Haley wrote: >> > Hi there, >> > >> > I've pivoted back to my ARM board again. I noticed that when I build >> world, >> > it builds all the man pages and languages and a whole bunch of other >> stuff. >> > That's not too bad because I have a decent computer, but when I run >> > installworld and install onto an sd card things get really slow. >> > >> > Is there a way to reduce what I am building and installing onto the sd >> card? >> > >> > >> > Current process: >> > make -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6 -j10 buildworld >> > >> > make -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6 KERNCONF=IMX6 -j10 >> buildkernel >> > >> > sudo mount /dev/da2s2 /usr/jails/Jailbird/mnt/ufspart >> > make TARGET=arm TARGET_ARCH=armv6 DESTDIR=/mnt/ufspart installworld >> > distribution >> > >> > >> > >> > Thanks, >> > >> > Russ >> >> Add to your crossbuild command line "srcconf=/some/path/src.conf" and in >> that src.conf file put a bunch of WITHOUT_foo commands to eliminate the >> things you don't need in the target system. Iirc, you need a fully- >> qualified pathname in the srcconf=. >> >> "man src.conf" gives you the list of WITH/WITHOUT controls you can set. >> >> Be sure to keep your crossbuild src.conf file(s) separate from your >> main /etc/src.conf file that's used when you build the host system. >> >> -- Ian >> >> >> > From owner-freebsd-arm@freebsd.org Sun Sep 27 10:34:53 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27FCB9D07C3 for ; Sun, 27 Sep 2015 10:34:53 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [54.72.43.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B7518BEF for ; Sun, 27 Sep 2015 10:34:52 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from [192.168.1.171] (89-27-2-202.bb.dnainternet.fi [89.27.2.202]) (authenticated bits=0) by mail.kronometrix.org (8.14.9/8.14.9) with ESMTP id t8RAYgOC037405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 27 Sep 2015 10:34:43 GMT (envelope-from sparvu@kronometrix.org) Reply-To: sparvu@kronometrix.org To: freebsd-arm@freebsd.org From: Stefan Parvu Subject: RBPI2 ds1307 rtc kernel panic X-Enigmail-Draft-Status: N1110 Organization: kronometrix.org Message-ID: <5607C63D.2010203@kronometrix.org> Date: Sun, 27 Sep 2015 13:34:37 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 10:34:53 -0000 Im seeing kernel panics after I have compiled support for DS1307 RTC device on RBPI2 hardware: panic: sleepq_add: td 0xc395b000 to sleep on wchan 0xc39fa380 with sleeping prohibited The system here: iichb0: mem 0x205000-0x20501f irq 61 on simplebus0 iicbus0: on iichb0 iic0: on iicbus0 iichb1: mem 0x804000-0x80401f irq 61 on simplebus0 iicbus1: on iichb1 iic1: on iicbus1 ds13070: at addr 0xd0 on iicbus1 FreeBSD rpi2 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r288098: Thu Aug 20 04:00:38 UTC 2015 root@rpi2:/usr/obj/usr/src/sys/KPI2 arm I have compiled the kernel by Vadim's procedure [1] but modified for RBPI2: bcm2836.dtsi: https://github.com/vzaigrin/ds1307/issues/1 Anyone any ideas why the crash ? Many thanks [1] https://vzaigrin.wordpress.com/2015/08/04/real-time-clock-on-raspberry-pi-with-freebsd-11/ -- Stefan Parvu From owner-freebsd-arm@freebsd.org Sun Sep 27 11:15:57 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D807CA0A41F for ; Sun, 27 Sep 2015 11:15:57 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 8690B169; Sun, 27 Sep 2015 11:15:57 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from chamsa.cs.huji.ac.il ([132.65.80.19]) by kabab.cs.huji.ac.il with esmtp id 1Zg9vh-000Ik3-Nl; Sun, 27 Sep 2015 14:15:41 +0300 Content-Type: multipart/mixed; boundary="Apple-Mail=_9E4B7BEB-8071-4527-8B9D-69069B183E57" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: netboot configuration [was: Re: NFS Root with Raspberry Pi (nfs_diskless: no interface)] From: Daniel Braniss In-Reply-To: <1443276119.1224.382.camel@freebsd.org> Date: Sun, 27 Sep 2015 14:15:41 +0300 Cc: freebsd-arm@freebsd.org Message-Id: <33EFE756-B428-4A72-B3C5-0E764FA8ACC6@cs.huji.ac.il> References: <20150922052522.GA62140@gmail.com> <00C49FEB-E8EF-4469-85E2-0F901215CD11@cs.huji.ac.il> <20150923050414.GB43653@gmail.com> <91AAC64E-4C38-47AA-8910-48F7654A7524@cs.huji.ac.il> <20150923174445.GE43653@gmail.com> <1443105426.1224.272.camel@freebsd.org> <20150924163658.GC32257@gmail.com> <560438C5.3090404@selasky.org> <1443142468.1224.322.camel@freebsd.org> <1443209159.1224.361.camel@freebsd.org> <12C96F79-2D70-408D-AD4C-F06F6B909AD3@cs.huji.ac.il> <1443276119.1224.382.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 11:15:58 -0000 --Apple-Mail=_9E4B7BEB-8071-4527-8B9D-69069B183E57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26 Sep 2015, at 17:01, Ian Lepore wrote: >=20 > On Sat, 2015-09-26 at 15:38 +0300, Daniel Braniss wrote: >>> On Sep 25, 2015, at 10:25 PM, Ian Lepore wrote: >>>=20 >>> On Fri, 2015-09-25 at 11:37 +0300, Daniel Braniss wrote: >>>>> On 25 Sep 2015, at 03:54, Ian Lepore wrote: >>>>>=20 >>>>> On Thu, 2015-09-24 at 19:54 +0200, Hans Petter Selasky wrote: >>>>>> On 09/24/15 18:36, Randy Westlund wrote: >>>>>>> On Thu, Sep 24, 2015 at 08:37:06AM -0600, Ian Lepore wrote: >>>>>>=20 >>> [...stuff about problems netbooting...] >>>>=20 >>>> hi Ian, >>>> can you help me here? >>>> I need the magics to get ubldr to boot from the net, >>>> i=E2=80=99m using an image built via crochet.=20 >>>>=20 >>>> cheers, >>>> danny >>>=20 >>> I've been struggling with how to set up a new default u-boot = environment >>> in our ports to make netbooting easier. The problem is that there = are >>> as many ways to netboot as there are different people wanting to do = it. >>> What I've been doing for years is loading both ubldr and the kernel = from >>> nfs, by configuring my dhcp server to provide all the info needed = (board >>> ip and netmask, server ip, ubldr file to load, and nfs root path), = all >>> based on the mac address of the board. I've learned that doesn't = work >>> well for most people who don't have easy control over their dhcp = server. >>>=20 >>> To try to keep this relatively simple, I'm going to assume that what >>> most folks want to do is: >>>=20 >>> * Load ubldr from the sdcard that has u-boot on it (not from = nfs). >>> * Make ubldr load the freebsd kernel from nfs. >>> * Use an nfs root filesystem. >>>=20 >>> So I'm assuming you've got an nfs server already serving up the root >>> filesystem (I'm not going to detail configuring that here). That >>> filesystem must contain an /etc/fstab that includes the ip:/rootpath >>> entry for the root filesystem. In other words, even though the = software >>> must already know the ip:/rootpath to find the fstab file, the file >>> still must contain a root path entry. (I find this annoying.) >>>=20 >>> Now on the u-boot side you need to add a few lines to the uEnv.txt = file >>> on the FAT partition (create the file there if it doesn't already >>> exist). You can configure a static IP address or get the IP from = dhcp: >>>=20 >>> For static IP (On RPi only, add one line: UserPreboot=3Dusb start) >>>=20 >>> loaderdev=3Dnet >>> rootpath=3D192.168.0.240:/wand >>> ipaddr=3D192.168.0.233 >>> netmask=3D255.255.255.0 >>>=20 >>>=20 >>> For DHCP (On RPi only, last line is: UserPreboot=3Dusb start && = dhcp) >>>=20 >>> loaderdev=3Dnet >>> rootpath=3D192.168.0.240:/wand >>> autoload=3Dno >>> UserPreboot=3Ddhcp >>>=20 >>> BTW, you may notice a Netboot command in the standard u-boot env. = Do >>> NOT set bootcmd=3Drun Netboot, that would make u-boot try to load = ubldr >>> over the network, which requires running a tftp server. >>>=20 >>> =E2=80=94 Ian >>=20 >> thanks!=20 >> it almost worked :-) >> - UserPreboot didn=E2=80=99t work, probably because I have the wrong = u-boot? >> stoping the boot, then typing >> usb start >> boot >> at the U-Boot> prompt saved the day! >>=20 >> - if instead of boot I type dhcp, it tries to tftp u-boot, but I = can=E2=80=99t figure out >> how to start it :-( >>=20 >> in any case, great! >> now it would be nice if we pull resources and get this diskless stuff = cleaned up >>=20 >> danny >>=20 >>=20 >=20 > I just committed the diskless fix, r288265. It should only be needed > for RPi and other systems with a usb-based NIC that initializes late = in > the boot process. tested, and it works. >=20 > All the u-boot ports have the UserPreboot hook in their env. Are you > using an old copy of crochet? (Hmmm, or has crochet never been = updated > to use the u-boot ports/packages for all the boards?) >=20 I compiled the u-boot-rpi from ports, the good news: it understands UserPreboot the bad news: the nfs boot gets stuck after a while. after much trial and error, this is what I do: hit a key to enter U-Boot then type: setenv loaderdev net boot attaching the console: --Apple-Mail=_9E4B7BEB-8071-4527-8B9D-69069B183E57 Content-Disposition: attachment; filename=boot.msg Content-Type: application/octet-stream; name="boot.msg" Content-Transfer-Encoding: 7bit U-Boot> v U-Boot 2013.01-rc1 (Sep 26 2015 - 09:44:35) arm-none-eabi-gcc (FreeBSD Ports Collection for armnoneeabi) 4.9.2 GNU ld (GNU Binutils) 2.25 U-Boot> printenv Fatboot=env exists loaderdev || env set loaderdev ${fatdev}; env exists UserFatboot && run UserFatboot; echo Booting from: ${fatdev} ${bootfile}; fatload ${fatdev} ${loadaddr} ${bootfile} && bootelf; Netboot=env exists ethact || usb start; env exists loaderdev || env set loaderdev net; env exists UserNetboot && run UserNetboot; dhcp ${loadaddr} ${bootfile} && bootelf; Preboot=fdt addr 0x100; env exists bootfile || bootfile=ubldr; env exists uenv_file || uenv_file=uEnv.txt; env exists SetupFatdev && run SetupFatdev; env exists SetupUenv && run SetupUenv; env exists UserPreboot && run UserPreboot; SetupFatdev=env exists fatdev || fatdev='mmc 0'; SetupUenv=fatload ${fatdev} ${loadaddr} ${uenv_file} && env import -t ${loadaddr} ${filesize}; UserPreboot=usb start arch=arm baudrate=115200 board=rpi_b board_name=rpi_b bootcmd=run Fatboot bootdelay=3 bootscript=fdt addr 0x100;bootelf 0x2000000 cpu=arm1176 ethact=sms0 fdtaddr=100 filesize=0x9c loadaddr=0x02000000 loadbootscript=fatload mmc 0 0x2000000 ubldr preboot=run Preboot soc=bcm2835 stderr=serial,lcd stdin=serial stdout=serial,lcd usbethaddr=b8:27:eb:7e:f3:9c vendor=raspberrypi Environment size: 1201/16380 bytes U-Boot> show HUSH_VERSION=0.01 bootfile=ubldr uenv_file=uEnv.txt fatdev=mmc 0 U-Boot> printenv Fatboot=env exists loaderdev || env set loaderdev ${fatdev}; env exists UserFatboot && run UserFatboot; echo Booting from: ${fatdev} ${bootfile}; fatload ${fatdev} ${loadaddr} ${bootfile} && bootelf; Netboot=env exists ethact || usb start; env exists loaderdev || env set loaderdev net; env exists UserNetboot && run UserNetboot; dhcp ${loadaddr} ${bootfile} && bootelf; Preboot=fdt addr 0x100; env exists bootfile || bootfile=ubldr; env exists uenv_file || uenv_file=uEnv.txt; env exists SetupFatdev && run SetupFatdev; env exists SetupUenv && run SetupUenv; env exists UserPreboot && run UserPreboot; SetupFatdev=env exists fatdev || fatdev='mmc 0'; SetupUenv=fatload ${fatdev} ${loadaddr} ${uenv_file} && env import -t ${loadaddr} ${filesize}; UserPreboot=usb start arch=arm baudrate=115200 board=rpi_b board_name=rpi_b bootcmd=run Fatboot bootdelay=3 bootscript=fdt addr 0x100;bootelf 0x2000000 cpu=arm1176 ethact=sms0 fdtaddr=100 filesize=0x9c loadaddr=0x02000000 loadbootscript=fatload mmc 0 0x2000000 ubldr preboot=run Preboot soc=bcm2835 stderr=serial,lcd stdin=serial stdout=serial,lcd usbethaddr=b8:27:eb:7e:f3:9c vendor=raspberrypi Environment size: 1201/16380 bytes U-Boot> setenv loaderdev net U-Boot> boot Booting from: mmc 0 ubldr reading ubldr 266046 bytes read in 69558 ms (2.9 KiB/s) ## Starting application at 0x01000094 ... Consoles: U-Boot console Compatible U-Boot API signature found @1db682a8 FreeBSD/armv6 U-Boot loader, Revision 1.2 (danny@rnd, Fri Sep 25 12:02:55 IDT 2015) DRAM: 480MB Number of U-Boot devices: 2 U-Boot env: loaderdev='net' Found U-Boot device: disk Found U-Boot device: net Waiting for Ethernet connection... done. /boot/kernel/kernel data=0x6d07e4+0xe781c / --Apple-Mail=_9E4B7BEB-8071-4527-8B9D-69069B183E57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Do you want it to load ubldr via tftp instead of from the sdcard? not sure what i want :-), with traditional pxe capable bioses, the = boot/dhcp has 2 stages, first if vendor id is set to PXEClient it sets filename to = pxeboot, then pxeboot sets vendor id to FreeBSD, and a whole bunch of other stuff is provided, like root-path, etc. in the case of rpi, if dhcp does not provide a filename, it goes an = tries to tftp load a nnnnnnn.img! so, for RPI, we don=E2=80=99t need the PXE stuff that deals with the net = driver, but would be nice (and i=E2=80=99m looking into it) to set the vendor id = stuff, but I=E2=80=99m stuck in first base. > That's an option, but ubldr doesn't change very often so just using = the > one on the sdcard should be good enough. >=20 > If you want u-boot to get an IP address via dhcp without trying to = tftp > an image, do "setenv autoload no" before the dhcp command. >=20 > -- Ian >=20 --Apple-Mail=_9E4B7BEB-8071-4527-8B9D-69069B183E57-- From owner-freebsd-arm@freebsd.org Sun Sep 27 12:09:02 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D1E1A0A7C9 for ; Sun, 27 Sep 2015 12:09:02 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EB805DF9 for ; Sun, 27 Sep 2015 12:09:01 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by wicge5 with SMTP id ge5so71506266wic.0 for ; Sun, 27 Sep 2015 05:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=L8jFesGuz3+6xRw4yQz5411R0CG3sQ3fmCct3vqWJWw=; b=AK6cppS88+GxQ+L/JCC8BClNrcTOkv+BYoGA6StnjmICM3CY7BetS1YEaEjscWHPf6 7V5YRgLhcQxEezNAdyhnLT1c0LheZp7hlI/qrKeowpJah1ZJtDDqqjlvfItcgxVDOBZH y7N8sSprKK9ok+LbY5dBnN2vFVuL+C+8uOFkOJlIsT55W35VX7Cy/J1xlMZ8kdrUVxc4 MrBIreZ3fAPsJ7VpRvu85fnOHXn2Jo4lPvqCcsQu3fRYY+USfYtauGN0x8V4hWdg+BM/ YBgJ93G9vBqhf2zuhKjdfY8dSUC7BxwyhOW4hSKs35oXb4XI0ZK7+/Sj96B1uGjUQhsk eCwg== X-Received: by 10.180.8.36 with SMTP id o4mr14001560wia.82.1443355740095; Sun, 27 Sep 2015 05:09:00 -0700 (PDT) Received: from [192.168.1.131] (xdsl-205-163.nblnetworks.fi. [83.145.205.163]) by smtp.googlemail.com with ESMTPSA id s1sm550628wik.16.2015.09.27.05.08.58 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Sep 2015 05:08:59 -0700 (PDT) Subject: Re: RBPI2 ds1307 rtc kernel panic To: sparvu@kronometrix.org References: <5607C63D.2010203@kronometrix.org> Cc: freebsd-arm@FreeBSD.org From: Jukka Ukkonen X-Enigmail-Draft-Status: N1110 Message-ID: <5607DC59.5050509@gmail.com> Date: Sun, 27 Sep 2015 15:08:57 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5607C63D.2010203@kronometrix.org> Content-Type: multipart/mixed; boundary="------------020705080105050600090706" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 12:09:02 -0000 This is a multi-part message in MIME format. --------------020705080105050600090706 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 09/27/15 13:34, Stefan Parvu wrote: > > Im seeing kernel panics after I have compiled support for DS1307 RTC > device on RBPI2 hardware: > > panic: sleepq_add: td 0xc395b000 to sleep on wchan 0xc39fa380 with > sleeping prohibited > > The system here: > > iichb0: mem 0x205000-0x20501f irq 61 on > simplebus0 > iicbus0: on iichb0 > iic0: on iicbus0 > iichb1: mem 0x804000-0x80401f irq 61 on > simplebus0 > iicbus1: on iichb1 > iic1: on iicbus1 > ds13070: at addr 0xd0 on iicbus1 > > > FreeBSD rpi2 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r288098: Thu Aug 20 > 04:00:38 UTC 2015 root@rpi2:/usr/obj/usr/src/sys/KPI2 arm > > > I have compiled the kernel by Vadim's procedure [1] but modified for > RBPI2: bcm2836.dtsi: https://github.com/vzaigrin/ds1307/issues/1 > > Anyone any ideas why the crash ? > Many thanks > > [1] > https://vzaigrin.wordpress.com/2015/08/04/real-time-clock-on-raspberry-pi-with-freebsd-11/ > Hi Stefan! I have used a different chip (Maxim ds3231), but I guess the process should be much the same for your chip. In my kernel configuration (sys/arm/conf/RPI-B) I have added this line ... device ds3231 in your case this should become device ds1307 In the DTS file (sys/boot/fdt/dts/arm/rpi.dts) I added the attached patch. In your case you should of course change the name of the chip in the DTS to ds1307 as well. The same changes work also for a ds3231 on RPI2. I have successfully equipped both my RPI-B and my PRI2 with the ds3231 chip. For RPI2 the files to modify are - sys/arm/conf/RPI2 and - sys/boot/fdt/dts/arm/rpi2.dts I hope this helps. Cheers, --jau --------------020705080105050600090706 Content-Type: text/x-patch; name="RPI-B-dts-ds3231.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="RPI-B-dts-ds3231.patch" Index: src.head/sys/boot/fdt/dts/arm/rpi.dts =================================================================== --- sys/boot/fdt/dts/arm/rpi.dts (revision 288306) +++ sys/boot/fdt/dts/arm/rpi.dts (working copy) @@ -292,6 +292,17 @@ broadcom,function = "ALT3"; }; }; + + bsc1 { + #address-cells = <0x1>; + #size-cells = <0x0>; + + rtc { + compatible = "maxim,ds3231"; + reg = <0xd0>; + }; + }; + usb { hub { compatible = "usb,hub", "usb,device"; --------------020705080105050600090706-- From owner-freebsd-arm@freebsd.org Sun Sep 27 15:57:35 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19C9DA06B1C for ; Sun, 27 Sep 2015 15:57:35 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [54.72.43.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A7B3D1A7 for ; Sun, 27 Sep 2015 15:57:34 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from [192.168.1.171] (89-27-2-202.bb.dnainternet.fi [89.27.2.202]) (authenticated bits=0) by mail.kronometrix.org (8.14.9/8.14.9) with ESMTP id t8RFvUOF039895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 27 Sep 2015 15:57:31 GMT (envelope-from sparvu@kronometrix.org) Reply-To: sparvu@kronometrix.org Subject: Re: RBPI2 ds1307 rtc kernel panic References: <5607C63D.2010203@kronometrix.org> <5607DC59.5050509@gmail.com> To: freebsd-arm@FreeBSD.org From: Stefan Parvu X-Enigmail-Draft-Status: N1110 Organization: kronometrix.org Message-ID: <560811E5.806@kronometrix.org> Date: Sun, 27 Sep 2015 18:57:25 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5607DC59.5050509@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 15:57:35 -0000 > device ds1307 > > In the DTS file (sys/boot/fdt/dts/arm/rpi.dts) I added Thanks a lot for comments. Couple of questions: 1. It seems I need to modify and add the rtc section under rpi2.dts not the bcm2836.dtsi. Do I need still to build the dtb file: root@rpi2:/usr/src/sys/tools/fdt # setenv MACHINE arm root@rpi2:/usr/src/sys/tools/fdt # ./make_dtb.sh /usr/src/sys /usr/src/sys/boot/fdt/dts/arm/rpi2.dts . converting /usr/src/sys/boot/fdt/dts/arm/rpi2.dts -> ./rpi2.dtb Warning (reg_format): "reg" property in /axi/gpio/rtc has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) Warning (avoid_default_addr_size): Relying on default #address-cells value for /axi/gpio/rtc Warning (avoid_default_addr_size): Relying on default #size-cells value for /axi/gpio/rtc 2. After modifying the rpi2.dts and the RPI2 kernel config file I just rebuild, right ? Nothing else ? Thanks, -- Stefan Parvu From owner-freebsd-arm@freebsd.org Sun Sep 27 16:14:58 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9416A0A539 for ; Sun, 27 Sep 2015 16:14:58 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A7A33AA6 for ; Sun, 27 Sep 2015 16:14:58 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sun, 27 Sep 2015 16:13:32 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t8RGEoF1009988; Sun, 27 Sep 2015 10:14:50 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1443370490.1224.392.camel@freebsd.org> Subject: Re: netboot configuration [was: Re: NFS Root with Raspberry Pi (nfs_diskless: no interface)] From: Ian Lepore To: Daniel Braniss Cc: freebsd-arm@freebsd.org Date: Sun, 27 Sep 2015 10:14:50 -0600 In-Reply-To: <33EFE756-B428-4A72-B3C5-0E764FA8ACC6@cs.huji.ac.il> References: <20150922052522.GA62140@gmail.com> <00C49FEB-E8EF-4469-85E2-0F901215CD11@cs.huji.ac.il> <20150923050414.GB43653@gmail.com> <91AAC64E-4C38-47AA-8910-48F7654A7524@cs.huji.ac.il> <20150923174445.GE43653@gmail.com> <1443105426.1224.272.camel@freebsd.org> <20150924163658.GC32257@gmail.com> <560438C5.3090404@selasky.org> <1443142468.1224.322.camel@freebsd.org> <1443209159.1224.361.camel@freebsd.org> <12C96F79-2D70-408D-AD4C-F06F6B909AD3@cs.huji.ac.il> <1443276119.1224.382.camel@freebsd.org> <33EFE756-B428-4A72-B3C5-0E764FA8ACC6@cs.huji.ac.il> Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 16:14:59 -0000 On Sun, 2015-09-27 at 14:15 +0300, Daniel Braniss wrote: > > On 26 Sep 2015, at 17:01, Ian Lepore wrote: > > > > On Sat, 2015-09-26 at 15:38 +0300, Daniel Braniss wrote: > >>> On Sep 25, 2015, at 10:25 PM, Ian Lepore wrote: > >>> > >>> On Fri, 2015-09-25 at 11:37 +0300, Daniel Braniss wrote: > >>>>> On 25 Sep 2015, at 03:54, Ian Lepore wrote: > >>>>> > >>>>> On Thu, 2015-09-24 at 19:54 +0200, Hans Petter Selasky wrote: > >>>>>> On 09/24/15 18:36, Randy Westlund wrote: > >>>>>>> On Thu, Sep 24, 2015 at 08:37:06AM -0600, Ian Lepore wrote: > >>>>>> > >>> [...stuff about problems netbooting...] > >>>> > >>>> hi Ian, > >>>> can you help me here? > >>>> I need the magics to get ubldr to boot from the net, > >>>> i’m using an image built via crochet. > >>>> > >>>> cheers, > >>>> danny > >>> > >>> I've been struggling with how to set up a new default u-boot environment > >>> in our ports to make netbooting easier. The problem is that there are > >>> as many ways to netboot as there are different people wanting to do it. > >>> What I've been doing for years is loading both ubldr and the kernel from > >>> nfs, by configuring my dhcp server to provide all the info needed (board > >>> ip and netmask, server ip, ubldr file to load, and nfs root path), all > >>> based on the mac address of the board. I've learned that doesn't work > >>> well for most people who don't have easy control over their dhcp server. > >>> > >>> To try to keep this relatively simple, I'm going to assume that what > >>> most folks want to do is: > >>> > >>> * Load ubldr from the sdcard that has u-boot on it (not from nfs). > >>> * Make ubldr load the freebsd kernel from nfs. > >>> * Use an nfs root filesystem. > >>> > >>> So I'm assuming you've got an nfs server already serving up the root > >>> filesystem (I'm not going to detail configuring that here). That > >>> filesystem must contain an /etc/fstab that includes the ip:/rootpath > >>> entry for the root filesystem. In other words, even though the software > >>> must already know the ip:/rootpath to find the fstab file, the file > >>> still must contain a root path entry. (I find this annoying.) > >>> > >>> Now on the u-boot side you need to add a few lines to the uEnv.txt file > >>> on the FAT partition (create the file there if it doesn't already > >>> exist). You can configure a static IP address or get the IP from dhcp: > >>> > >>> For static IP (On RPi only, add one line: UserPreboot=usb start) > >>> > >>> loaderdev=net > >>> rootpath=192.168.0.240:/wand > >>> ipaddr=192.168.0.233 > >>> netmask=255.255.255.0 > >>> > >>> > >>> For DHCP (On RPi only, last line is: UserPreboot=usb start && dhcp) > >>> > >>> loaderdev=net > >>> rootpath=192.168.0.240:/wand > >>> autoload=no > >>> UserPreboot=dhcp > >>> > >>> BTW, you may notice a Netboot command in the standard u-boot env. Do > >>> NOT set bootcmd=run Netboot, that would make u-boot try to load ubldr > >>> over the network, which requires running a tftp server. > >>> > >>> — Ian > >> > >> thanks! > >> it almost worked :-) > >> - UserPreboot didn’t work, probably because I have the wrong u-boot? > >> stoping the boot, then typing > >> usb start > >> boot > >> at the U-Boot> prompt saved the day! > >> > >> - if instead of boot I type dhcp, it tries to tftp u-boot, but I can’t figure out > >> how to start it :-( > >> > >> in any case, great! > >> now it would be nice if we pull resources and get this diskless stuff cleaned up > >> > >> danny > >> > >> > > > > I just committed the diskless fix, r288265. It should only be needed > > for RPi and other systems with a usb-based NIC that initializes late in > > the boot process. > tested, and it works. > > > > > All the u-boot ports have the UserPreboot hook in their env. Are you > > using an old copy of crochet? (Hmmm, or has crochet never been updated > > to use the u-boot ports/packages for all the boards?) > > > I compiled the u-boot-rpi from ports, > the good news: > it understands UserPreboot > the bad news: > the nfs boot gets stuck after a while. > > after much trial and error, this is what I do: > hit a key to enter U-Boot > then type: > setenv loaderdev net > boot > > attaching the console: I was also experiencing intermittant lockups while loader loads the kernel. I just wrote it off to failing hardware (I powered my rpi on for the first time in 6-8 months to work on this), since I've never had a problem with netbooting before (it's the only way I've ever booted the rpi). If it's not just my board going bad, then that's a bit of a mystery. The only other difference here from what I've always done is setting rootpath and other net config in u-boot instead of letting ubldr get it from dhcp. > > Do you want it to load ubldr via tftp instead of from the sdcard? > not sure what i want :-), with traditional pxe capable bioses, the boot/dhcp > has 2 stages, first if vendor id is set to PXEClient it sets filename to pxeboot, > then pxeboot sets vendor id to FreeBSD, and a whole bunch of other stuff > is provided, like root-path, etc. > > in the case of rpi, if dhcp does not provide a filename, it goes an tries > to tftp load a nnnnnnn.img! > That nnnnnnnn stuff is the board's mac address encoded as ascii-hex iirc, (but without the leading 0x), so that you can load a different image per board. > so, for RPI, we don’t need the PXE stuff that deals with the net driver, > but would be nice (and i’m looking into it) to set the vendor id stuff, > but I’m stuck in first base. > I know pretty much nothing about pxe at all. -- Ian > > That's an option, but ubldr doesn't change very often so just using the > > one on the sdcard should be good enough. > > > > If you want u-boot to get an IP address via dhcp without trying to tftp > > an image, do "setenv autoload no" before the dhcp command. > > > > -- Ian > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sun Sep 27 16:25:57 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E52B1A0AB84 for ; Sun, 27 Sep 2015 16:25:57 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 6EC7FFB9; Sun, 27 Sep 2015 16:25:56 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from e-bsd.cs.huji.ac.il ([132.65.80.241] helo=outmail.cs.huji.ac.il) by kabab.cs.huji.ac.il with esmtp id 1ZgElp-000MGt-W8; Sun, 27 Sep 2015 19:25:50 +0300 Received: from [132.65.179.20] (helo=mbpro2.bs.cs.huji.ac.il) by outmail.cs.huji.ac.il with esmtpsa id 1ZgElp-0006SD-J1; Sun, 27 Sep 2015 19:25:49 +0300 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: netboot configuration [was: Re: NFS Root with Raspberry Pi (nfs_diskless: no interface)] From: Daniel Braniss In-Reply-To: <1443370490.1224.392.camel@freebsd.org> Date: Sun, 27 Sep 2015 19:25:49 +0300 Cc: freebsd-arm@freebsd.org, Rick Macklem Message-Id: References: <20150922052522.GA62140@gmail.com> <00C49FEB-E8EF-4469-85E2-0F901215CD11@cs.huji.ac.il> <20150923050414.GB43653@gmail.com> <91AAC64E-4C38-47AA-8910-48F7654A7524@cs.huji.ac.il> <20150923174445.GE43653@gmail.com> <1443105426.1224.272.camel@freebsd.org> <20150924163658.GC32257@gmail.com> <560438C5.3090404@selasky.org> <1443142468.1224.322.camel@freebsd.org> <1443209159.1224.361.camel@freebsd.org> <12C96F79-2D70-408D-AD4C-F06F6B909AD3@cs.huji.ac.il> <1443276119.1224.382.camel@freebsd.org> <33EFE756-B428-4A72-B3C5-0E764FA8ACC6@cs.huji.ac.il> <1443370490.1224.392.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.2104) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 16:25:58 -0000 > On Sep 27, 2015, at 7:14 PM, Ian Lepore wrote: >=20 > On Sun, 2015-09-27 at 14:15 +0300, Daniel Braniss wrote: >>> On 26 Sep 2015, at 17:01, Ian Lepore wrote: >>>=20 >>> On Sat, 2015-09-26 at 15:38 +0300, Daniel Braniss wrote: >>>>> On Sep 25, 2015, at 10:25 PM, Ian Lepore wrote: >>>>>=20 >>>>> On Fri, 2015-09-25 at 11:37 +0300, Daniel Braniss wrote: >>>>>>> On 25 Sep 2015, at 03:54, Ian Lepore wrote: >>>>>>>=20 >>>>>>> On Thu, 2015-09-24 at 19:54 +0200, Hans Petter Selasky wrote: >>>>>>>> On 09/24/15 18:36, Randy Westlund wrote: >>>>>>>>> On Thu, Sep 24, 2015 at 08:37:06AM -0600, Ian Lepore wrote: >>>>>>>>=20 >>>>> [...stuff about problems netbooting...] >>>>>>=20 >>>>>> hi Ian, >>>>>> can you help me here? >>>>>> I need the magics to get ubldr to boot from the net, >>>>>> i=E2=80=99m using an image built via crochet.=20 >>>>>>=20 >>>>>> cheers, >>>>>> danny >>>>>=20 >>>>> I've been struggling with how to set up a new default u-boot = environment >>>>> in our ports to make netbooting easier. The problem is that there = are >>>>> as many ways to netboot as there are different people wanting to = do it. >>>>> What I've been doing for years is loading both ubldr and the = kernel from >>>>> nfs, by configuring my dhcp server to provide all the info needed = (board >>>>> ip and netmask, server ip, ubldr file to load, and nfs root path), = all >>>>> based on the mac address of the board. I've learned that doesn't = work >>>>> well for most people who don't have easy control over their dhcp = server. >>>>>=20 >>>>> To try to keep this relatively simple, I'm going to assume that = what >>>>> most folks want to do is: >>>>>=20 >>>>> * Load ubldr from the sdcard that has u-boot on it (not from = nfs). >>>>> * Make ubldr load the freebsd kernel from nfs. >>>>> * Use an nfs root filesystem. >>>>>=20 >>>>> So I'm assuming you've got an nfs server already serving up the = root >>>>> filesystem (I'm not going to detail configuring that here). That >>>>> filesystem must contain an /etc/fstab that includes the = ip:/rootpath >>>>> entry for the root filesystem. In other words, even though the = software >>>>> must already know the ip:/rootpath to find the fstab file, the = file >>>>> still must contain a root path entry. (I find this annoying.) >>>>>=20 >>>>> Now on the u-boot side you need to add a few lines to the uEnv.txt = file >>>>> on the FAT partition (create the file there if it doesn't already >>>>> exist). You can configure a static IP address or get the IP from = dhcp: >>>>>=20 >>>>> For static IP (On RPi only, add one line: UserPreboot=3Dusb start) >>>>>=20 >>>>> loaderdev=3Dnet >>>>> rootpath=3D192.168.0.240:/wand >>>>> ipaddr=3D192.168.0.233 >>>>> netmask=3D255.255.255.0 >>>>>=20 >>>>>=20 >>>>> For DHCP (On RPi only, last line is: UserPreboot=3Dusb start && = dhcp) >>>>>=20 >>>>> loaderdev=3Dnet >>>>> rootpath=3D192.168.0.240:/wand >>>>> autoload=3Dno >>>>> UserPreboot=3Ddhcp >>>>>=20 >>>>> BTW, you may notice a Netboot command in the standard u-boot env. = Do >>>>> NOT set bootcmd=3Drun Netboot, that would make u-boot try to load = ubldr >>>>> over the network, which requires running a tftp server. >>>>>=20 >>>>> =E2=80=94 Ian >>>>=20 >>>> thanks!=20 >>>> it almost worked :-) >>>> - UserPreboot didn=E2=80=99t work, probably because I have the = wrong u-boot? >>>> stoping the boot, then typing >>>> usb start >>>> boot >>>> at the U-Boot> prompt saved the day! >>>>=20 >>>> - if instead of boot I type dhcp, it tries to tftp u-boot, but I = can=E2=80=99t figure out >>>> how to start it :-( >>>>=20 >>>> in any case, great! >>>> now it would be nice if we pull resources and get this diskless = stuff cleaned up >>>>=20 >>>> danny >>>>=20 >>>>=20 >>>=20 >>> I just committed the diskless fix, r288265. It should only be = needed >>> for RPi and other systems with a usb-based NIC that initializes late = in >>> the boot process. >> tested, and it works. >>=20 >>>=20 >>> All the u-boot ports have the UserPreboot hook in their env. Are = you >>> using an old copy of crochet? (Hmmm, or has crochet never been = updated >>> to use the u-boot ports/packages for all the boards?) >>>=20 >> I compiled the u-boot-rpi from ports, >> the good news: >> it understands UserPreboot >> the bad news: >> the nfs boot gets stuck after a while. >>=20 >> after much trial and error, this is what I do: >> hit a key to enter U-Boot >> then type: >> setenv loaderdev net >> boot >>=20 >> attaching the console: >=20 > I was also experiencing intermittant lockups while loader loads the > kernel. I just wrote it off to failing hardware (I powered my rpi on > for the first time in 6-8 months to work on this), since I've never = had > a problem with netbooting before (it's the only way I've ever booted = the > rpi). If it's not just my board going bad, then that's a bit of a > mystery. The only other difference here from what I've always done is > setting rootpath and other net config in u-boot instead of letting = ubldr > get it from dhcp. with the stuff from crochet it works, same setup! I am sniffing the net = via wireshark, and it stops at different positions in the kernel file, so the settings of rootpath and other configs are irrelevant. the transfer is being done via udp/nfs/v3 (hence added ric :-) maybe he can see something we don=E2=80=99t. >=20 >>> Do you want it to load ubldr via tftp instead of from the sdcard? >> not sure what i want :-), with traditional pxe capable bioses, the = boot/dhcp >> has 2 stages, first if vendor id is set to PXEClient it sets filename = to pxeboot, >> then pxeboot sets vendor id to FreeBSD, and a whole bunch of other = stuff >> is provided, like root-path, etc. >>=20 >> in the case of rpi, if dhcp does not provide a filename, it goes an = tries >> to tftp load a nnnnnnn.img! >>=20 >=20 > That nnnnnnnn stuff is the board's mac address encoded as ascii-hex > iirc, (but without the leading 0x), so that you can load a different > image per board. i know, it goes back to SunOS days =E2=80=A6 >=20 >> so, for RPI, we don=E2=80=99t need the PXE stuff that deals with the = net driver, >> but would be nice (and i=E2=80=99m looking into it) to set the vendor = id stuff, >> but I=E2=80=99m stuck in first base. >>=20 >=20 > I know pretty much nothing about pxe at all. >=20 > -- Ian >=20 >>> That's an option, but ubldr doesn't change very often so just using = the >>> one on the sdcard should be good enough. >>>=20 >>> If you want u-boot to get an IP address via dhcp without trying to = tftp >>> an image, do "setenv autoload no" before the dhcp command. >>>=20 >>> -- Ian >>>=20 >>=20 >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm = >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org = " From owner-freebsd-arm@freebsd.org Sun Sep 27 16:35:20 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E39CCA0A0DA for ; Sun, 27 Sep 2015 16:35:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BA9513C9 for ; Sun, 27 Sep 2015 16:35:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sun, 27 Sep 2015 16:35:50 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t8RGZCPH010010; Sun, 27 Sep 2015 10:35:12 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1443371712.1224.398.camel@freebsd.org> Subject: Re: netboot configuration [was: Re: NFS Root with Raspberry Pi (nfs_diskless: no interface)] From: Ian Lepore To: Daniel Braniss Cc: freebsd-arm@freebsd.org, Rick Macklem Date: Sun, 27 Sep 2015 10:35:12 -0600 In-Reply-To: References: <20150922052522.GA62140@gmail.com> <00C49FEB-E8EF-4469-85E2-0F901215CD11@cs.huji.ac.il> <20150923050414.GB43653@gmail.com> <91AAC64E-4C38-47AA-8910-48F7654A7524@cs.huji.ac.il> <20150923174445.GE43653@gmail.com> <1443105426.1224.272.camel@freebsd.org> <20150924163658.GC32257@gmail.com> <560438C5.3090404@selasky.org> <1443142468.1224.322.camel@freebsd.org> <1443209159.1224.361.camel@freebsd.org> <12C96F79-2D70-408D-AD4C-F06F6B909AD3@cs.huji.ac.il> <1443276119.1224.382.camel@freebsd.org> <33EFE756-B428-4A72-B3C5-0E764FA8ACC6@cs.huji.ac.il> <1443370490.1224.392.camel@freebsd.org> Content-Type: text/plain; charset="iso-8859-7" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 16:35:20 -0000 On Sun, 2015-09-27 at 19:25 +0300, Daniel Braniss wrote: > > On Sep 27, 2015, at 7:14 PM, Ian Lepore wrote: > > > > On Sun, 2015-09-27 at 14:15 +0300, Daniel Braniss wrote: [...] > >> I compiled the u-boot-rpi from ports, > >> the good news: > >> it understands UserPreboot > >> the bad news: > >> the nfs boot gets stuck after a while. > >> > >> after much trial and error, this is what I do: > >> hit a key to enter U-Boot > >> then type: > >> setenv loaderdev net > >> boot > >> > >> attaching the console: > > > > I was also experiencing intermittant lockups while loader loads the > > kernel. I just wrote it off to failing hardware (I powered my rpi on > > for the first time in 6-8 months to work on this), since I've never had > > a problem with netbooting before (it's the only way I've ever booted the > > rpi). If it's not just my board going bad, then that's a bit of a > > mystery. The only other difference here from what I've always done is > > setting rootpath and other net config in u-boot instead of letting ubldr > > get it from dhcp. > > with the stuff from crochet it works, same setup! I am sniffing the net via > wireshark, and it stops at different positions in the kernel file, > so the settings of rootpath and other configs are irrelevant. > the transfer is being done via udp/nfs/v3 (hence added ric :-) maybe > he can see something we don¢t. Hmmm. What stuff from crochet? The two components that are in play here are u-boot itself (it contains the low-level network drivers that ubldr uses -- it's effectively acting as a bios for ubldr), and ubldr which contains the higher-level network code. In theory ubldr should be the same in both cases; nothing much has changed in the loader code for months. But there are different paths through the code depending on how it gets the network parms, and I could easily have glitched something when I added the feature that lets you set the config with u-boot env vars. The u-boot might be different between a crochet and ports build. They both start with gonzo's u-boot 2013.10 sources, but crochet probably has a slightly different set of patches it applies. -- Ian From owner-freebsd-arm@freebsd.org Sun Sep 27 17:02:46 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2D1AA0AE05 for ; Sun, 27 Sep 2015 17:02:45 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DACCF73 for ; Sun, 27 Sep 2015 17:02:45 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by wicfx3 with SMTP id fx3so76273784wic.1 for ; Sun, 27 Sep 2015 10:02:43 -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=DOCTuPMpFOudzDYLkeQZwDQ/jKhrd3kWl1pIeE6KxtY=; b=PDO6p/le8VoQcMdZM9HN06OqmZ28kdh97zDetclrY6fPVGSJo64PcFqHBoNyO4MnCy V9QPAGf2G7FEOd2K39MqAl0twFXjTfeQrpsDDLk6jY4R0l+aPV9TjHlVLHynbv85zRWP xdEoHkLNtT0inrA/wqMbMW0/eWbdRCewbs+fGx0KrXIIyi9Nmhhrd8VjRUuKIJFhHAdn 7W9fto0S4DeJrLKHA/UJZpWih1kAegjezqdOQv4QgzDYVlyCN5Ia1Aj363Hj8AQDGjlQ enr9ecqF6oyl/FIKZYuKsttiNOQmAY9p/Kp2ytTU4ItE+S6693BzrapS+Y6XA4BI4cWf Ph+w== X-Received: by 10.194.47.161 with SMTP id e1mr19442570wjn.1.1443373363855; Sun, 27 Sep 2015 10:02:43 -0700 (PDT) Received: from [192.168.1.193] (xdsl-205-163.nblnetworks.fi. [83.145.205.163]) by smtp.gmail.com with ESMTPSA id bk4sm8433164wjc.1.2015.09.27.10.02.43 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Sep 2015 10:02:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: RBPI2 ds1307 rtc kernel panic From: Jukka Ukkonen X-Mailer: iPad Mail (13A404) In-Reply-To: <560811E5.806@kronometrix.org> Date: Sun, 27 Sep 2015 20:02:43 +0300 Cc: freebsd-arm@FreeBSD.org Content-Transfer-Encoding: 7bit Message-Id: <59B7838A-A323-4656-A86B-E811DEF42C45@gmail.com> References: <5607C63D.2010203@kronometrix.org> <5607DC59.5050509@gmail.com> <560811E5.806@kronometrix.org> To: sparvu@kronometrix.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 17:02:46 -0000 Sent from my iPad > On 27 Sep 2015, at 18:57, Stefan Parvu wrote: > > >> device ds1307 >> >> In the DTS file (sys/boot/fdt/dts/arm/rpi.dts) I added > > Thanks a lot for comments. Couple of questions: > > 1. It seems I need to modify and add the rtc section under rpi2.dts not > the bcm2836.dtsi. Do I need still to build the dtb file: > > root@rpi2:/usr/src/sys/tools/fdt # setenv MACHINE arm > root@rpi2:/usr/src/sys/tools/fdt # ./make_dtb.sh /usr/src/sys > /usr/src/sys/boot/fdt/dts/arm/rpi2.dts . > converting /usr/src/sys/boot/fdt/dts/arm/rpi2.dts -> ./rpi2.dtb > Warning (reg_format): "reg" property in /axi/gpio/rtc has invalid length > (4 bytes) (#address-cells == 2, #size-cells == 1) > Warning (avoid_default_addr_size): Relying on default #address-cells > value for /axi/gpio/rtc > Warning (avoid_default_addr_size): Relying on default #size-cells value > for /axi/gpio/rtc Are there still your previous lines in the dtsi file? I don't remember having seen those complaints in a while. During my first attempts when I did not have the size-cells and address-cells in the dts I certainly saw the exact same warnings, though. > 2. After modifying the rpi2.dts and the RPI2 kernel config file I just > rebuild, right ? Nothing else ? Actually, if I remember correctly buildkernel might run dtc automatically when building for arm. It's been a while since I setup my own rpi2 build scripts. So, I don't remember this detail and at the moment I cannot go to check it on my build system. If for some reason the dtb is not automatically built, you certainly have to run dtc manually to get the dtb. When I get my hands on my build system I will try to check what it does with the dts and dtb files. At one moment I actually used a prebuilt content for the fat16 boot partition and manually modified an older dtb file converting it back to a dts with dtb, editing it converting again with dtc from dts to dtb when the ds3231 info was added. So, in the worst case I might have two distinct dtb files, one manually prebuilt one which definitely works and another automatically built one, which for all I know at the moment, could be faulty but also unused. --jau From owner-freebsd-arm@freebsd.org Sun Sep 27 18:29:50 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A694CA0AE92 for ; Sun, 27 Sep 2015 18:29:50 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6AE4936F for ; Sun, 27 Sep 2015 18:29:50 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: by ykft14 with SMTP id t14so155941326ykf.0 for ; Sun, 27 Sep 2015 11:29:49 -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=w1hP6RE2XXR3Fe4WEyoiIFOMW4OZBWUT3eqfAFA4/ec=; b=AnEWRhmqqpu2neM5jSWwBWmDfURd9UpA11y7ryAcPpNHyAstPcd/eaMIuawtMPgjmO QqJ2TjMnf3da/PDV39bSYOIkK8j+ohPaOXq/BEQDFmCMBC19+5BBkK/3St8Cll4by9e6 SFoYxuUipJj+huLUldOubjvm9fgXrXdh+o4Q6wvvjDDu+W4kFvRuPNW2SsAo8G8xrq1+ OfoDtXsI5aQmCicGsHhQpOuQhmbem3US3SfAq2Rv+haZDIrxzvF5JCrJHYb3pLD5kTNv 8+YoM6UmSdyl1pzWNAmBDQUc3Kq1HIGrQxKtCyx7yXM2ecMFiDk5XtQbRUfheGd/qF8L SllQ== MIME-Version: 1.0 X-Received: by 10.13.230.71 with SMTP id p68mr13460783ywe.132.1443378589688; Sun, 27 Sep 2015 11:29:49 -0700 (PDT) Received: by 10.129.43.70 with HTTP; Sun, 27 Sep 2015 11:29:49 -0700 (PDT) In-Reply-To: <5607C63D.2010203@kronometrix.org> References: <5607C63D.2010203@kronometrix.org> Date: Sun, 27 Sep 2015 15:29:49 -0300 Message-ID: Subject: Re: RBPI2 ds1307 rtc kernel panic From: Luiz Otavio O Souza To: sparvu@kronometrix.org Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 18:29:50 -0000 On 27 September 2015 at 07:34, Stefan Parvu wrote: > > Im seeing kernel panics after I have compiled support for DS1307 RTC > device on RBPI2 hardware: > > panic: sleepq_add: td 0xc395b000 to sleep on wchan 0xc39fa380 with > sleeping prohibited > > The system here: > > iichb0: mem 0x205000-0x20501f irq 61 on > simplebus0 > iicbus0: on iichb0 > iic0: on iicbus0 > iichb1: mem 0x804000-0x80401f irq 61 on > simplebus0 > iicbus1: on iichb1 > iic1: on iicbus1 > ds13070: at addr 0xd0 on iicbus1 > > > FreeBSD rpi2 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r288098: Thu Aug 20 > 04:00:38 UTC 2015 root@rpi2:/usr/obj/usr/src/sys/KPI2 arm > > > I have compiled the kernel by Vadim's procedure [1] but modified for > RBPI2: bcm2836.dtsi: https://github.com/vzaigrin/ds1307/issues/1 > > Anyone any ideas why the crash ? > Many thanks > > [1] > https://vzaigrin.wordpress.com/2015/08/04/real-time-clock-on-raspberry-pi-with-freebsd-11/ > > -- > Stefan Parvu The crash happens when you enable ntpd with an i2c RTC, this is a know issue. There are two workarounds: 1) sysctl machdep.rtc_save_period=0 2) use gpioiic(4) instead of the hardware i2c controller. gpioiic doesn't sleeps and this will prevent the crash. The setup of gpioiic requires a few more steps, so usually the option 1 is preferred. The crash happens because ntpd tries to update the RTC from a callout and callout functions should not sleep (which happens with most of i2c controllers we support on ARM). Also, I committed the change that includes #address-cells and #size-cells to RPi2 DTS file (bcm2836.dtsi). Thanks Jukka for noticing this. Luiz From owner-freebsd-arm@freebsd.org Sun Sep 27 18:43:29 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8318FA0A36A for ; Sun, 27 Sep 2015 18:43:29 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [54.72.43.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1AD13C94 for ; Sun, 27 Sep 2015 18:43:28 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from [192.168.1.171] (89-27-2-202.bb.dnainternet.fi [89.27.2.202]) (authenticated bits=0) by mail.kronometrix.org (8.14.9/8.14.9) with ESMTP id t8RIhPYd041165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 27 Sep 2015 18:43:25 GMT (envelope-from sparvu@kronometrix.org) Reply-To: sparvu@kronometrix.org Subject: Re: RBPI2 ds1307 rtc kernel panic References: <5607C63D.2010203@kronometrix.org> To: "freebsd-arm@freebsd.org" From: Stefan Parvu X-Enigmail-Draft-Status: N1110 Organization: kronometrix.org Message-ID: <560838C7.6010500@kronometrix.org> Date: Sun, 27 Sep 2015 21:43:19 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 18:43:29 -0000 > The crash happens when you enable ntpd with an i2c RTC, this is a know issue. > > There are two workarounds: > > 1) sysctl machdep.rtc_save_period=0 this will do just fine. thanks for clarification and for advice. We want to migrate from Raspbian to FreeBSD and we need to have a RTC hdw, for our product Kronometrix. One more thing, still a bit unclear to me: should I modify the sys/boot/fdt/dts/arm/rpi2.dts or sys/boot/fdt/dts/arm/bcm2836.dtsi Im now recompiling the kernel after I have modified the rpi2.dts, as Jukka pointed out. I did add to the sys/boot/fdt/dts/arm/rpi2.dts Jukka's patch, for ds1307. Worked fine. (built the fbt table file and install it under /boot/msdos) -- Stefan Parvu From owner-freebsd-arm@freebsd.org Mon Sep 28 01:37:26 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B20FBA0A45B for ; Mon, 28 Sep 2015 01:37:26 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67FF2F36 for ; Mon, 28 Sep 2015 01:37:26 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by vkgd64 with SMTP id d64so83125464vkg.0 for ; Sun, 27 Sep 2015 18:37:25 -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=9m4g3uJgGPgNftDahjKPBgqr7NZu6DJOcI4o1vRvb5Q=; b=1KLmZPhB4sLZPxEA/xcxUJhCqFIAFzQn40rKN9MANSWC2QmFEtYxqihhaXgnHI/XGx 77ykeKAK/AeRmAkyuAvDKNK81Vt8odtPSZER+cy57dq1UIwymtSz6yMO+JA9pbH35kLT vGZKqrnXu//bTXB74UJB4ILhB4nuN/5jlrh4gGto9MSF2nozseFK/CiUXgtYWu1andYp MG/MyT6wwJxAMvmBkq0LGRCqPPivT3tT8Nxlbj6xTns9BV+oL/j2gotgMjInpccBUOJt Y6UhKMi2xckKvI8ekImeBcvNVNvG3lTnxBknplIaehSMAcxjXobwQVPTlOQGZpXhtcoc JnrQ== MIME-Version: 1.0 X-Received: by 10.31.160.5 with SMTP id j5mr11328575vke.107.1443404245521; Sun, 27 Sep 2015 18:37:25 -0700 (PDT) Received: by 10.31.89.135 with HTTP; Sun, 27 Sep 2015 18:37:25 -0700 (PDT) In-Reply-To: References: <1443104974.1224.269.camel@freebsd.org> Date: Sun, 27 Sep 2015 18:37:25 -0700 Message-ID: Subject: Re: Building Less? From: Russell Haley To: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 01:37:26 -0000 So I had a half success. Creating the memory disk and the using the minimum build src.conf file reduced my build time to about 30 minutes! Everything fell apart when I tried to dd the image to my sd card. It ran all night and didn't complete. da2s2 is my rootfs partition. My sd card looks like this: fist 1mb raw uboot. *rhaley@Prescott:~% geom part list da2Geom name: da2modified: falsestate: OKfwheads: 255fwsectors: 63last: 7716863first: 63entries: 4scheme: MBRProviders:1. Name: da2s1 Mediasize: 52383744 (50M) Sectorsize: 512 Stripesize: 0 Stripeoffset: 1064448 Mode: r0w0e0 attrib: active rawtype: 11 length: 52383744 offset: 1064448 type: fat32 index: 1 end: 104390 start: 20792. Name: da2s2 Mediasize: 3897524736 (3.6G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 53480448 Mode: r1w1e1 rawtype: 165 length: 3897524736 offset: 53480448 type: freebsd index: 2 end: 7716806 start: 104454Consumers:1. Name: da2 Mediasize: 3951034368 (3.7G) Sectorsize: 512 Mode: r1w1e2* Here is my build commands: *#PREPARE MEMDISKtruncate -s 1024M ~/imx6.img sudo mdconfig -f imx6.img -u0 sudo newfs /dev/md0 sudo mount /dev/md0 /usr/jails/Jailbird/mnt/memdisk #IMX6make -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6 srcconf=/usr/home/rhaley/src-minimal-build.conf -j10 buildworld make -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6 KERNCONF=IMX6 srcconf=/usr/home/rhaley/src-minimal-build.conf -j10 buildkernel #INSTALLATIONmake TARGET=arm TARGET_ARCH=armv6 DESTDIR=/mnt/memdisk installworld distributionmake -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6 KERNCONF=IMX6 installkernel DESTDIR=/mnt/memdisk* *#POST BUILD * *sudo umount /dev/da2s2rhaley@Prescott:~% sudo umount /usr/jails/Jailbird/mnt/memdiskrhaley@Prescott:~% sudo mdconfig -d -u0rhaley@Prescott:~% sysctl kern.geom.debugflags=16kern.geom.debugflags: 0sysctl: kern.geom.debugflags=16: Operation not permittedrhaley@Prescott:~% sudo sysctl kern.geom.debugflags=16kern.geom.debugflags: 0 -> 16rhaley@Prescott:~% dd if=imx6.img of=/dev/da2 bs=512 seek=104454^C1680103+0 records in1680102+0 records out860212224 bytes transferred in 40541.360010 secs (21218 bytes/sec)* The dd command at the end there just ran all night before I cancelled it. The two things that stand out are: 1) I used a different block size in the dd than what was originally suggested (512 vs the suggested 4096k) 2) Perhaps my seek is incorrect? I took this value from the previous geom listing. I am hoping to preserve the existing fat partition preceding the rootfs. Any idea what I did wrong? Thanks, Russ On Sat, Sep 26, 2015 at 9:49 PM, Russell Haley wrote: > Interestingly the man pages for build that are linked to the src.conf man > pages don't seem to describe the srcconf variable. Or did I miss something? > > > https://www.freebsd.org/cgi/man.cgi?query=build&sektion=7&apropos=0&manpath=FreeBSD+10.2-RELEASE > > Russ > > On Sat, Sep 26, 2015 at 9:07 PM, Russell Haley > wrote: > >> Awesome, thanks for the src.conf files Michael, and thank you Ian for the >> description. It's kind of like the secret recipe! Together with the >> memdisk method that Ganbold has suggested I should be able to bring down my >> turn-around time. >> >> Cheers, >> Russ >> >> On Thu, Sep 24, 2015 at 7:29 AM, Ian Lepore wrote: >> >>> On Wed, 2015-09-23 at 22:15 -0700, Russell Haley wrote: >>> > Hi there, >>> > >>> > I've pivoted back to my ARM board again. I noticed that when I build >>> world, >>> > it builds all the man pages and languages and a whole bunch of other >>> stuff. >>> > That's not too bad because I have a decent computer, but when I run >>> > installworld and install onto an sd card things get really slow. >>> > >>> > Is there a way to reduce what I am building and installing onto the sd >>> card? >>> > >>> > >>> > Current process: >>> > make -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6 -j10 buildworld >>> > >>> > make -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6 KERNCONF=IMX6 -j10 >>> buildkernel >>> > >>> > sudo mount /dev/da2s2 /usr/jails/Jailbird/mnt/ufspart >>> > make TARGET=arm TARGET_ARCH=armv6 DESTDIR=/mnt/ufspart installworld >>> > distribution >>> > >>> > >>> > >>> > Thanks, >>> > >>> > Russ >>> >>> Add to your crossbuild command line "srcconf=/some/path/src.conf" and in >>> that src.conf file put a bunch of WITHOUT_foo commands to eliminate the >>> things you don't need in the target system. Iirc, you need a fully- >>> qualified pathname in the srcconf=. >>> >>> "man src.conf" gives you the list of WITH/WITHOUT controls you can set. >>> >>> Be sure to keep your crossbuild src.conf file(s) separate from your >>> main /etc/src.conf file that's used when you build the host system. >>> >>> -- Ian >>> >>> >>> >> > From owner-freebsd-arm@freebsd.org Mon Sep 28 03:20:17 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C52909CFE83 for ; Mon, 28 Sep 2015 03:20:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 718A6CE9 for ; Mon, 28 Sep 2015 03:20:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qgx61 with SMTP id 61so110976498qgx.3 for ; Sun, 27 Sep 2015 20:20:10 -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:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FvlKm0TfWQt9NpROEpCI5ar+SFHpeqEQn5c0IBv5C0M=; b=nMhK5qW9eTsAIs6KNbR5ckuWhTP4TNS3GHdgYFw0544eIym/mddePdvjFajhtSF9uN yza3CMmHyJ0XQj5SY4iyW+D8VxCqglocO3+8baKjWeEODtwBmKrKRpgwfM1tETu0zwRa DjtlFzs33tepYk+tMciOChAJozklxRNChAAKORwAIdzIOCTMJ4TFUjxHNzIR+k/DzgTS TJAKDvLJVcub1vuJHfarMTMXmFh9zFAU2p2ZzI7ox73q4f3GFYwCUgNvmLCdJifesv/o 5j57OUPZ0Q97D1xXPoZwURAi/j7Mi6QTTeTK6sFQU8wl15YT+vQwCX2F9S1NghXcDK3L M6ww== X-Gm-Message-State: ALoCoQnr7b4NlUbRpVcnCLhr1LYnONyS5BiuMYpExyT7yHvdsFcUX7tSTYQI1G2sHDvw/ZJE5+RT MIME-Version: 1.0 X-Received: by 10.140.83.202 with SMTP id j68mr20204286qgd.46.1443410410050; Sun, 27 Sep 2015 20:20:10 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.140.80.167 with HTTP; Sun, 27 Sep 2015 20:20:09 -0700 (PDT) X-Originating-IP: [2601:280:4900:3700:e41f:aefc:56c6:fc99] In-Reply-To: References: <1443104974.1224.269.camel@freebsd.org> Date: Sun, 27 Sep 2015 21:20:09 -0600 X-Google-Sender-Auth: QgnmpeYPBXft6a9R2jie71KNreM Message-ID: Subject: Re: Building Less? From: Warner Losh To: Russell Haley Cc: freebsd-arm , Ian Lepore Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 03:20:17 -0000 src.conf(5) describes it. Warner On Sat, Sep 26, 2015 at 10:49 PM, Russell Haley wrote: > Interestingly the man pages for build that are linked to the src.conf man > pages don't seem to describe the srcconf variable. Or did I miss something? > > > https://www.freebsd.org/cgi/man.cgi?query=build&sektion=7&apropos=0&manpath=FreeBSD+10.2-RELEASE > > Russ > > On Sat, Sep 26, 2015 at 9:07 PM, Russell Haley > wrote: > > > Awesome, thanks for the src.conf files Michael, and thank you Ian for the > > description. It's kind of like the secret recipe! Together with the > > memdisk method that Ganbold has suggested I should be able to bring down > my > > turn-around time. > > > > Cheers, > > Russ > > > > On Thu, Sep 24, 2015 at 7:29 AM, Ian Lepore wrote: > > > >> On Wed, 2015-09-23 at 22:15 -0700, Russell Haley wrote: > >> > Hi there, > >> > > >> > I've pivoted back to my ARM board again. I noticed that when I build > >> world, > >> > it builds all the man pages and languages and a whole bunch of other > >> stuff. > >> > That's not too bad because I have a decent computer, but when I run > >> > installworld and install onto an sd card things get really slow. > >> > > >> > Is there a way to reduce what I am building and installing onto the sd > >> card? > >> > > >> > > >> > Current process: > >> > make -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6 -j10 buildworld > >> > > >> > make -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6 KERNCONF=IMX6 -j10 > >> buildkernel > >> > > >> > sudo mount /dev/da2s2 /usr/jails/Jailbird/mnt/ufspart > >> > make TARGET=arm TARGET_ARCH=armv6 DESTDIR=/mnt/ufspart installworld > >> > distribution > >> > > >> > > >> > > >> > Thanks, > >> > > >> > Russ > >> > >> Add to your crossbuild command line "srcconf=/some/path/src.conf" and in > >> that src.conf file put a bunch of WITHOUT_foo commands to eliminate the > >> things you don't need in the target system. Iirc, you need a fully- > >> qualified pathname in the srcconf=. > >> > >> "man src.conf" gives you the list of WITH/WITHOUT controls you can set. > >> > >> Be sure to keep your crossbuild src.conf file(s) separate from your > >> main /etc/src.conf file that's used when you build the host system. > >> > >> -- Ian > >> > >> > >> > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Mon Sep 28 04:02:24 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 773EBA0BEE7 for ; Mon, 28 Sep 2015 04:02:24 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 30613C42; Mon, 28 Sep 2015 04:02:24 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by vkgd64 with SMTP id d64so84307715vkg.0; Sun, 27 Sep 2015 21:02:23 -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=tg/j8QN9G3ZoeWPfrIrHwZXDyyNf/lh/vGzoBpD5gdA=; b=pdNoAOB6s3acXOTKzwZRcWvGe9tXHat72++zQ4BIV2trC/bfeEgdo36Bmm4pHUjyQf 8xP0mOVs50SIpwCwA6IV8UntL4MXBAY3TW32fSPMZc+syTXM1h21abz8uxeSNBVXNz15 z/sehf+ZwmuB68IQcLGkReg9DxWGgWi8XZ8yVwtJ3U0fCm4fHopGy8wgGDBl9IhXIC1M dddGQinE5Ao6oEeb/THlSAt/L20+2TxPF5jYwP8HA4ex3j+wUrCI0TgPF/iuyj2c15mJ gbpXizH6YNx9C3hYXbDON8X9Zng3S60F1yrJ4ce3I1IPB8kWIxzTDRwOe/jB4bu8NiZk w9RA== MIME-Version: 1.0 X-Received: by 10.31.154.131 with SMTP id c125mr11684448vke.96.1443412942891; Sun, 27 Sep 2015 21:02:22 -0700 (PDT) Received: by 10.31.89.135 with HTTP; Sun, 27 Sep 2015 21:02:22 -0700 (PDT) In-Reply-To: References: <1443104974.1224.269.camel@freebsd.org> Date: Sun, 27 Sep 2015 21:02:22 -0700 Message-ID: Subject: Re: Building Less? From: Russell Haley To: Warner Losh Cc: Ian Lapore , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 04:02:24 -0000 Hi Warner, That's my point. The only place the file is used is during the build process. If the srcconf option is not described on man page for the build process, then it's existence would not be known to someone reading about building (i.e. me). More to the point, if I had come across the file myself, I would have wondered if it was even relevant to this version of the OS as it is not referenced in the only spot it is used (hence my question). I have experienced this confusion in the documentation before. Thanks for confirmation (sort of). I will investigate the route to reporting this to the documentation team. Cheers, Russ On Sep 27, 2015 8:20 PM, "Warner Losh" wrote: > src.conf(5) describes it. > > Warner > > On Sat, Sep 26, 2015 at 10:49 PM, Russell Haley > wrote: > >> Interestingly the man pages for build that are linked to the src.conf man >> pages don't seem to describe the srcconf variable. Or did I miss >> something? >> >> >> https://www.freebsd.org/cgi/man.cgi?query=build&sektion=7&apropos=0&manpath=FreeBSD+10.2-RELEASE >> >> Russ >> >> On Sat, Sep 26, 2015 at 9:07 PM, Russell Haley >> wrote: >> >> > Awesome, thanks for the src.conf files Michael, and thank you Ian for >> the >> > description. It's kind of like the secret recipe! Together with the >> > memdisk method that Ganbold has suggested I should be able to bring >> down my >> > turn-around time. >> > >> > Cheers, >> > Russ >> > >> > On Thu, Sep 24, 2015 at 7:29 AM, Ian Lepore wrote: >> > >> >> On Wed, 2015-09-23 at 22:15 -0700, Russell Haley wrote: >> >> > Hi there, >> >> > >> >> > I've pivoted back to my ARM board again. I noticed that when I build >> >> world, >> >> > it builds all the man pages and languages and a whole bunch of other >> >> stuff. >> >> > That's not too bad because I have a decent computer, but when I run >> >> > installworld and install onto an sd card things get really slow. >> >> > >> >> > Is there a way to reduce what I am building and installing onto the >> sd >> >> card? >> >> > >> >> > >> >> > Current process: >> >> > make -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6 -j10 buildworld >> >> > >> >> > make -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6 KERNCONF=IMX6 -j10 >> >> buildkernel >> >> > >> >> > sudo mount /dev/da2s2 /usr/jails/Jailbird/mnt/ufspart >> >> > make TARGET=arm TARGET_ARCH=armv6 DESTDIR=/mnt/ufspart installworld >> >> > distribution >> >> > >> >> > >> >> > >> >> > Thanks, >> >> > >> >> > Russ >> >> >> >> Add to your crossbuild command line "srcconf=/some/path/src.conf" and >> in >> >> that src.conf file put a bunch of WITHOUT_foo commands to eliminate the >> >> things you don't need in the target system. Iirc, you need a fully- >> >> qualified pathname in the srcconf=. >> >> >> >> "man src.conf" gives you the list of WITH/WITHOUT controls you can set. >> >> >> >> Be sure to keep your crossbuild src.conf file(s) separate from your >> >> main /etc/src.conf file that's used when you build the host system. >> >> >> >> -- Ian >> >> >> >> >> >> >> > >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> > > From owner-freebsd-arm@freebsd.org Mon Sep 28 04:06:26 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D35F99CF05B for ; Mon, 28 Sep 2015 04:06:26 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D5EBCB4 for ; Mon, 28 Sep 2015 04:06:26 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by igcrk20 with SMTP id rk20so44913957igc.1 for ; Sun, 27 Sep 2015 21:06:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=mgTQJkXcTTkFYHEQsnF3BcqsmwjXJKri3bOaNh0gpDQ=; b=CnItBzU3cOug8zGU+svrOhKnEK23S0AXG2qYEEKlGqY3oTZ23I7a3GVh0I/yJSjjqj EOZhwcF0Q5fIHgDCXWm07AyMEJ+oZMiEoji+I51UlnGIXlBp0HlIPpHxav78KF9cV1j6 Aro/YBimHZz8okzDeM73YHF5VlTDEIB6J59rX/6ekWB9QQCnq+sznYbVqG4joUISvIki G6+SUVJyAqVzDDXYTgLwit8PzHKF7VAMyZmqF7J0P3A5HWdApWHzrEWdX3i6gJmm8WoN zkpsMM7PRsIsoa9puerjU5WLAWYXmivlXI9/eUBjjT47AeJ4Y+hcNIXqUnaC5g0cdOY0 NPGw== X-Gm-Message-State: ALoCoQnqlaizBZ1qjaT/n96PO6nFDtMPC0Nc0d2dXnzO/50aHMsxh/F47tySMblu1S0kQWg+aGQK X-Received: by 10.50.176.197 with SMTP id ck5mr13680165igc.6.1443413179799; Sun, 27 Sep 2015 21:06:19 -0700 (PDT) Received: from ?IPv6:2601:280:4900:3700:f473:d326:5d09:a518? ([2601:280:4900:3700:f473:d326:5d09:a518]) by smtp.gmail.com with ESMTPSA id o9sm7206482igh.5.2015.09.27.21.06.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Sep 2015 21:06:19 -0700 (PDT) Sender: Warner Losh Subject: Re: Building Less? Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_53B6E7ED-D246-4984-A38B-9B19583D9058"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Warner Losh In-Reply-To: Date: Sun, 27 Sep 2015 22:06:19 -0600 Cc: Ian Lapore , freebsd-arm Message-Id: References: <1443104974.1224.269.camel@freebsd.org> To: Russell Haley X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 04:06:27 -0000 --Apple-Mail=_53B6E7ED-D246-4984-A38B-9B19583D9058 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii src.conf is only used to build /usr/src. src.con(5) documents that. = build(5) has a pointer. How would you suggest making this clearer? Warner > On Sep 27, 2015, at 10:02 PM, Russell Haley = wrote: >=20 > Hi Warner, >=20 > That's my point. The only place the file is used is during the build = process. If the srcconf option is not described on man page for the = build process, then it's existence would not be known to someone reading = about building (i.e. me). More to the point, if I had come across the = file myself, I would have wondered if it was even relevant to this = version of the OS as it is not referenced in the only spot it is used = (hence my question). I have experienced this confusion in the = documentation before. >=20 > Thanks for confirmation (sort of). I will investigate the route to = reporting this to the documentation team. >=20 >=20 > Cheers, >=20 > Russ >=20 >=20 >=20 >=20 >=20 > On Sep 27, 2015 8:20 PM, "Warner Losh" wrote: > src.conf(5) describes it. >=20 > Warner >=20 > On Sat, Sep 26, 2015 at 10:49 PM, Russell Haley = wrote: > Interestingly the man pages for build that are linked to the src.conf = man > pages don't seem to describe the srcconf variable. Or did I miss = something? >=20 > = https://www.freebsd.org/cgi/man.cgi?query=3Dbuild&sektion=3D7&apropos=3D0&= manpath=3DFreeBSD+10.2-RELEASE >=20 > Russ >=20 > On Sat, Sep 26, 2015 at 9:07 PM, Russell Haley = wrote: >=20 > > Awesome, thanks for the src.conf files Michael, and thank you Ian = for the > > description. It's kind of like the secret recipe! Together with the > > memdisk method that Ganbold has suggested I should be able to bring = down my > > turn-around time. > > > > Cheers, > > Russ > > > > On Thu, Sep 24, 2015 at 7:29 AM, Ian Lepore wrote: > > > >> On Wed, 2015-09-23 at 22:15 -0700, Russell Haley wrote: > >> > Hi there, > >> > > >> > I've pivoted back to my ARM board again. I noticed that when I = build > >> world, > >> > it builds all the man pages and languages and a whole bunch of = other > >> stuff. > >> > That's not too bad because I have a decent computer, but when I = run > >> > installworld and install onto an sd card things get really slow. > >> > > >> > Is there a way to reduce what I am building and installing onto = the sd > >> card? > >> > > >> > > >> > Current process: > >> > make -DNO_CLEAN TARGET=3Darm TARGET_ARCH=3Darmv6 -j10 buildworld > >> > > >> > make -DNO_CLEAN TARGET=3Darm TARGET_ARCH=3Darmv6 KERNCONF=3DIMX6 = -j10 > >> buildkernel > >> > > >> > sudo mount /dev/da2s2 /usr/jails/Jailbird/mnt/ufspart > >> > make TARGET=3Darm TARGET_ARCH=3Darmv6 DESTDIR=3D/mnt/ufspart = installworld > >> > distribution > >> > > >> > > >> > > >> > Thanks, > >> > > >> > Russ > >> > >> Add to your crossbuild command line "srcconf=3D/some/path/src.conf" = and in > >> that src.conf file put a bunch of WITHOUT_foo commands to eliminate = the > >> things you don't need in the target system. Iirc, you need a = fully- > >> qualified pathname in the srcconf=3D. > >> > >> "man src.conf" gives you the list of WITH/WITHOUT controls you can = set. > >> > >> Be sure to keep your crossbuild src.conf file(s) separate from your > >> main /etc/src.conf file that's used when you build the host system. > >> > >> -- Ian > >> > >> > >> > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 --Apple-Mail=_53B6E7ED-D246-4984-A38B-9B19583D9058 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWCLy8AAoJEGwc0Sh9sBEArtEQAOT+9qjdMAphLwLnpsMykKVQ L6YsVj+u+5y8j9HFYTbzoOCTbh2i01qcv4tIuoQw0qZ0zGhjrlHFYCOuCvEML6Lp DvO2FsFF7U4cQl0sUi5ia7X3VephF+8Gi98vxrn4E1BygoZbMQBasv+OFhV/Zc9O ybF+TsFKWXpqSp0HDR60baF1gyybrrFh9ZSP3NsSekgUhz0oPY50H30nFZA2nKBv ZCxU5fBSQHCpJsqizI3XhoQ0EJRjVQXKuDNP0z/Ad6gjNgFIGasSyOwAbgZIBiAT vxxfZySixEzbxwRnBD9FhF5QkX73hCpYuYqPD6B7+pS+aqFCu1VE+jZNbDmUNvi+ omyqZITJ6VG21n+AJNPE98c7xQbN/fHsajQAek6Km2zQr02TwMEvXXHbNbPVy37i buE4lQw1vYSYHlwMQQxweTDIq/aIypUHTfQHzJtFAVb/r8V73GmRQc7E3xSQV1Hk 3+qP8QihqlYrRXC8IOXqQyuIln+GFNj/1ctjwsmnOgkbFb6vpYeb+naBSpUiAlT8 Sv0xKPG4TWyDsazFP9YvVi+Csb7LlPlN12sCFfOi/2rR5VEuo25rdS41B1vTUNGV OH5lu7YMYMDeRtxxCKHHU4VyKMfGmxuQKtgEs/fbrQNFkR9XswYA4CwJq4c7On+p 5qcSJ3twXBG006VC7HFF =Et25 -----END PGP SIGNATURE----- --Apple-Mail=_53B6E7ED-D246-4984-A38B-9B19583D9058-- From owner-freebsd-arm@freebsd.org Mon Sep 28 04:21:08 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5FBFD9CFBA0 for ; Mon, 28 Sep 2015 04:21:08 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 16C9D360 for ; Mon, 28 Sep 2015 04:21:08 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by vkhf67 with SMTP id f67so84352016vkh.1 for ; Sun, 27 Sep 2015 21:21:07 -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=rWNy8zuvv4FjvDaystxF5NFUufxzY/94Puvi43nXIF4=; b=ReZySxEOwcf/7LOf/S/s4NGubQy++8CAr/ZCFAzMAqUJXnU+OIl5dqfqbxKgk3jv1f VTHPEX4NxrjiqhW5Cv/iDfi8+PsnspV5e975WwQ/4TjEP9fsNu/Sx4kEa0URcCpVWHKr A8dvDJqxkQtW3WNTz2FZtBVrXINdXmZYf36TkgGhJxESZ/VXA4Bu2tqBqrrqB4Db33Qz UfJtRMvtJdAWNAoe/W5/63y7VlB5JHpGqJPti42YfCyEw4UHNO6Pp3AXlJfKBJH11oB3 1KDh1Xv6oN6G5ywmzV3jY1UMSBrG+1L31BwRLTjWnEvK9M0a5TOH5vprg5+YZGXMCesR R7kQ== MIME-Version: 1.0 X-Received: by 10.31.160.5 with SMTP id j5mr11707712vke.107.1443414066879; Sun, 27 Sep 2015 21:21:06 -0700 (PDT) Received: by 10.31.89.135 with HTTP; Sun, 27 Sep 2015 21:21:06 -0700 (PDT) In-Reply-To: References: <1443104974.1224.269.camel@freebsd.org> Date: Sun, 27 Sep 2015 21:21:06 -0700 Message-ID: Subject: Re: Building Less? From: Russell Haley To: Warner Losh , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 04:21:08 -0000 The option should be included in the man pages for build: https://www.freebsd.org/cgi/man.cgi?query=build&sektion=7&apropos=0&manpath=FreeBSD+10.2-RELEASE "The default components included in the build are controlled by the file /etc/src.conf in the source tree. To override the default file, include the SRCCONF option in the make steps, pointing to a custom src.conf file. For more information see src.conf." Since I'm complaining, the src.conf file doesn't actually describe what it's purpose is. It says it contains settings, but not what those settings do. The reader is not informed of it's true purpose until they start reading the list of variables. There seems to be only one purpose to those settings: to control the components included in a build. So: The *src.conf* file contains settings that will apply to every build involving the FreeBSD source tree; see build(7) . becomes The *src.conf* file contains variables that control what components will apply to all builds involving the FreeBSD source tree; see build(7) . Thanks! Russ On Sun, Sep 27, 2015 at 9:06 PM, Warner Losh wrote: > src.conf is only used to build /usr/src. src.con(5) documents that. > build(5) has a pointer. > > How would you suggest making this clearer? > > Warner > > > > On Sep 27, 2015, at 10:02 PM, Russell Haley > wrote: > > > > Hi Warner, > > > > That's my point. The only place the file is used is during the build > process. If the srcconf option is not described on man page for the build > process, then it's existence would not be known to someone reading about > building (i.e. me). More to the point, if I had come across the file > myself, I would have wondered if it was even relevant to this version of > the OS as it is not referenced in the only spot it is used (hence my > question). I have experienced this confusion in the documentation before. > > > > Thanks for confirmation (sort of). I will investigate the route to > reporting this to the documentation team. > > > > > > Cheers, > > > > Russ > > > > > > > > > > > > On Sep 27, 2015 8:20 PM, "Warner Losh" wrote: > > src.conf(5) describes it. > > > > Warner > > > > On Sat, Sep 26, 2015 at 10:49 PM, Russell Haley > wrote: > > Interestingly the man pages for build that are linked to the src.conf man > > pages don't seem to describe the srcconf variable. Or did I miss > something? > > > > > https://www.freebsd.org/cgi/man.cgi?query=build&sektion=7&apropos=0&manpath=FreeBSD+10.2-RELEASE > > > > Russ > > > > On Sat, Sep 26, 2015 at 9:07 PM, Russell Haley > wrote: > > > > > Awesome, thanks for the src.conf files Michael, and thank you Ian for > the > > > description. It's kind of like the secret recipe! Together with the > > > memdisk method that Ganbold has suggested I should be able to bring > down my > > > turn-around time. > > > > > > Cheers, > > > Russ > > > > > > On Thu, Sep 24, 2015 at 7:29 AM, Ian Lepore wrote: > > > > > >> On Wed, 2015-09-23 at 22:15 -0700, Russell Haley wrote: > > >> > Hi there, > > >> > > > >> > I've pivoted back to my ARM board again. I noticed that when I build > > >> world, > > >> > it builds all the man pages and languages and a whole bunch of other > > >> stuff. > > >> > That's not too bad because I have a decent computer, but when I run > > >> > installworld and install onto an sd card things get really slow. > > >> > > > >> > Is there a way to reduce what I am building and installing onto the > sd > > >> card? > > >> > > > >> > > > >> > Current process: > > >> > make -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6 -j10 buildworld > > >> > > > >> > make -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6 KERNCONF=IMX6 -j10 > > >> buildkernel > > >> > > > >> > sudo mount /dev/da2s2 /usr/jails/Jailbird/mnt/ufspart > > >> > make TARGET=arm TARGET_ARCH=armv6 DESTDIR=/mnt/ufspart > installworld > > >> > distribution > > >> > > > >> > > > >> > > > >> > Thanks, > > >> > > > >> > Russ > > >> > > >> Add to your crossbuild command line "srcconf=/some/path/src.conf" and > in > > >> that src.conf file put a bunch of WITHOUT_foo commands to eliminate > the > > >> things you don't need in the target system. Iirc, you need a fully- > > >> qualified pathname in the srcconf=. > > >> > > >> "man src.conf" gives you the list of WITH/WITHOUT controls you can > set. > > >> > > >> Be sure to keep your crossbuild src.conf file(s) separate from your > > >> main /etc/src.conf file that's used when you build the host system. > > >> > > >> -- Ian > > >> > > >> > > >> > > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > > From owner-freebsd-arm@freebsd.org Mon Sep 28 14:20:22 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4257DA0A4C3 for ; Mon, 28 Sep 2015 14:20:22 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 22828181D for ; Mon, 28 Sep 2015 14:20:21 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 28 Sep 2015 14:20:53 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t8SEKAPl011765; Mon, 28 Sep 2015 08:20:10 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1443450010.1224.404.camel@freebsd.org> Subject: Re: Building Less? From: Ian Lepore To: Russell Haley Cc: Warner Losh , freebsd-arm Date: Mon, 28 Sep 2015 08:20:10 -0600 In-Reply-To: References: <1443104974.1224.269.camel@freebsd.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 14:20:22 -0000 I've got to agree the documentation is poor on this stuff. When I started doing freebsd-arm development full time one of the first things I did was write a wrapper script that invokes make with all the right magic for cross-building. One of the problems that needed solving was how to use custom make.conf and src.conf files instead of the ones in /etc. I couldn't find docs and had to spelunk around in the the makefiles to discover the existance of __MAKE_CONF= and srcconf=, and to this day I've got to say that it doesn't look like either of those was actually intended to be a user-accessible knob and I've never felt good about overriding them on the command line. So if this stuff is documented, it's not really easy enough to find. -- Ian On Sun, 2015-09-27 at 21:21 -0700, Russell Haley wrote: > The option should be included in the man pages for build: > > https://www.freebsd.org/cgi/man.cgi?query=build&sektion=7&apropos=0&manpath=FreeBSD+10.2-RELEASE > > "The default components included in the build are controlled by the file > /etc/src.conf in the source tree. To override the default file, include the > SRCCONF option in the make steps, pointing to a custom src.conf file. For > more information see src.conf." > > Since I'm complaining, the src.conf file doesn't actually describe what > it's purpose is. It says it contains settings, but not what those settings > do. The reader is not informed of it's true purpose until they start > reading the list of variables. There seems to be only one purpose to those > settings: to control the components included in a build. So: > > The *src.conf* file contains settings that will apply to every build > involving the FreeBSD source tree; see build(7) > . > > becomes > > The *src.conf* file contains variables that control what components > will apply to all builds > involving the FreeBSD source tree; see build(7) > . > > > Thanks! > > Russ > > On Sun, Sep 27, 2015 at 9:06 PM, Warner Losh wrote: > > > src.conf is only used to build /usr/src. src.con(5) documents that. > > build(5) has a pointer. > > > > How would you suggest making this clearer? > > > > Warner > > > > > > > On Sep 27, 2015, at 10:02 PM, Russell Haley > > wrote: > > > > > > Hi Warner, > > > > > > That's my point. The only place the file is used is during the build > > process. If the srcconf option is not described on man page for the build > > process, then it's existence would not be known to someone reading about > > building (i.e. me). More to the point, if I had come across the file > > myself, I would have wondered if it was even relevant to this version of > > the OS as it is not referenced in the only spot it is used (hence my > > question). I have experienced this confusion in the documentation before. > > > > > > Thanks for confirmation (sort of). I will investigate the route to > > reporting this to the documentation team. > > > > > > > > > Cheers, > > > > > > Russ > > > > > > > > > > > > > > > > > > On Sep 27, 2015 8:20 PM, "Warner Losh" wrote: > > > src.conf(5) describes it. > > > > > > Warner > > > > > > On Sat, Sep 26, 2015 at 10:49 PM, Russell Haley > > wrote: > > > Interestingly the man pages for build that are linked to the src.conf man > > > pages don't seem to describe the srcconf variable. Or did I miss > > something? > > > > > > > > https://www.freebsd.org/cgi/man.cgi?query=build&sektion=7&apropos=0&manpath=FreeBSD+10.2-RELEASE > > > > > > Russ > > > > > > On Sat, Sep 26, 2015 at 9:07 PM, Russell Haley > > wrote: > > > > > > > Awesome, thanks for the src.conf files Michael, and thank you Ian for > > the > > > > description. It's kind of like the secret recipe! Together with the > > > > memdisk method that Ganbold has suggested I should be able to bring > > down my > > > > turn-around time. > > > > > > > > Cheers, > > > > Russ > > > > > > > > On Thu, Sep 24, 2015 at 7:29 AM, Ian Lepore wrote: > > > > > > > >> On Wed, 2015-09-23 at 22:15 -0700, Russell Haley wrote: > > > >> > Hi there, > > > >> > > > > >> > I've pivoted back to my ARM board again. I noticed that when I build > > > >> world, > > > >> > it builds all the man pages and languages and a whole bunch of other > > > >> stuff. > > > >> > That's not too bad because I have a decent computer, but when I run > > > >> > installworld and install onto an sd card things get really slow. > > > >> > > > > >> > Is there a way to reduce what I am building and installing onto the > > sd > > > >> card? > > > >> > > > > >> > > > > >> > Current process: > > > >> > make -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6 -j10 buildworld > > > >> > > > > >> > make -DNO_CLEAN TARGET=arm TARGET_ARCH=armv6 KERNCONF=IMX6 -j10 > > > >> buildkernel > > > >> > > > > >> > sudo mount /dev/da2s2 /usr/jails/Jailbird/mnt/ufspart > > > >> > make TARGET=arm TARGET_ARCH=armv6 DESTDIR=/mnt/ufspart > > installworld > > > >> > distribution > > > >> > > > > >> > > > > >> > > > > >> > Thanks, > > > >> > > > > >> > Russ > > > >> > > > >> Add to your crossbuild command line "srcconf=/some/path/src.conf" and > > in > > > >> that src.conf file put a bunch of WITHOUT_foo commands to eliminate > > the > > > >> things you don't need in the target system. Iirc, you need a fully- > > > >> qualified pathname in the srcconf=. > > > >> > > > >> "man src.conf" gives you the list of WITH/WITHOUT controls you can > > set. > > > >> > > > >> Be sure to keep your crossbuild src.conf file(s) separate from your > > > >> main /etc/src.conf file that's used when you build the host system. > > > >> > > > >> -- Ian > > > >> > > > >> > > > >> > > > > > > > _______________________________________________ > > > freebsd-arm@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > > > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Mon Sep 28 16:35:21 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DFCF9A0B52C for ; Mon, 28 Sep 2015 16:35:21 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B245015DD for ; Mon, 28 Sep 2015 16:35:21 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t8SGTHMp070517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Sep 2015 09:29:17 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t8SGTHag070516; Mon, 28 Sep 2015 09:29:17 -0700 (PDT) (envelope-from jmg) Date: Mon, 28 Sep 2015 09:29:17 -0700 From: John-Mark Gurney To: Russell Haley Cc: Warner Losh , freebsd-arm Subject: Re: Building Less? Message-ID: <20150928162916.GU99677@funkthat.com> References: <1443104974.1224.269.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Mon, 28 Sep 2015 09:29:17 -0700 (PDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 16:35:22 -0000 Russell Haley wrote this message on Sun, Sep 27, 2015 at 21:21 -0700: > The option should be included in the man pages for build: > > https://www.freebsd.org/cgi/man.cgi?query=build&sektion=7&apropos=0&manpath=FreeBSD+10.2-RELEASE [great additions] I agree that this needs better documentation... If you send me a patch, I'll make sure it's marked up properly and committed... Thanks! > On Sun, Sep 27, 2015 at 9:06 PM, Warner Losh wrote: > > > src.conf is only used to build /usr/src. src.con(5) documents that. > > build(5) has a pointer. > > > > How would you suggest making this clearer? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Mon Sep 28 19:21:14 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D43AA0A46E for ; Mon, 28 Sep 2015 19:21:14 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E51B21601 for ; Mon, 28 Sep 2015 19:21:13 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from 127.0.0.1 (tor-exit.gansta93.com [195.154.56.44]) (authenticated bits=0) by feynman.konjz.org (8.14.7/8.14.4) with ESMTP id t8SJLwiq068569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 28 Sep 2015 15:22:00 -0400 (EDT) (envelope-from george@ceetonetechnology.com) To: "freebsd-arm@freebsd.org" From: George Rosamond Subject: BeagleBone Green X-Enigmail-Draft-Status: N1110 Message-ID: <56099322.1080804@ceetonetechnology.com> Date: Mon, 28 Sep 2015 15:21:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 19:21:14 -0000 At MakerFaire NYC this weekend, I found out that the BeagleBone Green was released. Cheaper than the Black, the only difference I saw was 'grooves' for four-pin connections to an array of sensors they are offering, eg, environmental, GPS, etc It wasn't available at the event, but it looks like the specs (and I think the chipset) are the same, if not identical. Anyone have one and build successfully? g From owner-freebsd-arm@freebsd.org Mon Sep 28 19:52:36 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB41DA0BEFC for ; Mon, 28 Sep 2015 19:52:36 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 72F791901 for ; Mon, 28 Sep 2015 19:52:36 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from 127.0.0.1 (torproxy02.31173.se [185.65.135.227]) (authenticated bits=0) by feynman.konjz.org (8.14.7/8.14.4) with ESMTP id t8SJrK7K069033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 28 Sep 2015 15:53:23 -0400 (EDT) (envelope-from george@ceetonetechnology.com) Subject: Re: Building Less? To: freebsd-arm@freebsd.org References: <1443104974.1224.269.camel@freebsd.org> <20150928162916.GU99677@funkthat.com> From: George Rosamond X-Enigmail-Draft-Status: N1110 Message-ID: <56099A79.8020403@ceetonetechnology.com> Date: Mon, 28 Sep 2015 15:52:25 -0400 MIME-Version: 1.0 In-Reply-To: <20150928162916.GU99677@funkthat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 19:52:36 -0000 John-Mark Gurney: > Russell Haley wrote this message on Sun, Sep 27, 2015 at 21:21 -0700: >> The option should be included in the man pages for build: >> >> https://www.freebsd.org/cgi/man.cgi?query=build&sektion=7&apropos=0&manpath=FreeBSD+10.2-RELEASE > > [great additions] > > I agree that this needs better documentation... If you send me a patch, > I'll make sure it's marked up properly and committed... > > Thanks! > >> On Sun, Sep 27, 2015 at 9:06 PM, Warner Losh wrote: >> >>> src.conf is only used to build /usr/src. src.con(5) documents that. >>> build(5) has a pointer. On a related note, I submitted this last year after some offline discussions with Tim and others: https://www.freebsd.org/cgi/man.cgi?query=build&sektion=7&apropos=0&manpath=FreeBSD+10.2-RELEASE Of course src.conf(5) is useful enough as it is, but a populated file makes sense to me, at least for crochet, since it can easily be explicitly referenced in the script. I don't think the *average* x86 server builder is concerned with removing bluetooth, floppy support, ipf from base, but I think for those with SoC and embedded hardware, it does matter. The point is, it might be worth having a fully commented, comprehensive /etc/src.conf file in place, at least for crochet. g From owner-freebsd-arm@freebsd.org Mon Sep 28 21:38:06 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59D9EA0A9BB for ; Mon, 28 Sep 2015 21:38:06 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 18D621FA5 for ; Mon, 28 Sep 2015 21:38:05 +0000 (UTC) (envelope-from jim@netgate.com) Received: by qkfq186 with SMTP id q186so73893352qkf.1 for ; Mon, 28 Sep 2015 14:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zt51SHW+MDKVBZoW/CyLCnC+VPxl4UFDs0xIF4LfGww=; b=GyxE9R2bYoBvscD9ZaSeTKpmKeRs6vvXXbjJxPF5Rw2Hg/ftLamO6ZQvSY8DEKvGWF 1OoeVAR/IgTI978lruBvfoQK4+qqfyrZUe+BMImewyjvCQ540p2kryvPrMY7+RkJlx7n Ej5w6yI36CzKJJDTTvrbNdErOAmnGWtRNdz+Y= 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=zt51SHW+MDKVBZoW/CyLCnC+VPxl4UFDs0xIF4LfGww=; b=eRsyXLAuXM5UZss9d7qmkMH8Xnxmk+BtOz662WVEUdFvb1K63OzfLw+fzXBAtygypl j7SaQX24DQ3+np1MwV9MlZMn+SDRvXM8Q24I+EiteDGyaVO5zt3EFZJ06ymLHRmJZ2Mr Ub56d/AET8DdHeS4I7xfEEDA+E2F4dLO6oO6AAwsd0Af4HZ8MPCqP1k7wnn3NZdnzpv6 lyDtqlt4iR1Ax//qFxW0LhI8qgjhpQGUD9KYvU+yOQul85ClsKwVUtPDtgzQrqMlNmXB QcVMXB4ly+NFdO1XXgymMxX5DBZs9J3hNzeZyum/R1vI7zvuTgaqjD+tdmk9GhwYzUf+ Ww6w== X-Gm-Message-State: ALoCoQkdznW9Mej97RmwTOSSp6KzMpDH2ZZK7eBRF0TEOcKOUFHrcKVBQHsee1U28Udpnyamhjtb X-Received: by 10.55.52.210 with SMTP id b201mr25022246qka.37.1443476284895; Mon, 28 Sep 2015 14:38:04 -0700 (PDT) Received: from jims-mbp.pfmechanics.com ([208.123.73.28]) by smtp.gmail.com with ESMTPSA id w3sm7909754qha.0.2015.09.28.14.38.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Sep 2015 14:38:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: BeagleBone Green From: Jim Thompson In-Reply-To: <56099322.1080804@ceetonetechnology.com> Date: Mon, 28 Sep 2015 16:37:59 -0500 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <967B69D5-19FA-40FE-BBFD-DFB231EEBC8D@netgate.com> References: <56099322.1080804@ceetonetechnology.com> To: George Rosamond X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 21:38:06 -0000 > On Sep 28, 2015, at 2:21 PM, George Rosamond = wrote: >=20 > At MakerFaire NYC this weekend, I found out that the BeagleBone Green > was released. Cheaper than the Black, the only difference I saw was > 'grooves' for four-pin connections to an array of sensors they are > offering, eg, environmental, GPS, etc >=20 > It wasn't available at the event, but it looks like the specs (and I > think the chipset) are the same, if not identical. >=20 > Anyone have one and build successfully? >=20 > g Differences between the Beaglebone Green and Beaglebone Black: 2x Grove connectors on Beaglebone Green (as you outlined)=20 Beaglebone Green eliminates microSD, HDMI and 5VDC barrel, and this is = what drives the $16 (list) price reduction. Power on Beaglebone Green is only via micro USB (Beaglebone Black uses = mini USB or separate 5VDC barrel) Otherwise, specs and chipset are, (as you surmised) identical. Jim From owner-freebsd-arm@freebsd.org Mon Sep 28 22:57:30 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 595C2A0BF1E for ; Mon, 28 Sep 2015 22:57:30 +0000 (UTC) (envelope-from rwestlun@gmail.com) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0DFFF18FF; Mon, 28 Sep 2015 22:57:30 +0000 (UTC) (envelope-from rwestlun@gmail.com) Received: by qgev79 with SMTP id v79so134301607qge.0; Mon, 28 Sep 2015 15:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Mh1F0ILL70EoiCIdG9j8OcBdBuNgNA8ZjEV74xwVDCg=; b=Nxb6J3Fsoz0FqvYBA0KWll6ReiNyTkQz/mS3z5B6qRKtKWAh09p5EE4GladFMhgCdX /Tk5ZEh4R8kWHfO/xKz/m+VQM+uLeT9MFIZvf9r+KWuIYAj0YDy/31tts1FCkABg9fz2 vh+CDyaYtueBMuSpptiJFWa/2cGGQzrNm8ZI5D1l6lrFdBetdbfOzlPQjlyt9VgclzdY Jkt4/Hp5H3sMm/aaay8mdGVxjcHiqNU+ECxRg7fYTZ3xIRIH6YRzlskOTccDWrtUBK0o j3utFimQ7yQQVg8Oj+cECHTiXfZC5W2/sDYcGzJqr2YAmtUr9ubeJJ3Nz8c3iBanpWCt d2Lg== X-Received: by 10.140.235.16 with SMTP id g16mr27035085qhc.33.1443481049245; Mon, 28 Sep 2015 15:57:29 -0700 (PDT) Received: from gmail.com (c-98-216-247-110.hsd1.ma.comcast.net. [98.216.247.110]) by smtp.gmail.com with ESMTPSA id v34sm8075299qge.47.2015.09.28.15.57.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Sep 2015 15:57:28 -0700 (PDT) Date: Mon, 28 Sep 2015 18:57:26 -0400 From: Randy Westlund To: Ian Lepore Cc: freebsd-arm@freebsd.org Subject: Re: netboot configuration [was: Re: NFS Root with Raspberry Pi (nfs_diskless: no interface)] Message-ID: <20150928225726.GD2887@gmail.com> References: <20150923174445.GE43653@gmail.com> <1443105426.1224.272.camel@freebsd.org> <20150924163658.GC32257@gmail.com> <560438C5.3090404@selasky.org> <1443142468.1224.322.camel@freebsd.org> <1443209159.1224.361.camel@freebsd.org> <12C96F79-2D70-408D-AD4C-F06F6B909AD3@cs.huji.ac.il> <1443276119.1224.382.camel@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6WlEvdN9Dv0WHSBl" Content-Disposition: inline In-Reply-To: <1443276119.1224.382.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 22:57:30 -0000 --6WlEvdN9Dv0WHSBl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Sep 26, 2015 at 08:01:59AM -0600, Ian Lepore wrote: > I just committed the diskless fix, r288265. It should only be needed > for RPi and other systems with a usb-based NIC that initializes late in > the boot process. Thanks for committing that. I can now boot the Pi, load ubldr via TFTP, and the kernel via NFS :) Randy --6WlEvdN9Dv0WHSBl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWCcXWAAoJEGaweXjzNsmpuB0IAMqLaJBi1BzcQ8dSDTmwr9jM g9vLOyxzKejDwGsKX9KM6drBVcV/A30LocEYX4UzvcOWluQbU+64cla5YeMTli0d dmCrEAUxeRGosRE1EywD8DRfideqBBfn1CL8LJRyQlN2/a5tyfQkn5loX36g6/kv bMxFbO7mfx5U1IOSv9VYFq8vBei8CKDWUV75l2yLGw2ddIxQHghqywqwPIUCgjLw vixDLHryTukpaMohvuF7J2Lv+t1EosY+Q2Zt1nXQ4VvJOnC+2Dfz7s1gSiMKJNqa gSbQhIu+UHu+8ol/b0Pye3cuwklph25SJdC/fVLz8NZqeFXTZG4e+01kQFuxVLk= =wzBh -----END PGP SIGNATURE----- --6WlEvdN9Dv0WHSBl-- From owner-freebsd-arm@freebsd.org Tue Sep 29 02:17:31 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2FF82A0B8CD for ; Tue, 29 Sep 2015 02:17:31 +0000 (UTC) (envelope-from rpaulo@me.com) Received: from mr11p00im-asmtp004.me.com (mr11p00im-asmtp004.me.com [17.110.69.135]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0E7041489 for ; Tue, 29 Sep 2015 02:17:31 +0000 (UTC) (envelope-from rpaulo@me.com) Received: from akita.hsd1.ca.comcast.net (c-73-162-13-215.hsd1.ca.comcast.net [73.162.13.215]) by mr11p00im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NVF001KC2CW1630@mr11p00im-asmtp004.me.com> for freebsd-arm@freebsd.org; Tue, 29 Sep 2015 02:17:23 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-09-29_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=3.68374314385633e-09 compositescore=0.959434806229091 phishscore=0 kscore.is_spamscore=0 rbsscore=0.959434806229091 recipient_to_sender_totalscore=0 spamscore=0 urlsuspectscore=0.959434806229091 adultscore=0 kscore.compositescore=0 circleOfTrustscore=0 suspectscore=0 recipient_domain_to_sender_totalscore=0 bulkscore=0 recipient_domain_to_sender_domain_totalscore=0 recipient_to_sender_domain_totalscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1412110000 definitions=main-1509290036 Message-id: <1443493039.1907.1.camel@me.com> Subject: Re: BeagleBone Green From: Rui Paulo To: Jim Thompson , George Rosamond Cc: "freebsd-arm@freebsd.org" Date: Mon, 28 Sep 2015 19:17:19 -0700 In-reply-to: <967B69D5-19FA-40FE-BBFD-DFB231EEBC8D@netgate.com> References: <56099322.1080804@ceetonetechnology.com> <967B69D5-19FA-40FE-BBFD-DFB231EEBC8D@netgate.com> Content-type: text/plain; charset=UTF-8 X-Mailer: Evolution 3.16.5-1 MIME-version: 1.0 Content-transfer-encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 02:17:31 -0000 On Mon, 2015-09-28 at 16:37 -0500, Jim Thompson wrote: > > > On Sep 28, 2015, at 2:21 PM, George Rosamond < > > george@ceetonetechnology.com> wrote: > > > > At MakerFaire NYC this weekend, I found out that the BeagleBone > > Green > > was released. Cheaper than the Black, the only difference I saw > > was > > 'grooves' for four-pin connections to an array of sensors they are > > offering, eg, environmental, GPS, etc > > > > It wasn't available at the event, but it looks like the specs (and > > I > > think the chipset) are the same, if not identical. > > > > Anyone have one and build successfully? > > > > g > > > Differences between the Beaglebone Green and Beaglebone Black: > > 2x Grove connectors on Beaglebone Green (as you outlined) > > Beaglebone Green eliminates microSD, HDMI and 5VDC barrel, and this > is what drives the $16 (list) price reduction. > > Power on Beaglebone Green is only via micro USB (Beaglebone Black > uses mini USB or separate 5VDC barrel) > > Otherwise, specs and chipset are, (as you surmised) identical. It just makes it much more complicated to boot FreeBSD with the lack of microSD. Probably not that attractive to FreeBSD users. -- Rui Paulo From owner-freebsd-arm@freebsd.org Tue Sep 29 02:29:02 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4222BA06151 for ; Tue, 29 Sep 2015 02:29:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F5701C6F for ; Tue, 29 Sep 2015 02:29:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qkas79 with SMTP id s79so11473101qka.0 for ; Mon, 28 Sep 2015 19:28:54 -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:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3mxLftV8O0a5vw5JQM+tUmXEUDbMEIHub0Bg5DQ/AdI=; b=aFkueGYjgBzpQ3aLm/Ybbrkt4tqzsqzFcqFPga+QozF+DP2Pz7mbVo3qpS1ZBSo6KP yHOwrr+VRXYdEDiXXDsHaonKmHXBKr2INwrH1ZhU4VkOviCRirxduU62K7WRffYr+mmJ N8kDrbU+c15BUmkuvpAXKGmCvamyfx/iWn618ghKgzHSNSUhrw+sU9WaSUxkGNB98Gnb ZyL6r+YWJaJ23QZeq7dLUkDPI2osOR+CmN7dw/n1FvuAJHNTKiLJQchQ9BVjgs8dsmnr 3PxUrz7xQUMqOzHTwNoMHIyofgFg/QAxX4RmuxbJnssqOj5/+jVLiRVqJntg8kdVvuoH imwA== X-Gm-Message-State: ALoCoQn2P4DAAezXk0pTMG1YCtXRj6WLDOJht1van1y88vMMb81RmaKf4dbkj1+5J7bNhuXw04h8 MIME-Version: 1.0 X-Received: by 10.55.24.75 with SMTP id j72mr15987655qkh.93.1443493734741; Mon, 28 Sep 2015 19:28:54 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.140.80.167 with HTTP; Mon, 28 Sep 2015 19:28:54 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <56099A79.8020403@ceetonetechnology.com> References: <1443104974.1224.269.camel@freebsd.org> <20150928162916.GU99677@funkthat.com> <56099A79.8020403@ceetonetechnology.com> Date: Mon, 28 Sep 2015 20:28:54 -0600 X-Google-Sender-Auth: GfrHn7lqlNaqMlZNAlFE1ZXKzKI Message-ID: Subject: Re: Building Less? From: Warner Losh To: George Rosamond Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 02:29:02 -0000 Crochet isn't part of the base system. If you'd like something included with crochet, you'll need to generate a patch, or talk offline with Tim. But it's unlikely that there will ever be a fully populated src.conf file in the base system. It would be too much of a hassle. We've tried that in the past, and is a big reason why we have /etc/defaults/rc.conf instead of having a fully populated /etc/rc.conf file. Why? Well, we could generate it on each build. mergemaster could install it. But it would be a guaranteed merge conflict as generated files tend to be ugly to merge. If we were to keep it up to date by hand, which might help a little on the merging problem, it would go stale quickly. We learned that with the src.conf.5 man page. If we generated something and installed it in src.conf.sample, that might be OK. However, it wouldn't be right for all platforms. The defaults are different depending on what target you are building for. That might be manageable though, since there are only a few of them. Warner On Mon, Sep 28, 2015 at 1:52 PM, George Rosamond < george@ceetonetechnology.com> wrote: > John-Mark Gurney: > > Russell Haley wrote this message on Sun, Sep 27, 2015 at 21:21 -0700: > >> The option should be included in the man pages for build: > >> > >> > https://www.freebsd.org/cgi/man.cgi?query=build&sektion=7&apropos=0&manpath=FreeBSD+10.2-RELEASE > > > > [great additions] > > > > I agree that this needs better documentation... If you send me a patch, > > I'll make sure it's marked up properly and committed... > > > > Thanks! > > > >> On Sun, Sep 27, 2015 at 9:06 PM, Warner Losh wrote: > >> > >>> src.conf is only used to build /usr/src. src.con(5) documents that. > >>> build(5) has a pointer. > > On a related note, I submitted this last year after some offline > discussions with Tim and others: > > > https://www.freebsd.org/cgi/man.cgi?query=build&sektion=7&apropos=0&manpath=FreeBSD+10.2-RELEASE > > Of course src.conf(5) is useful enough as it is, but a populated file > makes sense to me, at least for crochet, since it can easily be > explicitly referenced in the script. I don't think the *average* x86 > server builder is concerned with removing bluetooth, floppy support, ipf > from base, but I think for those with SoC and embedded hardware, it does > matter. > > The point is, it might be worth having a fully commented, comprehensive > /etc/src.conf file in place, at least for crochet. > > g > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Tue Sep 29 03:03:10 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24E7EA0B5BF for ; Tue, 29 Sep 2015 03:03:10 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6528A185D for ; Tue, 29 Sep 2015 03:03:09 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from 127.0.0.1 (server17.ofertaslimitadas.com.br [178.17.174.99]) (authenticated bits=0) by feynman.konjz.org (8.14.7/8.14.4) with ESMTP id t8T33rno076581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 28 Sep 2015 23:03:56 -0400 (EDT) (envelope-from george@ceetonetechnology.com) Subject: Re: Building Less? To: Warner Losh References: <1443104974.1224.269.camel@freebsd.org> <20150928162916.GU99677@funkthat.com> <56099A79.8020403@ceetonetechnology.com> Cc: "freebsd-arm@freebsd.org" From: George Rosamond Message-ID: <5609FF5F.2070705@ceetonetechnology.com> Date: Mon, 28 Sep 2015 23:02:55 -0400 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 03:03:10 -0000 Warner Losh: > Crochet isn't part of the base system. If you'd like something included > with crochet, you'll need to generate a patch, or talk offline with Tim. > Yes, so that's what I noted, Warner. I brought it up with Tim and thought it would be most appropriate in crochet, but others thought it should go into the base. I tend to think it's most relevant in crochet. > But it's unlikely that there will ever be a fully populated src.conf file in > the base system. It would be too much of a hassle. We've tried that in > the past, and is a big reason why we have /etc/defaults/rc.conf instead > of having a fully populated /etc/rc.conf file. Right. That makes sense to me... the defaults/ approach makes sense in both cases, but I still think it for crochet it's a sure move. > > Why? Well, we could generate it on each build. mergemaster could install > it. But it would be a guaranteed merge conflict as generated files tend > to be ugly to merge. If we were to keep it up to date by hand, which > might help a little on the merging problem, it would go stale quickly. > We learned that with the src.conf.5 man page. Got it. > > If we generated something and installed it in src.conf.sample, that might > be OK. However, it wouldn't be right for all platforms. The defaults are > different depending on what target you are building for. That might be > manageable though, since there are only a few of them. > Good insight. Thanks. So maybe I'll do the push request to freebsd/crochet and at least put it in the wind, for now. Just to repeat, I raised this for two specific reasons: 1. crochet makes explicit references to a src.conf file, so there should be a starting point/template, IMHO. 2. src.conf is useful for building a stripped down system where disk space, disk writes and memory are at a premium. g > Warner > > On Mon, Sep 28, 2015 at 1:52 PM, George Rosamond < > george@ceetonetechnology.com> wrote: > >> John-Mark Gurney: >>> Russell Haley wrote this message on Sun, Sep 27, 2015 at 21:21 -0700: >>>> The option should be included in the man pages for build: >>>> >>>> >> https://www.freebsd.org/cgi/man.cgi?query=build&sektion=7&apropos=0&manpath=FreeBSD+10.2-RELEASE >>> >>> [great additions] >>> >>> I agree that this needs better documentation... If you send me a patch, >>> I'll make sure it's marked up properly and committed... >>> >>> Thanks! >>> >>>> On Sun, Sep 27, 2015 at 9:06 PM, Warner Losh wrote: >>>> >>>>> src.conf is only used to build /usr/src. src.con(5) documents that. >>>>> build(5) has a pointer. >> >> On a related note, I submitted this last year after some offline >> discussions with Tim and others: >> >> >> https://www.freebsd.org/cgi/man.cgi?query=build&sektion=7&apropos=0&manpath=FreeBSD+10.2-RELEASE >> >> Of course src.conf(5) is useful enough as it is, but a populated file >> makes sense to me, at least for crochet, since it can easily be >> explicitly referenced in the script. I don't think the *average* x86 >> server builder is concerned with removing bluetooth, floppy support, ipf >> from base, but I think for those with SoC and embedded hardware, it does >> matter. >> >> The point is, it might be worth having a fully commented, comprehensive >> /etc/src.conf file in place, at least for crochet. >> >> g >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> > From owner-freebsd-arm@freebsd.org Tue Sep 29 03:56:53 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4CC41A0BFF6 for ; Tue, 29 Sep 2015 03:56:53 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 03F16178A for ; Tue, 29 Sep 2015 03:56:53 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by vkat63 with SMTP id t63so11404643vka.1 for ; Mon, 28 Sep 2015 20:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eyRGq/bVC9JOxobevNkeUhKyO0d5DpkbBbDz6G9vlxc=; b=yfkPk8q+ZgOfqMRhusLTKr1iex2RisS0wyyxgWnXHVoRvjZcB/Lro4Yxv8DF74UYW0 Q4NGWwl5WzavdW6+717xUKnY3rAt1UiMRv/wpGExka6V2Arw3VjPhYZTaNFZpwpIruRN hpKOhWH7ozPiUpXdwOZj6I1DvLxVT0NYRnDwmvT4bZwYr7NTNzBnIBVuyejc4cYgLvzQ 0kXKJpGVFKQNYPq2vfOQqvAEbkoZLnEc7+0ka5LJLnZvoHuIslVdTYBLs/VuzVqey2MW 6v/YJ8nh8YvcXcpswUGGyUKJQsoLRAfYRlx1uDc9gMrSrgFgq0Ru5ZJisCFoUQPC7uAi 2odQ== MIME-Version: 1.0 X-Received: by 10.31.27.214 with SMTP id b205mr14951938vkb.145.1443499011883; Mon, 28 Sep 2015 20:56:51 -0700 (PDT) Received: by 10.31.89.135 with HTTP; Mon, 28 Sep 2015 20:56:51 -0700 (PDT) In-Reply-To: <20150928162916.GU99677@funkthat.com> References: <1443104974.1224.269.camel@freebsd.org> <20150928162916.GU99677@funkthat.com> Date: Mon, 28 Sep 2015 20:56:51 -0700 Message-ID: Subject: Re: Building Less? From: Russell Haley To: John-Mark Gurney Cc: Warner Losh , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 03:56:53 -0000 Do I follow this? https://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/ Thanks, Russ On Mon, Sep 28, 2015 at 9:29 AM, John-Mark Gurney wrote: > Russell Haley wrote this message on Sun, Sep 27, 2015 at 21:21 -0700: > > The option should be included in the man pages for build: > > > > > https://www.freebsd.org/cgi/man.cgi?query=build&sektion=7&apropos=0&manpath=FreeBSD+10.2-RELEASE > > [great additions] > > I agree that this needs better documentation... If you send me a patch, > I'll make sure it's marked up properly and committed... > > Thanks! > > > On Sun, Sep 27, 2015 at 9:06 PM, Warner Losh wrote: > > > > > src.conf is only used to build /usr/src. src.con(5) documents that. > > > build(5) has a pointer. > > > > > > How would you suggest making this clearer? > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > From owner-freebsd-arm@freebsd.org Tue Sep 29 04:08:52 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50624A0A796 for ; Tue, 29 Sep 2015 04:08:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F4441C5D for ; Tue, 29 Sep 2015 04:08:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qgx61 with SMTP id 61so139116979qgx.3 for ; Mon, 28 Sep 2015 21:08:45 -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:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PodDxDeGU28DtjnZ21dtIOqjMaHSJfkSD8+dqbULR9k=; b=BvjQ8aK0pozW6m98K1BTj3EJRW2wz5ehYge0SHVqVk779+YfnWLxZsAaJhNchCsJ1R /Ylm5bVYUpW9/dteqyDtUTiJ7S7tQ6TwglsSA97hHFMJH9s8QUw6IiSzhxLfO7v0q1jW o92M2usJjhCQbU0Zl0Uu9uiXUlQNcm8WimPF3Eew1AP2xtBP2MfdCFJO2vtAVjX7tBBx XsjFbumsTSjD5wbm1Hx98AyO3pNgFZl8oTEevU5Rseubbe3xMtPbmn5/SdGQEkt1y/7p ZJ8CY5RYg3yC4LzL91yoKw3DzGZeqagUM8MX3ggfYq6xmr5Sx1iGDh7A/sdaAu2bjZmF lRTg== X-Gm-Message-State: ALoCoQm6bAgOHtMcEoaOyDm4t9jA30yedfW/ya06XDrXzAzOXwVIEG20REJBEI7Y5XDFFcOGhgNT MIME-Version: 1.0 X-Received: by 10.140.83.202 with SMTP id j68mr27646921qgd.46.1443499725087; Mon, 28 Sep 2015 21:08:45 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.140.80.167 with HTTP; Mon, 28 Sep 2015 21:08:44 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <1443104974.1224.269.camel@freebsd.org> <20150928162916.GU99677@funkthat.com> Date: Mon, 28 Sep 2015 22:08:44 -0600 X-Google-Sender-Auth: m9Og-kQW4R0cvtQBadF7z6y7GeA Message-ID: Subject: Re: Building Less? From: Warner Losh To: Russell Haley Cc: John-Mark Gurney , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 04:08:52 -0000 That's a good place to start. Warner On Mon, Sep 28, 2015 at 9:56 PM, Russell Haley wrote: > Do I follow this? > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/ > > Thanks, > > Russ > > On Mon, Sep 28, 2015 at 9:29 AM, John-Mark Gurney > wrote: > >> Russell Haley wrote this message on Sun, Sep 27, 2015 at 21:21 -0700: >> > The option should be included in the man pages for build: >> > >> > >> https://www.freebsd.org/cgi/man.cgi?query=build&sektion=7&apropos=0&manpath=FreeBSD+10.2-RELEASE >> >> [great additions] >> >> I agree that this needs better documentation... If you send me a patch, >> I'll make sure it's marked up properly and committed... >> >> Thanks! >> >> > On Sun, Sep 27, 2015 at 9:06 PM, Warner Losh wrote: >> > >> > > src.conf is only used to build /usr/src. src.con(5) documents that. >> > > build(5) has a pointer. >> > > >> > > How would you suggest making this clearer? >> >> -- >> John-Mark Gurney Voice: +1 415 225 5579 >> >> "All that I will do, has been done, All that I have, has not." >> > > From owner-freebsd-arm@freebsd.org Tue Sep 29 05:08:40 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EB47A0B196 for ; Tue, 29 Sep 2015 05:08:40 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A0F41A1B for ; Tue, 29 Sep 2015 05:08:40 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by wicge5 with SMTP id ge5so132826725wic.0 for ; Mon, 28 Sep 2015 22:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=uiQA+7i5cKT5uMpNLkcWOQA7w3W7+lakU0Ug9EmqoG4=; b=HasEz7amQIl8gpqWEbC7+Gyl2PIjKG98zwoPxRbJbMgz6bCh4pcjnmeyQcCz6Z2q0y qf/6tWJ0PQTcamnbNATRTUfMzjyhSymXUYHFOh8vNoF1HRbGoFBzdcWkZc8EijPNo7d+ SVkk/xlpIMVqQP2U3g7L6DI20L+TnWED+xpHjsqyDjJ8FWVEcl2SbGdeQnQQqvAqOT+o V67ewwWRlFxonH55h4ZmFuFfWpxe/fFHLxqWVdsWKZXRyKZ8LB9Ymlm6k90gIqxBtBEu zLE7xG5vKpsARlAZemGCLEIJ5VYqpCYk3pB9xnX3VdCn/2rrpsYq1/3sk/yM5+jIf1xD Zfgw== X-Received: by 10.194.209.240 with SMTP id mp16mr25738939wjc.100.1443503318197; Mon, 28 Sep 2015 22:08:38 -0700 (PDT) Received: from [192.168.1.131] (xdsl-205-163.nblnetworks.fi. [83.145.205.163]) by smtp.googlemail.com with ESMTPSA id wn10sm21732794wjc.46.2015.09.28.22.08.37 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Sep 2015 22:08:37 -0700 (PDT) From: Jukka Ukkonen Subject: Root mount on arm X-Enigmail-Draft-Status: N1110 To: freebsd-arm@FreeBSD.org Message-ID: <560A1CD4.9030600@gmail.com> Date: Tue, 29 Sep 2015 08:08:36 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 05:08:40 -0000 Hello all, Is there something different in how various actions are ordered at boot time on ARM and other architectures? In particular is there a difference in when and how the root file system gets mounted? On 10-stable I have been using a patch which allows the stat() calls to report the true media size of a block device, the true block count, and true block size for device entries. The whole thing only requires a few more extra lines in devfs_getattr(). Find the patch here... https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197876 Without the patch the media size and the block count are reported by stat() as zero, and the block size comes out as 4k for all devices no matter what the actual block size is. The original setup has been much like yet another Volkswagen cheating during the inspection. The patch has worked just fine independent of the architecture. During the last few months I have been using this modification on amd64 and ppc only, though. When I decided to test the same modification on arm I used 11-current instead of 10-stable. To my surprise the boot was interrupted with a complaint that the SD card device from which the root file system should have been mounted was locked/held by some other part of the kernel. Apparently this unexpected reaction was triggered by g_topology_assert() which is called from within g_dev_getprovider(). Now I am not quite sure whether this happens only on arm or is it 11-current in general. I will be able to test with 11-current on another architecture only after a week from now or so. Because I cannot do anything else to solve this mystery at the time I decided to try the swarm intelligence. Maybe someone on the list remembers the details of boot time actions on arm well enough to tell whether the interrupted boot could be due to some arm specific differences in how things are ordered during the boot. Cheers, --jau From owner-freebsd-arm@freebsd.org Tue Sep 29 05:29:51 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3FABA0BF6A for ; Tue, 29 Sep 2015 05:29:51 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9CBA1189C; Tue, 29 Sep 2015 05:29:51 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by vkgd64 with SMTP id d64so96866990vkg.0; Mon, 28 Sep 2015 22:29:50 -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=EstEchx2oa27cBI+oUx5+KHQa6p1/kGC8GvlOPLJRAE=; b=sykilKfaFbegcVW7usTj4gp2Rq2D2tX+FZ6cY8ZAi4NgVLLVlLQ5IXGBKSey/5N0s5 RzpQt2kUEQFzW13G5/Uj80T96v6J1AF0/DZ33mNEaf9URGSn3orQX3/wlGXLJEZkQhOI /gUvArlyXwQe9KTqEsZiXqVQeJSiDXak34bs/S5KmwrsbLScmPVnYNTVZBD0hDrWO4mE Usbcg9eXw265NDPP7IeEEoGNwxGhcWNN+fcFllCme+FBgUbqQ9gQaYB41JP/h5WnF9nq s1dAtm6UZtmLTTzZr7EKBajwk7xByM+6o1agqk471cGfa1pcmk8F2b2IbFxGeyW6nBzr 4nbQ== MIME-Version: 1.0 X-Received: by 10.31.151.84 with SMTP id z81mr15730521vkd.14.1443504590243; Mon, 28 Sep 2015 22:29:50 -0700 (PDT) Received: by 10.31.89.135 with HTTP; Mon, 28 Sep 2015 22:29:50 -0700 (PDT) In-Reply-To: References: <1443104974.1224.269.camel@freebsd.org> <20150928162916.GU99677@funkthat.com> Date: Mon, 28 Sep 2015 22:29:50 -0700 Message-ID: Subject: Re: Building Less? From: Russell Haley To: Warner Losh Cc: John-Mark Gurney , freebsd-arm , Ian Lepore Content-Type: multipart/mixed; boundary=001a1140f2e65582920520dc1ad9 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 05:29:52 -0000 --001a1140f2e65582920520dc1ad9 Content-Type: text/plain; charset=UTF-8 Okay, here is the diff for the changes above. I didn't re-build as Mr. Gurney said he would validate and commit . Can I suggest/submit some other changes to the build (7) page (that I will test myself)? Also the fdp-primer says in chapter 3.1 that the doc project owns man pages and then I couldn't find another single reference to them again. Much thanks! Russ On Mon, Sep 28, 2015 at 9:08 PM, Warner Losh wrote: > That's a good place to start. > > Warner > > On Mon, Sep 28, 2015 at 9:56 PM, Russell Haley > wrote: > >> Do I follow this? >> >> https://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/ >> >> Thanks, >> >> Russ >> >> On Mon, Sep 28, 2015 at 9:29 AM, John-Mark Gurney >> wrote: >> >>> Russell Haley wrote this message on Sun, Sep 27, 2015 at 21:21 -0700: >>> > The option should be included in the man pages for build: >>> > >>> > >>> https://www.freebsd.org/cgi/man.cgi?query=build&sektion=7&apropos=0&manpath=FreeBSD+10.2-RELEASE >>> >>> [great additions] >>> >>> I agree that this needs better documentation... If you send me a patch, >>> I'll make sure it's marked up properly and committed... >>> >>> Thanks! >>> >>> > On Sun, Sep 27, 2015 at 9:06 PM, Warner Losh wrote: >>> > >>> > > src.conf is only used to build /usr/src. src.con(5) documents that. >>> > > build(5) has a pointer. >>> > > >>> > > How would you suggest making this clearer? >>> >>> -- >>> John-Mark Gurney Voice: +1 415 225 5579 >>> >>> "All that I will do, has been done, All that I have, has not." >>> >> >> > --001a1140f2e65582920520dc1ad9 Content-Type: text/plain; charset=US-ASCII; name="src.conf-build.diff" Content-Disposition: attachment; filename="src.conf-build.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_if4xaswa0 SW5kZXg6IG1hbjUvc3JjLmNvbmYuNQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBtYW41L3NyYy5jb25mLjUJKHJl dmlzaW9uIDI4ODE2NCkKKysrIG1hbjUvc3JjLmNvbmYuNQkod29ya2luZyBjb3B5KQpAQCAtMTAs NyArMTAsNyBAQAogLlNoIERFU0NSSVBUSU9OCiBUaGUKIC5ObQotZmlsZSBjb250YWlucyBzZXR0 aW5ncyB0aGF0IHdpbGwgYXBwbHkgdG8gZXZlcnkgYnVpbGQgaW52b2x2aW5nIHRoZQorZmlsZSBj b250YWlucyB2YXJpYWJsZXMgdGhhdCBjb250cm9sIHdoYXQgY29tcG9uZW50cyB3aWxsIGJlIGdl bmVyYXRlZCBmb3IgYWxsIGJ1aWxkcyBpbnZvbHZpbmcgdGhlCiAuRngKIHNvdXJjZSB0cmVlOyBz ZWUKIC5YciBidWlsZCA3IC4KSW5kZXg6IG1hbjcvYnVpbGQuNwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBtYW43 L2J1aWxkLjcJKHJldmlzaW9uIDI4ODE2NCkKKysrIG1hbjcvYnVpbGQuNwkod29ya2luZyBjb3B5 KQpAQCAtMTAyLDcgKzEwMiwxMSBAQAogdmFyaWFibGVzIGRlc2NyaWJlZCBpbiB0aGUKIC5TeCBF TlZJUk9OTUVOVAogc2VjdGlvbiBiZWxvdywgYW5kIGJ5IHRoZSB2YXJpYWJsZXMgZG9jdW1lbnRl ZCBpbgotLlhyIG1ha2UuY29uZiA1IC4KKy5YciBtYWtlLmNvbmYgNSAuIAorVGhlIGRlZmF1bHQg Y29tcG9uZW50cyBpbmNsdWRlZCBpbiB0aGUgYnVpbGQgYXJlIHNwZWNpZmllZCBpbiB0aGUgZmls ZSAKKy9ldGMvc3JjLmNvbmYgaW4gdGhlIHNvdXJjZSB0cmVlLiBUbyBvdmVycmlkZSB0aGUgZGVm YXVsdCBmaWxlLCBpbmNsdWRlIAordGhlIFNSQ0NPTkYgb3B0aW9uIGluIHRoZSBtYWtlIHN0ZXBz LCBwb2ludGluZyB0byBhIGN1c3RvbSBzcmMuY29uZiAKK2ZpbGUuIEZvciBtb3JlIGluZm9ybWF0 aW9uIHNlZSBzcmMuY29uZi4KIC5QcAogVGhlIGZvbGxvd2luZyBsaXN0IHByb3ZpZGVzIHRoZSBu YW1lcyBhbmQgYWN0aW9ucyBmb3IgdGhlIHRhcmdldHMKIHN1cHBvcnRlZCBieSB0aGUgYnVpbGQg c3lzdGVtOgpAQCAtNDQ1LDYgKzQ0OSw5IEBACiAuQmQgLWxpdGVyYWwgLW9mZnNldCBpbmRlbnQK IG1ha2UgUE9SVFNfTU9EVUxFUz1lbXVsYXRvcnMva3FlbXUta21vZCBrZXJuZWwKIC5FZAorLkl0 IFZhIFNSQ0NPTkYKK1NwZWNpZnkgYSBmaWxlIHRvIG92ZXJyaWRlIHRoZSBkZWZhdWx0IC9ldGMv c3JjLmNvbmYuIFRoZSBzcmMuY29uZiBmaWxlIGNvbnRyb2xzIHRoZSBjb21wb25lbnRzIHRvIGJ1 aWxkLiBTZWUgCisuWHIgU1JDLkNPTkYgNQogLkl0IFZhIFNUUklQQklOCiBDb21tYW5kIHRvIHVz ZSBhdCBpbnN0YWxsIHRpbWUgd2hlbiBzdHJpcHBpbmcgYmluYXJpZXMuCiBCZSBzdXJlIHRvIGFk ZCBhbnkgYWRkaXRpb25hbCB0b29scyByZXF1aXJlZCB0byBydW4K --001a1140f2e65582920520dc1ad9-- From owner-freebsd-arm@freebsd.org Tue Sep 29 05:47:24 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28527A0AC44 for ; Tue, 29 Sep 2015 05:47:24 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E94531069 for ; Tue, 29 Sep 2015 05:47:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by pacfv12 with SMTP id fv12so200259979pac.2 for ; Mon, 28 Sep 2015 22:47:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=rwfv9Nw22HLG01Hdt6xI5cm/aep3Vwavpoaymw5gOFs=; b=RpCc+VjpnVK13V94nWzJLIauEJgvZyb3RHFzSI7L3gAx3dmXQsKU4j1IctzWg9QuNY uKYTGMpjIBc1iQfswisQvXmGwCa9x1vuktZJAy/Ip+bYk9xNGbt3HmVmJXbqdVvsm7pn QUAaHD9E6jtdJAgd4x1HTBcgWP+2Suz1SiwOf0vZZFPtP3nycfPIlB1/9wSfPFowCdmd IlBhXoQwpb5vUCVCJXdvF0VU9yoU5HKrhQmqbbuK2JTcvHYYtWJKkISsqoEYdArwxlXt l1w2Ng+fkdoOLgwaz8c9mamuq1eBmJJX6UwkhHk6V2qdl4lcV6D3EkQSQS6sYwZvkC+y 14QQ== X-Gm-Message-State: ALoCoQkeVf6K9IKhLxmbHH+cpc51bJVODFNTFSCGxAk259xp8gB4+X2jaZRNd16vk98oFsVxSAui X-Received: by 10.66.138.47 with SMTP id qn15mr30919387pab.12.1443505637059; Mon, 28 Sep 2015 22:47:17 -0700 (PDT) Received: from ip-100-127-145-114.ec2.internal ([69.53.245.31]) by smtp.gmail.com with ESMTPSA id si1sm22889698pbc.72.2015.09.28.22.47.15 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Sep 2015 22:47:16 -0700 (PDT) Sender: Warner Losh Subject: Re: Building Less? Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_13BCDBAD-02F7-497C-93F2-F48E9631BF2C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Warner Losh In-Reply-To: Date: Mon, 28 Sep 2015 23:46:09 -0600 Cc: John-Mark Gurney , freebsd-arm , Ian Lepore Message-Id: References: <1443104974.1224.269.camel@freebsd.org> <20150928162916.GU99677@funkthat.com> To: Russell Haley X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 05:47:24 -0000 --Apple-Mail=_13BCDBAD-02F7-497C-93F2-F48E9631BF2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This isn=E2=80=99t quite right. /etc/src.conf is used only for /usr/src = builds. It is ignored for /usr/doc and /usr/ports builds, which build(7) = also documents. I=E2=80=99d be more specific. Also, this is just a nit, the man page is src.conf 5, not SRC.CONF 5. If = you=E2=80=99re cleaning up the other language, you may want to correct = that. Warner > On Sep 28, 2015, at 11:29 PM, Russell Haley = wrote: >=20 > Okay, here is the diff for the changes above. I didn't re-build as Mr. = Gurney said he would validate and commit . Can I suggest/submit some = other changes to the build (7) page (that I will test myself)? Also the = fdp-primer says in chapter 3.1 that the doc project owns man pages and = then I couldn't find another single reference to them again. >=20 > Much thanks! > Russ >=20 > On Mon, Sep 28, 2015 at 9:08 PM, Warner Losh wrote: > That's a good place to start. >=20 > Warner >=20 > On Mon, Sep 28, 2015 at 9:56 PM, Russell Haley = wrote: > Do I follow this? >=20 > https://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/ >=20 > Thanks, >=20 > Russ >=20 > On Mon, Sep 28, 2015 at 9:29 AM, John-Mark Gurney = wrote: > Russell Haley wrote this message on Sun, Sep 27, 2015 at 21:21 -0700: > > The option should be included in the man pages for build: > > > > = https://www.freebsd.org/cgi/man.cgi?query=3Dbuild&sektion=3D7&apropos=3D0&= manpath=3DFreeBSD+10.2-RELEASE >=20 > [great additions] >=20 > I agree that this needs better documentation... If you send me a = patch, > I'll make sure it's marked up properly and committed... >=20 > Thanks! >=20 > > On Sun, Sep 27, 2015 at 9:06 PM, Warner Losh wrote: > > > > > src.conf is only used to build /usr/src. src.con(5) documents = that. > > > build(5) has a pointer. > > > > > > How would you suggest making this clearer? >=20 > -- > John-Mark Gurney Voice: +1 415 225 5579 >=20 > "All that I will do, has been done, All that I have, has not." >=20 >=20 >=20 > --Apple-Mail=_13BCDBAD-02F7-497C-93F2-F48E9631BF2C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWCiWhAAoJEGwc0Sh9sBEASLIP/27nFrIFf4KSzaSzn749tKik ALAu7AlI+E7BubEgLzT3RJW8pTLtQxkodas/f2SbaXKfb5Zvbrl7x0ZXhLPW7ZCO zZWLMGgPUm454vwG+3juXtfceTq8ms4kRMoxrPCC3r58GhKf4aADOXp57MMGJGre PPsHSHWErCP1LGIBCBbsoqftNLGOfndwUQUZzlF04K7ppzLAlUmRYP2y2WK91sJX fNUP17AJXeU6rR5LBgqMoIMTeK7rG+dnlZjV7Qye0KPuOw5gK6+hC+DML6gT0hVU l8M1+asexONuTxWX67WM45I4cdYgCtWpV9OG7y9zhgg/kMe4Hr0/j+9WenJ5O+IR NEs6rxS5KauzbAR+O//nRJeZyYg2ZFoBXX1c4AuYyVWk5NaPFgwh0olt1eRVFqZo 4kA2EmZkY/TvQp3pA398a9IgqolltgBiAEMX6AQoDOYxglR06zHHhGUwncxYjT2n cNXFPpwFQkHeoSB2Ym9sPLmhUqDWYZTPsK9ael3ddKevDO5qHNQrXlBEJWA7wkgo uDu2nO/2aYyWTUN0ECZsJXL25XJqFXZJJun92dApF4QlS3lnp7agABlSguDxnMXy p/Dsle4P0uWsbyvCB2BhhqAVACJUSMo7/kfZ2LM7Pd3+xUnCoRbIhL7uL2yaRVgk h5Bdn3sJZ3KlKwS1Kbor =cg1G -----END PGP SIGNATURE----- --Apple-Mail=_13BCDBAD-02F7-497C-93F2-F48E9631BF2C-- From owner-freebsd-arm@freebsd.org Tue Sep 29 05:55:53 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BDCA4A0B4C7 for ; Tue, 29 Sep 2015 05:55:53 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 715E2163F; Tue, 29 Sep 2015 05:55:53 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by vkao3 with SMTP id o3so96803770vka.2; Mon, 28 Sep 2015 22:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VPK8IHiHNZ7EwQBeZj3ehie2ySbac3BvWMHfek9a0VY=; b=N+K8UgzVWFEXMsXYJdLUZTQ8dc+FdYFit+UAS2qjPvXt7TXCEvrBb7ENp5eNmoULVS 2GNWcIx86KrLKv4zPVggEw4M2iEKr6PNPqUKkIlx+Edbd+uxTNTimPigLqhXYXjFqPd+ yIUu0cjGFafcf13cmQOUwS8OcPNJuwiinGh59M4uC6R+GFvbWC1+nZCbABuCIjHkPinK kCsrfOFLxFqvc9/OaPzHloPdEbdSRbOsMfLBKU9R3gDMV1mh8kDkgV0TAPLZ7PH3vczT OnJDumjac8qYI+R72ZuYQh5Ye2LoWE90HiHnno4v+gaG5hHI16q1dwxvaTxqI2HqeS8s SZgg== MIME-Version: 1.0 X-Received: by 10.31.154.131 with SMTP id c125mr15618404vke.96.1443506152403; Mon, 28 Sep 2015 22:55:52 -0700 (PDT) Received: by 10.31.89.135 with HTTP; Mon, 28 Sep 2015 22:55:52 -0700 (PDT) In-Reply-To: References: <1443104974.1224.269.camel@freebsd.org> <20150928162916.GU99677@funkthat.com> Date: Mon, 28 Sep 2015 22:55:52 -0700 Message-ID: Subject: Re: Building Less? From: Russell Haley To: Warner Losh Cc: John-Mark Gurney , freebsd-arm , Ian Lepore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 05:55:53 -0000 On it. Russ On Mon, Sep 28, 2015 at 10:46 PM, Warner Losh wrote: > This isn=E2=80=99t quite right. /etc/src.conf is used only for /usr/src b= uilds. It > is ignored for /usr/doc and /usr/ports builds, which build(7) also > documents. I=E2=80=99d be more specific. > > Also, this is just a nit, the man page is src.conf 5, not SRC.CONF 5. If > you=E2=80=99re cleaning up the other language, you may want to correct th= at. > > Warner > > > On Sep 28, 2015, at 11:29 PM, Russell Haley > wrote: > > > > Okay, here is the diff for the changes above. I didn't re-build as Mr. > Gurney said he would validate and commit . Can I suggest/submit some othe= r > changes to the build (7) page (that I will test myself)? Also the > fdp-primer says in chapter 3.1 that the doc project owns man pages and th= en > I couldn't find another single reference to them again. > > > > Much thanks! > > Russ > > > > On Mon, Sep 28, 2015 at 9:08 PM, Warner Losh wrote: > > That's a good place to start. > > > > Warner > > > > On Mon, Sep 28, 2015 at 9:56 PM, Russell Haley > wrote: > > Do I follow this? > > > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/ > > > > Thanks, > > > > Russ > > > > On Mon, Sep 28, 2015 at 9:29 AM, John-Mark Gurney > wrote: > > Russell Haley wrote this message on Sun, Sep 27, 2015 at 21:21 -0700: > > > The option should be included in the man pages for build: > > > > > > > https://www.freebsd.org/cgi/man.cgi?query=3Dbuild&sektion=3D7&apropos=3D0= &manpath=3DFreeBSD+10.2-RELEASE > > > > [great additions] > > > > I agree that this needs better documentation... If you send me a patch= , > > I'll make sure it's marked up properly and committed... > > > > Thanks! > > > > > On Sun, Sep 27, 2015 at 9:06 PM, Warner Losh wrote: > > > > > > > src.conf is only used to build /usr/src. src.con(5) documents that. > > > > build(5) has a pointer. > > > > > > > > How would you suggest making this clearer? > > > > -- > > John-Mark Gurney Voice: +1 415 225 5579 > > > > "All that I will do, has been done, All that I have, has not." > > > > > > > > > > From owner-freebsd-arm@freebsd.org Tue Sep 29 08:42:21 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80628A0BF9C for ; Tue, 29 Sep 2015 08:42:21 +0000 (UTC) (envelope-from uffe@uffe.org) Received: from mx0.starion.dk (mx0.starion.dk [93.162.70.34]) by mx1.freebsd.org (Postfix) with ESMTP id 3B09215AD for ; Tue, 29 Sep 2015 08:42:20 +0000 (UTC) (envelope-from uffe@uffe.org) X-tst: NONE (10.1.1.21) X-tst: NONE (10.1.1.21) Received: from mailstore.starion.info (unknown [10.1.1.21]) by mx0.starion.dk (Postfix) with SMTP id AF9142BD82B; Tue, 29 Sep 2015 10:36:44 +0200 (CEST) Received: (nullmailer pid 64074 invoked by uid 1004); Tue, 29 Sep 2015 08:36:44 -0000 Subject: Re: BeagleBone Green To: "freebsd-arm@freebsd.org" References: <56099322.1080804@ceetonetechnology.com> <967B69D5-19FA-40FE-BBFD-DFB231EEBC8D@netgate.com> <1443493039.1907.1.camel@me.com> Cc: Rui Paulo From: Uffe Jakobsen Message-ID: <560A4D8D.1020500@uffe.org> Date: Tue, 29 Sep 2015 10:36:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1443493039.1907.1.camel@me.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 08:42:21 -0000 On 2015-09-29 04:17, Rui Paulo wrote: > On Mon, 2015-09-28 at 16:37 -0500, Jim Thompson wrote: >> >>> On Sep 28, 2015, at 2:21 PM, George Rosamond < >>> george@ceetonetechnology.com> wrote: >>> >>> At MakerFaire NYC this weekend, I found out that the BeagleBone >>> Green >>> was released. Cheaper than the Black, the only difference I saw >>> was >>> 'grooves' for four-pin connections to an array of sensors they are >>> offering, eg, environmental, GPS, etc >>> >>> It wasn't available at the event, but it looks like the specs (and >>> I >>> think the chipset) are the same, if not identical. >>> >>> Anyone have one and build successfully? >>> >>> g >> >> >> Differences between the Beaglebone Green and Beaglebone Black: >> >> 2x Grove connectors on Beaglebone Green (as you outlined) >> >> Beaglebone Green eliminates microSD, HDMI and 5VDC barrel, and this >> is what drives the $16 (list) price reduction. >> >> Power on Beaglebone Green is only via micro USB (Beaglebone Black >> uses mini USB or separate 5VDC barrel) >> >> Otherwise, specs and chipset are, (as you surmised) identical. > > It just makes it much more complicated to boot FreeBSD with the lack of > microSD. Probably not that attractive to FreeBSD users. > As far as I can see the BeagleBone Green still has microSD on its backside. Only MicroHDMI have been removed. http://beagleboard.org/green Quote: (http://www.seeedstudio.com/wiki/Beaglebone_green) BeagleBone Green (BBG) is based on the classical open-source hardware design of BeagleBone Black (BBB) and added two Grove connectors. It has removed the HDMI port on the BBB and also updated the 5V barrel to Micro USB host. It is a low-cost, community-supported development platform for developers and hobbyists. /Uffe From owner-freebsd-arm@freebsd.org Tue Sep 29 09:24:18 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 159E2A0A284 for ; Tue, 29 Sep 2015 09:24:18 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 B9B151AC5; Tue, 29 Sep 2015 09:24:17 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from chamsa.cs.huji.ac.il ([132.65.80.19]) by kabab.cs.huji.ac.il with esmtp id 1Zgr8n-000NON-7T; Tue, 29 Sep 2015 12:24:05 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: netboot configuration [was: Re: NFS Root with Raspberry Pi (nfs_diskless: no interface)] From: Daniel Braniss In-Reply-To: <1443371712.1224.398.camel@freebsd.org> Date: Tue, 29 Sep 2015 12:24:04 +0300 Cc: freebsd-arm@freebsd.org, Rick Macklem Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150922052522.GA62140@gmail.com> <00C49FEB-E8EF-4469-85E2-0F901215CD11@cs.huji.ac.il> <20150923050414.GB43653@gmail.com> <91AAC64E-4C38-47AA-8910-48F7654A7524@cs.huji.ac.il> <20150923174445.GE43653@gmail.com> <1443105426.1224.272.camel@freebsd.org> <20150924163658.GC32257@gmail.com> <560438C5.3090404@selasky.org> <1443142468.1224.322.camel@freebsd.org> <1443209159.1224.361.camel@freebsd.org> <12C96F79-2D70-408D-AD4C-F06F6B909AD3@cs.huji.ac.il> <1443276119.1224.382.camel@freebsd.org> <33EFE756-B428-4A72-B3C5-0E764FA8ACC6@cs.huji.ac.il> <1443370490.1224.392.camel@freebsd.org> <1443371712.1224.398.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 09:24:18 -0000 > On 27 Sep 2015, at 19:35, Ian Lepore wrote: >=20 > On Sun, 2015-09-27 at 19:25 +0300, Daniel Braniss wrote: >>> On Sep 27, 2015, at 7:14 PM, Ian Lepore wrote: >>>=20 >>> On Sun, 2015-09-27 at 14:15 +0300, Daniel Braniss wrote: > [...] >>>> I compiled the u-boot-rpi from ports, >>>> the good news: >>>> it understands UserPreboot >>>> the bad news: >>>> the nfs boot gets stuck after a while. >>>>=20 >>>> after much trial and error, this is what I do: >>>> hit a key to enter U-Boot >>>> then type: >>>> setenv loaderdev net >>>> boot >>>>=20 >>>> attaching the console: >>>=20 >>> I was also experiencing intermittant lockups while loader loads the >>> kernel. I just wrote it off to failing hardware (I powered my rpi = on >>> for the first time in 6-8 months to work on this), since I've never = had >>> a problem with netbooting before (it's the only way I've ever booted = the >>> rpi). If it's not just my board going bad, then that's a bit of a >>> mystery. The only other difference here from what I've always done = is >>> setting rootpath and other net config in u-boot instead of letting = ubldr >>> get it from dhcp. >>=20 >> with the stuff from crochet it works, same setup! I am sniffing the = net via >> wireshark, and it stops at different positions in the kernel file, >> so the settings of rootpath and other configs are irrelevant. >> the transfer is being done via udp/nfs/v3 (hence added ric :-) maybe >> he can see something we don=E2=80=99t. >=20 > Hmmm. What stuff from crochet? The two components that are in play > here are u-boot itself (it contains the low-level network drivers that > ubldr uses -- it's effectively acting as a bios for ubldr), and ubldr > which contains the higher-level network code. >=20 > In theory ubldr should be the same in both cases; nothing much has > changed in the loader code for months. But there are different paths > through the code depending on how it gets the network parms, and I = could > easily have glitched something when I added the feature that lets you > set the config with u-boot env vars. >=20 > The u-boot might be different between a crochet and ports build. They > both start with gonzo's u-boot 2013.10 sources, but crochet probably = has > a slightly different set of patches it applies. >=20 > -- Ian >=20 with the old uboot it boots ok, with the newer/modified it stops at = random places reading via udp/nfs/v3 the kernel. it loads correctly all the = *.4th files, then starts reading the kernel, and hangs after a random time. on another issue, if I type dhcp instead of boot, it loads via TFTP = filename, which I set to ubldr/ubldr.bin, it loads and now prompts again, what should the command be? I tried go 0, go 20000, in which case execs the old ubldr :-( anyways, the fact that I can now boot over the net is great! danny From owner-freebsd-arm@freebsd.org Tue Sep 29 13:23:42 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A088A0A3AF for ; Tue, 29 Sep 2015 13:23:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 600D113D9 for ; Tue, 29 Sep 2015 13:23:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t8TDNXjV074934 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 29 Sep 2015 16:23:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t8TDNXjV074934 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t8TDNXJL074933 for freebsd-arm@freebsd.org; Tue, 29 Sep 2015 16:23:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 29 Sep 2015 16:23:33 +0300 From: Konstantin Belousov To: freebsd-arm@freebsd.org Subject: Shared page and related goodies for ARMv7 Message-ID: <20150929132332.GH11284@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 13:23:42 -0000 As an exercise to get myself more familiar with the ARM architecture, I added the shared page for FreeBSD/ARMv7. This provides the standard features tied to the shared page, in particular, a non-executable stack for the compatible binaries, and fast gettimeofday() and clock_gettime() functions. For reference, the measurements on my RPI2 done by tools/tools/syscall_timing, show for userspace gettimeofday: % ./syscall_timing gettimeofday Clock resolution: 0.000000053 test loop time iterations periteration gettimeofday 0 1.009965385 2743838 0.000000368 gettimeofday 1 1.009899240 2743629 0.000000368 gettimeofday 2 1.009952833 2538253 0.000000397 gettimeofday 3 1.009918198 2404272 0.000000420 gettimeofday 4 1.009875126 2404567 0.000000419 gettimeofday 5 1.009950700 2405196 0.000000419 gettimeofday 6 1.009859555 2623534 0.000000384 gettimeofday 7 1.009911534 2743249 0.000000368 gettimeofday 8 1.009928618 2743240 0.000000368 gettimeofday 9 1.009920910 2743227 0.000000368 for syscall: gettimeofday 0 1.009994949 659319 0.000001531 gettimeofday 1 1.009869846 583343 0.000001731 gettimeofday 2 1.009899950 583384 0.000001731 gettimeofday 3 1.009873232 636420 0.000001586 gettimeofday 4 1.009909639 669715 0.000001507 gettimeofday 5 1.009941201 669640 0.000001508 gettimeofday 6 1.009930733 669051 0.000001509 gettimeofday 7 1.009890005 669064 0.000001509 gettimeofday 8 1.009915474 669168 0.000001509 gettimeofday 9 1.009918860 668739 0.000001510 The patch is pretty much straightforward, interesting details are listed below. - The shared page is only enabled for ARMv7 kernels. From my reading of VMSA chapters for ARMv6 and ARMv7, only v7 ensures that there is no cache aliasing for multiple-times mapped page, while v6 requires coloring. Shared page is mapped both at the top of UVA and somewhere in KVA. - There is a bug in the generic timer setup, it seems. The CNTKCTL CP15 register is core-private, which means that the in-tree code only sets access permissions on the BSP. APs CNTKCTL are left in undefined state, possibly set up to some value by loader. This might allow userspace to reprogram timers on APs. I fixed this by using rendezvous after SMP is started. - I have to add explicit directives to create .note.GNU-stack sections in some __eabi files from libcompiler-rt which are linked into libc. Upstream refused to do global change adding the stack note for all asms, recommending to live with --noexecstack assembler option. But we cannot do this for files linked into libc. - arm64 would require some additions, I did not tested the build. It would be useful to test the patch on ARMv6 to ensure that signals and gettimeofday() work. diff --git a/contrib/compiler-rt/lib/builtins/arm/aeabi_memcmp.S b/contrib/compiler-rt/lib/builtins/arm/aeabi_memcmp.S index 051ce43..fa69327 100644 --- a/contrib/compiler-rt/lib/builtins/arm/aeabi_memcmp.S +++ b/contrib/compiler-rt/lib/builtins/arm/aeabi_memcmp.S @@ -18,3 +18,5 @@ END_COMPILERRT_FUNCTION(__aeabi_memcmp) DEFINE_AEABI_FUNCTION_ALIAS(__aeabi_memcmp4, __aeabi_memcmp) DEFINE_AEABI_FUNCTION_ALIAS(__aeabi_memcmp8, __aeabi_memcmp) + + .section .note.GNU-stack,"",%progbits diff --git a/contrib/compiler-rt/lib/builtins/arm/aeabi_memcpy.S b/contrib/compiler-rt/lib/builtins/arm/aeabi_memcpy.S index cf02332..35b8558 100644 --- a/contrib/compiler-rt/lib/builtins/arm/aeabi_memcpy.S +++ b/contrib/compiler-rt/lib/builtins/arm/aeabi_memcpy.S @@ -18,3 +18,5 @@ END_COMPILERRT_FUNCTION(__aeabi_memcpy) DEFINE_AEABI_FUNCTION_ALIAS(__aeabi_memcpy4, __aeabi_memcpy) DEFINE_AEABI_FUNCTION_ALIAS(__aeabi_memcpy8, __aeabi_memcpy) + + .section .note.GNU-stack,"",%progbits diff --git a/contrib/compiler-rt/lib/builtins/arm/aeabi_memmove.S b/contrib/compiler-rt/lib/builtins/arm/aeabi_memmove.S index 4dda06f..2f9f789 100644 --- a/contrib/compiler-rt/lib/builtins/arm/aeabi_memmove.S +++ b/contrib/compiler-rt/lib/builtins/arm/aeabi_memmove.S @@ -18,3 +18,5 @@ END_COMPILERRT_FUNCTION(__aeabi_memmove) DEFINE_AEABI_FUNCTION_ALIAS(__aeabi_memmove4, __aeabi_memmove) DEFINE_AEABI_FUNCTION_ALIAS(__aeabi_memmove8, __aeabi_memmove) + + .section .note.GNU-stack,"",%progbits diff --git a/contrib/compiler-rt/lib/builtins/arm/aeabi_memset.S b/contrib/compiler-rt/lib/builtins/arm/aeabi_memset.S index c8b49c7..f2342f0 100644 --- a/contrib/compiler-rt/lib/builtins/arm/aeabi_memset.S +++ b/contrib/compiler-rt/lib/builtins/arm/aeabi_memset.S @@ -32,3 +32,4 @@ END_COMPILERRT_FUNCTION(__aeabi_memclr) DEFINE_AEABI_FUNCTION_ALIAS(__aeabi_memclr4, __aeabi_memclr) DEFINE_AEABI_FUNCTION_ALIAS(__aeabi_memclr8, __aeabi_memclr) + .section .note.GNU-stack,"",%progbits diff --git a/contrib/gcc/config/arm/crti.asm b/contrib/gcc/config/arm/crti.asm index 166a3ce..8df00d2 100644 --- a/contrib/gcc/config/arm/crti.asm +++ b/contrib/gcc/config/arm/crti.asm @@ -60,6 +60,8 @@ .file "crti.asm" + .section .note.GNU-stack,"",%progbits + .section ".init" .align 2 .global _init diff --git a/contrib/gcc/config/arm/crtn.asm b/contrib/gcc/config/arm/crtn.asm index 360afae..1947919 100644 --- a/contrib/gcc/config/arm/crtn.asm +++ b/contrib/gcc/config/arm/crtn.asm @@ -68,6 +68,8 @@ .file "crtn.asm" + .section .note.GNU-stack,"",%progbits + .section ".init" ;; FUNC_END diff --git a/contrib/gcc/config/arm/lib1funcs.asm b/contrib/gcc/config/arm/lib1funcs.asm index 73c453d..8a48b25 100644 --- a/contrib/gcc/config/arm/lib1funcs.asm +++ b/contrib/gcc/config/arm/lib1funcs.asm @@ -1305,3 +1305,5 @@ LSYM(Lchange_\register): #include "ieee754-sf.S" #include "bpabi.S" #endif /* __symbian__ */ + + .section .note.GNU-stack,"",%progbits diff --git a/lib/csu/arm/crti.S b/lib/csu/arm/crti.S index 40e83bb..c6c37eb 100644 --- a/lib/csu/arm/crti.S +++ b/lib/csu/arm/crti.S @@ -19,3 +19,4 @@ _fini: stmdb sp!, {fp, ip, lr, pc} sub fp, ip, #4 + .section .note.GNU-stack,"",%progbits diff --git a/lib/csu/arm/crtn.S b/lib/csu/arm/crtn.S index 962f0ed..25bbd57 100644 --- a/lib/csu/arm/crtn.S +++ b/lib/csu/arm/crtn.S @@ -8,3 +8,5 @@ __FBSDID("$FreeBSD$"); .section .fini,"ax",%progbits ldmea fp, {fp, sp, pc} mov pc, lr + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/aeabi/aeabi_asm_double.S b/lib/libc/arm/aeabi/aeabi_asm_double.S index 7a5af82..ced4d78 100644 --- a/lib/libc/arm/aeabi/aeabi_asm_double.S +++ b/lib/libc/arm/aeabi/aeabi_asm_double.S @@ -117,3 +117,5 @@ ENTRY(__aeabi_cdcmpeq) msr cpsr_c, ip RET END(__aeabi_cdcmpeq) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/aeabi/aeabi_asm_float.S b/lib/libc/arm/aeabi/aeabi_asm_float.S index e05daa5..de6b1c8 100644 --- a/lib/libc/arm/aeabi/aeabi_asm_float.S +++ b/lib/libc/arm/aeabi/aeabi_asm_float.S @@ -108,3 +108,5 @@ ENTRY(__aeabi_cfcmpeq) msr cpsr_c, ip RET END(__aeabi_cfcmpeq) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/aeabi/aeabi_vfp_double.S b/lib/libc/arm/aeabi/aeabi_vfp_double.S index aae49f8..be4309d 100644 --- a/lib/libc/arm/aeabi/aeabi_vfp_double.S +++ b/lib/libc/arm/aeabi/aeabi_vfp_double.S @@ -201,3 +201,4 @@ AEABI_ENTRY(dsub) RET AEABI_END(dsub) + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/aeabi/aeabi_vfp_float.S b/lib/libc/arm/aeabi/aeabi_vfp_float.S index 7de8daf..c9df41c 100644 --- a/lib/libc/arm/aeabi/aeabi_vfp_float.S +++ b/lib/libc/arm/aeabi/aeabi_vfp_float.S @@ -188,3 +188,4 @@ AEABI_ENTRY(fsub) RET AEABI_END(fsub) + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/gen/__aeabi_read_tp.S b/lib/libc/arm/gen/__aeabi_read_tp.S index 670d0b8..224d6a6 100644 --- a/lib/libc/arm/gen/__aeabi_read_tp.S +++ b/lib/libc/arm/gen/__aeabi_read_tp.S @@ -45,3 +45,4 @@ END(__aeabi_read_tp) .word ARM_TP_ADDRESS #endif + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/gen/_ctx_start.S b/lib/libc/arm/gen/_ctx_start.S index 41bfff9..faedfb5 100644 --- a/lib/libc/arm/gen/_ctx_start.S +++ b/lib/libc/arm/gen/_ctx_start.S @@ -8,3 +8,5 @@ ENTRY(_ctx_start) bl _C_LABEL(ctx_done) bl _C_LABEL(abort) END(_ctx_start) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/gen/_setjmp.S b/lib/libc/arm/gen/_setjmp.S index 853f61c..e3c67fa 100644 --- a/lib/libc/arm/gen/_setjmp.S +++ b/lib/libc/arm/gen/_setjmp.S @@ -157,3 +157,5 @@ botch: b . #endif END(_longjmp) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/gen/alloca.S b/lib/libc/arm/gen/alloca.S index e4a73d4..2539b7a 100644 --- a/lib/libc/arm/gen/alloca.S +++ b/lib/libc/arm/gen/alloca.S @@ -44,3 +44,5 @@ ENTRY(alloca) mov r0, sp /* r0 = base of new space */ RET END(alloca) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/gen/divsi3.S b/lib/libc/arm/gen/divsi3.S index 82de5de..fac0663 100644 --- a/lib/libc/arm/gen/divsi3.S +++ b/lib/libc/arm/gen/divsi3.S @@ -389,3 +389,5 @@ ENTRY(__divsi3) mov r0, r3 RET END(__divsi3) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/gen/setjmp.S b/lib/libc/arm/gen/setjmp.S index c9ae329..4e3850d 100644 --- a/lib/libc/arm/gen/setjmp.S +++ b/lib/libc/arm/gen/setjmp.S @@ -158,3 +158,5 @@ ENTRY(__longjmp) bl PIC_SYM(_C_LABEL(abort), PLT) 1: b 1b /* Cannot get here */ END(__longjmp) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/gen/sigsetjmp.S b/lib/libc/arm/gen/sigsetjmp.S index 3743e89..236f531 100644 --- a/lib/libc/arm/gen/sigsetjmp.S +++ b/lib/libc/arm/gen/sigsetjmp.S @@ -66,3 +66,5 @@ ENTRY(siglongjmp) beq PIC_SYM(_C_LABEL(_longjmp), PLT) b PIC_SYM(_C_LABEL(longjmp), PLT) END(siglongjmp) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/string/ffs.S b/lib/libc/arm/string/ffs.S index cc7f396..0ed8152 100644 --- a/lib/libc/arm/string/ffs.S +++ b/lib/libc/arm/string/ffs.S @@ -84,3 +84,5 @@ ENTRY(ffs) RET #endif END(ffs) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/string/memcmp.S b/lib/libc/arm/string/memcmp.S index 6fd8130..33a11b7 100644 --- a/lib/libc/arm/string/memcmp.S +++ b/lib/libc/arm/string/memcmp.S @@ -181,3 +181,5 @@ ENTRY(memcmp) RET #endif END(memcmp) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/string/memcpy_arm.S b/lib/libc/arm/string/memcpy_arm.S index 56fb703..57b0449 100644 --- a/lib/libc/arm/string/memcpy_arm.S +++ b/lib/libc/arm/string/memcpy_arm.S @@ -334,3 +334,5 @@ ENTRY(memcpy) sub r1, r1, #1 b .Lmemcpy_l4 END(memcpy) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/string/memcpy_xscale.S b/lib/libc/arm/string/memcpy_xscale.S index a451de4..ab01544 100644 --- a/lib/libc/arm/string/memcpy_xscale.S +++ b/lib/libc/arm/string/memcpy_xscale.S @@ -1784,3 +1784,5 @@ ENTRY(memcpy) bx lr #endif /* !_STANDALONE */ END(memcpy) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/string/memmove.S b/lib/libc/arm/string/memmove.S index 2cd5a5e..8f96147 100644 --- a/lib/libc/arm/string/memmove.S +++ b/lib/libc/arm/string/memmove.S @@ -609,3 +609,5 @@ END(memmove) #else END(bcopy) #endif + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/string/memset.S b/lib/libc/arm/string/memset.S index 6d76901..96d2f93 100644 --- a/lib/libc/arm/string/memset.S +++ b/lib/libc/arm/string/memset.S @@ -263,3 +263,5 @@ END(bzero) #else END(memset) #endif + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/string/strcmp.S b/lib/libc/arm/string/strcmp.S index d610fea..1cdce8b 100644 --- a/lib/libc/arm/string/strcmp.S +++ b/lib/libc/arm/string/strcmp.S @@ -43,3 +43,5 @@ ENTRY(strcmp) sub r0, r2, r3 RET END(strcmp) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/string/strlen.S b/lib/libc/arm/string/strlen.S index c9334f9..240fa7d 100644 --- a/lib/libc/arm/string/strlen.S +++ b/lib/libc/arm/string/strlen.S @@ -83,3 +83,5 @@ ENTRY(strlen) mov r0, r1 RET END(strlen) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/string/strncmp.S b/lib/libc/arm/string/strncmp.S index a5c0320..affcaa0 100644 --- a/lib/libc/arm/string/strncmp.S +++ b/lib/libc/arm/string/strncmp.S @@ -56,3 +56,5 @@ ENTRY(strncmp) sub r0, r2, r3 RET END(strncmp) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/sys/Makefile.inc b/lib/libc/arm/sys/Makefile.inc index 60c2dc3..5e89109 100644 --- a/lib/libc/arm/sys/Makefile.inc +++ b/lib/libc/arm/sys/Makefile.inc @@ -1,6 +1,6 @@ # $FreeBSD$ -SRCS+= trivial-vdso_tc.c +SRCS+= __vdso_gettc.c MDASM= Ovfork.S brk.S cerror.S pipe.S ptrace.S sbrk.S shmat.S sigreturn.S syscall.S diff --git a/lib/libc/arm/sys/Ovfork.S b/lib/libc/arm/sys/Ovfork.S index 4520e02..73c619e 100644 --- a/lib/libc/arm/sys/Ovfork.S +++ b/lib/libc/arm/sys/Ovfork.S @@ -53,3 +53,5 @@ ENTRY(vfork) and r0, r0, r1 /* r0 == 0 if child, else unchanged */ mov r15, r2 END(vfork) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/sys/__vdso_gettc.c b/lib/libc/arm/sys/__vdso_gettc.c new file mode 100644 index 0000000..613e8fa --- /dev/null +++ b/lib/libc/arm/sys/__vdso_gettc.c @@ -0,0 +1,80 @@ +/*- + * Copyright (c) 2015 The FreeBSD Foundation + * + * Portions of this software were developed by Konstantin Belousov + * under sponsorship from the FreeBSD Foundation. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include "libc_private.h" + +/* + * Userspace gettimeofday() is only enabled on ARMv7 CPUs, but libc is + * compiled for ARMv6. Due to clang issues, .arch armv7-a directive + * does not work. + */ + +static inline uint64_t +cp15_cntvct_get(void) +{ + uint64_t reg; + + __asm __volatile("mrrc\tp15, 1, %Q0, %R0, c14" : "=r" (reg)); + return (reg); +} + +static inline uint64_t +cp15_cntpct_get(void) +{ + uint64_t reg; + + __asm __volatile("mrrc\tp15, 0, %Q0, %R0, c14" : "=r" (reg)); + return (reg); +} + +#pragma weak __vdso_gettc +u_int +__vdso_gettc(const struct vdso_timehands *th) +{ + uint64_t val; + + __asm __volatile(".word\t0xf57ff06f" : : : "memory"); /* isb */ + val = th->th_physical == 0 ? cp15_cntvct_get() : cp15_cntpct_get(); + return (val); +} + +#pragma weak __vdso_gettimekeep +int +__vdso_gettimekeep(struct vdso_timekeep **tk) +{ + + return (_elf_aux_info(AT_TIMEKEEP, tk, sizeof(*tk))); +} diff --git a/lib/libc/arm/sys/brk.S b/lib/libc/arm/sys/brk.S index e5f8336..bf1b4fb 100644 --- a/lib/libc/arm/sys/brk.S +++ b/lib/libc/arm/sys/brk.S @@ -91,3 +91,5 @@ ENTRY(_brk) .Lcurbrk: .word PIC_SYM(CURBRK, GOT) END(_brk) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/sys/cerror.S b/lib/libc/arm/sys/cerror.S index 26f5211..5fad698 100644 --- a/lib/libc/arm/sys/cerror.S +++ b/lib/libc/arm/sys/cerror.S @@ -47,3 +47,5 @@ ASENTRY(CERROR) mvn r1, #0x00000000 ldmfd sp!, {r4, pc} END(CERROR) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/sys/pipe.S b/lib/libc/arm/sys/pipe.S index 77ce0fc..778e923 100644 --- a/lib/libc/arm/sys/pipe.S +++ b/lib/libc/arm/sys/pipe.S @@ -49,3 +49,5 @@ ENTRY(_pipe) mov r0, #0x00000000 RET END(_pipe) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/sys/ptrace.S b/lib/libc/arm/sys/ptrace.S index 876da32..dade223 100644 --- a/lib/libc/arm/sys/ptrace.S +++ b/lib/libc/arm/sys/ptrace.S @@ -47,3 +47,5 @@ ENTRY(ptrace) bcs PIC_SYM(CERROR, PLT) RET END(ptrace) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/sys/sbrk.S b/lib/libc/arm/sys/sbrk.S index 5cd9a03..25622c4 100644 --- a/lib/libc/arm/sys/sbrk.S +++ b/lib/libc/arm/sys/sbrk.S @@ -78,3 +78,5 @@ ENTRY(_sbrk) .Lcurbrk: .word PIC_SYM(CURBRK, GOT) END(_sbrk) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/sys/shmat.S b/lib/libc/arm/sys/shmat.S index 3fc3d02..3574b1d 100644 --- a/lib/libc/arm/sys/shmat.S +++ b/lib/libc/arm/sys/shmat.S @@ -5,3 +5,5 @@ __FBSDID("$FreeBSD$"); #include "SYS.h" RSYSCALL(shmat) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/sys/sigreturn.S b/lib/libc/arm/sys/sigreturn.S index 1e0f245..c377e4a 100644 --- a/lib/libc/arm/sys/sigreturn.S +++ b/lib/libc/arm/sys/sigreturn.S @@ -40,3 +40,5 @@ __FBSDID("$FreeBSD$"); */ RSYSCALL(sigreturn) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/arm/sys/syscall.S b/lib/libc/arm/sys/syscall.S index 73e6b83..c88d1ae 100644 --- a/lib/libc/arm/sys/syscall.S +++ b/lib/libc/arm/sys/syscall.S @@ -36,3 +36,5 @@ __FBSDID("$FreeBSD$"); #include "SYS.h" RSYSCALL(syscall) + + .section .note.GNU-stack,"",%progbits diff --git a/lib/libc/sys/Makefile.inc b/lib/libc/sys/Makefile.inc index a4414fa..e4fe1b2 100644 --- a/lib/libc/sys/Makefile.inc +++ b/lib/libc/sys/Makefile.inc @@ -102,7 +102,7 @@ SYM_MAPS+= ${LIBC_SRCTOP}/sys/Symbol.map CLEANFILES+= ${SASM} ${SPSEUDO} .if ${MACHINE_CPUARCH} == "amd64" || ${MACHINE_CPUARCH} == "i386" || \ - ${MACHINE_CPUARCH} == "powerpc" + ${MACHINE_CPUARCH} == "powerpc" || ${MACHINE_ARCH:Marmv6*} NOTE_GNU_STACK='\t.section .note.GNU-stack,"",%%progbits\n' .else NOTE_GNU_STACK='' diff --git a/lib/libcompiler_rt/Makefile b/lib/libcompiler_rt/Makefile index 5e21883..22c9f89 100644 --- a/lib/libcompiler_rt/Makefile +++ b/lib/libcompiler_rt/Makefile @@ -230,7 +230,7 @@ SYMLINKS+=libcompiler_rt_p.a ${LIBDIR}/libgcc_p.a .endif .if ${MACHINE_CPUARCH} == "amd64" || ${MACHINE_CPUARCH} == "i386" || \ - ${MACHINE_CPUARCH} == "powerpc" + ${MACHINE_CPUARCH} == "powerpc" || ${MACHINE_ARCH:Marmv6*} AFLAGS+=--noexecstack ACFLAGS+=-Wa,--noexecstack .endif diff --git a/libexec/rtld-elf/arm/rtld_start.S b/libexec/rtld-elf/arm/rtld_start.S index c482808..431ea48 100644 --- a/libexec/rtld-elf/arm/rtld_start.S +++ b/libexec/rtld-elf/arm/rtld_start.S @@ -97,3 +97,4 @@ _rtld_bind_start: ldmia sp!,{r0-r5,sl,fp,lr} /* restore the stack */ mov pc, ip /* jump to the new address */ + .section .note.GNU-stack,"",%progbits diff --git a/sys/arm/arm/elf_machdep.c b/sys/arm/arm/elf_machdep.c index 34761ff..4322cdd 100644 --- a/sys/arm/arm/elf_machdep.c +++ b/sys/arm/arm/elf_machdep.c @@ -43,6 +43,7 @@ __FBSDID("$FreeBSD$"); #include #include +#include #include #include @@ -76,13 +77,20 @@ struct sysentvec elf32_freebsd_sysvec = { .sv_setregs = exec_setregs, .sv_fixlimit = NULL, .sv_maxssiz = NULL, - .sv_flags = SV_ABI_FREEBSD | SV_ILP32, + .sv_flags = +#if __ARM_ARCH >= 7 + SV_SHP | +#endif + SV_ABI_FREEBSD | SV_ILP32, .sv_set_syscall_retval = cpu_set_syscall_retval, .sv_fetch_syscall_args = cpu_fetch_syscall_args, .sv_syscallnames = syscallnames, + .sv_shared_page_base = SHAREDPAGE, + .sv_shared_page_len = PAGE_SIZE, .sv_schedtail = NULL, .sv_thread_detach = NULL, }; +INIT_SYSENTVEC(elf32_sysvec, &elf32_freebsd_sysvec); static Elf32_Brandinfo freebsd_brand_info = { .brand = ELFOSABI_FREEBSD, diff --git a/sys/arm/arm/generic_timer.c b/sys/arm/arm/generic_timer.c index 636ba75..fd1f029 100644 --- a/sys/arm/arm/generic_timer.c +++ b/sys/arm/arm/generic_timer.c @@ -49,10 +49,13 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include +#include #include #include #include #include +#include #ifdef FDT #include @@ -121,6 +124,9 @@ static struct timecounter arm_tmr_timecount = { #define set_el1(x, val) WRITE_SPECIALREG(x ##_el1, val) #endif +static uint32_t arm_tmr_fill_vdso_timehands(struct vdso_timehands *vdso_th, + struct timecounter *tc); + static int get_freq(void) { @@ -181,17 +187,32 @@ get_ctrl(bool physical) } static void -disable_user_access(void) +setup_user_access(void *arg __unused) { uint32_t cntkctl; cntkctl = get_el1(cntkctl); cntkctl &= ~(GT_CNTKCTL_PL0PTEN | GT_CNTKCTL_PL0VTEN | - GT_CNTKCTL_EVNTEN | GT_CNTKCTL_PL0VCTEN | GT_CNTKCTL_PL0PCTEN); + GT_CNTKCTL_EVNTEN); + if (arm_tmr_sc->physical) { + cntkctl |= GT_CNTKCTL_PL0PCTEN; + cntkctl &= ~GT_CNTKCTL_PL0VCTEN; + } else { + cntkctl |= GT_CNTKCTL_PL0VCTEN; + cntkctl &= ~GT_CNTKCTL_PL0PCTEN; + } set_el1(cntkctl, cntkctl); isb(); } +static void +tmr_setup_user_access(void *arg __unused) +{ + + smp_rendezvous(NULL, setup_user_access, NULL, NULL); +} +SYSINIT(tmr_ua, SI_SUB_SMP, SI_ORDER_SECOND, tmr_setup_user_access, NULL); + static unsigned arm_tmr_get_timecount(struct timecounter *tc) { @@ -381,7 +402,7 @@ arm_tmr_attach(device_t dev) } } - disable_user_access(); + arm_cpu_fill_vdso_timehands = arm_tmr_fill_vdso_timehands; arm_tmr_timecount.tc_frequency = sc->clkfreq; tc_init(&arm_tmr_timecount); @@ -485,3 +506,13 @@ DELAY(int usec) first = last; } } + +static uint32_t +arm_tmr_fill_vdso_timehands(struct vdso_timehands *vdso_th, + struct timecounter *tc) +{ + + vdso_th->th_physical = arm_tmr_sc->physical; + bzero(vdso_th->th_res, sizeof(vdso_th->th_res)); + return (tc == &arm_tmr_timecount); +} diff --git a/sys/arm/arm/machdep.c b/sys/arm/arm/machdep.c index 32bbbc6..0105b33 100644 --- a/sys/arm/arm/machdep.c +++ b/sys/arm/arm/machdep.c @@ -82,6 +82,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include @@ -336,7 +337,11 @@ sendsig(catcher, ksi, mask) tf->tf_r5 = (register_t)&fp->sf_uc; tf->tf_pc = (register_t)catcher; tf->tf_usr_sp = (register_t)fp; - tf->tf_usr_lr = (register_t)(PS_STRINGS - *(p->p_sysent->sv_szsigcode)); + if (p->p_sysent->sv_sigcode_base != 0) + tf->tf_usr_lr = (register_t)p->p_sysent->sv_sigcode_base; + else + tf->tf_usr_lr = (register_t)(PS_STRINGS - + *(p->p_sysent->sv_szsigcode)); /* Set the mode to enter in the signal handler */ #if __ARM_ARCH >= 7 if ((register_t)catcher & 1) @@ -1696,3 +1701,14 @@ initarm(struct arm_boot_params *abp) #endif /* !ARM_NEW_PMAP */ #endif /* FDT */ + +uint32_t (*arm_cpu_fill_vdso_timehands)(struct vdso_timehands *, + struct timecounter *); + +uint32_t +cpu_fill_vdso_timehands(struct vdso_timehands *vdso_th, struct timecounter *tc) +{ + + return (arm_cpu_fill_vdso_timehands != NULL ? + arm_cpu_fill_vdso_timehands(vdso_th, tc) : 0); +} diff --git a/sys/arm/include/md_var.h b/sys/arm/include/md_var.h index 030b48b..e70dd75 100644 --- a/sys/arm/include/md_var.h +++ b/sys/arm/include/md_var.h @@ -45,6 +45,11 @@ extern int (*_arm_bzero)(void *, int, int); extern int _min_memcpy_size; extern int _min_bzero_size; +struct vdso_timehands; +struct timecounter; +extern uint32_t (*arm_cpu_fill_vdso_timehands)(struct vdso_timehands *, + struct timecounter *); + #define DST_IS_USER 0x1 #define SRC_IS_USER 0x2 #define IS_PHYSICAL 0x4 diff --git a/sys/arm/include/vdso.h b/sys/arm/include/vdso.h index d6aa162..6a0ec7b 100644 --- a/sys/arm/include/vdso.h +++ b/sys/arm/include/vdso.h @@ -29,6 +29,7 @@ #define _ARM_VDSO_H #define VDSO_TIMEHANDS_MD \ - uint32_t th_res[8]; + uint32_t th_physical; \ + uint32_t th_res[7]; #endif diff --git a/sys/arm/include/vmparam.h b/sys/arm/include/vmparam.h index b6e76bf..36f19a3 100644 --- a/sys/arm/include/vmparam.h +++ b/sys/arm/include/vmparam.h @@ -124,7 +124,8 @@ #endif #define VM_MAX_ADDRESS VM_MAXUSER_ADDRESS -#define USRSTACK VM_MAXUSER_ADDRESS +#define SHAREDPAGE (VM_MAXUSER_ADDRESS - PAGE_SIZE) +#define USRSTACK SHAREDPAGE /* initial pagein size of beginning of executable file */ #ifndef VM_INITIAL_PAGEIN diff --git a/sys/conf/files.arm b/sys/conf/files.arm index 84267a0..a98390a 100644 --- a/sys/conf/files.arm +++ b/sys/conf/files.arm @@ -102,7 +102,6 @@ font.h optional sc \ no-obj no-implicit-rule before-depend \ clean "font.h ${SC_DFLT_FONT}-8x14 ${SC_DFLT_FONT}-8x16 ${SC_DFLT_FONT}-8x8" kern/subr_busdma_bufalloc.c standard -kern/subr_dummy_vdso_tc.c standard kern/subr_sfbuf.c standard libkern/arm/aeabi_unwind.c standard libkern/arm/divsi3.S standard diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c index 8023d55..ecec9cd 100644 --- a/sys/kern/imgact_elf.c +++ b/sys/kern/imgact_elf.c @@ -80,6 +80,9 @@ __FBSDID("$FreeBSD$"); #include #include +#ifdef __arm__ +#include +#endif #define ELF_NOTE_ROUNDSIZE 4 #define OLD_EI_BRAND 8 @@ -116,7 +119,8 @@ SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), CTLFLAG_RW, &elf_legacy_coredump, 0, ""); int __elfN(nxstack) = -#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */ +#if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */ || \ + (defined(__arm__) && __ARM_ARCH >= 7) 1; #else 0; From owner-freebsd-arm@freebsd.org Tue Sep 29 15:19:50 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3F51A0A1C5 for ; Tue, 29 Sep 2015 15:19:50 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B9CE41462 for ; Tue, 29 Sep 2015 15:19:50 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 29 Sep 2015 15:20:27 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t8TFJgMY014257; Tue, 29 Sep 2015 09:19:42 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1443539982.1224.433.camel@freebsd.org> Subject: Re: Shared page and related goodies for ARMv7 From: Ian Lepore To: Konstantin Belousov Cc: freebsd-arm@freebsd.org Date: Tue, 29 Sep 2015 09:19:42 -0600 In-Reply-To: <20150929132332.GH11284@kib.kiev.ua> References: <20150929132332.GH11284@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 15:19:50 -0000 On Tue, 2015-09-29 at 16:23 +0300, Konstantin Belousov wrote: > As an exercise to get myself more familiar with the ARM architecture, > I added the shared page for FreeBSD/ARMv7. This provides the standard > features tied to the shared page, in particular, a non-executable stack > for the compatible binaries, and fast gettimeofday() and clock_gettime() > functions. For reference, the measurements on my RPI2 done by > tools/tools/syscall_timing, show > for userspace gettimeofday: > % ./syscall_timing gettimeofday > Clock resolution: 0.000000053 > test loop time iterations periteration > gettimeofday 0 1.009965385 2743838 0.000000368 > gettimeofday 1 1.009899240 2743629 0.000000368 > gettimeofday 2 1.009952833 2538253 0.000000397 > gettimeofday 3 1.009918198 2404272 0.000000420 > gettimeofday 4 1.009875126 2404567 0.000000419 > gettimeofday 5 1.009950700 2405196 0.000000419 > gettimeofday 6 1.009859555 2623534 0.000000384 > gettimeofday 7 1.009911534 2743249 0.000000368 > gettimeofday 8 1.009928618 2743240 0.000000368 > gettimeofday 9 1.009920910 2743227 0.000000368 > for syscall: > gettimeofday 0 1.009994949 659319 0.000001531 > gettimeofday 1 1.009869846 583343 0.000001731 > gettimeofday 2 1.009899950 583384 0.000001731 > gettimeofday 3 1.009873232 636420 0.000001586 > gettimeofday 4 1.009909639 669715 0.000001507 > gettimeofday 5 1.009941201 669640 0.000001508 > gettimeofday 6 1.009930733 669051 0.000001509 > gettimeofday 7 1.009890005 669064 0.000001509 > gettimeofday 8 1.009915474 669168 0.000001509 > gettimeofday 9 1.009918860 668739 0.000001510 > > The patch is pretty much straightforward, interesting details are > listed below. > > - The shared page is only enabled for ARMv7 kernels. From my reading of > VMSA chapters for ARMv6 and ARMv7, only v7 ensures that there is no > cache aliasing for multiple-times mapped page, while v6 requires coloring. > Shared page is mapped both at the top of UVA and somewhere in KVA. > - There is a bug in the generic timer setup, it seems. The CNTKCTL CP15 > register is core-private, which means that the in-tree code only sets access > permissions on the BSP. APs CNTKCTL are left in undefined state, possibly > set up to some value by loader. This might allow userspace to reprogram > timers on APs. I fixed this by using rendezvous after SMP is started. > - I have to add explicit directives to create .note.GNU-stack sections in > some __eabi files from libcompiler-rt which are linked into libc. > Upstream refused to do global change adding the stack note for all asms, > recommending to live with --noexecstack assembler option. But we cannot > do this for files linked into libc. > - arm64 would require some additions, I did not tested the build. > > It would be useful to test the patch on ARMv6 to ensure that signals and > gettimeofday() work. Some things, in no particular order... I can't do anything with an inline email patch (my mail client destroys whitespace). Can you send it as an attachment, or put it somewhere on freefall or something please? There is no difference between armv6 and armv7 in our world. The only armv6 chip we support is the one used in the original rpi and it has a 16K 4-way L1 cache which means the page coloring issue disappears and we can treat it the same as an armv7 chip (different cache ops, but the caches behave the same). I just skimmed through the patch quickly and the main thing that jumps out at me is that what you've done works only on rpi2 and aarch64, because those are the only platforms that support that timer hardware. (That means I can't test it, but once I get your patch in a usable form I can have a shot at implementations for other timers). It's not clear to me that this scheme can even work on most armv7 hardware because of the timer hardware involved. I think it would mean giving userland read access to a whole page worth of IO space and in some cases there are registers in that range where reads have side effects whose consequences could be dire (such as pending-interrupt registers). -- Ian From owner-freebsd-arm@freebsd.org Tue Sep 29 15:25:51 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D6F1A0A787 for ; Tue, 29 Sep 2015 15:25:51 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E63919D6 for ; Tue, 29 Sep 2015 15:25:50 +0000 (UTC) (envelope-from jim@netgate.com) Received: by obbda8 with SMTP id da8so8282041obb.1 for ; Tue, 29 Sep 2015 08:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yWnE2NizCBVGuvFUWfssWkGTB38RWVECRHjCXg6xvc0=; b=j4yDJLMq1Io/P5k8yjej0mLDuVnwIJNF0XjNRZEqpTmj+Va4uA1NPqaK8kGg4f8YrP qLBufvxfL6pIg05kWKlu3m/hgYTgGlCvGecuzuykIppQdDrtFKOT9+3Zlu3iWA7D1IG6 GgQNwn8tPUkJm8aKwWM3mdki2lP+vNCr2Gx5Q= 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=yWnE2NizCBVGuvFUWfssWkGTB38RWVECRHjCXg6xvc0=; b=AE0BnFmaGg0RRUSkCFF6oTxNIyocD/49dO5KUPmSgb7B7I7b5lQYrVoJcl9dMbiWO0 ahoMTlrds4pjEt1PwkA780270VVwem3si80Jn2uEnD9vSwNkMIBKkT/v7ZlIjzsa0Gkt ffA3IZIYf0qg8RIYCy0lb1DTPmGlK+Knmu5yTliiCplirB1sJOriQE6NElqiYydoX+af C3XtNonUF7WpmF7Ttr9/lpIzGfHpzpEXgNhHJFdZAxYsaOn1BXTTCA+Y1I0jWKt/xend 28VI2vsy790HwXOcsgNuL/ng06Yfgh739EZ+lbgec2B5rfJRtCqwk/NRlZhynFYab/TO nuDw== X-Gm-Message-State: ALoCoQnU7xDQaWyPQBoyNgecwAvW7JojGLiARnrfrr5+kCQ17yBIulV/vuUn917bgkD370MphGCY X-Received: by 10.182.19.4 with SMTP id a4mr14601551obe.33.1443540350127; Tue, 29 Sep 2015 08:25:50 -0700 (PDT) Received: from [172.21.0.27] (65-36-83-15.static.grandenetworks.net. [65.36.83.15]) by smtp.gmail.com with ESMTPSA id fw5sm11614991obb.1.2015.09.29.08.25.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Sep 2015 08:25:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: BeagleBone Green From: Jim Thompson X-Mailer: iPhone Mail (13A404) In-Reply-To: <967B69D5-19FA-40FE-BBFD-DFB231EEBC8D@netgate.com> Date: Tue, 29 Sep 2015 10:25:47 -0500 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6EF9C190-A5C2-4B68-ACB5-805AE8323E57@netgate.com> References: <56099322.1080804@ceetonetechnology.com> <967B69D5-19FA-40FE-BBFD-DFB231EEBC8D@netgate.com> To: George Rosamond X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 15:25:51 -0000 > On Sep 28, 2015, at 4:37 PM, Jim Thompson wrote: >=20 > Beaglebone Green eliminates microSD I was mistaken. It appears that Beaglebone Green has microSD, and adds a bat= tery holder to keep the TOD clock running when no power is supplied. =20= From owner-freebsd-arm@freebsd.org Tue Sep 29 15:43:47 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 29440A0B57F for ; Tue, 29 Sep 2015 15:43:47 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 00A84159C for ; Tue, 29 Sep 2015 15:43:46 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 235A720801 for ; Tue, 29 Sep 2015 11:43:39 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Tue, 29 Sep 2015 11:43:39 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=G6DHPZwlkvzlO+o JBnAIBe9NwFU=; b=GP5c0ltdliyFu30PqbpWciHkwdS3OlFq3h6rmKyyLVi+xn6 2ldfv9WN73dQxPxwNr5B3qYY+hU00827fBwuHD5Bb529Or5KQOYi9rnmzuNFRBnU 6ch+xbkR5gniUyIsFTQiYkUMdt7BbdhJHXzdzoXc+QgZ42sJ6TjXDsbo8Sd8= Received: by web3.nyi.internal (Postfix, from userid 99) id 01050113A0E; Tue, 29 Sep 2015 11:43:38 -0400 (EDT) Message-Id: <1443541418.2789327.396636593.33FB13E5@webmail.messagingengine.com> X-Sasl-Enc: eYJyHrPGUR4wauH4S78Q2/zXHryOjC8keybWb+HtEn66 1443541418 From: Mark Felder To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-f5bf1cf6 In-Reply-To: <6EF9C190-A5C2-4B68-ACB5-805AE8323E57@netgate.com> References: <56099322.1080804@ceetonetechnology.com> <967B69D5-19FA-40FE-BBFD-DFB231EEBC8D@netgate.com> <6EF9C190-A5C2-4B68-ACB5-805AE8323E57@netgate.com> Subject: Re: BeagleBone Green Date: Tue, 29 Sep 2015 10:43:38 -0500 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 15:43:47 -0000 On Tue, Sep 29, 2015, at 10:25, Jim Thompson wrote: > > > > On Sep 28, 2015, at 4:37 PM, Jim Thompson wrote: > > > > Beaglebone Green eliminates microSD > > I was mistaken. It appears that Beaglebone Green has microSD, and adds a > battery holder to keep the TOD clock running when no power is supplied. > "Note: The RTC battery was removed from the final design." http://beagleboard.org/green at bottom of page under the video -- Mark Felder ports-secteam member feld@FreeBSD.org From owner-freebsd-arm@freebsd.org Tue Sep 29 16:02:04 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA90BA0C026 for ; Tue, 29 Sep 2015 16:02:04 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5AB8F11A4 for ; Tue, 29 Sep 2015 16:02:03 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id t8TFlT1N071723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Sep 2015 17:47:30 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id t8TFlMpA035718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Sep 2015 17:47:22 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id t8TFlMff043352; Tue, 29 Sep 2015 17:47:22 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id t8TFlMhc043351; Tue, 29 Sep 2015 17:47:22 +0200 (CEST) (envelope-from ticso) Date: Tue, 29 Sep 2015 17:47:22 +0200 From: Bernd Walter To: Jim Thompson Cc: George Rosamond , "freebsd-arm@freebsd.org" Subject: Re: BeagleBone Green Message-ID: <20150929154721.GE42013@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <56099322.1080804@ceetonetechnology.com> <967B69D5-19FA-40FE-BBFD-DFB231EEBC8D@netgate.com> <6EF9C190-A5C2-4B68-ACB5-805AE8323E57@netgate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6EF9C190-A5C2-4B68-ACB5-805AE8323E57@netgate.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 16:02:04 -0000 On Tue, Sep 29, 2015 at 10:25:47AM -0500, Jim Thompson wrote: > > > > On Sep 28, 2015, at 4:37 PM, Jim Thompson wrote: > > > > Beaglebone Green eliminates microSD > > I was mistaken. It appears that Beaglebone Green has microSD, and adds a battery holder to keep the TOD clock running when no power is supplied. Nice feature. On the other hand I don't like USB connectors for power and having the barrel plug was a good thing. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Tue Sep 29 16:05:22 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C5598A0C2FF for ; Tue, 29 Sep 2015 16:05:22 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A13B41295 for ; Tue, 29 Sep 2015 16:05:22 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 29 Sep 2015 16:05:54 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t8TG5EJL014400; Tue, 29 Sep 2015 10:05:14 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1443542714.1224.445.camel@freebsd.org> Subject: Re: netboot configuration [was: Re: NFS Root with Raspberry Pi (nfs_diskless: no interface)] From: Ian Lepore To: Daniel Braniss Cc: freebsd-arm@freebsd.org, Rick Macklem Date: Tue, 29 Sep 2015 10:05:14 -0600 In-Reply-To: References: <20150922052522.GA62140@gmail.com> <00C49FEB-E8EF-4469-85E2-0F901215CD11@cs.huji.ac.il> <20150923050414.GB43653@gmail.com> <91AAC64E-4C38-47AA-8910-48F7654A7524@cs.huji.ac.il> <20150923174445.GE43653@gmail.com> <1443105426.1224.272.camel@freebsd.org> <20150924163658.GC32257@gmail.com> <560438C5.3090404@selasky.org> <1443142468.1224.322.camel@freebsd.org> <1443209159.1224.361.camel@freebsd.org> <12C96F79-2D70-408D-AD4C-F06F6B909AD3@cs.huji.ac.il> <1443276119.1224.382.camel@freebsd.org> <33EFE756-B428-4A72-B3C5-0E764FA8ACC6@cs.huji.ac.il> <1443370490.1224.392.camel@freebsd.org> <1443371712.1224.398.camel@freebsd.org> Content-Type: text/plain; charset="iso-8859-13" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 16:05:22 -0000 On Tue, 2015-09-29 at 12:24 +0300, Daniel Braniss wrote: > > On 27 Sep 2015, at 19:35, Ian Lepore wrote: > > > > On Sun, 2015-09-27 at 19:25 +0300, Daniel Braniss wrote: > >>> On Sep 27, 2015, at 7:14 PM, Ian Lepore wrote: > >>> > >>> On Sun, 2015-09-27 at 14:15 +0300, Daniel Braniss wrote: > > [...] > >>>> I compiled the u-boot-rpi from ports, > >>>> the good news: > >>>> it understands UserPreboot > >>>> the bad news: > >>>> the nfs boot gets stuck after a while. > >>>> > >>>> after much trial and error, this is what I do: > >>>> hit a key to enter U-Boot > >>>> then type: > >>>> setenv loaderdev net > >>>> boot > >>>> > >>>> attaching the console: > >>> > >>> I was also experiencing intermittant lockups while loader loads the > >>> kernel. I just wrote it off to failing hardware (I powered my rpi on > >>> for the first time in 6-8 months to work on this), since I've never had > >>> a problem with netbooting before (it's the only way I've ever booted the > >>> rpi). If it's not just my board going bad, then that's a bit of a > >>> mystery. The only other difference here from what I've always done is > >>> setting rootpath and other net config in u-boot instead of letting ubldr > >>> get it from dhcp. > >> > >> with the stuff from crochet it works, same setup! I am sniffing the net via > >> wireshark, and it stops at different positions in the kernel file, > >> so the settings of rootpath and other configs are irrelevant. > >> the transfer is being done via udp/nfs/v3 (hence added ric :-) maybe > >> he can see something we donÿt. > > > > Hmmm. What stuff from crochet? The two components that are in play > > here are u-boot itself (it contains the low-level network drivers that > > ubldr uses -- it's effectively acting as a bios for ubldr), and ubldr > > which contains the higher-level network code. > > > > In theory ubldr should be the same in both cases; nothing much has > > changed in the loader code for months. But there are different paths > > through the code depending on how it gets the network parms, and I could > > easily have glitched something when I added the feature that lets you > > set the config with u-boot env vars. > > > > The u-boot might be different between a crochet and ports build. They > > both start with gonzo's u-boot 2013.10 sources, but crochet probably has > > a slightly different set of patches it applies. > > > > -- Ian > > > > with the old uboot it boots ok, with the newer/modified it stops at random > places reading via udp/nfs/v3 the kernel. it loads correctly all the *.4th files, > then starts reading the kernel, and hangs after a random time. > I have found that if I let u-boot get an ip address via dhcp then the load of the kernel in ubldr never fails (I've had it reboot-looping for 24 hours now without a hang). But without letting u-boot do the dhcp thing it hangs pretty much every time. Substituting a ping for the dhcp isn't enough to make it reliable. I've stopped debugging that whole mess for now to have a quick check whether the very latest mainline u-boot (2015.10-rc4) is able to netboot. It sure would be nice to use something modern that has already been debugged by others. :) > on another issue, if I type dhcp instead of boot, it loads via TFTP filename, > which I set to ubldr/ubldr.bin, it loads and now prompts again, > what should the command be? I tried go 0, go 20000, in which case execs > the old ubldr :-( > The old ubldr had to be launched using 'bootelf', the new ubldr.bin has to be launched using "go ${loadaddr}". While we transition from old to new I've been using "dhcp && bootelf || go ${loadaddr}" -- if it's ubldr the bootelf command works; if bootelf fails it fails back to using go. -- Ian From owner-freebsd-arm@freebsd.org Tue Sep 29 16:23:22 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2FA44A0CB9E for ; Tue, 29 Sep 2015 16:23:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CAE271E7B; Tue, 29 Sep 2015 16:23:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t8TGNCVr017657 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 29 Sep 2015 19:23:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t8TGNCVr017657 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t8TGNCKX017656; Tue, 29 Sep 2015 19:23:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 29 Sep 2015 19:23:12 +0300 From: Konstantin Belousov To: Ian Lepore Cc: freebsd-arm@freebsd.org Subject: Re: Shared page and related goodies for ARMv7 Message-ID: <20150929162312.GJ11284@kib.kiev.ua> References: <20150929132332.GH11284@kib.kiev.ua> <1443539982.1224.433.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1443539982.1224.433.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 16:23:22 -0000 On Tue, Sep 29, 2015 at 09:19:42AM -0600, Ian Lepore wrote: > I can't do anything with an inline email patch (my mail client destroys > whitespace). Can you send it as an attachment, or put it somewhere on > freefall or something please? I just committed the .note.GNU-stack bits, reviewed by andrew. This reduces the noise in the patch, the rest is available at https://people.freebsd.org/~kib/misc/arm_sharedpage.1.patch > > There is no difference between armv6 and armv7 in our world. The only > armv6 chip we support is the one used in the original rpi and it has a > 16K 4-way L1 cache which means the page coloring issue disappears and we > can treat it the same as an armv7 chip (different cache ops, but the > caches behave the same). Olivier just told me the same, I already changed the elf_machdep.c patch to enable shared page for ARMv6 and later. > > I just skimmed through the patch quickly and the main thing that jumps > out at me is that what you've done works only on rpi2 and aarch64, > because those are the only platforms that support that timer hardware. > (That means I can't test it, but once I get your patch in a usable form > I can have a shot at implementations for other timers). Cortex A7/A15 and whole ARMv8 is not too bad set of machines for fast gettimeofday() IMO, at least for the first try. I am willing to adjust both approach and code it for wider usefulness. > > It's not clear to me that this scheme can even work on most armv7 > hardware because of the timer hardware involved. I think it would mean > giving userland read access to a whole page worth of IO space and in > some cases there are registers in that range where reads have side > effects whose consequences could be dire (such as pending-interrupt > registers). Yes, if timer counter is on the page shared with other registers, which read side effects are not safe, it cannot be used. But I do not see how such hardware could be useful for any syscall-less implementation of gettimeofday(), except for very imprecise one, where counter is written to the shared page on timer interrupt. I do not think that we want such hack done. On x86, HPET timers have relatively sane design, the registers page can be exported to userspace r/o without consequences. Exporting HPET to userspace even could be useful on Core2 (old) machines where RDTSC is unusable. HPET could be made a test bed for this kind of hardware, but the interest is low and I did not coded neccessary infrastructure as result. From owner-freebsd-arm@freebsd.org Tue Sep 29 16:35:38 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65EE7A0A279 for ; Tue, 29 Sep 2015 16:35:38 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F4DD14BE for ; Tue, 29 Sep 2015 16:35:37 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from 127.0.0.1 (tor-exit-01.thehappy3.com [178.63.97.34]) (authenticated bits=0) by feynman.konjz.org (8.14.7/8.14.4) with ESMTP id t8TGaDD8026726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 29 Sep 2015 12:36:16 -0400 (EDT) (envelope-from george@ceetonetechnology.com) Subject: Re: BeagleBone Green To: ticso@cicely.de, Jim Thompson References: <56099322.1080804@ceetonetechnology.com> <967B69D5-19FA-40FE-BBFD-DFB231EEBC8D@netgate.com> <6EF9C190-A5C2-4B68-ACB5-805AE8323E57@netgate.com> <20150929154721.GE42013@cicely7.cicely.de> Cc: "freebsd-arm@freebsd.org" From: George Rosamond Message-ID: <560ABDC1.6000301@ceetonetechnology.com> Date: Tue, 29 Sep 2015 12:35:13 -0400 MIME-Version: 1.0 In-Reply-To: <20150929154721.GE42013@cicely7.cicely.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 16:35:38 -0000 Bernd Walter: > On Tue, Sep 29, 2015 at 10:25:47AM -0500, Jim Thompson wrote: >> >> >>> On Sep 28, 2015, at 4:37 PM, Jim Thompson wrote: >>> >>> Beaglebone Green eliminates microSD >> >> I was mistaken. It appears that Beaglebone Green has microSD, and adds a battery holder to keep the TOD clock running when no power is supplied. > > Nice feature. > On the other hand I don't like USB connectors for power and having the > barrel plug was a good thing. > +1 on that. There were cases in the past that I assume power was the issue with a number of BeagleBone problems, such as mount USB sticks. The OP question remains, though: has anyone installed FreeBSD on the Green yet? I'm curious about the support for groove and the associated devices, and whether the "identical chipsets" are *really* identical. We all know, by now, that the same label on a component is not necessarily the same chipset. g From owner-freebsd-arm@freebsd.org Tue Sep 29 16:54:33 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59E7BA0B111 for ; Tue, 29 Sep 2015 16:54:33 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from kif.fubar.geek.nz (kif.fubar.geek.nz [178.62.119.249]) by mx1.freebsd.org (Postfix) with ESMTP id 29D5A101F; Tue, 29 Sep 2015 16:54:32 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from bender.Home (unknown [90.214.223.59]) by kif.fubar.geek.nz (Postfix) with ESMTPSA id 9E82CD7907; Tue, 29 Sep 2015 16:54:26 +0000 (UTC) Date: Tue, 29 Sep 2015 17:54:22 +0100 From: Andrew Turner To: Konstantin Belousov Cc: Ian Lepore , freebsd-arm@freebsd.org Subject: Re: Shared page and related goodies for ARMv7 Message-ID: <20150929175422.417baf94@bender.Home> In-Reply-To: <20150929162312.GJ11284@kib.kiev.ua> References: <20150929132332.GH11284@kib.kiev.ua> <1443539982.1224.433.camel@freebsd.org> <20150929162312.GJ11284@kib.kiev.ua> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; amd64-portbld-freebsd10.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 16:54:33 -0000 On Tue, 29 Sep 2015 19:23:12 +0300 Konstantin Belousov wrote: > On Tue, Sep 29, 2015 at 09:19:42AM -0600, Ian Lepore wrote: > > I just skimmed through the patch quickly and the main thing that > > jumps out at me is that what you've done works only on rpi2 and > > aarch64, because those are the only platforms that support that > > timer hardware. (That means I can't test it, but once I get your > > patch in a usable form I can have a shot at implementations for > > other timers). > Cortex A7/A15 and whole ARMv8 is not too bad set of machines for fast > gettimeofday() IMO, at least for the first try. I am willing to > adjust both approach and code it for wider usefulness. It's an optional feature on ARMv7, we only build it for Exynos 5, Raspberry Pi 2, and QEMU virt. How will it work on hardware that lacks the generic timer? Will it always try and use this hardware, even if it's missing, or do we need to tell userland what to use, with a fallback to a syscall? Andrew From owner-freebsd-arm@freebsd.org Tue Sep 29 17:12:53 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2F6EA0BF15 for ; Tue, 29 Sep 2015 17:12:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4E1A61121; Tue, 29 Sep 2015 17:12:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t8THCkR0029726 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 29 Sep 2015 20:12:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t8THCkR0029726 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t8THCkew029725; Tue, 29 Sep 2015 20:12:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 29 Sep 2015 20:12:46 +0300 From: Konstantin Belousov To: Andrew Turner Cc: Ian Lepore , freebsd-arm@freebsd.org Subject: Re: Shared page and related goodies for ARMv7 Message-ID: <20150929171246.GK11284@kib.kiev.ua> References: <20150929132332.GH11284@kib.kiev.ua> <1443539982.1224.433.camel@freebsd.org> <20150929162312.GJ11284@kib.kiev.ua> <20150929175422.417baf94@bender.Home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150929175422.417baf94@bender.Home> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 17:12:53 -0000 On Tue, Sep 29, 2015 at 05:54:22PM +0100, Andrew Turner wrote: > On Tue, 29 Sep 2015 19:23:12 +0300 > Konstantin Belousov wrote: > > > On Tue, Sep 29, 2015 at 09:19:42AM -0600, Ian Lepore wrote: > > > I just skimmed through the patch quickly and the main thing that > > > jumps out at me is that what you've done works only on rpi2 and > > > aarch64, because those are the only platforms that support that > > > timer hardware. (That means I can't test it, but once I get your > > > patch in a usable form I can have a shot at implementations for > > > other timers). > > Cortex A7/A15 and whole ARMv8 is not too bad set of machines for fast > > gettimeofday() IMO, at least for the first try. I am willing to > > adjust both approach and code it for wider usefulness. > > It's an optional feature on ARMv7, we only build it for Exynos 5, > Raspberry Pi 2, and QEMU virt. > > How will it work on hardware that lacks the generic timer? Will it > always try and use this hardware, even if it's missing, or do we need > to tell userland what to use, with a fallback to a syscall? The AT_TIMEKEEP aux vector is provided by kernel. It points to the struct vdso_timekeep (see sys/vdso.h), which contains tk_ver and tk_enabled fields. The tk_ver member defines the version for layout of the struct vdso_timekeep, and tk_enabled is boolean which indicates should the user-space gettimeofday() mechanism be used. The tk_enabled member is never set to true for non generic timer timecounter in the patch. If the hardware is compatible, operator can still manually control use of the syscall vs. usermode time with sysctl kern.timecounter.fast_gettime. The struct vdso_timehands has the th_algo member, which is intended to communicate the actual algorithm to calculate the time. Idea of algorithm includes both kind of hardware used and interpretation of the VDSO_TIMEHANDS_MD members, if required by algorithm. This was intended to, eg. select between different hardware like RDTSC or HPET on x86. From owner-freebsd-arm@freebsd.org Wed Sep 30 07:39:31 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FEE9A0BDBE for ; Wed, 30 Sep 2015 07:39:31 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 0C5441439; Wed, 30 Sep 2015 07:39:30 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from chamsa.cs.huji.ac.il ([132.65.80.19]) by kabab.cs.huji.ac.il with esmtp id 1ZhBz1-000Cx1-NG; Wed, 30 Sep 2015 10:39:23 +0300 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: netboot configuration [was: Re: NFS Root with Raspberry Pi (nfs_diskless: no interface)] From: Daniel Braniss In-Reply-To: <1443542714.1224.445.camel@freebsd.org> Date: Wed, 30 Sep 2015 10:39:23 +0300 Cc: freebsd-arm@freebsd.org Message-Id: <7DBAE39E-55B2-4685-9C5E-2933B1DDFEF4@cs.huji.ac.il> References: <20150922052522.GA62140@gmail.com> <00C49FEB-E8EF-4469-85E2-0F901215CD11@cs.huji.ac.il> <20150923050414.GB43653@gmail.com> <91AAC64E-4C38-47AA-8910-48F7654A7524@cs.huji.ac.il> <20150923174445.GE43653@gmail.com> <1443105426.1224.272.camel@freebsd.org> <20150924163658.GC32257@gmail.com> <560438C5.3090404@selasky.org> <1443142468.1224.322.camel@freebsd.org> <1443209159.1224.361.camel@freebsd.org> <12C96F79-2D70-408D-AD4C-F06F6B909AD3@cs.huji.ac.il> <1443276119.1224.382.camel@freebsd.org> <33EFE756-B428-4A72-B3C5-0E764FA8ACC6@cs.huji.ac.il> <1443370490.1224.392.camel@freebsd.org> <1443371712.1224.398.camel@freebsd.org> <1443542714.1224.445.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.2104) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 07:39:31 -0000 > On 29 Sep 2015, at 19:05, Ian Lepore wrote: >=20 > On Tue, 2015-09-29 at 12:24 +0300, Daniel Braniss wrote: >>> On 27 Sep 2015, at 19:35, Ian Lepore wrote: >>>=20 >>> On Sun, 2015-09-27 at 19:25 +0300, Daniel Braniss wrote: >>>>> On Sep 27, 2015, at 7:14 PM, Ian Lepore wrote: >>>>>=20 >>>>> On Sun, 2015-09-27 at 14:15 +0300, Daniel Braniss wrote: >>> [...] >>>>>> I compiled the u-boot-rpi from ports, >>>>>> the good news: >>>>>> it understands UserPreboot >>>>>> the bad news: >>>>>> the nfs boot gets stuck after a while. >>>>>>=20 >>>>>> after much trial and error, this is what I do: >>>>>> hit a key to enter U-Boot >>>>>> then type: >>>>>> setenv loaderdev net >>>>>> boot >>>>>>=20 >>>>>> attaching the console: >>>>>=20 >>>>> I was also experiencing intermittant lockups while loader loads = the >>>>> kernel. I just wrote it off to failing hardware (I powered my rpi = on >>>>> for the first time in 6-8 months to work on this), since I've = never had >>>>> a problem with netbooting before (it's the only way I've ever = booted the >>>>> rpi). If it's not just my board going bad, then that's a bit of a >>>>> mystery. The only other difference here from what I've always = done is >>>>> setting rootpath and other net config in u-boot instead of letting = ubldr >>>>> get it from dhcp. >>>>=20 >>>> with the stuff from crochet it works, same setup! I am sniffing the = net via >>>> wireshark, and it stops at different positions in the kernel file, >>>> so the settings of rootpath and other configs are irrelevant. >>>> the transfer is being done via udp/nfs/v3 (hence added ric :-) = maybe >>>> he can see something we don=C2=B4t. >>>=20 >>> Hmmm. What stuff from crochet? The two components that are in play >>> here are u-boot itself (it contains the low-level network drivers = that >>> ubldr uses -- it's effectively acting as a bios for ubldr), and = ubldr >>> which contains the higher-level network code. >>>=20 >>> In theory ubldr should be the same in both cases; nothing much has >>> changed in the loader code for months. But there are different = paths >>> through the code depending on how it gets the network parms, and I = could >>> easily have glitched something when I added the feature that lets = you >>> set the config with u-boot env vars. >>>=20 >>> The u-boot might be different between a crochet and ports build. = They >>> both start with gonzo's u-boot 2013.10 sources, but crochet probably = has >>> a slightly different set of patches it applies. >>>=20 >>> -- Ian >>>=20 >>=20 >> with the old uboot it boots ok, with the newer/modified it stops at = random >> places reading via udp/nfs/v3 the kernel. it loads correctly all the = *.4th files, >> then starts reading the kernel, and hangs after a random time. >>=20 >=20 > I have found that if I let u-boot get an ip address via dhcp then the > load of the kernel in ubldr never fails (I've had it reboot-looping = for > 24 hours now without a hang). But without letting u-boot do the dhcp > thing it hangs pretty much every time. Substituting a ping > for the dhcp isn't enough to make it reliable. >=20 > I've stopped debugging that whole mess for now to have a quick check > whether the very latest mainline u-boot (2015.10-rc4) is able to > netboot. It sure would be nice to use something modern that has = already > been debugged by others. :) there is definitely an issue with the net driver in the newer/ports = u-boot. - tftpboot sometimes works :-) - same with nfs =09 via dhcp: it should not try tftp load filename if none is supplied, i.e. = defaulting to .img is wrong! i got ubldr loaded via tftp and then bootelf got it running. the loaded kernel complained: No valid device tree blob found! I guess some of the environmet variables got lost my network is quiet busy, may be thats a factor? =09 >=20 >> on another issue, if I type dhcp instead of boot, it loads via TFTP = filename, >> which I set to ubldr/ubldr.bin, it loads and now prompts again, >> what should the command be? I tried go 0, go 20000, in which case = execs >> the old ubldr :-( >>=20 >=20 > The old ubldr had to be launched using 'bootelf', the new ubldr.bin = has > to be launched using "go ${loadaddr}". While we transition from old = to > new I've been using "dhcp && bootelf || go ${loadaddr}" = -- > if it's ubldr the bootelf command works; if bootelf fails it fails = back > to using go. >=20 > -- Ian From owner-freebsd-arm@freebsd.org Wed Sep 30 09:20:35 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01D7FA0B6CB for ; Wed, 30 Sep 2015 09:20:35 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [54.72.43.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 90B2019F0 for ; Wed, 30 Sep 2015 09:20:33 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from [192.168.1.171] (188-127-209-196.cust.suomicom.net [188.127.209.196]) (authenticated bits=0) by mail.kronometrix.org (8.14.9/8.14.9) with ESMTP id t8U9KOUR073166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 30 Sep 2015 09:20:24 GMT (envelope-from sparvu@kronometrix.org) Reply-To: sparvu@kronometrix.org To: "freebsd-arm@freebsd.org" From: Stefan Parvu Subject: compile perl on RPI2 failure in opbasic/arith.t Organization: kronometrix.org Message-ID: <560BA953.8020702@kronometrix.org> Date: Wed, 30 Sep 2015 12:20:19 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 09:20:35 -0000 Im not able to compile perl on RPI2 hardware, using cc. Make test always breaks here: lib/vmsish .................................................... ok lib/warnings .................................................. ok Failed 1 test out of 2225, 99.96% okay. opbasic/arith.t ### Since not all tests were successful, you may want to run some of ### them individually and examine any diagnostic messages they produce. ### See the INSTALL document's section on "make test". ### You have a good chance to get more information by running ### ./perl harness ### in the 't' directory since most (>=80%) of the tests succeeded. ### You may have to set your dynamic library search path, ### LD_LIBRARY_PATH, to point to the build directory: ### setenv LD_LIBRARY_PATH `pwd`; cd t; ./perl harness ### LD_LIBRARY_PATH=`pwd`; export LD_LIBRARY_PATH; cd t; ./perl harness ### export LD_LIBRARY_PATH=`pwd`; cd t; ./perl harness ### for csh-style shells, like tcsh; or for traditional/modern ### Bourne-style shells, like bash, ksh, and zsh, respectively. Elapsed: 5258 sec u=65.39 s=22.30 cu=4439.46 cs=475.21 scripts=2225 tests=708155 *** Error code 1 Stop. I tried different versions, 5.20.3, 5.22 same results. Anyone any ideas ? I see there is perl installed under RPI2 /usr/local so it seems doable. This is what Im trying: sh Configure -Dprefix=/opt/kronometrix/perl -des Thanks, -- Stefan Parvu From owner-freebsd-arm@freebsd.org Wed Sep 30 09:24:42 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53361A0BAF6 for ; Wed, 30 Sep 2015 09:24:42 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E0BE91C9A for ; Wed, 30 Sep 2015 09:24:41 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by wicfx3 with SMTP id fx3so187534933wic.1 for ; Wed, 30 Sep 2015 02:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:cc:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=8Y9GxlvIHLUEuCqVzMSZ8ySe5OkyyjFK8fc/vhjEQp8=; b=IkLwPaZrhAmQe/WIAtvo0MAtF/JQrBD+SZxf+q78yalj2L6aBN9lpYG61uh+lOiXYm AK3Gtg7nSUZFO/7hA5okImFnDX8394Y69yWir2YBtxoJ20lMW92vubHoME/1Av1q+gwG /Y6PjFF1J+f72GtyzUMTCf10IY6caj9iZy3KSxSu93HcTnt+5AGPB3TC3QDoRZedgoeL zAWgDzYhDX8R9cHcIwdNI6lr0CICqXg0NVVaEqvCfP/la8hbG1kLtH02aGmvnr3Z5+1M swCzb66+dBEmxf1n7qOEZDSWUruNMyHcHxroqvnirDvRFUcIn47IG/zwM0SvMrgInkNO guLg== X-Received: by 10.195.11.40 with SMTP id ef8mr2854496wjd.103.1443605080271; Wed, 30 Sep 2015 02:24:40 -0700 (PDT) Received: from [192.168.1.131] (xdsl-205-163.nblnetworks.fi. [83.145.205.163]) by smtp.googlemail.com with ESMTPSA id jq10sm167033wjc.40.2015.09.30.02.24.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Sep 2015 02:24:39 -0700 (PDT) Subject: Re: compile perl on RPI2 failure in opbasic/arith.t References: <560BA953.8020702@kronometrix.org> Cc: freebsd-arm@freebsd.org To: Stefan Parvu From: Jukka Ukkonen Message-ID: <560BAA53.4090409@gmail.com> Date: Wed, 30 Sep 2015 12:24:35 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <560BA953.8020702@kronometrix.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 09:24:42 -0000 On 09/30/15 12:20, Stefan Parvu wrote: > Im not able to compile perl on RPI2 hardware, using cc. Make test always > breaks here: > > lib/vmsish .................................................... ok > lib/warnings .................................................. ok > Failed 1 test out of 2225, 99.96% okay. > opbasic/arith.t > ### Since not all tests were successful, you may want to run some of > ### them individually and examine any diagnostic messages they produce. > ### See the INSTALL document's section on "make test". > ### You have a good chance to get more information by running > ### ./perl harness > ### in the 't' directory since most (>=80%) of the tests succeeded. > ### You may have to set your dynamic library search path, > ### LD_LIBRARY_PATH, to point to the build directory: > ### setenv LD_LIBRARY_PATH `pwd`; cd t; ./perl harness > ### LD_LIBRARY_PATH=`pwd`; export LD_LIBRARY_PATH; cd t; ./perl harness > ### export LD_LIBRARY_PATH=`pwd`; cd t; ./perl harness > ### for csh-style shells, like tcsh; or for traditional/modern > ### Bourne-style shells, like bash, ksh, and zsh, respectively. > Elapsed: 5258 sec > u=65.39 s=22.30 cu=4439.46 cs=475.21 scripts=2225 tests=708155 > *** Error code 1 > > Stop. > > I tried different versions, 5.20.3, 5.22 same results. Anyone any > ideas ? I see there is perl installed under RPI2 /usr/local so it seems > doable. This is what Im trying: > > sh Configure -Dprefix=/opt/kronometrix/perl -des > > Thanks, > Have you tried installing perl 5.20 using the ports tree? --jau From owner-freebsd-arm@freebsd.org Wed Sep 30 09:26:00 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D68BA0BC93 for ; Wed, 30 Sep 2015 09:26:00 +0000 (UTC) (envelope-from sparvu@sdrdynamics.com) Received: from sdrdynamics.com (188-127-209-196.cust.suomicom.net [188.127.209.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.sdrdynamics.com", Issuer "mail.sdrdynamics.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 369811D34 for ; Wed, 30 Sep 2015 09:25:59 +0000 (UTC) (envelope-from sparvu@sdrdynamics.com) Received: from [192.168.1.171] ([192.168.1.171]) (authenticated bits=0) by sdrdynamics.com (8.14.9/8.14.9) with ESMTP id t8U9Eewb032327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 30 Sep 2015 12:14:40 +0300 (EEST) (envelope-from sparvu@sdrdynamics.com) Reply-To: sparvu@sdrdynamics.com From: Stefan Parvu X-Enigmail-Draft-Status: N1110 Organization: SDR Dynamics Oy To: "freebsd-arm@freebsd.org" Subject: compile perl on RPI2 failure in opbasic/arith.t Message-ID: <560BA800.3050705@sdrdynamics.com> Date: Wed, 30 Sep 2015 12:14:40 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 09:26:00 -0000 Im not able to compile perl on RPI2 hardware, using cc. Make test always breaks here: lib/vmsish .................................................... ok lib/warnings .................................................. ok Failed 1 test out of 2225, 99.96% okay. opbasic/arith.t ### Since not all tests were successful, you may want to run some of ### them individually and examine any diagnostic messages they produce. ### See the INSTALL document's section on "make test". ### You have a good chance to get more information by running ### ./perl harness ### in the 't' directory since most (>=80%) of the tests succeeded. ### You may have to set your dynamic library search path, ### LD_LIBRARY_PATH, to point to the build directory: ### setenv LD_LIBRARY_PATH `pwd`; cd t; ./perl harness ### LD_LIBRARY_PATH=`pwd`; export LD_LIBRARY_PATH; cd t; ./perl harness ### export LD_LIBRARY_PATH=`pwd`; cd t; ./perl harness ### for csh-style shells, like tcsh; or for traditional/modern ### Bourne-style shells, like bash, ksh, and zsh, respectively. Elapsed: 5258 sec u=65.39 s=22.30 cu=4439.46 cs=475.21 scripts=2225 tests=708155 *** Error code 1 Stop. I tried different versions, 5.20.3, 5.22 same results. Anyone any ideas ? I see there is perl installed under RPI2 /usr/local so it seems doable. This is what Im trying: sh Configure -Dprefix=/opt/kronometrix/perl -des -- Stefan Parvu From owner-freebsd-arm@freebsd.org Wed Sep 30 09:41:56 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21F8AA0AB59 for ; Wed, 30 Sep 2015 09:41:56 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [54.72.43.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AF85C14CE for ; Wed, 30 Sep 2015 09:41:54 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from [192.168.1.171] (188-127-209-196.cust.suomicom.net [188.127.209.196]) (authenticated bits=0) by mail.kronometrix.org (8.14.9/8.14.9) with ESMTP id t8U9fqwm073342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 30 Sep 2015 09:41:52 GMT (envelope-from sparvu@kronometrix.org) Reply-To: sparvu@kronometrix.org Subject: Re: compile perl on RPI2 failure in opbasic/arith.t References: <560BA953.8020702@kronometrix.org> <560BAA53.4090409@gmail.com> From: Stefan Parvu X-Enigmail-Draft-Status: N1110 Organization: kronometrix.org To: freebsd-arm@freebsd.org Message-ID: <560BAE5B.5030305@kronometrix.org> Date: Wed, 30 Sep 2015 12:41:47 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <560BAA53.4090409@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 09:41:56 -0000 > Have you tried installing perl 5.20 using the ports tree? nope. We are shipping our own Perl distro + modules for KDR (Kronometrix Data Recording pkg) as described here: http://www.kronometrix.org/man/faq.html "Another important reason was customer's environment, for example in the financial and banking sector. Usually such customers do not allow easily to add or install certain Perl5 modules on top of the operating system. Even more they have very strong requirements what operating system packages they manage. In early times, Kronometrix was around 400KB in size. After approaching large bank customers we needed to re-tink and adopt another mechanism to deploy Kronometrix in such networks." I could look to see whats cooking in ports for perl, sure. Perl5 compiles nicely on raspbian, should be as well on FreeBSD. Something probable about default configuration options passed during Configure -- Stefan Parvu From owner-freebsd-arm@freebsd.org Wed Sep 30 09:58:45 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B654A0B7A2 for ; Wed, 30 Sep 2015 09:58:45 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 BC1C11D08; Wed, 30 Sep 2015 09:58:44 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from chamsa.cs.huji.ac.il ([132.65.80.19]) by kabab.cs.huji.ac.il with esmtp id 1ZhE9h-000EYY-FC; Wed, 30 Sep 2015 12:58:33 +0300 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: netboot configuration [was: Re: NFS Root with Raspberry Pi (nfs_diskless: no interface)] From: Daniel Braniss In-Reply-To: <7DBAE39E-55B2-4685-9C5E-2933B1DDFEF4@cs.huji.ac.il> Date: Wed, 30 Sep 2015 12:58:33 +0300 Cc: freebsd-arm@freebsd.org Message-Id: References: <20150922052522.GA62140@gmail.com> <00C49FEB-E8EF-4469-85E2-0F901215CD11@cs.huji.ac.il> <20150923050414.GB43653@gmail.com> <91AAC64E-4C38-47AA-8910-48F7654A7524@cs.huji.ac.il> <20150923174445.GE43653@gmail.com> <1443105426.1224.272.camel@freebsd.org> <20150924163658.GC32257@gmail.com> <560438C5.3090404@selasky.org> <1443142468.1224.322.camel@freebsd.org> <1443209159.1224.361.camel@freebsd.org> <12C96F79-2D70-408D-AD4C-F06F6B909AD3@cs.huji.ac.il> <1443276119.1224.382.camel@freebsd.org> <33EFE756-B428-4A72-B3C5-0E764FA8ACC6@cs.huji.ac.il> <1443370490.1224.392.camel@freebsd.org> <1443371712.1224.398.camel@freebsd.org> <1443542714.1224.445.camel@freebsd.org> <7DBAE39E-55B2-4685-9C5E-2933B1DDFEF4@cs.huji.ac.il> To: Ian Lepore X-Mailer: Apple Mail (2.2104) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 09:58:45 -0000 last resort, check hardware so I took a brand new rpi, same problems. i saw many gpio0: stray interrupts, so I changed power supply, BINGO! it now works! thanks all for your patience. cheers, danny > On 30 Sep 2015, at 10:39, Daniel Braniss wrote: >=20 >>=20 >> On 29 Sep 2015, at 19:05, Ian Lepore wrote: >>=20 >> On Tue, 2015-09-29 at 12:24 +0300, Daniel Braniss wrote: >>>> On 27 Sep 2015, at 19:35, Ian Lepore wrote: >>>>=20 >>>> On Sun, 2015-09-27 at 19:25 +0300, Daniel Braniss wrote: >>>>>> On Sep 27, 2015, at 7:14 PM, Ian Lepore wrote: >>>>>>=20 >>>>>> On Sun, 2015-09-27 at 14:15 +0300, Daniel Braniss wrote: >>>> [...] >>>>>>> I compiled the u-boot-rpi from ports, >>>>>>> the good news: >>>>>>> it understands UserPreboot >>>>>>> the bad news: >>>>>>> the nfs boot gets stuck after a while. >>>>>>>=20 >>>>>>> after much trial and error, this is what I do: >>>>>>> hit a key to enter U-Boot >>>>>>> then type: >>>>>>> setenv loaderdev net >>>>>>> boot >>>>>>>=20 >>>>>>> attaching the console: >>>>>>=20 >>>>>> I was also experiencing intermittant lockups while loader loads = the >>>>>> kernel. I just wrote it off to failing hardware (I powered my = rpi on >>>>>> for the first time in 6-8 months to work on this), since I've = never had >>>>>> a problem with netbooting before (it's the only way I've ever = booted the >>>>>> rpi). If it's not just my board going bad, then that's a bit of = a >>>>>> mystery. The only other difference here from what I've always = done is >>>>>> setting rootpath and other net config in u-boot instead of = letting ubldr >>>>>> get it from dhcp. >>>>>=20 >>>>> with the stuff from crochet it works, same setup! I am sniffing = the net via >>>>> wireshark, and it stops at different positions in the kernel file, >>>>> so the settings of rootpath and other configs are irrelevant. >>>>> the transfer is being done via udp/nfs/v3 (hence added ric :-) = maybe >>>>> he can see something we don=C2=B4t. >>>>=20 >>>> Hmmm. What stuff from crochet? The two components that are in = play >>>> here are u-boot itself (it contains the low-level network drivers = that >>>> ubldr uses -- it's effectively acting as a bios for ubldr), and = ubldr >>>> which contains the higher-level network code. >>>>=20 >>>> In theory ubldr should be the same in both cases; nothing much has >>>> changed in the loader code for months. But there are different = paths >>>> through the code depending on how it gets the network parms, and I = could >>>> easily have glitched something when I added the feature that lets = you >>>> set the config with u-boot env vars. >>>>=20 >>>> The u-boot might be different between a crochet and ports build. = They >>>> both start with gonzo's u-boot 2013.10 sources, but crochet = probably has >>>> a slightly different set of patches it applies. >>>>=20 >>>> -- Ian >>>>=20 >>>=20 >>> with the old uboot it boots ok, with the newer/modified it stops at = random >>> places reading via udp/nfs/v3 the kernel. it loads correctly all the = *.4th files, >>> then starts reading the kernel, and hangs after a random time. >>>=20 >>=20 >> I have found that if I let u-boot get an ip address via dhcp then the >> load of the kernel in ubldr never fails (I've had it reboot-looping = for >> 24 hours now without a hang). But without letting u-boot do the dhcp >> thing it hangs pretty much every time. Substituting a ping = >> for the dhcp isn't enough to make it reliable. >>=20 >> I've stopped debugging that whole mess for now to have a quick check >> whether the very latest mainline u-boot (2015.10-rc4) is able to >> netboot. It sure would be nice to use something modern that has = already >> been debugged by others. :) >=20 > there is definitely an issue with the net driver in the newer/ports = u-boot. > - tftpboot sometimes works :-) > - same with nfs > =09 > via dhcp: > it should not try tftp load filename if none is supplied, i.e. = defaulting to > .img is wrong! >=20 > i got ubldr loaded via tftp and then bootelf got it running. > the loaded kernel complained: > No valid device tree blob found! > I guess some of the environmet variables got lost >=20 > my network is quiet busy, may be thats a factor? > =09 >>=20 >>> on another issue, if I type dhcp instead of boot, it loads via TFTP = filename, >>> which I set to ubldr/ubldr.bin, it loads and now prompts again, >>> what should the command be? I tried go 0, go 20000, in which case = execs >>> the old ubldr :-( >>>=20 >>=20 >> The old ubldr had to be launched using 'bootelf', the new ubldr.bin = has >> to be launched using "go ${loadaddr}". While we transition from old = to >> new I've been using "dhcp && bootelf || go ${loadaddr}" = -- >> if it's ubldr the bootelf command works; if bootelf fails it fails = back >> to using go. >>=20 >> -- Ian >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm = > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org = " From owner-freebsd-arm@freebsd.org Wed Sep 30 10:05:36 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F1B4A0BC73 for ; Wed, 30 Sep 2015 10:05:36 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 4A0151070; Wed, 30 Sep 2015 10:05:35 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from chamsa.cs.huji.ac.il ([132.65.80.19]) by kabab.cs.huji.ac.il with esmtp id 1ZhEGT-000Ejs-L6; Wed, 30 Sep 2015 13:05:33 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: netboot configuration [was: Re: NFS Root with Raspberry Pi (nfs_diskless: no interface)] From: Daniel Braniss In-Reply-To: Date: Wed, 30 Sep 2015 13:05:33 +0300 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2E1482CA-AD21-4EAC-9BE5-DB9F9468CC86@cs.huji.ac.il> References: <20150922052522.GA62140@gmail.com> <00C49FEB-E8EF-4469-85E2-0F901215CD11@cs.huji.ac.il> <20150923050414.GB43653@gmail.com> <91AAC64E-4C38-47AA-8910-48F7654A7524@cs.huji.ac.il> <20150923174445.GE43653@gmail.com> <1443105426.1224.272.camel@freebsd.org> <20150924163658.GC32257@gmail.com> <560438C5.3090404@selasky.org> <1443142468.1224.322.camel@freebsd.org> <1443209159.1224.361.camel@freebsd.org> <12C96F79-2D70-408D-AD4C-F06F6B909AD3@cs.huji.ac.il> <1443276119.1224.382.camel@freebsd.org> <33EFE756-B428-4A72-B3C5-0E764FA8ACC6@cs.huji.ac.il> <1443370490.1224.392.camel@freebsd.org> <1443371712.1224.398.camel@freebsd.org> <1443542714.1224.445.camel@freebsd.org> <7DBAE39E-55B2-4685-9C5E-2933B1DDFEF4@cs.huji.ac.il> To: Ian Lepore X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 10:05:36 -0000 > On 30 Sep 2015, at 12:58, Daniel Braniss wrote: >=20 > last resort, check hardware >=20 > so I took a brand new rpi, same problems. > i saw many gpio0: stray interrupts, so I changed power supply, BINGO! spoken too fast :-( back to old problems. > it now works! > thanks all for your patience. > cheers, > danny >=20 >> On 30 Sep 2015, at 10:39, Daniel Braniss wrote: >>=20 >>>=20 >>> On 29 Sep 2015, at 19:05, Ian Lepore wrote: >>>=20 >>> On Tue, 2015-09-29 at 12:24 +0300, Daniel Braniss wrote: >>>>> On 27 Sep 2015, at 19:35, Ian Lepore wrote: >>>>>=20 >>>>> On Sun, 2015-09-27 at 19:25 +0300, Daniel Braniss wrote: >>>>>>> On Sep 27, 2015, at 7:14 PM, Ian Lepore wrote: >>>>>>>=20 >>>>>>> On Sun, 2015-09-27 at 14:15 +0300, Daniel Braniss wrote: >>>>> [...] >>>>>>>> I compiled the u-boot-rpi from ports, >>>>>>>> the good news: >>>>>>>> it understands UserPreboot >>>>>>>> the bad news: >>>>>>>> the nfs boot gets stuck after a while. >>>>>>>>=20 >>>>>>>> after much trial and error, this is what I do: >>>>>>>> hit a key to enter U-Boot >>>>>>>> then type: >>>>>>>> setenv loaderdev net >>>>>>>> boot >>>>>>>>=20 >>>>>>>> attaching the console: >>>>>>>=20 >>>>>>> I was also experiencing intermittant lockups while loader loads = the >>>>>>> kernel. I just wrote it off to failing hardware (I powered my = rpi on >>>>>>> for the first time in 6-8 months to work on this), since I've = never had >>>>>>> a problem with netbooting before (it's the only way I've ever = booted the >>>>>>> rpi). If it's not just my board going bad, then that's a bit of = a >>>>>>> mystery. The only other difference here from what I've always = done is >>>>>>> setting rootpath and other net config in u-boot instead of = letting ubldr >>>>>>> get it from dhcp. >>>>>>=20 >>>>>> with the stuff from crochet it works, same setup! I am sniffing = the net via >>>>>> wireshark, and it stops at different positions in the kernel = file, >>>>>> so the settings of rootpath and other configs are irrelevant. >>>>>> the transfer is being done via udp/nfs/v3 (hence added ric :-) = maybe >>>>>> he can see something we don=C2=B4t. >>>>>=20 >>>>> Hmmm. What stuff from crochet? The two components that are in = play >>>>> here are u-boot itself (it contains the low-level network drivers = that >>>>> ubldr uses -- it's effectively acting as a bios for ubldr), and = ubldr >>>>> which contains the higher-level network code. >>>>>=20 >>>>> In theory ubldr should be the same in both cases; nothing much has >>>>> changed in the loader code for months. But there are different = paths >>>>> through the code depending on how it gets the network parms, and I = could >>>>> easily have glitched something when I added the feature that lets = you >>>>> set the config with u-boot env vars. >>>>>=20 >>>>> The u-boot might be different between a crochet and ports build. = They >>>>> both start with gonzo's u-boot 2013.10 sources, but crochet = probably has >>>>> a slightly different set of patches it applies. >>>>>=20 >>>>> -- Ian >>>>>=20 >>>>=20 >>>> with the old uboot it boots ok, with the newer/modified it stops at = random >>>> places reading via udp/nfs/v3 the kernel. it loads correctly all = the *.4th files, >>>> then starts reading the kernel, and hangs after a random time. >>>>=20 >>>=20 >>> I have found that if I let u-boot get an ip address via dhcp then = the >>> load of the kernel in ubldr never fails (I've had it reboot-looping = for >>> 24 hours now without a hang). But without letting u-boot do the = dhcp >>> thing it hangs pretty much every time. Substituting a ping = >>> for the dhcp isn't enough to make it reliable. >>>=20 >>> I've stopped debugging that whole mess for now to have a quick check >>> whether the very latest mainline u-boot (2015.10-rc4) is able to >>> netboot. It sure would be nice to use something modern that has = already >>> been debugged by others. :) >>=20 >> there is definitely an issue with the net driver in the newer/ports = u-boot. >> - tftpboot sometimes works :-) >> - same with nfs >> =09 >> via dhcp: >> it should not try tftp load filename if none is supplied, i.e. = defaulting to >> .img is wrong! >>=20 >> i got ubldr loaded via tftp and then bootelf got it running. >> the loaded kernel complained: >> No valid device tree blob found! >> I guess some of the environmet variables got lost >>=20 >> my network is quiet busy, may be thats a factor? >> =09 >>>=20 >>>> on another issue, if I type dhcp instead of boot, it loads via TFTP = filename, >>>> which I set to ubldr/ubldr.bin, it loads and now prompts again, >>>> what should the command be? I tried go 0, go 20000, in which case = execs >>>> the old ubldr :-( >>>>=20 >>>=20 >>> The old ubldr had to be launched using 'bootelf', the new ubldr.bin = has >>> to be launched using "go ${loadaddr}". While we transition from old = to >>> new I've been using "dhcp && bootelf || go ${loadaddr}" = -- >>> if it's ubldr the bootelf command works; if bootelf fails it fails = back >>> to using go. >>>=20 >>> -- Ian >>=20 >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm = >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org = " >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Wed Sep 30 13:13:44 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 002ECA0CA1B for ; Wed, 30 Sep 2015 13:13:44 +0000 (UTC) (envelope-from meloun@miracle.cz) Received: from mail.miracle.cz (mail.miracle.cz [193.84.128.19]) by mx1.freebsd.org (Postfix) with ESMTP id 7B3AC1220 for ; Wed, 30 Sep 2015 13:13:42 +0000 (UTC) (envelope-from meloun@miracle.cz) Received: from [193.84.128.50] (meloun.ad.miracle.cz [193.84.128.50]) by mail.miracle.cz (Postfix) with ESMTPSA id 275B4ACAD36 for ; Wed, 30 Sep 2015 15:05:12 +0200 (CEST) From: Michal Meloun Subject: Re: Shared page and related goodies for ARMv7 To: freebsd-arm@freebsd.org References: <20150929132332.GH11284@kib.kiev.ua> <1443539982.1224.433.camel@freebsd.org> <20150929162312.GJ11284@kib.kiev.ua> Organization: Miracle Group Message-ID: <560BDE08.4010405@miracle.cz> Date: Wed, 30 Sep 2015 15:05:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150929162312.GJ11284@kib.kiev.ua> 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.4.3 (mail.miracle.cz); Wed, 30 Sep 2015 15:05:12 +0200 (CEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 13:13:44 -0000 Dne 29.09.2015 v 18:23 Konstantin Belousov napsal(a): > On Tue, Sep 29, 2015 at 09:19:42AM -0600, Ian Lepore wrote: >> I can't do anything with an inline email patch (my mail client destroys >> whitespace). Can you send it as an attachment, or put it somewhere on >> freefall or something please? > I just committed the .note.GNU-stack bits, reviewed by andrew. This > reduces the noise in the patch, the rest is available at > https://people.freebsd.org/~kib/misc/arm_sharedpage.1.patch > >> >> There is no difference between armv6 and armv7 in our world. The only >> armv6 chip we support is the one used in the original rpi and it has a >> 16K 4-way L1 cache which means the page coloring issue disappears and we >> can treat it the same as an armv7 chip (different cache ops, but the >> caches behave the same). > Olivier just told me the same, I already changed the elf_machdep.c patch > to enable shared page for ARMv6 and later. > I like to have not-executable stack and signal trampoline on shared page, definitively. Can you, please, move timer related code to another patch? Ian, do you have any objection to this part? I only want to clarify "usage" rules for multiple mappings of physical page/range: - all aliases must use same memory type - all aliases must use same cache attributes in other words, only privileges can vary. Also on ARM, devices must be mapped using "device" memory type. >> >> I just skimmed through the patch quickly and the main thing that jumps >> out at me is that what you've done works only on rpi2 and aarch64, >> because those are the only platforms that support that timer hardware. >> (That means I can't test it, but once I get your patch in a usable form >> I can have a shot at implementations for other timers). > Cortex A7/A15 and whole ARMv8 is not too bad set of machines for fast > gettimeofday() IMO, at least for the first try. I am willing to adjust > both approach and code it for wider usefulness. > >> >> It's not clear to me that this scheme can even work on most armv7 >> hardware because of the timer hardware involved. I think it would mean >> giving userland read access to a whole page worth of IO space and in >> some cases there are registers in that range where reads have side >> effects whose consequences could be dire (such as pending-interrupt >> registers). > Yes, if timer counter is on the page shared with other registers, which > read side effects are not safe, it cannot be used. But I do not see how > such hardware could be useful for any syscall-less implementation of > gettimeofday(), except for very imprecise one, where counter is written > to the shared page on timer interrupt. I do not think that we want > such hack done. > > On x86, HPET timers have relatively sane design, the registers page can > be exported to userspace r/o without consequences. Exporting HPET to > userspace even could be useful on Core2 (old) machines where RDTSC is > unusable. HPET could be made a test bed for this kind of hardware, but > the interest is low and I did not coded neccessary infrastructure as > result. I don't thing that infecting user mode binaries by underlining hardware details is best choice. Moreover, I know at least 7 different timers implementation on ARMv6 and ARMv7. So we must be very flexible in this area. For example, we can do that like in signal trampoline case. A timer driver can inject its own user mode code to shared page for reading timecounter value. With fallback to syscall, of course. Michal Meloun From owner-freebsd-arm@freebsd.org Thu Oct 1 04:42:55 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6445A0C6C9 for ; Thu, 1 Oct 2015 04:42:55 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [54.72.43.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E92412AB for ; Thu, 1 Oct 2015 04:42:55 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from [192.168.1.171] (89-27-2-202.bb.dnainternet.fi [89.27.2.202]) (authenticated bits=0) by mail.kronometrix.org (8.14.9/8.14.9) with ESMTP id t914gqv6082681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 1 Oct 2015 04:42:52 GMT (envelope-from sparvu@kronometrix.org) Reply-To: sparvu@kronometrix.org Subject: Re: compile perl on RPI2 failure in opbasic/arith.t References: <560BA953.8020702@kronometrix.org> <560BAA53.4090409@gmail.com> <560BAE5B.5030305@kronometrix.org> To: freebsd-arm@freebsd.org From: Stefan Parvu X-Enigmail-Draft-Status: N1110 Organization: kronometrix.org Message-ID: <560CB9C6.5080900@kronometrix.org> Date: Thu, 1 Oct 2015 07:42:46 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <560BAE5B.5030305@kronometrix.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 04:42:56 -0000 Always make test fails here: $ ./TEST opbasic/arith.t t/opbasic/arith ... FAILED at test 175 Failed 1 test out of 1, 0.00% okay. opbasic/arith.t ### Since not all tests were successful, you may want to run some of ### them individually and examine any diagnostic messages they produce. ### See the INSTALL document's section on "make test". ### You may have to set your dynamic library search path, ### LD_LIBRARY_PATH, to point to the build directory: ### setenv LD_LIBRARY_PATH `pwd`; cd t; ./perl harness ### LD_LIBRARY_PATH=`pwd`; export LD_LIBRARY_PATH; cd t; ./perl harness ### export LD_LIBRARY_PATH=`pwd`; cd t; ./perl harness ### for csh-style shells, like tcsh; or for traditional/modern ### Bourne-style shells, like bash, ksh, and zsh, respectively. Elapsed: 0 sec u=0.18 s=0.02 cu=0.16 cs=0.04 scripts=1 tests=186 $ Something to do with floating point calculations on RBPi ? -- Stefan Parvu From owner-freebsd-arm@freebsd.org Thu Oct 1 08:45:12 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78D59A0C63C for ; Thu, 1 Oct 2015 08:45:12 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [54.72.43.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1374B1648 for ; Thu, 1 Oct 2015 08:45:11 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from [192.168.1.171] (188-127-209-196.cust.suomicom.net [188.127.209.196]) (authenticated bits=0) by mail.kronometrix.org (8.14.9/8.14.9) with ESMTP id t918j8OZ084711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 1 Oct 2015 08:45:09 GMT (envelope-from sparvu@kronometrix.org) Reply-To: sparvu@kronometrix.org To: "freebsd-arm@freebsd.org" From: Stefan Parvu Subject: compile kernel with hard float support X-Enigmail-Draft-Status: N1110 Organization: kronometrix.org Message-ID: <560CF28F.4000908@kronometrix.org> Date: Thu, 1 Oct 2015 11:45:03 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 08:45:12 -0000 I understood, by default, the image FreeBSD-armv6-11.0-RPI2-286947.img.gz has soft float support. All float-point operations are done in software not using the ARM hardware VFP. Correct ? If I want to build FreeBSD 11 with hard float support can I do this already ? Do we support hard float ? And how should I compile things ? # setenv ARCH armv6hf (is this correct ?) # make buildkernel KERNCONF=RPI2 Thanks, [1] http://download.raspbsd.org/FreeBSD-armv6-11.0-RPI2-286947.img.gz -- Stefan Parvu From owner-freebsd-arm@freebsd.org Thu Oct 1 08:54:23 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCF38A0CFAD for ; Thu, 1 Oct 2015 08:54:22 +0000 (UTC) (envelope-from pkhavkine@gmail.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA41F1C9F for ; Thu, 1 Oct 2015 08:54:22 +0000 (UTC) (envelope-from pkhavkine@gmail.com) Received: by ioiz6 with SMTP id z6so77414955ioi.2 for ; Thu, 01 Oct 2015 01:54:22 -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=YQa/GY68pVGmPHnZnxG2cVHsYKQBPNyGFrBcGHkVRtE=; b=DEisenmJceYYk2limsi/zstix2dqYss+bjMv08O2oNjYesDqUUV8e05plmd0nkGIeO v4NteRa/bVd5eXhKPf/awbCBwR3tVhOIhmgIlvvOkXCNoBCSHjGFLMFjDjwqSI50J2MC kSuh7AGpGCfoukQ1iKSb4TcvN9EnW9Aa53Ptu9U2Gftr5zGILEddffC9NyUsSIiPeVvO 7LjroW3z5rlIBkf4WgUcLMdTgzzIp732Gij00P5HQybQC3/uB6Hl3ikrmIi3hh97f7yz pozpbh/AJMSjJgEbW2MTZAoJmUwiTpmrUgX3CH6diA3EOXbsI3bnVvhsuPY96M73I3KB 8Bxw== MIME-Version: 1.0 X-Received: by 10.107.47.221 with SMTP id v90mr9329374iov.185.1443689661983; Thu, 01 Oct 2015 01:54:21 -0700 (PDT) Received: by 10.107.12.158 with HTTP; Thu, 1 Oct 2015 01:54:21 -0700 (PDT) In-Reply-To: <560CF28F.4000908@kronometrix.org> References: <560CF28F.4000908@kronometrix.org> Date: Thu, 1 Oct 2015 04:54:21 -0400 Message-ID: Subject: Re: compile kernel with hard float support From: Paul Khavkine To: sparvu@kronometrix.org Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 08:54:23 -0000 Hi Stefan. I have done it a couple weeks ago. Building and running armv6hf works. On Thu, Oct 1, 2015 at 4:45 AM, Stefan Parvu wrote: > > I understood, by default, the image > FreeBSD-armv6-11.0-RPI2-286947.img.gz has soft float support. All > float-point operations are done in software not using the ARM hardware > VFP. Correct ? > > If I want to build FreeBSD 11 with hard float support can I do this > already ? Do we support hard float ? And how should I compile things ? > > # setenv ARCH armv6hf (is this correct ?) > # make buildkernel KERNCONF=RPI2 > > Thanks, > > > [1] http://download.raspbsd.org/FreeBSD-armv6-11.0-RPI2-286947.img.gz > > -- > Stefan Parvu > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Thu Oct 1 08:59:59 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55894A0D368 for ; Thu, 1 Oct 2015 08:59:59 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [54.72.43.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C847E1DFD for ; Thu, 1 Oct 2015 08:59:58 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from [192.168.1.171] (188-127-209-196.cust.suomicom.net [188.127.209.196]) (authenticated bits=0) by mail.kronometrix.org (8.14.9/8.14.9) with ESMTP id t918xt14084838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 1 Oct 2015 08:59:56 GMT (envelope-from sparvu@kronometrix.org) Reply-To: sparvu@kronometrix.org Subject: Re: compile kernel with hard float support References: <560CF28F.4000908@kronometrix.org> To: "freebsd-arm@freebsd.org" From: Stefan Parvu Organization: kronometrix.org Message-ID: <560CF606.7000701@kronometrix.org> Date: Thu, 1 Oct 2015 11:59:50 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 08:59:59 -0000 > I have done it a couple weeks ago. > Building and running armv6hf works. I will build the kernel with hard float to see if perl make tests still breaks. Im trying to explain another issue: https://goo.gl/9JxVsE by this. Lets see. Thanks, -- Stefan Parvu From owner-freebsd-arm@freebsd.org Thu Oct 1 09:24:40 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E767AA0B775 for ; Thu, 1 Oct 2015 09:24:40 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [54.72.43.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 80B7C1B38 for ; Thu, 1 Oct 2015 09:24:39 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from [192.168.1.171] (188-127-209-196.cust.suomicom.net [188.127.209.196]) (authenticated bits=0) by mail.kronometrix.org (8.14.9/8.14.9) with ESMTP id t919OVcb085046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 1 Oct 2015 09:24:31 GMT (envelope-from sparvu@kronometrix.org) Reply-To: sparvu@kronometrix.org Subject: Re: compile kernel with hard float support References: <560CF28F.4000908@kronometrix.org> <20151001101825.44341b74@bender> To: Andrew Turner Cc: "freebsd-arm@freebsd.org" From: Stefan Parvu Organization: kronometrix.org Message-ID: <560CFBCA.5010001@kronometrix.org> Date: Thu, 1 Oct 2015 12:24:26 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151001101825.44341b74@bender> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 09:24:41 -0000 > No, armv6 is built with softfp. This means the compiler is free to use > the VFP, but when passing floating-point data between functions it > needs to copy this to the general-purpose registers. > > Even without this the helper functions detect the presence of the VFP > unit and make use of this when available. right. Got it. Thanks for explanation. > The kernel doesn't use any floating-point hardware, other than to > enable and disable it in the VFP driver. As such it doesn't matter if > you've built the kernel for hard-float or not, it will make no > difference to the code generated. ok, I see. Ok this probable wont make any difference to my case. Right. 10 x thanks. -- Stefan Parvu From owner-freebsd-arm@freebsd.org Thu Oct 1 09:25:24 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14C47A0B7D2 for ; Thu, 1 Oct 2015 09:25:24 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from kif.fubar.geek.nz (kif.fubar.geek.nz [178.62.119.249]) by mx1.freebsd.org (Postfix) with ESMTP id D9DFE1BCA for ; Thu, 1 Oct 2015 09:25:23 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from bender (unknown [193.12.234.196]) by kif.fubar.geek.nz (Postfix) with ESMTPSA id EFBB8D7A21; Thu, 1 Oct 2015 09:18:26 +0000 (UTC) Date: Thu, 1 Oct 2015 10:18:25 +0100 From: Andrew Turner To: Stefan Parvu Cc: "freebsd-arm@freebsd.org" Subject: Re: compile kernel with hard float support Message-ID: <20151001101825.44341b74@bender> In-Reply-To: <560CF28F.4000908@kronometrix.org> References: <560CF28F.4000908@kronometrix.org> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; amd64-portbld-freebsd10.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 09:25:24 -0000 On Thu, 1 Oct 2015 11:45:03 +0300 Stefan Parvu wrote: > > I understood, by default, the image > FreeBSD-armv6-11.0-RPI2-286947.img.gz has soft float support. All > float-point operations are done in software not using the ARM hardware > VFP. Correct ? No, armv6 is built with softfp. This means the compiler is free to use the VFP, but when passing floating-point data between functions it needs to copy this to the general-purpose registers. Even without this the helper functions detect the presence of the VFP unit and make use of this when available. > > If I want to build FreeBSD 11 with hard float support can I do this > already ? Do we support hard float ? And how should I compile things ? > > # setenv ARCH armv6hf (is this correct ?) > # make buildkernel KERNCONF=RPI2 The kernel doesn't use any floating-point hardware, other than to enable and disable it in the VFP driver. As such it doesn't matter if you've built the kernel for hard-float or not, it will make no difference to the code generated. Andrew From owner-freebsd-arm@freebsd.org Thu Oct 1 09:35:57 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09AAEA0C189 for ; Thu, 1 Oct 2015 09:35:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78D441173 for ; Thu, 1 Oct 2015 09:35:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t919Zonx078024 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 1 Oct 2015 12:35:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t919Zonx078024 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t919Zo2U078022; Thu, 1 Oct 2015 12:35:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 1 Oct 2015 12:35:50 +0300 From: Konstantin Belousov To: Stefan Parvu Cc: Andrew Turner , "freebsd-arm@freebsd.org" Subject: Re: compile kernel with hard float support Message-ID: <20151001093550.GQ11284@kib.kiev.ua> References: <560CF28F.4000908@kronometrix.org> <20151001101825.44341b74@bender> <560CFBCA.5010001@kronometrix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <560CFBCA.5010001@kronometrix.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 09:35:57 -0000 On Thu, Oct 01, 2015 at 12:24:26PM +0300, Stefan Parvu wrote: > > > No, armv6 is built with softfp. This means the compiler is free to use > > the VFP, but when passing floating-point data between functions it > > needs to copy this to the general-purpose registers. > > > > Even without this the helper functions detect the presence of the VFP > > unit and make use of this when available. > > right. Got it. Thanks for explanation. > > > > The kernel doesn't use any floating-point hardware, other than to > > enable and disable it in the VFP driver. As such it doesn't matter if > > you've built the kernel for hard-float or not, it will make no > > difference to the code generated. > > ok, I see. Ok this probable wont make any difference to my case. > Right. 10 x thanks. The issue, apparently, in the initialization of the VFS state. I do not quite understand why ARM is set to flush to zero. Both C and IEEE FP standard expect that denormals work. The following patch worked for me WRT perl t/opbasic/arith.t test 175 (perl git blead checkout). diff --git a/sys/arm/arm/vm_machdep.c b/sys/arm/arm/vm_machdep.c index 223ad96..895a14c 100644 --- a/sys/arm/arm/vm_machdep.c +++ b/sys/arm/arm/vm_machdep.c @@ -134,7 +134,7 @@ cpu_fork(register struct thread *td1, register struct proc *p2, pcb2->pcb_regs.sf_sp = STACKALIGN(td2->td_frame); pcb2->pcb_vfpcpu = -1; - pcb2->pcb_vfpstate.fpscr = VFPSCR_DN | VFPSCR_FZ; + pcb2->pcb_vfpstate.fpscr = VFPSCR_DN; tf = td2->td_frame; tf->tf_spsr &= ~PSR_C; From owner-freebsd-arm@freebsd.org Thu Oct 1 09:56:04 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78135A0D796 for ; Thu, 1 Oct 2015 09:56:04 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [54.72.43.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0FF5E1594 for ; Thu, 1 Oct 2015 09:56:03 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from [192.168.1.171] (188-127-209-196.cust.suomicom.net [188.127.209.196]) (authenticated bits=0) by mail.kronometrix.org (8.14.9/8.14.9) with ESMTP id t919u0bE085290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 1 Oct 2015 09:56:01 GMT (envelope-from sparvu@kronometrix.org) Reply-To: sparvu@kronometrix.org Subject: Re: compile kernel with hard float support References: <560CF28F.4000908@kronometrix.org> <20151001101825.44341b74@bender> <560CFBCA.5010001@kronometrix.org> <20151001093550.GQ11284@kib.kiev.ua> To: Konstantin Belousov Cc: Andrew Turner , "freebsd-arm@freebsd.org" From: Stefan Parvu Organization: kronometrix.org Message-ID: <560D032B.7030903@kronometrix.org> Date: Thu, 1 Oct 2015 12:55:55 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151001093550.GQ11284@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 09:56:04 -0000 > The following patch worked for me WRT perl t/opbasic/arith.t test 175 > (perl git blead checkout). > > diff --git a/sys/arm/arm/vm_machdep.c b/sys/arm/arm/vm_machdep.c > index 223ad96..895a14c 100644 > --- a/sys/arm/arm/vm_machdep.c > +++ b/sys/arm/arm/vm_machdep.c > @@ -134,7 +134,7 @@ cpu_fork(register struct thread *td1, register struct proc *p2, > pcb2->pcb_regs.sf_sp = STACKALIGN(td2->td_frame); > > pcb2->pcb_vfpcpu = -1; > - pcb2->pcb_vfpstate.fpscr = VFPSCR_DN | VFPSCR_FZ; > + pcb2->pcb_vfpstate.fpscr = VFPSCR_DN; > > tf = td2->td_frame; > tf->tf_spsr &= ~PSR_C; many thanks. I will try the patch. -- Stefan Parvu From owner-freebsd-arm@freebsd.org Thu Oct 1 16:24:52 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91A59A0D20D for ; Thu, 1 Oct 2015 16:24:52 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C79A1C84 for ; Thu, 1 Oct 2015 16:24:52 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Thu, 1 Oct 2015 16:23:14 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t91GOgZZ018701; Thu, 1 Oct 2015 10:24:42 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1443716682.66572.29.camel@freebsd.org> Subject: Re: netboot configuration [was: Re: NFS Root with Raspberry Pi (nfs_diskless: no interface)] From: Ian Lepore To: Daniel Braniss Cc: freebsd-arm@freebsd.org Date: Thu, 01 Oct 2015 10:24:42 -0600 In-Reply-To: <7DBAE39E-55B2-4685-9C5E-2933B1DDFEF4@cs.huji.ac.il> References: <20150922052522.GA62140@gmail.com> <00C49FEB-E8EF-4469-85E2-0F901215CD11@cs.huji.ac.il> <20150923050414.GB43653@gmail.com> <91AAC64E-4C38-47AA-8910-48F7654A7524@cs.huji.ac.il> <20150923174445.GE43653@gmail.com> <1443105426.1224.272.camel@freebsd.org> <20150924163658.GC32257@gmail.com> <560438C5.3090404@selasky.org> <1443142468.1224.322.camel@freebsd.org> <1443209159.1224.361.camel@freebsd.org> <12C96F79-2D70-408D-AD4C-F06F6B909AD3@cs.huji.ac.il> <1443276119.1224.382.camel@freebsd.org> <33EFE756-B428-4A72-B3C5-0E764FA8ACC6@cs.huji.ac.il> <1443370490.1224.392.camel@freebsd.org> <1443371712.1224.398.camel@freebsd.org> <1443542714.1224.445.camel@freebsd.org> <7DBAE39E-55B2-4685-9C5E-2933B1DDFEF4@cs.huji.ac.il> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 16:24:52 -0000 On Wed, 2015-09-30 at 10:39 +0300, Daniel Braniss wrote: > > On 29 Sep 2015, at 19:05, Ian Lepore wrote: > > > > On Tue, 2015-09-29 at 12:24 +0300, Daniel Braniss wrote: > >>> On 27 Sep 2015, at 19:35, Ian Lepore wrote: > >>> > >>> On Sun, 2015-09-27 at 19:25 +0300, Daniel Braniss wrote: > >>>>> On Sep 27, 2015, at 7:14 PM, Ian Lepore wrote: > >>>>> > >>>>> On Sun, 2015-09-27 at 14:15 +0300, Daniel Braniss wrote: > >>> [...] > >>>>>> I compiled the u-boot-rpi from ports, > >>>>>> the good news: > >>>>>> it understands UserPreboot > >>>>>> the bad news: > >>>>>> the nfs boot gets stuck after a while. > >>>>>> > >>>>>> after much trial and error, this is what I do: > >>>>>> hit a key to enter U-Boot > >>>>>> then type: > >>>>>> setenv loaderdev net > >>>>>> boot > >>>>>> > >>>>>> attaching the console: > >>>>> > >>>>> I was also experiencing intermittant lockups while loader loads the > >>>>> kernel. I just wrote it off to failing hardware (I powered my rpi on > >>>>> for the first time in 6-8 months to work on this), since I've never had > >>>>> a problem with netbooting before (it's the only way I've ever booted the > >>>>> rpi). If it's not just my board going bad, then that's a bit of a > >>>>> mystery. The only other difference here from what I've always done is > >>>>> setting rootpath and other net config in u-boot instead of letting ubldr > >>>>> get it from dhcp. > >>>> > >>>> with the stuff from crochet it works, same setup! I am sniffing the net via > >>>> wireshark, and it stops at different positions in the kernel file, > >>>> so the settings of rootpath and other configs are irrelevant. > >>>> the transfer is being done via udp/nfs/v3 (hence added ric :-) maybe > >>>> he can see something we don´t. > >>> > >>> Hmmm. What stuff from crochet? The two components that are in play > >>> here are u-boot itself (it contains the low-level network drivers that > >>> ubldr uses -- it's effectively acting as a bios for ubldr), and ubldr > >>> which contains the higher-level network code. > >>> > >>> In theory ubldr should be the same in both cases; nothing much has > >>> changed in the loader code for months. But there are different paths > >>> through the code depending on how it gets the network parms, and I could > >>> easily have glitched something when I added the feature that lets you > >>> set the config with u-boot env vars. > >>> > >>> The u-boot might be different between a crochet and ports build. They > >>> both start with gonzo's u-boot 2013.10 sources, but crochet probably has > >>> a slightly different set of patches it applies. > >>> > >>> -- Ian > >>> > >> > >> with the old uboot it boots ok, with the newer/modified it stops at random > >> places reading via udp/nfs/v3 the kernel. it loads correctly all the *.4th files, > >> then starts reading the kernel, and hangs after a random time. > >> > > > > I have found that if I let u-boot get an ip address via dhcp then the > > load of the kernel in ubldr never fails (I've had it reboot-looping for > > 24 hours now without a hang). But without letting u-boot do the dhcp > > thing it hangs pretty much every time. Substituting a ping > > for the dhcp isn't enough to make it reliable. > > > > I've stopped debugging that whole mess for now to have a quick check > > whether the very latest mainline u-boot (2015.10-rc4) is able to > > netboot. It sure would be nice to use something modern that has already > > been debugged by others. :) > > there is definitely an issue with the net driver in the newer/ports u-boot. > - tftpboot sometimes works :-) > - same with nfs > I've got the 2015.10-rc4 u-boot for rpi working now. It had some cache flushing problems which I think the u-boot folks have not noticed because the path through the code to launch a linux image is right, but the 'bootelf' and 'go' paths are not. I think the rc4 will turn into an actual release pretty soon and we'll have a new u-boot for rpi. > via dhcp: > it should not try tftp load filename if none is supplied, i.e. defaulting to > .img is wrong! > That's just not how they've defined u-boot to work. There is a whole lot of "it wasn't really designed, it just evolved over time" in u-boot. The original design was that if you left off the filename it tried to load a name based on the mac address. Then when people wanted to use dhcp just to get an IP but not load anything, the mechanism they set up for that is that you have to do "setenv autoload no" before using the dhcp or bootp commands. > i got ubldr loaded via tftp and then bootelf got it running. > the loaded kernel complained: > No valid device tree blob found! > I guess some of the environmet variables got lost > > my network is quiet busy, may be thats a factor? > If this is for rpi, u-boot should have set up an fdt_addr variable referencing the dtb blob it loads and modifies. (This is an rpi only thing, other platforms just leave the dtb loading to ubldr by setting fdt_name instead of fdt_addr, but that won't work on rpi.) So all in all I'd say the problem here is that u-boot 2013.10 for rpi just barely works under some conditions for netbooting, and it's probably not worth putting much more effort into it, because we should have the final 2015.10 release soon and then we can just update the port to use it. -- Ian From owner-freebsd-arm@freebsd.org Thu Oct 1 23:39:13 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8888FA0D048; Thu, 1 Oct 2015 23:39:13 +0000 (UTC) (envelope-from fbl@aoek.com) Received: from srv56-45.cdn.bestreaming.com (ns330343.ip-37-187-119.eu [37.187.119.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E14D81279; Thu, 1 Oct 2015 23:39:11 +0000 (UTC) (envelope-from fbl@aoek.com) Received: from mail.yourbox.net (localhost [127.0.0.1]) by srv56-45.cdn.bestreaming.com (8.14.7/8.14.7) with ESMTP id t91Nd7aI058214; Fri, 2 Oct 2015 01:39:07 +0200 (CEST) (envelope-from fbl@aoek.com) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 02 Oct 2015 01:39:07 +0200 From: =?UTF-8?Q?Jos=C3=A9_P=C3=A9rez?= To: freebsd-ports@freebsd.org, freebsd-arm@freebsd.org Subject: Uses/compiler.mk does not trigger under RBPi Message-ID: X-Sender: fbl@aoek.com User-Agent: Roundcube Webmail/1.0.3 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 23:39:13 -0000 Hi, I've notice that Uses/compiler.mk is not triggered and as a consequence does to set COMPILER_TYPE. me@raspberry-pi:~ % cat Makefile all: @${ECHO_CMD} ${LOCALBASE} @${ECHO_CMD} ${COMPILER_TYPE} .include me@raspberry-pi:~ % make /usr/local me@raspberry-pi:~ % As a result building ports is a nightmare. Note how in AMD64 it works: me@amd64:~ % make /usr/local clang me@amd64:~ % As a workaround I set COMPILER_TYPE=clang in /etc/make.conf but this is just an ugly hack. Can some expert trow a little light on this? Thank you. Regards, -- José Pérez From owner-freebsd-arm@freebsd.org Fri Oct 2 01:29:20 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E614CA0E901; Fri, 2 Oct 2015 01:29:20 +0000 (UTC) (envelope-from michelle@sorbs.net) Received: from hades.sorbs.net (mail.sorbs.net [67.231.146.200]) by mx1.freebsd.org (Postfix) with ESMTP id D35051196; Fri, 2 Oct 2015 01:29:20 +0000 (UTC) (envelope-from michelle@sorbs.net) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8 Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NVK00C29HN7R200@hades.sorbs.net>; Thu, 01 Oct 2015 17:35:33 -0700 (PDT) Message-id: <560DCFD7.30509@sorbs.net> Date: Fri, 02 Oct 2015 02:29:11 +0200 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: =?UTF-8?B?Sm9zw6kgUMOpcmV6?= Cc: freebsd-ports@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Uses/compiler.mk does not trigger under RBPi References: In-reply-to: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 01:29:21 -0000 José Pérez wrote: > Hi, > I've notice that Uses/compiler.mk is not triggered and as a > consequence does to set COMPILER_TYPE. > > me@raspberry-pi:~ % cat Makefile > all: > @${ECHO_CMD} ${LOCALBASE} > @${ECHO_CMD} ${COMPILER_TYPE} > .include > me@raspberry-pi:~ % make > /usr/local > > me@raspberry-pi:~ % > > As a result building ports is a nightmare. > > Note how in AMD64 it works: > me@amd64:~ % make > /usr/local > clang > me@amd64:~ % > > As a workaround I set COMPILER_TYPE=clang in /etc/make.conf but this > is just an ugly hack. > > Can some expert trow a little light on this? Thank you. > > Regards, > Try adding: USES+= compiler to the makefile first... (and it still has some issues but that should solve the first) -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-arm@freebsd.org Fri Oct 2 11:17:31 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1D96A0E67E for ; Fri, 2 Oct 2015 11:17:31 +0000 (UTC) (envelope-from prvs=71030a23e=julien.grall@citrix.com) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Verizon Public SureServer CA G14-SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 65FE917F8 for ; Fri, 2 Oct 2015 11:17:31 +0000 (UTC) (envelope-from prvs=71030a23e=julien.grall@citrix.com) X-IronPort-AV: E=Sophos;i="5.17,622,1437436800"; d="scan'208";a="303877853" Message-ID: <560E6768.6040705@citrix.com> Date: Fri, 2 Oct 2015 12:15:52 +0100 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Maxime Ripard CC: Ian Campbell , Mark Rutland , , Pawel Moll , =?windows-1252?Q?Emilio_L=F3pez?= , Michael Turquette , "Stephen Boyd" , Rob Herring , KumarGala , , , "freebsd-arm@freebsd.org" Subject: Re: "clk: sunxi: Add a simple gates driver" breaks kernel with older DTB References: <1443689231.16718.225.camel@citrix.com> <20151001204506.GR7104@lukather> <560E5767.2040502@citrix.com> <20151002105333.GA2696@lukather> In-Reply-To: <20151002105333.GA2696@lukather> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-DLP: MIA2 X-Mailman-Approved-At: Fri, 02 Oct 2015 11:24:57 +0000 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 11:17:31 -0000 On 02/10/15 11:53, Maxime Ripard wrote: >> If no, that's very unfortunate because it means that you can't >> re-use the same DT across multiple OS and the DT provided by the >> firmware (if it's built-in). > > Is there such OS yet (and by that, I mean one that actually shares our > DT, instead of rewriting its own) ? Yes, FreeBSD started to support the DT provided by vendors which are based on Linux bindings. The ARM64 port is only using DTB provided by the hardware. For ARM32, there is still some platform using a specific DT for FreeBSD but they are trying to get a ride. Regards, -- Julien Grall From owner-freebsd-arm@freebsd.org Fri Oct 2 14:38:44 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEA09A0DADB for ; Fri, 2 Oct 2015 14:38:44 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from valentine.liquidneon.com (valentine.liquidneon.com [216.87.78.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "valentine.liquidneon.com", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A520017E5 for ; Fri, 2 Oct 2015 14:38:44 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: by valentine.liquidneon.com (Postfix, from userid 1018) id 05F7B1FD7C; Fri, 2 Oct 2015 14:38:36 +0000 (UTC) Date: Fri, 2 Oct 2015 14:38:36 +0000 From: Brad Davis To: freebsd-arm@FreeBSD.org Subject: Raspberry Pi Camera? Message-ID: <20151002143835.GO65719@corpmail.liquidneon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 14:38:44 -0000 Hi, I am trying to find out what would be needed to support the Raspberry Pi Camera: https://www.raspberrypi.org/help/camera-module-setup/ Is anyone familiar with CSI and what we would need to do to talk to the Camera? Regards, Brad Davis From owner-freebsd-arm@freebsd.org Fri Oct 2 15:16:15 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0D1FA0D526 for ; Fri, 2 Oct 2015 15:16:15 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A5081E6C; Fri, 2 Oct 2015 15:16:14 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id t92FFqhF001013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Oct 2015 17:15:52 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id t92FFobY084906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Oct 2015 17:15:50 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id t92FFnJ4063182; Fri, 2 Oct 2015 17:15:49 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id t92FFnxA063181; Fri, 2 Oct 2015 17:15:49 +0200 (CEST) (envelope-from ticso) Date: Fri, 2 Oct 2015 17:15:49 +0200 From: Bernd Walter To: Brad Davis Cc: freebsd-arm@freebsd.org Subject: Re: Raspberry Pi Camera? Message-ID: <20151002151549.GF62073@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20151002143835.GO65719@corpmail.liquidneon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151002143835.GO65719@corpmail.liquidneon.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 15:16:16 -0000 On Fri, Oct 02, 2015 at 02:38:36PM +0000, Brad Davis wrote: > Hi, > > I am trying to find out what would be needed to support the Raspberry Pi > Camera: > > https://www.raspberrypi.org/help/camera-module-setup/ > > Is anyone familiar with CSI and what we would need to do to talk to the > Camera? The last thing I heared about this was that the CSI runs over the GPU, which was completely undocumented and runs on Linux using binaries. This was before they released some documentations about the GPU, but I have no idea if the documentation is good enough to get the CSI running. The camera itself is another story - Omnivision isn't very open with their documentations either, but quite often you get some register setup which magically works. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Fri Oct 2 15:20:50 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47A51A0D999 for ; Fri, 2 Oct 2015 15:20:50 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C1AC0111E; Fri, 2 Oct 2015 15:20:48 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Fri, 02 Oct 2015 17:15:37 +0200 id 00050803.560E9F99.00009777 Date: Fri, 2 Oct 2015 17:15:36 +0200 From: Milan Obuch To: Brad Davis Cc: freebsd-arm@FreeBSD.org Subject: Re: Raspberry Pi Camera? Message-ID: <20151002171536.4c1d07a3@zeta.dino.sk> In-Reply-To: <20151002143835.GO65719@corpmail.liquidneon.com> References: <20151002143835.GO65719@corpmail.liquidneon.com> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; i386-portbld-freebsd10.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 15:20:50 -0000 On Fri, 2 Oct 2015 14:38:36 +0000 Brad Davis wrote: > Hi, > > I am trying to find out what would be needed to support the Raspberry > Pi Camera: > > https://www.raspberrypi.org/help/camera-module-setup/ > > Is anyone familiar with CSI and what we would need to do to talk to > the Camera? > > > Regards, > Brad Davis > Search in this mailing list archive, I was able to setup picamera under FreeBSD with help from others and some messages could be found archive from February this year. Regards, Milan From owner-freebsd-arm@freebsd.org Fri Oct 2 16:30:41 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79C9AA0E9AC for ; Fri, 2 Oct 2015 16:30:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 39443190C; Fri, 2 Oct 2015 16:30:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igcrk20 with SMTP id rk20so21088026igc.1; Fri, 02 Oct 2015 09:30:40 -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=4AFsiQ2U4jvuTOyonnEj1EryEkBA24qixEYMapcEZNk=; b=VTjbq4xVKlN1CdeyvKiw31MbVDYf8CEoDFNtE/y556dlX1rYYUT0uB1w4QGS4C3/fi c1ozG2wyuK8sR7kLT3bEnl9UIgTeyRB0VnrpQEJa2Q2FuMuXWE3O/JPOCbqJBiLVmYkW lF6uP9K+XdfhwIOcGsC05r2fA+356cSnOhl7gckqc9B7PZGi9tiQyMhNVSsLYWWBAdc2 vbXMqbs5qI3YWeWL1b580FOszE0qOHWDjUsHAxbQUnrIOxoqpZfbKGSMf7IF8s4Kx3ox 5TNUAg4oqhIcb4DPQ5cxgfWso6scKcakkLhod979iFjWW1/ph3rAQ6iSLZyFcdd5+Git Y1cQ== MIME-Version: 1.0 X-Received: by 10.50.64.243 with SMTP id r19mr5012284igs.22.1443803440619; Fri, 02 Oct 2015 09:30:40 -0700 (PDT) Received: by 10.36.46.15 with HTTP; Fri, 2 Oct 2015 09:30:40 -0700 (PDT) In-Reply-To: <20151002171536.4c1d07a3@zeta.dino.sk> References: <20151002143835.GO65719@corpmail.liquidneon.com> <20151002171536.4c1d07a3@zeta.dino.sk> Date: Fri, 2 Oct 2015 09:30:40 -0700 Message-ID: Subject: Re: Raspberry Pi Camera? From: Adrian Chadd To: Milan Obuch Cc: Brad Davis , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 16:30:41 -0000 hi! Would you please write up how you did it? i'd like to throw it into the raspberry pi bits in the wiki. Thanks! -a On 2 October 2015 at 08:15, Milan Obuch wrote: > On Fri, 2 Oct 2015 14:38:36 +0000 > Brad Davis wrote: > >> Hi, >> >> I am trying to find out what would be needed to support the Raspberry >> Pi Camera: >> >> https://www.raspberrypi.org/help/camera-module-setup/ >> >> Is anyone familiar with CSI and what we would need to do to talk to >> the Camera? >> >> >> Regards, >> Brad Davis >> > > Search in this mailing list archive, I was able to setup picamera under > FreeBSD with help from others and some messages could be found archive > from February this year. > > Regards, > Milan > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Fri Oct 2 19:20:13 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C8559D03B2 for ; Fri, 2 Oct 2015 19:20:13 +0000 (UTC) (envelope-from c_dornig@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DDBCB1F7D for ; Fri, 2 Oct 2015 19:20:12 +0000 (UTC) (envelope-from c_dornig@gmx.de) Received: from [10.50.0.52] ([24.134.162.97]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LsUDg-1afJC03DJo-0122K3 for ; Fri, 02 Oct 2015 21:20:04 +0200 Message-ID: <560ED8DF.4080709@gmx.de> Date: Fri, 02 Oct 2015 21:19:59 +0200 From: "C.Dornig" User-Agent: Mutt 1.0 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: dwc on banana pi pro and poor network performance Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:4krCM/nkJ4Li8dwBDk9qL6J4Wqtks0rQpOGVIHh0gofmHDPC86i LhfhDZsdiyahnBugCo3sEEjf9qEp2CB0IBKpmYZsyMK3rnv32r6KCQSmOE4aBTnlVZV1w9U C1jNkqH5xbyp/sh95jVSf0CKwJXYCx8EoZWSA2QX3hMhrCBpYPLRdU9nMlBea+dCQsdvsFg En7t5Dtb5KlO+zaCsszbg== X-UI-Out-Filterresults: notjunk:1;V01:K0:4d8fHKXaHxI=:6TmyjHgsq2Q4KLqAfurUE0 dGlW86gH3eJkIIkikuuIjTrdVYPfMmueizJBAsmPzebyQUqmmHgvqFkl7627OmhOInWwGPH83 22nwjTu54ByRDUwlHBjyZPsN/RUfCPfzWiPPKl91+PgrPn1422o+Edb3jcsKFiaawPNH7mnUi sf209oNUXZ38dkubeEasJPYGfGIT0r7ljOrMU3m5MU2WFdXVqTbwH0eIVpfYkS3LOhOR9QQUN ykwwn44lG6k2aThq7xLFXf8wldmjV29AximnWzBOYodu+jssxEbTAz3unnPI2bqgVE9/bvngJ aV+9YItYKBkW5auDfPFxE1IOujCG9N8tuQwRSuNp2RPFzn3t+H1zH++DWRUp3nV4f9Mc7onOt Rf0LEbCemUKTGO+dKrQYuZzWGX7P3o6CR/KWGhS+bAAvScZkqPEPTbpcBm5rjrTgzyLhQnNLv RupVCwvXPKMEEav74/787GLo8IRQ+LxNxTou3Npi59w3rmHJaXb4o2MTowFFU0Eo4QsQKbiEi UzQ+wwWS5VgBoaykTdVNcIQJBWZSQsXWD9mLDQOLHWyxpnEPrGv+3aFQHfFaeQS7f6bXJj+Xt HhqUU4fmHCuWR9lss2IaiVnLDeNvcAqk2zc+qE5hhilrpA05xFgbofZYDIeZzR4MfjySluKdm Y3h180OaTToapTBPv8T7vX8YWbvP9vi3YD1uybO647hvrGxMX+FYx/HRMmb8rMNtN9sT4kfo4 1AKuSQ3NqDa9eCfWQADc+NakjWpvDU3xB0Is7tTgw0YOX/QoVBPZ0r6lExQqxtmzYbB4H4ch+ W16H+Q2 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 19:20:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I have a Lemaker Banana Pi Pro and want to use it as router (regarding the GBit interface). For testing i used iperf with two test hosts. The Pi have two vlans configured and each test node use the pi as router to reach the other node. I created a FreeBSD 11 image with crochet (FreeBSD r288430, +u-boot-bananapi version 2015-04). Test scenario: # On Banana: sysctl net.inet.ip.forwarding=1 sysctl net.inet.ip.fastforwarding=1 ifconfig vlan10 create ifconfig vlan10 vlan 10 vlandev dwc0 ifconfig vlan10 10.0.0.1/24 up ifconfig vlan11 create ifconfig vlan11 vlan 11 vlandev dwc0 ifconfig vlan11 10.0.1.1/24 up # Host 1: ifconfig vlan10 create ifconfig vlan10 vlan 10 vlandev em0 ifconfig vlan10 10.0.0.100/24 up route add -net 10.0.1.0/24 10.0.0.1 iperf -c 10.0.1.100 # Host 2: ifconfig vlan11 create ifconfig vlan11 vlan 11 vlandev em0 ifconfig vlan11 10.0.1.100/24 up route add -net 10.0.0.0/24 10.0.1.1 iperf -s The hosts can reach each others. Iperf reports me ~130 Mbit. During the test, netstat reports ~37k pps and the interrupt rate are also not very high (~300). The same test with Linux on the PI results ~550 Mbit. Iperf from host 1 to host 2 without PI in between reports ~990 Mbit. What's wrong here ? Regards, C. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWDtjaAAoJENpF8Q7kD80ylu0P/AwenlTV9xU5ZTGyOec8LQK9 p6GkBuBrXx/if8Su/c81mvSrJWnIufSUIZJmUTgOWLfYqgYAvc5MptTHzzgSa90d i96MdOurF60pKI+a9zcssC7GPYm6yEoSSwDkWecIn0VatlqDTB2ygCdQxie+FRgb SuCFWtyntfLlI45f63IRLgOA5rflEQiPq0L64XTcVe9EJpS6iAUrWnd5KA93/qn3 wJmzqFGITTgyV1OHzYQbkrTKZxQx2CUXpWr08O55J3vsD++Sl2AkGrq3iB4jowap UjA9BxF0KqtY6IwaepnsyrhbacARhJwwMdwjRI/0+zQP2pQcmzjCLtg8mYuOxVp1 lkljVy0FDN2U47eWjybdJ3YWDB4FVFZTOmxj55UKA9X4ayR2a2OMc64vxzJV+cjF 30spBAxYCCHGKWiRWLW0viuajCrBhS0wbD44jF1Be9GmBtRbBBOiZ0f2cLBzAV/x wJCjWaapDvmqzZ2R98uhc1N04ezmlidn1OrAt/Mgca85qQnz5vricbJRR5LUrZzJ tWuq5cTRE+vRC3nQCXuNqHa8AE0rzuSmzMxW12JETHHVqOwBPT5KD5JXk2+N5o2m 67DByhMVxnW/IrsDghNWTyQJJpceUkag2KffddqjYz3ph8KoGraaGw9f5pIOWGUN kWPmLJiSr29OX0/EAygK =ExPu -----END PGP SIGNATURE----- From owner-freebsd-arm@freebsd.org Fri Oct 2 21:49:59 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DECE3A0E30F for ; Fri, 2 Oct 2015 21:49:59 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A2FED1465 for ; Fri, 2 Oct 2015 21:49:59 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: by ykdg206 with SMTP id g206so122046959ykd.1 for ; Fri, 02 Oct 2015 14:49:59 -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=ug3PpaB5/jC45/cwc+LDqF9D1/bZxiUiOhA0Li4EE90=; b=H6PvLdfmIwjLzT5op8HWrsWZ/mn7k4cknw+dSATc9vpHtYBPS3wqrhkuRuY6PsHV7e ImpEdYRpcNn/LEnx8RmLf30q2Jtpq4dTXCHObN2TH9MzeoE6Bxn/AquH4p7EARkP0sEh cWFRMECUF8YwrQTcNb+AQEf3y6v+/wz5ynCGfcJ7CSGErbX803p7EbbPfK01VOCQJRS6 +hyyiBF913yuhrAowo4JFSVksFGzs77Oh1e5x4HLrJgPvAaEy8VYKqpV/x3j97vww6Zx ljgwLBSGG/4bSjL87O0FyoluqlO0zGw9FEJMRrysC4dZVZuhHNEFy9nkiPADQTKxvRUo ZR2w== MIME-Version: 1.0 X-Received: by 10.170.56.2 with SMTP id 2mr15257592yky.106.1443822598917; Fri, 02 Oct 2015 14:49:58 -0700 (PDT) Received: by 10.129.43.70 with HTTP; Fri, 2 Oct 2015 14:49:58 -0700 (PDT) In-Reply-To: <560ED8DF.4080709@gmx.de> References: <560ED8DF.4080709@gmx.de> Date: Fri, 2 Oct 2015 18:49:58 -0300 Message-ID: Subject: Re: dwc on banana pi pro and poor network performance From: Luiz Otavio O Souza To: "C.Dornig" Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 21:50:00 -0000 On 2 October 2015 at 16:19, C.Dornig wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > > I have a Lemaker Banana Pi Pro and want to use it as router (regarding > the GBit interface). > > For testing i used iperf with two test hosts. The Pi have two vlans > configured and each test node use the pi as router to reach the other node. > > I created a FreeBSD 11 image with crochet (FreeBSD r288430, > +u-boot-bananapi version 2015-04). > > Test scenario: > > # On Banana: > sysctl net.inet.ip.forwarding=1 > sysctl net.inet.ip.fastforwarding=1 > ifconfig vlan10 create > ifconfig vlan10 vlan 10 vlandev dwc0 > ifconfig vlan10 10.0.0.1/24 up > ifconfig vlan11 create > ifconfig vlan11 vlan 11 vlandev dwc0 > ifconfig vlan11 10.0.1.1/24 up > > # Host 1: > ifconfig vlan10 create > ifconfig vlan10 vlan 10 vlandev em0 > ifconfig vlan10 10.0.0.100/24 up > route add -net 10.0.1.0/24 10.0.0.1 > iperf -c 10.0.1.100 > > # Host 2: > ifconfig vlan11 create > ifconfig vlan11 vlan 11 vlandev em0 > ifconfig vlan11 10.0.1.100/24 up > route add -net 10.0.0.0/24 10.0.1.1 > iperf -s > > The hosts can reach each others. > > Iperf reports me ~130 Mbit. > > During the test, netstat reports ~37k pps and the interrupt rate are > also not very high (~300). > > The same test with Linux on the PI results ~550 Mbit. > > Iperf from host 1 to host 2 without PI in between reports ~990 Mbit. > > > What's wrong here ? > > Regards, > C. This is expected, if_dwc needs some work to perform better. I just did enough to make it work on A20. If someone is willing to work with this, I can help with some of details (yongari@ was kind enough to educate me about what could be done there), otherwise I'll fix this on my free time (i.e. it will take some time). Luiz From owner-freebsd-arm@freebsd.org Fri Oct 2 21:56:32 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55302A0E8FC; Fri, 2 Oct 2015 21:56:32 +0000 (UTC) (envelope-from fbl@aoek.com) Received: from srv56-45.cdn.bestreaming.com (ns330343.ip-37-187-119.eu [37.187.119.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BEDDF1A54; Fri, 2 Oct 2015 21:56:30 +0000 (UTC) (envelope-from fbl@aoek.com) Received: from mail.yourbox.net (localhost [127.0.0.1]) by srv56-45.cdn.bestreaming.com (8.14.7/8.14.7) with ESMTP id t92LuOjC010079; Fri, 2 Oct 2015 23:56:25 +0200 (CEST) (envelope-from fbl@aoek.com) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 02 Oct 2015 23:56:24 +0200 From: =?UTF-8?Q?Jos=C3=A9_P=C3=A9rez?= To: Michelle Sullivan Cc: freebsd-ports@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Uses/compiler.mk does not trigger under RBPi In-Reply-To: <560DCFD7.30509@sorbs.net> References: <560DCFD7.30509@sorbs.net> Message-ID: X-Sender: fbl@aoek.com User-Agent: Roundcube Webmail/1.0.3 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 21:56:32 -0000 Hi Michelle, thank you for your suggestion. Is this another workaround? I mean: many port Makefiles are affected, in the sense that when built on Intel/AMD the ports just work because Uses/compiler.mk is sucked in automatically, but it is not on ARM. So, shall I report a bug on all the ports that use COMPILER_TYPE, or is there a way to have ARM trigger Uses/compiler.mk? Thank you. Regards, --- José Pérez El 2015-10-02 02:29, Michelle Sullivan escribió: > José Pérez wrote: >> Hi, >> I've notice that Uses/compiler.mk is not triggered and as a >> consequence does to set COMPILER_TYPE. >> >> me@raspberry-pi:~ % cat Makefile >> all: >> @${ECHO_CMD} ${LOCALBASE} >> @${ECHO_CMD} ${COMPILER_TYPE} >> .include >> me@raspberry-pi:~ % make >> /usr/local >> >> me@raspberry-pi:~ % >> >> As a result building ports is a nightmare. >> >> Note how in AMD64 it works: >> me@amd64:~ % make >> /usr/local >> clang >> me@amd64:~ % >> >> As a workaround I set COMPILER_TYPE=clang in /etc/make.conf but this >> is just an ugly hack. >> >> Can some expert trow a little light on this? Thank you. >> >> Regards, >> > Try adding: > > USES+= compiler > > to the makefile first... > > (and it still has some issues but that should solve the first) From owner-freebsd-arm@freebsd.org Sat Oct 3 00:53:37 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B92FA0ECC1 for ; Sat, 3 Oct 2015 00:53:37 +0000 (UTC) (envelope-from maps@toomeek.waw.pl) Received: from poczta.toomeek.waw.pl (unknown [IPv6:2a02:7aa0:1619::c381:6d70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0E0641105 for ; Sat, 3 Oct 2015 00:53:36 +0000 (UTC) (envelope-from maps@toomeek.waw.pl) Received: from [192.168.137.1] (bir177.neoplus.adsl.tpnet.pl [83.28.133.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by poczta.toomeek.waw.pl (Postfix) with ESMTPSA id 08EA7C617F1 for ; Fri, 2 Oct 2015 20:53:23 -0400 (EDT) Subject: Re: dwc on banana pi pro and poor network performance To: freebsd-arm@freebsd.org References: <560ED8DF.4080709@gmx.de> From: TooMeeK Admin Message-ID: <560F2706.9@toomeek.waw.pl> Date: Sat, 3 Oct 2015 02:53:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <560ED8DF.4080709@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2015 00:53:37 -0000 Hello, I'm very interested what exacly image was used here? I would like to build it for my BPi :) On Linux it should go close to ~960Mbit, so You're right - there is something wrong. Please report CPU usage on Your tests? These VLANs are on the same port, so what about Your switch load? Please enable Jumbo Frames and test again? Iperf isn't accurate really.. W dniu 2015-10-02 o 21:19, C.Dornig pisze: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > > I have a Lemaker Banana Pi Pro and want to use it as router (regarding > the GBit interface). > > For testing i used iperf with two test hosts. The Pi have two vlans > configured and each test node use the pi as router to reach the other node. > > I created a FreeBSD 11 image with crochet (FreeBSD r288430, > +u-boot-bananapi version 2015-04). > > Test scenario: > > # On Banana: > sysctl net.inet.ip.forwarding=1 > sysctl net.inet.ip.fastforwarding=1 > ifconfig vlan10 create > ifconfig vlan10 vlan 10 vlandev dwc0 > ifconfig vlan10 10.0.0.1/24 up > ifconfig vlan11 create > ifconfig vlan11 vlan 11 vlandev dwc0 > ifconfig vlan11 10.0.1.1/24 up > > # Host 1: > ifconfig vlan10 create > ifconfig vlan10 vlan 10 vlandev em0 > ifconfig vlan10 10.0.0.100/24 up > route add -net 10.0.1.0/24 10.0.0.1 > iperf -c 10.0.1.100 > > # Host 2: > ifconfig vlan11 create > ifconfig vlan11 vlan 11 vlandev em0 > ifconfig vlan11 10.0.1.100/24 up > route add -net 10.0.0.0/24 10.0.1.1 > iperf -s > > The hosts can reach each others. > > Iperf reports me ~130 Mbit. > > During the test, netstat reports ~37k pps and the interrupt rate are > also not very high (~300). > > The same test with Linux on the PI results ~550 Mbit. > > Iperf from host 1 to host 2 without PI in between reports ~990 Mbit. > > > What's wrong here ? > > Regards, > C. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJWDtjaAAoJENpF8Q7kD80ylu0P/AwenlTV9xU5ZTGyOec8LQK9 > p6GkBuBrXx/if8Su/c81mvSrJWnIufSUIZJmUTgOWLfYqgYAvc5MptTHzzgSa90d > i96MdOurF60pKI+a9zcssC7GPYm6yEoSSwDkWecIn0VatlqDTB2ygCdQxie+FRgb > SuCFWtyntfLlI45f63IRLgOA5rflEQiPq0L64XTcVe9EJpS6iAUrWnd5KA93/qn3 > wJmzqFGITTgyV1OHzYQbkrTKZxQx2CUXpWr08O55J3vsD++Sl2AkGrq3iB4jowap > UjA9BxF0KqtY6IwaepnsyrhbacARhJwwMdwjRI/0+zQP2pQcmzjCLtg8mYuOxVp1 > lkljVy0FDN2U47eWjybdJ3YWDB4FVFZTOmxj55UKA9X4ayR2a2OMc64vxzJV+cjF > 30spBAxYCCHGKWiRWLW0viuajCrBhS0wbD44jF1Be9GmBtRbBBOiZ0f2cLBzAV/x > wJCjWaapDvmqzZ2R98uhc1N04ezmlidn1OrAt/Mgca85qQnz5vricbJRR5LUrZzJ > tWuq5cTRE+vRC3nQCXuNqHa8AE0rzuSmzMxW12JETHHVqOwBPT5KD5JXk2+N5o2m > 67DByhMVxnW/IrsDghNWTyQJJpceUkag2KffddqjYz3ph8KoGraaGw9f5pIOWGUN > kWPmLJiSr29OX0/EAygK > =ExPu > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Sat Oct 3 04:09:29 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9AC9A0F467; Sat, 3 Oct 2015 04:09:29 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (kientzle.com [142.254.26.11]) (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 E0B971016; Sat, 3 Oct 2015 04:09:28 +0000 (UTC) (envelope-from tim@kientzle.com) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id t933t1El038632; Sat, 3 Oct 2015 03:55:01 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.109] (192.168.1.101 [192.168.1.101]) by kientzle.com with SMTP id ze7f9npc4f7qvkhuvn25d6t2sw; Sat, 03 Oct 2015 03:55:01 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Uses/compiler.mk does not trigger under RBPi From: Tim Kientzle In-Reply-To: Date: Fri, 2 Oct 2015 20:54:48 -0700 Cc: Michelle Sullivan , freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <560DCFD7.30509@sorbs.net> To: =?utf-8?Q?Jos=C3=A9_P=C3=A9rez?= X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2015 04:09:29 -0000 What specific ports are you having trouble with? Tim > On Oct 2, 2015, at 2:56 PM, Jos=C3=A9 P=C3=A9rez wrote: >=20 > Hi Michelle, > thank you for your suggestion. Is this another workaround? >=20 > I mean: many port Makefiles are affected, in the sense that when built = on Intel/AMD the ports just work because Uses/compiler.mk is sucked in = automatically, but it is not on ARM. >=20 > So, shall I report a bug on all the ports that use COMPILER_TYPE, or = is there a way to have ARM trigger Uses/compiler.mk? >=20 > Thank you. >=20 > Regards, >=20 >=20 > --- > Jos=C3=A9 P=C3=A9rez >=20 > El 2015-10-02 02:29, Michelle Sullivan escribi=C3=B3: >> Jos=C3=A9 P=C3=A9rez wrote: >>> Hi, >>> I've notice that Uses/compiler.mk is not triggered and as a >>> consequence does to set COMPILER_TYPE. >>> me@raspberry-pi:~ % cat Makefile >>> all: >>> @${ECHO_CMD} ${LOCALBASE} >>> @${ECHO_CMD} ${COMPILER_TYPE} >>> .include >>> me@raspberry-pi:~ % make >>> /usr/local >>> me@raspberry-pi:~ % >>> As a result building ports is a nightmare. >>> Note how in AMD64 it works: >>> me@amd64:~ % make >>> /usr/local >>> clang >>> me@amd64:~ % >>> As a workaround I set COMPILER_TYPE=3Dclang in /etc/make.conf but = this >>> is just an ugly hack. >>> Can some expert trow a little light on this? Thank you. >>> Regards, >> Try adding: >> USES+=3D compiler >> to the makefile first... >> (and it still has some issues but that should solve the first) > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sat Oct 3 04:30:59 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48DBFA0D93A for ; Sat, 3 Oct 2015 04:30:59 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C6AF71EAB for ; Sat, 3 Oct 2015 04:30:58 +0000 (UTC) (envelope-from jim@netgate.com) Received: by lbwr8 with SMTP id r8so35434889lbw.2 for ; Fri, 02 Oct 2015 21:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DDKGxsvOKxzq6EknEhMjJeMjPYMnWwovCh5FSqKcrNs=; b=nAiJxmR1Eha7T+Hl+hNjlU4DXwMkDxH6CWMr9e5PYhu/FrCmPAHhRTXNPLfkICT+Su ZzC0y+SQksZMoL5n7HtCVOYkFb9e+tTdk+WwXP7oDLZv4VI3aAwUYq59/ya9yOexHEJM 0lW+4kiqJAXigM8qr0ijuVUekumOhmtCn0Ot8= 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=DDKGxsvOKxzq6EknEhMjJeMjPYMnWwovCh5FSqKcrNs=; b=INJIdiEgG5RBMxwaZnAOYCY7EfQmRZEKotWxgnEUb0ANHgrnlD8elf5g+eLf+j++tK aF6yDZp5KZ0PY27I26xoMZM6fV09T6eIrAzXvu49HqM4Lxa3qPAdDsT609miA8ZglyZc dqhDAPKiE1OniO0s/IGyOB3LevMmJkFqUrM3dNIf4KlScvloVEE7h658CiEdJ/m9a98z Kc4Cv7rBjGhDS7T1JO5oA75PkNO3AyVmiqzNUdDfeTnnki7VyvDhNSAkZKwG5v60n0bk crc3KjgIr73Ueut1H1en+XqFkycxlHsB/Rwoi+aTuIEgg8gMpSvgwCMH0rkHOxqVNnNl 07/w== X-Gm-Message-State: ALoCoQmUdZUfHTkvE3LT7MLPg68UHDT6SZpXHkNuJVtvhPha0GONaAFbQeDfPp24iswagJf2JZkq X-Received: by 10.112.13.136 with SMTP id h8mr6903986lbc.23.1443846656505; Fri, 02 Oct 2015 21:30:56 -0700 (PDT) Received: from [192.168.2.222] (c-217-115-42-158.cust.bredband2.com. [217.115.42.158]) by smtp.gmail.com with ESMTPSA id xt10sm2056825lbb.9.2015.10.02.21.30.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Oct 2015 21:30:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: dwc on banana pi pro and poor network performance From: Jim Thompson X-Mailer: iPhone Mail (13A404) In-Reply-To: <560F2706.9@toomeek.waw.pl> Date: Sat, 3 Oct 2015 06:30:55 +0200 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <560ED8DF.4080709@gmx.de> <560F2706.9@toomeek.waw.pl> To: TooMeeK Admin X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2015 04:30:59 -0000 > On Oct 3, 2015, at 2:53 AM, TooMeeK Admin wrote: >=20 > Hello, >=20 > I'm very interested what exacly image was used here? I would like to build= it for my BPi :) FreeBSD -CURRENT and Crochet were mentioned.=20 > On Linux it should go close to ~960Mbit, Not even. 600Mbits tops, and that's on a good day, downhill, and with the w= ind.=20 > so You're right - there is something wrong. > Please report CPU usage on Your tests? These VLANs are on the same port, s= o what about Your switch load? > Please enable Jumbo Frames and test again? Why? What would jumbo frames do for you, other than potentially (and artifi= cially) decease the interrupt rate? Without running something like jmg's automtu script, how would you talk to o= ther hosts on the network that don't support jumbo frames? > Iperf isn't accurate really.. It is fairly accurate. Really.=20 > W dniu 2015-10-02 o 21:19, C.Dornig pisze: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >>=20 >> Hi, >>=20 >>=20 >> I have a Lemaker Banana Pi Pro and want to use it as router (regarding >> the GBit interface). >>=20 >> For testing i used iperf with two test hosts. The Pi have two vlans >> configured and each test node use the pi as router to reach the other nod= e. >>=20 >> I created a FreeBSD 11 image with crochet (FreeBSD r288430, >> +u-boot-bananapi version 2015-04). >>=20 >> Test scenario: >>=20 >> # On Banana: >> sysctl net.inet.ip.forwarding=3D1 >> sysctl net.inet.ip.fastforwarding=3D1 >> ifconfig vlan10 create >> ifconfig vlan10 vlan 10 vlandev dwc0 >> ifconfig vlan10 10.0.0.1/24 up >> ifconfig vlan11 create >> ifconfig vlan11 vlan 11 vlandev dwc0 >> ifconfig vlan11 10.0.1.1/24 up >>=20 >> # Host 1: >> ifconfig vlan10 create >> ifconfig vlan10 vlan 10 vlandev em0 >> ifconfig vlan10 10.0.0.100/24 up >> route add -net 10.0.1.0/24 10.0.0.1 >> iperf -c 10.0.1.100 >>=20 >> # Host 2: >> ifconfig vlan11 create >> ifconfig vlan11 vlan 11 vlandev em0 >> ifconfig vlan11 10.0.1.100/24 up >> route add -net 10.0.0.0/24 10.0.1.1 >> iperf -s >>=20 >> The hosts can reach each others. >>=20 >> Iperf reports me ~130 Mbit. >>=20 >> During the test, netstat reports ~37k pps and the interrupt rate are >> also not very high (~300). >>=20 >> The same test with Linux on the PI results ~550 Mbit. >>=20 >> Iperf from host 1 to host 2 without PI in between reports ~990 Mbit. >>=20 >>=20 >> What's wrong here ? >>=20 >> Regards, >> C. >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >>=20 >> iQIcBAEBCAAGBQJWDtjaAAoJENpF8Q7kD80ylu0P/AwenlTV9xU5ZTGyOec8LQK9 >> p6GkBuBrXx/if8Su/c81mvSrJWnIufSUIZJmUTgOWLfYqgYAvc5MptTHzzgSa90d >> i96MdOurF60pKI+a9zcssC7GPYm6yEoSSwDkWecIn0VatlqDTB2ygCdQxie+FRgb >> SuCFWtyntfLlI45f63IRLgOA5rflEQiPq0L64XTcVe9EJpS6iAUrWnd5KA93/qn3 >> wJmzqFGITTgyV1OHzYQbkrTKZxQx2CUXpWr08O55J3vsD++Sl2AkGrq3iB4jowap >> UjA9BxF0KqtY6IwaepnsyrhbacARhJwwMdwjRI/0+zQP2pQcmzjCLtg8mYuOxVp1 >> lkljVy0FDN2U47eWjybdJ3YWDB4FVFZTOmxj55UKA9X4ayR2a2OMc64vxzJV+cjF >> 30spBAxYCCHGKWiRWLW0viuajCrBhS0wbD44jF1Be9GmBtRbBBOiZ0f2cLBzAV/x >> wJCjWaapDvmqzZ2R98uhc1N04ezmlidn1OrAt/Mgca85qQnz5vricbJRR5LUrZzJ >> tWuq5cTRE+vRC3nQCXuNqHa8AE0rzuSmzMxW12JETHHVqOwBPT5KD5JXk2+N5o2m >> 67DByhMVxnW/IrsDghNWTyQJJpceUkag2KffddqjYz3ph8KoGraaGw9f5pIOWGUN >> kWPmLJiSr29OX0/EAygK >> =3DExPu >> -----END PGP SIGNATURE----- >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sat Oct 3 05:30:04 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C5398A0E958 for ; Sat, 3 Oct 2015 05:30:04 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8C3D417D2 for ; Sat, 3 Oct 2015 05:30:04 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 7C0791FE022; Sat, 3 Oct 2015 07:30:01 +0200 (CEST) Subject: Re: dwc on banana pi pro and poor network performance To: "C.Dornig" , freebsd-arm@freebsd.org References: <560ED8DF.4080709@gmx.de> From: Hans Petter Selasky Message-ID: <560F683C.4070802@selasky.org> Date: Sat, 3 Oct 2015 07:31:40 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <560ED8DF.4080709@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2015 05:30:04 -0000 On 10/02/15 21:19, C.Dornig wrote: > The same test with Linux on the PI results ~550 Mbit. Hi, USB is 480Mbit/s minus protocol overhead, so I don't see how you can get 550 Mbit/s . BTW: Regarding the pps, this is much up to the sys/dev/usb/net/if_smsc.c . --HPS From owner-freebsd-arm@freebsd.org Sat Oct 3 05:41:27 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4695A0F209 for ; Sat, 3 Oct 2015 05:41:27 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46A631D74 for ; Sat, 3 Oct 2015 05:41:27 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by wicfx3 with SMTP id fx3so57510145wic.1 for ; Fri, 02 Oct 2015 22:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=in-reply-to:references:from:subject:to:cc:content-type :content-transfer-encoding:date:message-id:mime-version; bh=fHuTvBtoWQRUn9mGCq/ZYK2Pu1VERTouEXVwQWSijhY=; b=okdBTk9+1jPRJfoGLyyj++v+RWI7+WM+k1TfQk6Tun4q10Mhtaxrru4UPrKHoNZrXD SE2IhI/JZAukZnAunU6LD1Jc21Eo+IFqkrQWj0Fs1aVenBr89qn4rlN+M1QyDHrujE0Q s07ScFsbk+kQmFL7FrWoozpOZTKVlZajU8C2i9cdqHLX4bdUlEbGmiRf3x9rJyl07pGv jlxNAPmfdnJ9CuEwDgtu8K0lFYjNwOXOlkH4arF96doX1n6ynsMl70s4TD5/tcyZlw6J ApYMJtGygMVwBfaikcUphzJ2uk2LBZw1tNl7nSl826ig6tkUdYDoHjdmgG1VEWuJQLF9 nn9Q== X-Received: by 10.180.74.175 with SMTP id u15mr971226wiv.66.1443850885783; Fri, 02 Oct 2015 22:41:25 -0700 (PDT) Received: from [127.0.0.1] (xdsl-205-163.nblnetworks.fi. [83.145.205.163]) by smtp.gmail.com with ESMTPSA id qc4sm14660611wjc.33.2015.10.02.22.41.24 (version=TLS1 cipher=RC4-SHA bits=128/128); Fri, 02 Oct 2015 22:41:25 -0700 (PDT) In-Reply-To: References: <560ED8DF.4080709@gmx.de> <560F2706.9@toomeek.waw.pl> From: jau789@gmail.com Subject: Re: dwc on banana pi pro and poor network performance To: TooMeeK Admin , Jim Thompson Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sat, 3 Oct 2015 05:41:25 +0000 Message-ID: MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2015 05:41:27 -0000 Since iperf uses tcp by default, the congestion control methods used on the test systems may affect the test results quite seriously. Most of the cc methods known to freebsd were not designed with short high capasity links in mind. Many of those cc methods were in fact intended for long distances and high bandwidth. In this case the RTT is very short while many of the CC methods expext much higher RTTs. For the best results on short distances and high bandwidth enable ECN bits and use dctcp. The dctcp method was from day one intended to behave gracefully also when RTT is very short and the bandwidth is large. --jau On 03/10/2015 7:30 Jim Thompson wrote: > On Oct 3, 2015, at 2:53 AM, TooMeeK Admin wrote: > > Hello, > > I'm very interested what exacly image was used here? I would like to bui= ld it for my BPi :) FreeBSD -CURRENT and Crochet were mentioned. > On Linux it should go close to ~960Mbit, Not even. 600Mbits tops, and that's on a good day, downhill, and with the= wind. > so You're right - there is something wrong. > Please report CPU usage on Your tests? These VLANs are on the same port,= so what about Your switch load? > Please enable Jumbo Frames and test again? Why? What would jumbo frames do for you, other than potentially (and arti= ficially) decease the interrupt rate? Without running something like jmg's automtu script, how would you talk=20= to other hosts on the network that don't support jumbo frames? > Iperf isn't accurate really.. It is fairly accurate. Really. > W dniu 2015-10-02 o 21:19, C.Dornig pisze: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Hi, >> >> >> I have a Lemaker Banana Pi Pro and want to use it as router (regarding >> the GBit interface). >> >> For testing i used iperf with two test hosts. The Pi have two vlans >> configured and each test node use the pi as router to reach the other= node. >> >> I created a FreeBSD 11 image with crochet (FreeBSD r288430, >> +u-boot-bananapi version 2015-04). >> >> Test scenario: >> >> # On Banana: >> sysctl net.inet.ip.forwarding=3D1 >> sysctl net.inet.ip.fastforwarding=3D1 >> ifconfig vlan10 create >> ifconfig vlan10 vlan 10 vlandev dwc0 >> ifconfig vlan10 10.0.0.1/24 up >> ifconfig vlan11 create >> ifconfig vlan11 vlan 11 vlandev dwc0 >> ifconfig vlan11 10.0.1.1/24 up >> >> # Host 1: >> ifconfig vlan10 create >> ifconfig vlan10 vlan 10 vlandev em0 >> ifconfig vlan10 10.0.0.100/24 up >> route add -net 10.0.1.0/24 10.0.0.1 >> iperf -c 10.0.1.100 >> >> # Host 2: >> ifconfig vlan11 create >> ifconfig vlan11 vlan 11 vlandev em0 >> ifconfig vlan11 10.0.1.100/24 up >> route add -net 10.0.0.0/24 10.0.1.1 >> iperf -s >> >> The hosts can reach each others. >> >> Iperf reports me ~130 Mbit. >> >> During the test, netstat reports ~37k pps and the interrupt rate are >> also not very high (~300). >> >> The same test with Linux on the PI results ~550 Mbit. >> >> Iperf from host 1 to host 2 without PI in between reports ~990 Mbit. >> >> >> What's wrong here ? >> >> Regards, >> C. >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> >> iQIcBAEBCAAGBQJWDtjaAAoJENpF8Q7kD80ylu0P/AwenlTV9xU5ZTGyOec8LQK9 >> p6GkBuBrXx/if8Su/c81mvSrJWnIufSUIZJmUTgOWLfYqgYAvc5MptTHzzgSa90d >> i96MdOurF60pKI+a9zcssC7GPYm6yEoSSwDkWecIn0VatlqDTB2ygCdQxie+FRgb >> SuCFWtyntfLlI45f63IRLgOA5rflEQiPq0L64XTcVe9EJpS6iAUrWnd5KA93/qn3 >> wJmzqFGITTgyV1OHzYQbkrTKZxQx2CUXpWr08O55J3vsD++Sl2AkGrq3iB4jowap >> UjA9BxF0KqtY6IwaepnsyrhbacARhJwwMdwjRI/0+zQP2pQcmzjCLtg8mYuOxVp1 >> lkljVy0FDN2U47eWjybdJ3YWDB4FVFZTOmxj55UKA9X4ayR2a2OMc64vxzJV+cjF >> 30spBAxYCCHGKWiRWLW0viuajCrBhS0wbD44jF1Be9GmBtRbBBOiZ0f2cLBzAV/x >> wJCjWaapDvmqzZ2R98uhc1N04ezmlidn1OrAt/Mgca85qQnz5vricbJRR5LUrZzJ >> tWuq5cTRE+vRC3nQCXuNqHa8AE0rzuSmzMxW12JETHHVqOwBPT5KD5JXk2+N5o2m >> 67DByhMVxnW/IrsDghNWTyQJJpceUkag2KffddqjYz3ph8KoGraaGw9f5pIOWGUN >> kWPmLJiSr29OX0/EAygK >> =3DExPu >> -----END PGP SIGNATURE----- >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" _______________________________________________ freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sat Oct 3 10:15:10 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 166A8A0FEB3; Sat, 3 Oct 2015 10:15:10 +0000 (UTC) (envelope-from michelle@sorbs.net) Received: from hades.sorbs.net (mail.sorbs.net [67.231.146.200]) by mx1.freebsd.org (Postfix) with ESMTP id F39521B0D; Sat, 3 Oct 2015 10:15:09 +0000 (UTC) (envelope-from michelle@sorbs.net) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8 Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NVN00G9T3FLDC00@hades.sorbs.net>; Sat, 03 Oct 2015 03:21:23 -0700 (PDT) Message-id: <560FAAA4.6080800@sorbs.net> Date: Sat, 03 Oct 2015 12:15:00 +0200 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: =?UTF-8?B?Sm9zw6kgUMOpcmV6?= Cc: freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Uses/compiler.mk does not trigger under RBPi References: <560DCFD7.30509@sorbs.net> In-reply-to: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2015 10:15:10 -0000 José Pérez wrote: > Hi Michelle, > thank you for your suggestion. Is this another workaround? As far as I was aware if you need Uses/compiler.mk it should be specified (there are params if a particular compiler/feature set is required) with USES+=compiler > > I mean: many port Makefiles are affected, in the sense that when built > on Intel/AMD the ports just work because Uses/compiler.mk is sucked in > automatically, but it is not on ARM. But do they need Uses/compiler.mk ? If so then it might be someone screwed up, if they don't actually need it then that would be why it's not specified. > > So, shall I report a bug on all the ports that use COMPILER_TYPE, or > is there a way to have ARM trigger Uses/compiler.mk? If they use/require COMPILER_TYPE and don't specify USES+= compiler then I would log a bug for each port and let the ports manager take care of it as it's probably a change in default behavior that has caused the mess... how many are we talking about? 10+, 100+, 1000+? Regards, Michelle > > Thank you. > > Regards, > > > --- > José Pérez > > El 2015-10-02 02:29, Michelle Sullivan escribió: >> José Pérez wrote: >>> Hi, >>> I've notice that Uses/compiler.mk is not triggered and as a >>> consequence does to set COMPILER_TYPE. >>> >>> me@raspberry-pi:~ % cat Makefile >>> all: >>> @${ECHO_CMD} ${LOCALBASE} >>> @${ECHO_CMD} ${COMPILER_TYPE} >>> .include >>> me@raspberry-pi:~ % make >>> /usr/local >>> >>> me@raspberry-pi:~ % >>> >>> As a result building ports is a nightmare. >>> >>> Note how in AMD64 it works: >>> me@amd64:~ % make >>> /usr/local >>> clang >>> me@amd64:~ % >>> >>> As a workaround I set COMPILER_TYPE=clang in /etc/make.conf but this >>> is just an ugly hack. >>> >>> Can some expert trow a little light on this? Thank you. >>> >>> Regards, >>> >> Try adding: >> >> USES+= compiler >> >> to the makefile first... >> >> (and it still has some issues but that should solve the first) > _______________________________________________ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-arm@freebsd.org Sat Oct 3 14:21:57 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10D68A0D451 for ; Sat, 3 Oct 2015 14:21:57 +0000 (UTC) (envelope-from maps@toomeek.waw.pl) Received: from poczta.toomeek.waw.pl (unknown [IPv6:2a02:7aa0:1619::c381:6d70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CAA1B1FCB for ; Sat, 3 Oct 2015 14:21:55 +0000 (UTC) (envelope-from maps@toomeek.waw.pl) Received: from [192.168.137.1] (agws40.neoplus.adsl.tpnet.pl [31.63.198.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by poczta.toomeek.waw.pl (Postfix) with ESMTPSA id A4ABEC617F1 for ; Sat, 3 Oct 2015 10:21:51 -0400 (EDT) Subject: Re: dwc on banana pi pro and poor network performance To: freebsd-arm@freebsd.org References: <560ED8DF.4080709@gmx.de> <560F2706.9@toomeek.waw.pl> From: TooMeeK Admin Message-ID: <560FE47E.50703@toomeek.waw.pl> Date: Sat, 3 Oct 2015 16:21:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2015 14:21:57 -0000 Well, did I missed something? Both BPi and BP PRO have same chip. Here's real test from workstation - BPi test: iperf-2.0.5-2-win32>iperf -c 192.168.137.222 -P 10 ------------------------------------------------------------ Client connecting to 192.168.137.222, TCP port 5001 TCP window size: 64.0 KByte (default) ------------------------------------------------------------ [ 12] local 192.168.137.1 port 55957 connected with 192.168.137.222 port 5001 [ 9] local 192.168.137.1 port 55954 connected with 192.168.137.222 port 5001 [ 11] local 192.168.137.1 port 55956 connected with 192.168.137.222 port 5001 [ 8] local 192.168.137.1 port 55953 connected with 192.168.137.222 port 5001 [ 10] local 192.168.137.1 port 55955 connected with 192.168.137.222 port 5001 [ 4] local 192.168.137.1 port 55949 connected with 192.168.137.222 port 5001 [ 7] local 192.168.137.1 port 55952 connected with 192.168.137.222 port 5001 [ 6] local 192.168.137.1 port 55951 connected with 192.168.137.222 port 5001 [ 5] local 192.168.137.1 port 55950 connected with 192.168.137.222 port 5001 [ 3] local 192.168.137.1 port 55948 connected with 192.168.137.222 port 5001 [ ID] Interval Transfer Bandwidth [ 9] 0.0-10.0 sec 94.2 MBytes 79.0 Mbits/sec [ 11] 0.0-10.0 sec 103 MBytes 86.3 Mbits/sec [ 8] 0.0-10.0 sec 115 MBytes 96.6 Mbits/sec [ 4] 0.0-10.0 sec 111 MBytes 93.0 Mbits/sec [ 6] 0.0-10.0 sec 122 MBytes 102 Mbits/sec [ 5] 0.0-10.0 sec 106 MBytes 89.1 Mbits/sec [ 3] 0.0-10.0 sec 113 MBytes 94.6 Mbits/sec [ 12] 0.0-10.0 sec 119 MBytes 99.3 Mbits/sec [ 10] 0.0-10.0 sec 97.0 MBytes 81.1 Mbits/sec [ 7] 0.0-10.0 sec 126 MBytes 105 Mbits/sec [SUM] 0.0-10.0 sec 1.08 GBytes 925 Mbits/sec I assume it's accurate if You're right, huh? The problem here is how to achieve same speeds under FreeBSD. W dniu 2015-10-03 o 06:30, Jim Thompson pisze: > Not even. 600Mbits tops, and that's on a good day, downhill, and with > the wind.