From owner-freebsd-arm@FreeBSD.ORG Sun Feb 17 09:49:41 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A8C58687; Sun, 17 Feb 2013 09:49:41 +0000 (UTC) (envelope-from iain@g7iii.net) Received: from hal.g7iii.net (unknown [IPv6:2600:3c02::f03c:91ff:feae:1cbe]) by mx1.freebsd.org (Postfix) with ESMTP id 75D57F6D; Sun, 17 Feb 2013 09:49:41 +0000 (UTC) Received: from [192.168.39.76] (157.17.187.81.in-addr.arpa [81.187.17.157]) by hal.g7iii.net (Postfix) with ESMTP id 358B5208F5; Sun, 17 Feb 2013 09:49:34 +0000 (UTC) Message-ID: <5120A7AD.40903@g7iii.net> Date: Sun, 17 Feb 2013 09:49:33 +0000 From: Iain Young User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Damjan Marion Subject: Re: Beaglebone Serial Ports Progress References: <511E1A08.4020105@g7iii.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 09:49:41 -0000 Hi Damjan, On 15/02/13 16:46, You wrote: >> >> I tried changing 0x1000 for 0x2000, as it seems the next reg is also >> reserved for UART1. No more luck. So, thinking I needed to add it as an >> alias (as UART0 is), I added that, but it still dumped me at the >> debugger on boot. >> >> The only other thing is reg-shift. I must confess, I am a bit blind >> here. Not knowing what it actually did I left it as with UART0. I'm >> hoping it essentially includes the next register up for UART1, as >> while that's listed as "Reserved" in the memory map [Yes, I consulted >> SPRUH73G :)] , it seems to be reserved for UART1, but I am just >> guessing (Yes, I know, not good practice when kernel hacking...) >> >> I've attached the latest version of my patch, the output from the >> kernel until it blows up, as well as the trace. Patch is based on >> r246610 >> >> Anyone able to point me in the right direction ? I can't be too far >> away, and I can then add UART2-5, and submit an actual working patch! >> > > It is very likely that clock is disabled for USART1. Problem is that usart uses > standard serial driver which is not requesting clock to be enabled during the attach > by invoking ti_prcm_clk_enable(). > > Can you try to put following at the end of am335x_prcm_attach()? > > prcm_write_4(6c, 2); > > > This should be register CM_PER_UART1_CLKCTRL. That indeed fixed it, and adding the other CLKCTRL registers in a similar way enabled them as well. Have not been able to test fully, as my GPS units are 70 ft away in the shed at the end of the garden, however, my radio clock receivers are now happily twiddling CTS on UARTS3 and 4 (also tested on UART1), so I'm pretty sure all UARTS are fine. Before I send the full patch what are the FreeBSD standards wrt the above lines in am335x_prcm_attach() ? Should I leave as is ? Create a separate function, and call it from am335x_prcm_attach() ? Or do I create a #define in the same file, and create functions for each UART, as I see some other clocks do ? Now, An aside...PPS traditionally uses DCD. But on the 'bone, we need to use CTS instead. So I went looking through the source, and found: if (COM_PPSCTS(flags)) com->pps_bit = MSR_CTS; else com->pps_bit = MSR_DCD; pps_init(&com->pps); in sys/dev/sio/sio.c Wasn't sure if/how to set flags to make that if true from userspace, so hacked it so even the else set com->pps_bit to CTS, and hacked radioclkd2 to look at CTS rather than DCD as well in PPS mode, but to no avail. (radioclkd2 is working in poll mode, but that isn't great up against iwait under Linux, which will also be switched to PPS this week when the new 8 Gig microSD cards arrive) Anyone know where else I may want to look to complete the job ? The actual PPS code doesn't seem to mention DCD at all...So I guess that is particularly [And yes, in my opinion, ntpd has it's own issues with PPS, and assuming it's coming in on a serial port on DCD, and needing the prefer statement the atom_pps reference clock driver is something else for me to break :)] Now in the meantime, I'll go play with Ian's timer PPS patch :) Best Regards Iain From owner-freebsd-arm@FreeBSD.ORG Sun Feb 17 18:21:38 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6C8A7FC; Sun, 17 Feb 2013 18:21:38 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 3F39221F; Sun, 17 Feb 2013 18:21:37 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1HILaIa057949; Sun, 17 Feb 2013 18:21:36 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 96c4uh44phgrr3uyr4qgpwfzve; Sun, 17 Feb 2013 18:21:36 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Beaglebone Serial Ports Progress Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <5120A7AD.40903@g7iii.net> Date: Sun, 17 Feb 2013 10:21:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <73B8F088-EE5C-471D-AEED-52D4E45153DA@kientzle.com> References: <511E1A08.4020105@g7iii.net> <5120A7AD.40903@g7iii.net> To: Iain Young X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org, Damjan Marion X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 18:21:38 -0000 On Feb 17, 2013, at 1:49 AM, Iain Young wrote: > Hi Damjan, >=20 > On 15/02/13 16:46, You wrote: >=20 >>>=20 >>> I tried changing 0x1000 for 0x2000, as it seems the next reg is also >>> reserved for UART1. No more luck. So, thinking I needed to add it as = an >>> alias (as UART0 is), I added that, but it still dumped me at the >>> debugger on boot. >>>=20 >>> The only other thing is reg-shift. I must confess, I am a bit blind >>> here. Not knowing what it actually did I left it as with UART0. I'm >>> hoping it essentially includes the next register up for UART1, as >>> while that's listed as "Reserved" in the memory map [Yes, I = consulted >>> SPRUH73G :)] , it seems to be reserved for UART1, but I am just >>> guessing (Yes, I know, not good practice when kernel hacking...) >>>=20 >>> I've attached the latest version of my patch, the output from the >>> kernel until it blows up, as well as the trace. Patch is based on >>> r246610 >>>=20 >>> Anyone able to point me in the right direction ? I can't be too far >>> away, and I can then add UART2-5, and submit an actual working = patch! >>>=20 >>=20 >> It is very likely that clock is disabled for USART1. Problem is that = usart uses >> standard serial driver which is not requesting clock to be enabled = during the attach >> by invoking ti_prcm_clk_enable(). >>=20 >> Can you try to put following at the end of am335x_prcm_attach()? >>=20 >> prcm_write_4(6c, 2); >>=20 >>=20 >> This should be register CM_PER_UART1_CLKCTRL. >=20 > That indeed fixed it, and adding the other CLKCTRL registers in a > similar way enabled them as well. >=20 > Have not been able to test fully, as my GPS units are 70 ft away in = the > shed at the end of the garden, however, my radio clock receivers are = now > happily twiddling CTS on UARTS3 and 4 (also tested on UART1), so I'm > pretty sure all UARTS are fine. >=20 >=20 > Before I send the full patch what are the FreeBSD standards wrt the > above lines in am335x_prcm_attach() ? Should I leave as is ? Create > a separate function, and call it from am335x_prcm_attach() ? Or do I > create a #define in the same file, and create functions for each UART, > as I see some other clocks do ? It would require a little more work but I think the natural place to put this would be to put uart1: serial@48022000 { ... clocks =3D "UART1"; clock-parent =3D <&PRCM>; }; in the FDT (which is a straightforward way of saying "this device needs the PRCM to turn on "UART1" clocks) and then figure out how to actually support it. ;-) This is the same issue that we've been discussing for pinmux, and the above is essentially the same solution being discussed for pinmux. It's not yet clear to me where/how this info should be acted on. It could actually be handled in the simplebus driver, I think, without modifying (in this case) the UART driver code at all. That would need only a standard way for simplebus to communicate the clock-init string to the designated clock handler. The current handling for interrupt and memory resources could also be used as a model, though that might require modifying each driver to manage pinmux and clock resources. The nicest approach might be for simplebus to handle the clock-init key transparently in the many cases where there's a single clock and the driver doesn't need any special management and then provide a separate internal API for drivers that want to manage multiple clock modes or enable/disable clocks dynamically. Tim From owner-freebsd-arm@FreeBSD.ORG Sun Feb 17 18:53:57 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1875B5E1 for ; Sun, 17 Feb 2013 18:53:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x229.google.com (ie-in-x0229.1e100.net [IPv6:2607:f8b0:4001:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id C160E2DB for ; Sun, 17 Feb 2013 18:53:56 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id 13so6634924iea.0 for ; Sun, 17 Feb 2013 10:53:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=K4TPT6F25Eu95bUAeph4920FIubvdLV30lPtOtZhGs0=; b=HBUeqUJx+DRGGL/6G7ZvNLfGhlC5qyxpiTI1qbfUvOY9mCFHiGFktg9d5FdQBpjZrb ULcVZzlh7J5rvJ07h44K0q/hGdEqrPETyEB559StEuX7KiT9M8gMpUoMrv1aOh7Y7INb PiDZ2LD+QZwcUsCDqIwu2/d7sVMArRCq4ocHb3rpybVjf0DMFF0F9uNVxCcF4/nUGykS fgqQs4uVE7SK55plZvdP9UP4dUh2RtIPHwJhdlJ1KVb/i2EQd1mzIBH+UUzKcb0iz8Yl LrWuOFSUEmU0a/qnvbpXYnFpD2bj3Jvqvx2KWNuFNcHBTMNhLXEjE8+lELowZ4OjG474 BgCw== X-Received: by 10.50.207.39 with SMTP id lt7mr1893864igc.110.1361127236088; Sun, 17 Feb 2013 10:53:56 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id xc3sm7135685igb.10.2013.02.17.10.53.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Feb 2013 10:53:55 -0800 (PST) Sender: Warner Losh Subject: Re: Beaglebone Serial Ports Progress Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <73B8F088-EE5C-471D-AEED-52D4E45153DA@kientzle.com> Date: Sun, 17 Feb 2013 11:53:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9849AAD0-1C71-487D-A0C7-582FAD95FD41@bsdimp.com> References: <511E1A08.4020105@g7iii.net> <5120A7AD.40903@g7iii.net> <73B8F088-EE5C-471D-AEED-52D4E45153DA@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmCNjo008Nj9F4NtK3F/7W3o0PlDuyU9x5f9eaw0CgAYPYiWJLAVG2w4jbCWh6GEE4ad7TR Cc: freebsd-arm@freebsd.org, Damjan Marion X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 18:53:57 -0000 On Feb 17, 2013, at 11:21 AM, Tim Kientzle wrote: >=20 > On Feb 17, 2013, at 1:49 AM, Iain Young wrote: >=20 >> Hi Damjan, >>=20 >> On 15/02/13 16:46, You wrote: >>=20 >>>>=20 >>>> I tried changing 0x1000 for 0x2000, as it seems the next reg is = also >>>> reserved for UART1. No more luck. So, thinking I needed to add it = as an >>>> alias (as UART0 is), I added that, but it still dumped me at the >>>> debugger on boot. >>>>=20 >>>> The only other thing is reg-shift. I must confess, I am a bit blind >>>> here. Not knowing what it actually did I left it as with UART0. I'm >>>> hoping it essentially includes the next register up for UART1, as >>>> while that's listed as "Reserved" in the memory map [Yes, I = consulted >>>> SPRUH73G :)] , it seems to be reserved for UART1, but I am just >>>> guessing (Yes, I know, not good practice when kernel hacking...) >>>>=20 >>>> I've attached the latest version of my patch, the output from the >>>> kernel until it blows up, as well as the trace. Patch is based on >>>> r246610 >>>>=20 >>>> Anyone able to point me in the right direction ? I can't be too far >>>> away, and I can then add UART2-5, and submit an actual working = patch! >>>>=20 >>>=20 >>> It is very likely that clock is disabled for USART1. Problem is that = usart uses >>> standard serial driver which is not requesting clock to be enabled = during the attach >>> by invoking ti_prcm_clk_enable(). >>>=20 >>> Can you try to put following at the end of am335x_prcm_attach()? >>>=20 >>> prcm_write_4(6c, 2); >>>=20 >>>=20 >>> This should be register CM_PER_UART1_CLKCTRL. >>=20 >> That indeed fixed it, and adding the other CLKCTRL registers in a >> similar way enabled them as well. >>=20 >> Have not been able to test fully, as my GPS units are 70 ft away in = the >> shed at the end of the garden, however, my radio clock receivers are = now >> happily twiddling CTS on UARTS3 and 4 (also tested on UART1), so I'm >> pretty sure all UARTS are fine. >>=20 >>=20 >> Before I send the full patch what are the FreeBSD standards wrt the >> above lines in am335x_prcm_attach() ? Should I leave as is ? Create >> a separate function, and call it from am335x_prcm_attach() ? Or do I >> create a #define in the same file, and create functions for each = UART, >> as I see some other clocks do ? >=20 > It would require a little more work but I think the natural > place to put this would be to put >=20 > uart1: serial@48022000 { > ... > clocks =3D "UART1"; > clock-parent =3D <&PRCM>; > }; >=20 > in the FDT (which is a straightforward way of > saying "this device needs the PRCM to turn on > "UART1" clocks) and then figure out how to > actually support it. ;-) >=20 > This is the same issue that we've been discussing > for pinmux, and the above is essentially the same solution > being discussed for pinmux. >=20 > It's not yet clear to me where/how this info should be acted on. > It could actually be handled in the simplebus driver, I > think, without modifying (in this case) the UART driver code > at all. That would need only a standard way for simplebus to > communicate the clock-init string to the designated > clock handler. Yes. We also need to augment our clock support a bit too... In linux = land, which may prove illustrative, you create the clocks as part of the = SoC, associate names in the FDT and then each device requests the proper = clock from their FDT node. There is (or was a few months ago) a move = afoot to make this more automatic by default. > The current handling for interrupt and memory resources > could also be used as a model, though that might > require modifying each driver to manage pinmux and > clock resources. >=20 > The nicest approach might be for simplebus to > handle the clock-init key transparently in > the many cases where there's a single clock and > the driver doesn't need any special management > and then provide a separate internal API for drivers > that want to manage multiple clock modes or enable/disable > clocks dynamically. I rather like this idea, frankly... Warner= From owner-freebsd-arm@FreeBSD.ORG Mon Feb 18 11:06:41 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D3E7C1B9 for ; Mon, 18 Feb 2013 11:06:41 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C5A7BE19 for ; Mon, 18 Feb 2013 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1IB6fmW061473 for ; Mon, 18 Feb 2013 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1IB6f08061471 for freebsd-arm@FreeBSD.org; Mon, 18 Feb 2013 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Feb 2013 11:06:41 GMT Message-Id: <201302181106.r1IB6f08061471@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 11:06:41 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/175803 arm building xdev for arm failing o arm/175605 arm please fix build binutils-2.23.1 in raspberry pi o arm/174461 arm [patch] Fix off-by-one in arm9/arm10 cache maintenance o arm/173617 arm Dreamplug exhibits eSATA file corruption using network o kern/171096 arm [arm][xscale][ixp]Allow 16bit access on PCI bus o arm/166256 arm build fail in pmap.c o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) p arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 p arm/134338 arm [patch] Lock GPIO accesses on ixp425 18 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Feb 18 16:21:37 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 867F5C16 for ; Mon, 18 Feb 2013 16:21:37 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 375237FC for ; Mon, 18 Feb 2013 16:21:36 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1IGLRoR027827 for ; Mon, 18 Feb 2013 11:21:27 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Mon, 18 Feb 2013 11:21:27 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: failed mount root on pi Message-ID: <20130218112127.326bda1e@ivory.wynn.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 16:21:37 -0000 Greeting- I built a new kernel from head as of yesterday. The new kernel boots fine, but it can not seem to mount root. I am wondering if anyone else is having the same issue and what may have changed to make it impossible for the Pi to mount the SD card. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 April 19, 1775 An English attempt to confiscate guns from Americans triggered a successful revolution...... Dear Congress, that's a hint. From owner-freebsd-arm@FreeBSD.ORG Mon Feb 18 18:17:24 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1E98740A for ; Mon, 18 Feb 2013 18:17:24 +0000 (UTC) (envelope-from werner@thieprojects.ch) Received: from newton.metanet.ch (newton.metanet.ch [80.74.158.130]) by mx1.freebsd.org (Postfix) with ESMTP id 6A464D99 for ; Mon, 18 Feb 2013 18:17:22 +0000 (UTC) Received: (qmail 28147 invoked from network); 18 Feb 2013 19:17:20 +0100 Received: from 217-071-083-008.ip-tech.ch (HELO ?192.168.11.88?) (217.71.83.8) by newton.metanet.ch with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Feb 2013 19:17:20 +0100 Message-ID: <51227033.3070304@thieprojects.ch> Date: Mon, 18 Feb 2013 19:17:23 +0100 From: Werner Thie User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: RPi hangs in bootloader Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 18:17:24 -0000 Hi all just built a fresh image (latest sources) with Tim Kientzle's script for the RPi after getting my serial cable and see the following on the console > cu -l /dev/cuaU0 -s 115200 Connected 0 reading uEnv.txt 170 bytes read in 9448 ms (0 Bytes/s) Importing environment from mmc ... reading ubldr 242830 bytes read in 62811 ms (2.9 KiB/s) ## Starting application at 0x02000054 ... Consoles: U-Boot console Compatible API signature found @db662a8 Number of U-Boot devices: 1 FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@xtools, Mon Feb 18 08:36:09 CET 2013) DRAM: 224MB Device: disk error validating blob: FDT_ERR_BADMAGIC | /boot/kernel/kernel data=0x3939b8+0x4294c syms=[0x4+0x7f530+0x4+0x61597] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... fdt_start: 0x00466F50 Kernel entry at 0x100100... Kernel args: (null) After that the RPi hangs forever. Any hints what to try? I do not understand the FDT_ERR_BADMAGIC, the page http://www.denx.de/wiki/DULG/UBootCmdFDT has a lot of those errors listed in an example session but does not explain what the message conveys? TIA, Werner From owner-freebsd-arm@FreeBSD.ORG Mon Feb 18 18:57:33 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4BC1B101 for ; Mon, 18 Feb 2013 18:57:33 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 014CEF60 for ; Mon, 18 Feb 2013 18:57:32 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1U7Vu4-0005qu-R4; Mon, 18 Feb 2013 10:57:30 -0800 Message-ID: <51227998.2030401@bluezbox.com> Date: Mon, 18 Feb 2013 10:57:28 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brett Wynkoop Subject: Re: failed mount root on pi References: <20130218112127.326bda1e@ivory.wynn.com> In-Reply-To: <20130218112127.326bda1e@ivory.wynn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2/18/2013 8:21 AM, Brett Wynkoop wrote: > Greeting- > > I built a new kernel from head as of yesterday. The new kernel boots > fine, but it can not seem to mount root. > > I am wondering if anyone else is having the same issue and what may > have changed to make it impossible for the Pi to mount the SD card. > There was a problem with SDHCI driver: card capabilities read from the card were incomplete. Usually it was 1-bit bus instead of 4-bit bus or no high speed timing for cards that support high speed timing. It worked although not at maximum performance. With this problem gone new bug revealed - some cards stop responding when SDHCI is switched to high speed timing mode. Me and Ian looking into it. Meanwhile try adding following string to /boot/loader.rc on UFS partition: [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 18:57:33 -0000 On 2/18/2013 8:21 AM, Brett Wynkoop wrote: > Greeting- > > I built a new kernel from head as of yesterday. The new kernel boots > fine, but it can not seem to mount root. > > I am wondering if anyone else is having the same issue and what may > have changed to make it impossible for the Pi to mount the SD card. > There was a problem with SDHCI driver: card capabilities read from the card were incomplete. Usually it was 1-bit bus instead of 4-bit bus or no high speed timing for cards that support high speed timing. It worked although not at maximum performance. With this problem gone new bug revealed - some cards stop responding when SDHCI is switched to high speed timing mode. Me and Ian looking into it. Meanwhile try adding following string to /boot/loader.rc on UFS partition: set hw.bcm2835.sdhci.hs=0 From owner-freebsd-arm@FreeBSD.ORG Mon Feb 18 19:46:07 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4CE46E9B for ; Mon, 18 Feb 2013 19:46:07 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 21B541FF for ; Mon, 18 Feb 2013 19:46:06 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1IJjx1h064761; Mon, 18 Feb 2013 19:45:59 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id cmyqw9xxb69xsv533dsz6azs6s; Mon, 18 Feb 2013 19:45:59 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: RPi hangs in bootloader Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <51227033.3070304@thieprojects.ch> Date: Mon, 18 Feb 2013 11:45:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51227033.3070304@thieprojects.ch> To: Werner Thie X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 19:46:07 -0000 On Feb 18, 2013, at 10:17 AM, Werner Thie wrote: > Hi all >=20 > just built a fresh image (latest sources) with Tim Kientzle's script = for the RPi after getting my serial cable and see the following on the = console >=20 > > cu -l /dev/cuaU0 -s 115200 Context: You connected after the RPi boot blocks have already run. U-Boot's boot delay has just expired (the digit zero below) and U-Boot is reading its configuration: > Connected > 0 > reading uEnv.txt > 170 bytes read in 9448 ms (0 Bytes/s) > Importing environment from mmc ... > reading ubldr > 242830 bytes read in 62811 ms (2.9 KiB/s) > ## Starting application at 0x02000054 =85 Context: At this point, ubldr has started. ("ubldr" is "the U-Boot compatible version of loader(8)"). It first probes U-Boot for some general system info before it prints it's own version information: > Consoles: U-Boot console > Compatible API signature found @db662a8 > Number of U-Boot devices: 1 >=20 > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (root@xtools, Mon Feb 18 08:36:09 CET 2013) > DRAM: 224MB >=20 > Device: disk > error validating blob: FDT_ERR_BADMAGIC Context: ubldr has just run the loader.rc command that should find the FDT at a particular location in memory. Apparently, the block of memory it's looking at does not in fact contain a valid FDT. This could be a problem earlier in the boot process (there isn't an FDT where it should be) or could be a problem with ubldr (it's not actually looking where it was told to look) or with loader.rc (it may not have the correct command). (Note: I happen to be tinkering with that exact part of ubldr at the moment, but I just realized out that I haven't actually committed any of my changes yet, so I don't think this is my fault. ;-) You're pretty much toast at this point, since without an FDT, the kernel won't be able to boot. However, ubldr is going to load and execute the kernel anyway: > | > /boot/kernel/kernel data=3D0x3939b8+0x4294c = syms=3D[0x4+0x7f530+0x4+0x61597] > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > fdt_start: 0x00466F50 > Kernel entry at 0x100100... > Kernel args: (null) The last three messages are printed by ubldr just before it transfers control to the kernel. "Kernel args: (null)" is quite typical here. >=20 > After that the RPi hangs forever. Any hints what to try? When was the last time you built an image? There are two reasonable explanations: * RPi boot blocks aren't loading the proper FDT into memory. Look at the RPi boot configuration file config.txt which should refer to devtree.dat. Make sure devtree.dat matches an earlier build. * ubldr isn't correctly finding the FDT. There's been a steady amount of work on boot stuff recently, though I don't see anything in the last few weeks that seems directly relevant. Do you know what SVN revision you're using right now? Do you have an SVN revision of a recent good build? Tim From owner-freebsd-arm@FreeBSD.ORG Mon Feb 18 19:47:04 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A0C22FB6 for ; Mon, 18 Feb 2013 19:47:04 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 5E510212 for ; Mon, 18 Feb 2013 19:47:04 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1IJl4Kd064776; Mon, 18 Feb 2013 19:47:04 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id h43krtw6728yvds5zije6w26qa; Mon, 18 Feb 2013 19:47:03 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: RPi hangs in bootloader Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <51227033.3070304@thieprojects.ch> Date: Mon, 18 Feb 2013 11:47:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51227033.3070304@thieprojects.ch> To: Werner Thie X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 19:47:04 -0000 > I do not understand the FDT_ERR_BADMAGIC, the page = http://www.denx.de/wiki/DULG/UBootCmdFDT has a lot of those errors = listed in an example session but does not explain what the message = conveys? To help me clarify my own understanding, I wrote a brief explanation of where we are with FDT handling that digs into how RPi boot handles FDT today and points out some of the work that still remains. What FDT is: FDT is a way for the kernel to find out what hardware it's running on; there is a DTS (source) file you can edit that gets compiled into a DTB (binary) file that is actually used to drive the kernel driver setup. FDT was standardized as part of OpenFirmware on PowerPC; it allows the system to boot very quickly and allows people who are changing hardware configurations to quickly adjust the system to match new hardware. How FreeBSD uses FDT: For a while, we've mostly been compiling the FDT into the kernel, but we're trying to move to a better design where the FDT is provided by the boot loader. This will eventually allow us to use a single kernel on multiple systems (the fabled "GENERIC ARM kernel") and make it much easier to configure boards (for example, if you connect a new peripheral via GPIO, you'll be able to "just" edit the DTS, compile a new DTB, and reboot to use that peripheral). How FreeBSD-on-RPi handles FDT: The RPi is closer to this boot process than other platforms (I'm working right now to move BeagleBone in this direction) but it's still evolving. Here's how the RPi handles the FDT when booting FreeBSD: * The RPi boot blocks load the DTB into memory. * The RPi boot blocks edit the DTB with information about graphics = setup * U-Boot runs and discovers some additional system information (but doesn't deal with the FDT) * FreeBSD ubldr runs, finds the DTB in memory [0] and edits it to contain memory configuration and some other related data that it queries from U-Boot. [1] * ubldr tells the FreeBSD kernel how to access the FDT. Tim [0] This is the key part that's still not quite right on RPi; ubldr should request the FDT from U-Boot whereas right now it has special knowledge of how the RPi boot blocks store the FDT in memory. I'm trying right now to teach ubldr how to get an FDT from U-Boot. (U-Boot can get the FDT from the RPi blocks, but we are not using that capability today.) [1] A less-serious weakness of the current process: Either U-Boot or the RPi boot blocks should be doing this editing, instead of ubldr getting the information from U-Boot using a different mechanism. From owner-freebsd-arm@FreeBSD.ORG Mon Feb 18 19:54:05 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9BD97319 for ; Mon, 18 Feb 2013 19:54:05 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4B56F258 for ; Mon, 18 Feb 2013 19:54:04 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1IJrtit030830; Mon, 18 Feb 2013 14:53:56 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Mon, 18 Feb 2013 14:53:55 -0500 From: Brett Wynkoop To: Oleksandr Tymoshenko Subject: Re: failed mount root on pi Message-ID: <20130218145355.56f1ec04@ivory.wynn.com> In-Reply-To: <51227998.2030401@bluezbox.com> References: <20130218112127.326bda1e@ivory.wynn.com> <51227998.2030401@bluezbox.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 19:54:05 -0000 On Mon, 18 Feb 2013 10:57:28 -0800 Oleksandr Tymoshenko wrote: > There was a problem with SDHCI driver: card capabilities read from > the card were > incomplete. Usually it was 1-bit bus instead of 4-bit bus or no high > speed timing > for cards that support high speed timing. It worked although not at > maximum performance. With this problem gone new bug revealed - some > cards stop responding when SDHCI is switched to high speed timing > mode. Me and Ian looking into it. Meanwhile try adding following > string to /boot/loader.rc on UFS partition: > > set hw.bcm2835.sdhci.hs=0 Greeting- This did not help. I will mount the card on another box and revert to old kernel. For some odd reason I can not get into the boot loader to boot either kernel.old or kernel.generic. I have no keyboard response until the kernel boots. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 April 19, 1775 An English attempt to confiscate guns from Americans triggered a successful revolution...... Dear Congress, that's a hint. From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 01:05:48 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 408A1D03; Tue, 19 Feb 2013 01:05:48 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 1FAAA11E; Tue, 19 Feb 2013 01:05:48 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1J15Zi2094056; Mon, 18 Feb 2013 18:05:41 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1J15COM049014; Mon, 18 Feb 2013 18:05:12 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: RPi hangs in bootloader From: Ian Lepore To: Tim Kientzle In-Reply-To: References: <51227033.3070304@thieprojects.ch> Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Feb 2013 18:05:12 -0700 Message-ID: <1361235912.1164.55.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 01:05:48 -0000 On Mon, 2013-02-18 at 11:47 -0800, Tim Kientzle wrote: > > I do not understand the FDT_ERR_BADMAGIC, the page http://www.denx.de/wiki/DULG/UBootCmdFDT has a lot of those errors listed in an example session but does not explain what the message conveys? > > To help me clarify my own understanding, I wrote a brief > explanation of where we are with FDT handling that > digs into how RPi boot handles FDT today and points > out some of the work that still remains. > > What FDT is: > > FDT is a way for the kernel to find out what hardware it's > running on; there is a DTS (source) file you can edit > that gets compiled into a DTB (binary) file that is actually > used to drive the kernel driver setup. FDT was > standardized as part of OpenFirmware on PowerPC; it allows > the system to boot very quickly and allows people who are > changing hardware configurations to quickly adjust the system > to match new hardware. > > How FreeBSD uses FDT: > > For a while, we've mostly been compiling the FDT into the kernel, > but we're trying to move to a better design where the FDT is > provided by the boot loader. > > This will eventually allow us to use a single kernel on multiple > systems (the fabled "GENERIC ARM kernel") and make it > much easier to configure boards (for example, if you connect > a new peripheral via GPIO, you'll be able to "just" edit the > DTS, compile a new DTB, and reboot to use that peripheral). > > How FreeBSD-on-RPi handles FDT: > > The RPi is closer to this boot process than other platforms > (I'm working right now to move BeagleBone in this direction) > but it's still evolving. Here's how the RPi handles the FDT > when booting FreeBSD: > > * The RPi boot blocks load the DTB into memory. > > * The RPi boot blocks edit the DTB with information about graphics setup > > * U-Boot runs and discovers some additional system information > (but doesn't deal with the FDT) > > * FreeBSD ubldr runs, finds the DTB in memory [0] and edits it > to contain memory configuration and some other related > data that it queries from U-Boot. [1] > > * ubldr tells the FreeBSD kernel how to access the FDT. > > Tim > > [0] This is the key part that's still not quite right on RPi; > ubldr should request the FDT from U-Boot whereas right now it > has special knowledge of how the RPi boot blocks store the FDT > in memory. I'm trying right now to teach ubldr how to get > an FDT from U-Boot. (U-Boot can get the FDT from the RPi > blocks, but we are not using that capability today.) > > [1] A less-serious weakness of the current process: Either U-Boot or > the RPi boot blocks should be doing this editing, instead > of ubldr getting the information from U-Boot using a different > mechanism. While you're digging around in that area of the code... is there any way ubldr can find out from u-boot how it was loaded? I would love it if ubldr could automatically set currdev=net0: if it was loaded via dhcp or tftp, and automatically use net0:/boot/loader.rc in that case as well. If that's not possible, I'd settle for the ability to pass args to ubldr. Or even a value in the environment would work I guess, can ubldr see the u-boot env? The general thing I'm up to today is learning enough about ubldr to use it effectively, and ultimately to see if it can be used to load a (semi-)generic kernel plus a set of modules you configure in loader.rc. I've just managed to do that by hand, now to see if loader.rc will cooperate. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 01:25:56 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 79624B6 for ; Tue, 19 Feb 2013 01:25:56 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x22e.google.com (ie-in-x022e.1e100.net [IPv6:2607:f8b0:4001:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 4C1F61CD for ; Tue, 19 Feb 2013 01:25:56 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id k10so7927019iea.33 for ; Mon, 18 Feb 2013 17:25:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=9/KLkkA0GxMKNzdT0zcht53BO24BV+JMRL6NLGOw1lY=; b=Oco8T9KZSHEgjjibaoc3pSAfEsyb587O7NUseWVg6UjZo+YRj2OwCCmw+xS/A9ZkwG t6vCenFUuO3IS+o0skVZNKUat9oeyf7KajprKvBO+ZHqsK4hUOwyVeC3kmH8+oV3+jc5 gD3UJB8dF9GdSy6X/aAq0xL8LtoXP2HGRfOWFSs8X3PukfC4S8U/ZIjhOCKPpGfBucZv mPhuQ9GCU+Nns4I8C24u11IF9B1TS7N4w6D3rfeG8Z5DPohyaZ47qjixBW/gakJJGbS9 wsC1TD3lFZKXLacli9vHEhIAPyo5EEFcOQV8UYZqJgFlMNLW+hnxEZiKsQlYjo9w/ZV1 icsg== X-Received: by 10.50.194.129 with SMTP id hw1mr8252074igc.8.1361237155804; Mon, 18 Feb 2013 17:25:55 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id uy13sm11788858igb.7.2013.02.18.17.25.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Feb 2013 17:25:54 -0800 (PST) Sender: Warner Losh Subject: Re: RPi hangs in bootloader Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1361235912.1164.55.camel@revolution.hippie.lan> Date: Mon, 18 Feb 2013 18:25:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3C578B82-E8F9-4020-B52C-5F1091576E75@bsdimp.com> References: <51227033.3070304@thieprojects.ch> <1361235912.1164.55.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnR0LxeKaeNCGjGRa1F2NEEL2CMrSSeM0DIufGxru7nSJdpGMifslLRdDksdSf84wAYz7+N Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 01:25:56 -0000 On Feb 18, 2013, at 6:05 PM, Ian Lepore wrote: > On Mon, 2013-02-18 at 11:47 -0800, Tim Kientzle wrote: >>> I do not understand the FDT_ERR_BADMAGIC, the page = http://www.denx.de/wiki/DULG/UBootCmdFDT has a lot of those errors = listed in an example session but does not explain what the message = conveys? >>=20 >> To help me clarify my own understanding, I wrote a brief >> explanation of where we are with FDT handling that >> digs into how RPi boot handles FDT today and points >> out some of the work that still remains. >>=20 >> What FDT is: >>=20 >> FDT is a way for the kernel to find out what hardware it's >> running on; there is a DTS (source) file you can edit >> that gets compiled into a DTB (binary) file that is actually >> used to drive the kernel driver setup. FDT was >> standardized as part of OpenFirmware on PowerPC; it allows >> the system to boot very quickly and allows people who are >> changing hardware configurations to quickly adjust the system >> to match new hardware. >>=20 >> How FreeBSD uses FDT: >>=20 >> For a while, we've mostly been compiling the FDT into the kernel, >> but we're trying to move to a better design where the FDT is >> provided by the boot loader. >>=20 >> This will eventually allow us to use a single kernel on multiple >> systems (the fabled "GENERIC ARM kernel") and make it >> much easier to configure boards (for example, if you connect >> a new peripheral via GPIO, you'll be able to "just" edit the >> DTS, compile a new DTB, and reboot to use that peripheral). >>=20 >> How FreeBSD-on-RPi handles FDT: >>=20 >> The RPi is closer to this boot process than other platforms >> (I'm working right now to move BeagleBone in this direction) >> but it's still evolving. Here's how the RPi handles the FDT >> when booting FreeBSD: >>=20 >> * The RPi boot blocks load the DTB into memory. >>=20 >> * The RPi boot blocks edit the DTB with information about graphics = setup >>=20 >> * U-Boot runs and discovers some additional system information >> (but doesn't deal with the FDT) >>=20 >> * FreeBSD ubldr runs, finds the DTB in memory [0] and edits it >> to contain memory configuration and some other related >> data that it queries from U-Boot. [1] >>=20 >> * ubldr tells the FreeBSD kernel how to access the FDT. >>=20 >> Tim >>=20 >> [0] This is the key part that's still not quite right on RPi; >> ubldr should request the FDT from U-Boot whereas right now it >> has special knowledge of how the RPi boot blocks store the FDT >> in memory. I'm trying right now to teach ubldr how to get >> an FDT from U-Boot. (U-Boot can get the FDT from the RPi >> blocks, but we are not using that capability today.) >>=20 >> [1] A less-serious weakness of the current process: Either U-Boot or >> the RPi boot blocks should be doing this editing, instead >> of ubldr getting the information from U-Boot using a different >> mechanism. >=20 > While you're digging around in that area of the code... is there any = way > ubldr can find out from u-boot how it was loaded? I would love it if > ubldr could automatically set currdev=3Dnet0: if it was loaded via = dhcp or > tftp, and automatically use net0:/boot/loader.rc in that case as well. I don't think it can but... > If that's not possible, I'd settle for the ability to pass args to > ubldr. Or even a value in the environment would work I guess, can = ubldr > see the u-boot env? ... you can pass this in on the command line. I think the way we're = booting means we'd have to dig this information out of the environment, = in which case we can always grab the command line... > The general thing I'm up to today is learning enough about ubldr to = use > it effectively, and ultimately to see if it can be used to load a > (semi-)generic kernel plus a set of modules you configure in = loader.rc. > I've just managed to do that by hand, now to see if loader.rc will > cooperate. Let us know how that works out. Warner From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 02:01:18 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9193E4AF for ; Tue, 19 Feb 2013 02:01:18 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 0F8182F5 for ; Tue, 19 Feb 2013 02:01:17 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1J21HNF094839 for ; Mon, 18 Feb 2013 19:01:17 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1J20tJG049040; Mon, 18 Feb 2013 19:00:55 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: RPi hangs in bootloader From: Ian Lepore To: Warner Losh In-Reply-To: <3C578B82-E8F9-4020-B52C-5F1091576E75@bsdimp.com> References: <51227033.3070304@thieprojects.ch> <1361235912.1164.55.camel@revolution.hippie.lan> <3C578B82-E8F9-4020-B52C-5F1091576E75@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Feb 2013 19:00:55 -0700 Message-ID: <1361239255.1164.61.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 02:01:18 -0000 On Mon, 2013-02-18 at 18:25 -0700, Warner Losh wrote: > On Feb 18, 2013, at 6:05 PM, Ian Lepore wrote: [...] > > The general thing I'm up to today is learning enough about ubldr to use > > it effectively, and ultimately to see if it can be used to load a > > (semi-)generic kernel plus a set of modules you configure in loader.rc. > > I've just managed to do that by hand, now to see if loader.rc will > > cooperate. > > Let us know how that works out. > > Warner It actually worked out pretty well. This is my rc file now: rpi# cat /boot/loader.rc fdt addr 0x100 load kernel load uftdi set autoboot_delay=8000 The tricky bits are... if you're going to use any load commands, "load kernel" has to be first, and the delay of 8000 compensates for the fact that the get_timer() routine in the rpi u-boot we're all using right now returns micros rather than millis. I think soon we'll be able to stop building kitchen-sink kernels for things like the *Plug computers and instead just let all the standard modules get built along with a fairly minimal kernel. Folks should be able to download an image and enable features they want to try with a few edits to loader.rc and a reboot. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 04:31:27 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D4AFA2D8 for ; Tue, 19 Feb 2013 04:31:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id 8EEC1AD2 for ; Tue, 19 Feb 2013 04:31:27 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id 17so7848451iea.40 for ; Mon, 18 Feb 2013 20:31:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=V85bGfx88ENepuN10w1tj69tpEeC0vP0FenDGtMy7Rw=; b=DikJjlk/QHdGNr+GvwmwrgBQE816brF+CKraWBJVliRDMPZUPyrNjPWTBqoOw09gBS 7ZJW3SFra2Ke/fEMjbYUuEOd7BFObCN4zqvo9WqJevXl5uIVq8SufSRbJHCF1D/T8J2H 6bl//WXQhRXZip4yef5HI2QI9oJ4vcIPAS67jKFTBF+6jlMZFZCuPoYbvszslLqEN8ra XSREMk6Imhi35cYjKhL1Z1OX+a3NIxk4fFkxixP7UJa44BtgqLYZa0+8lvvQrQoE6ABJ VJuuimgMd2hH9AK+fqWK+ICIgWvKGyIBjUEDKf5htX9lj7sWI7m8/Pn9V2+SadYfUzX6 64iQ== X-Received: by 10.42.122.66 with SMTP id m2mr6884617icr.15.1361248287261; Mon, 18 Feb 2013 20:31:27 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ur12sm12076106igb.8.2013.02.18.20.31.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Feb 2013 20:31:26 -0800 (PST) Sender: Warner Losh Subject: Re: RPi hangs in bootloader Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1361239255.1164.61.camel@revolution.hippie.lan> Date: Mon, 18 Feb 2013 21:31:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8562026D-EB1F-4ED8-8C2A-DB9CCF2A5E36@bsdimp.com> References: <51227033.3070304@thieprojects.ch> <1361235912.1164.55.camel@revolution.hippie.lan> <3C578B82-E8F9-4020-B52C-5F1091576E75@bsdimp.com> <1361239255.1164.61.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmz/tSHaBKi3pv9y7uZ/kg9RWRwLzgVog2oTVNFynwqTUxHwtetVW5v7TrrlMOVbcNGGrs/ Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 04:31:27 -0000 On Feb 18, 2013, at 7:00 PM, Ian Lepore wrote: > On Mon, 2013-02-18 at 18:25 -0700, Warner Losh wrote: >> On Feb 18, 2013, at 6:05 PM, Ian Lepore wrote: > [...] >>> The general thing I'm up to today is learning enough about ubldr to = use >>> it effectively, and ultimately to see if it can be used to load a >>> (semi-)generic kernel plus a set of modules you configure in = loader.rc. >>> I've just managed to do that by hand, now to see if loader.rc will >>> cooperate. >>=20 >> Let us know how that works out. >>=20 >> Warner >=20 > It actually worked out pretty well. This is my rc file now: >=20 > rpi# cat /boot/loader.rc > fdt addr 0x100 > load kernel > load uftdi > set autoboot_delay=3D8000 >=20 > The tricky bits are... if you're going to use any load commands, "load > kernel" has to be first, and the delay of 8000 compensates for the = fact > that the get_timer() routine in the rpi u-boot we're all using right = now > returns micros rather than millis. >=20 > I think soon we'll be able to stop building kitchen-sink kernels for > things like the *Plug computers and instead just let all the standard > modules get built along with a fairly minimal kernel. Folks should be > able to download an image and enable features they want to try with a > few edits to loader.rc and a reboot. Yea, or we can finally get tagging on the .ko's working so that we can = load modules automatically based on unattached FDT devices... Warner= From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 05:00:34 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A2C62502 for ; Tue, 19 Feb 2013 05:00:34 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 525D5B6E for ; Tue, 19 Feb 2013 05:00:34 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1J50Ro8037046; Tue, 19 Feb 2013 00:00:27 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Tue, 19 Feb 2013 00:00:27 -0500 From: Brett Wynkoop To: Oleksandr Tymoshenko Subject: Re: failed mount root on pi Message-ID: <20130219000027.5e1045a2@ivory.wynn.com> In-Reply-To: <51227998.2030401@bluezbox.com> References: <20130218112127.326bda1e@ivory.wynn.com> <51227998.2030401@bluezbox.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 05:00:34 -0000 Greeting- Well I had to drop the mmc bus down to 400Khz per DamnHippi's suggestion in chat and now the Pi works. Gonzo I think maybe you should back the change out of the sources and drop it back to 400 Khz. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 Gun Control: The theory that a woman found dead in an alley, raped and strangled with her own pantyhose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 07:39:24 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 721A9BFA for ; Tue, 19 Feb 2013 07:39:24 +0000 (UTC) (envelope-from werner@thieprojects.ch) Received: from newton.metanet.ch (newton.metanet.ch [80.74.158.130]) by mx1.freebsd.org (Postfix) with ESMTP id 626BF19E for ; Tue, 19 Feb 2013 07:39:22 +0000 (UTC) Received: (qmail 23967 invoked from network); 19 Feb 2013 08:39:21 +0100 Received: from 217-071-083-008.ip-tech.ch (HELO ?192.168.11.88?) (217.71.83.8) by newton.metanet.ch with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Feb 2013 08:39:21 +0100 Message-ID: <51232C2C.4010308@thieprojects.ch> Date: Tue, 19 Feb 2013 08:39:24 +0100 From: Werner Thie User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: RPi hangs in bootloader References: <51227033.3070304@thieprojects.ch> 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 07:39:24 -0000 Hi Tim this was by far he best explanation of what's happening during boot I've ever read, be it on the Linux or on the BSD side, thank you so much! > Do you know what SVN revision you're using right now? Tue, Feb 18th 1800 - SVN #246947 > Do you have an SVN revision of a recent good build? No, this is my first go at the RPi Failing in the same way as the previous build, image fresh from your scripts. I'm now trying to get a hold of all the relevant bits in the boot process. Thxs, Werner From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 08:27:14 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E7357673 for ; Tue, 19 Feb 2013 08:27:14 +0000 (UTC) (envelope-from mats@exmandato.se) Received: from ext.mellstrand.net (ext.mellstrand.net [IPv6:2001:2040:4:2::51]) by mx1.freebsd.org (Postfix) with ESMTP id 9A38B6B9 for ; Tue, 19 Feb 2013 08:27:14 +0000 (UTC) Received: by ext.mellstrand.net Tue, 19 Feb 2013 08:27:06 GMT Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 From: Mats Mellstrand X-Priority: 3 In-Reply-To: Date: Tue, 19 Feb 2013 09:27:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> <20130131001553.GC67562@cicely7.cicely.de> <9E78813F3BF946A4A2FCEA2C363A847E@ad.peach.ne.jp> <016DDBBF-D502-4C76-96B5-BEE2D46FC6CC@exmandato.se> To: Daisuke Aoyama Cc: freebsd-arm@freebsd.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 08:27:15 -0000 Hi I'm having problem with scp to or from RPi. I have tried IPv4 and IPv6, ue0 and wlan0, but scp don't work. However ssh does. /mm=20 On 11 feb 2013, at 20:22, Daisuke Aoyama wrote: >> In trying to install the ports collection on my RPi, the following = happens: >>=20 >> kmem_malloc(4096): kmem_map too small: 12582912 total allocated >> KDB: enter: panic >> [ thread pid 27505 tid 100053 ] >> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >>=20 >> Suggestions? (more than not installing the ports collection) >=20 > This is known problem of old kernel. You can update the kernel to > http://www.peach.ne.jp/archives/rpi/kernel/kernel-20130209.gz >=20 > or use new image based on SVN r246603: > http://www.peach.ne.jp/archives/rpi/freebsd-pi-clang-20130210.img.gz >=20 > This image contain both complete source tree and portsnap = fetch/extracted tree. >=20 > Also, some packages making under freebsd-pi-clang-20130210.img are = uploaded to: > http://www.peach.ne.jp/archives/rpi/ports/packages/All/ > (compiled by clang/clang++ with bundled make.conf) > ---------------------------------------------------------------------- > How to use package: > First, install pkg manually: > # fetch http://www.peach.ne.jp/archives/rpi/pkg-static > # fetch = http://www.peach.ne.jp/archives/rpi/ports/packages/All/pkg-1.0.7.txz > # chmod 755 pkg-static > # ./pkg-static add pkg-1.0.7.txz > # echo 'PACKAGESITE : = http://www.peach.ne.jp/archives/rpi/ports/packages/All' > = /usr/local/etc/pkg.conf >=20 > For example, install bash and subversion: > # pkg install bash > # pkg install subversion > ---------------------------------------------------------------------- >=20 > Thank you. > --=20 > Daisuke Aoyama >=20 From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 08:46:51 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6A3C994E for ; Tue, 19 Feb 2013 08:46:51 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 304CA75E for ; Tue, 19 Feb 2013 08:46:50 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1J8knw4041990 for ; Tue, 19 Feb 2013 03:46:49 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Tue, 19 Feb 2013 03:46:49 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: Network Notes Message-ID: <20130219034649.5fb69bce@ivory.wynn.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 08:46:51 -0000 Greeting- Just discovered a difference in network performance between the Pi and the Bone. wynkoop@beaglebone:~ % ping prd7 PING prd7.wynn.com (199.89.147.7): 56 data bytes 64 bytes from 199.89.147.7: icmp_seq=0 ttl=64 time=2.170 ms 64 bytes from 199.89.147.7: icmp_seq=1 ttl=64 time=1.131 ms 64 bytes from 199.89.147.7: icmp_seq=2 ttl=64 time=0.977 ms 64 bytes from 199.89.147.7: icmp_seq=3 ttl=64 time=1.052 ms 64 bytes from 199.89.147.7: icmp_seq=4 ttl=64 time=1.217 ms ^C --- prd7.wynn.com ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.977/1.309/2.170/0.438 ms wynkoop@beaglebone:~ % root@fbsd-pi:~ # ping prd7 PING prd7.wynn.com (199.89.147.7): 56 data bytes 64 bytes from 199.89.147.7: icmp_seq=0 ttl=64 time=8.560 ms 64 bytes from 199.89.147.7: icmp_seq=1 ttl=64 time=10.222 ms 64 bytes from 199.89.147.7: icmp_seq=2 ttl=64 time=10.241 ms 64 bytes from 199.89.147.7: icmp_seq=3 ttl=64 time=10.110 ms 64 bytes from 199.89.147.7: icmp_seq=4 ttl=64 time=10.210 ms ^C --- prd7.wynn.com ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 8.560/9.869/10.241/0.656 ms root@fbsd-pi:~ # prd7 is on the same 10Mb switch as the Pi and it is on a different switch than the bone. I guess the bone has the better networking hardware. Now if only the bone could use usb I would be a happy camper! -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 Gun Control: The theory that a woman found dead in an alley, raped and strangled with her own pantyhose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 08:55:07 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2A4C2A5F for ; Tue, 19 Feb 2013 08:55:07 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id B97F179A for ; Tue, 19 Feb 2013 08:55:05 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1J8svSH042047; Tue, 19 Feb 2013 03:54:57 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Tue, 19 Feb 2013 03:54:56 -0500 From: Brett Wynkoop To: Mats Mellstrand Subject: re: scp trouble Message-ID: <20130219035456.2cb5e139@ivory.wynn.com> In-Reply-To: References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> <20130131001553.GC67562@cicely7.cicely.de> <9E78813F3BF946A4A2FCEA2C363A847E@ad.peach.ne.jp> <016DDBBF-D502-4C76-96B5-BEE2D46FC6CC@exmandato.se> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 08:55:07 -0000 On Tue, 19 Feb 2013 09:27:04 +0100 Mats Mellstrand wrote: > Hi > > I'm having problem with scp to or from RPi. > I have tried IPv4 and IPv6, ue0 and wlan0, but scp don't work. > However ssh does. > > /mm > > On 11 feb 2013, at 20:22, Daisuke Aoyama wrote: > > >> In trying to install the ports collection on my RPi, the following > >> happens: > >> > >> kmem_malloc(4096): kmem_map too small: 12582912 total allocated > >> KDB: enter: panic > >> [ thread pid 27505 tid 100053 ] > >> Stopped at $d: ldrb r15, [r15, r15, ror r15]! > >> > >> Suggestions? (more than not installing the ports collection) > > Greeting- I am using this as my base Pi image: http://www.raspberrypi.org/archives/3094 I have no problem with scp, but be warned that the current head has a new bug that will cause your Pi to maybe not mount root, so do not try to build a new kernel from head. I have used scp against with the kernel in that image. I also have done a portsnap and built several ports. Maybe Gonzo will drop the change he made to the speed of initial sd card probe and revert to 400Khz, then you should be able to build a custom kernel with no problem. I hope this helps. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 I would never invade the United States. There would be a gun behind every blade of grass. --Isoroku Yamamoto From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 09:01:34 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D5463C7A for ; Tue, 19 Feb 2013 09:01:34 +0000 (UTC) (envelope-from steve@sohara.org) Received: from uk1rly2283.eechost.net (relay01a.mail.uk1.eechost.net [217.69.40.75]) by mx1.freebsd.org (Postfix) with ESMTP id 9573E898 for ; Tue, 19 Feb 2013 09:01:33 +0000 (UTC) Received: from [31.186.37.179] (helo=smtp.marelmo.com) by uk1rly2283.eechost.net with esmtpa (Exim 4.72) (envelope-from ) id 1U7j4y-0002oH-Vh; Tue, 19 Feb 2013 09:01:37 +0000 Received: from [192.168.63.1] (helo=steve.marelmo.com) by smtp.marelmo.com with smtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U7j4i-000LRp-DP; Tue, 19 Feb 2013 09:01:20 +0000 Date: Tue, 19 Feb 2013 09:00:49 +0000 From: Steve O'Hara-Smith To: Brett Wynkoop Subject: Re: Network Notes Message-Id: <20130219090049.40cb855b2b7c855971f04a4a@sohara.org> In-Reply-To: <20130219034649.5fb69bce@ivory.wynn.com> References: <20130219034649.5fb69bce@ivory.wynn.com> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Auth-Info: 15567@permanet.ie (plain) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 09:01:34 -0000 On Tue, 19 Feb 2013 03:46:49 -0500 Brett Wynkoop wrote: > Greeting- > > Just discovered a difference in network performance between the Pi and > the Bone. > > wynkoop@beaglebone:~ % ping prd7 > PING prd7.wynn.com (199.89.147.7): 56 data bytes > 64 bytes from 199.89.147.7: icmp_seq=0 ttl=64 time=2.170 ms > 64 bytes from 199.89.147.7: icmp_seq=1 ttl=64 time=1.131 ms > 64 bytes from 199.89.147.7: icmp_seq=2 ttl=64 time=0.977 ms > 64 bytes from 199.89.147.7: icmp_seq=3 ttl=64 time=1.052 ms > 64 bytes from 199.89.147.7: icmp_seq=4 ttl=64 time=1.217 ms > ^C > --- prd7.wynn.com ping statistics --- > 5 packets transmitted, 5 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.977/1.309/2.170/0.438 ms > wynkoop@beaglebone:~ % > root@fbsd-pi:~ # ping prd7 > PING prd7.wynn.com (199.89.147.7): 56 data bytes > 64 bytes from 199.89.147.7: icmp_seq=0 ttl=64 time=8.560 ms > 64 bytes from 199.89.147.7: icmp_seq=1 ttl=64 time=10.222 ms This is an artefact of the FreeBSD drivers for the pi - Linux on the pi gets sub millisecond ping times on my network while FreeBSD gets the same 10ms you've been seeing. I've been assuming that it has to do with not using DMA yet. -- Steve O'Hara-Smith From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 09:14:38 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9C548391 for ; Tue, 19 Feb 2013 09:14:38 +0000 (UTC) (envelope-from werner@thieprojects.ch) Received: from newton.metanet.ch (newton.metanet.ch [80.74.158.130]) by mx1.freebsd.org (Postfix) with ESMTP id E9E49A6A for ; Tue, 19 Feb 2013 09:14:37 +0000 (UTC) Received: (qmail 20058 invoked from network); 19 Feb 2013 10:14:36 +0100 Received: from 217-071-083-008.ip-tech.ch (HELO ?192.168.11.88?) (217.71.83.8) by newton.metanet.ch with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Feb 2013 10:14:36 +0100 Message-ID: <5123427E.4030607@thieprojects.ch> Date: Tue, 19 Feb 2013 10:14:38 +0100 From: Werner Thie User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: RPi hangs in bootloader References: <51227033.3070304@thieprojects.ch> 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 09:14:38 -0000 Hi now retracing the generated configuration which was autogenerated from Tim Kientzle's scripts: Content of the FAT boot partition: 20 -rwxr-xr-x 1 root wheel 17764 Feb 18 17:57 bootcode.bin 4 -rwxr-xr-x 1 root wheel 105 Feb 18 17:57 config.txt 8 -rwxr-xr-x 1 root wheel 5284 Feb 18 17:57 fixup.dat 4 -rwxr-xr-x 1 root wheel 2018 Feb 18 17:57 fixup_cd.dat 16 -rwxr-xr-x 1 root wheel 16032 Feb 18 17:57 loader.hel 2300 -rwxr-xr-x 1 root wheel 2353656 Feb 18 17:57 start.elf 516 -rwxr-xr-x 1 root wheel 526828 Feb 18 17:57 start_cd.elf 240 -rwxr-xr-x 1 root wheel 242830 Feb 18 17:57 ubldr 308 -rwxr-xr-x 1 root wheel 312848 Feb 18 17:57 uboot.img 4 -rwxr-xr-x 1 root wheel 170 Feb 18 17:57 uenv.txt Content of uEnv.txt: loadbootscript=fatload mmc 0 0x2000000 ubldr bootscript=bootelf 0x2000000 Content of config.txt: device_tree=devtree.dat device_tree_address=0x100 Content of /boot partition: 4 drwxr-xr-x 7 root wthie 512 Feb 18 18:03 . 4 drwxr-xr-x 18 wthie wthie 1024 Feb 18 17:58 .. 4 drwxr-xr-x 2 root wheel 512 Feb 18 17:57 defaults 4 drwxr-xr-x 2 root wheel 512 Feb 18 17:57 firmware 4 drwxr-xr-x 2 root wheel 512 Feb 18 17:57 kernel 16 -r--r--r-- 1 root wheel 16032 Feb 18 17:58 loader.help 4 -rw-r--r-- 1 root wthie 15 Feb 18 18:03 loader.rc 4 drwxr-xr-x 2 root wheel 512 Feb 18 17:57 modules 192 -r-xr-xr-x 1 root wheel 195172 Feb 18 17:58 ubldr 4 drwxr-xr-x 2 root wheel 512 Feb 18 17:57 zfs Content of /boot/loader.rc: fdt addr 0x100 The only thing which does not seem to fit is the mentioning of the file devtree.dat, which is nowhere to be found. Also, no log file in the work directory is referring to devtree.dat, which seems quite fishy to me. I cloned a fresh version of uboot as advised by Tim's script, according to git the u-boot-rpi is up to date, no changes made on my side. In freebsd-beaglebone/u-boot-rpi git describe --tags loadb_works-2174-g6709570 That's about the end of my analysis, I'm stumped again. Werner From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 11:24:02 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 198B9112 for ; Tue, 19 Feb 2013 11:24:02 +0000 (UTC) (envelope-from werner@thieprojects.ch) Received: from newton.metanet.ch (newton.metanet.ch [80.74.158.130]) by mx1.freebsd.org (Postfix) with ESMTP id 83EE26E9 for ; Tue, 19 Feb 2013 11:24:00 +0000 (UTC) Received: (qmail 15812 invoked from network); 19 Feb 2013 12:23:59 +0100 Received: from 217-071-083-008.ip-tech.ch (HELO ?192.168.11.88?) (217.71.83.8) by newton.metanet.ch with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Feb 2013 12:23:59 +0100 Message-ID: <512360D0.6020709@thieprojects.ch> Date: Tue, 19 Feb 2013 12:24:00 +0100 From: Werner Thie User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: RPi hangs in bootloader References: <51227033.3070304@thieprojects.ch> <5123427E.4030607@thieprojects.ch> In-Reply-To: <5123427E.4030607@thieprojects.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 11:24:02 -0000 Hi top posting in this case: The error is not in the log file, its spelled out on the console when building the image: : Partitioning the raw disk image at Tue Feb 19 07:35:07 CET 2013 md2 created Setting up boot partition Creating the FAT partition at Tue Feb 19 07:35:07 CET 2013 md2s1 added active set on md2s1 Mounting the virtual FAT partition beaglebsd.sh: dtc: not found Installing ubldr : After cloning anew from https://github.com/kientzle/freebsd-beaglebone.git It seems that in the case of the RPi build the dtc is not compiled anymore. My suspicion was right then, it all ends with a file amiss. With two places in the scripts which supposedly should/will build the devtree.dat file (one in board/RaspberryPi/setup.sh and the other in lib/freebsd.sh) it should now be possible to find out what's going wrong. Thxs for listening, Werner On 2/19/13 10:14 AM, Werner Thie wrote: > Hi > > now retracing the generated configuration which was autogenerated from > Tim Kientzle's scripts: > > Content of the FAT boot partition: > > 20 -rwxr-xr-x 1 root wheel 17764 Feb 18 17:57 bootcode.bin > 4 -rwxr-xr-x 1 root wheel 105 Feb 18 17:57 config.txt > 8 -rwxr-xr-x 1 root wheel 5284 Feb 18 17:57 fixup.dat > 4 -rwxr-xr-x 1 root wheel 2018 Feb 18 17:57 fixup_cd.dat > 16 -rwxr-xr-x 1 root wheel 16032 Feb 18 17:57 loader.hel > 2300 -rwxr-xr-x 1 root wheel 2353656 Feb 18 17:57 start.elf > 516 -rwxr-xr-x 1 root wheel 526828 Feb 18 17:57 start_cd.elf > 240 -rwxr-xr-x 1 root wheel 242830 Feb 18 17:57 ubldr > 308 -rwxr-xr-x 1 root wheel 312848 Feb 18 17:57 uboot.img > 4 -rwxr-xr-x 1 root wheel 170 Feb 18 17:57 uenv.txt > > Content of uEnv.txt: > > loadbootscript=fatload mmc 0 0x2000000 ubldr > bootscript=bootelf 0x2000000 > > Content of config.txt: > > device_tree=devtree.dat > device_tree_address=0x100 > > Content of /boot partition: > > 4 drwxr-xr-x 7 root wthie 512 Feb 18 18:03 . > 4 drwxr-xr-x 18 wthie wthie 1024 Feb 18 17:58 .. > 4 drwxr-xr-x 2 root wheel 512 Feb 18 17:57 defaults > 4 drwxr-xr-x 2 root wheel 512 Feb 18 17:57 firmware > 4 drwxr-xr-x 2 root wheel 512 Feb 18 17:57 kernel > 16 -r--r--r-- 1 root wheel 16032 Feb 18 17:58 loader.help > 4 -rw-r--r-- 1 root wthie 15 Feb 18 18:03 loader.rc > 4 drwxr-xr-x 2 root wheel 512 Feb 18 17:57 modules > 192 -r-xr-xr-x 1 root wheel 195172 Feb 18 17:58 ubldr > 4 drwxr-xr-x 2 root wheel 512 Feb 18 17:57 zfs > > Content of /boot/loader.rc: > > fdt addr 0x100 > > The only thing which does not seem to fit is the mentioning of the file > devtree.dat, which is nowhere to be found. Also, no log file in the work > directory is referring to devtree.dat, which seems quite fishy to me. > > I cloned a fresh version of uboot as advised by Tim's script, according > to git the u-boot-rpi is up to date, no changes made on my side. > > In freebsd-beaglebone/u-boot-rpi > git describe --tags > > loadb_works-2174-g6709570 > > That's about the end of my analysis, I'm stumped again. > > Werner > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 17:15:34 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BCF1A4D7 for ; Tue, 19 Feb 2013 17:15:34 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 910C3735 for ; Tue, 19 Feb 2013 17:15:34 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1JHFWwF074633; Tue, 19 Feb 2013 17:15:32 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id mjjgsin928d5xpxs4euifbvpf2; Tue, 19 Feb 2013 17:15:32 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: RPi hangs in bootloader Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <512360D0.6020709@thieprojects.ch> Date: Tue, 19 Feb 2013 09:15:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51227033.3070304@thieprojects.ch> <5123427E.4030607@thieprojects.ch> <512360D0.6020709@thieprojects.ch> To: Werner Thie X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 17:15:34 -0000 On your x86 build machine: $ cd /usr/src/usr.bin/dtc $ make $ make install I'll add some more checks to the build script to test for dtc. (As of a couple of weeks ago, dtc is now built and installed by default, so this issue should be less common going forward.) Thanks for the diagnosis. Tim On Feb 19, 2013, at 3:24 AM, Werner Thie wrote: > Hi >=20 > top posting in this case: >=20 > The error is not in the log file, its spelled out on the console when = building the image: >=20 > : > Partitioning the raw disk image at Tue Feb 19 07:35:07 CET 2013 > md2 created > Setting up boot partition > Creating the FAT partition at Tue Feb 19 07:35:07 CET 2013 > md2s1 added > active set on md2s1 > Mounting the virtual FAT partition > beaglebsd.sh: dtc: not found > Installing ubldr > : >=20 > After cloning anew from > https://github.com/kientzle/freebsd-beaglebone.git >=20 > It seems that in the case of the RPi build the dtc is not compiled = anymore. My suspicion was right then, it all ends with a file amiss. >=20 > With two places in the scripts which supposedly should/will build the = devtree.dat file (one in board/RaspberryPi/setup.sh and the other in = lib/freebsd.sh) it should now be possible to find out what's going = wrong. >=20 > Thxs for listening, Werner >=20 > On 2/19/13 10:14 AM, Werner Thie wrote: >> Hi >>=20 >> now retracing the generated configuration which was autogenerated = from >> Tim Kientzle's scripts: >>=20 >> Content of the FAT boot partition: >>=20 >> 20 -rwxr-xr-x 1 root wheel 17764 Feb 18 17:57 bootcode.bin >> 4 -rwxr-xr-x 1 root wheel 105 Feb 18 17:57 config.txt >> 8 -rwxr-xr-x 1 root wheel 5284 Feb 18 17:57 fixup.dat >> 4 -rwxr-xr-x 1 root wheel 2018 Feb 18 17:57 fixup_cd.dat >> 16 -rwxr-xr-x 1 root wheel 16032 Feb 18 17:57 loader.hel >> 2300 -rwxr-xr-x 1 root wheel 2353656 Feb 18 17:57 start.elf >> 516 -rwxr-xr-x 1 root wheel 526828 Feb 18 17:57 start_cd.elf >> 240 -rwxr-xr-x 1 root wheel 242830 Feb 18 17:57 ubldr >> 308 -rwxr-xr-x 1 root wheel 312848 Feb 18 17:57 uboot.img >> 4 -rwxr-xr-x 1 root wheel 170 Feb 18 17:57 uenv.txt >>=20 >> Content of uEnv.txt: >>=20 >> loadbootscript=3Dfatload mmc 0 0x2000000 ubldr >> bootscript=3Dbootelf 0x2000000 >>=20 >> Content of config.txt: >>=20 >> device_tree=3Ddevtree.dat >> device_tree_address=3D0x100 >>=20 >> Content of /boot partition: >>=20 >> 4 drwxr-xr-x 7 root wthie 512 Feb 18 18:03 . >> 4 drwxr-xr-x 18 wthie wthie 1024 Feb 18 17:58 .. >> 4 drwxr-xr-x 2 root wheel 512 Feb 18 17:57 defaults >> 4 drwxr-xr-x 2 root wheel 512 Feb 18 17:57 firmware >> 4 drwxr-xr-x 2 root wheel 512 Feb 18 17:57 kernel >> 16 -r--r--r-- 1 root wheel 16032 Feb 18 17:58 loader.help >> 4 -rw-r--r-- 1 root wthie 15 Feb 18 18:03 loader.rc >> 4 drwxr-xr-x 2 root wheel 512 Feb 18 17:57 modules >> 192 -r-xr-xr-x 1 root wheel 195172 Feb 18 17:58 ubldr >> 4 drwxr-xr-x 2 root wheel 512 Feb 18 17:57 zfs >>=20 >> Content of /boot/loader.rc: >>=20 >> fdt addr 0x100 >>=20 >> The only thing which does not seem to fit is the mentioning of the = file >> devtree.dat, which is nowhere to be found. Also, no log file in the = work >> directory is referring to devtree.dat, which seems quite fishy to me. >>=20 >> I cloned a fresh version of uboot as advised by Tim's script, = according >> to git the u-boot-rpi is up to date, no changes made on my side. >>=20 >> In freebsd-beaglebone/u-boot-rpi >> git describe --tags >>=20 >> loadb_works-2174-g6709570 >>=20 >> That's about the end of my analysis, I'm stumped again. >>=20 >> Werner >>=20 >>=20 >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 17:35:26 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DDAF4D2F; Tue, 19 Feb 2013 17:35:26 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 9F2F6863; Tue, 19 Feb 2013 17:35:26 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1JHZQfq074768; Tue, 19 Feb 2013 17:35:26 GMT (envelope-from kientzle@FreeBSD.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id xfxprprjeb9vkjhz33ta9j4nzn; Tue, 19 Feb 2013 17:35:26 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Subject: Re: RPi hangs in bootloader Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <1361235912.1164.55.camel@revolution.hippie.lan> Date: Tue, 19 Feb 2013 09:35:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51227033.3070304@thieprojects.ch> <1361235912.1164.55.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 17:35:26 -0000 On Feb 18, 2013, at 5:05 PM, Ian Lepore wrote: > On Mon, 2013-02-18 at 11:47 -0800, Tim Kientzle wrote: >>> I do not understand the FDT_ERR_BADMAGIC, the page = http://www.denx.de/wiki/DULG/UBootCmdFDT has a lot of those errors = listed in an example session but does not explain what the message = conveys? >>=20 >> To help me clarify my own understanding, I wrote a brief >> explanation of where we are with FDT handling that >> digs into how RPi boot handles FDT today and points >> out some of the work that still remains. >>=20 >=20 > While you're digging around in that area of the code... is there any = way > ubldr can find out from u-boot how it was loaded? I would love it if > ubldr could automatically set currdev=3Dnet0: if it was loaded via = dhcp or > tftp, and automatically use net0:/boot/loader.rc in that case as well. I believe this is possible, but it would require some C-level work on ubldr. (And I'm not using netbooting in my current dev environment, so I don't have a good way to test this right now.) The U-Boot API does provide a way to access the U-Boot environment variables. My work on ubldr right now is using this to get the FDT information from U-Boot. If I stumble across the specific hooks needed for this, I'll let you know. > The general thing I'm up to today is learning enough about ubldr to = use > it effectively, and ultimately to see if it can be used to load a > (semi-)generic kernel plus a set of modules you configure in = loader.rc. > I've just managed to do that by hand, now to see if loader.rc will > cooperate. Modulo bugs, this should all work. ubldr is just loader(8) with U-Boot API grafted underneath instead of a PC BIOS. So module loading and all the boot-time configuration hooks that people are used to on x86 should Just Work. A couple of folks have talked about turning on FICL in ubldr, that would open even more automation possibilities. Tim From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 17:58:17 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 57C8FCD2 for ; Tue, 19 Feb 2013 17:58:17 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by mx1.freebsd.org (Postfix) with ESMTP id 0F1B29F0 for ; Tue, 19 Feb 2013 17:58:16 +0000 (UTC) Received: from mh2.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh2.mail.rice.edu (Postfix) with ESMTP id 3C37750013E; Tue, 19 Feb 2013 11:58:16 -0600 (CST) Received: from mh2.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh2.mail.rice.edu (Postfix) with ESMTP id 3AFB4500133; Tue, 19 Feb 2013 11:58:16 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel Received: from mh2.mail.rice.edu ([127.0.0.1]) by mh2.mail.rice.edu (mh2.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 7cyFYro9JXtN; Tue, 19 Feb 2013 11:58:16 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id A03C6500128; Tue, 19 Feb 2013 11:58:15 -0600 (CST) Message-ID: <5123BD37.7070709@rice.edu> Date: Tue, 19 Feb 2013 11:58:15 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130127 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andrew Turner Subject: Re: svn commit: r246926 - in head/sys: arm/arm arm/include vm References: <201302180102.r1I12nMX049209@svn.freebsd.org> <20130219083455.176129d3@bender> In-Reply-To: <20130219083455.176129d3@bender> Content-Type: multipart/mixed; boundary="------------030801040601070908060009" Cc: "arm@freebsd.org" , Alan Cox X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 17:58:17 -0000 This is a multi-part message in MIME format. --------------030801040601070908060009 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 02/18/2013 13:34, Andrew Turner wrote: > On Mon, 18 Feb 2013 01:02:49 +0000 (UTC) > Alan Cox wrote: > >> Author: alc >> Date: Mon Feb 18 01:02:48 2013 >> New Revision: 246926 >> URL: http://svnweb.freebsd.org/changeset/base/246926 >> >> Log: >> On arm, like sparc64, the end of the kernel map varies from one >> type of machine to another. Therefore, VM_MAX_KERNEL_ADDRESS can't >> be a constant. Instead, #define it to be a variable, >> vm_max_kernel_address, just like we do on sparc64. > This looks to be broken on non-FDT ARM. There are still a number of > copies of initarm for older ports without FDT that will need > vm_max_kernel_address to be set. Thanks for pointing this out. I believe that the attached patch adds the necessary initialization to all of the non-FDT platforms. Since I had to edit most of the pmap_bootstrap() calls, I also eliminated the redundant second argument. Alan --------------030801040601070908060009 Content-Type: text/plain; charset=ISO-8859-15; name="arm_vm_max_kernel_address2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arm_vm_max_kernel_address2.patch" Index: arm/arm/machdep.c =================================================================== --- arm/arm/machdep.c (revision 246926) +++ arm/arm/machdep.c (working copy) @@ -1476,7 +1476,7 @@ initarm(struct arm_boot_params *abp) arm_intrnames_init(); arm_vector_init(ARM_VECTORS_HIGH, ARM_VEC_ALL); arm_dump_avail_init(memsize, sizeof(dump_avail) / sizeof(dump_avail[0])); - pmap_bootstrap(freemempos, vm_max_kernel_address, &kernel_l1pt); + pmap_bootstrap(freemempos, &kernel_l1pt); msgbufp = (void *)msgbufpv.pv_va; msgbufinit(msgbufp, msgbufsize); mutex_init(); Index: arm/arm/pmap-v6.c =================================================================== --- arm/arm/pmap-v6.c (revision 246926) +++ arm/arm/pmap-v6.c (working copy) @@ -1538,7 +1538,7 @@ pmap_alloc_specials(vm_offset_t *availp, int pages #define PMAP_STATIC_L2_SIZE 16 void -pmap_bootstrap(vm_offset_t firstaddr, vm_offset_t lastaddr, struct pv_addr *l1pt) +pmap_bootstrap(vm_offset_t firstaddr, struct pv_addr *l1pt) { static struct l1_ttable static_l1; static struct l2_dtable static_l2[PMAP_STATIC_L2_SIZE]; @@ -1554,7 +1554,7 @@ void int l1idx, l2idx, l2next = 0; PDEBUG(1, printf("firstaddr = %08x, lastaddr = %08x\n", - firstaddr, lastaddr)); + firstaddr, vm_max_kernel_address)); virtual_avail = firstaddr; kernel_pmap->pm_l1 = l1; @@ -1670,7 +1670,8 @@ void pmap_set_pt_cache_mode(kernel_l1pt, (vm_offset_t)csrc_pte); pmap_alloc_specials(&virtual_avail, 1, &cdstp, &cdst_pte); pmap_set_pt_cache_mode(kernel_l1pt, (vm_offset_t)cdst_pte); - size = ((lastaddr - pmap_curmaxkvaddr) + L1_S_OFFSET) / L1_S_SIZE; + size = ((vm_max_kernel_address - pmap_curmaxkvaddr) + L1_S_OFFSET) / + L1_S_SIZE; pmap_alloc_specials(&virtual_avail, round_page(size * L2_TABLE_SIZE_REAL) / PAGE_SIZE, &pmap_kernel_l2ptp_kva, NULL); @@ -1692,9 +1693,9 @@ void cpu_l2cache_wbinv_all(); virtual_avail = round_page(virtual_avail); - virtual_end = lastaddr; + virtual_end = vm_max_kernel_address; kernel_vm_end = pmap_curmaxkvaddr; - arm_nocache_startaddr = lastaddr; + arm_nocache_startaddr = vm_max_kernel_address; mtx_init(&cmtx, "TMP mappings mtx", NULL, MTX_DEF); pmap_set_pcb_pagedir(kernel_pmap, thread0.td_pcb); Index: arm/arm/pmap.c =================================================================== --- arm/arm/pmap.c (revision 246926) +++ arm/arm/pmap.c (working copy) @@ -2254,7 +2254,7 @@ extern struct mtx smallalloc_mtx; #endif void -pmap_bootstrap(vm_offset_t firstaddr, vm_offset_t lastaddr, struct pv_addr *l1pt) +pmap_bootstrap(vm_offset_t firstaddr, struct pv_addr *l1pt) { static struct l1_ttable static_l1; static struct l2_dtable static_l2[PMAP_STATIC_L2_SIZE]; @@ -2270,7 +2270,7 @@ void int l1idx, l2idx, l2next = 0; PDEBUG(1, printf("firstaddr = %08x, lastaddr = %08x\n", - firstaddr, lastaddr)); + firstaddr, vm_max_kernel_address)); virtual_avail = firstaddr; kernel_pmap->pm_l1 = l1; @@ -2388,7 +2388,8 @@ void pmap_set_pt_cache_mode(kernel_l1pt, (vm_offset_t)csrc_pte); pmap_alloc_specials(&virtual_avail, 1, &cdstp, &cdst_pte); pmap_set_pt_cache_mode(kernel_l1pt, (vm_offset_t)cdst_pte); - size = ((lastaddr - pmap_curmaxkvaddr) + L1_S_OFFSET) / L1_S_SIZE; + size = ((vm_max_kernel_address - pmap_curmaxkvaddr) + L1_S_OFFSET) / + L1_S_SIZE; pmap_alloc_specials(&virtual_avail, round_page(size * L2_TABLE_SIZE_REAL) / PAGE_SIZE, &pmap_kernel_l2ptp_kva, NULL); @@ -2410,9 +2411,9 @@ void cpu_l2cache_wbinv_all(); virtual_avail = round_page(virtual_avail); - virtual_end = lastaddr; + virtual_end = vm_max_kernel_address; kernel_vm_end = pmap_curmaxkvaddr; - arm_nocache_startaddr = lastaddr; + arm_nocache_startaddr = vm_max_kernel_address; mtx_init(&cmtx, "TMP mappings mtx", NULL, MTX_DEF); #ifdef ARM_USE_SMALL_ALLOC Index: arm/at91/at91_machdep.c =================================================================== --- arm/at91/at91_machdep.c (revision 246900) +++ arm/at91/at91_machdep.c (working copy) @@ -624,7 +624,8 @@ initarm(struct arm_boot_params *abp) pmap_curmaxkvaddr = afterkern + L1_S_SIZE * (KERNEL_PT_KERN_NUM - 1); arm_dump_avail_init(memsize, sizeof(dump_avail)/sizeof(dump_avail[0])); - pmap_bootstrap(freemempos, KERNVIRTADDR + 3 * memsize, &kernel_l1pt); + vm_max_kernel_address = KERNVIRTADDR + 3 * memsize; + pmap_bootstrap(freemempos, &kernel_l1pt); msgbufp = (void*)msgbufpv.pv_va; msgbufinit(msgbufp, msgbufsize); mutex_init(); Index: arm/econa/econa_machdep.c =================================================================== --- arm/econa/econa_machdep.c (revision 246900) +++ arm/econa/econa_machdep.c (working copy) @@ -324,7 +324,8 @@ initarm(struct arm_boot_params *abp) pmap_curmaxkvaddr = afterkern + L1_S_SIZE * (KERNEL_PT_KERN_NUM - 1); arm_dump_avail_init(memsize, sizeof(dump_avail) / sizeof(dump_avail[0])); - pmap_bootstrap(freemempos, KERNVIRTADDR + 3 * memsize, &kernel_l1pt); + vm_max_kernel_address = KERNVIRTADDR + 3 * memsize; + pmap_bootstrap(freemempos, &kernel_l1pt); msgbufp = (void*)msgbufpv.pv_va; msgbufinit(msgbufp, msgbufsize); Index: arm/include/pmap.h =================================================================== --- arm/include/pmap.h (revision 246900) +++ arm/include/pmap.h (working copy) @@ -222,7 +222,7 @@ extern vm_paddr_t phys_avail[]; extern vm_offset_t virtual_avail; extern vm_offset_t virtual_end; -void pmap_bootstrap(vm_offset_t, vm_offset_t, struct pv_addr *); +void pmap_bootstrap(vm_offset_t firstaddr, struct pv_addr *l1pt); int pmap_change_attr(vm_offset_t, vm_size_t, int); void pmap_kenter(vm_offset_t va, vm_paddr_t pa); void pmap_kenter_nocache(vm_offset_t va, vm_paddr_t pa); Index: arm/s3c2xx0/s3c24x0_machdep.c =================================================================== --- arm/s3c2xx0/s3c24x0_machdep.c (revision 246900) +++ arm/s3c2xx0/s3c24x0_machdep.c (working copy) @@ -386,7 +386,8 @@ initarm(struct arm_boot_params *abp) pmap_curmaxkvaddr = afterkern + 0x100000 * (KERNEL_PT_KERN_NUM - 1); arm_dump_avail_init(memsize, sizeof(dump_avail) / sizeof(dump_avail[0])); - pmap_bootstrap(freemempos, KERNVIRTADDR + 3 * memsize, &kernel_l1pt); + vm_max_kernel_address = KERNVIRTADDR + 3 * memsize; + pmap_bootstrap(freemempos, &kernel_l1pt); msgbufp = (void*)msgbufpv.pv_va; msgbufinit(msgbufp, msgbufsize); mutex_init(); Index: arm/sa11x0/assabet_machdep.c =================================================================== --- arm/sa11x0/assabet_machdep.c (revision 246900) +++ arm/sa11x0/assabet_machdep.c (working copy) @@ -381,7 +381,8 @@ initarm(struct arm_boot_params *abp) dump_avail[3] = phys_avail[3] = 0; mutex_init(); - pmap_bootstrap(freemempos, 0xd0000000, &kernel_l1pt); + vm_max_kernel_address = 0xd0000000; + pmap_bootstrap(freemempos, &kernel_l1pt); init_param2(physmem); kdb_init(); Index: arm/xscale/i80321/ep80219_machdep.c =================================================================== --- arm/xscale/i80321/ep80219_machdep.c (revision 246900) +++ arm/xscale/i80321/ep80219_machdep.c (working copy) @@ -368,8 +368,8 @@ initarm(struct arm_boot_params *abp) dump_avail[2] = 0; dump_avail[3] = 0; - pmap_bootstrap(pmap_curmaxkvaddr, - 0xd0000000, &kernel_l1pt); + vm_max_kernel_address = 0xd0000000; + pmap_bootstrap(pmap_curmaxkvaddr, &kernel_l1pt); msgbufp = (void*)msgbufpv.pv_va; msgbufinit(msgbufp, msgbufsize); mutex_init(); Index: arm/xscale/i80321/iq31244_machdep.c =================================================================== --- arm/xscale/i80321/iq31244_machdep.c (revision 246900) +++ arm/xscale/i80321/iq31244_machdep.c (working copy) @@ -369,8 +369,8 @@ initarm(struct arm_boot_params *abp) dump_avail[2] = 0; dump_avail[3] = 0; - pmap_bootstrap(pmap_curmaxkvaddr, - 0xd0000000, &kernel_l1pt); + vm_max_kernel_address = 0xd0000000; + pmap_bootstrap(pmap_curmaxkvaddr, &kernel_l1pt); msgbufp = (void*)msgbufpv.pv_va; msgbufinit(msgbufp, msgbufsize); mutex_init(); Index: arm/xscale/i8134x/crb_machdep.c =================================================================== --- arm/xscale/i8134x/crb_machdep.c (revision 246900) +++ arm/xscale/i8134x/crb_machdep.c (working copy) @@ -347,8 +347,8 @@ initarm(struct arm_boot_params *abp) dump_avail[2] = 0; dump_avail[3] = 0; - pmap_bootstrap(pmap_curmaxkvaddr, - 0xd0000000, &kernel_l1pt); + vm_max_kernel_address = 0xd0000000; + pmap_bootstrap(pmap_curmaxkvaddr, &kernel_l1pt); msgbufp = (void*)msgbufpv.pv_va; msgbufinit(msgbufp, msgbufsize); mutex_init(); Index: arm/xscale/ixp425/avila_machdep.c =================================================================== --- arm/xscale/ixp425/avila_machdep.c (revision 246900) +++ arm/xscale/ixp425/avila_machdep.c (working copy) @@ -432,7 +432,8 @@ initarm(struct arm_boot_params *abp) pmap_curmaxkvaddr = afterkern + PAGE_SIZE; arm_dump_avail_init(memsize, sizeof(dump_avail) / sizeof(dump_avail[0])); - pmap_bootstrap(pmap_curmaxkvaddr, 0xd0000000, &kernel_l1pt); + vm_max_kernel_address = 0xd0000000; + pmap_bootstrap(pmap_curmaxkvaddr, &kernel_l1pt); msgbufp = (void*)msgbufpv.pv_va; msgbufinit(msgbufp, msgbufsize); mutex_init(); Index: arm/xscale/pxa/pxa_machdep.c =================================================================== --- arm/xscale/pxa/pxa_machdep.c (revision 246900) +++ arm/xscale/pxa/pxa_machdep.c (working copy) @@ -365,7 +365,8 @@ initarm(struct arm_boot_params *abp) } dump_avail[i] = 0; dump_avail[i] = 0; - pmap_bootstrap(pmap_curmaxkvaddr, 0xd0000000, &kernel_l1pt); + vm_max_kernel_address = 0xd0000000; + pmap_bootstrap(pmap_curmaxkvaddr, &kernel_l1pt); msgbufp = (void*)msgbufpv.pv_va; msgbufinit(msgbufp, msgbufsize); mutex_init(); --------------030801040601070908060009-- From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 17:59:00 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7345DD0B; Tue, 19 Feb 2013 17:59:00 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 1C7C69F9; Tue, 19 Feb 2013 17:58:59 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1JHwxRo007031; Tue, 19 Feb 2013 10:58:59 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1JHwuMY050113; Tue, 19 Feb 2013 10:58:56 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: RPi hangs in bootloader From: Ian Lepore To: Tim Kientzle In-Reply-To: References: <51227033.3070304@thieprojects.ch> <1361235912.1164.55.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Feb 2013 10:58:56 -0700 Message-ID: <1361296736.1164.75.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 17:59:00 -0000 On Tue, 2013-02-19 at 09:35 -0800, Tim Kientzle wrote: > On Feb 18, 2013, at 5:05 PM, Ian Lepore wrote: > > On Mon, 2013-02-18 at 11:47 -0800, Tim Kientzle wrote: > >>> I do not understand the FDT_ERR_BADMAGIC, the page http://www.denx.de/wiki/DULG/UBootCmdFDT has a lot of those errors listed in an example session but does not explain what the message conveys? > >> > >> To help me clarify my own understanding, I wrote a brief > >> explanation of where we are with FDT handling that > >> digs into how RPi boot handles FDT today and points > >> out some of the work that still remains. > >> > > > > While you're digging around in that area of the code... is there any way > > ubldr can find out from u-boot how it was loaded? I would love it if > > ubldr could automatically set currdev=net0: if it was loaded via dhcp or > > tftp, and automatically use net0:/boot/loader.rc in that case as well. > > I believe this is possible, but it would require some C-level > work on ubldr. (And I'm not using netbooting in my current > dev environment, so I don't have a good way to test this > right now.) > > The U-Boot API does provide a way to access the U-Boot > environment variables. My work on ubldr right now is > using this to get the FDT information from U-Boot. > > If I stumble across the specific hooks needed for this, > I'll let you know. > > > The general thing I'm up to today is learning enough about ubldr to use > > it effectively, and ultimately to see if it can be used to load a > > (semi-)generic kernel plus a set of modules you configure in loader.rc. > > I've just managed to do that by hand, now to see if loader.rc will > > cooperate. > > Modulo bugs, this should all work. ubldr is just loader(8) with > U-Boot API grafted underneath instead of a PC BIOS. > So module loading and all the boot-time configuration > hooks that people are used to on x86 should Just Work. > > A couple of folks have talked about turning on FICL > in ubldr, that would open even more automation > possibilities. That's what I'm testing at this very moment. So far it seems to be working fine, except that I notice "fdt addr 0x0100" has to be in the loader.rc file, it doesn't work if it's in the loader.conf file. So I'm off to see what's up with that... -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 18:23:55 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A7B61904; Tue, 19 Feb 2013 18:23:55 +0000 (UTC) (envelope-from iain@g7iii.net) Received: from hal.g7iii.net (hal.g7iii.net [64.22.109.39]) by mx1.freebsd.org (Postfix) with ESMTP id 853ECBE9; Tue, 19 Feb 2013 18:23:55 +0000 (UTC) Received: from [192.168.39.76] (157.17.187.81.in-addr.arpa [81.187.17.157]) by hal.g7iii.net (Postfix) with ESMTP id 42AD5208F5; Tue, 19 Feb 2013 18:23:48 +0000 (UTC) Message-ID: <5123C333.5090602@g7iii.net> Date: Tue, 19 Feb 2013 18:23:47 +0000 From: Iain Young User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Tim Kientzle Subject: Re: Beaglebone Serial Ports Progress References: <511E1A08.4020105@g7iii.net> <5120A7AD.40903@g7iii.net> <73B8F088-EE5C-471D-AEED-52D4E45153DA@kientzle.com> In-Reply-To: <73B8F088-EE5C-471D-AEED-52D4E45153DA@kientzle.com> Content-Type: multipart/mixed; boundary="------------030408000305050501040908" Cc: freebsd-arm@freebsd.org, Damjan Marion X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 18:23:55 -0000 This is a multi-part message in MIME format. --------------030408000305050501040908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 17/02/13 18:21, Tim Kientzle wrote: >> >> Before I send the full patch what are the FreeBSD standards wrt the >> above lines in am335x_prcm_attach() ? Should I leave as is ? Create >> a separate function, and call it from am335x_prcm_attach() ? Or do I >> create a #define in the same file, and create functions for each UART, >> as I see some other clocks do ? > > It would require a little more work but I think the natural > place to put this would be to put > > uart1: serial@48022000 { > ... > clocks = "UART1"; > clock-parent = <&PRCM>; > }; > > in the FDT (which is a straightforward way of > saying "this device needs the PRCM to turn on > "UART1" clocks) and then figure out how to > actually support it. ;-) > > This is the same issue that we've been discussing > for pinmux, and the above is essentially the same solution > being discussed for pinmux. > > It's not yet clear to me where/how this info should be acted on. > It could actually be handled in the simplebus driver, I > think, without modifying (in this case) the UART driver code > at all. That would need only a standard way for simplebus to > communicate the clock-init string to the designated > clock handler. In that case, I shall leave things as they are for now, until a consensus is come to, and other, better kernel coders than I have written the necessary glue :) In the meantime, the patch is attached here for anyone that wants to use the other 5 UARTS (note UART3's TX and RX lines are not brought out, but it's CTS and RTS lines can still be used for other things. The patch is in two parts, one for beaglebone.dts, and one for am335x_prcm.c. You need to apply both. patch -p0 from /usr/src or patch -p1 from /usr/src/sys should suffice. Thanks to all those that helped point me in the right direction, I couldn't have got the UARTs working without your help. Iain --------------030408000305050501040908 Content-Type: text/x-patch; name="beaglebone.dts.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="beaglebone.dts.patch" --- sys/boot/fdt/dts/beaglebone.dts.orig 2013-02-19 17:59:18.000000000 +0000 +++ sys/boot/fdt/dts/beaglebone.dts.irp 2013-02-19 17:53:38.000000000 +0000 @@ -39,6 +39,11 @@ aliases { soc = &SOC; uart0 = &uart0; + uart1 = &uart1; + uart2 = &uart2; + uart3 = &uart3; + uart4 = &uart4; + uart5 = &uart5; }; memory { @@ -127,6 +132,14 @@ "LCD_DATA5", "gpio2_11", "input_pulldown", "LCD_DATA6", "gpio2_12", "input_pulldown", "LCD_DATA7", "gpio2_13", "input_pulldown", + "LCD_DATA8", "uart5_txd","output", + "LCD_DATA9", "uart5_rxd","input_pulldown", + "LCD_DATA10", "uart3_ctsn", "input_pulldown", + "LCD_DATA11", "uart3_rtsn", "output", + "LCD_DATA12", "uart4_ctsn", "input_pulldown", + "LCD_DATA13", "uart4_rtsn", "output", + "LCD_DATA14", "uart5_ctsn", "input_pulldown", + "LCD_DATA15", "uart5_rtsn", "output", "LCD_VSYNC", "gpio2_22", "input_pulldown", "LCD_HSYNC", "gpio2_23", "input_pulldown", "LCD_PCLK", "gpio2_24", "input_pulldown", @@ -142,7 +155,20 @@ "GPMC_A2", "ehrpwm1A", "output", "GPMC_A3", "ehrpwm1B", "output", "GPMC_AD8", "ehrpwm2A", "output", - "GPMC_AD9", "ehrpwm2B", "output"; + "GPMC_AD9", "ehrpwm2B", "output", + "I2C2_SCL","uart1_rtsn","output", + "I2C2_SDA","uart1_ctsn","input_pulldown", + "UART1_RXD","uart1_rxd","input", + "UART1_TXD","uart1_txd","output", + "SPI0_D0","uart2_txd","output", + "SPI0_SCLK","uart2_rxd","input_pulldown", + "UART2_RXD","uart2_rxd","input_pulldown", + "GPMC_WAIT0","uart4_rxd","input_pulldown", + "GPMC_WPN","uart4_txd","output", + "UART5_TXD","uart2_ctsn","input_pulldown", + "UART5_RXD","uart2_rtsn","output"; + + }; prcm@44E00000 { @@ -187,7 +213,52 @@ reg-shift = <2>; interrupts = < 72 >; interrupt-parent = <&AINTC>; - clock-frequency = < 48000000 >; /* FIXME */ + clock-frequency = < 48000000 >; + }; + + uart1: serial@48022000 { + compatible = "ns16550"; + reg = <0x48022000 0x1000>; + reg-shift = <2>; + interrupts = < 73 >; + interrupt-parent = <&AINTC>; + clock-frequency = < 48000000 >; + }; + + uart2: serial@48024000 { + compatible = "ns16550"; + reg = <0x48024000 0x1000>; + reg-shift = <2>; + interrupts = < 74 >; + interrupt-parent = <&AINTC>; + clock-frequency = < 48000000 >; + }; + + uart3: serial@481a6000 { + compatible = "ns16550"; + reg = <0x481A6000 0x1000>; + reg-shift = <2>; + interrupts = < 44 >; + interrupt-parent = <&AINTC>; + clock-frequency = < 48000000 >; + }; + + uart4: serial@481a8000 { + compatible = "ns16550"; + reg = <0x481A8000 0x1000>; + reg-shift = <2>; + interrupts = < 45 >; + interrupt-parent = <&AINTC>; + clock-frequency = < 48000000 >; + }; + + uart5: serial@481a8000 { + compatible = "ns16550"; + reg = <0x481AA000 0x1000>; + reg-shift = <2>; + interrupts = < 46 >; + interrupt-parent = <&AINTC>; + clock-frequency = < 48000000 >; }; edma3@49000000 { --------------030408000305050501040908 Content-Type: text/x-patch; name="am335x_prcm_uart_clks.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="am335x_prcm_uart_clks.patch" --- sys/arm/ti/am335x/am335x_prcm.c.orig 2013-02-19 18:03:48.000000000 +0000 +++ sys/arm/ti/am335x/am335x_prcm.c 2013-02-19 18:03:42.000000000 +0000 @@ -314,6 +314,12 @@ device_printf(dev, "Clocks: System %u.%01u MHz, CPU %u MHz\n", sysclk/1000000, (sysclk % 1000000)/100000, fclk/1000000); + prcm_write_4(0x6c, 2); /* UART 1 ENABLE */ + prcm_write_4(0x70, 2); /* UART 2 ENABLE */ + prcm_write_4(0x74, 2); /* UART 3 ENABLE */ + prcm_write_4(0x78, 2); /* UART 4 ENABLE */ + prcm_write_4(0x38, 2); /* UART 5 ENABLE */ + return (0); } --------------030408000305050501040908-- From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 09:31:26 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 647D7267 for ; Wed, 20 Feb 2013 09:31:26 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp3.clear.net.nz (smtp3.clear.net.nz [203.97.33.64]) by mx1.freebsd.org (Postfix) with ESMTP id 3501AEC4 for ; Wed, 20 Feb 2013 09:31:26 +0000 (UTC) Received: from mxin1-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MII001FRIFIXR00@smtp3.clear.net.nz> for arm@freebsd.org; Wed, 20 Feb 2013 22:31:19 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO bender) ([202.0.48.19]) by smtpin1.paradise.net.nz with ESMTP; Wed, 20 Feb 2013 22:31:10 +1300 Date: Wed, 20 Feb 2013 22:31:05 +1300 From: Andrew Turner Subject: Re: svn commit: r246926 - in head/sys: arm/arm arm/include vm In-reply-to: <5123BD37.7070709@rice.edu> To: Alan Cox Message-id: <20130220223105.4b71c62f@bender> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit References: <201302180102.r1I12nMX049209@svn.freebsd.org> <20130219083455.176129d3@bender> <5123BD37.7070709@rice.edu> Cc: "arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 09:31:26 -0000 On Tue, 19 Feb 2013 11:58:15 -0600 Alan Cox wrote: > On 02/18/2013 13:34, Andrew Turner wrote: > > On Mon, 18 Feb 2013 01:02:49 +0000 (UTC) > > Alan Cox wrote: > > > >> Author: alc > >> Date: Mon Feb 18 01:02:48 2013 > >> New Revision: 246926 > >> URL: http://svnweb.freebsd.org/changeset/base/246926 > >> > >> Log: > >> On arm, like sparc64, the end of the kernel map varies from one > >> type of machine to another. Therefore, VM_MAX_KERNEL_ADDRESS can't > >> be a constant. Instead, #define it to be a variable, > >> vm_max_kernel_address, just like we do on sparc64. > > This looks to be broken on non-FDT ARM. There are still a number of > > copies of initarm for older ports without FDT that will need > > vm_max_kernel_address to be set. > > Thanks for pointing this out. I believe that the attached patch adds > the necessary initialization to all of the non-FDT platforms. Since I > had to edit most of the pmap_bootstrap() calls, I also eliminated the > redundant second argument. That patch looks correct and produces what appears to be a correct value on at91. Without the patch I get: # sysctl vm.max_kernel_address vm.max_kernel_address: 0 With the patch I get: # sysctl vm.max_kernel_address vm.max_kernel_address: 3623911424 I've checked this value for this board to be correct for the method at91 uses to calculate vm_max_kernel_address. Andrew From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 12:21:22 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 76466328; Wed, 20 Feb 2013 12:21:22 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 3B3B1D95; Wed, 20 Feb 2013 12:21:22 +0000 (UTC) Received: from terran (unknown [192.168.99.1]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPA id 7D4C3C493A; Wed, 20 Feb 2013 14:21:20 +0200 (EET) Date: Wed, 20 Feb 2013 14:21:40 +0200 From: Aleksandr Rybalko To: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org Subject: SPI, _sz fields in struct spi_command Message-Id: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 12:21:22 -0000 Hello ARM and MIPS hackers! Sorry for cross-post, but we have supported SPI devices on both platforms (and seems no others). Anyone know any reasons to keep both TX and RX _sz fields with same values? sys/dev/flash/at45d.c static int at45d_get_mfg_info(device_t dev, uint8_t *resp) { ... cmd.tx_cmd_sz = cmd.rx_cmd_sz = 5; ... } or sys/dev/flash/mx25l.c static int mx25l_read(device_t dev, off_t offset, caddr_t data, off_t count) { ... cmd.tx_cmd_sz = 5; cmd.rx_cmd_sz = 5; ... } That always require second but unused buffer or writable tx buffer. And not all controllers able to TX with RX same time. (at least rt305x can't). So if nobody have any objections, I will update drivers (SPI controllers and SPI attached devices) to set unused _sz field to zero. IIRC, I will require help with AT91 controller update, at least with testing. Thanks. WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 14:15:52 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1382859B for ; Wed, 20 Feb 2013 14:15:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x234.google.com (ie-in-x0234.1e100.net [IPv6:2607:f8b0:4001:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id DB4A370A for ; Wed, 20 Feb 2013 14:15:51 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id bn7so9743245ieb.39 for ; Wed, 20 Feb 2013 06:15:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=O8Jeiq/iupp3/DNz14CvZFGlsEnTE3MXGh9GIdzcqD4=; b=GB1shHKeOhIF+R2lHzqKDBNQaf/pyCgWuKi2bQ5vL11/axDpUYSQF7UcLn1aBNX0LJ pAGBsUAGCMyzCoPiHR76xsl/F2vJ7kjFqPCPP7ShO9iV8V3SSvhOQPWmYnnCCsuFnQy8 lISOt9OLlnf2Cl+2wOWsR7gxkZgGFGKTRfAxUIyMgwS8OQgZxDYpuSZ6dRCYRPAROdf5 RYzh2rX6XsUv1S0abtgMBhTbVhf648K8K1WZx3PEBkFH8jEtgpLaB2E9MQTiZOKZWWYW E5LB1mT1PvNNs2dgRFXR+EP0zoXzESg2FOYiwUPEMhSuCU72gWfB86ZxNuzB/Hn3yzBH eNpg== X-Received: by 10.43.8.200 with SMTP id ot8mr9298733icb.11.1361369751261; Wed, 20 Feb 2013 06:15:51 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id wv1sm13816863igb.0.2013.02.20.06.15.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 06:15:50 -0800 (PST) Sender: Warner Losh Subject: Re: SPI, _sz fields in struct spi_command Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> Date: Wed, 20 Feb 2013 07:15:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmHO2XbuFLZvs+bXJc4P9i0a7Jm77B8choifBEnCTgiK6FeGqMIiRQZAi43pHRGQczF4r7E Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 14:15:52 -0000 On Feb 20, 2013, at 5:21 AM, Aleksandr Rybalko wrote: > Hello ARM and MIPS hackers! >=20 > Sorry for cross-post, but we have supported SPI devices on both > platforms (and seems no others). >=20 > Anyone know any reasons to keep both TX and RX _sz fields with same > values? I wrote them to be separate for a reason.... I think I'd thought = there'd be cases when you'd want to throw away the results or transmit = garbage... I can't think of why right now... > sys/dev/flash/at45d.c > static int > at45d_get_mfg_info(device_t dev, uint8_t *resp) > { > ... > cmd.tx_cmd_sz =3D cmd.rx_cmd_sz =3D 5; > ... > } >=20 > or sys/dev/flash/mx25l.c > static int > mx25l_read(device_t dev, off_t offset, caddr_t data, off_t count) > { > ... > cmd.tx_cmd_sz =3D 5; > cmd.rx_cmd_sz =3D 5; > ... > } >=20 > That always require second but unused buffer or writable tx buffer. = And > not all controllers able to TX with RX same time. (at least rt305x > can't). So if nobody have any objections, I will update drivers (SPI > controllers and SPI attached devices) to set unused _sz field to zero. > IIRC, I will require help with AT91 controller update, at least with > testing. The AT91, I think, required a minimum size, which is why the at45d = driver set it I think.. I can't imagine an SPI controller that can't do both, because when you = write something with SPI, you usually have to read back the status at = the same time... Warner > Thanks. >=20 > WBW > --=20 > Aleksandr Rybalko > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to = "freebsd-mips-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 14:32:27 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3C74ADA9; Wed, 20 Feb 2013 14:32:27 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id C23C87EF; Wed, 20 Feb 2013 14:32:26 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1KEWDUH022958; Wed, 20 Feb 2013 07:32:19 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1KEWAKT051400; Wed, 20 Feb 2013 07:32:10 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: SPI, _sz fields in struct spi_command From: Ian Lepore To: Warner Losh In-Reply-To: <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Feb 2013 07:32:10 -0700 Message-ID: <1361370730.1185.10.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Aleksandr Rybalko , freebsd-arm@FreeBSD.org, freebsd-mips@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 14:32:27 -0000 On Wed, 2013-02-20 at 07:15 -0700, Warner Losh wrote: > On Feb 20, 2013, at 5:21 AM, Aleksandr Rybalko wrote: > > > Hello ARM and MIPS hackers! > > > > Sorry for cross-post, but we have supported SPI devices on both > > platforms (and seems no others). > > > > Anyone know any reasons to keep both TX and RX _sz fields with same > > values? > > I wrote them to be separate for a reason.... I think I'd thought there'd be cases when you'd want to throw away the results or transmit garbage... I can't think of why right now... > > > sys/dev/flash/at45d.c > > static int > > at45d_get_mfg_info(device_t dev, uint8_t *resp) > > { > > ... > > cmd.tx_cmd_sz = cmd.rx_cmd_sz = 5; > > ... > > } > > > > or sys/dev/flash/mx25l.c > > static int > > mx25l_read(device_t dev, off_t offset, caddr_t data, off_t count) > > { > > ... > > cmd.tx_cmd_sz = 5; > > cmd.rx_cmd_sz = 5; > > ... > > } > > > > That always require second but unused buffer or writable tx buffer. And > > not all controllers able to TX with RX same time. (at least rt305x > > can't). So if nobody have any objections, I will update drivers (SPI > > controllers and SPI attached devices) to set unused _sz field to zero. > > IIRC, I will require help with AT91 controller update, at least with > > testing. > > The AT91, I think, required a minimum size, which is why the at45d driver set it I think.. > > I can't imagine an SPI controller that can't do both, because when you write something with SPI, you usually have to read back the status at the same time... > > Warner I think with at91 you really must do same-sized xfers in both directions or you'll get underflow/overflow errors from the hardware. It might be possible to just ignore the error, but even then the only useful way the xfer sizes could be different is one of them would be zero. Different non-zero sizes just don't make sense. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 14:34:41 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6D481FF8 for ; Wed, 20 Feb 2013 14:34:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gg0-x22a.google.com (gg-in-x022a.1e100.net [IPv6:2607:f8b0:4002:c02::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 3484A81E for ; Wed, 20 Feb 2013 14:34:41 +0000 (UTC) Received: by mail-gg0-f170.google.com with SMTP id k4so1017367ggn.29 for ; Wed, 20 Feb 2013 06:34:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=CfxLiBkDogwmfMBNAqUcez0T4zMSq1Zl8A51IBnyml8=; b=fRNHAT2QVRtf1GgX0P0OksSHveLjDUX0w9XM2shmbn6IUPIi31el07bV1fBGAc92oh 6R7oN8jpXOEQKtowLNAZ7NI+aOtLkZ1iYIiG/TJx8pHxMrc6GBsAAi1gOvnnTvslAmek uMpY0C9oY2VW1iEMRcPCpyIZSGFbUzzXiwdhsxaOx1T0fJkft/nUvyJgMB1b+jhKX40h gMnm1plVmnqeEDMYG8TRSFoLJFTqXrE9VEffPlhR22DwTMz1jL6Xqu7mcGC7/VVzmZld ghUwHidRT2PrtiXH0ObclnnW1noVVQtMGBAhpB4jonlxazP65EYEZmGDAMLZfYcZE1lm P2qQ== X-Received: by 10.236.77.69 with SMTP id c45mr36575221yhe.65.1361370880254; Wed, 20 Feb 2013 06:34:40 -0800 (PST) Received: from [10.30.30.100] ([209.117.142.2]) by mx.google.com with ESMTPS id t8sm69514043anj.2.2013.02.20.06.34.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 06:34:39 -0800 (PST) Sender: Warner Losh Subject: Re: SPI, _sz fields in struct spi_command Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1361370730.1185.10.camel@revolution.hippie.lan> Date: Wed, 20 Feb 2013 07:34:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5C3022E6-AEDB-4403-B5C1-E6EA6F9451EE@bsdimp.com> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <1361370730.1185.10.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkeil9K5PLGRduxKAtxoXky3lwsTqWFvwM4FT/KxzjLT7zILc+Wb/MW2w3FbRxB/sIFgOhy Cc: Aleksandr Rybalko , freebsd-arm@FreeBSD.org, freebsd-mips@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 14:34:41 -0000 On Feb 20, 2013, at 7:32 AM, Ian Lepore wrote: > On Wed, 2013-02-20 at 07:15 -0700, Warner Losh wrote: >> On Feb 20, 2013, at 5:21 AM, Aleksandr Rybalko wrote: >>=20 >>> Hello ARM and MIPS hackers! >>>=20 >>> Sorry for cross-post, but we have supported SPI devices on both >>> platforms (and seems no others). >>>=20 >>> Anyone know any reasons to keep both TX and RX _sz fields with same >>> values? >>=20 >> I wrote them to be separate for a reason.... I think I'd thought = there'd be cases when you'd want to throw away the results or transmit = garbage... I can't think of why right now... >>=20 >>> sys/dev/flash/at45d.c >>> static int >>> at45d_get_mfg_info(device_t dev, uint8_t *resp) >>> { >>> ... >>> cmd.tx_cmd_sz =3D cmd.rx_cmd_sz =3D 5; >>> ... >>> } >>>=20 >>> or sys/dev/flash/mx25l.c >>> static int >>> mx25l_read(device_t dev, off_t offset, caddr_t data, off_t count) >>> { >>> ... >>> cmd.tx_cmd_sz =3D 5; >>> cmd.rx_cmd_sz =3D 5; >>> ... >>> } >>>=20 >>> That always require second but unused buffer or writable tx buffer. = And >>> not all controllers able to TX with RX same time. (at least rt305x >>> can't). So if nobody have any objections, I will update drivers (SPI >>> controllers and SPI attached devices) to set unused _sz field to = zero. >>> IIRC, I will require help with AT91 controller update, at least with >>> testing. >>=20 >> The AT91, I think, required a minimum size, which is why the at45d = driver set it I think.. >>=20 >> I can't imagine an SPI controller that can't do both, because when = you write something with SPI, you usually have to read back the status = at the same time... >>=20 >> Warner >=20 > I think with at91 you really must do same-sized xfers in both = directions > or you'll get underflow/overflow errors from the hardware. It might = be > possible to just ignore the error, but even then the only useful way = the > xfer sizes could be different is one of them would be zero. Different > non-zero sizes just don't make sense. Does 0 really work? I have a vague memory of trying to allow it when I = first wrote the driver and having it fail badly on the AT91RM9200... Warner Warner= From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 15:40:43 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B0CCDBF4; Wed, 20 Feb 2013 15:40:43 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id EC78FCC6; Wed, 20 Feb 2013 15:40:42 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id w5so3650741bku.41 for ; Wed, 20 Feb 2013 07:40:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=m+WdbAMqzsgRumh3e3jmtmrXXf8Dn7GRCzcUIjWWvjM=; b=g3Zi8GZrT1nGhqakwXTTu45AFl/m/7fUMcCe+WdXEWEIGoPRnFNVorx5Q7DZs3lQ5D SxXIb0jbR0FNxSrQm8wc+4zkRFZDqLrg6JuJg813+GfkMG/AtjWj3GGleMS8YMWI7hmY jElN1PkCJHXN9/UNiMcLCJ+z4XLmI0dOLFzpQtW+Efb1L+/L1RceB7s6sxZSHqOPKCah cjBKpj8a/aJ2AJRPp79WSSRXpwO6h2EN31X2hT4wX+uFGMs84HH1gvXCgdQUILpf0GQ5 SBs9h+js7aenKORNFtMhqjf84alT9pLk8FasDap4JQXiviISiorTCD0D/0/92HeJtVcC /OdQ== MIME-Version: 1.0 X-Received: by 10.204.157.150 with SMTP id b22mr8698173bkx.121.1361374835653; Wed, 20 Feb 2013 07:40:35 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.204.128.213 with HTTP; Wed, 20 Feb 2013 07:40:35 -0800 (PST) In-Reply-To: <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> Date: Wed, 20 Feb 2013 10:40:35 -0500 X-Google-Sender-Auth: uAkPZC0wQlwq2st81GnLl6O_EMk Message-ID: Subject: Re: SPI, _sz fields in struct spi_command From: Patrick Kelsey To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: Aleksandr Rybalko , freebsd-arm@freebsd.org, freebsd-mips@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 15:40:43 -0000 On Wed, Feb 20, 2013 at 9:15 AM, Warner Losh wrote: > > > On Feb 20, 2013, at 5:21 AM, Aleksandr Rybalko wrote: > > > Hello ARM and MIPS hackers! > > > > Sorry for cross-post, but we have supported SPI devices on both > > platforms (and seems no others). > > > > Anyone know any reasons to keep both TX and RX _sz fields with same > > values? > > I wrote them to be separate for a reason.... I think I'd thought there'd be cases when you'd want to throw away the results or transmit garbage... I can't think of why right now... Per the spec, there is always a data bit available to be received on the bus for each data bit clocked out. Per the application, all of those bits are not always of interest. There are a few examples that exist in the world that I am aware of where the data transmitted or received on the SPI bus is of no interest to at least one participant in the transaction: 1. Some devices only implement SDI. One example would be a low cost/low pin count DAC such as the AD5662. In this case, the host would never be interested in the data received from the SPI bus during transmissions to the DAC. 2. Some devices only implement SDO. One example would be a low cost/low pin count ADC, such as the AD7091. In this case, the host could safely transmit undefined data on the bus when retrieving data from the ADC. 3. The protocol that rides on the SPI is in whole or in part half duplex. (a) The protocol for talking to MMC/SD cards over SPI is entirely half duplex. When information is sent to the card from the host, all bits received from the card during the transmission are discarded. When the host wants to read data from the card, it transmits all ones bits. (b) At least some Broadcom switch chips provide no meaningful receive data during command transmit. In (1) and (3) above, the drivers for those chips could usefully tell the SPI bus interface that they aren't interested in received data when transmitting to the SPI-attached devices, and certainly it would be at least a small convenience to such SPI interface consumers to have the lower level driver handle it. Since not all host-side SPI interface hardware supports discarding received data, to allow a zero-sized receive buffer in the command passed down, at least some SPI interface hardware drivers will have to dynamically allocate or maintain a static discard buffer and provide error responses for allocation-failure or transfer-too-large. Example (2) is equally easy to handle on either side of the SPI bus interface by pointing the transmit buffer pointer at the receive buffer. -Patrick From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 16:44:29 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8E78383B for ; Wed, 20 Feb 2013 16:44:29 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 6E9FE121 for ; Wed, 20 Feb 2013 16:44:28 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1KGiMmT084952 for freebsd-arm@freebsd.org; Wed, 20 Feb 2013 16:44:22 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id m5n7ai2rcfhqmwehg52a4nqge6; for freebsd-arm@freebsd.org; Wed, 20 Feb 2013 16:44:22 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: multipart/signed; boundary="Apple-Mail=_D2A51642-4BF0-481E-B00E-57F550686EE1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: No more compiled-in FDTs?! Date: Wed, 20 Feb 2013 08:44:21 -0800 Message-Id: <726FA1B6-C3D7-479B-A6E0-78E8CC49144A@freebsd.org> To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 16:44:29 -0000 --Apple-Mail=_D2A51642-4BF0-481E-B00E-57F550686EE1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii I've just committed changes so that BeagleBone images (built with my scripts) no longer use the compiled-in FDT. (This includes changes to FreeBSD ubldr, to U-Boot, and to my scripts.) RaspberryPi has not been using the compiled-in FDT for some time now. My goal is demonstrate booting a single kernel on multiple ARM boards, which necessarily precludes using a compiled-in FDT. I plan to soon comment-out the compiled-in FDT from the kernel configurations in FreeBSD SVN for both BeagleBone and RaspberryPi. For reference, you can load an FDT from U-Boot: $ fatload mmc 0:1
$ fdt addr
or from within ubldr: $ load -t fdt These commands can be easily automated. In either case, ubldr should now find the FDT and correctly pass it to the kernel. Tim --Apple-Mail=_D2A51642-4BF0-481E-B00E-57F550686EE1 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----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQEcBAEBAgAGBQJRJP1mAAoJEGMNyGo0rfFBhQ8H/37GKksj0sXZtW0vQiUgmFLU fAbUpFizj4GfOMbYsuR38w1Dg0m5rClcdFpo2r2r8bvyrrsOV8/ZXpHIka+ZXmgn WflM/2GUFuN4a54AFeYOPBQp6xaQxZ6WuOqgvSkMlfJjtKQh64jPIo5q+G+9cZlq y/F8RourIUP2LRlANu6RkCPu2d/irbZOtBHnv5WIcuIfXppgqqA7Z92NKG1yE+Je OfO8eJ6pNPMSM2KM68jjwxWNUbnkmdEZaIPHGZo4+ErOBqFW4GGOoOj+TnF/E12B 22cC3HDY4bJ9IMowiYypG5ndrIzCgiasGlWWMTgfVO/1K1JWaf1v40Z8/YTRadA= =mIJb -----END PGP SIGNATURE----- --Apple-Mail=_D2A51642-4BF0-481E-B00E-57F550686EE1-- From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 16:50:09 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C9AB5AE6 for ; Wed, 20 Feb 2013 16:50:09 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ye0-f174.google.com (mail-ye0-f174.google.com [209.85.213.174]) by mx1.freebsd.org (Postfix) with ESMTP id 9050E175 for ; Wed, 20 Feb 2013 16:50:09 +0000 (UTC) Received: by mail-ye0-f174.google.com with SMTP id m3so1485872yen.19 for ; Wed, 20 Feb 2013 08:50:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=chBPYwBieneeNEtTG/UofUDGTpOANtarbD8bS0WfarY=; b=AemtgI1sL4ls8YVzHxNlYl3XE9OFmrx6HRivdxmRhHs+OKMox6u15b7p/FE7R1Qdit PnYttK0Y81ultEJF4Ge0268G4Jle4FpP8i+W8QygS4tZi/vcWe1RbTuBtTRtgk695xcj ox0CWiAgtoOCtbhIYj+4iZiqV33Jyn8/2HcUs+JUF6Z9+nv4CPSgfXks9LogKvKqLYMO V1ufD6HekDijNbXJY8WqS3DyaHYJFAM11PuRswjDYIKk5fGa8MQaa0IKB784ez6POd3Z Rtvu0zaAELxDp5G6LctnID2B/uB9tGiiSgB1NnIyo3BlhxbWAy2Cavz8V023uu1wMOkm Iomg== X-Received: by 10.236.179.37 with SMTP id g25mr37315899yhm.47.1361379003403; Wed, 20 Feb 2013 08:50:03 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id t8sm69947748anj.2.2013.02.20.08.50.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 08:50:02 -0800 (PST) Sender: Warner Losh Subject: Re: No more compiled-in FDTs?! Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <726FA1B6-C3D7-479B-A6E0-78E8CC49144A@freebsd.org> Date: Wed, 20 Feb 2013 09:49:59 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <726FA1B6-C3D7-479B-A6E0-78E8CC49144A@freebsd.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnVvti6Al9DTjKd4T2VNXJjwNRxrDnZf5dBxG/pmmRvMfiV3awhT1dBlpe/Pbvr+uJGRvRo Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 16:50:09 -0000 On Feb 20, 2013, at 9:44 AM, Tim Kientzle wrote: > I've just committed changes so that BeagleBone images > (built with my scripts) no longer use the compiled-in FDT. > (This includes changes to FreeBSD ubldr, to U-Boot, > and to my scripts.) > > RaspberryPi has not been using the compiled-in FDT for > some time now. > > My goal is demonstrate booting a single kernel on > multiple ARM boards, which necessarily precludes > using a compiled-in FDT. > > I plan to soon comment-out the compiled-in FDT from > the kernel configurations in FreeBSD SVN for both > BeagleBone and RaspberryPi. > > For reference, you can load an FDT from U-Boot: > $ fatload mmc 0:1
> $ fdt addr
> > or from within ubldr: > $ load -t fdt > > These commands can be easily automated. In either > case, ubldr should now find the FDT and correctly pass > it to the kernel. That's awesome. Warner From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 17:01:43 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 069D4CC4; Wed, 20 Feb 2013 17:01:43 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id BD7501F6; Wed, 20 Feb 2013 17:01:42 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1KH1ZIH066975; Wed, 20 Feb 2013 12:01:36 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 20 Feb 2013 12:01:29 -0500 From: Brett Wynkoop To: Tim Kientzle Subject: Re: No more compiled-in FDTs?! Message-ID: <20130220120129.4a1934e9@ivory.wynn.com> In-Reply-To: <726FA1B6-C3D7-479B-A6E0-78E8CC49144A@freebsd.org> References: <726FA1B6-C3D7-479B-A6E0-78E8CC49144A@freebsd.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/OCP2zoUOB3KUXM5q+cjv7lb"; protocol="application/pgp-signature" Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:01:43 -0000 --Sig_/OCP2zoUOB3KUXM5q+cjv7lb Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 20 Feb 2013 08:44:21 -0800 Tim Kientzle wrote: > I've just committed changes so that BeagleBone images > (built with my scripts) no longer use the compiled-in FDT. > (This includes changes to FreeBSD ubldr, to U-Boot, > and to my scripts.) Can you put out a short message about how to update an existing BeagleBone without needing to build a new image on another box? This is great progress! -Brett --=20 wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 April 19, 1775 An English attempt to confiscate guns from Americans triggered a successful revolution...... Dear Congress, that's a hint. --Sig_/OCP2zoUOB3KUXM5q+cjv7lb Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iQEcBAEBAgAGBQJRJQFqAAoJEK6K3yrc+RuDWpYH/RptCbxlkcvX3sbfQwT6ucCB 6TRIdwSL4xBQjCUXUWAFrY+ZiiPWbZJlUA7KybqZpbdjzX7LDm4qYoZR6ELKzzfZ 7d6cwd2CQgjJoSkoQoUpTg9DY0B4HmJU7hRIt8+HGBXO0GOvUSA6+G6KFuK04Sv2 5Ify9zAo/V8X5AGDwXHw8Pn47rD4TN1TzkAIx4Gw4H+q50X+Cj/EMQe4EDJwQvMv pqhbud7ybr+PwZLOW05FQWWSKn71YEuipnQ7EdWg/03ucG99qByLCfvBkva9wNEP 2vumeLDxNG+rB4JdCV3s1mcARZRnqOxAWH1ARSLg+MsXRSc9r12Tbi8S9gL6Ts8= =xRCw -----END PGP SIGNATURE----- --Sig_/OCP2zoUOB3KUXM5q+cjv7lb-- From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 18:12:19 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0AF51BD4; Wed, 20 Feb 2013 18:12:19 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id A95C5941; Wed, 20 Feb 2013 18:12:18 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id r1KHjjfT009591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Feb 2013 18:45:46 +0100 (CET) (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 r1KHinKS040719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2013 18:44:50 +0100 (CET) (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 r1KHinwH010874; Wed, 20 Feb 2013 18:44:49 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id r1KHintA010873; Wed, 20 Feb 2013 18:44:49 +0100 (CET) (envelope-from ticso) Date: Wed, 20 Feb 2013 18:44:49 +0100 From: Bernd Walter To: Patrick Kelsey Subject: Re: SPI, _sz fields in struct spi_command Message-ID: <20130220174449.GB6976@cicely7.cicely.de> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Aleksandr Rybalko , freebsd-arm@freebsd.org, freebsd-mips@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:12:19 -0000 On Wed, Feb 20, 2013 at 10:40:35AM -0500, Patrick Kelsey wrote: > On Wed, Feb 20, 2013 at 9:15 AM, Warner Losh wrote: > > > > > > On Feb 20, 2013, at 5:21 AM, Aleksandr Rybalko wrote: > > > > > Hello ARM and MIPS hackers! > > > > > > Sorry for cross-post, but we have supported SPI devices on both > > > platforms (and seems no others). > > > > > > Anyone know any reasons to keep both TX and RX _sz fields with same > > > values? > > > > I wrote them to be separate for a reason.... I think I'd thought there'd be cases when you'd want to throw away the results or transmit garbage... I can't think of why right now... > > > Per the spec, there is always a data bit available to be received on > the bus for each data bit clocked out. Per the application, all of > those bits are not always of interest. There are a few examples that > exist in the world that I am aware of where the data transmitted or > received on the SPI bus is of no interest to at least one participant > in the transaction: > > 1. Some devices only implement SDI. One example would be a low > cost/low pin count DAC such as the AD5662. In this case, the host > would never be interested in the data received from the SPI bus during > transmissions to the DAC. > > 2. Some devices only implement SDO. One example would be a low > cost/low pin count ADC, such as the AD7091. In this case, the host > could safely transmit undefined data on the bus when retrieving data > from the ADC. > > 3. The protocol that rides on the SPI is in whole or in part half duplex. > (a) The protocol for talking to MMC/SD cards over SPI is entirely > half duplex. When information is sent to the card from the host, all > bits received from the card during the transmission are discarded. > When the host wants to read data from the card, it transmits all ones > bits. > (b) At least some Broadcom switch chips provide no meaningful > receive data during command transmit. The AT91 SPI always has data for both directions. It has a register for word to send and a register for words received. With DMA you tell to automatically fill/empty those registers from/to one memory region. You have two DMA buffers for each direction, so you can interleave. They are automatically switched and you can recofigure the other. If e.g. you only have something to send and only supply a DMA buffer for send data, then the RX register gets filled, but never emptied. There is no overflow in master mode, the controller just stops until you empty the register. You can either empty each time with single interrupt overhead or supply some DMA memory as bit bucket. Same with RX-only - you need to fill the send register with dummy data, so easiest is to supply a dummy DMA-buffer. Some devices expect the dummy send buffer to be filled with 0xff, so that they don't interet it as a command. Supplying dummy memory for DMA hurts for large transfers, but seems to be unavoidable with some hardware. With the AT91 SPI you can use smaller dummy buffers and interleave them to reduce memory requirement, but I think the OS overhead is to big. > In (1) and (3) above, the drivers for those chips could usefully tell > the SPI bus interface that they aren't interested in received data > when transmitting to the SPI-attached devices, and certainly it would > be at least a small convenience to such SPI interface consumers to > have the lower level driver handle it. Since not all host-side SPI > interface hardware supports discarding received data, to allow a > zero-sized receive buffer in the command passed down, at least some > SPI interface hardware drivers will have to dynamically allocate or > maintain a static discard buffer and provide error responses for > allocation-failure or transfer-too-large. If it is SPI hardware drivers decision you at least nee to take into account that in some RX-only cases you need 0xff dummy data. The slave chip driver knows if the device parses received data, but the master chip driver won't. > Example (2) is equally easy to handle on either side of the SPI bus > interface by pointing the transmit buffer pointer at the receive > buffer. This destroys the send data, which is not always welcome behavour. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 18:45:57 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ED1DAD2B for ; Wed, 20 Feb 2013 18:45:57 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9DF85B3A for ; Wed, 20 Feb 2013 18:45:57 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1KIjups068106 for ; Wed, 20 Feb 2013 13:45:56 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 20 Feb 2013 13:45:56 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: zfs on arm Message-ID: <20130220134556.3499369c@ivory.wynn.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:45:58 -0000 Greeting- I just tried to build a kernel with zfs support on RPi. No joy: root@fbsd-pi:/sys/arm/conf # config RPI-B-TMPFS-ZFS WARNING: duplicate option `GEOM_PART_BSD' encountered. WARNING: duplicate option `GEOM_PART_MBR' encountered. RPI-B-TMPFS-ZFS: unknown option "OPENSOLARIS" root@fbsd-pi:/sys/arm/conf # BTW while the duplicate option lines have nothing to do with the the zfs issue if anyone knows why that complaint I would appreciate some education. No I do not have those two options twice in my kernel config. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 I would never invade the United States. There would be a gun behind every blade of grass. --Isoroku Yamamoto From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 18:58:00 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5FF20DD; Wed, 20 Feb 2013 18:58:00 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by mx1.freebsd.org (Postfix) with ESMTP id 7E573C27; Wed, 20 Feb 2013 18:57:58 +0000 (UTC) Received: by mail-bk0-f52.google.com with SMTP id jk13so3742166bkc.11 for ; Wed, 20 Feb 2013 10:57:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=K4OFvzWbMPvHU9Cokdhb/2MY9MxBMs3NMTNg3reFc78=; b=xKuZYBAr8NrdZNMveFp8W+kRZmfvfLsZUP/sGYhNpLzdIcdj7deBFp5uZCqYS6qabs seFmjyKnZTUfPDMHfkiGRA/A1zlsE8KDb3D/PiExo6YpUqDL1WOrCYy5fCTxy2LmwTDk 16p1lYeFJ8i025P1lZT45zk+cc5w+5Ro4pE0yJ/18+KWng4q58BRMW0sM/EyrcdjSxML NGHVzwAgQzWlJkt+3pfUO/5nrTtS3JWXodLBHLfrfJhwZn3MCToRuPSBng0/Tb9Zu4e8 Wg+Wgo1MeL58hvjH2c1Q1Oeu9XO3CgmlbuKjy3lP1DOo0bzIqPGxcY5diYfTYT9HfXfn jjbQ== MIME-Version: 1.0 X-Received: by 10.204.7.194 with SMTP id e2mr9044525bke.104.1361386672228; Wed, 20 Feb 2013 10:57:52 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.204.128.213 with HTTP; Wed, 20 Feb 2013 10:57:52 -0800 (PST) In-Reply-To: <20130220174449.GB6976@cicely7.cicely.de> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> Date: Wed, 20 Feb 2013 13:57:52 -0500 X-Google-Sender-Auth: YDGM2A-k-kvBKXx2pO_XkxFZwmE Message-ID: Subject: Re: SPI, _sz fields in struct spi_command From: Patrick Kelsey To: ticso@cicely.de Content-Type: text/plain; charset=ISO-8859-1 Cc: Aleksandr Rybalko , freebsd-arm@freebsd.org, freebsd-mips@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:58:00 -0000 On Wed, Feb 20, 2013 at 12:44 PM, Bernd Walter wrote: > On Wed, Feb 20, 2013 at 10:40:35AM -0500, Patrick Kelsey wrote: >> In (1) and (3) above, the drivers for those chips could usefully tell >> the SPI bus interface that they aren't interested in received data >> when transmitting to the SPI-attached devices, and certainly it would >> be at least a small convenience to such SPI interface consumers to >> have the lower level driver handle it. Since not all host-side SPI >> interface hardware supports discarding received data, to allow a >> zero-sized receive buffer in the command passed down, at least some >> SPI interface hardware drivers will have to dynamically allocate or >> maintain a static discard buffer and provide error responses for >> allocation-failure or transfer-too-large. > > If it is SPI hardware drivers decision you at least nee to take into > account that in some RX-only cases you need 0xff dummy data. > The slave chip driver knows if the device parses received data, but > the master chip driver won't. > >> Example (2) is equally easy to handle on either side of the SPI bus >> interface by pointing the transmit buffer pointer at the receive >> buffer. > > This destroys the send data, which is not always welcome behavour. > My comments are in the overall context of extending the functionality of the existing SPI bus interface in ways that provide programming conveniences to those who wish to use them. I am not suggesting in any way that the current interface be narrowed based on any set of assumptions, so in my view, there will always be a facility for fully independent transmit and receive buffers specified by the caller. My example (2) was for a slave device that does not have a data input pin and thus is oblivious to any data sent. Certainly, if you have a device that can receive data sent by the master and your code design calls for preserving the send data across bus transactions, you would continue to use two separate buffers. -Patrick From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 19:53:48 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2E6CA150 for ; Wed, 20 Feb 2013 19:53:48 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id BFE33FE5 for ; Wed, 20 Feb 2013 19:53:47 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1KJrkYX068828 for ; Wed, 20 Feb 2013 14:53:46 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 20 Feb 2013 14:53:45 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: fixing kerberos in build world Message-ID: <20130220145345.7830b9af@ivory.wynn.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:53:48 -0000 Greeting- Well I tried a build world today with kerberos enabled. My sources are about 7 days old. The buildworld of course failed. Does anyone know of a fix to allow kerberos to build again? Is there any plan to get some fix for this into head? I of course disabled kerberos in make.conf and started the build again. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 Gun Control: The theory that a woman found dead in an alley, raped and strangled with her own pantyhose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 20:26:17 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 23CE21AA for ; Wed, 20 Feb 2013 20:26:17 +0000 (UTC) (envelope-from steve@sohara.org) Received: from uk1rly2283.eechost.net (relay01a.mail.uk1.eechost.net [217.69.40.75]) by mx1.freebsd.org (Postfix) with ESMTP id D7A4B260 for ; Wed, 20 Feb 2013 20:26:16 +0000 (UTC) Received: from [31.186.37.179] (helo=smtp.marelmo.com) by uk1rly2283.eechost.net with esmtpa (Exim 4.72) (envelope-from ) id 1U8GFE-0008Vh-Ao; Wed, 20 Feb 2013 20:26:24 +0000 Received: from [192.168.63.1] (helo=steve.marelmo.com) by smtp.marelmo.com with smtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U8GEy-0006Nk-1Y; Wed, 20 Feb 2013 20:26:08 +0000 Date: Wed, 20 Feb 2013 20:25:37 +0000 From: Steve O'Hara-Smith To: Brett Wynkoop Subject: Re: zfs on arm Message-Id: <20130220202537.705decddfaa2b4a495dc5e1d@sohara.org> In-Reply-To: <20130220134556.3499369c@ivory.wynn.com> References: <20130220134556.3499369c@ivory.wynn.com> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Auth-Info: 15567@permanet.ie (plain) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:26:17 -0000 On Wed, 20 Feb 2013 13:45:56 -0500 Brett Wynkoop wrote: > Greeting- > > I just tried to build a kernel with zfs support on RPi. No joy: ZFS in 256MB (or 512MB if you have a later model B), isn't that pushing things just a little, given that 4GB is considered small memory for ZFS. -- Steve O'Hara-Smith From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 20:35:24 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 885346CA for ; Wed, 20 Feb 2013 20:35:24 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id C11A62EE for ; Wed, 20 Feb 2013 20:35:23 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1KKZJpk069385; Wed, 20 Feb 2013 15:35:20 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 20 Feb 2013 15:35:19 -0500 From: Brett Wynkoop To: "Steve O'Hara-Smith" Subject: Re: zfs on arm Message-ID: <20130220153519.7626984a@ivory.wynn.com> In-Reply-To: <20130220202537.705decddfaa2b4a495dc5e1d@sohara.org> References: <20130220134556.3499369c@ivory.wynn.com> <20130220202537.705decddfaa2b4a495dc5e1d@sohara.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:35:24 -0000 On Wed, 20 Feb 2013 20:25:37 +0000 "Steve O'Hara-Smith" wrote: > ZFS in 256MB (or 512MB if you have a later model B), isn't > that pushing things just a little, given that 4GB is considered small > memory for ZFS. > Greeting- There are many cases of x86 boxes running zfs with 512M and 768M of memory. It takes some tweaking, but it works after the correct adjustments. I think a 512M Pi should be able to do zfs just fine. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 "The strongest reason for the people to retain the right to keep and bear arms is, as a last resort, to protect themselves against tyranny in government" - Thomas Jefferson. From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 21:11:09 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3F3A58D4 for ; Wed, 20 Feb 2013 21:11:09 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gg0-x229.google.com (gg-in-x0229.1e100.net [IPv6:2607:f8b0:4002:c02::229]) by mx1.freebsd.org (Postfix) with ESMTP id 05D7D740 for ; Wed, 20 Feb 2013 21:11:08 +0000 (UTC) Received: by mail-gg0-f169.google.com with SMTP id j5so1087120ggn.28 for ; Wed, 20 Feb 2013 13:11:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=LajH/BkVlTcasgGP5xMwq2qaVxnxutjpZ3VmKwU7Rbk=; b=g2meKwZrK2GngtzSz0/i5odkbSGEwkTAijLO39Ge1woHlfmd1kXjqJMmA1hso9Pm3+ XtJfUovCi8j/FJDMJstIE6gYaVOIfprhuyOQBWPUmx2RLl7oSLXcvaEqGE0G3KFNWC+S JmlFXN4TNc7QLZ/0UOeWRVW1ezkSfswH3MOebqCm0KnqpwXQZZS+jH6wVvfDoT6h+Zrj jfJEUHkR2DhH/JN6JG3e001UPG7XiSm0wQ3chQbff9KY0l9u0hiqiB9FKRgh237Bokad V/YnlkZwu6mzZuUhuEOK1zh7XRxQLSMY39o4RRF7Q9oE/MSiYarWB5XiARD8BawfY2ZS sqMw== X-Received: by 10.236.119.69 with SMTP id m45mr38850651yhh.128.1361394668596; Wed, 20 Feb 2013 13:11:08 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id o8sm13251433ani.4.2013.02.20.13.11.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 13:11:07 -0800 (PST) Sender: Warner Losh Subject: Re: zfs on arm Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130220153519.7626984a@ivory.wynn.com> Date: Wed, 20 Feb 2013 14:11:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3B5DE103-7042-4FBE-B883-2856E73BFE6E@bsdimp.com> References: <20130220134556.3499369c@ivory.wynn.com> <20130220202537.705decddfaa2b4a495dc5e1d@sohara.org> <20130220153519.7626984a@ivory.wynn.com> To: Brett Wynkoop X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQk6iAHdZIf6gp+uQmldzqex8zQbGYN231mzf647asN+kEr/m7BLI6yx9OIztzKMkDP6hrlg Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 21:11:09 -0000 On Feb 20, 2013, at 1:35 PM, Brett Wynkoop wrote: > On Wed, 20 Feb 2013 20:25:37 +0000 > "Steve O'Hara-Smith" wrote: >=20 >> ZFS in 256MB (or 512MB if you have a later model B), isn't >> that pushing things just a little, given that 4GB is considered small >> memory for ZFS. >>=20 >=20 > Greeting- >=20 > There are many cases of x86 boxes running zfs with 512M and 768M of > memory. It takes some tweaking, but it works after the correct > adjustments. =20 >=20 > I think a 512M Pi should be able to do zfs just fine. =20 I've done this on x86 with 640MB, but it requires a lot of hand tuning. = You should be able to build the kernel (most likely the OPENSOLARIS = issue is just moving from options.* to options, mostly), but you'll = encounter resource starvation issues until the tuning is right. :( But = that was in the 7.x timeframe, iirc, and that was so many ZFS revisions = ago... Warner From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 21:43:50 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C3D0095A for ; Wed, 20 Feb 2013 21:43:50 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 86F7F900 for ; Wed, 20 Feb 2013 21:43:50 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1KLhldp070132; Wed, 20 Feb 2013 16:43:47 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 20 Feb 2013 16:43:46 -0500 From: Brett Wynkoop To: Warner Losh Subject: Re: zfs on arm Message-ID: <20130220164346.6f70c2e1@ivory.wynn.com> In-Reply-To: <3B5DE103-7042-4FBE-B883-2856E73BFE6E@bsdimp.com> References: <20130220134556.3499369c@ivory.wynn.com> <20130220202537.705decddfaa2b4a495dc5e1d@sohara.org> <20130220153519.7626984a@ivory.wynn.com> <3B5DE103-7042-4FBE-B883-2856E73BFE6E@bsdimp.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 21:43:50 -0000 On Wed, 20 Feb 2013 14:11:05 -0700 Warner Losh wrote: > I've done this on x86 with 640MB, but it requires a lot of hand > tuning. You should be able to build the kernel (most likely the > OPENSOLARIS issue is just moving from options.* to options, mostly), > but you'll encounter resource starvation issues until the tuning is > right. :( But that was in the 7.x timeframe, iirc, and that was so > many ZFS revisions ago... > > Warner > Warner- I am not sure what you are telling me to do to get the kernel to build. I agree that it should work better than in the 7.x days. I have brought up zfs on x86 with 512M already and gotten it stable. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 April 19, 1775 An English attempt to confiscate guns from Americans triggered a successful revolution...... Dear Congress, that's a hint. From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 21:52:28 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7A737C35 for ; Wed, 20 Feb 2013 21:52:28 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 54E9A967 for ; Wed, 20 Feb 2013 21:52:28 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r1KLqRCO064950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2013 13:52:27 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r1KLqRPR064949; Wed, 20 Feb 2013 13:52:27 -0800 (PST) (envelope-from jmg) Date: Wed, 20 Feb 2013 13:52:27 -0800 From: John-Mark Gurney To: Brett Wynkoop Subject: Re: zfs on arm Message-ID: <20130220215227.GP55866@funkthat.com> Mail-Followup-To: Brett Wynkoop , freebsd-arm@freebsd.org References: <20130220134556.3499369c@ivory.wynn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130220134556.3499369c@ivory.wynn.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 20 Feb 2013 13:52:27 -0800 (PST) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 21:52:28 -0000 Brett Wynkoop wrote this message on Wed, Feb 20, 2013 at 13:45 -0500: > Greeting- > > I just tried to build a kernel with zfs support on RPi. No joy: > > root@fbsd-pi:/sys/arm/conf # config RPI-B-TMPFS-ZFS > WARNING: duplicate option `GEOM_PART_BSD' encountered. > WARNING: duplicate option `GEOM_PART_MBR' encountered. > RPI-B-TMPFS-ZFS: unknown option "OPENSOLARIS" > root@fbsd-pi:/sys/arm/conf # Are you sure that the option OPENSOLARIS even exists? I just checked -head, and can't see any reference to this option... have you tried to use the option zfs? Looks like the zfs module isn't built on arm.. You could try to build it and install it from sys/modules/zfs... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 22:25:08 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 72996970 for ; Wed, 20 Feb 2013 22:25:08 +0000 (UTC) (envelope-from matthieu.kraus@s2008.tu-chemnitz.de) Received: from nick.hrz.tu-chemnitz.de (nick.hrz.tu-chemnitz.de [134.109.228.11]) by mx1.freebsd.org (Postfix) with ESMTP id E52C4CEB for ; Wed, 20 Feb 2013 22:25:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-chemnitz.de; s=dkim2010; h=Content-Transfer-Encoding:Content-Type:MIME-Version:In-Reply-To:References:Subject:To:From:Date:Message-ID; bh=KYoLBnWjvXswtwWN4PyPdai3dCDxMcf8lgNK5bBJslo=; b=WUrq0+8+4IxPIoEkDV3wL4q4VjXpXIeQCUC/j2GEMVSmFzg3GnmgCnC4rfaXGfkEtkV2zH0e4V8G0i24NjWI3bowM6zQZhxWhm+uhZZLcYu30wTKHOSQGy/qByKTqjFIrfO5ejp+5TnBlRIrQy4SxoOsvREftyNtfGYXUL3haW4=; Received: from pat.hrz.tu-chemnitz.de ([134.109.133.4] helo=mailbox.hrz.tu-chemnitz.de) by nick.hrz.tu-chemnitz.de with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U8I60-0000z5-WB for freebsd-arm@freebsd.org; Wed, 20 Feb 2013 23:25:01 +0100 Received: from woogie.hrz.tu-chemnitz.de ([134.109.133.13] helo=localhost) by mailbox.hrz.tu-chemnitz.de with esmtp (Exim 4.80.1) (envelope-from ) id 1U8I60-0001AD-Rv for freebsd-arm@freebsd.org; Wed, 20 Feb 2013 23:25:00 +0100 Received: from 77-64-182-15.dynamic.primacom.net (77-64-182-15.dynamic.primacom.net [77.64.182.15]) by mail.tu-chemnitz.de (Horde Framework) with HTTP; Wed, 20 Feb 2013 23:25:00 +0100 Message-ID: <20130220232500.23416ch2yni4pags@mail.tu-chemnitz.de> Date: Wed, 20 Feb 2013 23:25:00 +0100 From: Matthieu Kraus To: freebsd-arm@freebsd.org Subject: Re: zfs on arm References: <20130220134556.3499369c@ivory.wynn.com> <20130220202537.705decddfaa2b4a495dc5e1d@sohara.org> <20130220153519.7626984a@ivory.wynn.com> <3B5DE103-7042-4FBE-B883-2856E73BFE6E@bsdimp.com> <20130220164346.6f70c2e1@ivory.wynn.com> In-Reply-To: <20130220164346.6f70c2e1@ivory.wynn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) X-Originating-IP: 77.64.182.15 X-Scan-AV: mailbox.hrz.tu-chemnitz.de; 2013-02-20 23:25:00; 0bc8de55749bdcf34d954ba2f6f922e0 X-purgate: clean X-purgate-type: clean X-purgate-ID: 154106::1361399101-000004D6-892D8396/0-0/0-0 X-Scan-SA: nick.hrz.tu-chemnitz.de; 2013-02-20 23:25:01; 249cb433cad53fa9af844e73da63df4d X-Spam-Score: -1.6 (-) X-Spam-Report: --- Textanalyse SpamAssassin 3.3.1 (-1.6 Punkte) Fragen an/questions to: Postmaster TU Chemnitz * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain --- Ende Textanalyse X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 22:25:08 -0000 > I am not sure what you are telling me to do to get the kernel to > build. I agree that it should work better than in the 7.x days. I > have brought up zfs on x86 with 512M already and gotten it stable. > > -Brett make sure your kernel config contains something along the lines of this (you'll need opensolaris and zlib in addition to zfs as it depends on those): makeoptions MODULES_OVERRIDE="zfs opensolaris zlib" if it still refuses to build, this patch may help as a quick hack (a proper fix may be more appropriate): Index: sys/cddl/compat/opensolaris/sys/cpuvar.h =================================================================== --- sys/cddl/compat/opensolaris/sys/cpuvar.h (revision 244033) +++ sys/cddl/compat/opensolaris/sys/cpuvar.h (working copy) @@ -50,6 +50,9 @@ /* Some code may choose to redefine this if pcpu_t would be more useful. */ #define cpu_t solaris_cpu_t +#ifdef cpu_id +#undef cpu_id +#endif #define cpu_id cpuid extern solaris_cpu_t solaris_cpu[]; From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 22:33:36 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D089B1EB for ; Wed, 20 Feb 2013 22:33:36 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 953F4E1E for ; Wed, 20 Feb 2013 22:33:36 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1KMXZC5070715; Wed, 20 Feb 2013 17:33:35 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 20 Feb 2013 17:33:35 -0500 From: Brett Wynkoop To: Matthieu Kraus Subject: Re: zfs on arm Message-ID: <20130220173335.3c8fd895@ivory.wynn.com> In-Reply-To: <20130220232500.23416ch2yni4pags@mail.tu-chemnitz.de> References: <20130220134556.3499369c@ivory.wynn.com> <20130220202537.705decddfaa2b4a495dc5e1d@sohara.org> <20130220153519.7626984a@ivory.wynn.com> <3B5DE103-7042-4FBE-B883-2856E73BFE6E@bsdimp.com> <20130220164346.6f70c2e1@ivory.wynn.com> <20130220232500.23416ch2yni4pags@mail.tu-chemnitz.de> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 22:33:36 -0000 On Wed, 20 Feb 2013 23:25:00 +0100 Matthieu Kraus wrote: > > I am not sure what you are telling me to do to get the kernel to > > build. I agree that it should work better than in the 7.x days. I > > have brought up zfs on x86 with 512M already and gotten it stable. > > > > -Brett > > make sure your kernel config contains something along the lines of > this (you'll need opensolaris and zlib in addition to zfs as it > depends on those): > > makeoptions MODULES_OVERRIDE="zfs opensolaris zlib" So you are saying I can not build a static kernel with zfs support? -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 I would never invade the United States. There would be a gun behind every blade of grass. --Isoroku Yamamoto From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 22:37:01 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3C71C364 for ; Wed, 20 Feb 2013 22:37:01 +0000 (UTC) (envelope-from matthieu.kraus@s2008.tu-chemnitz.de) Received: from nick.hrz.tu-chemnitz.de (nick.hrz.tu-chemnitz.de [134.109.228.11]) by mx1.freebsd.org (Postfix) with ESMTP id E792CE62 for ; Wed, 20 Feb 2013 22:37:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-chemnitz.de; s=dkim2010; h=Content-Transfer-Encoding:Content-Type:MIME-Version:In-Reply-To:References:Subject:To:From:Date:Message-ID; bh=AHVCb0jqOIDqmdKBTw3wa4F3kUJDQCwSBYcuLm0lPsc=; b=iDFeMMYMTWw3kZ5sMaOim9jBAkG+d3k3hOeJD4Tii1Gt5xTibj/QAVX6fjMTslT7zophi3SBcWFUL3nQ49dWySUmF3bw6Z//0NZJxGW0lChiITyFJCA2xSUdUgB/qA74nl8dAPTZcur9moUkWPCuBpp8dQLsUVlkl5Wu8spm0VU=; Received: from postman.hrz.tu-chemnitz.de ([134.109.133.5] helo=mailbox.hrz.tu-chemnitz.de) by nick.hrz.tu-chemnitz.de with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U8IHb-0001kw-SN for freebsd-arm@freebsd.org; Wed, 20 Feb 2013 23:37:00 +0100 Received: from woogie.hrz.tu-chemnitz.de ([134.109.133.13] helo=localhost) by mailbox.hrz.tu-chemnitz.de with esmtp (Exim 4.80.1) (envelope-from ) id 1U8IHb-00042H-Nz for freebsd-arm@freebsd.org; Wed, 20 Feb 2013 23:36:59 +0100 Received: from 77-64-182-15.dynamic.primacom.net (77-64-182-15.dynamic.primacom.net [77.64.182.15]) by mail.tu-chemnitz.de (Horde Framework) with HTTP; Wed, 20 Feb 2013 23:36:59 +0100 Message-ID: <20130220233659.60495f50gnuz8a2z@mail.tu-chemnitz.de> Date: Wed, 20 Feb 2013 23:36:59 +0100 From: Matthieu Kraus To: freebsd-arm@freebsd.org Subject: Re: zfs on arm References: <20130220134556.3499369c@ivory.wynn.com> <20130220202537.705decddfaa2b4a495dc5e1d@sohara.org> <20130220153519.7626984a@ivory.wynn.com> <3B5DE103-7042-4FBE-B883-2856E73BFE6E@bsdimp.com> <20130220164346.6f70c2e1@ivory.wynn.com> <20130220232500.23416ch2yni4pags@mail.tu-chemnitz.de> <20130220173335.3c8fd895@ivory.wynn.com> In-Reply-To: <20130220173335.3c8fd895@ivory.wynn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) X-Originating-IP: 77.64.182.15 X-Scan-AV: mailbox.hrz.tu-chemnitz.de; 2013-02-20 23:36:59; a89bc911d83c2f1174d7cea55ceeab97 X-purgate: clean X-purgate-type: clean X-purgate-ID: 154106::1361399819-000004D6-BAE35092/0-0/0-0 X-Scan-SA: nick.hrz.tu-chemnitz.de; 2013-02-20 23:37:00; 1c077e4b5876702d102327a6eb67f2e1 X-Spam-Score: -1.6 (-) X-Spam-Report: --- Textanalyse SpamAssassin 3.3.1 (-1.6 Punkte) Fragen an/questions to: Postmaster TU Chemnitz * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain --- Ende Textanalyse X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 22:37:01 -0000 > So you are saying I can not build a static kernel with zfs support? > > -Brett I might be wrong here, but I couldn't find an option to build zfs support into the kernel (maybe because it has a third party license?), so I simply built the zfs support via modules which works for me - I didn't really see the need for monolithic zfs support tbh as it's not stable enough to run root on zfs, anyway, so having it as module that's loaded post-boot didn't seem like an issue to me. From owner-freebsd-arm@FreeBSD.ORG Wed Feb 20 23:04:37 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 99D9B7FA for ; Wed, 20 Feb 2013 23:04:37 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3CDE0117 for ; Wed, 20 Feb 2013 23:04:36 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1KN4Zt2071040; Wed, 20 Feb 2013 18:04:35 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 20 Feb 2013 18:04:35 -0500 From: Brett Wynkoop To: Matthieu Kraus Subject: Re: zfs on arm Message-ID: <20130220180435.1708d24d@ivory.wynn.com> In-Reply-To: <20130220233659.60495f50gnuz8a2z@mail.tu-chemnitz.de> References: <20130220134556.3499369c@ivory.wynn.com> <20130220202537.705decddfaa2b4a495dc5e1d@sohara.org> <20130220153519.7626984a@ivory.wynn.com> <3B5DE103-7042-4FBE-B883-2856E73BFE6E@bsdimp.com> <20130220164346.6f70c2e1@ivory.wynn.com> <20130220232500.23416ch2yni4pags@mail.tu-chemnitz.de> <20130220173335.3c8fd895@ivory.wynn.com> <20130220233659.60495f50gnuz8a2z@mail.tu-chemnitz.de> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 23:04:37 -0000 On Wed, 20 Feb 2013 23:36:59 +0100 Matthieu Kraus wrote: > > I might be wrong here, but I couldn't find an option to build zfs > support into the kernel (maybe because it has a third party > license?), so I simply built the zfs support via modules which works > for me - I didn't really see the need for monolithic zfs support tbh > as it's not stable enough to run root on zfs, anyway, so having it as > module that's loaded post-boot didn't seem like an issue to me. Greeting- I will try to build as a module and see what happens. I have run zfs on root using the mfsbsd install images since 8.0 without any stability problems. I do not think we can yet run zfs on root with ARM, but I am not certain as I am not really real up on how these boxes boot or if the boot loader understands zfs. I guess we would have to chainload something that could load the kernel from zfs. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 Gun Control: The theory that a woman found dead in an alley, raped and strangled with her own pantyhose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 00:27:17 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B9216651; Thu, 21 Feb 2013 00:27:17 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 3DCC97F1; Thu, 21 Feb 2013 00:27:16 +0000 (UTC) Received: from rnote.ddteam.net (102-43-135-95.pool.ukrtel.net [95.135.43.102]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 24AB1C4930; Thu, 21 Feb 2013 02:27:09 +0200 (EET) Date: Thu, 21 Feb 2013 02:26:55 +0200 From: Aleksandr Rybalko To: Patrick Kelsey Subject: Re: SPI, _sz fields in struct spi_command Message-Id: <20130221022655.6f693eb6.ray@freebsd.org> In-Reply-To: References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, ticso@cicely.de, freebsd-mips@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 00:27:17 -0000 On Wed, 20 Feb 2013 13:57:52 -0500 Patrick Kelsey wrote: > On Wed, Feb 20, 2013 at 12:44 PM, Bernd Walter > wrote: > > On Wed, Feb 20, 2013 at 10:40:35AM -0500, Patrick Kelsey wrote: > > >> In (1) and (3) above, the drivers for those chips could usefully > >> tell the SPI bus interface that they aren't interested in received > >> data when transmitting to the SPI-attached devices, and certainly > >> it would be at least a small convenience to such SPI interface > >> consumers to have the lower level driver handle it. Since not all > >> host-side SPI interface hardware supports discarding received > >> data, to allow a zero-sized receive buffer in the command passed > >> down, at least some SPI interface hardware drivers will have to > >> dynamically allocate or maintain a static discard buffer and > >> provide error responses for allocation-failure or > >> transfer-too-large. > > > > If it is SPI hardware drivers decision you at least nee to take into > > account that in some RX-only cases you need 0xff dummy data. > > The slave chip driver knows if the device parses received data, but > > the master chip driver won't. > > > >> Example (2) is equally easy to handle on either side of the SPI bus > >> interface by pointing the transmit buffer pointer at the receive > >> buffer. > > > > This destroys the send data, which is not always welcome behavour. > > > > My comments are in the overall context of extending the functionality > of the existing SPI bus interface in ways that provide programming > conveniences to those who wish to use them. I am not suggesting in > any way that the current interface be narrowed based on any set of > assumptions, so in my view, there will always be a facility for fully > independent transmit and receive buffers specified by the caller. > > My example (2) was for a slave device that does not have a data input > pin and thus is oblivious to any data sent. Certainly, if you have a > device that can receive data sent by the master and your code design > calls for preserving the send data across bus transactions, you would > continue to use two separate buffers. > > -Patrick Thanks to all for interesting comments, some of my keys for that topic you all already said but I say it again anyway :) So why I ask about that: 1. Do we really need to allocate second unused buffer? 2. Do we really need to spend clock cycles on that buffer? 3. Ralink-s SPI can't do bidirectional transfer (IIRC I've tested it properly, only 1 8bits reg for both RX and TX and same data on read after TX byte) (Sorry for not commited yet, will do, hope soon :) ) 4. Since we have sz for both direction and both types (cmd, data) why controller drivers force us to make it equal? (at91_spi_transfer KASSERT) What I think we need to do with that: 1. remove KASSERT in controller drivers, make driver to accept at least cases when (tx_sz == rx_sz), (tx_sz && !rx_sz), (!tx_sz && rx_sz). Plus if controller require some buffer to drain into it (don't know how to correctly say in English what men do after many beers :) ) allocate it or make some static buffer. 2. teach consumers to give only correct numbers (very nice we have only two SPI devices in tree) After that we will be able to make drivers for some (potential) devices which will require bidirectional communication. And controllers which can't do that, will just report error in that. I believe peoples thinks before attach such devices to controllers, so we will not have such incompatibility. Hope I'm not forget something important :-D Thanks to all! WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 01:44:48 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 05405735; Thu, 21 Feb 2013 01:44:48 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 62EBAA78; Thu, 21 Feb 2013 01:44:46 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id r1L1iatg021259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Feb 2013 02:44:37 +0100 (CET) (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 r1L1iYn6054286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 02:44:34 +0100 (CET) (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 r1L1iXo5012875; Thu, 21 Feb 2013 02:44:33 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id r1L1iXVK012874; Thu, 21 Feb 2013 02:44:33 +0100 (CET) (envelope-from ticso) Date: Thu, 21 Feb 2013 02:44:33 +0100 From: Bernd Walter To: Aleksandr Rybalko Subject: Re: SPI, _sz fields in struct spi_command Message-ID: <20130221014433.GA12189@cicely7.cicely.de> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130221022655.6f693eb6.ray@freebsd.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Patrick Kelsey , freebsd-arm@freebsd.org, ticso@cicely.de, freebsd-mips@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 01:44:48 -0000 On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr Rybalko wrote: > On Wed, 20 Feb 2013 13:57:52 -0500 > Patrick Kelsey wrote: > > > On Wed, Feb 20, 2013 at 12:44 PM, Bernd Walter > > wrote: > > > On Wed, Feb 20, 2013 at 10:40:35AM -0500, Patrick Kelsey wrote: > > > > >> In (1) and (3) above, the drivers for those chips could usefully > > >> tell the SPI bus interface that they aren't interested in received > > >> data when transmitting to the SPI-attached devices, and certainly > > >> it would be at least a small convenience to such SPI interface > > >> consumers to have the lower level driver handle it. Since not all > > >> host-side SPI interface hardware supports discarding received > > >> data, to allow a zero-sized receive buffer in the command passed > > >> down, at least some SPI interface hardware drivers will have to > > >> dynamically allocate or maintain a static discard buffer and > > >> provide error responses for allocation-failure or > > >> transfer-too-large. > > > > > > If it is SPI hardware drivers decision you at least nee to take into > > > account that in some RX-only cases you need 0xff dummy data. > > > The slave chip driver knows if the device parses received data, but > > > the master chip driver won't. > > > > > >> Example (2) is equally easy to handle on either side of the SPI bus > > >> interface by pointing the transmit buffer pointer at the receive > > >> buffer. > > > > > > This destroys the send data, which is not always welcome behavour. > > > > > > > My comments are in the overall context of extending the functionality > > of the existing SPI bus interface in ways that provide programming > > conveniences to those who wish to use them. I am not suggesting in > > any way that the current interface be narrowed based on any set of > > assumptions, so in my view, there will always be a facility for fully > > independent transmit and receive buffers specified by the caller. > > > > My example (2) was for a slave device that does not have a data input > > pin and thus is oblivious to any data sent. Certainly, if you have a > > device that can receive data sent by the master and your code design > > calls for preserving the send data across bus transactions, you would > > continue to use two separate buffers. > > > > -Patrick > > Thanks to all for interesting comments, some of my keys for that topic > you all already said but I say it again anyway :) > So why I ask about that: > 1. Do we really need to allocate second unused buffer? For AT91 yes, unless: - RX-only and you know that sending the RX buffers undefined content is Ok, which is not if the device needs 0xff - TX-only and you know that trashing the TX buffer is Ok > 2. Do we really need to spend clock cycles on that buffer? For AT91 it is required, others maybe not. > 3. Ralink-s SPI can't do bidirectional transfer (IIRC I've tested it > properly, only 1 8bits reg for both RX and TX and same data on read > after TX byte) (Sorry for not commited yet, will do, hope soon :) ) > 4. Since we have sz for both direction and both types (cmd, data) why > controller drivers force us to make it equal? (at91_spi_transfer > KASSERT) They can't otherwise. > What I think we need to do with that: > 1. remove KASSERT in controller drivers, make driver to accept at least > cases when (tx_sz == rx_sz), (tx_sz && !rx_sz), (!tx_sz && rx_sz). Plus > if controller require some buffer to drain into it (don't know how to > correctly say in English what men do after many beers :) ) allocate it > or make some static buffer. Sounds good. Static buffers however may require multiple DMA setup if the transfer request ist bigger. With AT91 this can be done via *empty interrupt to replay the same buffer. It is just not wise to interrupt on each single byte, which would be required without a DMA buffer at all. Sending 0xff as default dummy data requires filling the TX buffer with this value, so maybe if doing static then have 2 buffers, one with 0xff dummy data and one bit-bucket buffer to RX into. Otherwise use the same dummy data and if a driver requires sending dummy 0xff it needs to supply its own buffer, but there are many devices requiring this. > 2. teach consumers to give only correct numbers (very nice we have only > two SPI devices in tree) > > After that we will be able to make drivers for some (potential) devices > which will require bidirectional communication. And controllers which > can't do that, will just report error in that. I believe peoples thinks > before attach such devices to controllers, so we will not have such > incompatibility. I don't think there are many devices requiring RX/TX at the same time. And if a controller won't support it there is nothing to be done anyway beside bit bang-ing. But I usually do RX/TX at the same transfer with devices wanting a comand word and then sending data at the next data word. In many cases you must not deassert CS during this. I don't know how CS is handled in our SPI as I never did SPI with FreeBSD. If CS is handled automatically on each transaction then it must support bidirectional transactions. If CS however are done with separate calls it is Ok to do a TX and then an TX call before deasserting. The AT91 hardware has automatic CS support - in my own controller code outside of FreeBSD I usually prefer handling CS with GPIO for that reason. > Hope I'm not forget something important :-D > > Thanks to all! > > WBW > -- > Aleksandr Rybalko -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 02:49:52 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7728FAA2 for ; Thu, 21 Feb 2013 02:49:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by mx1.freebsd.org (Postfix) with ESMTP id 47E46D5E for ; Thu, 21 Feb 2013 02:49:52 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id k13so10559127iea.7 for ; Wed, 20 Feb 2013 18:49:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=6b2jKnedNPF9Cwu/vU/LzbSIVdsYrBB9EyaoRU4tJD4=; b=f6mCz1olQez+C7Xpm9gVcU2V580DvLXZxbMCGfkuEFbmGyYJ9Nv6dg2SEAxHPMqZdp AFu/B5e4HG2ikbXBXocSq7AgRFNgJ8wL/nZpgJ6zIvpAME/gTNWqRSbAuSUGCNpyQukP oN4Y7cG5X4WiZvtdW4sGeYio6kNHdWUypMY2ePWmO22FWlv3NWKHeLF79dwEY5KvsZP+ 4sXmS6ziXIB0BgQe3VEJwvDhtO7E3I9D2s9R1TkLL6NcqyQyu8LiPldp1XIJzl1QacAS FmG6Bbbd/ndPWsKsutwZ0MF9oj0DojCdVygm9wYfB6MjMLisHkIkpkzMG7hUyHQ7YGhp HG3A== X-Received: by 10.50.157.138 with SMTP id wm10mr9951446igb.103.1361414991866; Wed, 20 Feb 2013 18:49:51 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id xc3sm15336880igb.10.2013.02.20.18.49.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 18:49:50 -0800 (PST) Sender: Warner Losh Subject: Re: SPI, _sz fields in struct spi_command Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130221022655.6f693eb6.ray@freebsd.org> Date: Wed, 20 Feb 2013 19:49:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <62EDE91B-DDF3-462D-8802-7A7FBF00CE91@bsdimp.com> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnCtX41R3UDqQq3C4M55FlZQv5D+EqjrC/BLGLKVCSxIQbP2yofbHPuTKsFvPzCVcpUeGDX Cc: Patrick Kelsey , freebsd-arm@freebsd.org, ticso@cicely.de, freebsd-mips@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 02:49:52 -0000 On Feb 20, 2013, at 5:26 PM, Aleksandr Rybalko wrote: > On Wed, 20 Feb 2013 13:57:52 -0500 > Patrick Kelsey wrote: >=20 >> On Wed, Feb 20, 2013 at 12:44 PM, Bernd Walter >> wrote: >>> On Wed, Feb 20, 2013 at 10:40:35AM -0500, Patrick Kelsey wrote: >>=20 >>>> In (1) and (3) above, the drivers for those chips could usefully >>>> tell the SPI bus interface that they aren't interested in received >>>> data when transmitting to the SPI-attached devices, and certainly >>>> it would be at least a small convenience to such SPI interface >>>> consumers to have the lower level driver handle it. Since not all >>>> host-side SPI interface hardware supports discarding received >>>> data, to allow a zero-sized receive buffer in the command passed >>>> down, at least some SPI interface hardware drivers will have to >>>> dynamically allocate or maintain a static discard buffer and >>>> provide error responses for allocation-failure or >>>> transfer-too-large. >>>=20 >>> If it is SPI hardware drivers decision you at least nee to take into >>> account that in some RX-only cases you need 0xff dummy data. >>> The slave chip driver knows if the device parses received data, but >>> the master chip driver won't. >>>=20 >>>> Example (2) is equally easy to handle on either side of the SPI bus >>>> interface by pointing the transmit buffer pointer at the receive >>>> buffer. >>>=20 >>> This destroys the send data, which is not always welcome behavour. >>>=20 >>=20 >> My comments are in the overall context of extending the functionality >> of the existing SPI bus interface in ways that provide programming >> conveniences to those who wish to use them. I am not suggesting in >> any way that the current interface be narrowed based on any set of >> assumptions, so in my view, there will always be a facility for fully >> independent transmit and receive buffers specified by the caller. >>=20 >> My example (2) was for a slave device that does not have a data input >> pin and thus is oblivious to any data sent. Certainly, if you have a >> device that can receive data sent by the master and your code design >> calls for preserving the send data across bus transactions, you would >> continue to use two separate buffers. >>=20 >> -Patrick >=20 > Thanks to all for interesting comments, some of my keys for that topic > you all already said but I say it again anyway :) > So why I ask about that: > 1. Do we really need to allocate second unused buffer? Yes, but we could push that requirement into the spi host adapter drivr. > 2. Do we really need to spend clock cycles on that buffer? The way SPI works is that the cycles are spent, because TX cycles have = to equal RX cycles. > 3. Ralink-s SPI can't do bidirectional transfer (IIRC I've tested it > properly, only 1 8bits reg for both RX and TX and same data on read > after TX byte) (Sorry for not commited yet, will do, hope soon :) ) > 4. Since we have sz for both direction and both types (cmd, data) why > controller drivers force us to make it equal? (at91_spi_transfer > KASSERT) Because they must be equal. However, if we're pushing the buffer = management down a level, then we can remove them. > What I think we need to do with that: > 1. remove KASSERT in controller drivers, make driver to accept at = least > cases when (tx_sz =3D=3D rx_sz), (tx_sz && !rx_sz), (!tx_sz && rx_sz). = Plus > if controller require some buffer to drain into it (don't know how to > correctly say in English what men do after many beers :) ) allocate it > or make some static buffer. Yes, moving the responsibility from the driver to the spi controller = would be possible. > 2. teach consumers to give only correct numbers (very nice we have = only > two SPI devices in tree) I thought the at45 was bidirectional... > After that we will be able to make drivers for some (potential) = devices > which will require bidirectional communication. And controllers which > can't do that, will just report error in that. I believe peoples = thinks > before attach such devices to controllers, so we will not have such > incompatibility. If this feature becomes optional, we should have some way for the = controller to communicate that it can do bidirectional transfers. If we = have that, then such a device could refuse to attach on machines with = controllers that can't do htat. > Hope I'm not forget something important :-D No, that's OK. Warner > Thanks to all! >=20 > WBW > --=20 > Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 04:10:25 2013 Return-Path: Delivered-To: FreeBSD-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E50B7A41 for ; Thu, 21 Feb 2013 04:10:25 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 91B17B0 for ; Thu, 21 Feb 2013 04:10:22 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id r1L4AFVr024453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 21 Feb 2013 05:10:15 +0100 (CET) (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 r1L4ACXV057876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 05:10:12 +0100 (CET) (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 r1L4ACGL014057; Thu, 21 Feb 2013 05:10:12 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id r1L4ACmn014056; Thu, 21 Feb 2013 05:10:12 +0100 (CET) (envelope-from ticso) Date: Thu, 21 Feb 2013 05:10:12 +0100 From: Bernd Walter To: FreeBSD-arm@freebsd.org Subject: TFT Panel trouble with Raspi Message-ID: <20130221041011.GB12189@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Bernd Walter X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 04:10:26 -0000 I'm using the folloging Image: http://www.peach.ne.jp/archives/rpi/freebsd-pi-clang-20130210.img.gz With this Panel: http://www.chalk-elec.com/?page_id=1280#!/~/product/category=3094861&id=14647630 Resolution is 1024x600 pixel with an HDMI adapter. Under Linux at first it didn't display anything at all. The following config.txt was required: hdmi_ignore_edid=0xa5000080 hdmi_group=2 hdmi_mode=16 overscan_top=-40 overscan_bottom=125 This sets 1024x768 and tunes overscan area. Nice HDMI crap only knows defined resolutions... Without overscan values the display starts at the right top postion, but the 168 excessive bottom lines are missing on display - no surprise. Descriptions claims those to be pixels, so those values don't make 100% sense to me as math says the result to be 683 pixel, but basicly the result looks good. Considering the description it doesn't make sense to tamper with top values as it is correctly aligned without overscan. With FreeBSD however those values won't work. The result is that at top there is empty space and missing lines at the bottom. If I set 800x600 resolution everything looks good, but width isn't used completely. With description I would assume that setting bottom to 168 should give the right result, but setting bottom to 168 cuts 84 lines at bottom and 84 lines at top. With bottom to 336 the bottom is alligned correctly but missing 168 lines on top. With bottom to 336 and top to -168 the result is the same as with bottom at 168 and top at 0. Under Linux the result is different. Setting bottom to 168 cuts many more pixel at bottom and less pixel at top - sigh, so much about their documentation. I would guess it cuts about 3x at bottom and 1x at top. Adding top=-10 seems to add symetrical pixel at top and bottom. Strange enough - booting Linux with the above vendor supplied config shows this: [ 0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1024 bcm2708_fb.fbheight=683 bcm2708.boardrev=0x3 bcm2708.serial=0xda48bc18 smsc95xx.macaddr=B8:27:EB:48:BC:18 sdhci-bcm2708.emmc_clock_freq=100000000 vc_mem.mem_base=0xec00000 vc_mem.mem_size=0x10000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait fbheigh = 683, but I would say that I would have noticed 83 missing pixels, although it agrees with my math about those values to be pixels. Btw - on my LG TV with 1366x768 pixel (it announces as 1360x768 and scales to 1366 sigh) FreeBSD was missing bottom lines as well. I know because I plugged it into my TV to boot the FreeBSD for the first time, didn't get a login and thought there was only a getty running on serial console. I didn't debug there any further. Today with the TFT-Panel I saw that it is indeed running a getty. Whatever bad magic there is - Linux knows it and FreeBSD has problems. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 04:27:14 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B75A3E61 for ; Thu, 21 Feb 2013 04:27:14 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by mx1.freebsd.org (Postfix) with ESMTP id 80CD413F for ; Thu, 21 Feb 2013 04:27:14 +0000 (UTC) Received: by mail-qe0-f51.google.com with SMTP id 6so4132459qea.10 for ; Wed, 20 Feb 2013 20:27:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=pE2DD11vRssMAXn5c3zxX+vhTmIUr0xVA2ifb3OT20Y=; b=j0bVieXouTK8sYAk4JXEZpQuEL6tbyYTZGkAaC8jPjWtK2c+N9iORhVsEvzCEETZz7 N8PkRujYXvITjJOLlMmMSBsnd2ei43bgzneBQQBEYk6sD8JLaELNIoVDQnzDT64k9iO7 cySuw/MHOULmorexGm/DHEyFOwmh9PCy9x7NpuLjg+vL5ih3vkMR2qMUl99mXdMIyjDS IfoeGFVAUIodZ1PY7ksOMLQbvMBlJWbeQJhaER2A70UoKgiWma7GiFeJfgek+poB9S6L fvEhcHAzdnVw/F3F5qV4IWczdITyNbb5ZAtoFjYL0DsG+42tirkpf/M4rjv67RDgqKwY JtHA== MIME-Version: 1.0 X-Received: by 10.49.128.37 with SMTP id nl5mr11516389qeb.59.1361420828423; Wed, 20 Feb 2013 20:27:08 -0800 (PST) Received: by 10.49.51.138 with HTTP; Wed, 20 Feb 2013 20:27:08 -0800 (PST) Date: Thu, 21 Feb 2013 12:27:08 +0800 Message-ID: Subject: The Next BeagleBone Better & Faster for Less! From: Alie Tan To: "freebsd-arm@freebsd.org" X-Gm-Message-State: ALoCoQlWQwY0vR9AdJyMMeob+2mtPkkms0XrZjZ9k+nP7lGyIcC/n90D26I+KbjCgCUmpq+YWLU5 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 04:27:14 -0000 Just got a news about new Beaglebone: http://beagleboard.org/unzipped/ From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 04:49:24 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 979411FD for ; Thu, 21 Feb 2013 04:49:24 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) by mx1.freebsd.org (Postfix) with ESMTP id 5DCB81DF for ; Thu, 21 Feb 2013 04:49:23 +0000 (UTC) Received: from [192.168.1.104] (pool-173-77-66-237.nycmny.east.verizon.net [173.77.66.237]) (authenticated bits=0) by feynman.konjz.org (8.14.6/8.14.4) with ESMTP id r1L4n9OF001167 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 20 Feb 2013 23:49:15 -0500 (EST) (envelope-from george@ceetonetechnology.com) Message-ID: <5125A73F.10802@ceetonetechnology.com> Date: Wed, 20 Feb 2013 23:49:03 -0500 From: George Rosamond User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130117 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: The Next BeagleBone Better & Faster for Less! References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 5.32 (*****) FH_HOST_EQ_VERIZON_P,RDNS_DYNAMIC X-Spam-Hits: 5320 X-Spam-Names: FH_HOST_EQ_VERIZON_P,RDNS_DYNAMIC X-Spam-Flag: YES X-Mail-Provider: KonjZ X-Scanned-By: MIMEDefang 2.73 on 64.147.119.39 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: george@ceetonetechnology.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 04:49:24 -0000 On 02/20/13 23:27, Alie Tan wrote: > Just got a news about new Beaglebone: > > http://beagleboard.org/unzipped/ Wow. Although personally, I could do without the HDMI. It would be ideal there was a stock FBSD image for them to provide for purchasers... as in official on their www site as an alternative to Linux. g From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 05:56:38 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B797F193 for ; Thu, 21 Feb 2013 05:56:38 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 957C210EB for ; Thu, 21 Feb 2013 05:56:37 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1L5uaXE091024; Thu, 21 Feb 2013 05:56:36 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id euejwg5wkiw5qwexze9rntkw7w; Thu, 21 Feb 2013 05:56:36 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: No more compiled-in FDTs?! Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_E83718F1-75BB-45B4-8617-00F90DFAE2DD"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Tim Kientzle In-Reply-To: <20130220120129.4a1934e9@ivory.wynn.com> Date: Wed, 20 Feb 2013 21:56:36 -0800 Message-Id: <67B048BF-8EC4-463F-A806-5814B5A781D9@freebsd.org> References: <726FA1B6-C3D7-479B-A6E0-78E8CC49144A@freebsd.org> <20130220120129.4a1934e9@ivory.wynn.com> To: Brett Wynkoop X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 05:56:38 -0000 --Apple-Mail=_E83718F1-75BB-45B4-8617-00F90DFAE2DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 20, 2013, at 9:01 AM, Brett Wynkoop wrote: > On Wed, 20 Feb 2013 08:44:21 -0800 > Tim Kientzle wrote: >=20 >> I've just committed changes so that BeagleBone images >> (built with my scripts) no longer use the compiled-in FDT. >> (This includes changes to FreeBSD ubldr, to U-Boot, >> and to my scripts.) >=20 > Can you put out a short message about how to update an existing > BeagleBone without needing to build a new image on another box? Hmmm=85. no promises, but I *think* you can get there by downloading http://people.freebsd.org/~kientzle/beaglebone-msdos-partition.tgz and replace the contents of your FAT partition with the files in that archive. Probably a good idea to back up the old files first. (Note that only one file --- MLO --- actually has the same name.) Tim --Apple-Mail=_E83718F1-75BB-45B4-8617-00F90DFAE2DD 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----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQEcBAEBAgAGBQJRJbcUAAoJEGMNyGo0rfFBrxUH/jTGGhBYtvDI0CmjfCg5S2Oh OuvhBchxvnHk23vJpqGIJwwGwqtwD65jbJhRbINdCk48uhis82RNA8O/ZnNIfSqY +fAHbMrwuYcQNVbvX/kXpNg88s2n4lGDKQv9J5i0aiXh86eMixaVcAtGnEMAqGie 3VoScwYpgBTmD7dKtksenYgmAjio8DN1XRWkYtqRp/suJC5GvY7aPWHqOn2kab+d HvURIeTWWWZs4Pk6IUNA6FtlFUIfRdfc03gN/3My0LfCQRcU4bIyEGcHEAZOOdqn j81glE2xAG4YZn/z7N4H/1wDVbPFWqhm7G3qe2CoIyZX9pF2JkPQE6p3odX9fjg= =y8+/ -----END PGP SIGNATURE----- --Apple-Mail=_E83718F1-75BB-45B4-8617-00F90DFAE2DD-- From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 06:05:54 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 70832754; Thu, 21 Feb 2013 06:05:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 47D45114C; Thu, 21 Feb 2013 06:05:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1L65lL3010944; Thu, 21 Feb 2013 01:05:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1L65liD010940; Thu, 21 Feb 2013 06:05:47 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Feb 2013 06:05:47 GMT Message-Id: <201302210605.r1L65liD010940@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 06:05:54 -0000 TB --- 2013-02-21 04:10:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 04:10:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-21 04:10:20 - starting HEAD tinderbox run for arm/arm TB --- 2013-02-21 04:10:20 - cleaning the object tree TB --- 2013-02-21 04:10:20 - /usr/local/bin/svn stat /src TB --- 2013-02-21 04:10:24 - At svn revision 247073 TB --- 2013-02-21 04:10:25 - building world TB --- 2013-02-21 04:10:25 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 04:10:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 04:10:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 04:10:25 - SRCCONF=/dev/null TB --- 2013-02-21 04:10:25 - TARGET=arm TB --- 2013-02-21 04:10:25 - TARGET_ARCH=arm TB --- 2013-02-21 04:10:25 - TZ=UTC TB --- 2013-02-21 04:10:25 - __MAKE_CONF=/dev/null TB --- 2013-02-21 04:10:25 - cd /src TB --- 2013-02-21 04:10:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 21 04:10:30 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 21 05:59:30 UTC 2013 TB --- 2013-02-21 05:59:30 - generating LINT kernel config TB --- 2013-02-21 05:59:30 - cd /src/sys/arm/conf TB --- 2013-02-21 05:59:30 - /usr/bin/make -B LINT TB --- 2013-02-21 05:59:30 - cd /src/sys/arm/conf TB --- 2013-02-21 05:59:30 - /usr/sbin/config -m LINT TB --- 2013-02-21 05:59:30 - building LINT kernel TB --- 2013-02-21 05:59:30 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 05:59:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 05:59:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 05:59:30 - SRCCONF=/dev/null TB --- 2013-02-21 05:59:30 - TARGET=arm TB --- 2013-02-21 05:59:30 - TARGET_ARCH=arm TB --- 2013-02-21 05:59:30 - TZ=UTC TB --- 2013-02-21 05:59:30 - __MAKE_CONF=/dev/null TB --- 2013-02-21 05:59:30 - cd /src TB --- 2013-02-21 05:59:30 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 21 05:59:30 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppbus/pps.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppbus/vpo.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppbus/vpoio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppc/ppc.c cc1: warnings being treated as errors /src/sys/dev/ppc/ppc.c: In function 'ppc_smc37c66xgt_detect': /src/sys/dev/ppc/ppc.c:724: warning: implicit declaration of function 'critical_leave' /src/sys/dev/ppc/ppc.c:724: warning: nested extern declaration of 'critical_leave' [-Wnested-externs] *** [ppc.o] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 06:05:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 06:05:47 - ERROR: failed to build LINT kernel TB --- 2013-02-21 06:05:47 - 5597.33 user 985.47 system 6926.93 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 06:13:49 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9B4DEBB5 for ; Thu, 21 Feb 2013 06:13:49 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 616D7119B for ; Thu, 21 Feb 2013 06:13:48 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1L6Dl7Z075583; Thu, 21 Feb 2013 01:13:47 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Thu, 21 Feb 2013 01:13:46 -0500 From: Brett Wynkoop To: george@ceetonetechnology.com Subject: Re: The Next BeagleBone Better & Faster for Less! Message-ID: <20130221011346.3c376117@ivory.wynn.com> In-Reply-To: <5125A73F.10802@ceetonetechnology.com> References: <5125A73F.10802@ceetonetechnology.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 06:13:49 -0000 On Wed, 20 Feb 2013 23:49:03 -0500 George Rosamond wrote: > On 02/20/13 23:27, Alie Tan wrote: > > Just got a news about new Beaglebone: > > > > http://beagleboard.org/unzipped/ > > Wow. Although personally, I could do without the HDMI. > > It would be ideal there was a stock FBSD image for them to provide for > purchasers... as in official on their www site as an alternative to > Linux. > > g Greeting- We need working USB support to contribute that to their site. Is this new bone going to be the same as the old bone, but with video, in other words will current kernels run or will the hard core kernel folks have to rework things? Sure wish I could find solid specs on the new bone! -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 Gun Control: The theory that a woman found dead in an alley, raped and strangled with her own pantyhose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 06:49:10 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E59965E2 for ; Thu, 21 Feb 2013 06:49:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by mx1.freebsd.org (Postfix) with ESMTP id B84DB146E for ; Thu, 21 Feb 2013 06:49:10 +0000 (UTC) Received: by mail-ia0-f180.google.com with SMTP id f27so8074464iae.11 for ; Wed, 20 Feb 2013 22:49:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=AQTwBuBJTCug+t9XlvdcRPept9MobDjZrJcZfKFvWCw=; b=fiRnr+92LWAsh3IGcGQhzN3y/zai2HdW7evUhxBo+jYiofUYaePPiTvGo4qa05EdV0 M01n8r0G/arXsw+KxyooDyFbytHkIieo5efkWSgNlBGSZxyhcg4xD0CVPgnYGBDhigRP Bv+VG2rWV/cfkXuX1eCJ8r5tIPBuHdjQ4QPoyB33XlFmVZqpVHlbaXn6i+yvdgO8I3CE +G2cRQJrEVgLPBLVITXcXMc5Dqv4+RXqLS2dh4mHtRWKXEJR43Qb4Y7OIWvgWbz8+9qp fFO+TUxZ+8FJGnwCL2ceqsrgFHwTR8pTVAUpIayAMG3R1vja6q/CyxV7JXDNYTgTP5/k Lyrw== X-Received: by 10.50.53.176 with SMTP id c16mr11612883igp.36.1361429350171; Wed, 20 Feb 2013 22:49:10 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id uy13sm18181308igb.7.2013.02.20.22.49.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 22:49:09 -0800 (PST) Sender: Warner Losh Subject: Re: The Next BeagleBone Better & Faster for Less! Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130221011346.3c376117@ivory.wynn.com> Date: Wed, 20 Feb 2013 23:49:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <48679DB0-7A2B-4617-BAA3-30C21F3CD61B@bsdimp.com> References: <5125A73F.10802@ceetonetechnology.com> <20130221011346.3c376117@ivory.wynn.com> To: Brett Wynkoop X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQklSOJ+EUcCeuh7vrhLAgdqfFVqFnryqgLx1kkxSqH3VOH/EEi85ekVGhBOcToreCdPnbgw Cc: george@ceetonetechnology.com, freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 06:49:11 -0000 On Feb 20, 2013, at 11:13 PM, Brett Wynkoop wrote: > On Wed, 20 Feb 2013 23:49:03 -0500 > George Rosamond wrote: >=20 >> On 02/20/13 23:27, Alie Tan wrote: >>> Just got a news about new Beaglebone: >>>=20 >>> http://beagleboard.org/unzipped/ >>=20 >> Wow. Although personally, I could do without the HDMI. >>=20 >> It would be ideal there was a stock FBSD image for them to provide = for >> purchasers... as in official on their www site as an alternative to >> Linux. >>=20 >> g >=20 > Greeting- >=20 > We need working USB support to contribute that to their site. >=20 > Is this new bone going to be the same as the old bone, but with video, > in other words will current kernels run or will the hard core kernel > folks have to rework things? We'll likely have to rework thing, at least if we want to run out of = flash on the card. it has a new flash chip that has micron markings on = it. Sure would be nice to know what, exactly, that chip is... Warner From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 14:16:12 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 59EC95E4; Thu, 21 Feb 2013 14:16:12 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id A51F377C; Thu, 21 Feb 2013 14:16:11 +0000 (UTC) Received: from terran (unknown [192.168.99.1]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPA id 6B1E7C4950; Thu, 21 Feb 2013 16:16:04 +0200 (EET) Date: Thu, 21 Feb 2013 16:16:27 +0200 From: Aleksandr Rybalko To: Warner Losh Subject: Re: SPI, _sz fields in struct spi_command Message-Id: <20130221161627.478d35aa88c95c03cafb00a7@freebsd.org> In-Reply-To: <62EDE91B-DDF3-462D-8802-7A7FBF00CE91@bsdimp.com> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> <62EDE91B-DDF3-462D-8802-7A7FBF00CE91@bsdimp.com> X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Patrick Kelsey , freebsd-arm@freebsd.org, ticso@cicely.de, freebsd-mips@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:16:12 -0000 On Wed, 20 Feb 2013 19:49:20 -0700 Warner Losh wrote: > > On Feb 20, 2013, at 5:26 PM, Aleksandr Rybalko wrote: > > > On Wed, 20 Feb 2013 13:57:52 -0500 > > Patrick Kelsey wrote: > > > >> On Wed, Feb 20, 2013 at 12:44 PM, Bernd Walter > >> wrote: > >>> On Wed, Feb 20, 2013 at 10:40:35AM -0500, Patrick Kelsey wrote: > >> > >>>> In (1) and (3) above, the drivers for those chips could usefully > >>>> tell the SPI bus interface that they aren't interested in received > >>>> data when transmitting to the SPI-attached devices, and certainly > >>>> it would be at least a small convenience to such SPI interface > >>>> consumers to have the lower level driver handle it. Since not all > >>>> host-side SPI interface hardware supports discarding received > >>>> data, to allow a zero-sized receive buffer in the command passed > >>>> down, at least some SPI interface hardware drivers will have to > >>>> dynamically allocate or maintain a static discard buffer and > >>>> provide error responses for allocation-failure or > >>>> transfer-too-large. > >>> > >>> If it is SPI hardware drivers decision you at least nee to take into > >>> account that in some RX-only cases you need 0xff dummy data. > >>> The slave chip driver knows if the device parses received data, but > >>> the master chip driver won't. > >>> > >>>> Example (2) is equally easy to handle on either side of the SPI bus > >>>> interface by pointing the transmit buffer pointer at the receive > >>>> buffer. > >>> > >>> This destroys the send data, which is not always welcome behavour. > >>> > >> > >> My comments are in the overall context of extending the functionality > >> of the existing SPI bus interface in ways that provide programming > >> conveniences to those who wish to use them. I am not suggesting in > >> any way that the current interface be narrowed based on any set of > >> assumptions, so in my view, there will always be a facility for fully > >> independent transmit and receive buffers specified by the caller. > >> > >> My example (2) was for a slave device that does not have a data input > >> pin and thus is oblivious to any data sent. Certainly, if you have a > >> device that can receive data sent by the master and your code design > >> calls for preserving the send data across bus transactions, you would > >> continue to use two separate buffers. > >> > >> -Patrick > > > > Thanks to all for interesting comments, some of my keys for that topic > > you all already said but I say it again anyway :) > > So why I ask about that: > > 1. Do we really need to allocate second unused buffer? > > Yes, but we could push that requirement into the spi host adapter drivr. > > > 2. Do we really need to spend clock cycles on that buffer? > > The way SPI works is that the cycles are spent, because TX cycles have to equal RX cycles. I understand how it works, I'm about allocating/zeroing/etc for that buffer. :) > > > 3. Ralink-s SPI can't do bidirectional transfer (IIRC I've tested it > > properly, only 1 8bits reg for both RX and TX and same data on read > > after TX byte) (Sorry for not commited yet, will do, hope soon :) ) > > 4. Since we have sz for both direction and both types (cmd, data) why > > controller drivers force us to make it equal? (at91_spi_transfer > > KASSERT) > > Because they must be equal. However, if we're pushing the buffer management down a level, then we can remove them. They must be equal for controller, but it's good to have way to hint controller about "we don't need to RX anything, so take care your requirements yourself" :) So at91_spi will use some own buffer for that case, but other controllers will not spend time on that buffer. > > > What I think we need to do with that: > > 1. remove KASSERT in controller drivers, make driver to accept at least > > cases when (tx_sz == rx_sz), (tx_sz && !rx_sz), (!tx_sz && rx_sz). Plus > > if controller require some buffer to drain into it (don't know how to > > correctly say in English what men do after many beers :) ) allocate it > > or make some static buffer. > > Yes, moving the responsibility from the driver to the spi controller would be possible. Yep > > > 2. teach consumers to give only correct numbers (very nice we have only > > two SPI devices in tree) > > I thought the at45 was bidirectional... Nope, all transfers fill some part of tx buffer, then read on offset=sizeof(some part) of rx buffer. > > > After that we will be able to make drivers for some (potential) devices > > which will require bidirectional communication. And controllers which > > can't do that, will just report error in that. I believe peoples thinks > > before attach such devices to controllers, so we will not have such > > incompatibility. > > If this feature becomes optional, we should have some way for the controller to communicate that it can do bidirectional transfers. If we have that, then such a device could refuse to attach on machines with controllers that can't do htat. In the normal world nobody produce systems which have incompatible parts :) > > > Hope I'm not forget something important :-D > > No, that's OK. > > Warner > > > Thanks to all! > > > > WBW > > -- > > Aleksandr Rybalko > -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 14:22:14 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 35E54A99; Thu, 21 Feb 2013 14:22:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0C0EE81E; Thu, 21 Feb 2013 14:22:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1LEMD55074840; Thu, 21 Feb 2013 09:22:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1LEMDom074839; Thu, 21 Feb 2013 14:22:13 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 21 Feb 2013 14:22:13 GMT Message-Id: <201302211422.r1LEMDom074839@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:22:14 -0000 TB --- 2013-02-21 12:20:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-21 12:20:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-21 12:20:17 - starting HEAD tinderbox run for arm/arm TB --- 2013-02-21 12:20:17 - cleaning the object tree TB --- 2013-02-21 12:25:57 - /usr/local/bin/svn stat /src TB --- 2013-02-21 12:26:00 - At svn revision 247093 TB --- 2013-02-21 12:26:01 - building world TB --- 2013-02-21 12:26:01 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 12:26:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 12:26:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 12:26:01 - SRCCONF=/dev/null TB --- 2013-02-21 12:26:01 - TARGET=arm TB --- 2013-02-21 12:26:01 - TARGET_ARCH=arm TB --- 2013-02-21 12:26:01 - TZ=UTC TB --- 2013-02-21 12:26:01 - __MAKE_CONF=/dev/null TB --- 2013-02-21 12:26:01 - cd /src TB --- 2013-02-21 12:26:01 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 21 12:26:06 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 21 14:15:42 UTC 2013 TB --- 2013-02-21 14:15:42 - generating LINT kernel config TB --- 2013-02-21 14:15:42 - cd /src/sys/arm/conf TB --- 2013-02-21 14:15:42 - /usr/bin/make -B LINT TB --- 2013-02-21 14:15:42 - cd /src/sys/arm/conf TB --- 2013-02-21 14:15:42 - /usr/sbin/config -m LINT TB --- 2013-02-21 14:15:42 - building LINT kernel TB --- 2013-02-21 14:15:42 - CROSS_BUILD_TESTING=YES TB --- 2013-02-21 14:15:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-21 14:15:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-21 14:15:42 - SRCCONF=/dev/null TB --- 2013-02-21 14:15:42 - TARGET=arm TB --- 2013-02-21 14:15:42 - TARGET_ARCH=arm TB --- 2013-02-21 14:15:42 - TZ=UTC TB --- 2013-02-21 14:15:42 - __MAKE_CONF=/dev/null TB --- 2013-02-21 14:15:42 - cd /src TB --- 2013-02-21 14:15:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 21 14:15:42 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppbus/pps.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppbus/vpo.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppbus/vpoio.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/ppc/ppc.c cc1: warnings being treated as errors /src/sys/dev/ppc/ppc.c: In function 'ppc_smc37c66xgt_detect': /src/sys/dev/ppc/ppc.c:724: warning: implicit declaration of function 'critical_leave' /src/sys/dev/ppc/ppc.c:724: warning: nested extern declaration of 'critical_leave' [-Wnested-externs] *** [ppc.o] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-21 14:22:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-21 14:22:13 - ERROR: failed to build LINT kernel TB --- 2013-02-21 14:22:13 - 5591.03 user 975.04 system 7315.57 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 14:30:05 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0BABADDA; Thu, 21 Feb 2013 14:30:05 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 6B03D8BA; Thu, 21 Feb 2013 14:30:04 +0000 (UTC) Received: from terran (unknown [192.168.99.1]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPA id EBE9EC4950; Thu, 21 Feb 2013 16:30:02 +0200 (EET) Date: Thu, 21 Feb 2013 16:30:26 +0200 From: Aleksandr Rybalko To: ticso@cicely.de Subject: Re: SPI, _sz fields in struct spi_command Message-Id: <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> In-Reply-To: <20130221014433.GA12189@cicely7.cicely.de> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Patrick Kelsey , freebsd-arm@freebsd.org, Bernd Walter , freebsd-mips@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:30:05 -0000 On Thu, 21 Feb 2013 02:44:33 +0100 Bernd Walter wrote: > On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr Rybalko wrote: > > On Wed, 20 Feb 2013 13:57:52 -0500 > > Patrick Kelsey wrote: > > > > > On Wed, Feb 20, 2013 at 12:44 PM, Bernd Walter > > > wrote: > > > > On Wed, Feb 20, 2013 at 10:40:35AM -0500, Patrick Kelsey wrote: > > > > > > >> In (1) and (3) above, the drivers for those chips could usefully > > > >> tell the SPI bus interface that they aren't interested in received > > > >> data when transmitting to the SPI-attached devices, and certainly > > > >> it would be at least a small convenience to such SPI interface > > > >> consumers to have the lower level driver handle it. Since not all > > > >> host-side SPI interface hardware supports discarding received > > > >> data, to allow a zero-sized receive buffer in the command passed > > > >> down, at least some SPI interface hardware drivers will have to > > > >> dynamically allocate or maintain a static discard buffer and > > > >> provide error responses for allocation-failure or > > > >> transfer-too-large. > > > > > > > > If it is SPI hardware drivers decision you at least nee to take into > > > > account that in some RX-only cases you need 0xff dummy data. > > > > The slave chip driver knows if the device parses received data, but > > > > the master chip driver won't. > > > > > > > >> Example (2) is equally easy to handle on either side of the SPI bus > > > >> interface by pointing the transmit buffer pointer at the receive > > > >> buffer. > > > > > > > > This destroys the send data, which is not always welcome behavour. > > > > > > > > > > My comments are in the overall context of extending the functionality > > > of the existing SPI bus interface in ways that provide programming > > > conveniences to those who wish to use them. I am not suggesting in > > > any way that the current interface be narrowed based on any set of > > > assumptions, so in my view, there will always be a facility for fully > > > independent transmit and receive buffers specified by the caller. > > > > > > My example (2) was for a slave device that does not have a data input > > > pin and thus is oblivious to any data sent. Certainly, if you have a > > > device that can receive data sent by the master and your code design > > > calls for preserving the send data across bus transactions, you would > > > continue to use two separate buffers. > > > > > > -Patrick > > > > Thanks to all for interesting comments, some of my keys for that topic > > you all already said but I say it again anyway :) > > So why I ask about that: > > 1. Do we really need to allocate second unused buffer? > > For AT91 yes, unless: > - RX-only and you know that sending the RX buffers undefined content is Ok, > which is not if the device needs 0xff > - TX-only and you know that trashing the TX buffer is Ok Are you remember some? And anyway, with new scheme driver developer know requirement of device and will prepare second buffer for that device. Thanks to imp@ we have transfer structure which able to carry that simply :) > > > 2. Do we really need to spend clock cycles on that buffer? > > For AT91 it is required, others maybe not. I'm more about software :) > > > 3. Ralink-s SPI can't do bidirectional transfer (IIRC I've tested it > > properly, only 1 8bits reg for both RX and TX and same data on read > > after TX byte) (Sorry for not commited yet, will do, hope soon :) ) > > 4. Since we have sz for both direction and both types (cmd, data) why > > controller drivers force us to make it equal? (at91_spi_transfer > > KASSERT) > > They can't otherwise. They(drivers) can fill his(controllers) requirements :) > > > What I think we need to do with that: > > 1. remove KASSERT in controller drivers, make driver to accept at least > > cases when (tx_sz == rx_sz), (tx_sz && !rx_sz), (!tx_sz && rx_sz). Plus > > if controller require some buffer to drain into it (don't know how to > > correctly say in English what men do after many beers :) ) allocate it > > or make some static buffer. > > Sounds good. > Static buffers however may require multiple DMA setup if the transfer > request ist bigger. > With AT91 this can be done via *empty interrupt to replay the same buffer. > It is just not wise to interrupt on each single byte, which would be required > without a DMA buffer at all. > Sending 0xff as default dummy data requires filling the TX buffer with > this value, so maybe if doing static then have 2 buffers, one with 0xff > dummy data and one bit-bucket buffer to RX into. > Otherwise use the same dummy data and if a driver requires sending dummy > 0xff it needs to supply its own buffer, but there are many devices requiring > this. Better to not do something special, until we know requirements. Device want zeros on input while it do output, then driver must care for that. Simple is always better :-D > > > 2. teach consumers to give only correct numbers (very nice we have only > > two SPI devices in tree) > > > > After that we will be able to make drivers for some (potential) devices > > which will require bidirectional communication. And controllers which > > can't do that, will just report error in that. I believe peoples thinks > > before attach such devices to controllers, so we will not have such > > incompatibility. > > I don't think there are many devices requiring RX/TX at the same time. Anyway, we will be able to do that, and we don't care now because don't have such drivers yet. > And if a controller won't support it there is nothing to be done anyway > beside bit bang-ing. > But I usually do RX/TX at the same transfer with devices wanting a comand > word and then sending data at the next data word. > In many cases you must not deassert CS during this. As I seen, all controller drivers do exact that. > I don't know how CS is handled in our SPI as I never did SPI with FreeBSD. > If CS is handled automatically on each transaction then it must support > bidirectional transactions. > If CS however are done with separate calls it is Ok to do a TX and then > an TX call before deasserting. > The AT91 hardware has automatic CS support - in my own controller code > outside of FreeBSD I usually prefer handling CS with GPIO for that reason. > > > Hope I'm not forget something important :-D > > > > Thanks to all! > > > > WBW > > -- > > Aleksandr Rybalko > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. Thanks for comments Bernd! WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 14:46:02 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3BA712D3 for ; Thu, 21 Feb 2013 14:46:02 +0000 (UTC) (envelope-from werner@thieprojects.ch) Received: from newton.metanet.ch (newton.metanet.ch [80.74.158.130]) by mx1.freebsd.org (Postfix) with ESMTP id 9249C9A9 for ; Thu, 21 Feb 2013 14:46:01 +0000 (UTC) Received: (qmail 30234 invoked from network); 21 Feb 2013 15:45:54 +0100 Received: from 217-071-083-008.ip-tech.ch (HELO ?192.168.11.88?) (217.71.83.8) by newton.metanet.ch with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Feb 2013 15:45:54 +0100 Message-ID: <51263322.3030706@thieprojects.ch> Date: Thu, 21 Feb 2013 15:45:54 +0100 From: Werner Thie User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: MFCard access speed difference between RPi and Beaglebone Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:46:02 -0000 Hi trying to nail down the crash and core dump in Python when importing ctypes I did a parallel build of python on both systems with the same SVN rev 246947 of kernel. The RPi seems to beat the Bbone quite clearly with a ration of 6 : 10 It is very apparent (when unpacking for instance) that the Bb shows a much more pronounced 'hickup' behavior, unpacking 40-60 files and then most probably doing disk IO. Swapping the MFCards does not change the situation at all. Can anybody out there suppprt this observation and/or explain it? Cheers, Werner From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 14:48:39 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E10763CE for ; Thu, 21 Feb 2013 14:48:39 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 0FA619D1 for ; Thu, 21 Feb 2013 14:48:34 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1LEmRaN042000 for ; Thu, 21 Feb 2013 07:48:28 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1LEmPl7052940; Thu, 21 Feb 2013 07:48:25 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: The Next BeagleBone Better & Faster for Less! From: Ian Lepore To: Warner Losh In-Reply-To: <48679DB0-7A2B-4617-BAA3-30C21F3CD61B@bsdimp.com> References: <5125A73F.10802@ceetonetechnology.com> <20130221011346.3c376117@ivory.wynn.com> <48679DB0-7A2B-4617-BAA3-30C21F3CD61B@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Feb 2013 07:48:25 -0700 Message-ID: <1361458105.1185.19.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: george@ceetonetechnology.com, freebsd-arm@FreeBSD.org, Brett Wynkoop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:48:39 -0000 On Wed, 2013-02-20 at 23:49 -0700, Warner Losh wrote: > On Feb 20, 2013, at 11:13 PM, Brett Wynkoop wrote: > > > On Wed, 20 Feb 2013 23:49:03 -0500 > > George Rosamond wrote: > > > >> On 02/20/13 23:27, Alie Tan wrote: > >>> Just got a news about new Beaglebone: > >>> > >>> http://beagleboard.org/unzipped/ > >> > >> Wow. Although personally, I could do without the HDMI. > >> > >> It would be ideal there was a stock FBSD image for them to provide for > >> purchasers... as in official on their www site as an alternative to > >> Linux. > >> > >> g > > > > Greeting- > > > > We need working USB support to contribute that to their site. > > > > Is this new bone going to be the same as the old bone, but with video, > > in other words will current kernels run or will the hard core kernel > > folks have to rework things? > > We'll likely have to rework thing, at least if we want to run out of flash on the card. it has a new flash chip that has micron markings on it. Sure would be nice to know what, exactly, that chip is... > > Warner Unless it's a fairly old chip, or one of Micron's offerings with on-chip ECC, our current ecc code isn't going to handle it. I just spent weeks learning that the hard way. The ecc code we have checked in is a hamming code implementation that can correct single-bit errors, and modern nand chips are requiring algorithms that can correct multi-bit errors. Our current code also isn't ready to handle the situation where the SoC's nand flash controller hardware does ecc with some cooperation from software. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 14:58:44 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1B29D88B for ; Thu, 21 Feb 2013 14:58:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x22c.google.com (ia-in-x022c.1e100.net [IPv6:2607:f8b0:4001:c02::22c]) by mx1.freebsd.org (Postfix) with ESMTP id E0720A9A for ; Thu, 21 Feb 2013 14:58:43 +0000 (UTC) Received: by mail-ia0-f172.google.com with SMTP id l29so6149141iag.17 for ; Thu, 21 Feb 2013 06:58:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=70/kVyayxlgxprR+Rz/pDaNH4jZ4zYq25YdYEedX3xQ=; b=JzekeinSci5i+3sDnalMZXD+91138Mjpn+M3laGpKkGsKA0i0KqdMQKyriSGH+po0r jM4V0q1baTLww1fsW98k0RAc6xbLBQGlmmfLE2t1H9ZNRyIAY53F/l6GYbqItXN4acoA kpX3I2rBNIJ13Vizhw2GDZklu4z0GuSAueFbKBhwmFhGHUhAVhP3UIv5dh4751WEMAN5 XUlucCr4h057LEBZChIw8T481BGgsHCtmd18GbuPJeRSGa2NGQcm3KnlBFeu28NA4Lr1 kaiw1OuHEtzBXgg/dyuykgiuclc6ypy2h0W/yxkNHuiePPwzwG383Y+qqMoXIJnOeZ6m BN6w== X-Received: by 10.50.88.168 with SMTP id bh8mr4049256igb.67.1361458723413; Thu, 21 Feb 2013 06:58:43 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id dy5sm12385494igc.1.2013.02.21.06.58.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 06:58:42 -0800 (PST) Sender: Warner Losh Subject: Re: The Next BeagleBone Better & Faster for Less! Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1361458105.1185.19.camel@revolution.hippie.lan> Date: Thu, 21 Feb 2013 07:58:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5125A73F.10802@ceetonetechnology.com> <20130221011346.3c376117@ivory.wynn.com> <48679DB0-7A2B-4617-BAA3-30C21F3CD61B@bsdimp.com> <1361458105.1185.19.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmzDBavKylRer3xaa03YnFwCb0kl8shZPx1MfPqqqqeNnKiS6N3ZNJRKG1VRJxrbUuXAFQ/ Cc: george@ceetonetechnology.com, freebsd-arm@FreeBSD.org, Brett Wynkoop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:58:44 -0000 On Feb 21, 2013, at 7:48 AM, Ian Lepore wrote: > On Wed, 2013-02-20 at 23:49 -0700, Warner Losh wrote: >> On Feb 20, 2013, at 11:13 PM, Brett Wynkoop wrote: >>=20 >>> On Wed, 20 Feb 2013 23:49:03 -0500 >>> George Rosamond wrote: >>>=20 >>>> On 02/20/13 23:27, Alie Tan wrote: >>>>> Just got a news about new Beaglebone: >>>>>=20 >>>>> http://beagleboard.org/unzipped/ >>>>=20 >>>> Wow. Although personally, I could do without the HDMI. >>>>=20 >>>> It would be ideal there was a stock FBSD image for them to provide = for >>>> purchasers... as in official on their www site as an alternative to >>>> Linux. >>>>=20 >>>> g >>>=20 >>> Greeting- >>>=20 >>> We need working USB support to contribute that to their site. >>>=20 >>> Is this new bone going to be the same as the old bone, but with = video, >>> in other words will current kernels run or will the hard core kernel >>> folks have to rework things? >>=20 >> We'll likely have to rework thing, at least if we want to run out of = flash on the card. it has a new flash chip that has micron markings on = it. Sure would be nice to know what, exactly, that chip is... >>=20 >> Warner >=20 > Unless it's a fairly old chip, or one of Micron's offerings with = on-chip > ECC, our current ecc code isn't going to handle it. I just spent = weeks > learning that the hard way. The ecc code we have checked in is a > hamming code implementation that can correct single-bit errors, and > modern nand chips are requiring algorithms that can correct multi-bit > errors. Our current code also isn't ready to handle the situation = where > the SoC's nand flash controller hardware does ecc with some = cooperation > from software. Yes. I believe that the newest ~20nm chips require 40 bits per 1k of = correction, and the current, but soon to be phased out ~25nm chips = require 30 bits of correction. Only the really old 5x nm MLC parts and = up through the 3x SLC parts can get bye with a 1 bit corrector. Most = people use some flavor of bch code these days, not the simpler hamming = code. I'm not aware of any NAND chips that have the ECC engine integrated into = them, but that may just be due to my focus in the NAND market these = days. Are you sure you don't mean ECC engines in the SoC itself, which = seem to be much more common? Then again, I've been trying to avoid = dealing too much with NAND Flash in open source these days... Warner= From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 15:17:42 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 181A5E15 for ; Thu, 21 Feb 2013 15:17:42 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id E0153BF9 for ; Thu, 21 Feb 2013 15:17:41 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1LFHfOH042499 for ; Thu, 21 Feb 2013 08:17:41 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1LFHcSu052973; Thu, 21 Feb 2013 08:17:39 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: The Next BeagleBone Better & Faster for Less! From: Ian Lepore To: Warner Losh In-Reply-To: References: <5125A73F.10802@ceetonetechnology.com> <20130221011346.3c376117@ivory.wynn.com> <48679DB0-7A2B-4617-BAA3-30C21F3CD61B@bsdimp.com> <1361458105.1185.19.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Feb 2013 08:17:38 -0700 Message-ID: <1361459858.1185.25.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: george@ceetonetechnology.com, freebsd-arm@FreeBSD.org, Brett Wynkoop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:17:42 -0000 On Thu, 2013-02-21 at 07:58 -0700, Warner Losh wrote: > On Feb 21, 2013, at 7:48 AM, Ian Lepore wrote: > > > On Wed, 2013-02-20 at 23:49 -0700, Warner Losh wrote: > >> On Feb 20, 2013, at 11:13 PM, Brett Wynkoop wrote: > >> > >>> On Wed, 20 Feb 2013 23:49:03 -0500 > >>> George Rosamond wrote: > >>> > >>>> On 02/20/13 23:27, Alie Tan wrote: > >>>>> Just got a news about new Beaglebone: > >>>>> > >>>>> http://beagleboard.org/unzipped/ > >>>> > >>>> Wow. Although personally, I could do without the HDMI. > >>>> > >>>> It would be ideal there was a stock FBSD image for them to provide for > >>>> purchasers... as in official on their www site as an alternative to > >>>> Linux. > >>>> > >>>> g > >>> > >>> Greeting- > >>> > >>> We need working USB support to contribute that to their site. > >>> > >>> Is this new bone going to be the same as the old bone, but with video, > >>> in other words will current kernels run or will the hard core kernel > >>> folks have to rework things? > >> > >> We'll likely have to rework thing, at least if we want to run out of flash on the card. it has a new flash chip that has micron markings on it. Sure would be nice to know what, exactly, that chip is... > >> > >> Warner > > > > Unless it's a fairly old chip, or one of Micron's offerings with on-chip > > ECC, our current ecc code isn't going to handle it. I just spent weeks > > learning that the hard way. The ecc code we have checked in is a > > hamming code implementation that can correct single-bit errors, and > > modern nand chips are requiring algorithms that can correct multi-bit > > errors. Our current code also isn't ready to handle the situation where > > the SoC's nand flash controller hardware does ecc with some cooperation > > from software. > > Yes. I believe that the newest ~20nm chips require 40 bits per 1k of correction, and the current, but soon to be phased out ~25nm chips require 30 bits of correction. Only the really old 5x nm MLC parts and up through the 3x SLC parts can get bye with a 1 bit corrector. Most people use some flavor of bch code these days, not the simpler hamming code. > > I'm not aware of any NAND chips that have the ECC engine integrated into them, but that may just be due to my focus in the NAND market these days. Are you sure you don't mean ECC engines in the SoC itself, which seem to be much more common? Then again, I've been trying to avoid dealing too much with NAND Flash in open source these days... > > Warner No, I very much mean (mostly-) transparent ECC performed wholly within the nand chip. The one we just switched to (because our AT91 SoCs don't have the horsepower to do software multi-bit ecc) is MT29F4G08ABADAWP. The "mostly" part is that the hardware puts the ecc data where it wants within the spare area and if software wants to use any spare-area bytes as metadata it must work around the hardware ecc data. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 15:21:03 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3CF35F67; Thu, 21 Feb 2013 15:21:03 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 556BEC2B; Thu, 21 Feb 2013 15:21:01 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id w5so4181529bku.41 for ; Thu, 21 Feb 2013 07:21:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=s9vmj0Q10HVzEGIuwILtE//1cgLoNE+tOUjr0DgghTU=; b=MIhselwS7Eta5g5m/9Ehi81j3XiC3/ajoDZkVjvD9KsZe4oNYC8g8Lj1iIJRDjjrR5 WVsm+4UhNaCU3KwmngtbI4i3LRrViTwcfmDQfh2YR1AX78xuLhDDqMnp+XenbI/h5JJK jk684f4aSSelStK735t31rXK94aUkkVoAO7wzH2cqsudkMPHpo10rlpTB5qt/hQTzHzu /5es4Xsd4O338s5sXgXgWjoqFBnv4V3iVVVz5hUafnaEXhdXtxvVgMhnl074rKc9hi3f kC6x237t2kaq4rTgMgQkrSiQ10+c43sYXPX28bS5XZfhzqB/7ldZBgU34x6pCrL/tG44 iXnA== MIME-Version: 1.0 X-Received: by 10.204.157.150 with SMTP id b22mr10643610bkx.121.1361460060904; Thu, 21 Feb 2013 07:21:00 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.204.128.213 with HTTP; Thu, 21 Feb 2013 07:21:00 -0800 (PST) In-Reply-To: <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> Date: Thu, 21 Feb 2013 10:21:00 -0500 X-Google-Sender-Auth: J65QkwzS-WHCMjsxmJsL8WBBtOE Message-ID: Subject: Re: SPI, _sz fields in struct spi_command From: Patrick Kelsey To: Aleksandr Rybalko Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org, Bernd Walter , ticso@cicely.de, freebsd-mips@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:21:03 -0000 >On Thu, Feb 21, 2013 at 9:30 AM, Aleksandr Rybalko wrote: >> On Thu, 21 Feb 2013 02:44:33 +0100 >> Bernd Walter wrote: >> >> On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr Rybalko wrote: >> > 2. teach consumers to give only correct numbers (very nice we have only >> > two SPI devices in tree) >> > >> > After that we will be able to make drivers for some (potential) devices >> > which will require bidirectional communication. And controllers which >> > can't do that, will just report error in that. I believe peoples thinks >> > before attach such devices to controllers, so we will not have such >> > incompatibility. >> >> I don't think there are many devices requiring RX/TX at the same time. > > Anyway, we will be able to do that, and we don't care now because don't > have such drivers yet. > Taking the view that "RX/TX at the same time" means that one wants to send meaningful data to the slave device at the same time one is interested in what data is returned during that transmission, there are such devices in use out there. Linear Technologies has several ADCs, such as the LTC2446, for which you obtain the previous conversion result while sending the configuration bits for the next conversion to be performed. Although this is slightly out of focus for the specific issue originally raised, while on the topic of things that need to get done on SPI in real systems, there are also devices out there that require specific data or some number of clocks to be provided while chip select is deasserted. One example of the former is the LTC2404, which is a multichannel ADC for which the input channel for the next conversion is selected by the last four bits clocked in *before* chip select is asserted. One example of the latter is the spec for SPI access to MMC/SD cards, which requires a certain number of clocks to be applied with chip select deasserted in order to initialize the card. If you ever find yourself wondering why an SPI software interface provides independent bus acquisition and chip select control, the reason is to support these types of devices. -Patrick From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 16:19:29 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D060614D for ; Thu, 21 Feb 2013 16:19:29 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8DACC235 for ; Thu, 21 Feb 2013 16:19:29 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1LGJRj3084677; Thu, 21 Feb 2013 11:19:27 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Thu, 21 Feb 2013 11:19:27 -0500 From: Brett Wynkoop To: Werner Thie Subject: Re: MFCard access speed difference between RPi and Beaglebone Message-ID: <20130221111927.1687e114@ivory.wynn.com> In-Reply-To: <51263322.3030706@thieprojects.ch> References: <51263322.3030706@thieprojects.ch> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 16:19:29 -0000 On Thu, 21 Feb 2013 15:45:54 +0100 Werner Thie wrote: > Hi > > trying to nail down the crash and core dump in Python when importing > ctypes I did a parallel build of python on both systems with the same > SVN rev 246947 of kernel. > Greeting- How long did it take you to build python on each box? At the moment I can only do ports builds on the Pi because of lack of disk space on the bone. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 "The strongest reason for the people to retain the right to keep and bear arms is, as a last resort, to protect themselves against tyranny in government" - Thomas Jefferson. From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 16:30:28 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3BBF3377; Thu, 21 Feb 2013 16:30:28 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id DB3282B5; Thu, 21 Feb 2013 16:30:26 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id r1LGUIl2043298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Feb 2013 17:30:18 +0100 (CET) (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 r1LGU4Zp074880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 17:30:04 +0100 (CET) (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 r1LGU4Se017045; Thu, 21 Feb 2013 17:30:04 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id r1LGU3xn017044; Thu, 21 Feb 2013 17:30:03 +0100 (CET) (envelope-from ticso) Date: Thu, 21 Feb 2013 17:30:03 +0100 From: Bernd Walter To: Patrick Kelsey Subject: Re: SPI, _sz fields in struct spi_command Message-ID: <20130221163003.GC12189@cicely7.cicely.de> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Aleksandr Rybalko , Bernd Walter , freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 16:30:28 -0000 On Thu, Feb 21, 2013 at 10:21:00AM -0500, Patrick Kelsey wrote: > >On Thu, Feb 21, 2013 at 9:30 AM, Aleksandr Rybalko wrote: > >> On Thu, 21 Feb 2013 02:44:33 +0100 > >> Bernd Walter wrote: > >> > >> On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr Rybalko wrote: > >> > 2. teach consumers to give only correct numbers (very nice we have only > >> > two SPI devices in tree) > >> > > >> > After that we will be able to make drivers for some (potential) devices > >> > which will require bidirectional communication. And controllers which > >> > can't do that, will just report error in that. I believe peoples thinks > >> > before attach such devices to controllers, so we will not have such > >> > incompatibility. > >> > >> I don't think there are many devices requiring RX/TX at the same time. > > > > Anyway, we will be able to do that, and we don't care now because don't > > have such drivers yet. > > > > Taking the view that "RX/TX at the same time" means that one wants to > send meaningful data to the slave device at the same time one is > interested in what data is returned during that transmission, there > are such devices in use out there. Linear Technologies has several > ADCs, such as the LTC2446, for which you obtain the previous > conversion result while sending the configuration bits for the next > conversion to be performed. Forgot about ADC with channel selection. > Although this is slightly out of focus for the specific issue > originally raised, while on the topic of things that need to get done > on SPI in real systems, there are also devices out there that require > specific data or some number of clocks to be provided while chip > select is deasserted. One example of the former is the LTC2404, which > is a multichannel ADC for which the input channel for the next > conversion is selected by the last four bits clocked in *before* chip > select is asserted. One example of the latter is the spec for SPI > access to MMC/SD cards, which requires a certain number of clocks to > be applied with chip select deasserted in order to initialize the > card. If you ever find yourself wondering why an SPI software > interface provides independent bus acquisition and chip select > control, the reason is to support these types of devices. With many ADC you also want probing support. Assign CS and GPIO-read MISO for ready without clocking. Some flash chips also work this way. Not sure if AT45DB support this and how our driver works. With own projects I usually ask AT45DB about ready state by transfering a status word. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 16:58:21 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ACE8DD70 for ; Thu, 21 Feb 2013 16:58:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gg0-x231.google.com (mail-gg0-x231.google.com [IPv6:2607:f8b0:4002:c02::231]) by mx1.freebsd.org (Postfix) with ESMTP id 715C46B3 for ; Thu, 21 Feb 2013 16:58:21 +0000 (UTC) Received: by mail-gg0-f177.google.com with SMTP id q1so1238721gge.8 for ; Thu, 21 Feb 2013 08:58:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=TYo1o/KaRVscz/jKakqykSLLY3KlJR47XYqJHKnrXko=; b=m8hzVzetnyZeKBca266BXy0zzw6yR2Kcx837+2OdxEljENCNdOt0rP3y5X3jR9wlKT Cx6aCwAua0mchiJnHk9DVz5Kpw+YOXnqKIfSoEhc6JRR9Yuf8kL+LbS0T++s7kR8diW4 EQWC5YqqR9zLrOM2NiTjWR6vA7dP/KUxSt0FA+wfred+DQH7z5Y20NyImasPezj2EfsM dp4PX3JXI+RMBjt5fGbz6Bcgu75Td1JHIXiESpYMIaFBhZcy453OLyds6QfcMq2nLSLX d5oHcJ/2ljTalZBHcrJpKWDjtJtqvAtbaisonBRbfG8LxjfwbcSvidhqh3itMBPZ8Mct 8HsQ== X-Received: by 10.236.156.197 with SMTP id m45mr46340710yhk.60.1361465900943; Thu, 21 Feb 2013 08:58:20 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id d19sm77661625anm.18.2013.02.21.08.58.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 08:58:20 -0800 (PST) Sender: Warner Losh Subject: Re: The Next BeagleBone Better & Faster for Less! Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1361459858.1185.25.camel@revolution.hippie.lan> Date: Thu, 21 Feb 2013 09:58:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4D7690E7-FF0E-4354-961A-BE481F4F09E6@bsdimp.com> References: <5125A73F.10802@ceetonetechnology.com> <20130221011346.3c376117@ivory.wynn.com> <48679DB0-7A2B-4617-BAA3-30C21F3CD61B@bsdimp.com> <1361458105.1185.19.camel@revolution.hippie.lan> <1361459858.1185.25.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlgZeNvQjGRqxYnJpXU4l1iX+ZUcd0sjZqqoKB+Jzpk0RvnziYmhtk1TKNOECcfWu+jFel0 Cc: george@ceetonetechnology.com, freebsd-arm@FreeBSD.org, Brett Wynkoop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 16:58:21 -0000 On Feb 21, 2013, at 8:17 AM, Ian Lepore wrote: > MT29F4G08ABADAWP That's a sweet setup! Just got done reading the data sheet. I learned = something new today. I'd been reading too many SoC flash ECC engine = descriptions lately... This is a 34nm SLC part, btw, and the internal ECC gives 4 bits of = correction, which should be plenty... Warner From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 16:59:19 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2BC6ADC0; Thu, 21 Feb 2013 16:59:19 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id D55B66C1; Thu, 21 Feb 2013 16:59:18 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1LGx0QS094648; Thu, 21 Feb 2013 16:59:00 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id nuuc3bzsnrpgnv9mu8z4tqxnve; Thu, 21 Feb 2013 16:59:00 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: The Next BeagleBone Better & Faster for Less! Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <1361459858.1185.25.camel@revolution.hippie.lan> Date: Thu, 21 Feb 2013 08:58:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5125A73F.10802@ceetonetechnology.com> <20130221011346.3c376117@ivory.wynn.com> <48679DB0-7A2B-4617-BAA3-30C21F3CD61B@bsdimp.com> <1361458105.1185.19.camel@revolution.hippie.lan> <1361459858.1185.25.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: george@ceetonetechnology.com, freebsd-arm@freebsd.org, Brett Wynkoop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 16:59:19 -0000 On Feb 21, 2013, at 7:17 AM, Ian Lepore wrote: > On Thu, 2013-02-21 at 07:58 -0700, Warner Losh wrote: >> On Feb 21, 2013, at 7:48 AM, Ian Lepore wrote: >>=20 >>> On Wed, 2013-02-20 at 23:49 -0700, Warner Losh wrote: >>>> On Feb 20, 2013, at 11:13 PM, Brett Wynkoop wrote: >>>>=20 >>>>> On Wed, 20 Feb 2013 23:49:03 -0500 >>>>> George Rosamond wrote: >>>>>=20 >>>>>> On 02/20/13 23:27, Alie Tan wrote: >>>>>>> Just got a news about new Beaglebone: >>>>>>>=20 >>>>>>> http://beagleboard.org/unzipped/ >>>>>>=20 >>>>>> Wow. Although personally, I could do without the HDMI. >>>>>>=20 >>>>>> It would be ideal there was a stock FBSD image for them to = provide for >>>>>> purchasers... as in official on their www site as an alternative = to >>>>>> Linux. >>>>>>=20 >>>>>> g >>>>>=20 >>>>> Greeting- >>>>>=20 >>>>> We need working USB support to contribute that to their site. >>>>>=20 >>>>> Is this new bone going to be the same as the old bone, but with = video, >>>>> in other words will current kernels run or will the hard core = kernel >>>>> folks have to rework things? >>>>=20 >>>> We'll likely have to rework thing, at least if we want to run out = of flash on the card. it has a new flash chip that has micron markings = on it. Sure would be nice to know what, exactly, that chip is=85 I haven't found what SoC the new BeagleBone is using, but the AM3359 used on the original BeagleBone does support hardware ECC in the memory controller. "Section 7.1.1.1 GPMC (General Purpose Memory Controller) Features =85 =95 Up to 16-bit ECC support for NAND flash using BCH code (t=3D4, 8 or 16) or Hamming code for 8-bit or 16-bit NAND-flash, organized with page size of 512 bytes, 1K bytes, or more." There is also an "Error Location Module" documented in Section 7.4 of the TRM which seems to be the component that actually implements the ECC coding and works with the GPMC. Definitely a chunk of work to integrate, but it doesn't appear to require that we implement software ECC. Tim From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 17:01:52 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 17DD3459 for ; Thu, 21 Feb 2013 17:01:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gg0-x22a.google.com (gg-in-x022a.1e100.net [IPv6:2607:f8b0:4002:c02::22a]) by mx1.freebsd.org (Postfix) with ESMTP id CF8DE721 for ; Thu, 21 Feb 2013 17:01:51 +0000 (UTC) Received: by mail-gg0-f170.google.com with SMTP id k4so1255429ggn.15 for ; Thu, 21 Feb 2013 09:01:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=kcu70eVOsLEgVc7wW86xmI+np1Lh3fLuULMR8uFNE9M=; b=dsqosO3NBMQbg8dKQWrnovwRwue+VHrnjIxPYOfIkPUGbQelYH5fLIHcRaIkiSQxmU ChTjR3AllQOMLkttlnf20DyiXMHrQRbqO11pCaW6k7Xet3RufyCkKg5r3UFbcjnncYYF MAIvZfqiaTTFKIMI4iW3g1FctXJcEH0+I67OnuU+eNMVQ7yYR2U3PZjtt5BHihHyxidx 1PaimtiZGcGzeh7u9q59hJnJehfbkgMHZrVVzlw1w5audNwhTmXSsJA2p1FIF3DZM5qv 8wRhzdQsD3/B7nBmcFdbOX0X07kRyf5jX0NZ6soHEPD6pjPKomHAfw7iM6YoXleHro5W XrUQ== X-Received: by 10.101.165.18 with SMTP id s18mr13779495ano.49.1361466111191; Thu, 21 Feb 2013 09:01:51 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id n4sm45195929ank.1.2013.02.21.09.01.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 09:01:50 -0800 (PST) Sender: Warner Losh Subject: Re: The Next BeagleBone Better & Faster for Less! Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: Date: Thu, 21 Feb 2013 10:01:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5B57B232-3DEE-42A4-9623-58E7D75291B9@bsdimp.com> References: <5125A73F.10802@ceetonetechnology.com> <20130221011346.3c376117@ivory.wynn.com> <48679DB0-7A2B-4617-BAA3-30C21F3CD61B@bsdimp.com> <1361458105.1185.19.camel@revolution.hippie.lan> <1361459858.1185.25.camel@revolution.hippie.lan> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmbeilyhgxVhzu89lYbp+FRvAximbazuWFuA6WQ69E92H7j5ohg4EfQhCMcIql9Qzd1QVdg Cc: george@ceetonetechnology.com, freebsd-arm@freebsd.org, Brett Wynkoop , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 17:01:52 -0000 On Feb 21, 2013, at 9:58 AM, Tim Kientzle wrote: >=20 > On Feb 21, 2013, at 7:17 AM, Ian Lepore wrote: >=20 >> On Thu, 2013-02-21 at 07:58 -0700, Warner Losh wrote: >>> On Feb 21, 2013, at 7:48 AM, Ian Lepore wrote: >>>=20 >>>> On Wed, 2013-02-20 at 23:49 -0700, Warner Losh wrote: >>>>> On Feb 20, 2013, at 11:13 PM, Brett Wynkoop wrote: >>>>>=20 >>>>>> On Wed, 20 Feb 2013 23:49:03 -0500 >>>>>> George Rosamond wrote: >>>>>>=20 >>>>>>> On 02/20/13 23:27, Alie Tan wrote: >>>>>>>> Just got a news about new Beaglebone: >>>>>>>>=20 >>>>>>>> http://beagleboard.org/unzipped/ >>>>>>>=20 >>>>>>> Wow. Although personally, I could do without the HDMI. >>>>>>>=20 >>>>>>> It would be ideal there was a stock FBSD image for them to = provide for >>>>>>> purchasers... as in official on their www site as an alternative = to >>>>>>> Linux. >>>>>>>=20 >>>>>>> g >>>>>>=20 >>>>>> Greeting- >>>>>>=20 >>>>>> We need working USB support to contribute that to their site. >>>>>>=20 >>>>>> Is this new bone going to be the same as the old bone, but with = video, >>>>>> in other words will current kernels run or will the hard core = kernel >>>>>> folks have to rework things? >>>>>=20 >>>>> We'll likely have to rework thing, at least if we want to run out = of flash on the card. it has a new flash chip that has micron markings = on it. Sure would be nice to know what, exactly, that chip is=85 >=20 > I haven't found what SoC the new BeagleBone is > using, but the AM3359 used on the original BeagleBone > does support hardware ECC in the memory controller. >=20 > "Section 7.1.1.1 GPMC (General Purpose Memory Controller) Features > =85 > =95 Up to 16-bit ECC support for NAND flash using BCH code (t=3D4, 8 > or 16) or Hamming code for 8-bit or 16-bit NAND-flash, organized > with page size of 512 bytes, 1K bytes, or more." >=20 > There is also an "Error Location Module" documented in Section 7.4 > of the TRM which seems to be the component that actually > implements the ECC coding and works with the GPMC. >=20 > Definitely a chunk of work to integrate, but it doesn't appear > to require that we implement software ECC. Software BCH is very slow in comparison to hardware.. Warner From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 17:02:37 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D33764A4 for ; Thu, 21 Feb 2013 17:02:37 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id B5A93733 for ; Thu, 21 Feb 2013 17:02:37 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1LH2bmK094749; Thu, 21 Feb 2013 17:02:37 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id hmijxn2x544a9zf32pd4mse9rw; Thu, 21 Feb 2013 17:02:37 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: MFCard access speed difference between RPi and Beaglebone Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <51263322.3030706@thieprojects.ch> Date: Thu, 21 Feb 2013 09:02:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <337A8E96-9B28-4F98-8131-9E68A57B42E3@kientzle.com> References: <51263322.3030706@thieprojects.ch> To: Werner Thie X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 17:02:37 -0000 On Feb 21, 2013, at 6:45 AM, Werner Thie wrote: > Hi >=20 > trying to nail down the crash and core dump in Python when importing = ctypes I did a parallel build of python on both systems with the same = SVN rev 246947 of kernel. >=20 > The RPi seems to beat the Bbone quite clearly with a ration of 6 : 10 >=20 > It is very apparent (when unpacking for instance) that the Bb shows a = much more pronounced 'hickup' behavior, unpacking 40-60 files and then = most probably doing disk IO. >=20 > Swapping the MFCards does not change the situation at all. >=20 > Can anybody out there suppprt this observation and/or explain it? I've seen the same behavior with things like SVN checkouts; the BBone runs quite smoothly for a while and then stalls. I've been assuming that it was the MMCSD driver; skimming through the code, it looks like there's a lot of room for improvement. Tim From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 17:25:20 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2DE4A279 for ; Thu, 21 Feb 2013 17:25:20 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) by mx1.freebsd.org (Postfix) with ESMTP id E1B938EE for ; Thu, 21 Feb 2013 17:25:19 +0000 (UTC) Received: from [192.168.1.104] (pool-173-77-66-237.nycmny.east.verizon.net [173.77.66.237]) (authenticated bits=0) by feynman.konjz.org (8.14.6/8.14.4) with ESMTP id r1LHP8nt026072 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 21 Feb 2013 12:25:13 -0500 (EST) (envelope-from george@ceetonetechnology.com) Message-ID: <5126586D.3000103@ceetonetechnology.com> Date: Thu, 21 Feb 2013 12:25:01 -0500 From: George Rosamond User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130117 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Raspberry Pi Build Errors Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 5.32 (*****) FH_HOST_EQ_VERIZON_P,RDNS_DYNAMIC X-Spam-Hits: 5320 X-Spam-Names: FH_HOST_EQ_VERIZON_P,RDNS_DYNAMIC X-Spam-Flag: YES X-Mail-Provider: KonjZ X-Scanned-By: MIMEDefang 2.73 on 64.147.119.39 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: george@ceetonetechnology.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 17:25:20 -0000 So just as someone posted on Gonzo's kernelnomicon.org, I'm getting the following error when building Raspberry Pi with both his script and Tim's. -------------------------------------------------------------- >>> World build completed on Tue Feb 19 15:25:47 EST 2013 -------------------------------------------------------------- "/data/gonzo/freebsd-src/sys/boot/Makefile", line 4: Could not find bsd.arch.inc.mk Yes, I have MAKESYSPATH=$SRCROOT/share/mk. I even changed it to the absolute path. bsd.arch.inc.mk is in $SRCROOT/share/mk If I directly run 'make' in sys/boot, I still get "Could not find bsd.arch.inc.mk" Is there something I missed? g From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 17:52:26 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A546DF2F for ; Thu, 21 Feb 2013 17:52:26 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ye0-f180.google.com (mail-ye0-f180.google.com [209.85.213.180]) by mx1.freebsd.org (Postfix) with ESMTP id 6C418B0A for ; Thu, 21 Feb 2013 17:52:26 +0000 (UTC) Received: by mail-ye0-f180.google.com with SMTP id r13so288712yen.11 for ; Thu, 21 Feb 2013 09:52:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=U64TUwLNUY1LXDs9z8VyPUlTIqt9k3rLsb9gSTk4ehY=; b=SmkngM46aGgoj3D0/jmic4daEwpwai8u2/UZLDmTV+VNUjwdhP4mVPeWMla8DsGI6P Qv9YY+Uff0l1awMeOwVlMW37rC+Aw0S3t4x3IEmsOwtwRTMTj7licY8LlbwrUNXJC0Mo IvaftDyBnGyMnNWvyN67ExoGBWCW0cXB3C9BubZ2RmH7FrLXXjc3+pdCjKuybTJcBmr0 lR1CjOkcN0BR6cKcQcGvClpdAgonXDniFK/Cz1nCtW7BNNZFFm1UeZMmcWjxPmmWFQHf WpvmUh2WzZnXeMYznUSLAwpovqkw1yV/0/qVJlGtwPg8zOFc0Sf05NOgOzGEVWOi93cp LZXQ== X-Received: by 10.236.82.65 with SMTP id n41mr45443790yhe.66.1361469140265; Thu, 21 Feb 2013 09:52:20 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id w7sm116439829yhj.0.2013.02.21.09.52.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 09:52:19 -0800 (PST) Sender: Warner Losh Subject: Re: MFCard access speed difference between RPi and Beaglebone Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <337A8E96-9B28-4F98-8131-9E68A57B42E3@kientzle.com> Date: Thu, 21 Feb 2013 10:52:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <071CB345-EA30-4799-B59C-AFA6C1C03F83@bsdimp.com> References: <51263322.3030706@thieprojects.ch> <337A8E96-9B28-4F98-8131-9E68A57B42E3@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnYt1cKf7tbQgW7CZyqwhy9JnGPvGa6LCTFu4ODad6SCdJIib/UWgCfUxasqMNSEtOnR+z7 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 17:52:26 -0000 On Feb 21, 2013, at 10:02 AM, Tim Kientzle wrote: > On Feb 21, 2013, at 6:45 AM, Werner Thie wrote: >=20 >> Hi >>=20 >> trying to nail down the crash and core dump in Python when importing = ctypes I did a parallel build of python on both systems with the same = SVN rev 246947 of kernel. >>=20 >> The RPi seems to beat the Bbone quite clearly with a ration of 6 : 10 >>=20 >> It is very apparent (when unpacking for instance) that the Bb shows a = much more pronounced 'hickup' behavior, unpacking 40-60 files and then = most probably doing disk IO. >>=20 >> Swapping the MFCards does not change the situation at all. >>=20 >> Can anybody out there suppprt this observation and/or explain it? >=20 > I've seen the same behavior with things like SVN checkouts; > the BBone runs quite smoothly for a while and then stalls. >=20 > I've been assuming that it was the MMCSD driver; skimming > through the code, it looks like there's a lot of room for > improvement. I write mmcsd(4) for crappy hardware (the AT91RM9200's mmc controller = was a new low in low performance), so I never got a chance to do much = optimization. I'm sure there's much low-hanging fruit there... Warner From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 17:59:14 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A9E5D303 for ; Thu, 21 Feb 2013 17:59:14 +0000 (UTC) (envelope-from werner@thieprojects.ch) Received: from newton.metanet.ch (newton.metanet.ch [80.74.158.130]) by mx1.freebsd.org (Postfix) with ESMTP id 04392C02 for ; Thu, 21 Feb 2013 17:59:13 +0000 (UTC) Received: (qmail 6284 invoked from network); 21 Feb 2013 18:59:12 +0100 Received: from 217-071-083-008.ip-tech.ch (HELO ?192.168.11.88?) (217.71.83.8) by newton.metanet.ch with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Feb 2013 18:59:12 +0100 Message-ID: <51266071.4040909@thieprojects.ch> Date: Thu, 21 Feb 2013 18:59:13 +0100 From: Werner Thie User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Brett Wynkoop Subject: Re: MFCard access speed difference between RPi and Beaglebone References: <51263322.3030706@thieprojects.ch> <20130221111927.1687e114@ivory.wynn.com> In-Reply-To: <20130221111927.1687e114@ivory.wynn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 17:59:14 -0000 Hi > How long did it take you to build python on each box? At the moment I > can only do ports builds on the Pi because of lack of disk space on the > bone. The Bbone on 5V power supply takes 67min to do make install after a make clean make deinstall (all the deps present) Impressive are the 13min spent in the SHA package check ;-) Cheers, Werner From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 22:02:24 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2CD7EAC6; Thu, 21 Feb 2013 22:02:24 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id A34FDF46; Thu, 21 Feb 2013 22:02:23 +0000 (UTC) Received: from rnote.ddteam.net (216-44-133-95.pool.ukrtel.net [95.133.44.216]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 960CFC4930; Fri, 22 Feb 2013 00:02:21 +0200 (EET) Date: Fri, 22 Feb 2013 00:02:07 +0200 From: Aleksandr Rybalko To: ticso@cicely.de Subject: Re: SPI, _sz fields in struct spi_command Message-Id: <20130222000207.d1478231.ray@freebsd.org> In-Reply-To: <20130221163003.GC12189@cicely7.cicely.de> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> <20130221163003.GC12189@cicely7.cicely.de> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Patrick Kelsey , freebsd-arm@freebsd.org, Bernd Walter , freebsd-mips@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 22:02:24 -0000 On Thu, 21 Feb 2013 17:30:03 +0100 Bernd Walter wrote: > On Thu, Feb 21, 2013 at 10:21:00AM -0500, Patrick Kelsey wrote: > > >On Thu, Feb 21, 2013 at 9:30 AM, Aleksandr Rybalko > > > wrote: > > >> On Thu, 21 Feb 2013 02:44:33 +0100 > > >> Bernd Walter wrote: > > >> > > >> On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr Rybalko > > >> wrote: > > >> > 2. teach consumers to give only correct numbers (very nice we > > >> > have only two SPI devices in tree) > > >> > > > >> > After that we will be able to make drivers for some > > >> > (potential) devices which will require bidirectional > > >> > communication. And controllers which can't do that, will just > > >> > report error in that. I believe peoples thinks before attach > > >> > such devices to controllers, so we will not have such > > >> > incompatibility. > > >> > > >> I don't think there are many devices requiring RX/TX at the same > > >> time. > > > > > > Anyway, we will be able to do that, and we don't care now because > > > don't have such drivers yet. > > > > > > > Taking the view that "RX/TX at the same time" means that one wants > > to send meaningful data to the slave device at the same time one is > > interested in what data is returned during that transmission, there > > are such devices in use out there. Linear Technologies has several > > ADCs, such as the LTC2446, for which you obtain the previous > > conversion result while sending the configuration bits for the next > > conversion to be performed. > > Forgot about ADC with channel selection. > > > Although this is slightly out of focus for the specific issue > > originally raised, while on the topic of things that need to get > > done on SPI in real systems, there are also devices out there that > > require specific data or some number of clocks to be provided while > > chip select is deasserted. One example of the former is the > > LTC2404, which is a multichannel ADC for which the input channel > > for the next conversion is selected by the last four bits clocked > > in *before* chip select is asserted. One example of the latter is > > the spec for SPI access to MMC/SD cards, which requires a certain > > number of clocks to be applied with chip select deasserted in order > > to initialize the card. If you ever find yourself wondering why an > > SPI software interface provides independent bus acquisition and > > chip select control, the reason is to support these types of > > devices. > > With many ADC you also want probing support. > Assign CS and GPIO-read MISO for ready without clocking. > Some flash chips also work this way. > Not sure if AT45DB support this and how our driver works. > With own projects I usually ask AT45DB about ready state by > transfering a status word. > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. Guys, I don't said it will not be supported. :) I said drivers of controllers who can't will return error in that case, but other might be ok. So, conclusion: go-go-go ray! do it please! :-D -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 22:39:50 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2F82CD4F; Thu, 21 Feb 2013 22:39:50 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2319F1DA; Thu, 21 Feb 2013 22:39:48 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1LMdlqr048239; Thu, 21 Feb 2013 15:39:48 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1LMdj1G053497; Thu, 21 Feb 2013 15:39:45 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: SPI, _sz fields in struct spi_command From: Ian Lepore To: Aleksandr Rybalko In-Reply-To: <20130222000207.d1478231.ray@freebsd.org> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> <20130221163003.GC12189@cicely7.cicely.de> <20130222000207.d1478231.ray@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Feb 2013 15:39:45 -0700 Message-ID: <1361486385.1185.38.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, Bernd Walter , ticso@cicely.de, freebsd-mips@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 22:39:50 -0000 On Fri, 2013-02-22 at 00:02 +0200, Aleksandr Rybalko wrote: > On Thu, 21 Feb 2013 17:30:03 +0100 > Bernd Walter wrote: > > > On Thu, Feb 21, 2013 at 10:21:00AM -0500, Patrick Kelsey wrote: > > > >On Thu, Feb 21, 2013 at 9:30 AM, Aleksandr Rybalko > > > > wrote: > > > >> On Thu, 21 Feb 2013 02:44:33 +0100 > > > >> Bernd Walter wrote: > > > >> > > > >> On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr Rybalko > > > >> wrote: > > > >> > 2. teach consumers to give only correct numbers (very nice we > > > >> > have only two SPI devices in tree) > > > >> > > > > >> > After that we will be able to make drivers for some > > > >> > (potential) devices which will require bidirectional > > > >> > communication. And controllers which can't do that, will just > > > >> > report error in that. I believe peoples thinks before attach > > > >> > such devices to controllers, so we will not have such > > > >> > incompatibility. > > > >> > > > >> I don't think there are many devices requiring RX/TX at the same > > > >> time. > > > > > > > > Anyway, we will be able to do that, and we don't care now because > > > > don't have such drivers yet. > > > > > > > > > > Taking the view that "RX/TX at the same time" means that one wants > > > to send meaningful data to the slave device at the same time one is > > > interested in what data is returned during that transmission, there > > > are such devices in use out there. Linear Technologies has several > > > ADCs, such as the LTC2446, for which you obtain the previous > > > conversion result while sending the configuration bits for the next > > > conversion to be performed. > > > > Forgot about ADC with channel selection. > > > > > Although this is slightly out of focus for the specific issue > > > originally raised, while on the topic of things that need to get > > > done on SPI in real systems, there are also devices out there that > > > require specific data or some number of clocks to be provided while > > > chip select is deasserted. One example of the former is the > > > LTC2404, which is a multichannel ADC for which the input channel > > > for the next conversion is selected by the last four bits clocked > > > in *before* chip select is asserted. One example of the latter is > > > the spec for SPI access to MMC/SD cards, which requires a certain > > > number of clocks to be applied with chip select deasserted in order > > > to initialize the card. If you ever find yourself wondering why an > > > SPI software interface provides independent bus acquisition and > > > chip select control, the reason is to support these types of > > > devices. > > > > With many ADC you also want probing support. > > Assign CS and GPIO-read MISO for ready without clocking. > > Some flash chips also work this way. > > Not sure if AT45DB support this and how our driver works. > > With own projects I usually ask AT45DB about ready state by > > transfering a status word. > > > > -- > > B.Walter http://www.bwct.de > > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > > Guys, I don't said it will not be supported. :) > I said drivers of controllers who can't will return error in that case, > but other might be ok. > > So, conclusion: go-go-go ray! do it please! > :-D > One other little thought to consider... since tx and rx size must be the same if they're both non-zero, then could we change to having a single io_size field, and pass a NULL pointer for rx or tx buffer if that part of the transfer isn't needed? -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 22:59:41 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E1D5D719; Thu, 21 Feb 2013 22:59:41 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 324D22E6; Thu, 21 Feb 2013 22:59:40 +0000 (UTC) Received: from rnote.ddteam.net (216-44-133-95.pool.ukrtel.net [95.133.44.216]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id CC5C0C493C; Fri, 22 Feb 2013 00:59:39 +0200 (EET) Date: Fri, 22 Feb 2013 00:59:26 +0200 From: Aleksandr Rybalko To: Ian Lepore Subject: Re: SPI, _sz fields in struct spi_command Message-Id: <20130222005926.2aa6db7f.ray@freebsd.org> In-Reply-To: <1361486385.1185.38.camel@revolution.hippie.lan> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> <20130221163003.GC12189@cicely7.cicely.de> <20130222000207.d1478231.ray@freebsd.org> <1361486385.1185.38.camel@revolution.hippie.lan> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Aleksandr Rybalko , Bernd Walter , freebsd-arm@FreeBSD.org, ticso@cicely.de, freebsd-mips@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 22:59:42 -0000 On Thu, 21 Feb 2013 15:39:45 -0700 Ian Lepore wrote: > On Fri, 2013-02-22 at 00:02 +0200, Aleksandr Rybalko wrote: > > On Thu, 21 Feb 2013 17:30:03 +0100 > > Bernd Walter wrote: > > > > > On Thu, Feb 21, 2013 at 10:21:00AM -0500, Patrick Kelsey wrote: > > > > >On Thu, Feb 21, 2013 at 9:30 AM, Aleksandr Rybalko > > > > > wrote: > > > > >> On Thu, 21 Feb 2013 02:44:33 +0100 > > > > >> Bernd Walter wrote: > > > > >> > > > > >> On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr Rybalko > > > > >> wrote: > > > > >> > 2. teach consumers to give only correct numbers (very nice > > > > >> > we have only two SPI devices in tree) > > > > >> > > > > > >> > After that we will be able to make drivers for some > > > > >> > (potential) devices which will require bidirectional > > > > >> > communication. And controllers which can't do that, will > > > > >> > just report error in that. I believe peoples thinks before > > > > >> > attach such devices to controllers, so we will not have > > > > >> > such incompatibility. > > > > >> > > > > >> I don't think there are many devices requiring RX/TX at the > > > > >> same time. > > > > > > > > > > Anyway, we will be able to do that, and we don't care now > > > > > because don't have such drivers yet. > > > > > > > > > > > > > Taking the view that "RX/TX at the same time" means that one > > > > wants to send meaningful data to the slave device at the same > > > > time one is interested in what data is returned during that > > > > transmission, there are such devices in use out there. Linear > > > > Technologies has several ADCs, such as the LTC2446, for which > > > > you obtain the previous conversion result while sending the > > > > configuration bits for the next conversion to be performed. > > > > > > Forgot about ADC with channel selection. > > > > > > > Although this is slightly out of focus for the specific issue > > > > originally raised, while on the topic of things that need to get > > > > done on SPI in real systems, there are also devices out there > > > > that require specific data or some number of clocks to be > > > > provided while chip select is deasserted. One example of the > > > > former is the LTC2404, which is a multichannel ADC for which > > > > the input channel for the next conversion is selected by the > > > > last four bits clocked in *before* chip select is asserted. > > > > One example of the latter is the spec for SPI access to MMC/SD > > > > cards, which requires a certain number of clocks to be applied > > > > with chip select deasserted in order to initialize the card. > > > > If you ever find yourself wondering why an SPI software > > > > interface provides independent bus acquisition and chip select > > > > control, the reason is to support these types of devices. > > > > > > With many ADC you also want probing support. > > > Assign CS and GPIO-read MISO for ready without clocking. > > > Some flash chips also work this way. > > > Not sure if AT45DB support this and how our driver works. > > > With own projects I usually ask AT45DB about ready state by > > > transfering a status word. > > > > > > -- > > > B.Walter http://www.bwct.de > > > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner > > > uvm. > > > > Guys, I don't said it will not be supported. :) > > I said drivers of controllers who can't will return error in that > > case, but other might be ok. > > > > So, conclusion: go-go-go ray! do it please! > > :-D > > > > One other little thought to consider... since tx and rx size must be > the same if they're both non-zero, then could we change to having a > single io_size field, and pass a NULL pointer for rx or tx buffer if > that part of the transfer isn't needed? > > -- Ian > > Yeah, very-very good idea! That how my uncommited driver for i.MX515 SPI works :) Objections? WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 23:02:59 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 75FA798D for ; Thu, 21 Feb 2013 23:02:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 36DD332A for ; Thu, 21 Feb 2013 23:02:59 +0000 (UTC) Received: by mail-yh0-f46.google.com with SMTP id q15so12919yhf.19 for ; Thu, 21 Feb 2013 15:02:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=18hoJwfk6xsq6duaD+G5D0Ouaw0gSr3f7iGliAf0gl4=; b=RhWsBrIrUJpe57u+tO+UqUE12TbChKHgVzMRfm1Ovbl1ErU6eODPcNWaLwszT8fn5R AtghmLYk8rb9uPbneBDmpT9k/bom5ADtRfAsUmyuDgBFEvAAgoXouWqZbfs/L/2M5ZRh mu9qDf9KD8i5kv4Ce5YnMuVc9vQV/MP67zQIaiWxINnNBQGvOEa/MK4r3CRWhpuvapVo fH91QIuMpLTBKfO5wdF3XhZ+XGbNgdq75YpAb9Vt3MKbx2u3YNjlUM/wb2rRTXkAVHuU UB1KqfPPOEgI0TIQSfBDWS2piK3UR0UV2SfHHfPAD6xfvIwOOgcXw7zgWZ73Q3BklSbN werw== X-Received: by 10.236.139.113 with SMTP id b77mr48035628yhj.130.1361487778466; Thu, 21 Feb 2013 15:02:58 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id f20sm288851ang.10.2013.02.21.15.02.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 15:02:57 -0800 (PST) Sender: Warner Losh Subject: Re: SPI, _sz fields in struct spi_command Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130222005926.2aa6db7f.ray@freebsd.org> Date: Thu, 21 Feb 2013 16:02:54 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> <20130221163003.GC12189@cicely7.cicely.de> <20130222000207.d1478231.ray@freebsd.org> <1361486385.1185.38.camel@revolution.hippie.lan> <20130222005926.2aa6db7f.ray@freebsd.org> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlC7wE2+rBJ7Zy1Fj55GnlJhoEncBqKFGZL7FeEgeIcsYCm9Aek7PO53L18qcN+SPipyKn7 Cc: freebsd-arm@FreeBSD.org, Bernd Walter , ticso@cicely.de, Ian Lepore , freebsd-mips@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 23:02:59 -0000 On Feb 21, 2013, at 3:59 PM, Aleksandr Rybalko wrote: > On Thu, 21 Feb 2013 15:39:45 -0700 > Ian Lepore wrote: > >> On Fri, 2013-02-22 at 00:02 +0200, Aleksandr Rybalko wrote: >>> On Thu, 21 Feb 2013 17:30:03 +0100 >>> Bernd Walter wrote: >>> >>>> On Thu, Feb 21, 2013 at 10:21:00AM -0500, Patrick Kelsey wrote: >>>>>> On Thu, Feb 21, 2013 at 9:30 AM, Aleksandr Rybalko >>>>>> wrote: >>>>>>> On Thu, 21 Feb 2013 02:44:33 +0100 >>>>>>> Bernd Walter wrote: >>>>>>> >>>>>>> On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr Rybalko >>>>>>> wrote: >>>>>>>> 2. teach consumers to give only correct numbers (very nice >>>>>>>> we have only two SPI devices in tree) >>>>>>>> >>>>>>>> After that we will be able to make drivers for some >>>>>>>> (potential) devices which will require bidirectional >>>>>>>> communication. And controllers which can't do that, will >>>>>>>> just report error in that. I believe peoples thinks before >>>>>>>> attach such devices to controllers, so we will not have >>>>>>>> such incompatibility. >>>>>>> >>>>>>> I don't think there are many devices requiring RX/TX at the >>>>>>> same time. >>>>>> >>>>>> Anyway, we will be able to do that, and we don't care now >>>>>> because don't have such drivers yet. >>>>>> >>>>> >>>>> Taking the view that "RX/TX at the same time" means that one >>>>> wants to send meaningful data to the slave device at the same >>>>> time one is interested in what data is returned during that >>>>> transmission, there are such devices in use out there. Linear >>>>> Technologies has several ADCs, such as the LTC2446, for which >>>>> you obtain the previous conversion result while sending the >>>>> configuration bits for the next conversion to be performed. >>>> >>>> Forgot about ADC with channel selection. >>>> >>>>> Although this is slightly out of focus for the specific issue >>>>> originally raised, while on the topic of things that need to get >>>>> done on SPI in real systems, there are also devices out there >>>>> that require specific data or some number of clocks to be >>>>> provided while chip select is deasserted. One example of the >>>>> former is the LTC2404, which is a multichannel ADC for which >>>>> the input channel for the next conversion is selected by the >>>>> last four bits clocked in *before* chip select is asserted. >>>>> One example of the latter is the spec for SPI access to MMC/SD >>>>> cards, which requires a certain number of clocks to be applied >>>>> with chip select deasserted in order to initialize the card. >>>>> If you ever find yourself wondering why an SPI software >>>>> interface provides independent bus acquisition and chip select >>>>> control, the reason is to support these types of devices. >>>> >>>> With many ADC you also want probing support. >>>> Assign CS and GPIO-read MISO for ready without clocking. >>>> Some flash chips also work this way. >>>> Not sure if AT45DB support this and how our driver works. >>>> With own projects I usually ask AT45DB about ready state by >>>> transfering a status word. >>>> >>>> -- >>>> B.Walter http://www.bwct.de >>>> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner >>>> uvm. >>> >>> Guys, I don't said it will not be supported. :) >>> I said drivers of controllers who can't will return error in that >>> case, but other might be ok. >>> >>> So, conclusion: go-go-go ray! do it please! >>> :-D >>> >> >> One other little thought to consider... since tx and rx size must be >> the same if they're both non-zero, then could we change to having a >> single io_size field, and pass a NULL pointer for rx or tx buffer if >> that part of the transfer isn't needed? >> >> -- Ian >> >> > > Yeah, very-very good idea! That how my uncommited driver for i.MX515 > SPI works :) > > Objections? I'm cool with that. Warner From owner-freebsd-arm@FreeBSD.ORG Thu Feb 21 23:17:59 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3D88EBFC; Thu, 21 Feb 2013 23:17:59 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id DC38B3D5; Thu, 21 Feb 2013 23:17:58 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1LNHvBd048729; Thu, 21 Feb 2013 16:17:58 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1LNHtwl053569; Thu, 21 Feb 2013 16:17:55 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: SPI, _sz fields in struct spi_command From: Ian Lepore To: Aleksandr Rybalko In-Reply-To: <20130222005926.2aa6db7f.ray@freebsd.org> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> <20130221163003.GC12189@cicely7.cicely.de> <20130222000207.d1478231.ray@freebsd.org> <1361486385.1185.38.camel@revolution.hippie.lan> <20130222005926.2aa6db7f.ray@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Feb 2013 16:17:55 -0700 Message-ID: <1361488675.1185.42.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, Bernd Walter , ticso@cicely.de, freebsd-mips@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 23:17:59 -0000 On Fri, 2013-02-22 at 00:59 +0200, Aleksandr Rybalko wrote: > On Thu, 21 Feb 2013 15:39:45 -0700 > Ian Lepore wrote: > > > On Fri, 2013-02-22 at 00:02 +0200, Aleksandr Rybalko wrote: > > > On Thu, 21 Feb 2013 17:30:03 +0100 > > > Bernd Walter wrote: > > > > > > > On Thu, Feb 21, 2013 at 10:21:00AM -0500, Patrick Kelsey wrote: > > > > > >On Thu, Feb 21, 2013 at 9:30 AM, Aleksandr Rybalko > > > > > > wrote: > > > > > >> On Thu, 21 Feb 2013 02:44:33 +0100 > > > > > >> Bernd Walter wrote: > > > > > >> > > > > > >> On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr Rybalko > > > > > >> wrote: > > > > > >> > 2. teach consumers to give only correct numbers (very nice > > > > > >> > we have only two SPI devices in tree) > > > > > >> > > > > > > >> > After that we will be able to make drivers for some > > > > > >> > (potential) devices which will require bidirectional > > > > > >> > communication. And controllers which can't do that, will > > > > > >> > just report error in that. I believe peoples thinks before > > > > > >> > attach such devices to controllers, so we will not have > > > > > >> > such incompatibility. > > > > > >> > > > > > >> I don't think there are many devices requiring RX/TX at the > > > > > >> same time. > > > > > > > > > > > > Anyway, we will be able to do that, and we don't care now > > > > > > because don't have such drivers yet. > > > > > > > > > > > > > > > > Taking the view that "RX/TX at the same time" means that one > > > > > wants to send meaningful data to the slave device at the same > > > > > time one is interested in what data is returned during that > > > > > transmission, there are such devices in use out there. Linear > > > > > Technologies has several ADCs, such as the LTC2446, for which > > > > > you obtain the previous conversion result while sending the > > > > > configuration bits for the next conversion to be performed. > > > > > > > > Forgot about ADC with channel selection. > > > > > > > > > Although this is slightly out of focus for the specific issue > > > > > originally raised, while on the topic of things that need to get > > > > > done on SPI in real systems, there are also devices out there > > > > > that require specific data or some number of clocks to be > > > > > provided while chip select is deasserted. One example of the > > > > > former is the LTC2404, which is a multichannel ADC for which > > > > > the input channel for the next conversion is selected by the > > > > > last four bits clocked in *before* chip select is asserted. > > > > > One example of the latter is the spec for SPI access to MMC/SD > > > > > cards, which requires a certain number of clocks to be applied > > > > > with chip select deasserted in order to initialize the card. > > > > > If you ever find yourself wondering why an SPI software > > > > > interface provides independent bus acquisition and chip select > > > > > control, the reason is to support these types of devices. > > > > > > > > With many ADC you also want probing support. > > > > Assign CS and GPIO-read MISO for ready without clocking. > > > > Some flash chips also work this way. > > > > Not sure if AT45DB support this and how our driver works. > > > > With own projects I usually ask AT45DB about ready state by > > > > transfering a status word. > > > > > > > > -- > > > > B.Walter http://www.bwct.de > > > > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner > > > > uvm. > > > > > > Guys, I don't said it will not be supported. :) > > > I said drivers of controllers who can't will return error in that > > > case, but other might be ok. > > > > > > So, conclusion: go-go-go ray! do it please! > > > :-D > > > > > > > One other little thought to consider... since tx and rx size must be > > the same if they're both non-zero, then could we change to having a > > single io_size field, and pass a NULL pointer for rx or tx buffer if > > that part of the transfer isn't needed? > > > > -- Ian > > > > > > Yeah, very-very good idea! That how my uncommited driver for i.MX515 > SPI works :) > > Objections? > > WBW So just to be clear... if a device driver passes a NULL tx pointer to the controller driver, it's saying "My device doesn't care what it receives during this transfer." If the device needs zeroes or ones then the buffer full of them has to be provided, right? I'm thinking for the controller that does dma, this simplifies things down to making a bus_dmamem_alloc() call (which is fast these days because of the zone allocator) and it doesn't bother to set the contents of that buffer to anything before starting the dma. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 00:05:34 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 645769D6; Fri, 22 Feb 2013 00:05:34 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id C311280A; Fri, 22 Feb 2013 00:05:33 +0000 (UTC) Received: from rnote.ddteam.net (216-44-133-95.pool.ukrtel.net [95.133.44.216]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 352CEC493D; Fri, 22 Feb 2013 02:05:31 +0200 (EET) Date: Fri, 22 Feb 2013 02:05:17 +0200 From: Aleksandr Rybalko To: Ian Lepore Subject: Re: SPI, _sz fields in struct spi_command Message-Id: <20130222020517.f0bd9987.ray@freebsd.org> In-Reply-To: <1361488675.1185.42.camel@revolution.hippie.lan> References: <20130220142140.f8e5a616c75d72e2519dbc69@freebsd.org> <54C08D8E-4C5F-49AF-BEE6-D78EC05D2A24@bsdimp.com> <20130220174449.GB6976@cicely7.cicely.de> <20130221022655.6f693eb6.ray@freebsd.org> <20130221014433.GA12189@cicely7.cicely.de> <20130221163026.dbeb03f9c38de3d24a7ab30f@freebsd.org> <20130221163003.GC12189@cicely7.cicely.de> <20130222000207.d1478231.ray@freebsd.org> <1361486385.1185.38.camel@revolution.hippie.lan> <20130222005926.2aa6db7f.ray@freebsd.org> <1361488675.1185.42.camel@revolution.hippie.lan> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Aleksandr Rybalko , Bernd Walter , freebsd-arm@FreeBSD.org, freebsd-mips@FreeBSD.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 00:05:34 -0000 On Thu, 21 Feb 2013 16:17:55 -0700 Ian Lepore wrote: > On Fri, 2013-02-22 at 00:59 +0200, Aleksandr Rybalko wrote: > > On Thu, 21 Feb 2013 15:39:45 -0700 > > Ian Lepore wrote: > > > > > On Fri, 2013-02-22 at 00:02 +0200, Aleksandr Rybalko wrote: > > > > On Thu, 21 Feb 2013 17:30:03 +0100 > > > > Bernd Walter wrote: > > > > > > > > > On Thu, Feb 21, 2013 at 10:21:00AM -0500, Patrick Kelsey > > > > > wrote: > > > > > > >On Thu, Feb 21, 2013 at 9:30 AM, Aleksandr Rybalko > > > > > > > wrote: > > > > > > >> On Thu, 21 Feb 2013 02:44:33 +0100 > > > > > > >> Bernd Walter wrote: > > > > > > >> > > > > > > >> On Thu, Feb 21, 2013 at 02:26:55AM +0200, Aleksandr > > > > > > >> Rybalko wrote: > > > > > > >> > 2. teach consumers to give only correct numbers (very > > > > > > >> > nice we have only two SPI devices in tree) > > > > > > >> > > > > > > > >> > After that we will be able to make drivers for some > > > > > > >> > (potential) devices which will require bidirectional > > > > > > >> > communication. And controllers which can't do that, > > > > > > >> > will just report error in that. I believe peoples > > > > > > >> > thinks before attach such devices to controllers, so > > > > > > >> > we will not have such incompatibility. > > > > > > >> > > > > > > >> I don't think there are many devices requiring RX/TX at > > > > > > >> the same time. > > > > > > > > > > > > > > Anyway, we will be able to do that, and we don't care now > > > > > > > because don't have such drivers yet. > > > > > > > > > > > > > > > > > > > Taking the view that "RX/TX at the same time" means that one > > > > > > wants to send meaningful data to the slave device at the > > > > > > same time one is interested in what data is returned during > > > > > > that transmission, there are such devices in use out > > > > > > there. Linear Technologies has several ADCs, such as the > > > > > > LTC2446, for which you obtain the previous conversion > > > > > > result while sending the configuration bits for the next > > > > > > conversion to be performed. > > > > > > > > > > Forgot about ADC with channel selection. > > > > > > > > > > > Although this is slightly out of focus for the specific > > > > > > issue originally raised, while on the topic of things that > > > > > > need to get done on SPI in real systems, there are also > > > > > > devices out there that require specific data or some number > > > > > > of clocks to be provided while chip select is deasserted. > > > > > > One example of the former is the LTC2404, which is a > > > > > > multichannel ADC for which the input channel for the next > > > > > > conversion is selected by the last four bits clocked in > > > > > > *before* chip select is asserted. One example of the latter > > > > > > is the spec for SPI access to MMC/SD cards, which requires > > > > > > a certain number of clocks to be applied with chip select > > > > > > deasserted in order to initialize the card. If you ever > > > > > > find yourself wondering why an SPI software interface > > > > > > provides independent bus acquisition and chip select > > > > > > control, the reason is to support these types of devices. > > > > > > > > > > With many ADC you also want probing support. > > > > > Assign CS and GPIO-read MISO for ready without clocking. > > > > > Some flash chips also work this way. > > > > > Not sure if AT45DB support this and how our driver works. > > > > > With own projects I usually ask AT45DB about ready state by > > > > > transfering a status word. > > > > > > > > > > -- > > > > > B.Walter http://www.bwct.de > > > > > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD > > > > > Rechner uvm. > > > > > > > > Guys, I don't said it will not be supported. :) > > > > I said drivers of controllers who can't will return error in > > > > that case, but other might be ok. > > > > > > > > So, conclusion: go-go-go ray! do it please! > > > > :-D > > > > > > > > > > One other little thought to consider... since tx and rx size must > > > be the same if they're both non-zero, then could we change to > > > having a single io_size field, and pass a NULL pointer for rx or > > > tx buffer if that part of the transfer isn't needed? > > > > > > -- Ian > > > > > > > > > > Yeah, very-very good idea! That how my uncommited driver for i.MX515 > > SPI works :) > > > > Objections? > > > > WBW > > So just to be clear... if a device driver passes a NULL tx pointer to > the controller driver, it's saying "My device doesn't care what it > receives during this transfer." If the device needs zeroes or ones > then the buffer full of them has to be provided, right? One letter will change whole world :-D You said: if (tx == NULL) { drain_rx_to_dev_null(); } cmd_sz - how much to transfer; cmd_tx - TX buffer pointer, or NULL (NULL mean "transmit anything you like or use /etc/master.passwd for that " :) ) cmd_rx - RX buffer pointer, or NULL (NULL mean "I will not read that sucks after transfer, read it if you want" ) Same with data_sz, data_tx, data_rx. > > I'm thinking for the controller that does dma, this simplifies things > down to making a bus_dmamem_alloc() call (which is fast these days > because of the zone allocator) and it doesn't bother to set the > contents of that buffer to anything before starting the dma. Think it will be ok if we alloc one page on start (for those who need it) and then realloc to bigger block if somebody request. > > -- Ian > > Thanks Ian! Thanks Warner! WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 05:50:51 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 276BE4B4 for ; Fri, 22 Feb 2013 05:50:51 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by mx1.freebsd.org (Postfix) with ESMTP id DD15486C for ; Fri, 22 Feb 2013 05:50:50 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id cr7so227198qab.3 for ; Thu, 21 Feb 2013 21:50:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=zR1bgyDaz+IBjpVWklt7bLNmPfqVgKnuZYoaidXqyW4=; b=MG3B5zIabCZUMGYq1sLSnF4jDJIx/0F9XeJZRacminGwBNpNkQ4Jef37C1rp5lrTM4 L96Zppb6iaQFsW7tB+whgI/fAcjyolPAxAylSJ/yK1ywUsQRX+xBfxZ0ZVVVa0u8Eya5 /jJD9xFg8/UZbyI2FdFPQ84JBGIcanUGF/qp3w4B6dZpwQGflP2jwKHibi/L2+kN8g90 mxMXNTWCYu++2JxRXLGVgXrXaUH8LjylNRtdIg0ypNQS8ffAw+1/L3JQYAyu78iS+8jr lq/SlqB9ITAdfIwoNMljS/mUD7TAZeseBpWBLW9R050BTzvz6USkSRujr6NeZAX9o4XC GyTw== MIME-Version: 1.0 X-Received: by 10.224.33.208 with SMTP id i16mr601362qad.45.1361512243828; Thu, 21 Feb 2013 21:50:43 -0800 (PST) Received: by 10.49.51.138 with HTTP; Thu, 21 Feb 2013 21:50:43 -0800 (PST) Date: Fri, 22 Feb 2013 13:50:43 +0800 Message-ID: Subject: Unable to copy DTB into module directory From: Alie Tan To: "freebsd-arm@freebsd.org" X-Gm-Message-State: ALoCoQnxhXEPESND/sgfohHi+rZx8zjVpe64ISnoaTDcieFLlT3/IvFaUkzYTDQR/a//3N1STZot Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 05:50:51 -0000 Hi, I just built RasPi image and keeps getting this message: "unable to copy DTB into module directory" then the raspi reboot again and again. From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 06:07:19 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6AEB4625 for ; Fri, 22 Feb 2013 06:07:19 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 31A658CC for ; Fri, 22 Feb 2013 06:07:18 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1M67Gcp099987; Fri, 22 Feb 2013 06:07:16 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id juw6am628tptgjne2epasxht3a; Fri, 22 Feb 2013 06:07:16 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Unable to copy DTB into module directory Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Thu, 21 Feb 2013 22:07:14 -0800 Content-Transfer-Encoding: 7bit Message-Id: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> References: To: Alie Tan X-Mailer: Apple Mail (2.1283) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 06:07:19 -0000 On Feb 21, 2013, at 9:50 PM, Alie Tan wrote: > > I just built RasPi image and keeps getting this message: > > "unable to copy DTB into module directory" > > then the raspi reboot again and again. Try backing out r247045 and see if that fixes it for you. Also try breaking into the U-Boot prompt and entering U-Boot> fdt addr 0x100 there and let me know if that makes a difference. I fear my most recent changes to support FDT cleanly on BeagleBone may have broken ubldr on RaspberryPi. It will be a couple of days before I can make any progress on this. Tim From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 06:17:36 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7669A782 for ; Fri, 22 Feb 2013 06:17:36 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 530D9914 for ; Fri, 22 Feb 2013 06:17:35 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1M6HYTo000125; Fri, 22 Feb 2013 06:17:34 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id pvakrjutbrbvhd2csp8gafv8cs; Fri, 22 Feb 2013 06:17:34 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Unable to copy DTB into module directory Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> Date: Thu, 21 Feb 2013 22:17:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> To: Alie Tan X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 06:17:36 -0000 On Feb 21, 2013, at 10:07 PM, Tim Kientzle wrote: > On Feb 21, 2013, at 9:50 PM, Alie Tan wrote: >>=20 >> I just built RasPi image and keeps getting this message: >>=20 >> "unable to copy DTB into module directory" >>=20 >> then the raspi reboot again and again. >=20 > Try backing out r247045 and see if that fixes > it for you. >=20 > Also try breaking into the U-Boot prompt > and entering Sorry, left out some steps here. (To clarify, this is a separate experiment to be done with an image that includes r247045). The instructions should say: 1) Remove the "fdt addr 0x100" command from loader.rc 2) Early in boot, break to the U-Boot prompt (hit any key during the = 3-second countdown) 3) Enter these two commands to U-Boot U-Boot> fdt addr 0x100 U-Boot> run bootcmd This way, U-Boot will identify the FDT and ubldr will get it from U-Boot (instead of ubldr accessing it directly). Tim From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 06:47:56 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0DDAAEBC for ; Fri, 22 Feb 2013 06:47:56 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by mx1.freebsd.org (Postfix) with ESMTP id C4C949FE for ; Fri, 22 Feb 2013 06:47:55 +0000 (UTC) Received: by mail-qe0-f43.google.com with SMTP id s14so174903qeb.16 for ; Thu, 21 Feb 2013 22:47:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=JX6h+PgaTGBQhGiVF+c7OLH5b84m1zEi49XGCMun0Ys=; b=gruZLkvLw3tPKrSprd9GamhxhDqSbBs3pbvEOc9OY7GEo0b+2a7ysGrSTBgWEinVPc YAMLFVy+9zPqxG+k9yWZtJDCkggVscsHFPIaBGuYi2AKGDcoCnjelrVYDvY62YAMAr4k e50aQb8XNFqTIrMmPU739J1/SwJAgBBt2TuwpxHXsrwzW81x1PGU3EDpRe1WjoCmZBR7 3zToQl4HJzGkS76bNetNjAhRr3LWVDG0n6QPlDDIiFRykCP4RBWYIn8+4TRCaWlmRkFu ivWNTkgL5POSnC4otudFdirPM57/eeKciXqmrzUnb9sXdRSDcBrS/1/WErjfx308qx4a OMJQ== MIME-Version: 1.0 X-Received: by 10.229.174.196 with SMTP id u4mr76483qcz.84.1361515668971; Thu, 21 Feb 2013 22:47:48 -0800 (PST) Received: by 10.49.51.138 with HTTP; Thu, 21 Feb 2013 22:47:48 -0800 (PST) In-Reply-To: References: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> Date: Fri, 22 Feb 2013 14:47:48 +0800 Message-ID: Subject: Re: Unable to copy DTB into module directory From: Alie Tan To: Tim Kientzle X-Gm-Message-State: ALoCoQmz8juvsOgqiE5/QrO6r8JErS1tXAMTAf3EpJX935hXxOJqr/IBQdehpbMhPKEkfsAdTu2Q Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 06:47:56 -0000 On Fri, Feb 22, 2013 at 2:17 PM, Tim Kientzle wrote: > > On Feb 21, 2013, at 10:07 PM, Tim Kientzle wrote: > > > On Feb 21, 2013, at 9:50 PM, Alie Tan wrote: > >> > >> I just built RasPi image and keeps getting this message: > >> > >> "unable to copy DTB into module directory" > >> > >> then the raspi reboot again and again. > > > > Try backing out r247045 and see if that fixes > > it for you. > > > > Also try breaking into the U-Boot prompt > > and entering > > Sorry, left out some steps here. (To clarify, this is a separate > experiment to be done with an image that includes > r247045). The instructions should say: > > 1) Remove the "fdt addr 0x100" command from loader.rc > > 2) Early in boot, break to the U-Boot prompt (hit any key during the > 3-second countdown) > I can't even hit any key on my keyboard. What to do now? > > 3) Enter these two commands to U-Boot > > U-Boot> fdt addr 0x100 > U-Boot> run bootcmd > > This way, U-Boot will identify the FDT and ubldr will > get it from U-Boot (instead of ubldr accessing it > directly). > > Tim > > From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 06:57:20 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 791C1BF for ; Fri, 22 Feb 2013 06:57:20 +0000 (UTC) (envelope-from werner@thieprojects.ch) Received: from newton.metanet.ch (newton.metanet.ch [80.74.158.130]) by mx1.freebsd.org (Postfix) with ESMTP id A6915A40 for ; Fri, 22 Feb 2013 06:57:19 +0000 (UTC) Received: (qmail 21559 invoked from network); 22 Feb 2013 07:57:16 +0100 Received: from 217-071-083-008.ip-tech.ch (HELO ?192.168.11.88?) (217.71.83.8) by newton.metanet.ch with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Feb 2013 07:57:16 +0100 Message-ID: <512716CE.7050600@thieprojects.ch> Date: Fri, 22 Feb 2013 07:57:18 +0100 From: Werner Thie User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Alie Tan Subject: Re: Unable to copy DTB into module directory References: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 06:57:20 -0000 On 2/22/13 7:47 AM, Alie Tan wrote: > On Fri, Feb 22, 2013 at 2:17 PM, Tim Kientzle wrote: > >> >> On Feb 21, 2013, at 10:07 PM, Tim Kientzle wrote: >> >>> On Feb 21, 2013, at 9:50 PM, Alie Tan wrote: >>>> >>>> I just built RasPi image and keeps getting this message: >>>> >>>> "unable to copy DTB into module directory" >>>> >>>> then the raspi reboot again and again. >>> >>> Try backing out r247045 and see if that fixes >>> it for you. >>> >>> Also try breaking into the U-Boot prompt >>> and entering >> >> Sorry, left out some steps here. (To clarify, this is a separate >> experiment to be done with an image that includes >> r247045). The instructions should say: >> >> 1) Remove the "fdt addr 0x100" command from loader.rc >> >> 2) Early in boot, break to the U-Boot prompt (hit any key during the >> 3-second countdown) >> > I can't even hit any key on my keyboard. What to do now? Are you on USB/serial console? 256MB RPi? No reset button? If so, it's very tricky to bring cu up and sneak in a keystroke (not ENTER though) Fiddling with the power and cu usually takes a few attempts for me Werner From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 07:07:37 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1E15031A for ; Fri, 22 Feb 2013 07:07:37 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by mx1.freebsd.org (Postfix) with ESMTP id D6ABAAA2 for ; Fri, 22 Feb 2013 07:07:36 +0000 (UTC) Received: by mail-qe0-f42.google.com with SMTP id 2so183703qeb.1 for ; Thu, 21 Feb 2013 23:07:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=IjN+aoiTohZs2QtUH8Pkx83lQ0xxGl/lUX5cIOy3x50=; b=K4UePdhpSddZsiSkmyjuzviGtJBJPYhfcePJelzXcoHuzq/mEo0WbeLiG8uJxxJYHk cgB+IFUNdkKR+QtLneUi2WRcFfCt5hiI+HLsCj4PN9azcGEIcatEJ4DoLgbbTMFqyGoi KU/11DVfMydQfFiNSmlYqPMvgAOlEBQJeUz9qgHenfig724GAiZ4Ipvg9h4wdioOWOhg vYyrPlItZMhiQZcdPxGOTKyKAn1SyiBwEu2wcS1zR/fOQ6O1K4bfwZF5PthPV/8oNtDY UU/vuD3HIQ3ftRpKSLj0Ynb7vxLqmStfLhqRf95fbl2braebl3Q5YfczAy6ygPPeZTdK a2OA== MIME-Version: 1.0 X-Received: by 10.224.17.68 with SMTP id r4mr664604qaa.20.1361516850560; Thu, 21 Feb 2013 23:07:30 -0800 (PST) Received: by 10.49.51.138 with HTTP; Thu, 21 Feb 2013 23:07:30 -0800 (PST) In-Reply-To: <512716CE.7050600@thieprojects.ch> References: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> <512716CE.7050600@thieprojects.ch> Date: Fri, 22 Feb 2013 15:07:30 +0800 Message-ID: Subject: Re: Unable to copy DTB into module directory From: Alie Tan To: Werner Thie X-Gm-Message-State: ALoCoQnPfGk9tFDkabwR/lD8Z+5Si/lidYAiEVXhPbdc0tl5E/dRhQVXOT+1e8Ysv5Zlr8OMOU1Y Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Tim Kientzle , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 07:07:37 -0000 On Fri, Feb 22, 2013 at 2:57 PM, Werner Thie wrote: > On 2/22/13 7:47 AM, Alie Tan wrote: > >> On Fri, Feb 22, 2013 at 2:17 PM, Tim Kientzle wrote: >> >> >>> On Feb 21, 2013, at 10:07 PM, Tim Kientzle wrote: >>> >>> On Feb 21, 2013, at 9:50 PM, Alie Tan wrote: >>>> >>>>> >>>>> I just built RasPi image and keeps getting this message: >>>>> >>>>> "unable to copy DTB into module directory" >>>>> >>>>> then the raspi reboot again and again. >>>>> >>>> >>>> Try backing out r247045 and see if that fixes >>>> it for you. >>>> >>>> Also try breaking into the U-Boot prompt >>>> and entering >>>> >>> >>> Sorry, left out some steps here. (To clarify, this is a separate >>> experiment to be done with an image that includes >>> r247045). The instructions should say: >>> >>> 1) Remove the "fdt addr 0x100" command from loader.rc >>> >>> 2) Early in boot, break to the U-Boot prompt (hit any key during the >>> 3-second countdown) >>> >>> I can't even hit any key on my keyboard. What to do now? >> > > Are you on USB/serial console? 256MB RPi? No reset button? > I am on video console connected to HDMI, 512MB RPI > If so, it's very tricky to bring cu up and sneak in a keystroke (not ENTER > though) > > Fiddling with the power and cu usually takes a few attempts for me > > Werner > > From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 07:13:48 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 064213B9 for ; Fri, 22 Feb 2013 07:13:48 +0000 (UTC) (envelope-from werner@thieprojects.ch) Received: from newton.metanet.ch (newton.metanet.ch [80.74.158.130]) by mx1.freebsd.org (Postfix) with ESMTP id 6A319ADD for ; Fri, 22 Feb 2013 07:13:47 +0000 (UTC) Received: (qmail 29714 invoked from network); 22 Feb 2013 08:13:45 +0100 Received: from 217-071-083-008.ip-tech.ch (HELO ?192.168.11.88?) (217.71.83.8) by newton.metanet.ch with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Feb 2013 08:13:45 +0100 Message-ID: <51271AAB.4080005@thieprojects.ch> Date: Fri, 22 Feb 2013 08:13:47 +0100 From: Werner Thie User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Alie Tan Subject: Re: Unable to copy DTB into module directory References: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> <512716CE.7050600@thieprojects.ch> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 07:13:48 -0000 On 2/22/13 8:07 AM, Alie Tan wrote: > > On Fri, Feb 22, 2013 at 2:57 PM, Werner Thie > wrote: > > On 2/22/13 7:47 AM, Alie Tan wrote: > > On Fri, Feb 22, 2013 at 2:17 PM, Tim Kientzle > wrote: > > > On Feb 21, 2013, at 10:07 PM, Tim Kientzle wrote: > > On Feb 21, 2013, at 9:50 PM, Alie Tan wrote: > > > I just built RasPi image and keeps getting this message: > > "unable to copy DTB into module directory" > > then the raspi reboot again and again. > > > Try backing out r247045 and see if that fixes > it for you. > > Also try breaking into the U-Boot prompt > and entering > > > Sorry, left out some steps here. (To clarify, this is a > separate > experiment to be done with an image that includes > r247045). The instructions should say: > > 1) Remove the "fdt addr 0x100" command from loader.rc > > 2) Early in boot, break to the U-Boot prompt (hit any > key during the > 3-second countdown) > > I can't even hit any key on my keyboard. What to do now? > > > Are you on USB/serial console? 256MB RPi? No reset button? > > > I am on video console connected to HDMI, 512MB RPI > > If so, it's very tricky to bring cu up and sneak in a keystroke (not > ENTER though) > > Fiddling with the power and cu usually takes a few attempts for me > > Werner > > Hmm, sorry - never used that HDMI output so far, I'm on serial console Werner From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 07:43:14 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C8D43598 for ; Fri, 22 Feb 2013 07:43:14 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8B451C16 for ; Fri, 22 Feb 2013 07:43:14 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id dx4so253960qab.2 for ; Thu, 21 Feb 2013 23:43:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=SGPqsfe8r/BVVvChkN4gYIBUqVr0tNlXWLVBSh+jMx8=; b=COrOGXHZsaR9eR5HtYx5MNjDJf4jjB+mkHqjQ4Afl2E1MKUxjVePyO3B585xfRdfDa qay+4KqPtYgtVMP9nF+PLtdeyVMepG4H4539BD2ktGM4JjnYomUaLfdUuR0BfseYpGFI ByNiI7WFvWzt1ucXyc9LePv+jfQhBf88Mbj4WvuKOxpAoa3KuY5eqrL+SBVK4n7Kz4e4 pbBIcp9nNucoperLDeEazYaGaWKRON66dqw6wzA+SppMvj6dzIVvkoJKklN7Fu+2b4nO 69ec5J3Ilo33oXT2D1/1m45aAoQ/liXHnBqIRwiI5btjNz06w1DnCNMCx7TzW6K4iM0D 8YJA== MIME-Version: 1.0 X-Received: by 10.224.33.208 with SMTP id i16mr696196qad.45.1361518987722; Thu, 21 Feb 2013 23:43:07 -0800 (PST) Received: by 10.49.51.138 with HTTP; Thu, 21 Feb 2013 23:43:07 -0800 (PST) In-Reply-To: <51271AAB.4080005@thieprojects.ch> References: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> <512716CE.7050600@thieprojects.ch> <51271AAB.4080005@thieprojects.ch> Date: Fri, 22 Feb 2013 15:43:07 +0800 Message-ID: Subject: Re: Unable to copy DTB into module directory From: Alie Tan To: Werner Thie X-Gm-Message-State: ALoCoQnzAFTvfUZq7HAqyFqfyKCzkIwB5TnppsYFolZCAWAsH5n0gOrB+3aHaisP9Ta+JopRp2gV Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Tim Kientzle , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 07:43:14 -0000 On Fri, Feb 22, 2013 at 3:13 PM, Werner Thie wrote: > On 2/22/13 8:07 AM, Alie Tan wrote: > >> >> On Fri, Feb 22, 2013 at 2:57 PM, Werner Thie > > wrote: >> >> On 2/22/13 7:47 AM, Alie Tan wrote: >> >> On Fri, Feb 22, 2013 at 2:17 PM, Tim Kientzle > > wrote: >> >> >> On Feb 21, 2013, at 10:07 PM, Tim Kientzle wrote: >> >> On Feb 21, 2013, at 9:50 PM, Alie Tan wrote: >> >> >> I just built RasPi image and keeps getting this >> message: >> >> "unable to copy DTB into module directory" >> >> then the raspi reboot again and again. >> >> >> Try backing out r247045 and see if that fixes >> it for you. >> >> Also try breaking into the U-Boot prompt >> and entering >> >> >> Sorry, left out some steps here. (To clarify, this is a >> separate >> experiment to be done with an image that includes >> r247045). The instructions should say: >> >> 1) Remove the "fdt addr 0x100" command from loader.rc >> >> 2) Early in boot, break to the U-Boot prompt (hit any >> key during the >> 3-second countdown) >> >> I can't even hit any key on my keyboard. What to do now? >> >> >> Are you on USB/serial console? 256MB RPi? No reset button? >> >> >> I am on video console connected to HDMI, 512MB RPI >> >> If so, it's very tricky to bring cu up and sneak in a keystroke (not >> ENTER though) >> >> Fiddling with the power and cu usually takes a few attempts for me >> >> Werner >> >> >> Hmm, sorry - never used that HDMI output so far, I'm on serial console > Btw I am using script from http://kernelnomicon.org/?p=275 to build the image > > Werner > From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 08:27:09 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 736BFFC7 for ; Fri, 22 Feb 2013 08:27:09 +0000 (UTC) (envelope-from werner@thieprojects.ch) Received: from newton.metanet.ch (newton.metanet.ch [80.74.158.130]) by mx1.freebsd.org (Postfix) with ESMTP id BB073E97 for ; Fri, 22 Feb 2013 08:27:08 +0000 (UTC) Received: (qmail 4212 invoked from network); 22 Feb 2013 09:27:07 +0100 Received: from 217-071-083-008.ip-tech.ch (HELO ?192.168.11.88?) (217.71.83.8) by newton.metanet.ch with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Feb 2013 09:27:07 +0100 Message-ID: <51272BDF.5090603@thieprojects.ch> Date: Fri, 22 Feb 2013 09:27:11 +0100 From: Werner Thie User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Alie Tan Subject: Re: Unable to copy DTB into module directory References: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> <512716CE.7050600@thieprojects.ch> <51271AAB.4080005@thieprojects.ch> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 08:27:09 -0000 On 2/22/13 8:43 AM, Alie Tan wrote: > On Fri, Feb 22, 2013 at 3:13 PM, Werner Thie > wrote: > > On 2/22/13 8:07 AM, Alie Tan wrote: > > > On Fri, Feb 22, 2013 at 2:57 PM, Werner Thie > > __>> wrote: > > On 2/22/13 7:47 AM, Alie Tan wrote: > > On Fri, Feb 22, 2013 at 2:17 PM, Tim Kientzle > > >> wrote: > > > On Feb 21, 2013, at 10:07 PM, Tim Kientzle wrote: > > On Feb 21, 2013, at 9:50 PM, Alie Tan wrote: > > > I just built RasPi image and keeps getting > this message: > > "unable to copy DTB into module directory" > > then the raspi reboot again and again. > > > Try backing out r247045 and see if that fixes > it for you. > > Also try breaking into the U-Boot prompt > and entering > > > Sorry, left out some steps here. (To clarify, this > is a > separate > experiment to be done with an image that includes > r247045). The instructions should say: > > 1) Remove the "fdt addr 0x100" command from > loader.rc > > 2) Early in boot, break to the U-Boot prompt > (hit any > key during the > 3-second countdown) > > I can't even hit any key on my keyboard. What to do now? > > > Are you on USB/serial console? 256MB RPi? No reset button? > > > I am on video console connected to HDMI, 512MB RPI > > If so, it's very tricky to bring cu up and sneak in a > keystroke (not > ENTER though) > > Fiddling with the power and cu usually takes a few attempts > for me > > Werner > > > Hmm, sorry - never used that HDMI output so far, I'm on serial console > > > Btw I am using script from http://kernelnomicon.org/?p=275 to build the > image Me, I prefer Tim Kientzle's work, runs really smooth now, great customization hooks and despite its name, not only for Beaglebone but RPi VersatilePB and PandaBoard too https://github.com/kientzle/freebsd-beaglebone Werner From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 09:12:01 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 730E2D0C for ; Fri, 22 Feb 2013 09:12:01 +0000 (UTC) (envelope-from steve@sohara.org) Received: from uk1rly2283.eechost.net (relay01a.mail.uk1.eechost.net [217.69.40.75]) by mx1.freebsd.org (Postfix) with ESMTP id 29597E7 for ; Fri, 22 Feb 2013 09:12:00 +0000 (UTC) Received: from [31.186.37.179] (helo=smtp.marelmo.com) by uk1rly2283.eechost.net with esmtpa (Exim 4.72) (envelope-from ) id 1U8ofn-0006gf-G5 for freebsd-arm@freebsd.org; Fri, 22 Feb 2013 09:12:07 +0000 Received: from [192.168.63.1] (helo=steve.marelmo.com) by smtp.marelmo.com with smtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U8ofY-000EfA-DL for freebsd-arm@freebsd.org; Fri, 22 Feb 2013 09:11:52 +0000 Date: Fri, 22 Feb 2013 09:11:22 +0000 From: Steve O'Hara-Smith To: freebsd-arm@freebsd.org Subject: Re: Unable to copy DTB into module directory Message-Id: <20130222091122.1760eb0a75550e56537da471@sohara.org> In-Reply-To: <51272BDF.5090603@thieprojects.ch> References: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> <512716CE.7050600@thieprojects.ch> <51271AAB.4080005@thieprojects.ch> <51272BDF.5090603@thieprojects.ch> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Auth-Info: 15567@permanet.ie (plain) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 09:12:01 -0000 On Fri, 22 Feb 2013 09:27:11 +0100 Werner Thie wrote: > Me, I prefer Tim Kientzle's work, runs really smooth now, great > customization hooks and despite its name, not only for Beaglebone but > RPi VersatilePB and PandaBoard too > > https://github.com/kientzle/freebsd-beaglebone There's one problem with Tim's otherwise excellent script, it only works on a -current host, it won't work on 9.1 because the xdev setup is too old. -- Steve O'Hara-Smith From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 11:48:20 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1284BF25 for ; Fri, 22 Feb 2013 11:48:20 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by mx1.freebsd.org (Postfix) with ESMTP id CCB7D945 for ; Fri, 22 Feb 2013 11:48:19 +0000 (UTC) Received: by mail-qe0-f43.google.com with SMTP id s14so268111qeb.30 for ; Fri, 22 Feb 2013 03:48:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=cg2JT9dfe5kxi2UvUQP3jDtUS8/2bfUZg1Yk6a7305M=; b=jc+3IYtJx3y33hgf/O5bttxI8oxOvM9LJ0EylTYCHRKNcte+SjfPzRjHxhWSzA+n7a 4fdbdqj1AZFTnifOOgku3lTohXRW4jX7m7W1CrSMiDLNgZJzpC+r1/qLbX0KK2iEHWhj 0cMF2DCaQbCZCQo+d0QTlhX/EFum61w6Sc3QCpuuN+iAveMHFTU+230hIfBxYX1Zu9BE YWDuGT2aDDVgGmEOqcPomKCn9g7y1d3JfE78E9ssjSv2KcPfQ0IMtl+I7hRnrIet9nW7 Vbgsmwx/1ygEsKLenHoCSsASs9a1P7jSSDkEfx2g6gxyDYa1FbsdiIQWy92vaVT/6g9E i4tQ== MIME-Version: 1.0 X-Received: by 10.49.131.67 with SMTP id ok3mr689324qeb.42.1361533698852; Fri, 22 Feb 2013 03:48:18 -0800 (PST) Received: by 10.49.51.138 with HTTP; Fri, 22 Feb 2013 03:48:18 -0800 (PST) In-Reply-To: References: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> Date: Fri, 22 Feb 2013 19:48:18 +0800 Message-ID: Subject: Re: Unable to copy DTB into module directory From: Alie Tan To: Tim Kientzle X-Gm-Message-State: ALoCoQnKvJvBk3GfmudsZYTAcH8jJRDIMK8QzLPu788TaJKsPOPjm3xTI+oKr6rnL+5xq5wACt5j Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:48:20 -0000 On Fri, Feb 22, 2013 at 2:17 PM, Tim Kientzle wrote: > > On Feb 21, 2013, at 10:07 PM, Tim Kientzle wrote: > > > On Feb 21, 2013, at 9:50 PM, Alie Tan wrote: > >> > >> I just built RasPi image and keeps getting this message: > >> > >> "unable to copy DTB into module directory" > >> > >> then the raspi reboot again and again. > > > > Try backing out r247045 and see if that fixes > > it for you. > > > > Also try breaking into the U-Boot prompt > > and entering > > Sorry, left out some steps here. (To clarify, this is a separate > experiment to be done with an image that includes > r247045). The instructions should say: > Fyi, Reverting r247045 didn't help my proble :-( > > 1) Remove the "fdt addr 0x100" command from loader.rc > > 2) Early in boot, break to the U-Boot prompt (hit any key during the > 3-second countdown) > > 3) Enter these two commands to U-Boot > > U-Boot> fdt addr 0x100 > U-Boot> run bootcmd > > This way, U-Boot will identify the FDT and ubldr will > get it from U-Boot (instead of ubldr accessing it > directly). > > Tim > > From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 11:56:16 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 93B982AD for ; Fri, 22 Feb 2013 11:56:16 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2F38A9B0 for ; Fri, 22 Feb 2013 11:56:16 +0000 (UTC) Received: by mail-qe0-f42.google.com with SMTP id 2so273335qeb.15 for ; Fri, 22 Feb 2013 03:56:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=pOsvsgdhUOdNXRNx7cW4c9j4IoU3wBOvEMNFIVnP/uk=; b=PNjivTZSxQJ1qSyZ3dqa5EUCgyMtbuevPKp1x9EnvVNOcXgT7XwmyNEFgc4rj1ixBM ICrdycUUaNlEHVB1gejSyBTc4zaKTFihBcdsxdcHXS9duBq6rra3Ds/x5EjM1IWLP30h mwhDXnh5vpW2BaimJumcdXfXbWZZM6M2dEPr1uuFmAbZJgBnf2sYgroMLl1xlGfm7ipI 9eAPyXyltVZ9aYS1sLWCy7o8hynFM3qB/5l2xmViKnoaLRFmvp+eUomkccFO3pOhurPI P3KHbefyXQ8pUNH+TXx8BsVyec4ehnG2gYyHEugJLCAUi/sZUhJPXV/u37MWIc+GZ72T sK8w== MIME-Version: 1.0 X-Received: by 10.49.72.136 with SMTP id d8mr678681qev.62.1361534175472; Fri, 22 Feb 2013 03:56:15 -0800 (PST) Received: by 10.49.51.138 with HTTP; Fri, 22 Feb 2013 03:56:15 -0800 (PST) In-Reply-To: References: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> Date: Fri, 22 Feb 2013 19:56:15 +0800 Message-ID: Subject: Re: Unable to copy DTB into module directory From: Alie Tan To: Tim Kientzle X-Gm-Message-State: ALoCoQncyfLwT/BYNd87LfS9DkaBZ3rUtHhDEeURvzoyiK9mIkxNsSTmodEwPsv/OEGw1i7B3caS Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:56:16 -0000 On Fri, Feb 22, 2013 at 7:48 PM, Alie Tan wrote: > On Fri, Feb 22, 2013 at 2:17 PM, Tim Kientzle wrote: > >> >> On Feb 21, 2013, at 10:07 PM, Tim Kientzle wrote: >> >> > On Feb 21, 2013, at 9:50 PM, Alie Tan wrote: >> >> >> >> I just built RasPi image and keeps getting this message: >> >> >> >> "unable to copy DTB into module directory" >> >> >> >> then the raspi reboot again and again. >> > >> > Try backing out r247045 and see if that fixes >> > it for you. >> > >> > Also try breaking into the U-Boot prompt >> > and entering >> >> Sorry, left out some steps here. (To clarify, this is a separate >> experiment to be done with an image that includes >> r247045). The instructions should say: >> > Fyi, Reverting r247045 didn't help my proble :-( > Sorry for incomplete information. Reverting r247045 removes "unable to copy DTB into module directory" error message but my raspi still keeps rebooting after bootloader > >> 1) Remove the "fdt addr 0x100" command from loader.rc >> >> 2) Early in boot, break to the U-Boot prompt (hit any key during the >> 3-second countdown) >> >> 3) Enter these two commands to U-Boot >> >> U-Boot> fdt addr 0x100 >> U-Boot> run bootcmd >> >> This way, U-Boot will identify the FDT and ubldr will >> get it from U-Boot (instead of ubldr accessing it >> directly). >> >> Tim >> >> > From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 13:47:54 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C5307484 for ; Fri, 22 Feb 2013 13:47:54 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 7EF60105 for ; Fri, 22 Feb 2013 13:47:48 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1MDllfP060396 for ; Fri, 22 Feb 2013 06:47:47 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1MDli4O054574; Fri, 22 Feb 2013 06:47:44 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Unable to copy DTB into module directory From: Ian Lepore To: "Steve O'Hara-Smith" In-Reply-To: <20130222091122.1760eb0a75550e56537da471@sohara.org> References: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> <512716CE.7050600@thieprojects.ch> <51271AAB.4080005@thieprojects.ch> <51272BDF.5090603@thieprojects.ch> <20130222091122.1760eb0a75550e56537da471@sohara.org> Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Feb 2013 06:47:44 -0700 Message-ID: <1361540864.1185.65.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:47:54 -0000 On Fri, 2013-02-22 at 09:11 +0000, Steve O'Hara-Smith wrote: > On Fri, 22 Feb 2013 09:27:11 +0100 > Werner Thie wrote: > > > Me, I prefer Tim Kientzle's work, runs really smooth now, great > > customization hooks and despite its name, not only for Beaglebone but > > RPi VersatilePB and PandaBoard too > > > > https://github.com/kientzle/freebsd-beaglebone > > There's one problem with Tim's otherwise excellent script, it only > works on a -current host, it won't work on 9.1 because the xdev setup is too > old. > Hmm, that's odd. I don't use Tim's scripts directly, but my build process is similar, and my build machine runs 8.3 to cross-build for RPi and BeagleBone. Hmm, but I do still use gcc rather than clang, I wonder if that's the difference? -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 14:27:14 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AD0A2E41 for ; Fri, 22 Feb 2013 14:27:14 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) by mx1.freebsd.org (Postfix) with ESMTP id 438ED2FD for ; Fri, 22 Feb 2013 14:27:13 +0000 (UTC) Received: from [192.168.1.104] (pool-173-77-66-237.nycmny.east.verizon.net [173.77.66.237]) (authenticated bits=0) by feynman.konjz.org (8.14.6/8.14.4) with ESMTP id r1MER6lK072030 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 22 Feb 2013 09:27:12 -0500 (EST) (envelope-from george@ceetonetechnology.com) Message-ID: <51278034.7020409@ceetonetechnology.com> Date: Fri, 22 Feb 2013 09:27:00 -0500 From: George Rosamond User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130117 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Unable to copy DTB into module directory References: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> <512716CE.7050600@thieprojects.ch> <51271AAB.4080005@thieprojects.ch> <51272BDF.5090603@thieprojects.ch> <20130222091122.1760eb0a75550e56537da471@sohara.org> <1361540864.1185.65.camel@revolution.hippie.lan> In-Reply-To: <1361540864.1185.65.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 5.32 (*****) FH_HOST_EQ_VERIZON_P,RDNS_DYNAMIC X-Spam-Hits: 5320 X-Spam-Names: FH_HOST_EQ_VERIZON_P,RDNS_DYNAMIC X-Spam-Flag: YES X-Mail-Provider: KonjZ X-Scanned-By: MIMEDefang 2.73 on 64.147.119.39 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: george@ceetonetechnology.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:27:14 -0000 On 02/22/13 08:47, Ian Lepore wrote: > On Fri, 2013-02-22 at 09:11 +0000, Steve O'Hara-Smith wrote: >> On Fri, 22 Feb 2013 09:27:11 +0100 >> Werner Thie wrote: >> >>> Me, I prefer Tim Kientzle's work, runs really smooth now, great >>> customization hooks and despite its name, not only for Beaglebone but >>> RPi VersatilePB and PandaBoard too >>> >>> https://github.com/kientzle/freebsd-beaglebone >> >> There's one problem with Tim's otherwise excellent script, it only >> works on a -current host, it won't work on 9.1 because the xdev setup is too >> old. >> > > Hmm, that's odd. I don't use Tim's scripts directly, but my build > process is similar, and my build machine runs 8.3 to cross-build for RPi > and BeagleBone. Hmm, but I do still use gcc rather than clang, I wonder > if that's the difference? > For the Beagle Bone build, I just have to adjust the tunefs -j line, since my build box is 8.3. And I'm using GCC. But Tim's script is fine for Beagle Bones on that host. This applies to both Gonzo and Tim's scripts, although neither will build RPi as my email yesterday noted. g From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 16:09:59 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F4111697 for ; Fri, 22 Feb 2013 16:09:58 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 921A39B3 for ; Fri, 22 Feb 2013 16:09:58 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1MG9pHr008357 for ; Fri, 22 Feb 2013 11:09:52 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Fri, 22 Feb 2013 11:09:52 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: erlang on arm Message-ID: <20130222110952.4c0d0306@ivory.wynn.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 16:09:59 -0000 Greeting- On suggestion from someone at NYCBUG I decided to build ejabberd yesterday. ejabberd requires erlang, which is marked as not able to build on arm. I commented out that check in the make file and erlang built just fine for me on my Pi. I will be submitting a PR to change the erlang make file, but in the meantime if you need erlang on arm just comment out the following line from the make file: ONLY_FOR_ARCHS= i386 amd64 sparc64 powerpc I hope someone finds this helpful. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 April 19, 1775 An English attempt to confiscate guns from Americans triggered a successful revolution...... Dear Congress, that's a hint. From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 17:55:05 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 607D7112 for ; Fri, 22 Feb 2013 17:55:05 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 223DAEC4 for ; Fri, 22 Feb 2013 17:55:04 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1MHt36c009595 for ; Fri, 22 Feb 2013 12:55:03 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Fri, 22 Feb 2013 12:55:03 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: Fw: ports/176353: erlang builds on arm - port makefile needs to be fixed Message-ID: <20130222125503.0a671116@ivory.wynn.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 17:55:05 -0000 Greeting- Now that I have my Pi fairly stable and connected to some small usb storage I can make my first real contribution to the arm effort. Below is the pr I submitted, which includes a very small makefile fix, to get erlang to build on arm. Thanks to everyone who is doing kernel hacking on the Pi and Beaglebone. Shameless begging here....someone with the know how please give us USB on the BeagleBone! -Brett Begin forwarded message: Date: Fri, 22 Feb 2013 17:50:00 GMT From: FreeBSD-gnats-submit@FreeBSD.org To: Brett Wynkoop Subject: Re: ports/176353: erlang builds on arm - port makefile needs to be fixed Thank you very much for your problem report. It has the internal identification `ports/176353'. The individual assigned to look at your report is: freebsd-ports-bugs. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=176353 >Category: ports >Responsible: freebsd-ports-bugs >Synopsis: erlang builds on arm - port makefile needs to be fixed >Arrival-Date: Fri Feb 22 17:50:00 UTC 2013 -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 April 19, 1775 An English attempt to confiscate guns from Americans triggered a successful revolution...... Dear Congress, that's a hint. From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 17:56:50 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B7C2E164; Fri, 22 Feb 2013 17:56:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 78035ED7; Fri, 22 Feb 2013 17:56:50 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1MHuiAa078809; Fri, 22 Feb 2013 12:56:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1MHuihw078805; Fri, 22 Feb 2013 17:56:44 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 22 Feb 2013 17:56:44 GMT Message-Id: <201302221756.r1MHuihw078805@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 17:56:50 -0000 TB --- 2013-02-22 16:00:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-22 16:00:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-22 16:00:17 - starting HEAD tinderbox run for arm/arm TB --- 2013-02-22 16:00:17 - cleaning the object tree TB --- 2013-02-22 16:00:17 - /usr/local/bin/svn stat /src TB --- 2013-02-22 16:00:21 - At svn revision 247151 TB --- 2013-02-22 16:00:22 - building world TB --- 2013-02-22 16:00:22 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 16:00:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 16:00:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 16:00:22 - SRCCONF=/dev/null TB --- 2013-02-22 16:00:22 - TARGET=arm TB --- 2013-02-22 16:00:22 - TARGET_ARCH=arm TB --- 2013-02-22 16:00:22 - TZ=UTC TB --- 2013-02-22 16:00:22 - __MAKE_CONF=/dev/null TB --- 2013-02-22 16:00:22 - cd /src TB --- 2013-02-22 16:00:22 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 22 16:00:26 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Feb 22 17:50:52 UTC 2013 TB --- 2013-02-22 17:50:52 - generating LINT kernel config TB --- 2013-02-22 17:50:52 - cd /src/sys/arm/conf TB --- 2013-02-22 17:50:52 - /usr/bin/make -B LINT TB --- 2013-02-22 17:50:52 - cd /src/sys/arm/conf TB --- 2013-02-22 17:50:52 - /usr/sbin/config -m LINT TB --- 2013-02-22 17:50:52 - building LINT kernel TB --- 2013-02-22 17:50:52 - CROSS_BUILD_TESTING=YES TB --- 2013-02-22 17:50:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-22 17:50:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-22 17:50:52 - SRCCONF=/dev/null TB --- 2013-02-22 17:50:52 - TARGET=arm TB --- 2013-02-22 17:50:52 - TARGET_ARCH=arm TB --- 2013-02-22 17:50:52 - TZ=UTC TB --- 2013-02-22 17:50:52 - __MAKE_CONF=/dev/null TB --- 2013-02-22 17:50:52 - cd /src TB --- 2013-02-22 17:50:52 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 22 17:50:52 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ld -b binary --no-warn-mismatch -d -warn-common -r -o mw88W8363.fwo mw88W8363.fw uudecode -o mwlboot.fw /src/sys/contrib/dev/mwl/mwlboot.fw.uu ld -b binary --no-warn-mismatch -d -warn-common -r -o mwlboot.fwo mwlboot.fw cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/dev/mxge/if_mxge.c /src/sys/dev/mxge/if_mxge.c: In function 'mxge_rx_csum': /src/sys/dev/mxge/if_mxge.c:2571: error: 'cap' undeclared (first use in this function) /src/sys/dev/mxge/if_mxge.c:2571: error: (Each undeclared identifier is reported only once /src/sys/dev/mxge/if_mxge.c:2571: error: for each function it appears in.) *** [if_mxge.o] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-22 17:56:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-22 17:56:44 - ERROR: failed to build LINT kernel TB --- 2013-02-22 17:56:44 - 5575.86 user 979.06 system 6986.90 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 18:00:04 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 038145B4 for ; Fri, 22 Feb 2013 18:00:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id BAEB8F36 for ; Fri, 22 Feb 2013 18:00:03 +0000 (UTC) Received: by mail-yh0-f52.google.com with SMTP id q46so161299yhf.25 for ; Fri, 22 Feb 2013 10:00:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=OQtCljt0zJnBRCI9vsNR4NOQa6i7cI+2nm41P75nAs4=; b=MZFmkdErylBAo8bQy/BUXkq0yc/fGlU+Pw2kjHGgDDZbN3kHCnyG4M7P3iKGkqtOKc VU9heq6haZJ2Aop/Opv9n5n4bdcV5TOJVvpU3FH/XD9Z3DqE9rmIatnNfPipnMelJILd taY/yECBL+pgKnBbQNfsDr44BZDAm7YIXeS2mIXSH4vlIZoWSxapbLjL9ntv7msugYus CVeBZMBDegXmL4MEKDLJgQrls1HDApKRedY68JQmFpDK10r53ZAHOjL5xfPmhc3bHIx6 0+yQbjD0EtdSH2d1tm3zuzrl/T8psTTCpzhbtZFdzKeqJ0GoOXRZrYSlmEnOHcsij668 e+Cw== X-Received: by 10.236.169.104 with SMTP id m68mr5406332yhl.27.1361556002664; Fri, 22 Feb 2013 10:00:02 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id x8sm7333510yhn.12.2013.02.22.10.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 10:00:01 -0800 (PST) Sender: Warner Losh Subject: Re: Unable to copy DTB into module directory Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130222091122.1760eb0a75550e56537da471@sohara.org> Date: Fri, 22 Feb 2013 10:59:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> <512716CE.7050600@thieprojects.ch> <51271AAB.4080005@thieprojects.ch> <51272BDF.5090603@thieprojects.ch> <20130222091122.1760eb0a75550e56537da471@sohara.org> To: Steve O'Hara-Smith X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmRWVvkxqjL5qttgQxZh4BI7LTiZcdgS9HPaR5Fwj9//FcAGXZQPRZGPGyLcWypgyz6tLvD Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 18:00:04 -0000 On Feb 22, 2013, at 2:11 AM, Steve O'Hara-Smith wrote: > On Fri, 22 Feb 2013 09:27:11 +0100 > Werner Thie wrote: >=20 >> Me, I prefer Tim Kientzle's work, runs really smooth now, great=20 >> customization hooks and despite its name, not only for Beaglebone but=20= >> RPi VersatilePB and PandaBoard too >>=20 >> https://github.com/kientzle/freebsd-beaglebone >=20 > There's one problem with Tim's otherwise excellent script, it = only > works on a -current host, it won't work on 9.1 because the xdev setup = is too > old. Is this because make xdev on a 9.1 host doesn't work, or because there's = changes in current's toolchain that haven't been MFCd? Warner From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 19:12:55 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6E5F63CF for ; Fri, 22 Feb 2013 19:12:55 +0000 (UTC) (envelope-from steve@sohara.org) Received: from uk1rly2283.eechost.net (relay01a.mail.uk1.eechost.net [217.69.40.75]) by mx1.freebsd.org (Postfix) with ESMTP id 0C1E93F9 for ; Fri, 22 Feb 2013 19:12:54 +0000 (UTC) Received: from [31.186.37.179] (helo=smtp.marelmo.com) by uk1rly2283.eechost.net with esmtpa (Exim 4.72) (envelope-from ) id 1U8y3M-0001NM-8C; Fri, 22 Feb 2013 19:13:04 +0000 Received: from [192.168.63.1] (helo=steve.marelmo.com) by smtp.marelmo.com with smtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U8y36-0004Bd-UB; Fri, 22 Feb 2013 19:12:48 +0000 Date: Fri, 22 Feb 2013 19:12:16 +0000 From: Steve O'Hara-Smith To: Warner Losh Subject: Re: Unable to copy DTB into module directory Message-Id: <20130222191216.299b8b44158caef7bb9b3aa1@sohara.org> In-Reply-To: References: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> <512716CE.7050600@thieprojects.ch> <51271AAB.4080005@thieprojects.ch> <51272BDF.5090603@thieprojects.ch> <20130222091122.1760eb0a75550e56537da471@sohara.org> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Auth-Info: 15567@permanet.ie (plain) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 19:12:55 -0000 On Fri, 22 Feb 2013 10:59:58 -0700 Warner Losh wrote: > > On Feb 22, 2013, at 2:11 AM, Steve O'Hara-Smith wrote: > > > On Fri, 22 Feb 2013 09:27:11 +0100 > > Werner Thie wrote: > > > >> Me, I prefer Tim Kientzle's work, runs really smooth now, great > >> customization hooks and despite its name, not only for Beaglebone but > >> RPi VersatilePB and PandaBoard too > >> > >> https://github.com/kientzle/freebsd-beaglebone > > > > There's one problem with Tim's otherwise excellent script, it > > only works on a -current host, it won't work on 9.1 because the xdev > > setup is too old. > > Is this because make xdev on a 9.1 host doesn't work, or because there's > changes in current's toolchain that haven't been MFCd? The latter, I don't recall the exact error message but the essence of it was "Your xdev environment is too old, it's missing $feature update it". -- Steve O'Hara-Smith | Directable Mirror Arrays C:>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/ From owner-freebsd-arm@FreeBSD.ORG Fri Feb 22 19:49:52 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 85E88135 for ; Fri, 22 Feb 2013 19:49:52 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from smtp.getmail.no (smtp.getmail.no [84.208.15.66]) by mx1.freebsd.org (Postfix) with ESMTP id 33716805 for ; Fri, 22 Feb 2013 19:49:51 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from get-mta-scan02.get.basefarm.net ([10.5.16.4]) by get-mta-out03.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0MIN008WR0F2RV00@get-mta-out03.get.basefarm.net> for freebsd-arm@FreeBSD.org; Fri, 22 Feb 2013 20:49:50 +0100 (MET) Received: from get-mta-scan02.get.basefarm.net (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 4BA6D1EA81E4_127CBDEB for ; Fri, 22 Feb 2013 19:49:50 +0000 (GMT) Received: from kg-v2.kg4.no (cm-84.215.134.159.getinternet.no [84.215.134.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by get-mta-scan02.get.basefarm.net (Sophos Email Appliance) with ESMTPSA id 247DB1EA4644_127CBDEF for ; Fri, 22 Feb 2013 19:49:50 +0000 (GMT) Date: Fri, 22 Feb 2013 20:49:49 +0100 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Subject: Cubieboard - how-to? Message-id: <20130222204949.9c3c315077868dcd88a80200@getmail.no> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 19:49:52 -0000 Hello, In a surprise move (not even I did see it coming) I was able to get a Cubieboard (bought it secondhand locally) today. It is the 2012-09-09[2] revision, according to the text on the board itself. Naturally, I want to run FreeBSD on it (well, it is natural for me). - is there a how-to or a writeup somewhere on getting FreeBSD running on the Cubieboard? (everything from install on what? usb stick, microSD, sata hard drive - to which bootloader? - to do you need a serial connection?) - are there ready-made FreeBSD images available somewhere? I tried googling, but didn't get much References: 1) http://cubieboard.org/ 2) http://linux-sunxi.org/Cubieboard -- Torfinn Ingolfsen From owner-freebsd-arm@FreeBSD.ORG Sat Feb 23 04:10:50 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5635CA00 for ; Sat, 23 Feb 2013 04:10:50 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) by mx1.freebsd.org (Postfix) with ESMTP id EF2FAA8D for ; Sat, 23 Feb 2013 04:10:49 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 493C439E09; Sat, 23 Feb 2013 13:00:54 +0900 (JST) Received: from artemis (unknown [172.18.0.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id 341EB39D62; Sat, 23 Feb 2013 13:00:54 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: "Mats Mellstrand" References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> <20130131001553.GC67562@cicely7.cicely.de> <9E78813F3BF946A4A2FCEA2C363A847E@ad.peach.ne.jp> <016DDBBF-D502-4C76-96B5-BEE2D46FC6CC@exmandato.se> In-Reply-To: Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Date: Sat, 23 Feb 2013 13:00:59 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-arm@freebsd.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 04:10:50 -0000 Hi, Did you quote IPv6 address? scp use ':' as special char. Also '[' and ']' may need quotation/escaping for the shell. Please try like this: # scp -v some.txt pi@'[your IPv6 of RPi]':. or use host name instead of IPv6 address. Regards, -- Daisuke Aoyama -------------------------------------------------- From: "Mats Mellstrand" Sent: Tuesday, February 19, 2013 5:27 PM To: "Daisuke Aoyama" Cc: ; Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) > Hi > > I'm having problem with scp to or from RPi. > I have tried IPv4 and IPv6, ue0 and wlan0, but scp don't work. > However ssh does. > > /mm > > On 11 feb 2013, at 20:22, Daisuke Aoyama wrote: > >>> In trying to install the ports collection on my RPi, the following happens: >>> >>> kmem_malloc(4096): kmem_map too small: 12582912 total allocated >>> KDB: enter: panic >>> [ thread pid 27505 tid 100053 ] >>> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >>> >>> Suggestions? (more than not installing the ports collection) >> >> This is known problem of old kernel. You can update the kernel to >> http://www.peach.ne.jp/archives/rpi/kernel/kernel-20130209.gz >> >> or use new image based on SVN r246603: >> http://www.peach.ne.jp/archives/rpi/freebsd-pi-clang-20130210.img.gz >> >> This image contain both complete source tree and portsnap fetch/extracted tree. >> >> Also, some packages making under freebsd-pi-clang-20130210.img are uploaded to: >> http://www.peach.ne.jp/archives/rpi/ports/packages/All/ >> (compiled by clang/clang++ with bundled make.conf) >> ---------------------------------------------------------------------- >> How to use package: >> First, install pkg manually: >> # fetch http://www.peach.ne.jp/archives/rpi/pkg-static >> # fetch http://www.peach.ne.jp/archives/rpi/ports/packages/All/pkg-1.0.7.txz >> # chmod 755 pkg-static >> # ./pkg-static add pkg-1.0.7.txz >> # echo 'PACKAGESITE : http://www.peach.ne.jp/archives/rpi/ports/packages/All' > >> /usr/local/etc/pkg.conf >> >> For example, install bash and subversion: >> # pkg install bash >> # pkg install subversion >> ---------------------------------------------------------------------- >> >> Thank you. >> -- >> Daisuke Aoyama >> From owner-freebsd-arm@FreeBSD.ORG Sat Feb 23 04:51:55 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 033CDF0B for ; Sat, 23 Feb 2013 04:51:55 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id C2358BF2 for ; Sat, 23 Feb 2013 04:51:54 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1N4pkLr007323; Sat, 23 Feb 2013 04:51:46 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id gde89vn4j6jnqekqqsy6wqw2hs; Sat, 23 Feb 2013 04:51:45 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Unable to copy DTB into module directory Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20130222191216.299b8b44158caef7bb9b3aa1@sohara.org> Date: Fri, 22 Feb 2013 20:51:43 -0800 Content-Transfer-Encoding: 7bit Message-Id: <13819FCD-40B6-48F3-9C96-8ED028DB81D3@kientzle.com> References: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> <512716CE.7050600@thieprojects.ch> <51271AAB.4080005@thieprojects.ch> <51272BDF.5090603@thieprojects.ch> <20130222091122.1760eb0a75550e56537da471@sohara.org> <20130222191216.299b8b44158caef7bb9b3aa1@sohara.org> To: "Steve O'Hara-Smith" X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 04:51:55 -0000 On Feb 22, 2013, at 11:12 AM, Steve O'Hara-Smith wrote: > On Fri, 22 Feb 2013 10:59:58 -0700 > Warner Losh wrote: > >> >> On Feb 22, 2013, at 2:11 AM, Steve O'Hara-Smith wrote: >> >>> On Fri, 22 Feb 2013 09:27:11 +0100 >>> Werner Thie wrote: >>> >>>> Me, I prefer Tim Kientzle's work, runs really smooth now, great >>>> customization hooks and despite its name, not only for Beaglebone but >>>> RPi VersatilePB and PandaBoard too >>>> >>>> https://github.com/kientzle/freebsd-beaglebone >>> >>> There's one problem with Tim's otherwise excellent script, it >>> only works on a -current host, it won't work on 9.1 because the xdev >>> setup is too old. >> >> Is this because make xdev on a 9.1 host doesn't work, or because there's >> changes in current's toolchain that haven't been MFCd? > > The latter, I don't recall the exact error message but the essence > of it was "Your xdev environment is too old, it's missing $feature update > it". I apologize for not MFCing that a long time ago. r231336 implemented -print-file-name=include in our gcc.c wrapper, which is used by the U-Boot sources. I just MFCed it to stable/9 at r247167. Tim From owner-freebsd-arm@FreeBSD.ORG Sat Feb 23 04:53:18 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7E9B4F44 for ; Sat, 23 Feb 2013 04:53:18 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 57F6EBFD for ; Sat, 23 Feb 2013 04:53:17 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1N4rGHN007340; Sat, 23 Feb 2013 04:53:16 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id t37hsvgjjh7ui9i27tvbz357ss; Sat, 23 Feb 2013 04:53:15 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Unable to copy DTB into module directory Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Tim Kientzle In-Reply-To: Date: Fri, 22 Feb 2013 20:53:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> To: Alie Tan X-Mailer: Apple Mail (2.1283) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 04:53:18 -0000 On Feb 22, 2013, at 3:56 AM, Alie Tan wrote: > On Fri, Feb 22, 2013 at 7:48 PM, Alie Tan wrote: > On Fri, Feb 22, 2013 at 2:17 PM, Tim Kientzle = wrote: >=20 > On Feb 21, 2013, at 10:07 PM, Tim Kientzle wrote: >=20 > > On Feb 21, 2013, at 9:50 PM, Alie Tan wrote: > >> > >> I just built RasPi image and keeps getting this message: > >> > >> "unable to copy DTB into module directory" > >> > >> then the raspi reboot again and again. > > > > Try backing out r247045 and see if that fixes > > it for you. > Fyi, Reverting r247045 didn't help my proble :-( > Sorry for incomplete information. Reverting r247045 removes "unable to = copy DTB into module directory" error message but my raspi still keeps = rebooting after bootloader Thanks for testing that. Apparently, there is more going on here than I thought. I'll dig into it this weekend. Tim From owner-freebsd-arm@FreeBSD.ORG Sat Feb 23 04:55:30 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C4D09124 for ; Sat, 23 Feb 2013 04:55:30 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by mx1.freebsd.org (Postfix) with ESMTP id 877F8C31 for ; Sat, 23 Feb 2013 04:55:30 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id o13so754850qaj.19 for ; Fri, 22 Feb 2013 20:55:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=uNUd28tVyWr30C3F8sOnWAO3q50RsyWoViYEKfAvTwc=; b=dlnoC3aD2JFeFlWN1Nf3uygQO+NN3TaEKYd5RyxjMTGFlhqtuOzn8sPfxx8c9Z5ROy H5PE7YwiBFRzDk170S++tc4/myWVq0yTaGkUt2G7s6rkjyOU325Tu3tIa1c1s9/HFjPY WA/xyc8MLzRAaqoWAQqvyuHD7ZYaHqR702O691jd++EIh6szkTlivXxbJBBXvqeuGUqb Ihxrf8VLoyXBQYpzwb/ER04a9sy17JMCQN1ZSoqI6y9d97NkxDYCsrTwqsNv7ZBdGq3G QfpfqBxdB85Qyu4ZsbawuC93b8ZvClLh4kjv3DXZdItTi2jWMGPUVR5kwb1mR2Xm32SF YTpg== MIME-Version: 1.0 X-Received: by 10.49.84.104 with SMTP id x8mr2408609qey.5.1361595329844; Fri, 22 Feb 2013 20:55:29 -0800 (PST) Received: by 10.49.87.193 with HTTP; Fri, 22 Feb 2013 20:55:29 -0800 (PST) In-Reply-To: References: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> Date: Sat, 23 Feb 2013 12:55:29 +0800 Message-ID: Subject: Re: Unable to copy DTB into module directory From: Alie Tan To: Tim Kientzle X-Gm-Message-State: ALoCoQkYshhGjDJVN3qhu4+VvbVXCrU3shldrBiS3v74x+1yoVvp+zbaVOPAzikUrL/ZPckxEvJM Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 04:55:30 -0000 On Fri, Feb 22, 2013 at 7:56 PM, Alie Tan wrote: > On Fri, Feb 22, 2013 at 7:48 PM, Alie Tan wrote: > >> On Fri, Feb 22, 2013 at 2:17 PM, Tim Kientzle wrote: >> >>> >>> On Feb 21, 2013, at 10:07 PM, Tim Kientzle wrote: >>> >>> > On Feb 21, 2013, at 9:50 PM, Alie Tan wrote: >>> >> >>> >> I just built RasPi image and keeps getting this message: >>> >> >>> >> "unable to copy DTB into module directory" >>> >> >>> >> then the raspi reboot again and again. >>> > >>> > Try backing out r247045 and see if that fixes >>> > it for you. >>> > >>> > Also try breaking into the U-Boot prompt >>> > and entering >>> >>> Sorry, left out some steps here. (To clarify, this is a separate >>> experiment to be done with an image that includes >>> r247045). The instructions should say: >>> >> Fyi, Reverting r247045 didn't help my proble :-( >> > Sorry for incomplete information. Reverting r247045 removes "unable to > copy DTB into module directory" error message but my raspi still keeps > rebooting after bootloader > Removing WITH_ARM_EABI="YES" solved my problem > >>> 1) Remove the "fdt addr 0x100" command from loader.rc >>> >>> 2) Early in boot, break to the U-Boot prompt (hit any key during the >>> 3-second countdown) >>> >>> 3) Enter these two commands to U-Boot >>> >>> U-Boot> fdt addr 0x100 >>> U-Boot> run bootcmd >>> >>> This way, U-Boot will identify the FDT and ubldr will >>> get it from U-Boot (instead of ubldr accessing it >>> directly). >>> >>> Tim >>> >>> >> > From owner-freebsd-arm@FreeBSD.ORG Sat Feb 23 06:23:18 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 92038757 for ; Sat, 23 Feb 2013 06:23:18 +0000 (UTC) (envelope-from mats@exmandato.se) Received: from ext.mellstrand.net (ext.mellstrand.net [IPv6:2001:2040:4:2::51]) by mx1.freebsd.org (Postfix) with ESMTP id 1DE32E68 for ; Sat, 23 Feb 2013 06:23:17 +0000 (UTC) Received: by ext.mellstrand.net Sat, 23 Feb 2013 06:23:10 GMT Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 From: Mats Mellstrand X-Priority: 3 In-Reply-To: Date: Sat, 23 Feb 2013 07:23:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <28AF530A-E06F-480A-8A4D-242FB0019136@exmandato.se> References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> <20130131001553.GC67562@cicely7.cicely.de> <9E78813F3BF946A4A2FCEA2C363A847E@ad.peach.ne.jp> <016DDBBF-D502-4C76-96B5-BEE2D46FC6CC@exmandato.se> To: "Daisuke Aoyama" Cc: freebsd-arm@freebsd.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 06:23:18 -0000 Hi On 23 feb 2013, at 05:00, "Daisuke Aoyama" wrote: > Hi, >=20 > Did you quote IPv6 address? I use hostname.=20 > scp use ':' as special char. > Also '[' and ']' may need quotation/escaping for the shell. >=20 > Please try like this: > # scp -v some.txt pi@'[your IPv6 of RPi]':. >=20 > or use host name instead of IPv6 address. Hostname. The scp client - I have tried many - connects to RPi but after a while = the connection stalls. And the same happens with both IPv4. [client] ~% scp -4 rpi:/usr/home/mats/tess.txt . C0755 868 tess.txt No file is copied [client] ~% scp -6 rpi:/usr/home/mats/tess.txt . C0755 868 tess.txt No file is copied /mm >=20 > Regards, > --=20 > Daisuke Aoyama >=20 >=20 > -------------------------------------------------- > From: "Mats Mellstrand" > Sent: Tuesday, February 19, 2013 5:27 PM > To: "Daisuke Aoyama" > Cc: ; > Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + = ubldr) >=20 >> Hi >>=20 >> I'm having problem with scp to or from RPi. >> I have tried IPv4 and IPv6, ue0 and wlan0, but scp don't work. >> However ssh does. >>=20 >> /mm >>=20 >> On 11 feb 2013, at 20:22, Daisuke Aoyama wrote: >>=20 >>>> In trying to install the ports collection on my RPi, the following = happens: >>>>=20 >>>> kmem_malloc(4096): kmem_map too small: 12582912 total allocated >>>> KDB: enter: panic >>>> [ thread pid 27505 tid 100053 ] >>>> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >>>>=20 >>>> Suggestions? (more than not installing the ports collection) >>>=20 >>> This is known problem of old kernel. You can update the kernel to >>> http://www.peach.ne.jp/archives/rpi/kernel/kernel-20130209.gz >>>=20 >>> or use new image based on SVN r246603: >>> http://www.peach.ne.jp/archives/rpi/freebsd-pi-clang-20130210.img.gz >>>=20 >>> This image contain both complete source tree and portsnap = fetch/extracted tree. >>>=20 >>> Also, some packages making under freebsd-pi-clang-20130210.img are = uploaded to: >>> http://www.peach.ne.jp/archives/rpi/ports/packages/All/ >>> (compiled by clang/clang++ with bundled make.conf) >>> = ---------------------------------------------------------------------- >>> How to use package: >>> First, install pkg manually: >>> # fetch http://www.peach.ne.jp/archives/rpi/pkg-static >>> # fetch = http://www.peach.ne.jp/archives/rpi/ports/packages/All/pkg-1.0.7.txz >>> # chmod 755 pkg-static >>> # ./pkg-static add pkg-1.0.7.txz >>> # echo 'PACKAGESITE : = http://www.peach.ne.jp/archives/rpi/ports/packages/All' > = /usr/local/etc/pkg.conf >>>=20 >>> For example, install bash and subversion: >>> # pkg install bash >>> # pkg install subversion >>> = ---------------------------------------------------------------------- >>>=20 >>> Thank you. >>> --=20 >>> Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Sat Feb 23 06:27:10 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B848C899 for ; Sat, 23 Feb 2013 06:27:10 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 91370E8C for ; Sat, 23 Feb 2013 06:27:10 +0000 (UTC) Received: by mail-ia0-f174.google.com with SMTP id u20so1155994iag.5 for ; Fri, 22 Feb 2013 22:27:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7QuKgryAg2G8zLEbu3E7Z4yAmAzdgNniVpZdat3azLs=; b=Br0tWHqK5gNGUqo4ZBD0tN1yoARGCIaOo0Kr7gFBpgFC+p8fbMAU3H1XIUDOA7ZZIY UxYlwV4FDZ6q3AGM6IqAGnVSld8unVe9vpr+G9z8UHZ5V+bDqN6VVjubS+dRaXYVWGw6 XwXSWKTb/ruB8Qijh+/ibk8bFHthpiI+IGKfpKI6Cx1baKUgoWm89QzKUiMAPni24zTU bUy4hPU411SIltoiKSk1CB6canm7o5Fv0dJs7rKfy5w+XHHelL4dTwELHklnfRcHmjS9 3FwWMnEDlVfsh7PnQB4oP9ZoWKlGb9uYcnuGYCXStvRBT9fOr2jlZIVtPi62QsbUvCwQ 59IQ== MIME-Version: 1.0 X-Received: by 10.50.156.198 with SMTP id wg6mr456208igb.47.1361600830266; Fri, 22 Feb 2013 22:27:10 -0800 (PST) Received: by 10.64.6.230 with HTTP; Fri, 22 Feb 2013 22:27:10 -0800 (PST) In-Reply-To: <20130222204949.9c3c315077868dcd88a80200@getmail.no> References: <20130222204949.9c3c315077868dcd88a80200@getmail.no> Date: Sat, 23 Feb 2013 14:27:10 +0800 Message-ID: Subject: Re: Cubieboard - how-to? From: Ganbold Tsagaankhuu To: Torfinn Ingolfsen Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 06:27:10 -0000 Hi, On Sat, Feb 23, 2013 at 3:49 AM, Torfinn Ingolfsen wrote: > Hello, > > In a surprise move (not even I did see it coming) I was able to get a Cubieboard (bought it secondhand locally) today. > It is the 2012-09-09[2] revision, according to the text on the board itself. > > Naturally, I want to run FreeBSD on it (well, it is natural for me). > - is there a how-to or a writeup somewhere on getting FreeBSD running on the Cubieboard? A10 SoC support is in HEAD, but in beginning period. As for running FreeBSD, there are some netboot tips for Hackberry (uses same SoC A10 as cubieboard) and some scripts files that should work for cubieboard too. Please check those at: http://kernelnomicon.org/?p=298 FYI, I run my cubieboard loading/booting kernel from SD card. > (everything from install on what? usb stick, microSD, sata hard drive - to which bootloader? - to do you need a serial connection?) > - are there ready-made FreeBSD images available somewhere? > > I tried googling, but didn't get much > For very quick testing you can grab kernel from: http://people.freebsd.org/~ganbold/cubieboard/kernel and try to boot from net/SD card using files (script, uboot, spl etc) at http://people.freebsd.org/~gonzo/arm/hackberry/ Kernel assumes you have rootfs on usb stick's second partition (like da0s2) There is no SATA driver yet as well as SD and NAND drivers. usb works (2 host usb interfaces), so I only tested mounting rootfs using usb stick. There is no ethernet driver yet too. So basically board support is in beginning stage but in pretty good shape. Also uart related diff is sent for the review. For test however you can use usb connected devices like maybe ethernet, hard disk etc. If you need rootfs I can send you the link off the list, where you can download the image. You can also build your own rootfs using Tim's scripts (https://github.com/kientzle/freebsd-beaglebone, you can build for BeagleBone and use its disk image) hope this helps, Ganbold > References: > 1) http://cubieboard.org/ > 2) http://linux-sunxi.org/Cubieboard > -- > Torfinn Ingolfsen > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sat Feb 23 14:27:30 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B80E39A0 for ; Sat, 23 Feb 2013 14:27:30 +0000 (UTC) (envelope-from mats@exmandato.se) Received: from ext.mellstrand.net (ext.mellstrand.net [IPv6:2001:2040:4:2::51]) by mx1.freebsd.org (Postfix) with ESMTP id E7A31F41 for ; Sat, 23 Feb 2013 14:27:29 +0000 (UTC) Received: by ext.mellstrand.net Sat, 23 Feb 2013 14:27:17 GMT Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Mats Mellstrand X-Priority: 3 In-Reply-To: <28AF530A-E06F-480A-8A4D-242FB0019136@exmandato.se> Date: Sat, 23 Feb 2013 15:27:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <858C493F-151D-4811-8696-AE5932919413@exmandato.se> References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> <20130131001553.GC67562@cicely7.cicely.de> <9E78813F3BF946A4A2FCEA2C363A847E@ad.peach.ne.jp> <016DDBBF-D502-4C76-96B5-BEE2D46FC6CC@exmandato.se> <28AF530A-E06F-480A-8A4D-242FB0019136@exmandato.se> To: "Daisuke Aoyama" Cc: freebsd-arm@freebsd.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 14:27:30 -0000 Hi Some more "digging" [client] ~/Desktop% sftp rpi Received message too long 459092027 I tried various clients, with the same result. To summarize - and correct my self: The name rpi is registered in my DNS and associated with both an IPv4 = and IPv6 address. Both addresses also have reverse name definitions (in-addr.arpa and = ip6.arpa).=20 I am using the latest image from http://www.peach.ne.jp/archives/rpi/ FreeBSD a25.mellstrand.net 10.0-CURRENT FreeBSD 10.0-CURRENT #0 = r246603M: Sun Feb 10 10:24:24 JST 2013 = aoyama@fbs.local:/usr/obj-rpi-clang/arm.armv6/usr/src/sys/RPI-B-test16 = arm=20 I have disabled all ipfw functions I can ssh to and from the RPi I can scp from the RPi I can't scp to the RPi I can't open an sftp session to the RPi I have lots of debug output from the sshd and the various clients I have = tried.=20 I am attaching a small part from the client side: debug1: Authentication succeeded (publickey). debug1: Sending command: scp -v -f -- tess.txt debug2: channel 0: request exec confirm 1 debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 65536 debug2: channel_input_status_confirm: type 99 id 0 debug2: exec request accepted on channel 0 debug2: channel 0: rcvd ext data 39 Sending file modes: C0755 868 tess.txt debug2: channel 0: written 39 to efd 8 Sink: C0755 868 tess.txt C0755 868 tess.txt debug2: channel 0: read<=3D0 rfd 6 len 0 debug2: channel 0: read failed debug2: channel 0: close_read debug2: channel 0: input open -> drain debug2: channel 0: ibuf empty debug2: channel 0: send eof debug2: channel 0: input drain -> closed debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug2: channel 0: rcvd close debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1) debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Transferred: sent 2656, received 2488 bytes, in 0.4 seconds Bytes per second: sent 7543.1, received 7066.0 debug1: Exit status 1 /mm On 23 feb 2013, at 07:23, Mats Mellstrand wrote: > Hi > On 23 feb 2013, at 05:00, "Daisuke Aoyama" wrote: >=20 >> Hi, >>=20 >> Did you quote IPv6 address? >=20 > I use hostname.=20 >=20 >> scp use ':' as special char. >> Also '[' and ']' may need quotation/escaping for the shell. >>=20 >> Please try like this: >> # scp -v some.txt pi@'[your IPv6 of RPi]':. >>=20 >> or use host name instead of IPv6 address. >=20 > Hostname. >=20 > The scp client - I have tried many - connects to RPi but after a while = the connection stalls. >=20 > And the same happens with both IPv4. >=20 > [client] ~% scp -4 rpi:/usr/home/mats/tess.txt . > C0755 868 tess.txt >=20 > No file is copied >=20 > [client] ~% scp -6 rpi:/usr/home/mats/tess.txt . > C0755 868 tess.txt >=20 >=20 > No file is copied >=20 >=20 > /mm >=20 >>=20 >> Regards, >> --=20 >> Daisuke Aoyama >>=20 >>=20 >> -------------------------------------------------- >> From: "Mats Mellstrand" >> Sent: Tuesday, February 19, 2013 5:27 PM >> To: "Daisuke Aoyama" >> Cc: ; >> Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot = + ubldr) >>=20 >>> Hi >>>=20 >>> I'm having problem with scp to or from RPi. >>> I have tried IPv4 and IPv6, ue0 and wlan0, but scp don't work. >>> However ssh does. >>>=20 >>> /mm >>>=20 >>> On 11 feb 2013, at 20:22, Daisuke Aoyama wrote: >>>=20 >>>>> In trying to install the ports collection on my RPi, the following = happens: >>>>>=20 >>>>> kmem_malloc(4096): kmem_map too small: 12582912 total allocated >>>>> KDB: enter: panic >>>>> [ thread pid 27505 tid 100053 ] >>>>> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >>>>>=20 >>>>> Suggestions? (more than not installing the ports collection) >>>>=20 >>>> This is known problem of old kernel. You can update the kernel to >>>> http://www.peach.ne.jp/archives/rpi/kernel/kernel-20130209.gz >>>>=20 >>>> or use new image based on SVN r246603: >>>> = http://www.peach.ne.jp/archives/rpi/freebsd-pi-clang-20130210.img.gz >>>>=20 >>>> This image contain both complete source tree and portsnap = fetch/extracted tree. >>>>=20 >>>> Also, some packages making under freebsd-pi-clang-20130210.img are = uploaded to: >>>> http://www.peach.ne.jp/archives/rpi/ports/packages/All/ >>>> (compiled by clang/clang++ with bundled make.conf) >>>> = ---------------------------------------------------------------------- >>>> How to use package: >>>> First, install pkg manually: >>>> # fetch http://www.peach.ne.jp/archives/rpi/pkg-static >>>> # fetch = http://www.peach.ne.jp/archives/rpi/ports/packages/All/pkg-1.0.7.txz >>>> # chmod 755 pkg-static >>>> # ./pkg-static add pkg-1.0.7.txz >>>> # echo 'PACKAGESITE : = http://www.peach.ne.jp/archives/rpi/ports/packages/All' > = /usr/local/etc/pkg.conf >>>>=20 >>>> For example, install bash and subversion: >>>> # pkg install bash >>>> # pkg install subversion >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> Thank you. >>>> --=20 >>>> Daisuke Aoyama >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sat Feb 23 14:45:56 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AF373FDC for ; Sat, 23 Feb 2013 14:45:56 +0000 (UTC) (envelope-from mats@exmandato.se) Received: from ext.mellstrand.net (ext.mellstrand.net [IPv6:2001:2040:4:2::51]) by mx1.freebsd.org (Postfix) with ESMTP id CA62BFCF for ; Sat, 23 Feb 2013 14:45:55 +0000 (UTC) Received: by ext.mellstrand.net Sat, 23 Feb 2013 14:45:52 GMT Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Mats Mellstrand X-Priority: 3 In-Reply-To: <858C493F-151D-4811-8696-AE5932919413@exmandato.se> Date: Sat, 23 Feb 2013 15:45:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <010BA15C-C907-43C4-8886-2DE84CE62689@exmandato.se> References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> <20130131001553.GC67562@cicely7.cicely.de> <9E78813F3BF946A4A2FCEA2C363A847E@ad.peach.ne.jp> <016DDBBF-D502-4C76-96B5-BEE2D46FC6CC@exmandato.se> <28AF530A-E06F-480A-8A4D-242FB0019136@exmandato.se> <858C493F-151D-4811-8696-AE5932919413@exmandato.se> To: "Daisuke Aoyama" Cc: freebsd-arm@freebsd.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 14:45:56 -0000 Hi=20 I made a cut-and-paste error in my previous mail The log file from the client side should be: debug1: Sending command: scp -v -f -- tess.txt debug2: channel 0: request exec confirm 1 debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 65536 debug2: channel_input_status_confirm: type 99 id 0 debug2: exec request accepted on channel 0 debug2: channel 0: rcvd ext data 39 Sending file modes: C0755 868 tess.txt debug2: channel 0: written 39 to efd 8 Sink: C0755 868 tess.txt C0755 868 tess.txt debug2: channel 0: read<=3D0 rfd 6 len 0 debug2: channel 0: read failed debug2: channel 0: close_read debug2: channel 0: input open -> drain debug2: channel 0: ibuf empty debug2: channel 0: send eof debug2: channel 0: input drain -> closed [client] ~/Desktop% debug2: channel 0: rcvd eof <--- = here the client receives an eof from the RPi, closes the connectionand = return. The output from the session continues... debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug2: channel 0: rcvd close debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1) debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Transferred: sent 2656, received 2488 bytes, in 0.4 seconds Bytes per second: sent 7543.1, received 7066.0 debug1: Exit status 1 On 23 feb 2013, at 15:27, Mats Mellstrand wrote: > Hi >=20 > Some more "digging" >=20 >=20 > [client] ~/Desktop% sftp rpi > Received message too long 459092027 >=20 > I tried various clients, with the same result. >=20 > To summarize - and correct my self: >=20 > The name rpi is registered in my DNS and associated with both an IPv4 = and IPv6 address. > Both addresses also have reverse name definitions (in-addr.arpa and = ip6.arpa).=20 > I am using the latest image from http://www.peach.ne.jp/archives/rpi/ >=20 > FreeBSD a25.mellstrand.net 10.0-CURRENT FreeBSD 10.0-CURRENT #0 = r246603M: Sun Feb 10 10:24:24 JST 2013 = aoyama@fbs.local:/usr/obj-rpi-clang/arm.armv6/usr/src/sys/RPI-B-test16 = arm=20 >=20 > I have disabled all ipfw functions >=20 > I can ssh to and from the RPi >=20 > I can scp from the RPi >=20 > I can't scp to the RPi >=20 > I can't open an sftp session to the RPi >=20 > I have lots of debug output from the sshd and the various clients I = have tried.=20 > I am attaching a small part from the client side: >=20 > debug1: Authentication succeeded (publickey). > debug1: Sending command: scp -v -f -- tess.txt > debug2: channel 0: request exec confirm 1 > debug2: callback done > debug2: channel 0: open confirm rwindow 0 rmax 32768 > debug2: channel 0: rcvd adjust 65536 > debug2: channel_input_status_confirm: type 99 id 0 > debug2: exec request accepted on channel 0 > debug2: channel 0: rcvd ext data 39 > Sending file modes: C0755 868 tess.txt > debug2: channel 0: written 39 to efd 8 > Sink: C0755 868 tess.txt > C0755 868 tess.txt > debug2: channel 0: read<=3D0 rfd 6 len 0 > debug2: channel 0: read failed > debug2: channel 0: close_read > debug2: channel 0: input open -> drain > debug2: channel 0: ibuf empty > debug2: channel 0: send eof > debug2: channel 0: input drain -> closed > debug2: channel 0: rcvd eof > debug2: channel 0: output open -> drain > debug2: channel 0: obuf empty > debug2: channel 0: close_write > debug2: channel 0: output drain -> closed > debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 > debug2: channel 0: rcvd close > debug3: channel 0: will not send data after close > debug2: channel 0: almost dead > debug2: channel 0: gc: notify user > debug2: channel 0: gc: user detached > debug2: channel 0: send close > debug2: channel 0: is dead > debug2: channel 0: garbage collecting > debug1: channel 0: free: client-session, nchannels 1 > debug3: channel 0: status: The following connections are open: > #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1) >=20 > debug1: fd 0 clearing O_NONBLOCK > debug1: fd 1 clearing O_NONBLOCK > Transferred: sent 2656, received 2488 bytes, in 0.4 seconds > Bytes per second: sent 7543.1, received 7066.0 > debug1: Exit status 1 >=20 >=20 > /mm >=20 >=20 > On 23 feb 2013, at 07:23, Mats Mellstrand wrote: >=20 >> Hi >> On 23 feb 2013, at 05:00, "Daisuke Aoyama" = wrote: >>=20 >>> Hi, >>>=20 >>> Did you quote IPv6 address? >>=20 >> I use hostname.=20 >>=20 >>> scp use ':' as special char. >>> Also '[' and ']' may need quotation/escaping for the shell. >>>=20 >>> Please try like this: >>> # scp -v some.txt pi@'[your IPv6 of RPi]':. >>>=20 >>> or use host name instead of IPv6 address. >>=20 >> Hostname. >>=20 >> The scp client - I have tried many - connects to RPi but after a = while the connection stalls. >>=20 >> And the same happens with both IPv4. >>=20 >> [client] ~% scp -4 rpi:/usr/home/mats/tess.txt . >> C0755 868 tess.txt >>=20 >> No file is copied >>=20 >> [client] ~% scp -6 rpi:/usr/home/mats/tess.txt . >> C0755 868 tess.txt >>=20 >>=20 >> No file is copied >>=20 >>=20 >> /mm >>=20 >>>=20 >>> Regards, >>> --=20 >>> Daisuke Aoyama >>>=20 >>>=20 >>> -------------------------------------------------- >>> From: "Mats Mellstrand" >>> Sent: Tuesday, February 19, 2013 5:27 PM >>> To: "Daisuke Aoyama" >>> Cc: ; >>> Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot = + ubldr) >>>=20 >>>> Hi >>>>=20 >>>> I'm having problem with scp to or from RPi. >>>> I have tried IPv4 and IPv6, ue0 and wlan0, but scp don't work. >>>> However ssh does. >>>>=20 >>>> /mm >>>>=20 >>>> On 11 feb 2013, at 20:22, Daisuke Aoyama = wrote: >>>>=20 >>>>>> In trying to install the ports collection on my RPi, the = following happens: >>>>>>=20 >>>>>> kmem_malloc(4096): kmem_map too small: 12582912 total allocated >>>>>> KDB: enter: panic >>>>>> [ thread pid 27505 tid 100053 ] >>>>>> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >>>>>>=20 >>>>>> Suggestions? (more than not installing the ports collection) >>>>>=20 >>>>> This is known problem of old kernel. You can update the kernel to >>>>> http://www.peach.ne.jp/archives/rpi/kernel/kernel-20130209.gz >>>>>=20 >>>>> or use new image based on SVN r246603: >>>>> = http://www.peach.ne.jp/archives/rpi/freebsd-pi-clang-20130210.img.gz >>>>>=20 >>>>> This image contain both complete source tree and portsnap = fetch/extracted tree. >>>>>=20 >>>>> Also, some packages making under freebsd-pi-clang-20130210.img are = uploaded to: >>>>> http://www.peach.ne.jp/archives/rpi/ports/packages/All/ >>>>> (compiled by clang/clang++ with bundled make.conf) >>>>> = ---------------------------------------------------------------------- >>>>> How to use package: >>>>> First, install pkg manually: >>>>> # fetch http://www.peach.ne.jp/archives/rpi/pkg-static >>>>> # fetch = http://www.peach.ne.jp/archives/rpi/ports/packages/All/pkg-1.0.7.txz >>>>> # chmod 755 pkg-static >>>>> # ./pkg-static add pkg-1.0.7.txz >>>>> # echo 'PACKAGESITE : = http://www.peach.ne.jp/archives/rpi/ports/packages/All' > = /usr/local/etc/pkg.conf >>>>>=20 >>>>> For example, install bash and subversion: >>>>> # pkg install bash >>>>> # pkg install subversion >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> Thank you. >>>>> --=20 >>>>> Daisuke Aoyama >>=20 >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sat Feb 23 17:00:37 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4662716B for ; Sat, 23 Feb 2013 17:00:37 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id D7341911 for ; Sat, 23 Feb 2013 17:00:29 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1NH0TnZ082732 for ; Sat, 23 Feb 2013 10:00:29 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1NH06VK056063; Sat, 23 Feb 2013 10:00:06 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) From: Ian Lepore To: Mats Mellstrand In-Reply-To: <010BA15C-C907-43C4-8886-2DE84CE62689@exmandato.se> References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> <20130131001553.GC67562@cicely7.cicely.de> <9E78813F3BF946A4A2FCEA2C363A847E@ad.peach.ne.jp> <016DDBBF-D502-4C76-96B5-BEE2D46FC6CC@exmandato.se> <28AF530A-E06F-480A-8A4D-242FB0019136@exmandato.se> <858C493F-151D-4811-8696-AE5932919413@exmandato.se> <010BA15C-C907-43C4-8886-2DE84CE62689@exmandato.se> Content-Type: text/plain; charset="us-ascii" Date: Sat, 23 Feb 2013 10:00:06 -0700 Message-ID: <1361638806.1185.101.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 17:00:37 -0000 On Sat, 2013-02-23 at 15:45 +0100, Mats Mellstrand wrote: > Hi > > I made a cut-and-paste error in my previous mail > The log file from the client side should be: > > debug1: Sending command: scp -v -f -- tess.txt > debug2: channel 0: request exec confirm 1 > debug2: callback done > debug2: channel 0: open confirm rwindow 0 rmax 32768 > debug2: channel 0: rcvd adjust 65536 > debug2: channel_input_status_confirm: type 99 id 0 > debug2: exec request accepted on channel 0 > debug2: channel 0: rcvd ext data 39 > Sending file modes: C0755 868 tess.txt > debug2: channel 0: written 39 to efd 8 > Sink: C0755 868 tess.txt > C0755 868 tess.txt > debug2: channel 0: read<=0 rfd 6 len 0 > debug2: channel 0: read failed > debug2: channel 0: close_read > debug2: channel 0: input open -> drain > debug2: channel 0: ibuf empty > debug2: channel 0: send eof > debug2: channel 0: input drain -> closed > [client] ~/Desktop% debug2: channel 0: rcvd eof <--- here the client receives an eof from the RPi, closes the connectionand return. The output from the session continues... > debug2: channel 0: output open -> drain > debug2: channel 0: obuf empty > debug2: channel 0: close_write > debug2: channel 0: output drain -> closed > debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 > debug2: channel 0: rcvd close > debug3: channel 0: will not send data after close > debug2: channel 0: almost dead > debug2: channel 0: gc: notify user > debug2: channel 0: gc: user detached > debug2: channel 0: send close > debug2: channel 0: is dead > debug2: channel 0: garbage collecting > debug1: channel 0: free: client-session, nchannels 1 > debug3: channel 0: status: The following connections are open: > #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1) > > debug1: fd 0 clearing O_NONBLOCK > debug1: fd 1 clearing O_NONBLOCK > Transferred: sent 2656, received 2488 bytes, in 0.4 seconds > Bytes per second: sent 7543.1, received 7066.0 > debug1: Exit status 1 Is there any chance you've got a logon script (.cshrc or whatever) that's echoing output when you log on, even in the case of a non-interactive session? I've had that kind of thing cause ssh and scp problems in the past. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Feb 23 17:04:30 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F311819E; Sat, 23 Feb 2013 17:04:29 +0000 (UTC) (envelope-from mats@exmandato.se) Received: from ext.mellstrand.net (ext.mellstrand.net [IPv6:2001:2040:4:2::51]) by mx1.freebsd.org (Postfix) with ESMTP id 81202929; Sat, 23 Feb 2013 17:04:29 +0000 (UTC) Received: by ext.mellstrand.net Sat, 23 Feb 2013 17:04:21 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) From: Mats Mellstrand In-Reply-To: <1361638806.1185.101.camel@revolution.hippie.lan> Date: Sat, 23 Feb 2013 18:04:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> <20130131001553.GC67562@cicely7.cicely.de> <9E78813F3BF946A4A2FCEA2C363A847E@ad.peach.ne.jp> <016DDBBF-D502-4C76-96B5-BEE2D46FC6CC@exmandato.se> <28AF530A-E06F-480A-8A4D-242FB0019136@exmandato.se> <858C493F-151D-4811-8696-AE5932919413@exmandato.se> <010BA15C-C907-43C4-8886-2DE84CE62689@exmandato.se> <1361638806.1185.1! 01.camel@revolution.hippie.lan> To: Ian Lepore Cc: freebsd-arm@freebsd.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 17:04:30 -0000 On 23 feb 2013, at 18:00, Ian Lepore wrote: > On Sat, 2013-02-23 at 15:45 +0100, Mats Mellstrand wrote: >> Hi=20 >>=20 >> I made a cut-and-paste error in my previous mail >> The log file from the client side should be: >>=20 >> debug1: Sending command: scp -v -f -- tess.txt >> debug2: channel 0: request exec confirm 1 >> debug2: callback done >> debug2: channel 0: open confirm rwindow 0 rmax 32768 >> debug2: channel 0: rcvd adjust 65536 >> debug2: channel_input_status_confirm: type 99 id 0 >> debug2: exec request accepted on channel 0 >> debug2: channel 0: rcvd ext data 39 >> Sending file modes: C0755 868 tess.txt >> debug2: channel 0: written 39 to efd 8 >> Sink: C0755 868 tess.txt >> C0755 868 tess.txt >> debug2: channel 0: read<=3D0 rfd 6 len 0 >> debug2: channel 0: read failed >> debug2: channel 0: close_read >> debug2: channel 0: input open -> drain >> debug2: channel 0: ibuf empty >> debug2: channel 0: send eof >> debug2: channel 0: input drain -> closed >> [client] ~/Desktop% debug2: channel 0: rcvd eof <--- = here the client receives an eof from the RPi, closes the connectionand = return. The output from the session continues... >> debug2: channel 0: output open -> drain >> debug2: channel 0: obuf empty >> debug2: channel 0: close_write >> debug2: channel 0: output drain -> closed >> debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 >> debug2: channel 0: rcvd close >> debug3: channel 0: will not send data after close >> debug2: channel 0: almost dead >> debug2: channel 0: gc: notify user >> debug2: channel 0: gc: user detached >> debug2: channel 0: send close >> debug2: channel 0: is dead >> debug2: channel 0: garbage collecting >> debug1: channel 0: free: client-session, nchannels 1 >> debug3: channel 0: status: The following connections are open: >> #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1) >>=20 >> debug1: fd 0 clearing O_NONBLOCK >> debug1: fd 1 clearing O_NONBLOCK >> Transferred: sent 2656, received 2488 bytes, in 0.4 seconds >> Bytes per second: sent 7543.1, received 7066.0 >> debug1: Exit status 1 >=20 > Is there any chance you've got a logon script (.cshrc or whatever) > that's echoing output when you log on, even in the case of a > non-interactive session? I've had that kind of thing cause ssh and = scp > problems in the past. >=20 > -- Ian Yes! That was the problem. Thanks! /mm >=20 >=20 From owner-freebsd-arm@FreeBSD.ORG Sat Feb 23 22:01:47 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F2795448 for ; Sat, 23 Feb 2013 22:01:47 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id D26D377E for ; Sat, 23 Feb 2013 22:01:46 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1NM1i3U011783; Sat, 23 Feb 2013 22:01:44 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 7hvd2v6r7u5vtqxde23rhqfw96; Sat, 23 Feb 2013 22:01:44 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Unable to copy DTB into module directory Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: Date: Sat, 23 Feb 2013 14:01:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3A8BA2BC-6707-4309-B6E3-5B15712ED67D@kientzle.com> To: Alie Tan X-Mailer: Apple Mail (2.1283) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 22:01:48 -0000 > >> > >> I just built RasPi image and keeps getting this message: > >> > >> "unable to copy DTB into module directory" > >> > >> then the raspi reboot again and again. > > > > Try backing out r247045 and see if that fixes > > it for you. > > >=20 > Fyi, Reverting r247045 didn't help my proble :-( > Sorry for incomplete information. Reverting r247045 removes "unable to = copy DTB into module directory" error message but my raspi still keeps = rebooting after boot loader I believe that r247201 fixes the bug I introduced with r247045 and should allow RPi to boot cleanly again. (Though I seem to have some other problem locally that I need to track down=85) This should also make it possible to have U-Boot pick up the FDT from the RPi boot code (by adding "fdt addr 0x100" to the right place in uEnv.txt or the u-boot loader script) and remove that command from loader.rc. If U-Boot knows about the FDT, then ubldr should pick it up automatically now. I've made the necessary adjustment to my build scripts; it should be a very small tweak to Oleksandr's as well. Let me know if this works for you. Tim