From owner-freebsd-arm@freebsd.org Sun Mar 26 12:07:45 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 040F3D124D4; Sun, 26 Mar 2017 12:07:45 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 759C81889; Sun, 26 Mar 2017 12:07:44 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id x137so9789158lff.3; Sun, 26 Mar 2017 05:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9s7jlmzSFGnGUr3N8L9/bw21b5uvSZN+LzZAWAH6dhs=; b=ZMrrArW1jJEnpWdazzXt/CbkdYUdj3WKR0Qbl7yuEx3z9/ZjsDiAK/gm5IUY7tJVm8 h6+BuqNqe24G0SMxGcgEyoe+yMY2Rh1ElOVMFsTqG+f4V13pMoeU3DLzgOlBdFJd6rme cSdDvCvFUM+G3UxFyFgTEiopWc1qIR1rbbJQnWObvoiXd45KVz7hnWaR2itX63bP+eY9 bmoBTaFC6v3tTZtclprYB+6itzw9epmDdIeL6F/6So3knS+Tl4Mo3FERZb4R7SI9rWh+ 4ZgSORLCyMFBOQuV1vWvp1kkGi4MYpdGB/3Nebket66+ZzM0EMIh3EsyQf4i8mjoN3FP sLUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9s7jlmzSFGnGUr3N8L9/bw21b5uvSZN+LzZAWAH6dhs=; b=J7JW3iQnMhugViv3X6RyHiFcxWlBWcqXWzfa+e75qEM872ZclydCqe3zDmqD9TbYsP lhnQ9A2w6jtkTNxS+wjh/iX8U4vvVHhjnaPjEP9dTIChlEhQSHmu7+Ca4UKAZBOTx6+n Wvvdkghvheq0tFjREKhXkjtdPEnIzEn7JbSnpYWegz93gfrl0sixXJSS6RGa4ORm4Lw0 dat2VMAoHtc4oJSdjKy8B9G1NPe3gGwerBYa9DBAGv456HhP2ng2xQwl05/yUVxvabgX wwe1s6a1kF4v9xtXlkCp82stt9VgDlfWumqs5LhDYKuBYN1WxPep2ypCj+GVUkUj/0n0 uPvQ== X-Gm-Message-State: AFeK/H1hcLciSb02PhihMGA+k3WdO2r+8nXfde8p/vQYzp1yLF51+QkAzE8J9yvKUWP49aFDAvwVUuYUinTu9g== X-Received: by 10.25.0.148 with SMTP id 142mr8639677lfa.156.1490530062398; Sun, 26 Mar 2017 05:07:42 -0700 (PDT) MIME-Version: 1.0 Sender: lwhsu.freebsd@gmail.com Received: by 10.25.193.22 with HTTP; Sun, 26 Mar 2017 05:07:41 -0700 (PDT) In-Reply-To: <906EDF27-C387-4188-978F-66B81E31093B@dsl-only.net> References: <906EDF27-C387-4188-978F-66B81E31093B@dsl-only.net> From: Li-Wen Hsu Date: Sun, 26 Mar 2017 20:07:41 +0800 X-Google-Sender-Auth: 9RLogrV68EaaaMonwE2kAmoors0 Message-ID: Subject: Re: I had to revert /usr/local/aarch64-freebsd from 2.28 for its bin/ld to work for -r315870 buildworld (adm64 -> arm64 cross build) To: Mark Millard Cc: Baptiste Daroussin , FreeBSD Toolchain , freebsd-arm , FreeBSD Ports Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 12:07:45 -0000 On Fri, Mar 24, 2017 at 11:31 AM, Mark Millard wrote: > Building /usr/obj/pine64_clang/arm64.aarch64/usr/src/lib/libc/libc. > so.7.full > --- libc.so.7.full --- > building shared library libc.so.7 > /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x3b): > R_AARCH64_ABS64 used with TLS symbol udb > /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x58): > R_AARCH64_ABS64 used with TLS symbol uf > /usr/local/aarch64-freebsd/bin/ld: utxdb.pico(.debug_info+0x5a): > R_AARCH64_ABS64 used with TLS symbol futx_to_utx.ut > /usr/local/aarch64-freebsd/bin/ld: jemalloc_tsd.pico(.debug_info+0x3c): > R_AARCH64_ABS64 used with TLS symbol __je_tsd_tls > /usr/local/aarch64-freebsd/bin/ld: jemalloc_tsd.pico(.debug_info+0x146e): > R_AARCH64_ABS64 used with TLS symbol __je_tsd_initialized > /usr/local/aarch64-freebsd/bin/ld: cxa_thread_atexit_impl.pico(.debug_info+0x3b): > R_AARCH64_ABS64 used with TLS symbol dtors > /usr/local/aarch64-freebsd/bin/ld: xlocale.pico(.debug_info+0x403): > R_AARCH64_ABS64 used with TLS symbol __thread_locale > /usr/local/aarch64-freebsd/bin/ld: setrunelocale.pico(.debug_info+0x3c): > R_AARCH64_ABS64 used with TLS symbol _ThreadRuneLocale > cc: error: linker command failed with exit code 1 (use -v to see > invocation) > I also see this on our CI server: https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/ , this job began failing since aarch64-binutils upgraded to 2.28 on pkg.freebsd.org. Should we revert this change for now? Or the fix is being prepared? Best, Li-Wen -- Li-Wen Hsu https://lwhsu.org From owner-freebsd-arm@freebsd.org Sun Mar 26 22:22:00 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3FC77D1DF4F for ; Sun, 26 Mar 2017 22:22:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-177.reflexion.net [208.70.211.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5CF81E11 for ; Sun, 26 Mar 2017 22:21:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6578 invoked from network); 26 Mar 2017 22:22:52 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 26 Mar 2017 22:22:52 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Sun, 26 Mar 2017 18:21:57 -0400 (EDT) Received: (qmail 10776 invoked from network); 26 Mar 2017 22:21:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Mar 2017 22:21:57 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id D2154EC770C; Sun, 26 Mar 2017 15:21:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: I had to revert /usr/local/aarch64-freebsd from 2.28 for its bin/ld to work for -r315870 buildworld (adm64 -> arm64 cross build) From: Mark Millard In-Reply-To: Date: Sun, 26 Mar 2017 15:21:56 -0700 Cc: FreeBSD Toolchain , freebsd-arm , FreeBSD Ports Content-Transfer-Encoding: quoted-printable Message-Id: References: <906EDF27-C387-4188-978F-66B81E31093B@dsl-only.net> To: Li-Wen Hsu , Baptiste Daroussin X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 22:22:00 -0000 On 2017-Mar-26, at 5:07 AM, Li-Wen Hsu wrote: On Fri, Mar 24, 2017 at 11:31 AM, Mark Millard = wrote: > Building = /usr/obj/pine64_clang/arm64.aarch64/usr/src/lib/libc/libc.so.7.full > --- libc.so.7.full --- > building shared library libc.so.7 > /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x3b): = R_AARCH64_ABS64 used with TLS symbol udb > /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x58): = R_AARCH64_ABS64 used with TLS symbol uf > /usr/local/aarch64-freebsd/bin/ld: utxdb.pico(.debug_info+0x5a): = R_AARCH64_ABS64 used with TLS symbol futx_to_utx.ut > /usr/local/aarch64-freebsd/bin/ld: = jemalloc_tsd.pico(.debug_info+0x3c): R_AARCH64_ABS64 used with TLS = symbol __je_tsd_tls > /usr/local/aarch64-freebsd/bin/ld: = jemalloc_tsd.pico(.debug_info+0x146e): R_AARCH64_ABS64 used with TLS = symbol __je_tsd_initialized > /usr/local/aarch64-freebsd/bin/ld: = cxa_thread_atexit_impl.pico(.debug_info+0x3b): R_AARCH64_ABS64 used with = TLS symbol dtors > /usr/local/aarch64-freebsd/bin/ld: xlocale.pico(.debug_info+0x403): = R_AARCH64_ABS64 used with TLS symbol __thread_locale > /usr/local/aarch64-freebsd/bin/ld: = setrunelocale.pico(.debug_info+0x3c): R_AARCH64_ABS64 used with TLS = symbol _ThreadRuneLocale > cc: error: linker command failed with exit code 1 (use -v to see = invocation) >=20 > I also see this on our CI server: = https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/ , this job began = failing since aarch64-binutils upgraded to 2.28 on pkg.freebsd.org. >=20 > Should we revert this change for now? Or the fix is being prepared? I have no clue about any effort to fix the problem. I noticed this after first doing a self-hosted amd64 update. Once I noticed the amd64 -> arm64 problem (the next thing that I tried), I also reverted for targeting armv6/v7 and for targeting powerpc64 and powerpc without testing 2.28 for them. I had to in order to complete targeting arm64 because of the slave-port status that had me revert devel/binutils itself as well. So I do not even know if TARGET_ARCH=3Daarch64 is the only problem area. I've no say in if something like this is reverted but I'd guess that unless the time frame for a fix is known to be rather short it would be reverted until there is an expected-fix available. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Mar 27 19:29:22 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5A15D2008B for ; Mon, 27 Mar 2017 19:29:22 +0000 (UTC) (envelope-from lacour.alexandre@gmail.com) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 70A0AC9E for ; Mon, 27 Mar 2017 19:29:22 +0000 (UTC) (envelope-from lacour.alexandre@gmail.com) Received: by mail-vk0-x22b.google.com with SMTP id s68so64129540vke.3 for ; Mon, 27 Mar 2017 12:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=GGztf6IFuRcSvEGUJLgE2GFngGAolULCfT/UEB/PYjI=; b=KnJmNTs5OCGjJo34bdYGyKwr8H+UrFfInFpjpLI6r2/dFhtSSzbPrEnDt/uypN1Nni Dell11NRB6g11AYYaOaXh8klXgasT9QrFzU5amHShGRxOXHJp/FNTJd623TiKbj6jfue 7mFcp4OLq7M4r5Dmi9QbAIXWgnLhYJHpa0iEwZkmUb9BIoYeqQc18+v4fhUHPGXkE6r5 qUlVupptoL5JSC+ZeZs1bmlXkPfRt553LsIVATIesacckV5lAW85+HHWX9YlbVkTNgFm 9SzID16R4mBMl+ASZ4yil9KFqWVQMfCOj9+KcXEVc+dRKBzi9HP9T4uBnPqRKk9PVrAb UEdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GGztf6IFuRcSvEGUJLgE2GFngGAolULCfT/UEB/PYjI=; b=Ra7zQqcGUBqMFUYvpsco8DHr2Dqa/dAVgPC/3au4lUsawCNBY8KHWA35SJqz7ejmaj AdJRhtlYzHUIh9H+k4UbvxpMqPWSOCyyno5KV0kCDYs6uArbZzOWtSwwCOmoznAiE9rZ r4exqbB65lFIC2OsQZq/9MTELoXydsWx4ivmHDQ5mHYYryTkz9WccK7fIGV536PjM3mt pmZMr63xRrU0aAR1UKb5mQrXbR6e6JoC8sCJdY6p7/u+dboJ2THXwfCrWw1VsesW9jUO Ghr8TqkiG3AqabOw5rzWpQx2Ye5hqT/Owm9uaCnuVqMvDaj0yGal52yQCXdjkgy0SoEO 5B0g== X-Gm-Message-State: AFeK/H1pD2s0oGZx5nKjp6qMvQLExJBhN73R8++THhbfBH7xpGncyAxn+lsWdVy0cNuqCJuPA+bIhyo83lhtvg== X-Received: by 10.159.35.143 with SMTP id 15mr8049026uao.150.1490642959012; Mon, 27 Mar 2017 12:29:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.66.134 with HTTP; Mon, 27 Mar 2017 12:28:48 -0700 (PDT) From: Alexandre LACOUR Date: Mon, 27 Mar 2017 21:28:48 +0200 Message-ID: Subject: Beagleborne Board Black Wireless // cpsw0: Failed to read from PHY To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 19:29:22 -0000 Hello, I don't know how to solve the following issue. I can read some articles but haven't seen corrections. As of now I can't load the wireless device. $ uname -a FreeBSD beaglebone 11.0-STABLE FreeBSD 11.0-STABLE #0 r315855: Thu Mar 23 21:44:11 UTC 2017 root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE arm $ dmesg | grep cps cpswss0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a1007ff,0x4a101200-0x4a1012ff irq 38,39,40,41 on simplebus0 cpswss0: CPSW SS Version 1.12 (0) cpswss0: Initial queue size TX=128 RX=384 cpsw0: on cpswss0 cpsw0: Failed to read from PHY. cpsw0: attaching PHYs failed device_attach: cpsw0 attach returned 6 Any ideas ? Thanks for your support. ---- Alexandre LACOUR Skype: lacour_a GSM: +33 6 29 79 74 64 From owner-freebsd-arm@freebsd.org Tue Mar 28 03:59:06 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45A7DD2154B for ; Tue, 28 Mar 2017 03:59:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-179.reflexion.net [208.70.211.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EDD6D7B6 for ; Tue, 28 Mar 2017 03:59:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28528 invoked from network); 28 Mar 2017 03:59:57 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Mar 2017 03:59:57 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Mon, 27 Mar 2017 23:59:03 -0400 (EDT) Received: (qmail 27894 invoked from network); 28 Mar 2017 03:59:02 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Mar 2017 03:59:02 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 27966EC8257; Mon, 27 Mar 2017 20:59:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!] From: Mark Millard In-Reply-To: <1C595969-C6E0-44A2-9086-E48C237263BC@dsl-only.net> Date: Mon, 27 Mar 2017 20:59:01 -0700 Cc: FreeBSD Current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: 7bit Message-Id: References: <01735A68-FED6-4E63-964F-0820FE5C446C@dsl-only.net> <16B3D614-62E1-4E58-B409-8DB9DBB35BCB@dsl-only.net> <5BEAFC6C-DA80-4D7B-AB55-977E585D1ACC@dsl-only.net> <10F50F1C-FD26-4142-9350-966312822438@dsl-only.net> <76DD9882-B4BD-4A16-A8E1-5A5FBB5A21F5@dsl-only.net> <1C595969-C6E0-44A2-9086-E48C237263BC@dsl-only.net> To: Andrew Turner , freebsd-arm X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 03:59:06 -0000 On 2017-Mar-21, at 7:21 PM, Mark Millard wrote: > On 2017-Mar-18, at 9:10 PM, Mark Millard wrote: > >> >> On 2017-Mar-18, at 5:53 PM, Mark Millard wrote: >> >>> A new, significant discovery follows. . . >>> >>> While checking out use of procstat -v I ran >>> into the following common property for the 3 >>> programs that I looked at: >>> >>> A) My small test program that fails for >>> a dynamically allocated space. >>> >>> B) sh reporting Failed assertion: "tsd_booted". >>> >>> C) su reporting Failed assertion: "tsd_booted". >>> >>> Here are example addresses from the area of >>> incorrectly zeroed memory (A then B then C): >>> >>> (lldb) print dyn_region >>> (region *volatile) $0 = 0x0000000040616000 >>> >>> (lldb) print &__je_tsd_booted >>> (bool *) $0 = 0x0000000040618520 >>> >>> (lldb) print &__je_tsd_booted >>> (bool *) $0 = 0x0000000040618520 >> >> That last above was a copy/paste error. Correction: >> >> (lldb) print &__je_tsd_booted >> (bool *) $0 = 0x000000004061d520 >> >>> The first is from dynamic allocation ending up >>> in the area. The other two are from libc.so.7 >>> globals/statics ending up in the general area. >>> >>> It looks like something is trashing a specific >>> memory area for some reason, rather independently >>> of what the program specifics are. > > I probably should have noted that the processes > involved were: child/parent then grandparent > and then great grandparent. The grandparent > was sh and the great grandparent was su. > > The ancestors in the process tree are being > damaged, not just the instances of the > program that demonstrates the problem. > >>> Other notes: >>> >>> At least for my small program showing failure: >>> >>> Being explicit about the combined conditions for failure >>> for my test program. . . >>> >>> Both tcache enabled and allocations fitting in SMALL_MAXCLASS >>> are required in order to make the program fail. >>> >>> Note: >>> >>> lldb) print __je_tcache_maxclass >>> (size_t) $0 = 32768 >>> >>> which is larger than SMALL_MAXCLASS. I've not observed >>> failures for sizes above SMALL_MAXCLASS but not exceeding >>> __je_tcache_maxclass. >>> >>> Thus tcache use by itself does not seen sufficient for >>> my program to get corruption of its dynamically allocated >>> memory: the small allocation size also matters. >>> >>> >>> Be warned that I can not eliminate the possibility that >>> the trashing changed what region of memory it trashed >>> for larger allocations or when tcache is disabled. >> >> The pine64+ 2GB eventually got into a state where: >> >> /etc/malloc.conf -> tcache:false >> >> made no difference and the failure kept occurring >> with that symbolic link in place. >> >> But after a reboot of the pin46+ 2GB >> /etc/malloc.conf -> tcache:false was again effective >> for my test program. (It was still present from >> before the reboot.) >> >> I checked the .core files and the allocated address >> assigned to dyn_region was the same in the tries >> before and after the reboot. (I had put in an >> additional raise(SIGABRT) so I'd always have >> a core file to look at.) >> >> Apparently /etc/malloc.conf -> tcache:false was >> being ignored before the reboot for some reason? > > I have also discovered that if the child process > in an example like my program does a: > > (void) posix_madvise(dyn_region, region_size, POSIX_MADV_WILLNEED); > > after the fork but before the sleep/swap-out/wait > then the problem does not happen. This is without > any read or write access to the memory between the > fork and sleep/swap-out/wait. > > By contrast such POSIX_MADV_WILLNEED use in the parent > process does not change the failure behavior. I've added another test program to bugzilla 217239 and 217138, one with thousands of 14 KiByte allocations. The test program usually ends up with them all being zeroed in the parent and child of the fork. But I've had a couple of runs where a much smaller prefix was messed up and then there were normal, expected values. #define region_size (14u*1024u) . . . #define num_regions (256u*1024u*1024u/region_size) So num_regions==18724, using up most of 256 MiBytes. Note: each region has its own 14 KiByte allocation. But dyn_regions[1296].array[0] in one example was the first normal value. In another example dyn_regions[2180].array[4096] was the first normal value. The last is interesting for being part way through an allocation's space. That but aligning with a 4 KiByte page size would seem odd for a pure-jemalloc issue. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Mar 28 10:50:16 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E9DCD20B15 for ; Tue, 28 Mar 2017 10:50:16 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 64A8D799 for ; Tue, 28 Mar 2017 10:50:15 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x22d.google.com with SMTP id r142so32716690qke.2 for ; Tue, 28 Mar 2017 03:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=EWvhhQ1LNU9EfqiapBNMATCOAVu8IrilGFwr+DDqPAY=; b=MZZ0A9TBFu1HY8zOK4ljrkzkdxkeMMhyv+P913pY5eGclb46Je4B6uOjQnbcxaiPH9 lFboBSu4Z+ZJfW+7svR6u4luqIKXciQ7A1iMjW0SwWwSLkbuVSpI1JGv3f7VFXbMorHx qLFdMVCDTHHmlp+7DitIVnuPecyNA3rHH7qd4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=EWvhhQ1LNU9EfqiapBNMATCOAVu8IrilGFwr+DDqPAY=; b=mdOfdOgkDugBrnM72P6lehfahzT6lVOmcIb9ucNCllRvjcjCwoeqUe++1+wwC0NbpZ +vU7t3aILfXNb3l/4wQoz8m6wondFAWdEtYu/tDgh9zjCkiUgVcJLyWqyfuYRFegigxm ZOmP9EYZHJ98PMjFhfYfPx3RGSKvFlBH7uJBNESo10hofE2u4Wf68IUhxA816ez9bdfm rwzEO6HwRQmruzaMTp07gssduJ3hRp2veloFY1/azgpopujW3JquFyJNURTi2KbGLGFa WItq7tMa82TJaICpXxLpqD+u5kcKrco69d4NUkl3yjhHwJiRNgwo3LIWtWU5auhewt2M sm4g== X-Gm-Message-State: AFeK/H2ALLc2pRAmjjl4o1R4D8NnHMcLuNNI2xAshLFcwoPUP/FVoJngKmx3WUOMJgH8TA== X-Received: by 10.55.88.66 with SMTP id m63mr25600780qkb.270.1490698214530; Tue, 28 Mar 2017 03:50:14 -0700 (PDT) Received: from [192.168.0.11] ([186.236.217.98]) by smtp.googlemail.com with ESMTPSA id a21sm1163382qkc.12.2017.03.28.03.50.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 03:50:14 -0700 (PDT) To: "freebsd-arm@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= Subject: vm_fault: pager read error, pid 1 (init) on beaglebone black Message-ID: <62c82146-0022-d811-891e-2f12c28af1aa@bsd.com.br> Date: Tue, 28 Mar 2017 07:49:46 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 10:50:16 -0000 After upgrade my src to revision 316065 and rebuild my beaglebone black image I'm getting this error on boot: ===================================================================== Growing root partition to fill device mmcsd0s2 resized mmcsd0s2a resized eval: growfs: Device not configured /etc/rc: WARNING: hostid: unable to figure out a UUID from DMI data, generating a new one eval: sleep: Device not configured eval: uuidgen: Device not configured eval: /sbin/md5: Device not configured Setting hostuuid: . Setting hostid: 0x. sysctl: invalid unsigned long '0x' eval: cannot open /etc/fstab: Device not configured No suitable dump device was found. eval: cannot open /etc/fstab: Device not configured eval: /sbin/swapon: Device not configured Warning! No /etc/fstab: skipping disk checks. eval: mount: Device not configured Mounting root filesystem rw failed, startup aborted ERROR: ABORTING BOOT (sending SIGTERM to parent)! vm_fault: pager read error, pid 1 (init) vm_fault: pager read error, pid 1 (init) vm_fault: pager read error, pid 1 (init) vm_fault: pager read error, pid 1 (init) ===================================================================== When building images using crochet, theses error messages pops up: ===================================================================== tunefs: NFSv4 ACLs set Mounting all file systems: Mounting FAT partition 1 at /root/crochet/work/_.mount.boot Mounting UFS partition 1 at /root/crochet/work/_.mount.freebsd Installing U-Boot from: /usr/local/share/u-boot/u-boot-beaglebone /root/crochet/work/fdt/fdt.7pbKpU/beaglebone.dtb: Warning (unit_address_vs_reg): Node /ocp/ethernet@4a100000/slave@4a100200 has a unit name, but no reg property /root/crochet/work/fdt/fdt.7pbKpU/beaglebone.dtb: Warning (unit_address_vs_reg): Node /ocp/ethernet@4a100000/slave@4a100300 has a unit name, but no reg property : Warning (unit_address_vs_reg): Node /ocp/ethernet@4a100000/slave@4a100200 has a unit name, but no reg property : Warning (unit_address_vs_reg): Node /ocp/ethernet@4a100000/slave@4a100300 has a unit name, but no reg property /root/crochet/work/fdt/fdt.FyugYN/beaglebone.dtb: Warning (unit_address_vs_reg): Node /ocp/ethernet@4a100000/slave@4a100200 has a unit name, but no reg property /root/crochet/work/fdt/fdt.FyugYN/beaglebone.dtb: Warning (unit_address_vs_reg): Node /ocp/ethernet@4a100000/slave@4a100300 has a unit name, but no reg property /root/crochet/work/fdt/fdt.8TQGJw/beaglebone-black.dtb: Warning (unit_address_vs_reg): Node /ocp/i2c@44e0b000/tda19988 has a reg or ranges property, but no unit name /root/crochet/work/fdt/fdt.8TQGJw/beaglebone-black.dtb: Warning (unit_address_vs_reg): Node /ocp/i2c@44e0b000/tda19988/ports/port@0 has a unit name, but no reg property /root/crochet/work/fdt/fdt.8TQGJw/beaglebone-black.dtb: Warning (unit_address_vs_reg): Node /ocp/i2c@44e0b000/tda19988/ports/port@0/endpoint@0 has a unit name, but no reg property /root/crochet/work/fdt/fdt.8TQGJw/beaglebone-black.dtb: Warning (unit_address_vs_reg): Node /ocp/ethernet@4a100000/slave@4a100200 has a unit name, but no reg property /root/crochet/work/fdt/fdt.8TQGJw/beaglebone-black.dtb: Warning (unit_address_vs_reg): Node /ocp/ethernet@4a100000/slave@4a100300 has a unit name, but no reg property /root/crochet/work/fdt/fdt.8TQGJw/beaglebone-black.dtb: Warning (unit_address_vs_reg): Node /ocp/lcdc@4830e000/port/endpoint@0 has a unit name, but no reg property : Warning (unit_address_vs_reg): Node /ocp/i2c@44e0b000/tda19988 has a reg or ranges property, but no unit name : Warning (unit_address_vs_reg): Node /ocp/i2c@44e0b000/tda19988/ports/port@0 has a unit name, but no reg property : Warning (unit_address_vs_reg): Node /ocp/i2c@44e0b000/tda19988/ports/port@0/endpoint@0 has a unit name, but no reg property : Warning (unit_address_vs_reg): Node /ocp/ethernet@4a100000/slave@4a100200 has a unit name, but no reg property : Warning (unit_address_vs_reg): Node /ocp/ethernet@4a100000/slave@4a100300 has a unit name, but no reg property : Warning (unit_address_vs_reg): Node /ocp/lcdc@4830e000/port/endpoint@0 has a unit name, but no reg property /root/crochet/work/fdt/fdt.tdGlJZ/beaglebone-black.dtb: Warning (unit_address_vs_reg): Node /ocp/i2c@44e0b000/tda19988 has a reg or ranges property, but no unit name /root/crochet/work/fdt/fdt.tdGlJZ/beaglebone-black.dtb: Warning (unit_address_vs_reg): Node /ocp/i2c@44e0b000/tda19988/ports/port@0 has a unit name, but no reg property /root/crochet/work/fdt/fdt.tdGlJZ/beaglebone-black.dtb: Warning (unit_address_vs_reg): Node /ocp/i2c@44e0b000/tda19988/ports/port@0/endpoint@0 has a unit name, but no reg property /root/crochet/work/fdt/fdt.tdGlJZ/beaglebone-black.dtb: Warning (unit_address_vs_reg): Node /ocp/ethernet@4a100000/slave@4a100200 has a unit name, but no reg property /root/crochet/work/fdt/fdt.tdGlJZ/beaglebone-black.dtb: Warning (unit_address_vs_reg): Node /ocp/ethernet@4a100000/slave@4a100300 has a unit name, but no reg property /root/crochet/work/fdt/fdt.tdGlJZ/beaglebone-black.dtb: Warning (unit_address_vs_reg): Node /ocp/lcdc@4830e000/port/endpoint@0 has a unit name, but no reg property ===================================================================== Someone can give me a hint about what is causing this? []'s -Otacilio From owner-freebsd-arm@freebsd.org Tue Mar 28 13:56:10 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B786D2213A for ; Tue, 28 Mar 2017 13:56:10 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 6D19C613 for ; Tue, 28 Mar 2017 13:56:09 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from dhcp-10-248-121-82.eduroam.wireless.private.cam.ac.uk (global-5-144.nat-2.net.cam.ac.uk [131.111.5.144]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 452AF4E6A2 for ; Tue, 28 Mar 2017 13:56:03 +0000 (UTC) From: Andrew Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Making INTRNG a requirement on armv6 Date: Tue, 28 Mar 2017 14:56:02 +0100 References: To: freebsd-arm@freebsd.org In-Reply-To: Message-Id: <3359BFE7-64DB-460C-821B-50325FC253AA@fubar.geek.nz> X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 13:56:10 -0000 > On 16 Mar 2017, at 17:08, Andrew Turner wrote: >=20 > Hello arm, >=20 > I would like to make INTRNG a requirement on armv6. This is to help > with moving more armv6 kernel configurations into GENERIC. It also > helps when we want a child interrupt controller, e.g. a GPIO driver. >=20 > Most of the current armv6 kernel configurations already use INTRNG, so > only a few places need to be updated.=20 >=20 > I=E2=80=99ve run a test build making it an error to not have INTRNG = enabled and > found the following armv6 configs fail: >=20 > AML8726 > ARMADAXP > DIGI-CCWMX53 > EFIKA_MX > IMX53 > IMX53-QSB > VERSATILEPB > YYHD18 >=20 > I'm interested in people who have this hardware to try enabling INTRNG > and testing. Note that this may require the interrupt controller = driver > the SoC uses to be ported to INTRNG. >=20 The following configs still need work. AML8726 ARMADAXP VERSATILEPB YYHD18 John Where has promised patches for the AML8726 (that I would expect to = work with YYHD18), but that still leaves the ARMADAXP and VERSATILEPB = configs. If nobody cares about these we should remove them as there will be = further updates and cleanups needed in the future and we need someone to = test them on these platforms. Andrew From owner-freebsd-arm@freebsd.org Tue Mar 28 17:48:08 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4168D22898 for ; Tue, 28 Mar 2017 17:48:08 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B9BD4C05 for ; Tue, 28 Mar 2017 17:48:08 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1csvDt-0000yo-Vy; Tue, 28 Mar 2017 10:48:02 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v2SHm1gm003769; Tue, 28 Mar 2017 10:48:01 -0700 (PDT) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Tue, 28 Mar 2017 10:48:00 -0700 From: Oleksandr Tymoshenko To: Andrew Turner Cc: freebsd-arm@freebsd.org Subject: Re: Making INTRNG a requirement on armv6 Message-ID: <20170328174800.GA3754@bluezbox.com> References: <3359BFE7-64DB-460C-821B-50325FC253AA@fubar.geek.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3359BFE7-64DB-460C-821B-50325FC253AA@fubar.geek.nz> X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Andrew Turner (andrew@fubar.geek.nz) wrote: > > > On 16 Mar 2017, at 17:08, Andrew Turner wrote: > > > > Hello arm, > > > > I would like to make INTRNG a requirement on armv6. This is to help > > with moving more armv6 kernel configurations into GENERIC. It also > > helps when we want a child interrupt controller, e.g. a GPIO driver. > > > > Most of the current armv6 kernel configurations already use INTRNG, so > > only a few places need to be updated. > > > > I’ve run a test build making it an error to not have INTRNG enabled and > > found the following armv6 configs fail: > > > > AML8726 > > ARMADAXP > > DIGI-CCWMX53 > > EFIKA_MX > > IMX53 > > IMX53-QSB > > VERSATILEPB > > YYHD18 > > > > I'm interested in people who have this hardware to try enabling INTRNG > > and testing. Note that this may require the interrupt controller driver > > the SoC uses to be ported to INTRNG. > > > > The following configs still need work. > > AML8726 > ARMADAXP > VERSATILEPB > YYHD18 > > John Where has promised patches for the AML8726 (that I would expect to work with YYHD18), but that still leaves the ARMADAXP and VERSATILEPB configs. > > If nobody cares about these we should remove them as there will be further updates and cleanups needed in the future and we need someone to test them on these platforms. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: fubar.geek.nz] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 17:48:09 -0000 Andrew Turner (andrew@fubar.geek.nz) wrote: > > > On 16 Mar 2017, at 17:08, Andrew Turner wrote: > > > > Hello arm, > > > > I would like to make INTRNG a requirement on armv6. This is to help > > with moving more armv6 kernel configurations into GENERIC. It also > > helps when we want a child interrupt controller, e.g. a GPIO driver. > > > > Most of the current armv6 kernel configurations already use INTRNG, so > > only a few places need to be updated. > > > > I’ve run a test build making it an error to not have INTRNG enabled and > > found the following armv6 configs fail: > > > > AML8726 > > ARMADAXP > > DIGI-CCWMX53 > > EFIKA_MX > > IMX53 > > IMX53-QSB > > VERSATILEPB > > YYHD18 > > > > I'm interested in people who have this hardware to try enabling INTRNG > > and testing. Note that this may require the interrupt controller driver > > the SoC uses to be ported to INTRNG. > > > > The following configs still need work. > > AML8726 > ARMADAXP > VERSATILEPB > YYHD18 > > John Where has promised patches for the AML8726 (that I would expect to work with YYHD18), but that still leaves the ARMADAXP and VERSATILEPB configs. > > If nobody cares about these we should remove them as there will be further updates and cleanups needed in the future and we need someone to test them on these platforms. VERSATILEPB is QEMU platform. I'll take a look at implementing INTRNG for it. -- gonzo From owner-freebsd-arm@freebsd.org Tue Mar 28 23:55:03 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15187D23374 for ; Tue, 28 Mar 2017 23:55:03 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A5CBB1B1E for ; Tue, 28 Mar 2017 23:55:02 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1490745298; l=3450; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=R7gU8SME0AaCmd6cSoGqm4ov0Y5AtVrmiquAnARPj50=; b=QP4Bl5Ml6iMtdpZ6lx//OiGtGuG3CQHKSrwjAeufHwUdQ8T3S2vjgD3uSs2al6zEjM 4nQykDJrMwkIvd+hmzvq3xVrTIADzc0r8Xn5JVwoyWYtVRD2Wrj4fkAy/2XiD5oNLP5n Pn5UBiQQbm2Q1s57up0F8YZMstKC46sl9zMiw= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGhIi99LnOZs= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02abf9.virtua.com.br [187.2.171.249]) by smtp.strato.de (RZmta 40.4 DYNA|AUTH) with ESMTPSA id 605bc6t2SNsv30I (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Wed, 29 Mar 2017 01:54:57 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 576EA7506DAD for ; Tue, 28 Mar 2017 20:54:54 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Enabling ADC on a Beaglebone Black running FreeBSD 12.0-CURRENT (BEAGLEBONE) From: "Dr. Rolf Jansen" In-Reply-To: <271AFD8F-BD2C-445C-AB95-D7D07593E487@obsigna.com> Date: Tue, 28 Mar 2017 20:54:52 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5D2FEB0D-64F3-488C-8458-85E7DF10EFB7@obsigna.com> References: <0C4DCBB9-2642-4B0F-B15B-4139D5D8B249@obsigna.com> <271AFD8F-BD2C-445C-AB95-D7D07593E487@obsigna.com> To: freebsd-arm@FreeBSD.org X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 23:55:03 -0000 Today I updated once again my Beaglebone Black by merging-in the latest = FreeBSD 12.0-CURRENT (BEAGLEBONE) snapshot, and once again I enabled the = ADCs on the Beaglebone in the device tree blob am335x-boneblack.dtb, and = the ADC is still working fine. Even if it is not that a big hassle to modify the device tree blob, I am = curious on why the ADC has been disabled in the blob in the first place, = end even more, given the fact that the device ti_adc driver is built-in = to kernel and once enabled, the ADC is functional. Didn't it work at some time in the past? Now it is. What is missing to activate the ADC in the device tree blob by default? Best regards Rolf Am 12.03.2017 um 18:38 schrieb Dr. Rolf Jansen : > The ADC is disabled in the respective device tree file = am335x-boneblack.dtb. In order to enable the it, I did: >=20 > 1. decompile the device tree blob (.dtb) into a device tree source = file (.dts): >=20 > cd /boot/dtb > dtc -I dtb -O dts am335x-boneblack.dtb > am335x-boneblack.dts >=20 >=20 > 2. edit the .dts file, and change the entry for tscadc to the = following: >=20 > tscadc@44e0d000 { > compatible =3D "ti,am3359-tscadc"; > reg =3D <0x44e0d000 0x1000>; > interrupt-parent =3D <0x1>; > interrupts =3D <0x10>; > ti,hwmods =3D "adc_tsc"; > status =3D "okay"; > dmas =3D <0x29 0x35 0x0 0x29 0x39 0x0>; > dma-names =3D "fifo0", "fifo1"; >=20 > tsc { > compatible =3D "ti,am3359-tsc"; > }; >=20 > adc { > #io-channel-cells =3D <0x1>; > compatible =3D "ti,am3359-adc"; > ti,adc-channels =3D <0 1 2 3 4 5 6>; > }; > }; >=20 > ActualLy I changed the status from "disabled" to "okay" and I added = the ti,adc-channels descriptor to the adc section. >=20 > 3. save the original DTB and compile the DTS: >=20 > mv am335x-boneblack.dtb am335x-boneblack.dtb.orig > dtc -O dtb -o am335x-boneblack.dtb -b 0 am335x-boneblack.dts >=20 > 4. restart >=20 > 5. check it: >=20 > sysctl dev.ti_adc > .... > dev.ti_adc.0.ain.6.input: 0 > dev.ti_adc.0.ain.6.samples_avg: 0 > dev.ti_adc.0.ain.6.open_delay: 0 > dev.ti_adc.0.ain.6.enable: 0 > dev.ti_adc.0.ain.5.input: 0 > dev.ti_adc.0.ain.5.samples_avg: 0 > dev.ti_adc.0.ain.5.open_delay: 0 > dev.ti_adc.0.ain.5.enable: 0 > dev.ti_adc.0.ain.4.input: 0 > dev.ti_adc.0.ain.4.samples_avg: 0 > dev.ti_adc.0.ain.4.open_delay: 0 > dev.ti_adc.0.ain.4.enable: 0 > dev.ti_adc.0.ain.3.input: 0 > dev.ti_adc.0.ain.3.samples_avg: 0 > dev.ti_adc.0.ain.3.open_delay: 0 > dev.ti_adc.0.ain.3.enable: 0 > dev.ti_adc.0.ain.2.input: 0 > dev.ti_adc.0.ain.2.samples_avg: 0 > dev.ti_adc.0.ain.2.open_delay: 0 > dev.ti_adc.0.ain.2.enable: 0 > dev.ti_adc.0.ain.1.input: 0 > dev.ti_adc.0.ain.1.samples_avg: 0 > dev.ti_adc.0.ain.1.open_delay: 0 > dev.ti_adc.0.ain.1.enable: 0 > dev.ti_adc.0.ain.0.input: 3071 > dev.ti_adc.0.ain.0.samples_avg: 0 > dev.ti_adc.0.ain.0.open_delay: 0 > dev.ti_adc.0.ain.0.enable: 1 > dev.ti_adc.0.clockdiv: 2400 > dev.ti_adc.0.%parent: simplebus0 > dev.ti_adc.0.%pnpinfo: name=3Dtscadc@44e0d000 = compat=3Dti,am3359-tscadc > dev.ti_adc.0.%location:=20 > dev.ti_adc.0.%driver: ti_adc > dev.ti_adc.0.%desc: TI ADC controller > dev.ti_adc.%parent:=20 >=20 > I can enable the ADC channels, and when connecting a 1002 mV DC source = to AIN0 the reading was 2279, which is perfectly in line with = 1002*4095/1800 =3D 2279.55. >=20 > Best regards >=20 > Rolf From owner-freebsd-arm@freebsd.org Wed Mar 29 00:30:52 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7EAAAD23E12 for ; Wed, 29 Mar 2017 00:30:52 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 498323281 for ; Wed, 29 Mar 2017 00:30:51 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v2T0Uur2041653 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Mar 2017 17:30:56 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v2T0UtpL041652; Tue, 28 Mar 2017 17:30:55 -0700 (PDT) (envelope-from fbsd) Date: Tue, 28 Mar 2017 17:30:55 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Uname -a no longer reports revision number on RPI2 Message-ID: <20170329003055.GA41615@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 00:30:52 -0000 I just noticed that uname no longer seems to report revision numbers on an RPI2 running 12 current. root@www:/usr/ports/www/firefox # uname -a FreeBSD www.zefox.com 12.0-CURRENT FreeBSD 12.0-CURRENT #22: Tue Mar 28 01:55:52 PDT 2017 bob@www.zefox.com:/usr/obj/usr/src/sys/RPI2 arm Is there a way to recover the old behavior? The man pages seem unchanged. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Wed Mar 29 00:47:35 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6DF5D1E227 for ; Wed, 29 Mar 2017 00:47:35 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 712253B32 for ; Wed, 29 Mar 2017 00:47:34 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id v2T0ZPkW089580 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Mar 2017 02:35:26 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id v2T0ZMnT005302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Mar 2017 02:35:22 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id v2T0ZLu3089780; Wed, 29 Mar 2017 02:35:21 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id v2T0ZKji089779; Wed, 29 Mar 2017 02:35:20 +0200 (CEST) (envelope-from ticso) Date: Wed, 29 Mar 2017 02:35:20 +0200 From: Bernd Walter To: bob prohaska Cc: freebsd-arm@freebsd.org Subject: Re: Uname -a no longer reports revision number on RPI2 Message-ID: <20170329003520.GD88450@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20170329003055.GA41615@www.zefox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170329003055.GA41615@www.zefox.net> X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-1.507 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 00:47:35 -0000 On Tue, Mar 28, 2017 at 05:30:55PM -0700, bob prohaska wrote: > I just noticed that uname no longer seems to report revision numbers on > an RPI2 running 12 current. > > > root@www:/usr/ports/www/firefox # uname -a > FreeBSD www.zefox.com 12.0-CURRENT FreeBSD 12.0-CURRENT #22: Tue Mar 28 01:55:52 PDT 2017 bob@www.zefox.com:/usr/obj/usr/src/sys/RPI2 arm > > > Is there a way to recover the old behavior? The man pages seem unchanged. The revision number uses svnversion on a subversion worktree. If you've got your source in any other way this can't work. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Wed Mar 29 00:52:43 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B40BD1E44E for ; Wed, 29 Mar 2017 00:52:43 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B62E3F3A for ; Wed, 29 Mar 2017 00:52:42 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v2T0ql5d041940 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Mar 2017 17:52:47 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v2T0qke3041939; Tue, 28 Mar 2017 17:52:46 -0700 (PDT) (envelope-from fbsd) Date: Tue, 28 Mar 2017 17:52:46 -0700 From: bob prohaska To: ticso@cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: Uname -a no longer reports revision number on RPI2 Message-ID: <20170329005245.GB41615@www.zefox.net> References: <20170329003055.GA41615@www.zefox.net> <20170329003520.GD88450@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170329003520.GD88450@cicely7.cicely.de> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 00:52:43 -0000 On Wed, Mar 29, 2017 at 02:35:20AM +0200, Bernd Walter wrote: > > The revision number uses svnversion on a subversion worktree. > If you've got your source in any other way this can't work. > > -- Ok, that makes sense, I started using svnup when svnlite stopped working: root@www:/usr # svnlite checkout https://svn.FreeBSD.org/base/head /usr/src svn: E175003: Attempt to fetch capability 'depth' resulted in 'yes' root@www:/usr # The error is identical, whether checkout out a new tree or just updating an existing one. I think the problem is a damaged config file, but I haven't found it. Thanks for reading, and any guidance! bob prohaska From owner-freebsd-arm@freebsd.org Wed Mar 29 06:11:58 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39CB7D23319; Wed, 29 Mar 2017 06:11:58 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE9DD67442; Wed, 29 Mar 2017 06:11:57 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: by mail-qk0-x231.google.com with SMTP id r142so4651744qke.2; Tue, 28 Mar 2017 23:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nTYPCuJs0lEF3GlEVhyQVX6O/kTafl4IKg4HomdkfXA=; b=sS6Mgx6fBeEdRIPtISGbe74uiAP/uswdxaKlffM3Wzuf9GfdzamHsxbAbGL04UzxQG uW8JTylaySDMZqOYGQL8eg2Uf3TsxDdQ3N4dwaecBOwgJL+/5M2hnVZOKwVbuYMDdhp/ VTHlds6IIK/b2cY/XRHxt6G4AngBroQE7a83zODjcNAKSldn7vUxBgYAeH+6EXiSI4co nU9wcgUQQsZjKXKbnI0J5YgDXbN5MFC5MjVG43l7Ot9Y2BjtH7OebMy50b+f2/LR+E8r X2MwXITdDqNiupevEvmmJdEzGOJhbLMP3TeAa1MQDlG2Y7m03210vZ4iule7RKQ6S+AY A9hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nTYPCuJs0lEF3GlEVhyQVX6O/kTafl4IKg4HomdkfXA=; b=o6a+jZUTNumbuOpbA7dLmPaiVozGHWqAJa18IU8Pb52TqZCqTXy6HhvR5e4p6BO8fG l7sTz9/fYA/fI8MXsu1So2+DmvW5SIcWXwJF15qN5/+LI8UT8xTV20ObJdFmbPKLL6CC gJ7p61zUSWM6nY3DckaUWxlFc7uP7jclJIDPFJPyTt/XUt6Elxr9LihPAd7L98QyCNq1 SqBwaluaNBwW3lKr7JpMQpts+CMNozC82bvBr7drD3EdfMw5oXC9CpNkuSH5xmoHxklO cSHgbTfVGyNfP80Vkwo5rh003OtqHzHu0OTn8vLLf6Qrsu2VleANHz2XsnL/HNfUpcPX lRpw== X-Gm-Message-State: AFeK/H2ahNvW5+zxGgk5kFInrIAZpR81sF+Wn0yL9RtAY648re7Xc2xTipCi3/mQqjACAk1/a+hHvIeZEWEsEw== X-Received: by 10.55.47.4 with SMTP id v4mr28565282qkh.77.1490767916809; Tue, 28 Mar 2017 23:11:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.38.146 with HTTP; Tue, 28 Mar 2017 23:11:56 -0700 (PDT) From: Shrikanth Kamath Date: Tue, 28 Mar 2017 23:11:56 -0700 Message-ID: Subject: ldscript.arm and elf section ordering To: freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 06:11:58 -0000 Have a question around the order in which symtab/strtab/shstrtab are placed for the elf binaries. Working with two different versions of the LLVM toolchain here in Juniper, so when building FreeBSD kernel with llvm 3.5 toolchain for arm (toolchain is published from sources internally) the sections shstrtab/symtab/strtab have offsets that are in increasing order (this is skimmed output from readelf) [Nr] Name Type Addr Off Size ES Flg Lk Inf Al ... [44] .shstrtab STRTAB 00000000 ede7f2 000283 00 0 0 1 [45] .symtab SYMTAB 00000000 edf1d0 05fc40 10 46 15427 4 [46] .strtab STRTAB 00000000 f3ee10 0834a2 00 0 0 1 When building with llvm 3.7 though the offsets do not appear to be in the expected order [40] .shstrtab STRTAB 00000000 10cbdaa 000229 00 0 0 1 [41] .symtab SYMTAB 00000000 fd0520 079de0 10 42 22109 4 [42] .strtab STRTAB 00000000 104a300 081aaa 00 0 0 1 the .shstrtab offset appears to be beyond section ".strtab" and ".symtab" but in terms of section ordering .shstrtab appears before symtab and strtab. Due to some design constraint I need to investigate if we can fix the .shstrtab beyond .symtab and .strtab, query to hackers is if this is an advisable thing to do? And how should the ldscript.arm be used to reorder this. Thanks, -- Shrikanth R K From owner-freebsd-arm@freebsd.org Wed Mar 29 17:45:08 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02310D23D6B for ; Wed, 29 Mar 2017 17:45:08 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BC19232F9 for ; Wed, 29 Mar 2017 17:45:07 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qt0-x22e.google.com with SMTP id x35so19142907qtc.2 for ; Wed, 29 Mar 2017 10:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=to:from:subject:message-id:date:user-agent:mime-version; bh=CRgubWfg84Er752akIsLUqNKxy4gAeW8GCNjgp2RdU4=; b=NBKz7cnPqYkX9KGGByKrI9PQGlbDtZzoxsZBBeVH/lEpErm//S8wfZ9oxFFbmtUNu2 nLNje0hSzkvT9EDlIxXXmJ+t9QnudgBUUphgt9U+fxnPwNN0xpOjyXcEaXV6dLsyUlgj u+wqoNbpxhAV3NStVToTehXeqK/LPYIfyhXuI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=CRgubWfg84Er752akIsLUqNKxy4gAeW8GCNjgp2RdU4=; b=J+O5vmM+CgYaErQPmLtsaI7zpoJzv4jxM605hPxLGHF0wZmgpjuKQDPyuLMRtrKNEm HYUY4nBb/sX93a3zopx1Q9d4bs+zcjyyvG0Qyi5ZvV+shuhGS5mxvkA88BEScyog+rc2 p6aU+vsx0PhWw4/nL/vweCMLXcRGber/Y3SDxudvaXPKKfN9sy4IdVtd6ROc1Q4nxTN5 ac5WuSygT2ZzxCWRMvnjH3S1zbyWAFmOg5qtRYCqocWQNxkkrE0BwXpK8yS5DDjzjzPX 47GYmRmQ1wGaKjjWMXa4pSj7kGOAM+8M2uI/VvezohEr6cOmpU0BLSlD6pQftYIZ395A oyew== X-Gm-Message-State: AFeK/H2bX+z1DkOcYvjESnh2uUXq8oB8nkxgqzzzuetI/0k2+SG3EQ6x02LXIlji0BNHhQ== X-Received: by 10.200.39.136 with SMTP id w8mr1898939qtw.284.1490809506444; Wed, 29 Mar 2017 10:45:06 -0700 (PDT) Received: from [10.51.220.177] ([177.20.152.129]) by smtp.googlemail.com with ESMTPSA id k4sm5363023qta.5.2017.03.29.10.45.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 10:45:05 -0700 (PDT) To: "freebsd-arm@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= Subject: gcc for aarch64 Message-ID: <5eb49766-e5af-d89f-b4f6-a0d655a3859a@bsd.com.br> Date: Wed, 29 Mar 2017 14:44:58 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 17:45:08 -0000 Dear, is anyone using gcc in aarch64 architecture? The last time I tried to compile the gcc I received a message that the architecture was not supported. []'s -Otacilio From owner-freebsd-arm@freebsd.org Wed Mar 29 18:22:04 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48273D247C7 for ; Wed, 29 Mar 2017 18:22:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0EA5532FB for ; Wed, 29 Mar 2017 18:22:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x235.google.com with SMTP id 190so61677761itm.0 for ; Wed, 29 Mar 2017 11:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=ot086LhtLHnk/Ubo3UKmWQ70jIEIaXLqMK367wAut70=; b=uWeBMS9gxQKOWuk1EzhgW4CoL0zgwaV7gTwX2ARvbq4bItvrW5oo3TcEWIfmchorRb tshA19jFde2j/Ch1Tt/uy335lZMX279+p9uYoVkkyQj2M067jcnrBe8X2p6JvtcxT/IV pvvNsDhU+zTSa9iYzcN4JTRjpHoE9J9OI2tBbo0kJXbs+Oyo8C7eVdufQLC4xgrT6lyX Lvm9YKMQrVxPgQGhzQrA3fZWGvbqk1GwKIiv7ElQiCftxX/dSnG7+k2xmbJzK6vOM/In RDMGRQsgpitN4zeZ9EnD+WsRa1YEKuQiEg4mSoosdi2z9No03KV5Vp34uRdSM/7S9Su8 oL9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=ot086LhtLHnk/Ubo3UKmWQ70jIEIaXLqMK367wAut70=; b=G2AWxw6XII30EuHlnHILnSPjHFSf25O4I87yGwWk58OQsXryYm7biWL72Ec7+LhLiz QkiA12ZNSrhPQor94o7l/NGz3XiHweA4Daq4v5LsKSo93Y2FzHlcbiA8lTG3rHxm2xVR q6Pu1Vei7E2s6xWA+q6VK0hQNAq6F2hyesvBym0uFqyXObQ3exLxTvNnM1O+NEXLyegI NBu+2oOj53eGv1V9pvrRiSKRkBalx9cUymFhZ4p1Au0SuZ1tZDErWINPMW5oCyFObuIV qCx+Cjkb9yyO3SpKBBRRLJRbVxWJpQjieTtEYWPFcA3HRHl66h8bzShW1Ge2Hd3Os59E J38A== X-Gm-Message-State: AFeK/H3ZgEVn7FRZfJLKPdlMuQZYSOU4bLsAcse21PRZwTmPM7D3xJ0XCtzo0nHJCBXOoch+mIUPsVyxV9V8GA== X-Received: by 10.36.76.11 with SMTP id a11mr2822815itb.60.1490811723323; Wed, 29 Mar 2017 11:22:03 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.146.24 with HTTP; Wed, 29 Mar 2017 11:22:02 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:a045:c633:4156:d07c] In-Reply-To: <5eb49766-e5af-d89f-b4f6-a0d655a3859a@bsd.com.br> References: <5eb49766-e5af-d89f-b4f6-a0d655a3859a@bsd.com.br> From: Warner Losh Date: Wed, 29 Mar 2017 12:22:02 -0600 X-Google-Sender-Auth: pY3uDfUxEhxpJcE2szKOj1Bf8i4 Message-ID: Subject: Re: gcc for aarch64 To: =?UTF-8?B?T3RhY8OtbGlv?= Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 18:22:04 -0000 The in-tree gcc compiler doesn't have any aarch64 support. Out of tree ones should be supported though. Or at least it should be possible to try to build and see what blows up... Most developers use clang on aarch64, so there's bound to be a few surprises. Warner On Wed, Mar 29, 2017 at 11:44 AM, Otac=C3=ADlio = wrote: > Dear, is anyone using gcc in aarch64 architecture? The last time I tried = to > compile the gcc I received a message that the architecture was not > supported. > > []'s > > -Otacilio > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Wed Mar 29 18:26:11 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CACF2D24840 for ; Wed, 29 Mar 2017 18:26:11 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (smtp.fgznet.ch [IPv6:2001:4060:1:1001::14:52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 91F533566 for ; Wed, 29 Mar 2017 18:26:11 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from [192.168.225.14] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by fgznet.ch (Postfix) with ESMTPSA id 067FBC6F58; Wed, 29 Mar 2017 20:25:59 +0200 (CEST) Subject: Re: gcc for aarch64 To: Warner Losh , =?UTF-8?B?T3RhY8OtbGlv?= References: <5eb49766-e5af-d89f-b4f6-a0d655a3859a@bsd.com.br> Cc: "freebsd-arm@freebsd.org" From: Andreas Tobler Message-ID: <43c04670-4913-325f-98ff-ab5502afa0a2@fgznet.ch> Date: Wed, 29 Mar 2017 20:26:35 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: Obelix Submit on 127.0.1.1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 18:26:11 -0000 On 29.03.17 20:22, Warner Losh wrote: > The in-tree gcc compiler doesn't have any aarch64 support. Out of tree > ones should be supported though. Or at least it should be possible to > try to build and see what blows up... Most developers use clang on > aarch64, so there's bound to be a few surprises. > > Warner > > On Wed, Mar 29, 2017 at 11:44 AM, Otacílio wrote: >> Dear, is anyone using gcc in aarch64 architecture? The last time I tried to >> compile the gcc I received a message that the architecture was not >> supported. [pine64:~] andreast% pkg info |grep gcc gcc5-devel-5.4.1.s20170321 GNU Compiler Collection 5 gcc6-devel-6.3.1.s20170323 GNU Compiler Collection 6 gcc7-devel-7.0.1.s20170319 GNU Compiler Collection 7 Also release gcc5 and gcc6 are supported. Everything is in gcc trunk, gcc6 and gcc5 branch too. gcc49 is not supported. We hopefully will switch soon lang/gcc from gcc4.9.4 to gcc5.4.1 Andreas From owner-freebsd-arm@freebsd.org Wed Mar 29 18:26:35 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 397C5D24872 for ; Wed, 29 Mar 2017 18:26:35 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E7FC135D6 for ; Wed, 29 Mar 2017 18:26:34 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x230.google.com with SMTP id p22so20617647qka.3 for ; Wed, 29 Mar 2017 11:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:references:cc:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=MvGnlY6J815W3QjeLOOerFDbGCf/2LMFe4S4O8QodSc=; b=GZc+Trz3n8tmScG9HPJc48Hrw6LRXxhcdATBnsWXdru28hsVEhSDbD30yzfIRU7pX3 ytb6EtEhPYHyOdrSKOynroH45ijPhVpcSQGMfZv8IEU7BCmZdC3xcDvuj5OZVBwCRM05 xWDvNQRV97Fxf0Z2N57Nl5KFgKt/YdxO/4IeA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:cc:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=MvGnlY6J815W3QjeLOOerFDbGCf/2LMFe4S4O8QodSc=; b=BZF0O6S/Z/+AXHp/8ibs10mHCPlHN43bxOeBjx2K8e3tjt0EnGpc8QABEdRfF2CIi1 0a1tEmBob1E1yC0EzD6ds+4pyIDEOwp1tVGrjcx1b7oGQ7dO0YiRVnD2gvQwmhK3iHub BxN4WOLoEAjrWJavNUzlyMMAS9Tco/Ii5mWmkiNSS5NZCmqn1+uMpFnb/5NrIRcFK+qf 96T5XHXO/RL+eQrJaPG/Pk2jOwr735WUGx2Ff24HJDYbJvNSLKZ8CUn4cxd2O9INb18p i+JpEQGuQNP2uzPweSeioVQaMrrlsxpsYsaOXWnMUHZu2yyAS2MOgoi2TVOud4BxgHbi JHdg== X-Gm-Message-State: AFeK/H1Pc207tu3U8iGaKMrm2IDKyto/lXgbI24GGf0VcKrpFd17SdZqm4Z5uak+vFnwJw== X-Received: by 10.55.198.149 with SMTP id s21mr1837331qkl.24.1490811993733; Wed, 29 Mar 2017 11:26:33 -0700 (PDT) Received: from [192.168.43.219] (179-240-134-47.3g.claro.net.br. [179.240.134.47]) by smtp.googlemail.com with ESMTPSA id c6sm5422379qte.30.2017.03.29.11.26.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 11:26:33 -0700 (PDT) Subject: Re: gcc for aarch64 References: <5eb49766-e5af-d89f-b4f6-a0d655a3859a@bsd.com.br> Cc: "freebsd-arm@freebsd.org" To: Warner Losh From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: Date: Wed, 29 Mar 2017 15:26:25 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 18:26:35 -0000 For me, the problem is that I need the Fortran compiler and so far I know this is available only by GCC. Thanks a lot []'s -Otacilio Em 29/03/2017 15:22, Warner Losh escreveu: > The in-tree gcc compiler doesn't have any aarch64 support. Out of tree > ones should be supported though. Or at least it should be possible to > try to build and see what blows up... Most developers use clang on > aarch64, so there's bound to be a few surprises. > > Warner > > On Wed, Mar 29, 2017 at 11:44 AM, Otacílio wrote: >> Dear, is anyone using gcc in aarch64 architecture? The last time I tried to >> compile the gcc I received a message that the architecture was not >> supported. >> >> []'s >> >> -Otacilio >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Wed Mar 29 18:30:31 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96494D2497C for ; Wed, 29 Mar 2017 18:30:31 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 50444386C for ; Wed, 29 Mar 2017 18:30:31 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qt0-x229.google.com with SMTP id n21so20343400qta.1 for ; Wed, 29 Mar 2017 11:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=pIYkbktBC0RuPJ8dOTKtmdz89JJDpV+6IAXHv7n+s/Q=; b=UmWjPpk0oZ2LcW4vDX8tiVF34NcNaAqfZn1Ab7kKud/cjlYt3zSCbTylYCiY0oWcYQ ic0tC/D0n1mUjR8scawgu+r4F2qJGoGg8VaJCZa5l9fFW4jQbJLgmWq/dBJK6D/esAlV b1Fy7p+dOh5jC8DMp20riQIXc7IZynqEbuYUs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=pIYkbktBC0RuPJ8dOTKtmdz89JJDpV+6IAXHv7n+s/Q=; b=iIeFozq5Ou0g51e8UM4rFGYrwtH90dbQONcdnY6x0B69fE9OqukmcL+gr4c1qxifQn oorok9qqSRlV/8dAtdycODHUV34nk2yvDiqK1t3A57mZq7w9rCxqCw5NR9cfWAOFCFQF NtPsCZ7R9smcFfMeiQWJ/KrM6GoHTlP3nkM9M3HqtnCIy3ROK3BHFUVR9SFbM6vXA6iY 7Wlk0na3Vy7HdxKK2r7A0hkRMKckZuCcPSbZYt8xBJAjFGsnKCHHQuPldY4LaNxM7mIE JZVRJe5cruVKxgZYqiW87vwZgyyE5w1TF/yVIX/ylhb5yAtbb5lrZw/O1VCs3EdDvFM/ BTzA== X-Gm-Message-State: AFeK/H3FI8o4zJ8OGGSNkcBe52vLEeBgZgwerqgIVaZfXKG5hubIQQDNuRuQvEcrpG/nhw== X-Received: by 10.200.54.247 with SMTP id b52mr2079316qtc.160.1490812230090; Wed, 29 Mar 2017 11:30:30 -0700 (PDT) Received: from [192.168.43.219] (179-240-134-47.3g.claro.net.br. [179.240.134.47]) by smtp.googlemail.com with ESMTPSA id k51sm5426196qtf.31.2017.03.29.11.30.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 11:30:29 -0700 (PDT) Subject: Re: gcc for aarch64 To: Andreas Tobler References: <5eb49766-e5af-d89f-b4f6-a0d655a3859a@bsd.com.br> <43c04670-4913-325f-98ff-ab5502afa0a2@fgznet.ch> Cc: "freebsd-arm@freebsd.org" From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: Date: Wed, 29 Mar 2017 15:30:22 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <43c04670-4913-325f-98ff-ab5502afa0a2@fgznet.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 18:30:31 -0000 Em 29/03/2017 15:26, Andreas Tobler escreveu: > On 29.03.17 20:22, Warner Losh wrote: >> The in-tree gcc compiler doesn't have any aarch64 support. Out of tree >> ones should be supported though. Or at least it should be possible to >> try to build and see what blows up... Most developers use clang on >> aarch64, so there's bound to be a few surprises. >> >> Warner >> >> On Wed, Mar 29, 2017 at 11:44 AM, Otacílio >> wrote: >>> Dear, is anyone using gcc in aarch64 architecture? The last time I >>> tried to >>> compile the gcc I received a message that the architecture was not >>> supported. > > [pine64:~] andreast% pkg info |grep gcc > gcc5-devel-5.4.1.s20170321 GNU Compiler Collection 5 > gcc6-devel-6.3.1.s20170323 GNU Compiler Collection 6 > gcc7-devel-7.0.1.s20170319 GNU Compiler Collection 7 > > Also release gcc5 and gcc6 are supported. > > Everything is in gcc trunk, gcc6 and gcc5 branch too. > > gcc49 is not supported. We hopefully will switch soon lang/gcc from > gcc4.9.4 to gcc5.4.1 > > Andreas > Thank you by your hint. I was trying only with lang/gcc because I supposed that this version was the one with the best support. []'s -Otacilio From owner-freebsd-arm@freebsd.org Thu Mar 30 00:09:30 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8FA3D23156 for ; Thu, 30 Mar 2017 00:09:30 +0000 (UTC) (envelope-from ash@aeria.net) Received: from death.aeria.net (death.aeria.net [205.134.176.45]) by mx1.freebsd.org (Postfix) with ESMTP id 9CCD1E36 for ; Thu, 30 Mar 2017 00:09:29 +0000 (UTC) (envelope-from ash@aeria.net) X-Comment: SPF not applicable to localhost connection - skipped check Received: from localhost (localhost [127.0.0.1]) by death.aeria.net (Postfix) with ESMTP id 4E3244E658 for ; Thu, 30 Mar 2017 00:04:47 +0000 (UTC) From: ash To: Subject: BBB SPI port config ofw,dts question Date: Thu, 30 Mar 2017 00:03:40 +0000 MIME-Version: 1.0 Message-ID: Organization: aeria User-Agent: Trojita Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 00:09:30 -0000 I'd like to mate an SPI flash for my lattice iCE fpga's directly to the spi=20= port on the BBB. I'm having difficulty driving the ofw/dts/devtree . =20 I've crocheted an install; and it's stable enough to boot, network and=20 mount nfs.=20 root@beaglebone:~ # uname -a FreeBSD beaglebone 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r315282: Tue Mar 14=20= 21:06:39 UTC 2017 =20 root@kaylee.dyn.aeria.net:/dozer/bbone/crochet/work/obj/arm.armv6/usr/12heads= rc/sys/BEAGLEBONE=20 arm I see that the spi peripherals are in the dts via: root@beaglebone:~ # ofwdump -a | grep spi Node 0x5eb4: spinlock@480ca000 Node 0x67ac: spi@48030000 Node 0x68d8: spi@481a0000 How do I instruct the fdt machinery to 'instantiate' an spi channel, associate cs pins and see what spi flash i/o options are=20 already in the tree. =20 The config.txt documentation has so far evaded me.=20 This helped a bit, but that heavy lifting has been done a is in CURRENT +=20 crochet https://wiki.freebsd.org/FlattenedDeviceTree I'd like to use one of these common spi devices at the end of the day:=20 SST25VF512A-33-4C-SAE S25FL116K0XMFI041 N25Q128A13ESE40E http://www.mouser.com/Search/ProductDetail.aspx?R=3DSST25VF512A-33-4C-SAEvirt= ualkey57940000virtualkey804-25VF512A3CSAE http://www.mouser.com/Search/ProductDetail.aspx?R=3DS25FL116K0XMFI041virtualk= ey66850000virtualkey797-25FL116KOXMFI041 http://www.digikey.com/product-detail/en/N25Q128A13ESE40E/557-1562-ND/3874288= Given the spigen code, am I going to be writing a kernel module or is are=20 there enough userland tools to manage? Is there some sample code that does=20= this? --=20 -ash From owner-freebsd-arm@freebsd.org Thu Mar 30 19:11:51 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B5C5D2601D for ; Thu, 30 Mar 2017 19:11:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0AE2F615 for ; Thu, 30 Mar 2017 19:11:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2UJBo66051623 for ; Thu, 30 Mar 2017 19:11:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 218236] image for RPI2 does not boot on "Raspberry Pi 2 Model B V1.2" (rainbow screen) Date: Thu, 30 Mar 2017 19:11:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: lothar.linhard@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 19:11:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218236 Bug ID: 218236 Summary: image for RPI2 does not boot on "Raspberry Pi 2 Model B V1.2" (rainbow screen) Product: Base System Version: 11.0-STABLE Hardware: arm OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: lothar.linhard@gmail.com I tested ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/FreeBSD-11.0-ST= ABLE-arm-armv6-RPI2-20170323-r315855.img.xz and ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/11.0/FreeBSD-11.0-REL= EASE-arm-armv6-RPI2.img.xz both work fine on "Raspberry Pi 2 Model B V1.1" but not on "Raspberry Pi 2 Model B V1.2" (however V1.2 boots ok with 2017-03-02-raspbian-jessie-lite.i= mg). With the FreeBSD-11 image the V1.2 stocks with the rainbow color screen. ------ Also (but unrelated): there is no RPI2 image for the CURRENT FreeBSD-12.0. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Thu Mar 30 20:29:03 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42C73D26FA9 for ; Thu, 30 Mar 2017 20:29:03 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 24110BAB for ; Thu, 30 Mar 2017 20:29:02 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1ctggl-0005rO-Ax; Thu, 30 Mar 2017 13:29:00 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v2UKSwcu022529; Thu, 30 Mar 2017 13:28:58 -0700 (PDT) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Thu, 30 Mar 2017 13:28:58 -0700 From: Oleksandr Tymoshenko To: "Dr. Rolf Jansen" Cc: freebsd-arm@FreeBSD.org Subject: Re: Enabling ADC on a Beaglebone Black running FreeBSD 12.0-CURRENT (BEAGLEBONE) Message-ID: <20170330202858.GA22253@bluezbox.com> References: <0C4DCBB9-2642-4B0F-B15B-4139D5D8B249@obsigna.com> <271AFD8F-BD2C-445C-AB95-D7D07593E487@obsigna.com> <5D2FEB0D-64F3-488C-8458-85E7DF10EFB7@obsigna.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D2FEB0D-64F3-488C-8458-85E7DF10EFB7@obsigna.com> X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Dr. Rolf Jansen (rj@obsigna.com) wrote: > Today I updated once again my Beaglebone Black by > merging-in the latest FreeBSD 12.0-CURRENT (BEAGLEBONE) > snapshot, and once again I enabled the ADCs on the > Beaglebone in the device tree blob am335x-boneblack.dtb, > and the ADC is still working fine. > > Even if it is not that a big hassle to modify the device > tree blob, I am curious on why the ADC has been disabled > in the blob in the first place, end even more, given the > fact that the device ti_adc driver is built-in to kernel > and once enabled, the ADC is functional. > > Didn't it work at some time in the past? Now it is. > > What is missing to activate the ADC in the device tree > blob by default? [...] 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] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 20:29:03 -0000 Dr. Rolf Jansen (rj@obsigna.com) wrote: > Today I updated once again my Beaglebone Black by > merging-in the latest FreeBSD 12.0-CURRENT (BEAGLEBONE) > snapshot, and once again I enabled the ADCs on the > Beaglebone in the device tree blob am335x-boneblack.dtb, > and the ADC is still working fine. > > Even if it is not that a big hassle to modify the device > tree blob, I am curious on why the ADC has been disabled > in the blob in the first place, end even more, given the > fact that the device ti_adc driver is built-in to kernel > and once enabled, the ADC is functional. > > Didn't it work at some time in the past? Now it is. > > What is missing to activate the ADC in the device tree > blob by default? Few months ago FreeBSD switched to using upstream DTB files instead of custom-made ones. For some reason ADC is disabled in upstream. If you're running recent FreeBSD you can use dtb overlays to enable ADC without hassle of maintaining custom dts file. You can do following: 1. Create am335x-beaglebone-tscadc.dts with following content: /dts-v1/; /plugin/; / { compatible = "ti,am335x-bone-green", "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx"; fragment@0 { target = <&tscadc>; __overlay__ { status = "okay"; adc { ti,adc-channels = <0 1 2 3 4 5 6>; }; }; }; }; 2. Compile overlay: $ dtc -I dts -O dtb -o am335x-beaglebone-tscadc.dtbo am335x-beaglebone-tscadc.dts 3. Copy it to /boot/dtb/ directory on your BBB 4. Enable overlay in /boot/loader.conf by adding following line: fdt_overlays="am335x-beaglebone-tscadc.dtbo" -- gonzo From owner-freebsd-arm@freebsd.org Thu Mar 30 20:42:20 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 57296D2641B for ; Thu, 30 Mar 2017 20:42:20 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C4843667 for ; Thu, 30 Mar 2017 20:42:18 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id b0d976a2 for ; Thu, 30 Mar 2017 22:35:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=bvYCzXTi09Sf aUAMS+4C9inVT8g=; b=DIXwqakRWhSIxjzvt0TMySuASP2/zOgum4TXZFNoFD1/ nnxNIQ1qmQxuNlYiWmNxDivd1qavdXWDWE2/u9OCImAhly1bmpAWkJWUtO6zgv5X sS1ZYqH5axwErR6ofzplisDB49rMzxKhUHBq/UX53vzXzExGEktNNk2w9ZKH1Uk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=ZXrGFM F3lCDcRnoiL2xfY9blYh9UAEuB+ILpvXKFZIzT05qISNF7HNpaZszh7NlnMez1ns MT6Cs7Aw2mQ29vkvaSnuJTD3tqcsrYjoXSVwKaRK0nlg12blgnYPqlkUE5ZJQ6wC ocPBKuXIan2enyTuvGsI+ekbF9Qa+G+CkpyLE= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id a490b61b TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO for ; Thu, 30 Mar 2017 22:35:35 +0200 (CEST) Date: Thu, 30 Mar 2017 22:35:34 +0200 From: Emmanuel Vadot To: freebsd-arm@freebsd.org Subject: Re: Enabling ADC on a Beaglebone Black running FreeBSD 12.0-CURRENT (BEAGLEBONE) Message-Id: <20170330223534.0ccc82eec0bf820651604cd7@bidouilliste.com> In-Reply-To: <20170330202858.GA22253@bluezbox.com> References: <0C4DCBB9-2642-4B0F-B15B-4139D5D8B249@obsigna.com> <271AFD8F-BD2C-445C-AB95-D7D07593E487@obsigna.com> <5D2FEB0D-64F3-488C-8458-85E7DF10EFB7@obsigna.com> <20170330202858.GA22253@bluezbox.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.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.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 20:42:20 -0000 On Thu, 30 Mar 2017 13:28:58 -0700 Oleksandr Tymoshenko wrote: > Dr. Rolf Jansen (rj@obsigna.com) wrote: > > Today I updated once again my Beaglebone Black by > > merging-in the latest FreeBSD 12.0-CURRENT (BEAGLEBONE) > > snapshot, and once again I enabled the ADCs on the > > Beaglebone in the device tree blob am335x-boneblack.dtb, > > and the ADC is still working fine. > > > > Even if it is not that a big hassle to modify the device > > tree blob, I am curious on why the ADC has been disabled > > in the blob in the first place, end even more, given the > > fact that the device ti_adc driver is built-in to kernel > > and once enabled, the ADC is functional. > > > > Didn't it work at some time in the past? Now it is. > > > > What is missing to activate the ADC in the device tree > > blob by default? > > Few months ago FreeBSD switched to using upstream DTB files > instead of custom-made ones. For some reason ADC is disabled > in upstream. If you're running recent FreeBSD you can use > dtb overlays to enable ADC without hassle of maintaining > custom dts file. You can do following: > > 1. Create am335x-beaglebone-tscadc.dts with following > content: > > /dts-v1/; > /plugin/; > > / { > compatible = "ti,am335x-bone-green", "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx"; > > fragment@0 { > target = <&tscadc>; > __overlay__ { > status = "okay"; > adc { > ti,adc-channels = <0 1 2 3 4 5 6>; > }; > }; > }; > }; > > 2. Compile overlay: > $ dtc -I dts -O dtb -o am335x-beaglebone-tscadc.dtbo am335x-beaglebone-tscadc.dts > > 3. Copy it to /boot/dtb/ directory on your BBB > > 4. Enable overlay in /boot/loader.conf by adding following line: > > fdt_overlays="am335x-beaglebone-tscadc.dtbo" > > -- > gonzo I guess that ADC uses pins that can be used for other purpose so they didn't enabled it by default ? If it's not the case they should be enable by default. Note 1 : You need to use a recent dtc (i.e. the latest dtc imported in HEAD) Note 2 : We really need to add some dtbo facility for people in the buildkernel process. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Mar 30 21:11:43 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA7E3D24589 for ; Thu, 30 Mar 2017 21:11:43 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 55918320 for ; Thu, 30 Mar 2017 21:11:42 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1490908299; l=2022; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=sigTRtfhSQMPHAYJQEUduFKiR1OKgWaJPRg1mQFWKEQ=; b=dkNFygDvNl1sEiiOr4BM7RJG6MD+oCd9fcFO1CSgWKUKN2X9x0iCMgeVUtpFhrto5+ Q4PZbGGFyMPWd19Du2WFkcV1W0NOgeuv7B35goVMK4fWdO75z9pls6CKT+coU9pSVJ9V DG0bGO1jakk896h2VNqXtU6eMjAopx0BMvH6c= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGh0i99LiI4M= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b5db.virtua.com.br [187.2.181.219]) by smtp.strato.de (RZmta 40.4 DYNA|AUTH) with ESMTPSA id 60bc88t2ULBcPHf (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Thu, 30 Mar 2017 23:11:38 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 7F3ED7506DAD for ; Thu, 30 Mar 2017 18:11:35 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Enabling ADC on a Beaglebone Black running FreeBSD 12.0-CURRENT (BEAGLEBONE) From: "Dr. Rolf Jansen" In-Reply-To: <20170330202858.GA22253@bluezbox.com> Date: Thu, 30 Mar 2017 18:11:33 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <79EE9798-BCF0-4585-93F5-4E604142561F@obsigna.com> References: <0C4DCBB9-2642-4B0F-B15B-4139D5D8B249@obsigna.com> <271AFD8F-BD2C-445C-AB95-D7D07593E487@obsigna.com> <5D2FEB0D-64F3-488C-8458-85E7DF10EFB7@obsigna.com> <20170330202858.GA22253@bluezbox.com> To: freebsd-arm@FreeBSD.org X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 21:11:43 -0000 Am 30.03.2017 um 17:28 schrieb Oleksandr Tymoshenko = : > Dr. Rolf Jansen (rj@obsigna.com) wrote: >> Today I updated once again my Beaglebone Black by >> merging-in the latest FreeBSD 12.0-CURRENT (BEAGLEBONE) >> snapshot, and once again I enabled the ADCs on the >> Beaglebone in the device tree blob am335x-boneblack.dtb, >> and the ADC is still working fine. >>=20 >> Even if it is not that a big hassle to modify the device >> tree blob, I am curious on why the ADC has been disabled >> in the blob in the first place, end even more, given the >> fact that the device ti_adc driver is built-in to kernel >> and once enabled, the ADC is functional. >>=20 >> Didn't it work at some time in the past? Now it is. >>=20 >> What is missing to activate the ADC in the device tree >> blob by default? >=20 > Few months ago FreeBSD switched to using upstream DTB files > instead of custom-made ones. For some reason ADC is disabled > in upstream. If you're running recent FreeBSD you can use > dtb overlays to enable ADC without hassle of maintaining > custom dts file. You can do following: >=20 > 1. Create am335x-beaglebone-tscadc.dts with following > content: >=20 > /dts-v1/; > /plugin/; >=20 > / { > compatible =3D "ti,am335x-bone-green", "ti,am335x-bone-black", = "ti,am335x-bone", "ti,am33xx"; >=20 > fragment@0 { > target =3D <&tscadc>; > __overlay__ { > status =3D "okay"; > adc { > ti,adc-channels =3D <0 1 2 3 4 5 6>; > }; > }; > }; > }; >=20 > 2. Compile overlay: > $ dtc -I dts -O dtb -o am335x-beaglebone-tscadc.dtbo = am335x-beaglebone-tscadc.dts >=20 > 3. Copy it to /boot/dtb/ directory on your BBB >=20 > 4. Enable overlay in /boot/loader.conf by adding following line: >=20 > fdt_overlays=3D"am335x-beaglebone-tscadc.dtbo" Oleksandr, thank you very much for drawing my attention to the dtb = overlay facility. I created and enabled the adc-dtb-overlay file as you explained above, = and it works. Best regards Rolf From owner-freebsd-arm@freebsd.org Thu Mar 30 21:27:18 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75554D24B04 for ; Thu, 30 Mar 2017 21:27:18 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 12ABDFB7 for ; Thu, 30 Mar 2017 21:27:17 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1490909235; l=2698; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=muWCnLQXnNC12Lrj5kfW3IYWHvD6qLCOClNkoJE2f54=; b=HPhdj2TCQbanvbnQ2orcIcVScFzXd2gXEHuRd9uGyV9fMio0u/AnfMvwiW6iW8MESu 07t9cgB0UQt8UZ85zzCrKv/iiC+tUXTzZzY7RQDIMX6toywZE/QBybkjrJbyDKfKhtaz ++3p38sUjNcf9sNN3FgVX1qpiCVpX8W+wCiUY= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGh0i99LiI4M= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b5db.virtua.com.br [187.2.181.219]) by smtp.strato.de (RZmta 40.4 DYNA|AUTH) with ESMTPSA id d06a02t2ULRFNRx (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Thu, 30 Mar 2017 23:27:15 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id C83C17506DAD; Thu, 30 Mar 2017 18:27:12 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Enabling ADC on a Beaglebone Black running FreeBSD 12.0-CURRENT (BEAGLEBONE) From: "Dr. Rolf Jansen" In-Reply-To: <20170330223534.0ccc82eec0bf820651604cd7@bidouilliste.com> Date: Thu, 30 Mar 2017 18:27:11 -0300 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <0C4DCBB9-2642-4B0F-B15B-4139D5D8B249@obsigna.com> <271AFD8F-BD2C-445C-AB95-D7D07593E487@obsigna.com> <5D2FEB0D-64F3-488C-8458-85E7DF10EFB7@obsigna.com> <20170330202858.GA22253@bluezbox.com> <20170330223534.0ccc82eec0bf820651604cd7@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 21:27:18 -0000 Am 30.03.2017 um 17:35 schrieb Emmanuel Vadot : > On Thu, 30 Mar 2017 13:28:58 -0700 > Oleksandr Tymoshenko wrote: >=20 >> Dr. Rolf Jansen (rj@obsigna.com) wrote: >>> Today I updated once again my Beaglebone Black by >>> merging-in the latest FreeBSD 12.0-CURRENT (BEAGLEBONE) >>> snapshot, and once again I enabled the ADCs on the >>> Beaglebone in the device tree blob am335x-boneblack.dtb, >>> and the ADC is still working fine. >>>=20 >>> Even if it is not that a big hassle to modify the device >>> tree blob, I am curious on why the ADC has been disabled >>> in the blob in the first place, end even more, given the >>> fact that the device ti_adc driver is built-in to kernel >>> and once enabled, the ADC is functional. >>>=20 >>> Didn't it work at some time in the past? Now it is. >>>=20 >>> What is missing to activate the ADC in the device tree >>> blob by default? >>=20 >> Few months ago FreeBSD switched to using upstream DTB files >> instead of custom-made ones. For some reason ADC is disabled >> in upstream. If you're running recent FreeBSD you can use >> dtb overlays to enable ADC without hassle of maintaining >> custom dts file. You can do following: >>=20 >> 1. Create am335x-beaglebone-tscadc.dts with following >> content: >>=20 >> /dts-v1/; >> /plugin/; >>=20 >> / { >> compatible =3D "ti,am335x-bone-green", "ti,am335x-bone-black", = "ti,am335x-bone", "ti,am33xx"; >>=20 >> fragment@0 { >> target =3D <&tscadc>; >> __overlay__ { >> status =3D "okay"; >> adc { >> ti,adc-channels =3D <0 1 2 3 4 5 6>; >> }; >> }; >> }; >> }; >>=20 >> 2. Compile overlay: >> $ dtc -I dts -O dtb -o am335x-beaglebone-tscadc.dtbo = am335x-beaglebone-tscadc.dts >>=20 >> 3. Copy it to /boot/dtb/ directory on your BBB >>=20 >> 4. Enable overlay in /boot/loader.conf by adding following line: >>=20 >> fdt_overlays=3D"am335x-beaglebone-tscadc.dtbo" >>=20 >> --=20 >> gonzo >=20 > I guess that ADC uses pins that can be used for other purpose so they > didn't enabled it by default ? If it's not the case they should be > enable by default. AFAIK, the ADC pins are dedicated ones. See here: http://beagleboard.org/support/bone101 In every pinout scheme for the different programmable modes, the ADC = pins are shown invariably at the same positions.=20 > Note 1 : You need to use a recent dtc (i.e. the latest dtc imported in = HEAD) I use the latest one which came with the FreeBSD 12.0-CURRENT = (BEAGLEBONE) snapshot, and it works. > Note 2 : We really need to add some dtbo facility for people in the = buildkernel process. :-Q Best regards Rolf= From owner-freebsd-arm@freebsd.org Thu Mar 30 23:30:01 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC1B6D26251 for ; Thu, 30 Mar 2017 23:30:01 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42FD278E for ; Thu, 30 Mar 2017 23:30:01 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id z15so35678975lfd.1 for ; Thu, 30 Mar 2017 16:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:reply-to:mail-followup-to :mime-version:content-disposition; bh=DvcepPosxfDhE71t0d2iD4mQoDmi3VXPdZNfpYUauM0=; b=Tt1O2zqr5qOv7J+96btUFK/XCx6Tr1IF1/i7qsiY+t0iob7iRpUtWan9Y8jnIAM3PU Xnq0eUOYn7KLZ/q4lQEgggOjhi3W1BCIbGMFv+Gyl5nfNtQa6Ql5mDypIyhkWxmPVde5 ltXMHGy/2T7IFk6iZE3yaKL7afGeZ85F5BrP86lPF/NJEJxxpKA0nWCKzXoMBCx8MNrl zmPBO/z3c7YyP5WddxqLzeX89LmJlteh0dttmeMRen7ZABIDND1fOiQr7mmVJzH7EUZ0 JfqphW7f9+gmur72K0ZiAh4U2npu0+6a0ae6OjBbXINYyargTrTAPhWAUXq8kJ45tRXw q2ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:reply-to :mail-followup-to:mime-version:content-disposition; bh=DvcepPosxfDhE71t0d2iD4mQoDmi3VXPdZNfpYUauM0=; b=KpwpPRj05w8NOP4MUNLxgOxMZ+GlB0bFbEPdDpIQ+c54zr3ERjmQ89GlPLPTufvSVK TPZ5OQgZYfwWUpDBJSaYlxJq1rT5KSFVDlaR+G5ejVFxsuH8RJY5+zXUCajHvt2lSevc gSvJP0ydHMMB59ObH4CjKpChGkNQBLIGPpzmLJ08SY0Tv2yot143wkYTchy0trt7lhjA TYUgPgx5dyXwDKZNdgQ3VrmDIWpfEYbVvVSzCRvxt/Em7brcdEhP0ittMaYaNU9hjXVZ 92W67C+QWJ08YPC0+FWIXB8tx4+4XB0+E0dXfTDXrjOBug2wFg8OIUdhQfQ4P5JGj+w5 qymA== X-Gm-Message-State: AFeK/H3OaOxjn6bWuODpRF1ClxXuf5dflAkJBhPhq1qfHpVNTzpcw48O2MsCzkD/FIjTeQ== X-Received: by 10.25.152.9 with SMTP id a9mr551380lfe.155.1490916598100; Thu, 30 Mar 2017 16:29:58 -0700 (PDT) Received: from jrl.uk.to (cm-84.211.229.154.getinternet.no. [84.211.229.154]) by smtp.gmail.com with ESMTPSA id 3sm606019ljj.16.2017.03.30.16.29.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 16:29:57 -0700 (PDT) Date: Fri, 31 Mar 2017 01:29:07 +0200 From: Rasmus Liland To: freebsd-arm@freebsd.org Subject: DB-88F6XXX kernel on 88F6281_A0 (GoFlex Net) Message-ID: <20170330232907.GA21389@jrl.uk.to> Reply-To: Rasmus Liland Mail-Followup-To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline X-GPG-Key-Server: http://pgp.mit.edu X-GPG-Key-FingerPrint: DD51 6042 15B2 DC18 B546 B847 9807 9AF9 3DFD 5DF7 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 23:30:01 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear arm list, I now almost managed to boot the DB-88F6XXX configuration on a Seagate GoFlex Net (Kirkwood 88F6281_A0), but not past clang announcement of the first nine dmesg lines before CPU announcement is being expected. Based on sys/arm/mv/kirkwood/kirkwood.c, I am certain this board is supported. Attached is a log of the kernel being loaded in u-boot by running standard commands: dhcp tftpboot 500000 kernel.bin go 500000 The kernel was built based on an old 10/stable tree last checked out August 2016 using this standard procedure from the FreeBSD Wiki https://wiki.freebsd.org/FreeBSDMarvell: make buildworld TARGET_ARCH=arm make buildkernel TARGET_ARCH=arm KERNCONF=DB-88F6XXX I am not sure how to make it past the clang announcement, thus is it possible for anyone to point me in a fruitful direction? /Rasmus --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="goflex_uboot.log" U-Boot 2010.09 (Feb 16 2011 - 18:42:02) UBIT v0.6 by Jeff Doozan and Peter Carmichael SoC: Kirkwood 88F6281_A0 DRAM: 128 MiB NAND: 256 MiB In: serial Out: serial Err: serial Net: egiga0 88E1116 Initialized on egiga0 Creating 1 MTD partitions on "nand0": 0x000002500000-0x000010000000 : "mtd=3" UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 129024 bytes UBI: smallest flash I/O unit: 2048 UBI: sub-page size: 512 UBI: VID header offset: 512 (aligned 512) UBI: data offset: 2048 UBI: attached mtd1 to ubi0 UBI: MTD device name: "mtd=3" UBI: MTD device size: 219 MiB UBI: number of good PEBs: 1752 UBI: number of bad PEBs: 0 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold: 4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 0 UBI: available PEBs: 1731 UBI: total number of reserved PEBs: 21 UBI: number of PEBs reserved for bad PEB handling: 17 UBI: max/mean erase counter: 1/1 UBIFS error (pid 0): ubifs_get_sb: cannot open "ubi:silent", error -19 Error reading superblock on volume 'ubi:silent'! UBIFS not mounted, use ubifs mount to mount volume first! Using egiga0 device ping failed; host 10.10.10.5 is not alive (Re)start USB... USB: Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 1 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 Marvell>> dhcp BOOTP broadcast 1 *** Unhandled DHCP Option in OFFER/ACK: 28 *** Unhandled DHCP Option in OFFER/ACK: 28 DHCP client bound to address 10.6.6.26 *** Warning: no boot file name; using '0A06061A.img' Using egiga0 device TFTP from server 10.6.6.1; our IP address is 10.6.6.26 Filename '0A06061A.img'. Load address: 0x800000 Loading: * TFTP error: 'File not found' (1) Not retrying... Marvell>> tftpboot 500000 kernel.bin Using egiga0 device TFTP from server 10.6.6.1; our IP address is 10.6.6.26 Filename 'kernel.bin'. Load address: 0x500000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ####################################### done Bytes transferred = 4380232 (42d648 hex) Marvell>> go 500000 ## Starting application at 0x00500000 ... KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.3-STABLE #0 r304297: Thu Mar 30 19:28:22 CEST 2017 root@node:/usr/obj/arm.arm/usr/src/stable/10/sys/DB-88F6XXX arm FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 --HcAYCG3uE/tztfnV-- From owner-freebsd-arm@freebsd.org Fri Mar 31 03:54:49 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA0D1D26662 for ; Fri, 31 Mar 2017 03:54:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-14.reflexion.net [208.70.210.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7215EBC6 for ; Fri, 31 Mar 2017 03:54:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3283 invoked from network); 31 Mar 2017 03:54:47 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 31 Mar 2017 03:54:47 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.30.2) with SMTP; Thu, 30 Mar 2017 23:54:46 -0400 (EDT) Received: (qmail 1156 invoked from network); 31 Mar 2017 03:54:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 31 Mar 2017 03:54:46 -0000 Received: from [192.168.1.119] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id EC716EC7848; Thu, 30 Mar 2017 20:54:45 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Is this procstat -v output valid/expected? Explanation? Message-Id: Date: Thu, 30 Mar 2017 20:54:45 -0700 Cc: freebsd-arm To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 03:54:49 -0000 The following is based on a test-case program that: A) Allocates lots of 14KiByte "regions" with malloc, initializing each byte of each region to a never-zero pattern of bytes. "Lots" uses up most of 256 MiBytes across the regions. Once initialized none of these bytes are written again (not even by the later child process). B) Tests the byte patterns (SIGABRT if the pattern test fails). C) Forks. D) The parent waits for child; child sleeps 60 sec. Note: In the full test forcing swapping of both is involved during the sleep but that is not being done here. E) The child checks the byte patterns and exits (SIGABRT if the pattern test fails). The child does not write to any of the allocation regions. F) The (former) parent checks the byte patterns and exits (SIGABRT if the pattern test fails). It does not write to any of the allocated regions during this activity. [The context happens to be arm64.] Note the two instances of "67306" in the below from what will become the parent process: # procstat -v 6310 PID START END PRT RES PRES REF SHD FLAG = TP PATH 6310 0x10000 0x11000 r-- 1 51 3 1 CN-- = vn /root/c_tests/swaptesting2 6310 0x20000 0x21000 r-x 1 51 3 1 CN-- = vn /root/c_tests/swaptesting2 6310 0x30000 0x40000 rw- 16 0 1 0 C--- = vn /root/c_tests/swaptesting2 6310 0x40000 0x41000 r-- 1 38 2 0 ---- = df=20 6310 0x41000 0x75000 rw- 37 38 2 0 ---- = df=20 6310 0x40030000 0x4004b000 r-x 27 29 59 27 CN-- = vn /libexec/ld-elf.so.1 6310 0x4004b000 0x40052000 rw- 7 7 1 0 ---- = df=20 6310 0x4005a000 0x4005b000 rw- 1 0 1 0 C--- = vn /libexec/ld-elf.so.1 6310 0x4005b000 0x4005c000 rw- 1 1 1 0 ---- = df=20 6310 0x4005c000 0x401b4000 r-x 344 376 59 27 CN-- = vn /lib/libc.so.7 6310 0x401b4000 0x401c3000 --- 0 0 1 0 ---- = df=20 6310 0x401c3000 0x401cf000 rw- 12 0 1 0 C--- = vn /lib/libc.so.7 6310 0x401cf000 0x40202000 rw- 22 67306 2 0 ---- = df=20 6310 0x40400000 0x50e00000 rw- 67284 67306 2 0 ---- = df=20 6310 0xfffffffdf000 0xfffffffff000 rw- 3 3 1 0 ---D = df=20 6310 0xfffffffff000 0x1000000000000 r-x 1 1 35 0 ---- = ph=20 Later after the fork (so child sleeping and parent waiting) it as turned into: # procstat -v 6310 PID START END PRT RES PRES REF SHD FLAG = TP PATH 6310 0x10000 0x11000 r-- 1 51 5 1 CN-- = vn /root/c_tests/swaptesting2 6310 0x20000 0x21000 r-x 1 51 5 1 CN-- = vn /root/c_tests/swaptesting2 6310 0x30000 0x40000 rw- 16 0 1 0 C--- = vn /root/c_tests/swaptesting2 6310 0x40000 0x41000 r-- 1 1 2 0 CN-- = df=20 6310 0x41000 0x75000 rw- 37 37 2 0 CN-- = df=20 6310 0x40030000 0x4004b000 r-x 27 29 60 27 CN-- = vn /libexec/ld-elf.so.1 6310 0x4004b000 0x40052000 rw- 7 0 1 0 C--- = df=20 6310 0x4005a000 0x4005b000 rw- 1 0 2 0 CN-- = vn /libexec/ld-elf.so.1 6310 0x4005b000 0x4005c000 rw- 1 0 1 0 C--- = df=20 6310 0x4005c000 0x401b4000 r-x 344 376 60 27 CN-- = vn /lib/libc.so.7 6310 0x401b4000 0x401c3000 --- 0 0 2 0 CN-- = df=20 6310 0x401c3000 0x401cf000 rw- 12 0 2 0 CN-- = vn /lib/libc.so.7 6310 0x401cf000 0x40202000 rw- 22 22 2 0 CN-- = df=20 6310 0x40400000 0x50e00000 rw- 67284 67284 2 0 CN-- = df=20 6310 0xfffffffdf000 0xfffffffff000 rw- 3 0 1 0 C--D = df=20 6310 0xfffffffff000 0x1000000000000 r-x 1 1 36 0 ---- = ph=20 The child never shows the large PRES figure for the range: 0x401cf000 0x40202000 But for the size of that range the earlier PRES=3D=3D67306 seems odd, as if it spans the following: 0x40400000 0x50e0000 In fact 22+67284=3D=3D67306. Another point that I noticed that the I found SHD stays zero on the memory area spanning the allocations (0x40400000 0x50e00000) and more: (This was during the child's sleep.) # procstat -v 6313 PID START END PRT RES PRES REF SHD FLAG = TP PATH 6313 0x10000 0x11000 r-- 1 51 5 1 CN-- = vn /root/c_tests/swaptesting2 6313 0x20000 0x21000 r-x 1 51 5 1 CN-- = vn /root/c_tests/swaptesting2 6313 0x30000 0x40000 rw- 16 0 1 0 C--- = vn /root/c_tests/swaptesting2 6313 0x40000 0x41000 r-- 1 1 2 0 CN-- = df=20 6313 0x41000 0x75000 rw- 37 37 2 0 CN-- = df=20 6313 0x40030000 0x4004b000 r-x 27 29 60 27 CN-- = vn /libexec/ld-elf.so.1 6313 0x4004b000 0x40052000 rw- 7 0 1 0 C--- = df=20 6313 0x4005a000 0x4005b000 rw- 1 0 2 0 CN-- = vn /libexec/ld-elf.so.1 6313 0x4005b000 0x4005c000 rw- 1 0 1 0 C--- = df=20 6313 0x4005c000 0x401b4000 r-x 344 376 60 27 CN-- = vn /lib/libc.so.7 6313 0x401b4000 0x401c3000 --- 0 0 2 0 CN-- = df=20 6313 0x401c3000 0x401cf000 rw- 12 0 2 0 CN-- = vn /lib/libc.so.7 6313 0x401cf000 0x40202000 rw- 22 22 2 0 CN-- = df=20 6313 0x40400000 0x50e00000 rw- 67284 67284 2 0 CN-- = df=20 6313 0xfffffffdf000 0xfffffffff000 rw- 3 0 1 0 C--D = df=20 6313 0xfffffffff000 0x1000000000000 r-x 1 1 36 0 ---- = ph=20 For: 0x40400000 0x50e00000 (and more) my first thought was that forking would shadow for copy-on-write and so the shadow page count would be non-zero in one or both of the parent vs. child. But Ive never seen procstat -v report such a figure for the range holding the allocations. The REF=3D=3D2 also seems odd: it lasts from before the fork through after it as well, both parent and child processes still existing. It would seem that the REF's are not per-process. Context details: # uname -paKU FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r315914M arm64 = aarch64 1200027 1200027 FYI: the source code is. . . (Ignore comments tied to swapping and its/the "problem" for this question.) # more swap_testing2.c // swap_testing2.c // Built via (c++ was clang++ 4.0 in my case): // // cc -g -std=3Dc11 -Wpedantic -o swaptesting2 swap_testing2.c // -O0 and -O2 also gets the problem. #include // for fork(), sleep(.) #include // for pid_t #include // for wait(.) #include // for raise(.), SIGABRT extern void test_setup(void); // Sets up the memory byte = patterns. extern void test_check(void); // Tests the memory byte patterns. extern void partial_test_check(void); // Tests just [0] of = dyn_regions[0] int main(void) { test_setup(); test_check(); // Before fork() [passes] pid_t pid =3D fork(); int wait_status =3D 0;; // After fork; before waitsleep/swap-out. //if (0=3D=3Dpid) partial_test_check(); // Even the above is sufficient by // itself to prevent failure for // region_size 1u through // 4u*1024u! // But 4u*1024u+1u and above fail // with this access to memory. // The failing test is of // (*dyn_regions[0]).array[4096u]. // This test never fails here. if (0 // for size_t, NULL #include // for malloc(.), free(.) #define region_size (14u*1024u) // Bad dyn_regions patterns, parent and child // processes: // 256u, 2u*1024u, 4u*1024u, 8u*1024u, // 9u*1024u, 12u*1024u, 14u*1024u // (but see the partial_test_check() call // notes above). // Works: // 14u*1024u+1u, 15u*1024u, 16u*1024u, // 32u*1024u, 256u*1024u*1024u #define num_regions (256u*1024u*1024u/region_size) typedef volatile unsigned char value_type; struct region_struct { value_type array[region_size]; }; typedef struct region_struct region; static region * volatile dyn_regions[num_regions] =3D {NULL,}; static value_type value(size_t v) { return (value_type)((v&0xFEu)|0x1u); = } // value now avoids the zero value since the failures // are zeros. void test_setup(void) { for(size_t i=3D0u; i Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7CAE2D264F0 for ; Fri, 31 Mar 2017 06:53:52 +0000 (UTC) (envelope-from jan.sieka@gmail.com) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BBC9C87 for ; Fri, 31 Mar 2017 06:53:52 +0000 (UTC) (envelope-from jan.sieka@gmail.com) Received: by mail-oi0-x234.google.com with SMTP id o67so52184373oib.1 for ; Thu, 30 Mar 2017 23:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=5DmBPjoMnWcRxKUWR5qJgvvZ0r7Ni2cFwAL7KbWGMEs=; b=ZBwv4reRbLVGdS8rGcZ/p2HYihBPZCwXlb0/IbQcXvnC/0VnIjZSi8PYm/XbwiZK4T wpB5FtvkfF407eM5OHNMC8VzMUimDv/juyrEy2cvCKpWQ1S5PomeDLBkYWnNlAA+nWlS Tt+o/LYOc7wgbs7yUb4ksXcx00F/RB+5MNLXremfbaNCTRakHE6/uoSYaLwOgjkxj+RP 2he2Rv8Eehs/b43S1IbLM+dkOK4cA6KaAqMTq+hKVGD87ZGcKbVWwd9I1l83l6Ok3JOU PWwNeaPLErMyYP4y47Iw3hMWQKrkwLhOagSLyYuZhMW3QzrJfF77rLJYeuBH1a47FWFE knsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=5DmBPjoMnWcRxKUWR5qJgvvZ0r7Ni2cFwAL7KbWGMEs=; b=bItu8fCCBKND0ESAi9abddP9ZGcgHmS74sDamI5Nc9RoICzsiTTlAEbyZZE3nwwl1d UcdPPIeV1NqfldfdzGqNApvJawCXvO+3jgNkU8PO+ktM6JnNoY2xNfKKJj0Kwg3gGsp2 XguxclNAUK3rwE2qnD6mfMg4zj+Thkp17si9sLhnElTOG+m3L0aVZ5aotK5sflg6GIBn JIsrMZoe3blAjmF9734YYsDJnocXNJCNZLS31uHj71P5zHUA8TV0PPDL1q/mxIrlakUS Y/sAywMYum6yVzP6lr0sOjUYHoj0UolZrFPHN6MSPVaHkEgAaDHBh6DwBhcNUSJQV7VX 4CRg== X-Gm-Message-State: AFeK/H0+WJ3wjuIr9yQ0SIaypEbZ1hm+inHWPOG5Dh7MU3UCg/XfkaWN/NwpnjpBTmwljO73qc4WdvXRuZIBiw== X-Received: by 10.202.181.7 with SMTP id e7mr712357oif.60.1490943231547; Thu, 30 Mar 2017 23:53:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.68.145 with HTTP; Thu, 30 Mar 2017 23:53:51 -0700 (PDT) In-Reply-To: <20170330232907.GA21389@jrl.uk.to> References: <20170330232907.GA21389@jrl.uk.to> From: Jan Sieka Date: Fri, 31 Mar 2017 08:53:51 +0200 Message-ID: Subject: Re: DB-88F6XXX kernel on 88F6281_A0 (GoFlex Net) To: Rasmus Liland , freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 06:53:52 -0000 Hi Rasmus! Where did you get the address 500000? I recall that it must be double checked that this address is correct. Best regards, Jan Sieka 2017-03-31 1:29 GMT+02:00 Rasmus Liland : > Dear arm list, > > I now almost managed to boot the DB-88F6XXX configuration on a > Seagate GoFlex Net (Kirkwood 88F6281_A0), but not past clang > announcement of the first nine dmesg lines before CPU > announcement is being expected. > > Based on sys/arm/mv/kirkwood/kirkwood.c, I am certain this board > is supported. Attached is a log of the kernel being loaded in > u-boot by running standard commands: > > dhcp > tftpboot 500000 kernel.bin > go 500000 > > The kernel was built based on an old 10/stable tree last checked > out August 2016 using this standard procedure from the FreeBSD > Wiki https://wiki.freebsd.org/FreeBSDMarvell: > > make buildworld TARGET_ARCH=arm > make buildkernel TARGET_ARCH=arm KERNCONF=DB-88F6XXX > > I am not sure how to make it past the clang announcement, thus is > it possible for anyone to point me in a fruitful direction? > > /Rasmus > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Fri Mar 31 07:01:12 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31C58D26708 for ; Fri, 31 Mar 2017 07:01:12 +0000 (UTC) (envelope-from jan.sieka@gmail.com) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EAE47FB3 for ; Fri, 31 Mar 2017 07:01:11 +0000 (UTC) (envelope-from jan.sieka@gmail.com) Received: by mail-oi0-x22c.google.com with SMTP id r203so52202771oib.3 for ; Fri, 31 Mar 2017 00:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Z5KppFDabadV9CH1mnii6A3faP97GaTWW3dOvcb6U88=; b=RZGjmrAe+0Vf6q0CKOiabJT7T1AVITr5LKtht+n5CfArzt42WaotcyYm+919F3JFMT QxhRPE+aSuzxN+LwDO7SAw4LyDimzQ9ZPMveqqUmHFKpdRUmlbUVvbFt73+JK0dreuUZ OiJ1QM/kDeek4ij7nbtmltmqD3NZCqI7XjW9DcOSTf/wY1k4vRasupy5MS0b9Gc5UzTq m/sq15AKXpx2kLSdCB9gUTIxrfASWrY2KvSFR9tKu3j5NBvIvDxAM6j3FlyQX0TX9s4I RBmjMJ3MsiJEkjmlXVqC4YXY6+BdCAERjDz/iQAH9dEF4dHkdzPbqhtbgootCt6P/gmQ GuQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Z5KppFDabadV9CH1mnii6A3faP97GaTWW3dOvcb6U88=; b=sLysbDmIdK/0SjUn4fCKISVwue9Zsf9tuiikdFyR3/0SgmOSeltoaUzuJz2fxs5P0J TNo6Vn1zSRNPhEM9rT16+d5H0Wy/Bww+dW0fzNeo58lV/QRfTOFspVwm+cxzloR6kozH R6bV7/MicAa+UWVNsJvB86dUPx0EZe2hIaem5tRb+5L+QTbPhtIbHm2z6OEKLo7o4jBz bG6DrPBkrbsG5FxlvOD5yrQu7/WYd9gpSYCAmFWUe6zVJkMk8tw+5+c54iajJ6wBQp6N 5A6JC/goBzsPzFdwE3/BU1pyKHWjrKMJKAvS0hRljHO1y701wEyBaPmB+GYSrNTBeqxh EY4g== X-Gm-Message-State: AFeK/H0TLapmYfD0tfGj1F9dsewnfwa5I9+4APe8iMK043yjNSeKk0QZ8lqNX3/tG+XdJCuEVz/j+d5+p0k/Pw== X-Received: by 10.202.73.17 with SMTP id w17mr822358oia.16.1490943671216; Fri, 31 Mar 2017 00:01:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.68.145 with HTTP; Fri, 31 Mar 2017 00:01:10 -0700 (PDT) In-Reply-To: References: <20170330232907.GA21389@jrl.uk.to> From: Jan Sieka Date: Fri, 31 Mar 2017 09:01:10 +0200 Message-ID: Subject: Re: DB-88F6XXX kernel on 88F6281_A0 (GoFlex Net) To: Rasmus Liland , freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 07:01:12 -0000 Hi Rasmus! I searched a little and based on that file: https://svnweb.freebsd.org/base/releng/10.3/sys/arm/mv/kirkwood/std.kirkwood?view=markup and the wiki you mentioned I'd try to load the kernel under 900000 and go to that address: tftpboot 900000 kernel.bin go 900000 Best regards, Jan Sieka 2017-03-31 8:53 GMT+02:00 Jan Sieka : > Hi Rasmus! > > Where did you get the address 500000? I recall that it must be double > checked that this address is correct. > > Best regards, > > Jan Sieka > > 2017-03-31 1:29 GMT+02:00 Rasmus Liland : > >> Dear arm list, >> >> I now almost managed to boot the DB-88F6XXX configuration on a >> Seagate GoFlex Net (Kirkwood 88F6281_A0), but not past clang >> announcement of the first nine dmesg lines before CPU >> announcement is being expected. >> >> Based on sys/arm/mv/kirkwood/kirkwood.c, I am certain this board >> is supported. Attached is a log of the kernel being loaded in >> u-boot by running standard commands: >> >> dhcp >> tftpboot 500000 kernel.bin >> go 500000 >> >> The kernel was built based on an old 10/stable tree last checked >> out August 2016 using this standard procedure from the FreeBSD >> Wiki https://wiki.freebsd.org/FreeBSDMarvell: >> >> make buildworld TARGET_ARCH=arm >> make buildkernel TARGET_ARCH=arm KERNCONF=DB-88F6XXX >> >> I am not sure how to make it past the clang announcement, thus is >> it possible for anyone to point me in a fruitful direction? >> >> /Rasmus >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> > > From owner-freebsd-arm@freebsd.org Fri Mar 31 08:15:06 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0020AD27BC0 for ; Fri, 31 Mar 2017 08:15:05 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76EE8C7D for ; Fri, 31 Mar 2017 08:15:05 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id z15so39566472lfd.1 for ; Fri, 31 Mar 2017 01:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-disposition:in-reply-to; bh=V9Gqds3y8ci+ez0wypLH2RxszDLKKwKq5X43lR2/FZM=; b=rswCJWKgUlg03tovoYOl3ijVwU84vPHOSfVZkJkciHYK5AS0vdMATC9iUddpZuvflX Sj91lY1XaSX7znDnxC4+dGNhKuhcPLYFK8iZtrJ8US3JEMyPVHrEST7Ws18pHOEcA3ES 6qhhlHJ93AG1e5qhuEuA+LErq0lFUzvuU5rLU9ib9aS3dVM74A9A3Y3DsjRkN3zsg/OL VhkeD2BGU/XypGFUmmzQsjLo36Z1qksMMNjaGTt/470ghQvzjMEYsWvDc5YvIOEs7xDh ZYKkzIWlBhvBD6G6pY4RIkOdipt7BnIleSrxVyqo53hZpRvAge+pv07+d6/unBU8SiKf fOJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:reply-to :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=V9Gqds3y8ci+ez0wypLH2RxszDLKKwKq5X43lR2/FZM=; b=tBtzmmZt6tnD0FPStLp65FeJ3xZoyQBiED6ZznMFLILo/0U99x7lH53YCrObBs/sNN raB3rA3qmWe25nHIgFjRDxMGZcBHrSF2G53x6apTJiFBakuHWsH3NoeOVWBwlHzXJmL4 fAN/qtsuOZxtswN3cn0tMBUFuZED/socW0GHIzZjK6Qz6YTBuavdCDAlCQrqkpogToKK duFMhf8+FcCpRbQlslq3H8hitENArVjj4pczgqyMZ3tUHV0DLXs6A1UJMznHPw8GrT0f HjBxECNATgsT4XEpyli8LJNZJbOWjWY4eoZd/jVs3MpaGgkDZiFLOwexGQNJH52xUZ8O FNNQ== X-Gm-Message-State: AFeK/H1VfnFkeCVoa5GXna4T7oE9nNY7nxQnZ9UTqpGhlthO4DmMaf+avAI6VTEWQNJCvA== X-Received: by 10.25.92.25 with SMTP id q25mr558770lfb.121.1490948103329; Fri, 31 Mar 2017 01:15:03 -0700 (PDT) Received: from jrl.uk.to (eduroam-193-157-117-77.uio.no. [193.157.117.77]) by smtp.gmail.com with ESMTPSA id x28sm803075ljd.60.2017.03.31.01.15.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 01:15:02 -0700 (PDT) Date: Fri, 31 Mar 2017 10:14:13 +0200 From: Rasmus Liland To: Jan Sieka , freebsd-arm Subject: Re: DB-88F6XXX kernel on 88F6281_A0 (GoFlex Net) Message-ID: <20170331081413.GA29182@jrl.uk.to> Reply-To: Rasmus Liland Mail-Followup-To: Jan Sieka , freebsd-arm References: <20170330232907.GA21389@jrl.uk.to> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-GPG-Key-Server: http://pgp.mit.edu X-GPG-Key-FingerPrint: DD51 6042 15B2 DC18 B546 B847 9807 9AF9 3DFD 5DF7 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 08:15:06 -0000 On 2017-03-31 08:53 +0200, Jan Sieka wrote: > Hi Rasmus! > > Where did you get the address 500000? I recall that it must be > double checked that this address is correct. I adjusted the address to 500000 myself when noticing the tftpload command not being able to load kernel.bin at 900000 because it stalled halfway at the "Loading:" series of number signs (#), thus I noticed the series becoming longer, i.e. more data being loaded (from tftpd to to somewhere) when decreasing 900000 to 500000. I'm not at this computer right now, but can provide interesting output on this and other things later. /Rasmus From owner-freebsd-arm@freebsd.org Fri Mar 31 09:42:21 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA05AD26B78 for ; Fri, 31 Mar 2017 09:42:21 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C666DAF for ; Fri, 31 Mar 2017 09:42:21 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: by mail-lf0-x22a.google.com with SMTP id h125so40715802lfe.0 for ; Fri, 31 Mar 2017 02:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-disposition:in-reply-to; bh=jNt0EW+rgsLyPmLiuypgiIEI7dXOSrm/1kBEplwh6d4=; b=s9BAuZXJtpuUYJssmAXhjwE37ctzKgD+cLR2jhKm4y/eZ8UxoDjW+Xk0PpsFGYA+2F sQnO/0ZbmubYNzObUmNabIxPEiX1hyzmX+94oaPPTIr54hLoZKs2pf7Kogv2V+iSdidJ gMuho1EJltd+HqWR538ZF6V8fOKWC9Q8uGuy71mjUS/Izr96Y/KgGCurRQ/5eEqJfdpA jeHR6E1AeKDK9iaw6kCQPI0bKMmEto8ZTQfMmpUFQZUbIajf5gIq8mDN6YIfKGcXiK8e GmhJng7ogL4edL9qWrJ581kwoly3xJZp9MuO9GrR2wAnmxKpyN/gR7lPHAfYvPjKUIPK COsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:reply-to :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=jNt0EW+rgsLyPmLiuypgiIEI7dXOSrm/1kBEplwh6d4=; b=XPLz41b+ZxA4jVUBmnksh6YMcjDd0OdSTPGC6y3uMwT/3Gh5prVdAI/u1julWzrwEk X0rIyUjqhH5oHiuMxb3kzz+xfueBCHxuX5pwOH6wYyT6fWwDwy0Ep+DlVVYJaPfxjXvr bwtql/CqwnSlFjmnFxy/THGpeylFnzAyOfs9jTAgXukjf0mudGDyh7XeECRWErnVwkeR Ko4R58pZsvCWvKalzVhorxH/SHruWuohy+TdxI0ZmrvDZ9aGt4dXLY1CpoGPtrhez6qK e3hbOAZpB8GYee+96O531BQDp19uDdlFiC3dwvfZ5xJXxo05Ghuovgf1Roz+33ViHRZU s/wQ== X-Gm-Message-State: AFeK/H2nJ7vdQROWQEmp2UY7YwG+4Dh89z5P4rNO+fanqisK/pkrYiWLaLYPR812fWT3Fw== X-Received: by 10.25.23.97 with SMTP id n94mr619008lfi.48.1490953338136; Fri, 31 Mar 2017 02:42:18 -0700 (PDT) Received: from jrl.uk.to (eduroam-193-157-117-77.uio.no. [193.157.117.77]) by smtp.gmail.com with ESMTPSA id u128sm830783lff.4.2017.03.31.02.42.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 02:42:16 -0700 (PDT) Date: Fri, 31 Mar 2017 11:41:27 +0200 From: Rasmus Liland To: Mori Hiroki , freebsd-arm Subject: Re: DB-88F6XXX kernel on 88F6281_A0 (GoFlex Net) Message-ID: <20170331094127.GA29618@jrl.uk.to> Reply-To: Rasmus Liland Mail-Followup-To: Mori Hiroki , freebsd-arm References: <20170330232907.GA21389@jrl.uk.to> <888745.43951.qm@web101706.mail.ssk.yahoo.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <888745.43951.qm@web101706.mail.ssk.yahoo.co.jp> X-GPG-Key-Server: http://pgp.mit.edu X-GPG-Key-FingerPrint: DD51 6042 15B2 DC18 B546 B847 9807 9AF9 3DFD 5DF7 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 09:42:21 -0000 On 2017-03-31 10:07 +0900, Mori Hiroki wrote: > Hi. > > Sorry not answer. > I build mv/orion just now. > https://gist.github.com/yamori813/ecd5df1b314053a73f310c1122775540 > > I modify dts file that is very hard. > > My dts file is this. > https://github.com/yamori813/freebsd/blob/zrouter/sys/boot/fdt/dts/arm/wzr-ampg300nh.dts > https://github.com/yamori813/freebsd/blob/zrouter/sys/boot/fdt/dts/arm/db88f5181.dtsi > > I use my maintenance ZRouter build system. > https://github.com/yamori813/zrouter/tree/add_new_devices Hi! I think I found an existing dts for my board at https://svnweb.freebsd.org/base/releng/10.3/sys/boot/fdt/dts/arm/db88f6281.dts and a crypto address seems to have been modified for this in the future: https://svnweb.freebsd.org/base/stable/11/sys/boot/fdt/dts/arm/db88f6281.dts?r1=262614&r2=302408 I realize a dts file is a sort of structural sketch of the board. Is it then supposed to be included in the kernel config as extra information for the compiler? /Rasmus From owner-freebsd-arm@freebsd.org Fri Mar 31 10:45:48 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B226D26FFA for ; Fri, 31 Mar 2017 10:45:48 +0000 (UTC) (envelope-from jan.sieka@gmail.com) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D380BA83 for ; Fri, 31 Mar 2017 10:45:47 +0000 (UTC) (envelope-from jan.sieka@gmail.com) Received: by mail-oi0-x22a.google.com with SMTP id f193so56232896oib.2 for ; Fri, 31 Mar 2017 03:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=74797dqcgjNhyuhYWfFWYPRtXAiOQtQAouGSYZMMSvk=; b=Eoa5xSSjwm7Xm+mZRPBhDgadAj6SrAm6PIlDUNx2oqcqXhQHMt3y2W3xngQDjv/04M Cq3wzBLxNyAtOoepk7fG0Yda8OfH2XzdocEzJtex2fArrSXd8rpCrQfKKyEvyKFfOf3m mlYWTFHzh8AodcJyE6L4xGhdxd+uORzolVqWyv6OdOiYELWQeDQRPKsVqv7a/SGpPyL2 MNeLaK9XdASOVkiWkMno/91JH+qwvWGc0mjJwzM4+muryUke6WSedK6ueLOSOkqxtoBV azF+JtXBaRNMpI5ABVFwFOqSV5oFVBgIHEr3qcxzUpMcjDej+zhPAxDaEGVntrs8ciEj u7dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=74797dqcgjNhyuhYWfFWYPRtXAiOQtQAouGSYZMMSvk=; b=Ex3ZJgGcxQBV+RyJvTM15EjT1dG6q6r2TIxWkeGu26ttltGKJ40DIOsIEgDX6F+tiu bZnMcSHh67OsHkiZLHJYFCk+2oS2sfxM0Aa82OqoaEPeFDIzQYD2ViLMGQ76ZfQS9k90 /h/UH5M4ONzUVqFitZj7rlqFofdX7UXTnK1lSMZMfd1IBDixFcVqufLciucO2qQAMj/A i7oc8P8IQVwPxA8oRpye0UCGW+oaAAkUyCWcYX1uAgmxLzxFdTEwWXGchylh/GJdbEGC tKa6INalDBgNNSyO1EXt3dyWi/hPvsNEx/gjRO9vr8gND/8z1nN3GgXBuqwkdnkLiT+p lpTQ== X-Gm-Message-State: AFeK/H12jD/TnRP6ycaB/Q/j40vlWUr9dWU4immnXehomWazry5UtMmV1r2Hh5CeDM5OpBTMx9SZ9KgYDalDAw== X-Received: by 10.157.89.219 with SMTP id u27mr1389813otg.32.1490957146680; Fri, 31 Mar 2017 03:45:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.68.145 with HTTP; Fri, 31 Mar 2017 03:45:45 -0700 (PDT) In-Reply-To: <20170331094127.GA29618@jrl.uk.to> References: <20170330232907.GA21389@jrl.uk.to> <888745.43951.qm@web101706.mail.ssk.yahoo.co.jp> <20170331094127.GA29618@jrl.uk.to> From: Jan Sieka Date: Fri, 31 Mar 2017 12:45:45 +0200 Message-ID: Subject: Re: DB-88F6XXX kernel on 88F6281_A0 (GoFlex Net) To: Rasmus Liland , Mori Hiroki , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 10:45:48 -0000 Hello! The .dts file is included in the kernel config file. Look here in the line 8: https://svnweb.freebsd.org/base/releng/10.3/sys/arm/conf/DB-88F6XXX?view=markup How much memory (RAM) do you have on your board? I'm recalling that sometimes when we tried to load FreeBSD kernel under the wrong address we were overwriting the U-Boot in the RAM thus we observed stalled tftp load. So the question is what is the address under which the U-Boot is copied to the memory on your board. Best regards, Jan 2017-03-31 11:41 GMT+02:00 Rasmus Liland : > On 2017-03-31 10:07 +0900, Mori Hiroki wrote: > > Hi. > > > > Sorry not answer. > > I build mv/orion just now. > > https://gist.github.com/yamori813/ecd5df1b314053a73f310c1122775540 > > > > I modify dts file that is very hard. > > > > My dts file is this. > > https://github.com/yamori813/freebsd/blob/zrouter/sys/boot/ > fdt/dts/arm/wzr-ampg300nh.dts > > https://github.com/yamori813/freebsd/blob/zrouter/sys/boot/ > fdt/dts/arm/db88f5181.dtsi > > > > I use my maintenance ZRouter build system. > > https://github.com/yamori813/zrouter/tree/add_new_devices > > Hi! > > I think I found an existing dts for my board at > https://svnweb.freebsd.org/base/releng/10.3/sys/boot/fdt/ > dts/arm/db88f6281.dts > > and a crypto address seems to have been modified for this in the > future: > https://svnweb.freebsd.org/base/stable/11/sys/boot/fdt/ > dts/arm/db88f6281.dts?r1=262614&r2=302408 > > I realize a dts file is a sort of structural sketch of the board. > Is it then supposed to be included in the kernel config as extra > information for the compiler? > > /Rasmus > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Fri Mar 31 10:57:00 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53363D272F4 for ; Fri, 31 Mar 2017 10:57:00 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C9472129 for ; Fri, 31 Mar 2017 10:56:59 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: by mail-lf0-x231.google.com with SMTP id h125so41707693lfe.0 for ; Fri, 31 Mar 2017 03:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-disposition:in-reply-to; bh=a0ab8G/EgSTR+3OUH1FarYXEphhgOPitrCyEkqK7a/w=; b=EnQedmNBIqdrKCCDKumuhOwQfpfzA5RZAJ8627neT/K1FH0kPjoPNga4Xe/8npG/dP pi4Sm7VNqRDA6pnEINnI4UIgscr3Y1Gyme1nvWnUrtt2sdSRYIHRJbq+jUFQ0QzVc9pO phFcwypgr9PxScvEPXrwalEXFnPXcGWfjUbGEdxOI9fjEaf6C2miro2ZsnZbXJ0bsqrr W9sc3vbrrBK49Q9PtRyXBn6QAExdEgytVddeLlIWM5PAAPji0FZZk/bFf4tMrIbiSlHT rMLPU5PyDMhdaC9JVNJ1kaM2n/Tv+m2QHeSAx6IoDa+5kRxw6TWzTsxL/M2oyIdr3ccW tFxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:reply-to :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=a0ab8G/EgSTR+3OUH1FarYXEphhgOPitrCyEkqK7a/w=; b=Xsx1Nk8H6pOt3W1oMtIIMxxrYQy+qmp49apk9BeyDcjcvp4XE0V+CXbHUVI/ZK9kbS P4eiKGwx+W+pZzNGBnpZ/vONlGC7cYk+3F59k16hUksMKF12QlqQ+0nuPEkSYUgpRjRQ FPWKTy9EQpv0geOXHfz9pBZn9J+dv4+0x+XYjZHveYqWz/Dz7c2ML420FZERG8Ri+QMj 5nTmO3kysvPTVxQ2jYjadHe5bfR9J/Cb1CkVq6hhdcuJD0qVmg88xT/mSo6MG9QjwRW3 YD+fP6QrvpO4nuLB7CoiLYgL0riVl9PXiRXFdUIjXPYMj7uk4Ak1JjK/2qXkOksBbgLY H+FQ== X-Gm-Message-State: AFeK/H3OOvTgJ1QfhY451p6ckAUBeLLqLs69xPgww2ib3IL4lKfomzfte596SasFrdHgVw== X-Received: by 10.25.56.1 with SMTP id f1mr855071lfa.83.1490957817571; Fri, 31 Mar 2017 03:56:57 -0700 (PDT) Received: from jrl.uk.to (cm-84.211.229.154.getinternet.no. [84.211.229.154]) by smtp.gmail.com with ESMTPSA id e10sm849530ljb.38.2017.03.31.03.56.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 03:56:56 -0700 (PDT) Date: Fri, 31 Mar 2017 12:56:06 +0200 From: Rasmus Liland To: Jan Sieka , freebsd-arm Subject: Re: DB-88F6XXX kernel on 88F6281_A0 (GoFlex Net) Message-ID: <20170331105606.GA31398@jrl.uk.to> Reply-To: Rasmus Liland Mail-Followup-To: Jan Sieka , freebsd-arm References: <20170330232907.GA21389@jrl.uk.to> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-GPG-Key-Server: http://pgp.mit.edu X-GPG-Key-FingerPrint: DD51 6042 15B2 DC18 B546 B847 9807 9AF9 3DFD 5DF7 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 10:57:00 -0000 On 2017-03-31 09:01 +0200, Jan Sieka wrote: > Hi Rasmus! > > I searched a little and based on that file: > https://svnweb.freebsd.org/base/releng/10.3/sys/arm/mv/kirkwood/std.kirkwood?view=markup > and the wiki you mentioned I'd try to load the kernel under > 900000 and go to that address: > > tftpboot 900000 kernel.bin > go 900000 Hi Jan! When I try to load the kernel.bin at address 900000, this happens: | Marvell>> tftpboot 900000 kernel.bin | Using egiga0 device | TFTP from server 10.6.6.1; our IP address is 10.6.6.26 | Filename 'kernel.bin'. | Load address: 0x900000 | Loading: ################################################################# | ################################################################# | ############# U-boot is stalling here, and at the other end of the ethernet cable the FreeBSD tftpd process is discovering it as a timeout ACK in stderr. Thus, what I did in the earlier email was decrementing the address to 500000, or even as high as 600000, then this happens: | Marvell>> tftpboot 600000 kernel.bin | Using egiga0 device | TFTP from server 10.6.6.1; our IP address is 10.6.6.26 | Filename 'kernel.bin'. | Load address: 0x600000 | Loading: ################################################################# | ################################################################# | ################################################################# | ################################################################# | ####################################### | done | Bytes transferred = 4380232 (42d648 hex) | Marvell>> go 600000 | ## Starting application at 0x00600000 ... | KDB: debugger backends: ddb | KDB: current backend: ddb | Copyright (c) 1992-2016 The FreeBSD Project. | Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 | The Regents of the University of California. All rights reserved. | FreeBSD is a registered trademark of The FreeBSD Foundation. | FreeBSD 10.3-STABLE #0 r304297: Thu Mar 30 19:28:22 CEST 2017 | root@node:/usr/obj/arm.arm/usr/src/stable/10/sys/DB-88F6XXX arm | FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 The std.kirkwood file header specifically mentions 900000 to be the right place for the kernel to account for the page table in another place, and the possibility for these to be bounced higher if there is a problem. The next step would be to change the addresses of KERNPHYSADDR, and KERNVIRTADDR to something new. What is the right procedure to calculate new addresses for these? /Rasmus From owner-freebsd-arm@freebsd.org Fri Mar 31 11:16:31 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6BA35D278F8 for ; Fri, 31 Mar 2017 11:16:31 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E135CDFA for ; Fri, 31 Mar 2017 11:16:30 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id x137so42132613lff.3 for ; Fri, 31 Mar 2017 04:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-disposition:in-reply-to; bh=XQZ/N0eZF9v7E/oscLRa09diLRlJwaCib1kKJ4LW2+E=; b=NCva+v0o9XmF4q4jqXGu+M40QcB0rpvKF/+F7u5sdf9AW2R2Y5Lml5LDr64ER99BcB hyHaX32OiyShpvumLmz7G1dr7uwTxMVVwcmv5864KoX1Mv0oC2aF8UuRdFeqiESENNOi 6z+7D1hd9MD9ajktwqNyge2mmSHEBkCZ3QOe094claxVmORMchjQ0cBio4vcR9MCOgkA H8/V1LJDOkJVS+UBLuQ3Lhk7tc+PHuOBQp4lXWaz+zTk1wyYwHFDe4+mu7eQGwZzYDMS dn+m/t4bfrtz0PSQezmlCxa7vqmf0LHgrVavYBJN2z1dhBOB7onmHNWUSAxYUuFayTAj fz0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:reply-to :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=XQZ/N0eZF9v7E/oscLRa09diLRlJwaCib1kKJ4LW2+E=; b=Fr9GCI8uvtI+eo1z41SvUsicNduGnwKROiKaPlfwe8Iho+CEZuT7Q6qrONAKShA7D+ 71CUxHlR1QQ7u1TtVh7DdeGEKget8uJ4u66uG9/0cgGBuz9yg4TNHykmIu+7XKe+mKMd MUKQcRmG9qJiOf4drz4J047nHhu9oh2PZ/odmJOocis2XwWMcdcBGSdSTwTjsh5Jourv 5RhMn6giMWGFxRrsVXdmHZshjfqVuAn52/bMfUZaUAiqYtKCdF/5JbtphfopJwRgJhK9 x2C0KgNWhN6HuP1myZhEJuIRITE5Vs6Vjj+5P02hqqwRgGyoSYM/a4aRJ6pU176o/6Q0 l+1g== X-Gm-Message-State: AFeK/H1Y1WeBg2HNR2Zl6agcHU/eA/suIjtYT6xcPXJMaIrjyCatGS+KNRxfVfx1rHovKw== X-Received: by 10.25.242.73 with SMTP id d9mr933032lfk.89.1490958989092; Fri, 31 Mar 2017 04:16:29 -0700 (PDT) Received: from jrl.uk.to (cm-84.211.229.154.getinternet.no. [84.211.229.154]) by smtp.gmail.com with ESMTPSA id c5sm874141lfk.51.2017.03.31.04.16.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 04:16:28 -0700 (PDT) Date: Fri, 31 Mar 2017 13:15:38 +0200 From: Rasmus Liland To: Jan Sieka , freebsd-arm Subject: Re: DB-88F6XXX kernel on 88F6281_A0 (GoFlex Net) Message-ID: <20170331111538.GB31398@jrl.uk.to> Reply-To: Rasmus Liland Mail-Followup-To: Jan Sieka , freebsd-arm References: <20170330232907.GA21389@jrl.uk.to> <888745.43951.qm@web101706.mail.ssk.yahoo.co.jp> <20170331094127.GA29618@jrl.uk.to> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-GPG-Key-Server: http://pgp.mit.edu X-GPG-Key-FingerPrint: DD51 6042 15B2 DC18 B546 B847 9807 9AF9 3DFD 5DF7 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 11:16:31 -0000 On 2017-03-31 12:45 +0200, Jan Sieka wrote: > Hello! > > The .dts file is included in the kernel config file. Look here > in the line 8: > https://svnweb.freebsd.org/base/releng/10.3/sys/arm/conf/DB-88F6XXX?view=markup Hello! Yes, it seems the dts file is specified at line 97, and the std.db88f6xxx is at line 8. Perhaps these need to be modified, yes. > How much memory (RAM) do you have on your board? > > I'm recalling that sometimes when we tried to load FreeBSD > kernel under the wrong address we were overwriting the U-Boot > in the RAM thus we observed stalled tftp load. So the question > is what is the address under which the U-Boot is copied to the > memory on your board. U-Boot announces the amount of DRAM to 128MiB, and 256MiB of NAND. Is there any U-boot command I can run to show some of the memory mapping to determine the new addresses? I looked around and at least found the commands cmp, md, and bdinfo, perhaps they are useful: | Marvell>> help | bdinfo - print Board Info structure | cmp - memory compare | md - memory display | Marvell>> cmp | cmp - memory compare | | Usage: | cmp [.b, .w, .l] addr1 addr2 count | Marvell>> md | md - memory display | | Usage: | md [.b, .w, .l] address [# of objects] | Marvell>> bdinfo | arch_number = 0x00000C11 | env_t = 0x00000000 | boot_params = 0x00000100 | DRAM bank = 0x00000000 | -> start = 0x00000000 | -> size = 0x08000000 | DRAM bank = 0x00000001 | -> start = 0x00000000 | -> size = 0x00000000 | DRAM bank = 0x00000002 | -> start = 0x00000000 | -> size = 0x00000000 | DRAM bank = 0x00000003 | -> start = 0x00000000 | -> size = 0x00000000 /Rasmus From owner-freebsd-arm@freebsd.org Fri Mar 31 14:01:02 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C50F6D2715A for ; Fri, 31 Mar 2017 14:01:02 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C14F16 for ; Fri, 31 Mar 2017 14:01:02 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-it0-x22f.google.com with SMTP id e75so13243337itd.1 for ; Fri, 31 Mar 2017 07:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Hv/fpZ8HuiEV/LIjra9DqFtQfDMxLAg2OQrj17l3qqg=; b=YrzCckues7gixTKTV77IlSzPMpcTHx9mAttS30dgcU8wG26uS0l/AllMSXnV/UxV++ dE7ylFDEk3n2wLXvrLjePEIHb9L3PIncoxj7Wts81XFvyxuAjlhFM9a5MqxamPR+f0uB Len9tPU/+HCDkKMvXmzc/e4IdgEtZj49gUXpGC8Fav2JrcT/V5G/k4dlLVqwDE49Hw5N kb6zydo8SSsiERFjrkghHipVa7+SgkKNvAsRdYJWyHAvA0jJV7pqeEpay9e6h5L8RvWM FbEzt3fHpdvcofKEK7lkuxJLSlIlkdMkhhi1Mauze1v5Ypajn8uyIU+HERCQlFIQKc5P VBgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Hv/fpZ8HuiEV/LIjra9DqFtQfDMxLAg2OQrj17l3qqg=; b=BA0RcnMISQ3dLxUB3JbZgUIv7outLg8ikr2ec2d3tlGMahJU0H+j1xkrLwEsUbsi57 zYNPnHuv2qsQy1awWrpjWy701BKACPGs2gpO1JwHEYpicnkhnQHXa6tOQBc+DqtTT85g AGiZdlPMpFyH04EZCK3pM2p5czjFfLH55nSIhLNF8wLq6tKkEocEWWc8cQ24Rk/6w+La tiyGyAQMhnDn0ZCXhYoW0fQ4CG55lY7kYXwn/fpmr64rEOAD2BgF5N266j5f8TPyGmOG ZlulCONJHW+WNeAGSERNT1e4tWILK+DUmTH7KBDio78AjNiU0uZ3V5KItDrzlNoqkEj5 c4HQ== X-Gm-Message-State: AFeK/H3s82H3irJA6DDpQaR0VDYcQI5HDEBMFUHvUPirDg/7qvCGhAK9RyW+0YmavI+dy+L1w13JFVInnSN2bg== X-Received: by 10.36.137.68 with SMTP id s65mr3081161itd.70.1490968861324; Fri, 31 Mar 2017 07:01:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.146 with HTTP; Fri, 31 Mar 2017 07:01:00 -0700 (PDT) From: Marcin Wojtas Date: Fri, 31 Mar 2017 16:01:00 +0200 Message-ID: Subject: Coherent bus_dma for ARMv7 To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 14:01:02 -0000 Hi, In current FreeBSD-HEAD ARMv7 platforms, which support hardware IO cache coherency cannot make use of this feature. In our project we implemented coherent variant bus_dma, which is basing on x86 and arm64 approach. Using of above solution is not obligatory and depends on setting newly added option for that purpose. Needless to say, our platform (Marvell Armada 38x) IO performance boosted after switching to it. Do you wish to enable such option in HEAD? Regards, Marcin From owner-freebsd-arm@freebsd.org Fri Mar 31 14:05:09 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F54FD2733C for ; Fri, 31 Mar 2017 14:05:09 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EB5016B5 for ; Fri, 31 Mar 2017 14:05:08 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-io0-x232.google.com with SMTP id b140so40266803iof.1 for ; Fri, 31 Mar 2017 07:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Dr4C4+06ZK39jo1tUcV8FiM6AZ2pnLY5x0T2/NN4OOE=; b=rrGSKlWURSE8Nuajnyij+EW1Tfon5yvPzN3yB5QEuHtxspAb+TlXGuZWpl8CzY024E /WnGZ1qD3sPdkoVzYBccA65mF7VIN1U/pu65l2CQIXa9TfYAKZ8o5va4C2kqzMw2INnH eomnbNvN2ViWANwhiDxk5h8fs6BclCE3DTrlK59UvG2ywI0Nwt9kOWHYJ+6+BLF6sJnV B53Y7749Z638/tQG+zlvI/MRKZ5oHInW+x9cbW6XyRtjvwklrTkTG88cKDuziBbZgRs4 9dPuMnnZ02azva0FaTYPDpQW5UviVhNcG6VYmIB+ULpwYu/ZOBN8O2bLfLU0oR+Q0jrv Z5iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Dr4C4+06ZK39jo1tUcV8FiM6AZ2pnLY5x0T2/NN4OOE=; b=hnuk2prpgPvLZ5vWMVMbp3h1NCgRUAu5CyPBEem4Aghn/nn5HuiQaQ4YqVgPaxWOQL b3Ni3gv/Q1p+0shhsOR9gnky12UwlNx+/lAvTOi1zGYl1EMVdmsL/9z+o5V7Wd+ACRtx 4K0me7uf7u2JpCbrC3LzFTy1Po0SRRgMpIxEFOnYb/rzH6HZnMcKE/UhYH2Tpz6EQF5H st2km10nOj9m2ejp9Os+HyYvHSf1D0PwzYiZkar3p9ge5MKI5QCTvH2AekKnuh572Gto ufkgw9lhM3By5Cjz44fZX0BDAOCu2Y4jood2xGZwUHO5n9ERqgS4RWzRVeGImqDKOdMX KZew== X-Gm-Message-State: AFeK/H1/+SXNlPGcfcx2T2lGn3QL2fiR1vuJBYQBBHpcHQq7Y0+gZvVofMtCWc7bMpmLwc/7yuXfMzvoSyB/VA== X-Received: by 10.107.134.94 with SMTP id i91mr3282109iod.0.1490969108000; Fri, 31 Mar 2017 07:05:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.146 with HTTP; Fri, 31 Mar 2017 07:05:07 -0700 (PDT) In-Reply-To: References: From: Marcin Wojtas Date: Fri, 31 Mar 2017 16:05:07 +0200 Message-ID: Subject: Re: Coherent bus_dma for ARMv7 To: freebsd-arm@freebsd.org Content-Type: multipart/mixed; boundary=001a113ec89c0de2a2054c074ca8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 14:05:09 -0000 --001a113ec89c0de2a2054c074ca8 Content-Type: text/plain; charset=UTF-8 Patch with the coherent bus_dma support attached. Marcin 2017-03-31 16:01 GMT+02:00 Marcin Wojtas : > Hi, > > In current FreeBSD-HEAD ARMv7 platforms, which support hardware IO > cache coherency cannot make use of this feature. In our project we > implemented coherent variant bus_dma, which is basing on x86 and arm64 > approach. Using of above solution is not obligatory and depends on > setting newly added option for that purpose. > > Needless to say, our platform (Marvell Armada 38x) IO performance > boosted after switching to it. Do you wish to enable such option in > HEAD? > > Regards, > Marcin --001a113ec89c0de2a2054c074ca8 Content-Type: application/octet-stream; name="0001-Introduce-preliminary-version-of-coherent-DMA-for-AR.patch" Content-Disposition: attachment; filename="0001-Introduce-preliminary-version-of-coherent-DMA-for-AR.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j0xwi9m40 RnJvbSBlMjJiZTYzNTQ0MGEwYzNiNWY3OTdjMmNkNGNkOThmODUxNmMyZjE1IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBaYmlnbmlldyBCb2RlayA8emJiQHNlbWloYWxmLmNvbT4KRGF0 ZTogV2VkLCAyNCBBdWcgMjAxNiAyMTowMTowOSArMDIwMApTdWJqZWN0OiBbUEFUQ0hdIEludHJv ZHVjZSBwcmVsaW1pbmFyeSB2ZXJzaW9uIG9mIGNvaGVyZW50IERNQSBmb3IgQVJNCgotIEJhc2Vk IG9uIHg4NiBpbXBsZW1lbnRhdGlvbiB3aXRoIGJ1c19kbWFtYXBfc3luYygpCiAgaW5zcGlyZWQg YnkgYXJtNjQgb25lLgotIE5vdCBzdXJlIHdoeSBEU0Igd2FzIHVzZWQgaW5zdGVhZCBvZiBETUIg YnV0IHRoaXMgc2hvdWxkCiAgbm90IGNhdXNlIGFueSBpbXBhY3Qgb24gZGF0YSB2YWxpZGl0eSBi dXQgcmF0aGVyIG9uIHNwZWVkLgotLS0KIHN5cy9hcm0vYXJtL2J1c2RtYV9ib3VuY2UuYyAgICAg ICAgICAgfCAxMDg4ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKwogc3lzL2FybS9h cm0vYnVzZG1hX21hY2hkZXAtY29oZXJlbnQuYyB8ICAzNTkgKysrKysrKysrKysKIHN5cy9hcm0v aW5jbHVkZS9idXNkbWFfaW1wbC5oICAgICAgICAgfCAgIDk2ICsrKwogc3lzL2NvbmYvZmlsZXMu YXJtICAgICAgICAgICAgICAgICAgICB8ICAgIDYgKy0KIHN5cy9jb25mL29wdGlvbnMuYXJtICAg ICAgICAgICAgICAgICAgfCAgICAxICsKIDUgZmlsZXMgY2hhbmdlZCwgMTU0OCBpbnNlcnRpb25z KCspLCAyIGRlbGV0aW9ucygtKQogY3JlYXRlIG1vZGUgMTAwNjQ0IHN5cy9hcm0vYXJtL2J1c2Rt YV9ib3VuY2UuYwogY3JlYXRlIG1vZGUgMTAwNjQ0IHN5cy9hcm0vYXJtL2J1c2RtYV9tYWNoZGVw LWNvaGVyZW50LmMKIGNyZWF0ZSBtb2RlIDEwMDY0NCBzeXMvYXJtL2luY2x1ZGUvYnVzZG1hX2lt cGwuaAoKZGlmZiAtLWdpdCBhL3N5cy9hcm0vYXJtL2J1c2RtYV9ib3VuY2UuYyBiL3N5cy9hcm0v YXJtL2J1c2RtYV9ib3VuY2UuYwpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi4x M2Q3OTdhCi0tLSAvZGV2L251bGwKKysrIGIvc3lzL2FybS9hcm0vYnVzZG1hX2JvdW5jZS5jCkBA IC0wLDAgKzEsMTA4OCBAQAorLyotCisgKiBDb3B5cmlnaHQgKGMpIDE5OTcsIDE5OTggSnVzdGlu IFQuIEdpYmJzLgorICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlv biBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAq IG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcg Y29uZGl0aW9ucworICogYXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2Ug Y29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMg bGlzdCBvZiBjb25kaXRpb25zLCBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLAorICogICAg d2l0aG91dCBtb2RpZmljYXRpb24sIGltbWVkaWF0ZWx5IGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhl IGZpbGUuCisgKiAyLiBUaGUgbmFtZSBvZiB0aGUgYXV0aG9yIG1heSBub3QgYmUgdXNlZCB0byBl bmRvcnNlIG9yIHByb21vdGUgcHJvZHVjdHMKKyAqICAgIGRlcml2ZWQgZnJvbSB0aGlzIHNvZnR3 YXJlIHdpdGhvdXQgc3BlY2lmaWMgcHJpb3Igd3JpdHRlbiBwZXJtaXNzaW9uLgorICoKKyAqIFRI SVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIEFVVEhPUiBBTkQgQ09OVFJJQlVUT1JTIGBg QVMgSVMnJyBBTkQKKyAqIEFOWSBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVE SU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRQorICogSU1QTElFRCBXQVJSQU5USUVTIE9GIE1F UkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UKKyAqIEFS RSBESVNDTEFJTUVELiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQVVUSE9SIE9SIENPTlRSSUJVVE9S UyBCRSBMSUFCTEUgRk9SCisgKiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BF Q0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCisgKiBEQU1BR0VTIChJTkNMVURJTkcs IEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUworICog T1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJ TlRFUlJVUFRJT04pCisgKiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFC SUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAorICogTElBQklMSVRZLCBPUiBUT1JU IChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQor ICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRI RSBQT1NTSUJJTElUWSBPRgorICogU1VDSCBEQU1BR0UuCisgKi8KKworI2luY2x1ZGUgPHN5cy9j ZGVmcy5oPgorX19GQlNESUQoIiRGcmVlQlNEJCIpOworCisjaW5jbHVkZSA8c3lzL3BhcmFtLmg+ CisjaW5jbHVkZSA8c3lzL3N5c3RtLmg+CisjaW5jbHVkZSA8c3lzL21hbGxvYy5oPgorI2luY2x1 ZGUgPHN5cy9idXMuaD4KKyNpbmNsdWRlIDxzeXMvaW50ZXJydXB0Lmg+CisjaW5jbHVkZSA8c3lz L2tlcm5lbC5oPgorI2luY2x1ZGUgPHN5cy9rdHIuaD4KKyNpbmNsdWRlIDxzeXMvbG9jay5oPgor I2luY2x1ZGUgPHN5cy9wcm9jLmg+CisjaW5jbHVkZSA8c3lzL21lbWRlc2MuaD4KKyNpbmNsdWRl IDxzeXMvbXV0ZXguaD4KKyNpbmNsdWRlIDxzeXMvc3lzY3RsLmg+CisjaW5jbHVkZSA8c3lzL3Vp by5oPgorCisjaW5jbHVkZSA8dm0vdm0uaD4KKyNpbmNsdWRlIDx2bS92bV9leHRlcm4uaD4KKyNp bmNsdWRlIDx2bS92bV9rZXJuLmg+CisjaW5jbHVkZSA8dm0vdm1fcGFnZS5oPgorI2luY2x1ZGUg PHZtL3ZtX21hcC5oPgorCisjaW5jbHVkZSA8bWFjaGluZS9hdG9taWMuaD4KKyNpbmNsdWRlIDxt YWNoaW5lL2J1cy5oPgorI2luY2x1ZGUgPG1hY2hpbmUvbWRfdmFyLmg+CisjaW5jbHVkZSA8bWFj aGluZS9idXNkbWFfaW1wbC5oPgorCisjZGVmaW5lIE1BWF9CUEFHRVMgNjQKKworZW51bSB7CisJ QlVTX0RNQV9DT1VMRF9CT1VOQ0UJPSAweDAxLAorCUJVU19ETUFfTUlOX0FMTE9DX0NPTVAJPSAw eDAyLAorCUJVU19ETUFfS01FTV9BTExPQwk9IDB4MDQsCit9OworCitzdHJ1Y3QgYm91bmNlX3pv bmU7CisKK3N0cnVjdCBidXNfZG1hX3RhZyB7CisJc3RydWN0IGJ1c19kbWFfdGFnX2NvbW1vbiBj b21tb247CisJaW50CQkJbWFwX2NvdW50OworCWludAkJCWJvdW5jZV9mbGFnczsKKwlidXNfZG1h X3NlZ21lbnRfdAkqc2VnbWVudHM7CisJc3RydWN0IGJvdW5jZV96b25lCSpib3VuY2Vfem9uZTsK K307CisKK3N0cnVjdCBib3VuY2VfcGFnZSB7CisJdm1fb2Zmc2V0X3QJdmFkZHI7CQkvKiBrdmEg b2YgYm91bmNlIGJ1ZmZlciAqLworCWJ1c19hZGRyX3QJYnVzYWRkcjsJLyogUGh5c2ljYWwgYWRk cmVzcyAqLworCXZtX29mZnNldF90CWRhdGF2YWRkcjsJLyoga3ZhIG9mIGNsaWVudCBkYXRhICov CisJYnVzX2FkZHJfdAlkYXRhYWRkcjsJLyogY2xpZW50IHBoeXNpY2FsIGFkZHJlc3MgKi8KKwli dXNfc2l6ZV90CWRhdGFjb3VudDsJLyogY2xpZW50IGRhdGEgY291bnQgKi8KKwlTVEFJTFFfRU5U UlkoYm91bmNlX3BhZ2UpIGxpbmtzOworfTsKKworaW50IGJ1c2RtYV9zd2lfcGVuZGluZzsKKwor c3RydWN0IGJvdW5jZV96b25lIHsKKwlTVEFJTFFfRU5UUlkoYm91bmNlX3pvbmUpIGxpbmtzOwor CVNUQUlMUV9IRUFEKGJwX2xpc3QsIGJvdW5jZV9wYWdlKSBib3VuY2VfcGFnZV9saXN0OworCWlu dAkJdG90YWxfYnBhZ2VzOworCWludAkJZnJlZV9icGFnZXM7CisJaW50CQlyZXNlcnZlZF9icGFn ZXM7CisJaW50CQlhY3RpdmVfYnBhZ2VzOworCWludAkJdG90YWxfYm91bmNlZDsKKwlpbnQJCXRv dGFsX2RlZmVycmVkOworCWludAkJbWFwX2NvdW50OworCWJ1c19zaXplX3QJYWxpZ25tZW50Owor CWJ1c19hZGRyX3QJbG93YWRkcjsKKwljaGFyCQl6b25laWRbOF07CisJY2hhcgkJbG93YWRkcmlk WzIwXTsKKwlzdHJ1Y3Qgc3lzY3RsX2N0eF9saXN0IHN5c2N0bF90cmVlOworCXN0cnVjdCBzeXNj dGxfb2lkICpzeXNjdGxfdHJlZV90b3A7Cit9OworCitzdGF0aWMgc3RydWN0IG10eCBib3VuY2Vf bG9jazsKK3N0YXRpYyBpbnQgdG90YWxfYnBhZ2VzOworc3RhdGljIGludCBidXNkbWFfem9uZWNv dW50Oworc3RhdGljIFNUQUlMUV9IRUFEKCwgYm91bmNlX3pvbmUpIGJvdW5jZV96b25lX2xpc3Q7 CisKK3N0YXRpYyBTWVNDVExfTk9ERShfaHcsIE9JRF9BVVRPLCBidXNkbWEsIENUTEZMQUdfUkQs IDAsICJCdXNkbWEgcGFyYW1ldGVycyIpOworU1lTQ1RMX0lOVChfaHdfYnVzZG1hLCBPSURfQVVU TywgdG90YWxfYnBhZ2VzLCBDVExGTEFHX1JELCAmdG90YWxfYnBhZ2VzLCAwLAorCSAgICJUb3Rh bCBib3VuY2UgcGFnZXMiKTsKKworc3RydWN0IGJ1c19kbWFtYXAgeworCXN0cnVjdCBicF9saXN0 CSAgICAgICBicGFnZXM7CisJaW50CQkgICAgICAgcGFnZXNuZWVkZWQ7CisJaW50CQkgICAgICAg cGFnZXNyZXNlcnZlZDsKKwlidXNfZG1hX3RhZ190CSAgICAgICBkbWF0OworCXN0cnVjdCBtZW1k ZXNjCSAgICAgICBtZW07CisJYnVzX2RtYW1hcF9jYWxsYmFja190ICpjYWxsYmFjazsKKwl2b2lk CQkgICAgICAqY2FsbGJhY2tfYXJnOworCVNUQUlMUV9FTlRSWShidXNfZG1hbWFwKSBsaW5rczsK K307CisKK3N0YXRpYyBTVEFJTFFfSEVBRCgsIGJ1c19kbWFtYXApIGJvdW5jZV9tYXBfd2FpdGlu Z2xpc3Q7CitzdGF0aWMgU1RBSUxRX0hFQUQoLCBidXNfZG1hbWFwKSBib3VuY2VfbWFwX2NhbGxi YWNrbGlzdDsKK3N0YXRpYyBzdHJ1Y3QgYnVzX2RtYW1hcCBub2JvdW5jZV9kbWFtYXA7CisKK3N0 YXRpYyB2b2lkIGluaXRfYm91bmNlX3BhZ2VzKHZvaWQgKmR1bW15KTsKK3N0YXRpYyBpbnQgYWxs b2NfYm91bmNlX3pvbmUoYnVzX2RtYV90YWdfdCBkbWF0KTsKK3N0YXRpYyBpbnQgYWxsb2NfYm91 bmNlX3BhZ2VzKGJ1c19kbWFfdGFnX3QgZG1hdCwgdV9pbnQgbnVtcGFnZXMpOworc3RhdGljIGlu dCByZXNlcnZlX2JvdW5jZV9wYWdlcyhidXNfZG1hX3RhZ190IGRtYXQsIGJ1c19kbWFtYXBfdCBt YXAsCisJCQkJaW50IGNvbW1pdCk7CitzdGF0aWMgYnVzX2FkZHJfdCBhZGRfYm91bmNlX3BhZ2Uo YnVzX2RtYV90YWdfdCBkbWF0LCBidXNfZG1hbWFwX3QgbWFwLAorCQkJCSAgdm1fb2Zmc2V0X3Qg dmFkZHIsIGJ1c19hZGRyX3QgYWRkciwKKwkJCQkgIGJ1c19zaXplX3Qgc2l6ZSk7CitzdGF0aWMg dm9pZCBmcmVlX2JvdW5jZV9wYWdlKGJ1c19kbWFfdGFnX3QgZG1hdCwgc3RydWN0IGJvdW5jZV9w YWdlICpicGFnZSk7CitpbnQgcnVuX2ZpbHRlcihidXNfZG1hX3RhZ190IGRtYXQsIGJ1c19hZGRy X3QgcGFkZHIpOworc3RhdGljIHZvaWQgX2J1c19kbWFtYXBfY291bnRfcGFnZXMoYnVzX2RtYV90 YWdfdCBkbWF0LCBidXNfZG1hbWFwX3QgbWFwLAorCQkJCSAgICBwbWFwX3QgcG1hcCwgdm9pZCAq YnVmLCBidXNfc2l6ZV90IGJ1ZmxlbiwKKwkJCQkgICAgaW50IGZsYWdzKTsKK3N0YXRpYyB2b2lk IF9idXNfZG1hbWFwX2NvdW50X3BoeXMoYnVzX2RtYV90YWdfdCBkbWF0LCBidXNfZG1hbWFwX3Qg bWFwLAorCQkJCSAgIHZtX3BhZGRyX3QgYnVmLCBidXNfc2l6ZV90IGJ1ZmxlbiwKKwkJCQkgICBp bnQgZmxhZ3MpOworc3RhdGljIGludCBfYnVzX2RtYW1hcF9yZXNlcnZlX3BhZ2VzKGJ1c19kbWFf dGFnX3QgZG1hdCwgYnVzX2RtYW1hcF90IG1hcCwKKwkJCQkgICAgIGludCBmbGFncyk7CisvKgor ICogQWxsb2NhdGUgYSBkZXZpY2Ugc3BlY2lmaWMgZG1hX3RhZy4KKyAqLworc3RhdGljIGludAor Ym91bmNlX2J1c19kbWFfdGFnX2NyZWF0ZShidXNfZG1hX3RhZ190IHBhcmVudCwgYnVzX3NpemVf dCBhbGlnbm1lbnQsCisgICAgYnVzX2FkZHJfdCBib3VuZGFyeSwgYnVzX2FkZHJfdCBsb3dhZGRy LCBidXNfYWRkcl90IGhpZ2hhZGRyLAorICAgIGJ1c19kbWFfZmlsdGVyX3QgKmZpbHRlciwgdm9p ZCAqZmlsdGVyYXJnLCBidXNfc2l6ZV90IG1heHNpemUsCisgICAgaW50IG5zZWdtZW50cywgYnVz X3NpemVfdCBtYXhzZWdzeiwgaW50IGZsYWdzLCBidXNfZG1hX2xvY2tfdCAqbG9ja2Z1bmMsCisg ICAgdm9pZCAqbG9ja2Z1bmNhcmcsIGJ1c19kbWFfdGFnX3QgKmRtYXQpCit7CisJYnVzX2RtYV90 YWdfdCBuZXd0YWc7CisJaW50IGVycm9yOworCisJKmRtYXQgPSBOVUxMOworCWVycm9yID0gY29t bW9uX2J1c19kbWFfdGFnX2NyZWF0ZShwYXJlbnQgIT0gTlVMTCA/ICZwYXJlbnQtPmNvbW1vbiA6 CisJICAgIE5VTEwsIGFsaWdubWVudCwgYm91bmRhcnksIGxvd2FkZHIsIGhpZ2hhZGRyLCBmaWx0 ZXIsIGZpbHRlcmFyZywKKwkgICAgbWF4c2l6ZSwgbnNlZ21lbnRzLCBtYXhzZWdzeiwgZmxhZ3Ms IGxvY2tmdW5jLCBsb2NrZnVuY2FyZywKKwkgICAgc2l6ZW9mIChzdHJ1Y3QgYnVzX2RtYV90YWcp LCAodm9pZCAqKikmbmV3dGFnKTsKKwlpZiAoZXJyb3IgIT0gMCkKKwkJcmV0dXJuIChlcnJvcik7 CisKKwluZXd0YWctPmNvbW1vbi5pbXBsID0gJmJ1c19kbWFfYm91bmNlX2ltcGw7CisJbmV3dGFn LT5tYXBfY291bnQgPSAwOworCW5ld3RhZy0+c2VnbWVudHMgPSBOVUxMOworCisJaWYgKHBhcmVu dCAhPSBOVUxMICYmICgobmV3dGFnLT5jb21tb24uZmlsdGVyICE9IE5VTEwpIHx8CisJICAgICgo cGFyZW50LT5ib3VuY2VfZmxhZ3MgJiBCVVNfRE1BX0NPVUxEX0JPVU5DRSkgIT0gMCkpKQorCQlu ZXd0YWctPmJvdW5jZV9mbGFncyB8PSBCVVNfRE1BX0NPVUxEX0JPVU5DRTsKKworCWlmIChuZXd0 YWctPmNvbW1vbi5sb3dhZGRyIDwgcHRvYSgodm1fcGFkZHJfdClNYXhtZW0pIHx8CisJICAgIG5l d3RhZy0+Y29tbW9uLmFsaWdubWVudCA+IDEpCisJCW5ld3RhZy0+Ym91bmNlX2ZsYWdzIHw9IEJV U19ETUFfQ09VTERfQk9VTkNFOworCisJaWYgKCgobmV3dGFnLT5ib3VuY2VfZmxhZ3MgJiBCVVNf RE1BX0NPVUxEX0JPVU5DRSkgIT0gMCkgJiYKKwkgICAgKGZsYWdzICYgQlVTX0RNQV9BTExPQ05P VykgIT0gMCkgeworCQlzdHJ1Y3QgYm91bmNlX3pvbmUgKmJ6OworCisJCS8qIE11c3QgYm91bmNl ICovCisJCWlmICgoZXJyb3IgPSBhbGxvY19ib3VuY2Vfem9uZShuZXd0YWcpKSAhPSAwKSB7CisJ CQlmcmVlKG5ld3RhZywgTV9ERVZCVUYpOworCQkJcmV0dXJuIChlcnJvcik7CisJCX0KKwkJYnog PSBuZXd0YWctPmJvdW5jZV96b25lOworCisJCWlmIChwdG9hKGJ6LT50b3RhbF9icGFnZXMpIDwg bWF4c2l6ZSkgeworCQkJaW50IHBhZ2VzOworCisJCQlwYWdlcyA9IGF0b3AobWF4c2l6ZSkgLSBi ei0+dG90YWxfYnBhZ2VzOworCisJCQkvKiBBZGQgcGFnZXMgdG8gb3VyIGJvdW5jZSBwb29sICov CisJCQlpZiAoYWxsb2NfYm91bmNlX3BhZ2VzKG5ld3RhZywgcGFnZXMpIDwgcGFnZXMpCisJCQkJ ZXJyb3IgPSBFTk9NRU07CisJCX0KKwkJLyogUGVyZm9ybWVkIGluaXRpYWwgYWxsb2NhdGlvbiAq LworCQluZXd0YWctPmJvdW5jZV9mbGFncyB8PSBCVVNfRE1BX01JTl9BTExPQ19DT01QOworCX0g ZWxzZQorCQllcnJvciA9IDA7CisJCisJaWYgKGVycm9yICE9IDApCisJCWZyZWUobmV3dGFnLCBN X0RFVkJVRik7CisJZWxzZQorCQkqZG1hdCA9IG5ld3RhZzsKKwlDVFI0KEtUUl9CVVNETUEsICIl cyByZXR1cm5lZCB0YWcgJXAgdGFnIGZsYWdzIDB4JXggZXJyb3IgJWQiLAorCSAgICBfX2Z1bmNf XywgbmV3dGFnLCAobmV3dGFnICE9IE5VTEwgPyBuZXd0YWctPmNvbW1vbi5mbGFncyA6IDApLAor CSAgICBlcnJvcik7CisJcmV0dXJuIChlcnJvcik7Cit9CisKK3N0YXRpYyBpbnQKK2JvdW5jZV9i dXNfZG1hX3RhZ19kZXN0cm95KGJ1c19kbWFfdGFnX3QgZG1hdCkKK3sKKwlidXNfZG1hX3RhZ190 IGRtYXRfY29weSwgcGFyZW50OworCWludCBlcnJvcjsKKworCWVycm9yID0gMDsKKwlkbWF0X2Nv cHkgPSBkbWF0OworCisJaWYgKGRtYXQgIT0gTlVMTCkgeworCQlpZiAoZG1hdC0+bWFwX2NvdW50 ICE9IDApIHsKKwkJCWVycm9yID0gRUJVU1k7CisJCQlnb3RvIG91dDsKKwkJfQorCQl3aGlsZSAo ZG1hdCAhPSBOVUxMKSB7CisJCQlwYXJlbnQgPSAoYnVzX2RtYV90YWdfdClkbWF0LT5jb21tb24u cGFyZW50OworCQkJYXRvbWljX3N1YnRyYWN0X2ludCgmZG1hdC0+Y29tbW9uLnJlZl9jb3VudCwg MSk7CisJCQlpZiAoZG1hdC0+Y29tbW9uLnJlZl9jb3VudCA9PSAwKSB7CisJCQkJaWYgKGRtYXQt PnNlZ21lbnRzICE9IE5VTEwpCisJCQkJCWZyZWUoZG1hdC0+c2VnbWVudHMsIE1fREVWQlVGKTsK KwkJCQlmcmVlKGRtYXQsIE1fREVWQlVGKTsKKwkJCQkvKgorCQkJCSAqIExhc3QgcmVmZXJlbmNl IGNvdW50LCBzbworCQkJCSAqIHJlbGVhc2Ugb3VyIHJlZmVyZW5jZQorCQkJCSAqIGNvdW50IG9u IG91ciBwYXJlbnQuCisJCQkJICovCisJCQkJZG1hdCA9IHBhcmVudDsKKwkJCX0gZWxzZQorCQkJ CWRtYXQgPSBOVUxMOworCQl9CisJfQorb3V0OgorCUNUUjMoS1RSX0JVU0RNQSwgIiVzIHRhZyAl cCBlcnJvciAlZCIsIF9fZnVuY19fLCBkbWF0X2NvcHksIGVycm9yKTsKKwlyZXR1cm4gKGVycm9y KTsKK30KKworLyoKKyAqIEFsbG9jYXRlIGEgaGFuZGxlIGZvciBtYXBwaW5nIGZyb20ga3ZhL3V2 YS9waHlzaWNhbAorICogYWRkcmVzcyBzcGFjZSBpbnRvIGJ1cyBkZXZpY2Ugc3BhY2UuCisgKi8K K3N0YXRpYyBpbnQKK2JvdW5jZV9idXNfZG1hbWFwX2NyZWF0ZShidXNfZG1hX3RhZ190IGRtYXQs IGludCBmbGFncywgYnVzX2RtYW1hcF90ICptYXBwKQoreworCXN0cnVjdCBib3VuY2Vfem9uZSAq Yno7CisJaW50IGVycm9yLCBtYXhwYWdlcywgcGFnZXM7CisKKwllcnJvciA9IDA7CisKKwlpZiAo ZG1hdC0+c2VnbWVudHMgPT0gTlVMTCkgeworCQlkbWF0LT5zZWdtZW50cyA9IChidXNfZG1hX3Nl Z21lbnRfdCAqKW1hbGxvYygKKwkJICAgIHNpemVvZihidXNfZG1hX3NlZ21lbnRfdCkgKiBkbWF0 LT5jb21tb24ubnNlZ21lbnRzLAorCQkgICAgTV9ERVZCVUYsIE1fTk9XQUlUKTsKKwkJaWYgKGRt YXQtPnNlZ21lbnRzID09IE5VTEwpIHsKKwkJCUNUUjMoS1RSX0JVU0RNQSwgIiVzOiB0YWcgJXAg ZXJyb3IgJWQiLAorCQkJICAgIF9fZnVuY19fLCBkbWF0LCBFTk9NRU0pOworCQkJcmV0dXJuIChF Tk9NRU0pOworCQl9CisJfQorCisJLyoKKwkgKiBCb3VuY2luZyBtaWdodCBiZSByZXF1aXJlZCBp ZiB0aGUgZHJpdmVyIGFza3MgZm9yIGFuIGFjdGl2ZQorCSAqIGV4Y2x1c2lvbiByZWdpb24sIGEg ZGF0YSBhbGlnbm1lbnQgdGhhdCBpcyBzdHJpY3RlciB0aGFuIDEsIGFuZC9vcgorCSAqIGFuIGFj dGl2ZSBhZGRyZXNzIGJvdW5kYXJ5LgorCSAqLworCWlmIChkbWF0LT5ib3VuY2VfZmxhZ3MgJiBC VVNfRE1BX0NPVUxEX0JPVU5DRSkgeworCQkvKiBNdXN0IGJvdW5jZSAqLworCQlpZiAoZG1hdC0+ Ym91bmNlX3pvbmUgPT0gTlVMTCkgeworCQkJaWYgKChlcnJvciA9IGFsbG9jX2JvdW5jZV96b25l KGRtYXQpKSAhPSAwKQorCQkJCXJldHVybiAoZXJyb3IpOworCQl9CisJCWJ6ID0gZG1hdC0+Ym91 bmNlX3pvbmU7CisKKwkJKm1hcHAgPSAoYnVzX2RtYW1hcF90KW1hbGxvYyhzaXplb2YoKiptYXBw KSwgTV9ERVZCVUYsCisJCSAgICBNX05PV0FJVCB8IE1fWkVSTyk7CisJCWlmICgqbWFwcCA9PSBO VUxMKSB7CisJCQlDVFIzKEtUUl9CVVNETUEsICIlczogdGFnICVwIGVycm9yICVkIiwKKwkJCSAg ICBfX2Z1bmNfXywgZG1hdCwgRU5PTUVNKTsKKwkJCXJldHVybiAoRU5PTUVNKTsKKwkJfQorCisJ CS8qIEluaXRpYWxpemUgdGhlIG5ldyBtYXAgKi8KKwkJU1RBSUxRX0lOSVQoJigoKm1hcHApLT5i cGFnZXMpKTsKKworCQkvKgorCQkgKiBBdHRlbXB0IHRvIGFkZCBwYWdlcyB0byBvdXIgcG9vbCBv biBhIHBlci1pbnN0YW5jZQorCQkgKiBiYXNpcyB1cCB0byBhIHNhbmUgbGltaXQuCisJCSAqLwor CQlpZiAoZG1hdC0+Y29tbW9uLmFsaWdubWVudCA+IDEpCisJCQltYXhwYWdlcyA9IE1BWF9CUEFH RVM7CisJCWVsc2UKKwkJCW1heHBhZ2VzID0gTUlOKE1BWF9CUEFHRVMsIE1heG1lbSAtCisJCQkg ICAgYXRvcChkbWF0LT5jb21tb24ubG93YWRkcikpOworCQlpZiAoKGRtYXQtPmJvdW5jZV9mbGFn cyAmIEJVU19ETUFfTUlOX0FMTE9DX0NPTVApID09IDAgfHwKKwkJICAgIChiei0+bWFwX2NvdW50 ID4gMCAmJiBiei0+dG90YWxfYnBhZ2VzIDwgbWF4cGFnZXMpKSB7CisJCQlwYWdlcyA9IE1BWChh dG9wKGRtYXQtPmNvbW1vbi5tYXhzaXplKSwgMSk7CisJCQlwYWdlcyA9IE1JTihtYXhwYWdlcyAt IGJ6LT50b3RhbF9icGFnZXMsIHBhZ2VzKTsKKwkJCXBhZ2VzID0gTUFYKHBhZ2VzLCAxKTsKKwkJ CWlmIChhbGxvY19ib3VuY2VfcGFnZXMoZG1hdCwgcGFnZXMpIDwgcGFnZXMpCisJCQkJZXJyb3Ig PSBFTk9NRU07CisJCQlpZiAoKGRtYXQtPmJvdW5jZV9mbGFncyAmIEJVU19ETUFfTUlOX0FMTE9D X0NPTVApCisJCQkgICAgPT0gMCkgeworCQkJCWlmIChlcnJvciA9PSAwKSB7CisJCQkJCWRtYXQt PmJvdW5jZV9mbGFncyB8PQorCQkJCQkgICAgQlVTX0RNQV9NSU5fQUxMT0NfQ09NUDsKKwkJCQl9 CisJCQl9IGVsc2UKKwkJCQllcnJvciA9IDA7CisJCX0KKwkJYnotPm1hcF9jb3VudCsrOworCX0g ZWxzZSB7CisJCSptYXBwID0gTlVMTDsKKwl9CisJaWYgKGVycm9yID09IDApCisJCWRtYXQtPm1h cF9jb3VudCsrOworCUNUUjQoS1RSX0JVU0RNQSwgIiVzOiB0YWcgJXAgdGFnIGZsYWdzIDB4JXgg ZXJyb3IgJWQiLAorCSAgICBfX2Z1bmNfXywgZG1hdCwgZG1hdC0+Y29tbW9uLmZsYWdzLCBlcnJv cik7CisJcmV0dXJuIChlcnJvcik7Cit9CisKKy8qCisgKiBEZXN0cm95IGEgaGFuZGxlIGZvciBt YXBwaW5nIGZyb20ga3ZhL3V2YS9waHlzaWNhbAorICogYWRkcmVzcyBzcGFjZSBpbnRvIGJ1cyBk ZXZpY2Ugc3BhY2UuCisgKi8KK3N0YXRpYyBpbnQKK2JvdW5jZV9idXNfZG1hbWFwX2Rlc3Ryb3ko YnVzX2RtYV90YWdfdCBkbWF0LCBidXNfZG1hbWFwX3QgbWFwKQoreworCisJaWYgKG1hcCAhPSBO VUxMICYmIG1hcCAhPSAmbm9ib3VuY2VfZG1hbWFwKSB7CisJCWlmIChTVEFJTFFfRklSU1QoJm1h cC0+YnBhZ2VzKSAhPSBOVUxMKSB7CisJCQlDVFIzKEtUUl9CVVNETUEsICIlczogdGFnICVwIGVy cm9yICVkIiwKKwkJCSAgICBfX2Z1bmNfXywgZG1hdCwgRUJVU1kpOworCQkJcmV0dXJuIChFQlVT WSk7CisJCX0KKwkJaWYgKGRtYXQtPmJvdW5jZV96b25lKQorCQkJZG1hdC0+Ym91bmNlX3pvbmUt Pm1hcF9jb3VudC0tOworCQlmcmVlKG1hcCwgTV9ERVZCVUYpOworCX0KKwlkbWF0LT5tYXBfY291 bnQtLTsKKwlDVFIyKEtUUl9CVVNETUEsICIlczogdGFnICVwIGVycm9yIDAiLCBfX2Z1bmNfXywg ZG1hdCk7CisJcmV0dXJuICgwKTsKK30KKworCisvKgorICogQWxsb2NhdGUgYSBwaWVjZSBvZiBt ZW1vcnkgdGhhdCBjYW4gYmUgZWZmaWNpZW50bHkgbWFwcGVkIGludG8KKyAqIGJ1cyBkZXZpY2Ug c3BhY2UgYmFzZWQgb24gdGhlIGNvbnN0cmFpbnRzIGxpdGVkIGluIHRoZSBkbWEgdGFnLgorICog QSBkbWFtYXAgdG8gZm9yIHVzZSB3aXRoIGRtYW1hcF9sb2FkIGlzIGFsc28gYWxsb2NhdGVkLgor ICovCitzdGF0aWMgaW50Citib3VuY2VfYnVzX2RtYW1lbV9hbGxvYyhidXNfZG1hX3RhZ190IGRt YXQsIHZvaWQqKiB2YWRkciwgaW50IGZsYWdzLAorICAgIGJ1c19kbWFtYXBfdCAqbWFwcCkKK3sK Kwl2bV9tZW1hdHRyX3QgYXR0cjsKKwlpbnQgbWZsYWdzOworCisJaWYgKGZsYWdzICYgQlVTX0RN QV9OT1dBSVQpCisJCW1mbGFncyA9IE1fTk9XQUlUOworCWVsc2UKKwkJbWZsYWdzID0gTV9XQUlU T0s7CisKKwkvKiBJZiB3ZSBzdWNjZWVkLCBubyBtYXBwaW5nL2JvdW5jaW5nIHdpbGwgYmUgcmVx dWlyZWQgKi8KKwkqbWFwcCA9IE5VTEw7CisKKwlpZiAoZG1hdC0+c2VnbWVudHMgPT0gTlVMTCkg eworCQlkbWF0LT5zZWdtZW50cyA9IChidXNfZG1hX3NlZ21lbnRfdCAqKW1hbGxvYygKKwkJICAg IHNpemVvZihidXNfZG1hX3NlZ21lbnRfdCkgKiBkbWF0LT5jb21tb24ubnNlZ21lbnRzLAorCQkg ICAgTV9ERVZCVUYsIG1mbGFncyk7CisJCWlmIChkbWF0LT5zZWdtZW50cyA9PSBOVUxMKSB7CisJ CQlDVFI0KEtUUl9CVVNETUEsICIlczogdGFnICVwIHRhZyBmbGFncyAweCV4IGVycm9yICVkIiwK KwkJCSAgICBfX2Z1bmNfXywgZG1hdCwgZG1hdC0+Y29tbW9uLmZsYWdzLCBFTk9NRU0pOworCQkJ cmV0dXJuIChFTk9NRU0pOworCQl9CisJfQorCWlmIChmbGFncyAmIEJVU19ETUFfWkVSTykKKwkJ bWZsYWdzIHw9IE1fWkVSTzsKKwlpZiAoZmxhZ3MgJiBCVVNfRE1BX05PQ0FDSEUpCisJCWF0dHIg PSBWTV9NRU1BVFRSX1VOQ0FDSEVBQkxFOworCWVsc2UKKwkJYXR0ciA9IFZNX01FTUFUVFJfREVG QVVMVDsKKworCS8qIAorCSAqIFhYWDoKKwkgKiAoZG1hdC0+YWxpZ25tZW50IDw9IGRtYXQtPm1h eHNpemUpIGlzIGp1c3QgYSBxdWljayBoYWNrOyB0aGUgZXhhY3QKKwkgKiBhbGlnbm1lbnQgZ3Vh cmFudGVlcyBvZiBtYWxsb2MgbmVlZCB0byBiZSBuYWlsZWQgZG93biwgYW5kIHRoZQorCSAqIGNv ZGUgYmVsb3cgc2hvdWxkIGJlIHJld3JpdHRlbiB0byB0YWtlIHRoYXQgaW50byBhY2NvdW50Lgor CSAqCisJICogSW4gdGhlIG1lYW50aW1lLCB3ZSdsbCB3YXJuIHRoZSB1c2VyIGlmIG1hbGxvYyBn ZXRzIGl0IHdyb25nLgorCSAqLworCWlmICgoZG1hdC0+Y29tbW9uLm1heHNpemUgPD0gUEFHRV9T SVpFKSAmJgorCSAgIChkbWF0LT5jb21tb24uYWxpZ25tZW50IDw9IGRtYXQtPmNvbW1vbi5tYXhz aXplKSAmJgorCSAgICBkbWF0LT5jb21tb24ubG93YWRkciA+PSBwdG9hKCh2bV9wYWRkcl90KU1h eG1lbSkgJiYKKwkgICAgYXR0ciA9PSBWTV9NRU1BVFRSX0RFRkFVTFQpIHsKKwkJKnZhZGRyID0g bWFsbG9jKGRtYXQtPmNvbW1vbi5tYXhzaXplLCBNX0RFVkJVRiwgbWZsYWdzKTsKKwl9IGVsc2Ug aWYgKGRtYXQtPmNvbW1vbi5uc2VnbWVudHMgPj0gYnRvYyhkbWF0LT5jb21tb24ubWF4c2l6ZSkg JiYKKwkgICAgZG1hdC0+Y29tbW9uLmFsaWdubWVudCA8PSBQQUdFX1NJWkUgJiYKKwkgICAgKGRt YXQtPmNvbW1vbi5ib3VuZGFyeSA9PSAwIHx8CisJICAgIGRtYXQtPmNvbW1vbi5ib3VuZGFyeSA+ PSBkbWF0LT5jb21tb24ubG93YWRkcikpIHsKKwkJLyogUGFnZS1iYXNlZCBtdWx0aS1zZWdtZW50 IGFsbG9jYXRpb25zIGFsbG93ZWQgKi8KKwkJKnZhZGRyID0gKHZvaWQgKilrbWVtX2FsbG9jX2F0 dHIoa2VybmVsX2FyZW5hLAorCQkgICAgZG1hdC0+Y29tbW9uLm1heHNpemUsIG1mbGFncywgMHVs LCBkbWF0LT5jb21tb24ubG93YWRkciwKKwkJICAgIGF0dHIpOworCQlkbWF0LT5ib3VuY2VfZmxh Z3MgfD0gQlVTX0RNQV9LTUVNX0FMTE9DOworCX0gZWxzZSB7CisJCSp2YWRkciA9ICh2b2lkICop a21lbV9hbGxvY19jb250aWcoa2VybmVsX2FyZW5hLAorCQkgICAgZG1hdC0+Y29tbW9uLm1heHNp emUsIG1mbGFncywgMHVsLCBkbWF0LT5jb21tb24ubG93YWRkciwKKwkJICAgIGRtYXQtPmNvbW1v bi5hbGlnbm1lbnQgIT0gMCA/IGRtYXQtPmNvbW1vbi5hbGlnbm1lbnQgOiAxdWwsCisJCSAgICBk bWF0LT5jb21tb24uYm91bmRhcnksIGF0dHIpOworCQlkbWF0LT5ib3VuY2VfZmxhZ3MgfD0gQlVT X0RNQV9LTUVNX0FMTE9DOworCX0KKwlpZiAoKnZhZGRyID09IE5VTEwpIHsKKwkJQ1RSNChLVFJf QlVTRE1BLCAiJXM6IHRhZyAlcCB0YWcgZmxhZ3MgMHgleCBlcnJvciAlZCIsCisJCSAgICBfX2Z1 bmNfXywgZG1hdCwgZG1hdC0+Y29tbW9uLmZsYWdzLCBFTk9NRU0pOworCQlyZXR1cm4gKEVOT01F TSk7CisJfSBlbHNlIGlmICh2dG9waHlzKCp2YWRkcikgJiAoZG1hdC0+Y29tbW9uLmFsaWdubWVu dCAtIDEpKSB7CisJCXByaW50ZigiYnVzX2RtYW1lbV9hbGxvYyBmYWlsZWQgdG8gYWxpZ24gbWVt b3J5IHByb3Blcmx5LlxuIik7CisJfQorCUNUUjQoS1RSX0JVU0RNQSwgIiVzOiB0YWcgJXAgdGFn IGZsYWdzIDB4JXggZXJyb3IgJWQiLAorCSAgICBfX2Z1bmNfXywgZG1hdCwgZG1hdC0+Y29tbW9u LmZsYWdzLCAwKTsKKwlyZXR1cm4gKDApOworfQorCisvKgorICogRnJlZSBhIHBpZWNlIG9mIG1l bW9yeSBhbmQgaXQncyBhbGxvY2lhdGVkIGRtYW1hcCwgdGhhdCB3YXMgYWxsb2NhdGVkCisgKiB2 aWEgYnVzX2RtYW1lbV9hbGxvYy4gIE1ha2UgdGhlIHNhbWUgY2hvaWNlIGZvciBmcmVlL2NvbnRp Z2ZyZWUuCisgKi8KK3N0YXRpYyB2b2lkCitib3VuY2VfYnVzX2RtYW1lbV9mcmVlKGJ1c19kbWFf dGFnX3QgZG1hdCwgdm9pZCAqdmFkZHIsIGJ1c19kbWFtYXBfdCBtYXApCit7CisJLyoKKwkgKiBk bWFtZW0gZG9lcyBub3QgbmVlZCB0byBiZSBib3VuY2VkLCBzbyB0aGUgbWFwIHNob3VsZCBiZQor CSAqIE5VTEwgYW5kIHRoZSBCVVNfRE1BX0tNRU1fQUxMT0MgZmxhZyBjbGVhcmVkIGlmIG1hbGxv YygpCisJICogd2FzIHVzZWQgYW5kIHNldCBpZiBrbWVtX2FsbG9jX2NvbnRpZygpIHdhcyB1c2Vk LgorCSAqLworCWlmIChtYXAgIT0gTlVMTCkKKwkJcGFuaWMoImJ1c19kbWFtZW1fZnJlZTogSW52 YWxpZCBtYXAgZnJlZWRcbiIpOworCWlmICgoZG1hdC0+Ym91bmNlX2ZsYWdzICYgQlVTX0RNQV9L TUVNX0FMTE9DKSA9PSAwKQorCQlmcmVlKHZhZGRyLCBNX0RFVkJVRik7CisJZWxzZQorCQlrbWVt X2ZyZWUoa2VybmVsX2FyZW5hLCAodm1fb2Zmc2V0X3QpdmFkZHIsCisJCSAgICBkbWF0LT5jb21t b24ubWF4c2l6ZSk7CisJQ1RSMyhLVFJfQlVTRE1BLCAiJXM6IHRhZyAlcCBmbGFncyAweCV4Iiwg X19mdW5jX18sIGRtYXQsCisJICAgIGRtYXQtPmJvdW5jZV9mbGFncyk7Cit9CisKK3N0YXRpYyB2 b2lkCitfYnVzX2RtYW1hcF9jb3VudF9waHlzKGJ1c19kbWFfdGFnX3QgZG1hdCwgYnVzX2RtYW1h cF90IG1hcCwgdm1fcGFkZHJfdCBidWYsCisgICAgYnVzX3NpemVfdCBidWZsZW4sIGludCBmbGFn cykKK3sKKwlidXNfYWRkcl90IGN1cmFkZHI7CisJYnVzX3NpemVfdCBzZ3NpemU7CisKKwlpZiAo KG1hcCAhPSAmbm9ib3VuY2VfZG1hbWFwICYmIG1hcC0+cGFnZXNuZWVkZWQgPT0gMCkpIHsKKwkJ LyoKKwkJICogQ291bnQgdGhlIG51bWJlciBvZiBib3VuY2UgcGFnZXMKKwkJICogbmVlZGVkIGlu IG9yZGVyIHRvIGNvbXBsZXRlIHRoaXMgdHJhbnNmZXIKKwkJICovCisJCWN1cmFkZHIgPSBidWY7 CisJCXdoaWxlIChidWZsZW4gIT0gMCkgeworCQkJc2dzaXplID0gTUlOKGJ1ZmxlbiwgZG1hdC0+ Y29tbW9uLm1heHNlZ3N6KTsKKwkJCWlmIChidXNfZG1hX3J1bl9maWx0ZXIoJmRtYXQtPmNvbW1v biwgY3VyYWRkcikpIHsKKwkJCQlzZ3NpemUgPSBNSU4oc2dzaXplLCBQQUdFX1NJWkUpOworCQkJ CW1hcC0+cGFnZXNuZWVkZWQrKzsKKwkJCX0KKwkJCWN1cmFkZHIgKz0gc2dzaXplOworCQkJYnVm bGVuIC09IHNnc2l6ZTsKKwkJfQorCQlDVFIxKEtUUl9CVVNETUEsICJwYWdlc25lZWRlZD0gJWRc biIsIG1hcC0+cGFnZXNuZWVkZWQpOworCX0KK30KKworc3RhdGljIHZvaWQKK19idXNfZG1hbWFw X2NvdW50X3BhZ2VzKGJ1c19kbWFfdGFnX3QgZG1hdCwgYnVzX2RtYW1hcF90IG1hcCwgcG1hcF90 IHBtYXAsCisgICAgdm9pZCAqYnVmLCBidXNfc2l6ZV90IGJ1ZmxlbiwgaW50IGZsYWdzKQorewor CXZtX29mZnNldF90IHZhZGRyOworCXZtX29mZnNldF90IHZlbmRhZGRyOworCWJ1c19hZGRyX3Qg cGFkZHI7CisJYnVzX3NpemVfdCBzZ19sZW47CisKKwlpZiAoKG1hcCAhPSAmbm9ib3VuY2VfZG1h bWFwICYmIG1hcC0+cGFnZXNuZWVkZWQgPT0gMCkpIHsKKwkJQ1RSNChLVFJfQlVTRE1BLCAibG93 YWRkcj0gJWQgTWF4bWVtPSAlZCwgYm91bmRhcnk9ICVkLCAiCisJCSAgICAiYWxpZ25tZW50PSAl ZCIsIGRtYXQtPmNvbW1vbi5sb3dhZGRyLAorCQkgICAgcHRvYSgodm1fcGFkZHJfdClNYXhtZW0p LAorCQkgICAgZG1hdC0+Y29tbW9uLmJvdW5kYXJ5LCBkbWF0LT5jb21tb24uYWxpZ25tZW50KTsK KwkJQ1RSMyhLVFJfQlVTRE1BLCAibWFwPSAlcCwgbm9ib3VuY2VtYXA9ICVwLCBwYWdlc25lZWRl ZD0gJWQiLAorCQkgICAgbWFwLCAmbm9ib3VuY2VfZG1hbWFwLCBtYXAtPnBhZ2VzbmVlZGVkKTsK KwkJLyoKKwkJICogQ291bnQgdGhlIG51bWJlciBvZiBib3VuY2UgcGFnZXMKKwkJICogbmVlZGVk IGluIG9yZGVyIHRvIGNvbXBsZXRlIHRoaXMgdHJhbnNmZXIKKwkJICovCisJCXZhZGRyID0gKHZt X29mZnNldF90KWJ1ZjsKKwkJdmVuZGFkZHIgPSAodm1fb2Zmc2V0X3QpYnVmICsgYnVmbGVuOwor CisJCXdoaWxlICh2YWRkciA8IHZlbmRhZGRyKSB7CisJCQlzZ19sZW4gPSBQQUdFX1NJWkUgLSAo KHZtX29mZnNldF90KXZhZGRyICYgUEFHRV9NQVNLKTsKKwkJCWlmIChwbWFwID09IGtlcm5lbF9w bWFwKQorCQkJCXBhZGRyID0gcG1hcF9rZXh0cmFjdCh2YWRkcik7CisJCQllbHNlCisJCQkJcGFk ZHIgPSBwbWFwX2V4dHJhY3QocG1hcCwgdmFkZHIpOworCQkJaWYgKGJ1c19kbWFfcnVuX2ZpbHRl cigmZG1hdC0+Y29tbW9uLCBwYWRkcikgIT0gMCkgeworCQkJCXNnX2xlbiA9IHJvdW5kdXAyKHNn X2xlbiwKKwkJCQkgICAgZG1hdC0+Y29tbW9uLmFsaWdubWVudCk7CisJCQkJbWFwLT5wYWdlc25l ZWRlZCsrOworCQkJfQorCQkJdmFkZHIgKz0gc2dfbGVuOworCQl9CisJCUNUUjEoS1RSX0JVU0RN QSwgInBhZ2VzbmVlZGVkPSAlZFxuIiwgbWFwLT5wYWdlc25lZWRlZCk7CisJfQorfQorCitzdGF0 aWMgaW50CitfYnVzX2RtYW1hcF9yZXNlcnZlX3BhZ2VzKGJ1c19kbWFfdGFnX3QgZG1hdCwgYnVz X2RtYW1hcF90IG1hcCwgaW50IGZsYWdzKQoreworCisJLyogUmVzZXJ2ZSBOZWNlc3NhcnkgQm91 bmNlIFBhZ2VzICovCisJbXR4X2xvY2soJmJvdW5jZV9sb2NrKTsKKwlpZiAoZmxhZ3MgJiBCVVNf RE1BX05PV0FJVCkgeworCQlpZiAocmVzZXJ2ZV9ib3VuY2VfcGFnZXMoZG1hdCwgbWFwLCAwKSAh PSAwKSB7CisJCQltdHhfdW5sb2NrKCZib3VuY2VfbG9jayk7CisJCQlyZXR1cm4gKEVOT01FTSk7 CisJCX0KKwl9IGVsc2UgeworCQlpZiAocmVzZXJ2ZV9ib3VuY2VfcGFnZXMoZG1hdCwgbWFwLCAx KSAhPSAwKSB7CisJCQkvKiBRdWV1ZSB1cyBmb3IgcmVzb3VyY2VzICovCisJCQlTVEFJTFFfSU5T RVJUX1RBSUwoJmJvdW5jZV9tYXBfd2FpdGluZ2xpc3QsIG1hcCwgbGlua3MpOworCQkJbXR4X3Vu bG9jaygmYm91bmNlX2xvY2spOworCQkJcmV0dXJuIChFSU5QUk9HUkVTUyk7CisJCX0KKwl9CisJ bXR4X3VubG9jaygmYm91bmNlX2xvY2spOworCisJcmV0dXJuICgwKTsKK30KKworLyoKKyAqIEFk ZCBhIHNpbmdsZSBjb250aWd1b3VzIHBoeXNpY2FsIHJhbmdlIHRvIHRoZSBzZWdtZW50IGxpc3Qu CisgKi8KK3N0YXRpYyBpbnQKK19idXNfZG1hbWFwX2FkZHNlZyhidXNfZG1hX3RhZ190IGRtYXQs IGJ1c19kbWFtYXBfdCBtYXAsIGJ1c19hZGRyX3QgY3VyYWRkciwKKyAgICBidXNfc2l6ZV90IHNn c2l6ZSwgYnVzX2RtYV9zZWdtZW50X3QgKnNlZ3MsIGludCAqc2VncCkKK3sKKwlidXNfYWRkcl90 IGJhZGRyLCBibWFzazsKKwlpbnQgc2VnOworCisJLyoKKwkgKiBNYWtlIHN1cmUgd2UgZG9uJ3Qg Y3Jvc3MgYW55IGJvdW5kYXJpZXMuCisJICovCisJYm1hc2sgPSB+KGRtYXQtPmNvbW1vbi5ib3Vu ZGFyeSAtIDEpOworCWlmIChkbWF0LT5jb21tb24uYm91bmRhcnkgPiAwKSB7CisJCWJhZGRyID0g KGN1cmFkZHIgKyBkbWF0LT5jb21tb24uYm91bmRhcnkpICYgYm1hc2s7CisJCWlmIChzZ3NpemUg PiAoYmFkZHIgLSBjdXJhZGRyKSkKKwkJCXNnc2l6ZSA9IChiYWRkciAtIGN1cmFkZHIpOworCX0K KworCS8qCisJICogSW5zZXJ0IGNodW5rIGludG8gYSBzZWdtZW50LCBjb2FsZXNjaW5nIHdpdGgK KwkgKiBwcmV2aW91cyBzZWdtZW50IGlmIHBvc3NpYmxlLgorCSAqLworCXNlZyA9ICpzZWdwOwor CWlmIChzZWcgPT0gLTEpIHsKKwkJc2VnID0gMDsKKwkJc2Vnc1tzZWddLmRzX2FkZHIgPSBjdXJh ZGRyOworCQlzZWdzW3NlZ10uZHNfbGVuID0gc2dzaXplOworCX0gZWxzZSB7CisJCWlmIChjdXJh ZGRyID09IHNlZ3Nbc2VnXS5kc19hZGRyICsgc2Vnc1tzZWddLmRzX2xlbiAmJgorCQkgICAgKHNl Z3Nbc2VnXS5kc19sZW4gKyBzZ3NpemUpIDw9IGRtYXQtPmNvbW1vbi5tYXhzZWdzeiAmJgorCQkg ICAgKGRtYXQtPmNvbW1vbi5ib3VuZGFyeSA9PSAwIHx8CisJCSAgICAgKHNlZ3Nbc2VnXS5kc19h ZGRyICYgYm1hc2spID09IChjdXJhZGRyICYgYm1hc2spKSkKKwkJCXNlZ3Nbc2VnXS5kc19sZW4g Kz0gc2dzaXplOworCQllbHNlIHsKKwkJCWlmICgrK3NlZyA+PSBkbWF0LT5jb21tb24ubnNlZ21l bnRzKQorCQkJCXJldHVybiAoMCk7CisJCQlzZWdzW3NlZ10uZHNfYWRkciA9IGN1cmFkZHI7CisJ CQlzZWdzW3NlZ10uZHNfbGVuID0gc2dzaXplOworCQl9CisJfQorCSpzZWdwID0gc2VnOworCXJl dHVybiAoc2dzaXplKTsKK30KKworLyoKKyAqIFV0aWxpdHkgZnVuY3Rpb24gdG8gbG9hZCBhIHBo eXNpY2FsIGJ1ZmZlci4gIHNlZ3AgY29udGFpbnMKKyAqIHRoZSBzdGFydGluZyBzZWdtZW50IG9u IGVudHJhY2UsIGFuZCB0aGUgZW5kaW5nIHNlZ21lbnQgb24gZXhpdC4KKyAqLworc3RhdGljIGlu dAorYm91bmNlX2J1c19kbWFtYXBfbG9hZF9waHlzKGJ1c19kbWFfdGFnX3QgZG1hdCwgYnVzX2Rt YW1hcF90IG1hcCwKKyAgICB2bV9wYWRkcl90IGJ1ZiwgYnVzX3NpemVfdCBidWZsZW4sIGludCBm bGFncywgYnVzX2RtYV9zZWdtZW50X3QgKnNlZ3MsCisgICAgaW50ICpzZWdwKQoreworCWJ1c19z aXplX3Qgc2dzaXplOworCWJ1c19hZGRyX3QgY3VyYWRkcjsKKwlpbnQgZXJyb3I7CisKKwlpZiAo bWFwID09IE5VTEwpCisJCW1hcCA9ICZub2JvdW5jZV9kbWFtYXA7CisKKwlpZiAoc2VncyA9PSBO VUxMKQorCQlzZWdzID0gZG1hdC0+c2VnbWVudHM7CisKKwlpZiAoKGRtYXQtPmJvdW5jZV9mbGFn cyAmIEJVU19ETUFfQ09VTERfQk9VTkNFKSAhPSAwKSB7CisJCV9idXNfZG1hbWFwX2NvdW50X3Bo eXMoZG1hdCwgbWFwLCBidWYsIGJ1ZmxlbiwgZmxhZ3MpOworCQlpZiAobWFwLT5wYWdlc25lZWRl ZCAhPSAwKSB7CisJCQllcnJvciA9IF9idXNfZG1hbWFwX3Jlc2VydmVfcGFnZXMoZG1hdCwgbWFw LCBmbGFncyk7CisJCQlpZiAoZXJyb3IpCisJCQkJcmV0dXJuIChlcnJvcik7CisJCX0KKwl9CisK Kwl3aGlsZSAoYnVmbGVuID4gMCkgeworCQljdXJhZGRyID0gYnVmOworCQlzZ3NpemUgPSBNSU4o YnVmbGVuLCBkbWF0LT5jb21tb24ubWF4c2Vnc3opOworCQlpZiAoKChkbWF0LT5ib3VuY2VfZmxh Z3MgJiBCVVNfRE1BX0NPVUxEX0JPVU5DRSkgIT0gMCkgJiYKKwkJICAgIG1hcC0+cGFnZXNuZWVk ZWQgIT0gMCAmJgorCQkgICAgYnVzX2RtYV9ydW5fZmlsdGVyKCZkbWF0LT5jb21tb24sIGN1cmFk ZHIpKSB7CisJCQlzZ3NpemUgPSBNSU4oc2dzaXplLCBQQUdFX1NJWkUpOworCQkJY3VyYWRkciA9 IGFkZF9ib3VuY2VfcGFnZShkbWF0LCBtYXAsIDAsIGN1cmFkZHIsCisJCQkgICAgc2dzaXplKTsK KwkJfQorCQlzZ3NpemUgPSBfYnVzX2RtYW1hcF9hZGRzZWcoZG1hdCwgbWFwLCBjdXJhZGRyLCBz Z3NpemUsIHNlZ3MsCisJCSAgICBzZWdwKTsKKwkJaWYgKHNnc2l6ZSA9PSAwKQorCQkJYnJlYWs7 CisJCWJ1ZiArPSBzZ3NpemU7CisJCWJ1ZmxlbiAtPSBzZ3NpemU7CisJfQorCisJLyoKKwkgKiBE aWQgd2UgZml0PworCSAqLworCXJldHVybiAoYnVmbGVuICE9IDAgPyBFRkJJRyA6IDApOyAvKiBY WFggYmV0dGVyIHJldHVybiB2YWx1ZSBoZXJlPyAqLworfQorCisvKgorICogVXRpbGl0eSBmdW5j dGlvbiB0byBsb2FkIGEgbGluZWFyIGJ1ZmZlci4gIHNlZ3AgY29udGFpbnMKKyAqIHRoZSBzdGFy dGluZyBzZWdtZW50IG9uIGVudHJhY2UsIGFuZCB0aGUgZW5kaW5nIHNlZ21lbnQgb24gZXhpdC4K KyAqLworc3RhdGljIGludAorYm91bmNlX2J1c19kbWFtYXBfbG9hZF9idWZmZXIoYnVzX2RtYV90 YWdfdCBkbWF0LCBidXNfZG1hbWFwX3QgbWFwLCB2b2lkICpidWYsCisgICAgYnVzX3NpemVfdCBi dWZsZW4sIHBtYXBfdCBwbWFwLCBpbnQgZmxhZ3MsIGJ1c19kbWFfc2VnbWVudF90ICpzZWdzLAor ICAgIGludCAqc2VncCkKK3sKKwlidXNfc2l6ZV90IHNnc2l6ZSwgbWF4X3Nnc2l6ZTsKKwlidXNf YWRkcl90IGN1cmFkZHI7CisJdm1fb2Zmc2V0X3QgdmFkZHI7CisJaW50IGVycm9yOworCisJaWYg KG1hcCA9PSBOVUxMKQorCQltYXAgPSAmbm9ib3VuY2VfZG1hbWFwOworCisJaWYgKHNlZ3MgPT0g TlVMTCkKKwkJc2VncyA9IGRtYXQtPnNlZ21lbnRzOworCisJaWYgKChkbWF0LT5ib3VuY2VfZmxh Z3MgJiBCVVNfRE1BX0NPVUxEX0JPVU5DRSkgIT0gMCkgeworCQlfYnVzX2RtYW1hcF9jb3VudF9w YWdlcyhkbWF0LCBtYXAsIHBtYXAsIGJ1ZiwgYnVmbGVuLCBmbGFncyk7CisJCWlmIChtYXAtPnBh Z2VzbmVlZGVkICE9IDApIHsKKwkJCWVycm9yID0gX2J1c19kbWFtYXBfcmVzZXJ2ZV9wYWdlcyhk bWF0LCBtYXAsIGZsYWdzKTsKKwkJCWlmIChlcnJvcikKKwkJCQlyZXR1cm4gKGVycm9yKTsKKwkJ fQorCX0KKworCXZhZGRyID0gKHZtX29mZnNldF90KWJ1ZjsKKwl3aGlsZSAoYnVmbGVuID4gMCkg eworCQkvKgorCQkgKiBHZXQgdGhlIHBoeXNpY2FsIGFkZHJlc3MgZm9yIHRoaXMgc2VnbWVudC4K KwkJICovCisJCWlmIChwbWFwID09IGtlcm5lbF9wbWFwKQorCQkJY3VyYWRkciA9IHBtYXBfa2V4 dHJhY3QodmFkZHIpOworCQllbHNlCisJCQljdXJhZGRyID0gcG1hcF9leHRyYWN0KHBtYXAsIHZh ZGRyKTsKKworCQkvKgorCQkgKiBDb21wdXRlIHRoZSBzZWdtZW50IHNpemUsIGFuZCBhZGp1c3Qg Y291bnRzLgorCQkgKi8KKwkJbWF4X3Nnc2l6ZSA9IE1JTihidWZsZW4sIGRtYXQtPmNvbW1vbi5t YXhzZWdzeik7CisJCXNnc2l6ZSA9IFBBR0VfU0laRSAtICgodm1fb2Zmc2V0X3QpY3VyYWRkciAm IFBBR0VfTUFTSyk7CisJCWlmICgoKGRtYXQtPmJvdW5jZV9mbGFncyAmIEJVU19ETUFfQ09VTERf Qk9VTkNFKSAhPSAwKSAmJgorCQkgICAgbWFwLT5wYWdlc25lZWRlZCAhPSAwICYmCisJCSAgICBi dXNfZG1hX3J1bl9maWx0ZXIoJmRtYXQtPmNvbW1vbiwgY3VyYWRkcikpIHsKKwkJCXNnc2l6ZSA9 IHJvdW5kdXAyKHNnc2l6ZSwgZG1hdC0+Y29tbW9uLmFsaWdubWVudCk7CisJCQlzZ3NpemUgPSBN SU4oc2dzaXplLCBtYXhfc2dzaXplKTsKKwkJCWN1cmFkZHIgPSBhZGRfYm91bmNlX3BhZ2UoZG1h dCwgbWFwLCB2YWRkciwgY3VyYWRkciwKKwkJCSAgICBzZ3NpemUpOworCQl9IGVsc2UgeworCQkJ c2dzaXplID0gTUlOKHNnc2l6ZSwgbWF4X3Nnc2l6ZSk7CisJCX0KKwkJc2dzaXplID0gX2J1c19k bWFtYXBfYWRkc2VnKGRtYXQsIG1hcCwgY3VyYWRkciwgc2dzaXplLCBzZWdzLAorCQkgICAgc2Vn cCk7CisJCWlmIChzZ3NpemUgPT0gMCkKKwkJCWJyZWFrOworCQl2YWRkciArPSBzZ3NpemU7CisJ CWJ1ZmxlbiAtPSBzZ3NpemU7CisJfQorCisJLyoKKwkgKiBEaWQgd2UgZml0PworCSAqLworCXJl dHVybiAoYnVmbGVuICE9IDAgPyBFRkJJRyA6IDApOyAvKiBYWFggYmV0dGVyIHJldHVybiB2YWx1 ZSBoZXJlPyAqLworfQorCitzdGF0aWMgdm9pZAorYm91bmNlX2J1c19kbWFtYXBfd2FpdG9rKGJ1 c19kbWFfdGFnX3QgZG1hdCwgYnVzX2RtYW1hcF90IG1hcCwKKyAgICBzdHJ1Y3QgbWVtZGVzYyAq bWVtLCBidXNfZG1hbWFwX2NhbGxiYWNrX3QgKmNhbGxiYWNrLCB2b2lkICpjYWxsYmFja19hcmcp Cit7CisKKwlpZiAobWFwID09IE5VTEwpCisJCXJldHVybjsKKwltYXAtPm1lbSA9ICptZW07CisJ bWFwLT5kbWF0ID0gZG1hdDsKKwltYXAtPmNhbGxiYWNrID0gY2FsbGJhY2s7CisJbWFwLT5jYWxs YmFja19hcmcgPSBjYWxsYmFja19hcmc7Cit9CisKK3N0YXRpYyBidXNfZG1hX3NlZ21lbnRfdCAq Citib3VuY2VfYnVzX2RtYW1hcF9jb21wbGV0ZShidXNfZG1hX3RhZ190IGRtYXQsIGJ1c19kbWFt YXBfdCBtYXAsCisgICAgYnVzX2RtYV9zZWdtZW50X3QgKnNlZ3MsIGludCBuc2VncywgaW50IGVy cm9yKQoreworCisJaWYgKHNlZ3MgPT0gTlVMTCkKKwkJc2VncyA9IGRtYXQtPnNlZ21lbnRzOwor CXJldHVybiAoc2Vncyk7Cit9CisKKy8qCisgKiBSZWxlYXNlIHRoZSBtYXBwaW5nIGhlbGQgYnkg bWFwLgorICovCitzdGF0aWMgdm9pZAorYm91bmNlX2J1c19kbWFtYXBfdW5sb2FkKGJ1c19kbWFf dGFnX3QgZG1hdCwgYnVzX2RtYW1hcF90IG1hcCkKK3sKKwlzdHJ1Y3QgYm91bmNlX3BhZ2UgKmJw YWdlOworCisJaWYgKG1hcCA9PSBOVUxMKQorCQlyZXR1cm47CisKKwl3aGlsZSAoKGJwYWdlID0g U1RBSUxRX0ZJUlNUKCZtYXAtPmJwYWdlcykpICE9IE5VTEwpIHsKKwkJU1RBSUxRX1JFTU9WRV9I RUFEKCZtYXAtPmJwYWdlcywgbGlua3MpOworCQlmcmVlX2JvdW5jZV9wYWdlKGRtYXQsIGJwYWdl KTsKKwl9Cit9CisKK3N0YXRpYyB2b2lkCitib3VuY2VfYnVzX2RtYW1hcF9zeW5jKGJ1c19kbWFf dGFnX3QgZG1hdCwgYnVzX2RtYW1hcF90IG1hcCwKKyAgICBidXNfZG1hc3luY19vcF90IG9wKQor eworCXN0cnVjdCBib3VuY2VfcGFnZSAqYnBhZ2U7CisJLyoKKwkgKiBYWFg6CisJICogVGhpcyBi dXNfZG1hIGltcGxlbWVudGF0aW9uIHJlcXVpcmVzIElPLUNvaGVyZW50IGFyY2hpdGVjdXRyZS4K KwkgKiBJZiBJTy1Db2hlcmVuY3kgaXMgbm90IGd1YXJhbnRlZWQsIGNhY2hlIG9wZXJhdGlvbnMg aGF2ZSB0byBiZQorCSAqIGFkZGVkIHRvIHRoaXMgZnVuY3Rpb24uCisJICovCisKKwlpZiAob3Ag PT0gQlVTX0RNQVNZTkNfUE9TVFdSSVRFKQorCQlyZXR1cm47CisKKwlpZiAoKG9wICYgQlVTX0RN QVNZTkNfUE9TVFJFQUQpICE9IDApIHsKKwkJLyoKKwkJICogV2FpdCBmb3IgYW55IERNQSBvcGVy YXRpb25zIHRvIGNvbXBsZXRlIGJlZm9yZSB0aGUgYmNvcHkuCisJCSAqLworCQlkc2IoKTsKKwl9 CisKKwlpZiAoKGJwYWdlID0gU1RBSUxRX0ZJUlNUKCZtYXAtPmJwYWdlcykpICE9IE5VTEwpIHsK KwkJQ1RSNChLVFJfQlVTRE1BLCAiJXM6IHRhZyAlcCB0YWcgZmxhZ3MgMHgleCBvcCAweCV4ICIK KwkJICAgICJwZXJmb3JtaW5nIGJvdW5jZSIsIF9fZnVuY19fLCBkbWF0LCBkbWF0LT5jb21tb24u ZmxhZ3MsCisJCSAgICBvcCk7CisJCWlmICgob3AgJiBCVVNfRE1BU1lOQ19QUkVXUklURSkgIT0g MCkgeworCQkJd2hpbGUgKGJwYWdlICE9IE5VTEwpIHsKKwkJCQlpZiAoYnBhZ2UtPmRhdGF2YWRk ciAhPSAwKSB7CisJCQkJCWJjb3B5KCh2b2lkICopYnBhZ2UtPmRhdGF2YWRkciwKKwkJCQkJICAg ICh2b2lkICopYnBhZ2UtPnZhZGRyLAorCQkJCQkgICAgYnBhZ2UtPmRhdGFjb3VudCk7CisJCQkJ fSBlbHNlIHsKKwkJCQkJcGh5c2NvcHlvdXQoYnBhZ2UtPmRhdGFhZGRyLAorCQkJCQkgICAgKHZv aWQgKilicGFnZS0+dmFkZHIsCisJCQkJCSAgICBicGFnZS0+ZGF0YWNvdW50KTsKKwkJCQl9CisJ CQkJYnBhZ2UgPSBTVEFJTFFfTkVYVChicGFnZSwgbGlua3MpOworCQkJfQorCQkJZG1hdC0+Ym91 bmNlX3pvbmUtPnRvdGFsX2JvdW5jZWQrKzsKKwkJfQorCisJCWlmICgob3AgJiBCVVNfRE1BU1lO Q19QT1NUUkVBRCkgIT0gMCkgeworCQkJd2hpbGUgKGJwYWdlICE9IE5VTEwpIHsKKwkJCQlpZiAo YnBhZ2UtPmRhdGF2YWRkciAhPSAwKSB7CisJCQkJCWJjb3B5KCh2b2lkICopYnBhZ2UtPnZhZGRy LAorCQkJCQkgICAgKHZvaWQgKilicGFnZS0+ZGF0YXZhZGRyLAorCQkJCQkgICAgYnBhZ2UtPmRh dGFjb3VudCk7CisJCQkJfSBlbHNlIHsKKwkJCQkJcGh5c2NvcHlpbigodm9pZCAqKWJwYWdlLT52 YWRkciwKKwkJCQkJICAgIGJwYWdlLT5kYXRhYWRkciwgYnBhZ2UtPmRhdGFjb3VudCk7CisJCQkJ fQorCQkJCWJwYWdlID0gU1RBSUxRX05FWFQoYnBhZ2UsIGxpbmtzKTsKKwkJCX0KKwkJCWRtYXQt PmJvdW5jZV96b25lLT50b3RhbF9ib3VuY2VkKys7CisJCX0KKwl9CisKKwlpZiAoKG9wICYgQlVT X0RNQVNZTkNfUFJFV1JJVEUpICE9IDApIHsKKwkJLyoKKwkJICogV2FpdCBmb3IgdGhlIGJjb3B5 IHRvIGNvbXBsZXRlIGJlZm9yZSBhbnkgRE1BIG9wZXJhdGlvbnMuCisJCSAqLworCQlkc2IoKTsK Kwl9Cit9CisKK3N0YXRpYyB2b2lkCitpbml0X2JvdW5jZV9wYWdlcyh2b2lkICpkdW1teSBfX3Vu dXNlZCkKK3sKKworCXRvdGFsX2JwYWdlcyA9IDA7CisJU1RBSUxRX0lOSVQoJmJvdW5jZV96b25l X2xpc3QpOworCVNUQUlMUV9JTklUKCZib3VuY2VfbWFwX3dhaXRpbmdsaXN0KTsKKwlTVEFJTFFf SU5JVCgmYm91bmNlX21hcF9jYWxsYmFja2xpc3QpOworCW10eF9pbml0KCZib3VuY2VfbG9jaywg ImJvdW5jZSBwYWdlcyBsb2NrIiwgTlVMTCwgTVRYX0RFRik7Cit9CitTWVNJTklUKGJwYWdlcywg U0lfU1VCX0xPQ0ssIFNJX09SREVSX0FOWSwgaW5pdF9ib3VuY2VfcGFnZXMsIE5VTEwpOworCitz dGF0aWMgc3RydWN0IHN5c2N0bF9jdHhfbGlzdCAqCitidXNkbWFfc3lzY3RsX3RyZWUoc3RydWN0 IGJvdW5jZV96b25lICpieikKK3sKKworCXJldHVybiAoJmJ6LT5zeXNjdGxfdHJlZSk7Cit9CisK K3N0YXRpYyBzdHJ1Y3Qgc3lzY3RsX29pZCAqCitidXNkbWFfc3lzY3RsX3RyZWVfdG9wKHN0cnVj dCBib3VuY2Vfem9uZSAqYnopCit7CisKKwlyZXR1cm4gKGJ6LT5zeXNjdGxfdHJlZV90b3ApOwor fQorCitzdGF0aWMgaW50CithbGxvY19ib3VuY2Vfem9uZShidXNfZG1hX3RhZ190IGRtYXQpCit7 CisJc3RydWN0IGJvdW5jZV96b25lICpiejsKKworCS8qIENoZWNrIHRvIHNlZSBpZiB3ZSBhbHJl YWR5IGhhdmUgYSBzdWl0YWJsZSB6b25lICovCisJU1RBSUxRX0ZPUkVBQ0goYnosICZib3VuY2Vf em9uZV9saXN0LCBsaW5rcykgeworCQlpZiAoKGRtYXQtPmNvbW1vbi5hbGlnbm1lbnQgPD0gYnot PmFsaWdubWVudCkgJiYKKwkJICAgIChkbWF0LT5jb21tb24ubG93YWRkciA+PSBiei0+bG93YWRk cikpIHsKKwkJCWRtYXQtPmJvdW5jZV96b25lID0gYno7CisJCQlyZXR1cm4gKDApOworCQl9CisJ fQorCisJaWYgKChieiA9IChzdHJ1Y3QgYm91bmNlX3pvbmUgKiltYWxsb2Moc2l6ZW9mKCpieiks IE1fREVWQlVGLAorCSAgICBNX05PV0FJVCB8IE1fWkVSTykpID09IE5VTEwpCisJCXJldHVybiAo RU5PTUVNKTsKKworCVNUQUlMUV9JTklUKCZiei0+Ym91bmNlX3BhZ2VfbGlzdCk7CisJYnotPmZy ZWVfYnBhZ2VzID0gMDsKKwliei0+cmVzZXJ2ZWRfYnBhZ2VzID0gMDsKKwliei0+YWN0aXZlX2Jw YWdlcyA9IDA7CisJYnotPmxvd2FkZHIgPSBkbWF0LT5jb21tb24ubG93YWRkcjsKKwliei0+YWxp Z25tZW50ID0gTUFYKGRtYXQtPmNvbW1vbi5hbGlnbm1lbnQsIFBBR0VfU0laRSk7CisJYnotPm1h cF9jb3VudCA9IDA7CisJc25wcmludGYoYnotPnpvbmVpZCwgOCwgInpvbmUlZCIsIGJ1c2RtYV96 b25lY291bnQpOworCWJ1c2RtYV96b25lY291bnQrKzsKKwlzbnByaW50Zihiei0+bG93YWRkcmlk LCAxOCwgIiUjangiLCAodWludG1heF90KWJ6LT5sb3dhZGRyKTsKKwlTVEFJTFFfSU5TRVJUX1RB SUwoJmJvdW5jZV96b25lX2xpc3QsIGJ6LCBsaW5rcyk7CisJZG1hdC0+Ym91bmNlX3pvbmUgPSBi ejsKKworCXN5c2N0bF9jdHhfaW5pdCgmYnotPnN5c2N0bF90cmVlKTsKKwliei0+c3lzY3RsX3Ry ZWVfdG9wID0gU1lTQ1RMX0FERF9OT0RFKCZiei0+c3lzY3RsX3RyZWUsCisJICAgIFNZU0NUTF9T VEFUSUNfQ0hJTERSRU4oX2h3X2J1c2RtYSksIE9JRF9BVVRPLCBiei0+em9uZWlkLAorCSAgICBD VExGTEFHX1JELCAwLCAiIik7CisJaWYgKGJ6LT5zeXNjdGxfdHJlZV90b3AgPT0gTlVMTCkgewor CQlzeXNjdGxfY3R4X2ZyZWUoJmJ6LT5zeXNjdGxfdHJlZSk7CisJCXJldHVybiAoMCk7CS8qIFhY WCBlcnJvciBjb2RlPyAqLworCX0KKworCVNZU0NUTF9BRERfSU5UKGJ1c2RtYV9zeXNjdGxfdHJl ZShieiksCisJICAgIFNZU0NUTF9DSElMRFJFTihidXNkbWFfc3lzY3RsX3RyZWVfdG9wKGJ6KSks IE9JRF9BVVRPLAorCSAgICAidG90YWxfYnBhZ2VzIiwgQ1RMRkxBR19SRCwgJmJ6LT50b3RhbF9i cGFnZXMsIDAsCisJICAgICJUb3RhbCBib3VuY2UgcGFnZXMiKTsKKwlTWVNDVExfQUREX0lOVChi dXNkbWFfc3lzY3RsX3RyZWUoYnopLAorCSAgICBTWVNDVExfQ0hJTERSRU4oYnVzZG1hX3N5c2N0 bF90cmVlX3RvcChieikpLCBPSURfQVVUTywKKwkgICAgImZyZWVfYnBhZ2VzIiwgQ1RMRkxBR19S RCwgJmJ6LT5mcmVlX2JwYWdlcywgMCwKKwkgICAgIkZyZWUgYm91bmNlIHBhZ2VzIik7CisJU1lT Q1RMX0FERF9JTlQoYnVzZG1hX3N5c2N0bF90cmVlKGJ6KSwKKwkgICAgU1lTQ1RMX0NISUxEUkVO KGJ1c2RtYV9zeXNjdGxfdHJlZV90b3AoYnopKSwgT0lEX0FVVE8sCisJICAgICJyZXNlcnZlZF9i cGFnZXMiLCBDVExGTEFHX1JELCAmYnotPnJlc2VydmVkX2JwYWdlcywgMCwKKwkgICAgIlJlc2Vy dmVkIGJvdW5jZSBwYWdlcyIpOworCVNZU0NUTF9BRERfSU5UKGJ1c2RtYV9zeXNjdGxfdHJlZShi eiksCisJICAgIFNZU0NUTF9DSElMRFJFTihidXNkbWFfc3lzY3RsX3RyZWVfdG9wKGJ6KSksIE9J RF9BVVRPLAorCSAgICAiYWN0aXZlX2JwYWdlcyIsIENUTEZMQUdfUkQsICZiei0+YWN0aXZlX2Jw YWdlcywgMCwKKwkgICAgIkFjdGl2ZSBib3VuY2UgcGFnZXMiKTsKKwlTWVNDVExfQUREX0lOVChi dXNkbWFfc3lzY3RsX3RyZWUoYnopLAorCSAgICBTWVNDVExfQ0hJTERSRU4oYnVzZG1hX3N5c2N0 bF90cmVlX3RvcChieikpLCBPSURfQVVUTywKKwkgICAgInRvdGFsX2JvdW5jZWQiLCBDVExGTEFH X1JELCAmYnotPnRvdGFsX2JvdW5jZWQsIDAsCisJICAgICJUb3RhbCBib3VuY2UgcmVxdWVzdHMi KTsKKwlTWVNDVExfQUREX0lOVChidXNkbWFfc3lzY3RsX3RyZWUoYnopLAorCSAgICBTWVNDVExf Q0hJTERSRU4oYnVzZG1hX3N5c2N0bF90cmVlX3RvcChieikpLCBPSURfQVVUTywKKwkgICAgInRv dGFsX2RlZmVycmVkIiwgQ1RMRkxBR19SRCwgJmJ6LT50b3RhbF9kZWZlcnJlZCwgMCwKKwkgICAg IlRvdGFsIGJvdW5jZSByZXF1ZXN0cyB0aGF0IHdlcmUgZGVmZXJyZWQiKTsKKwlTWVNDVExfQURE X1NUUklORyhidXNkbWFfc3lzY3RsX3RyZWUoYnopLAorCSAgICBTWVNDVExfQ0hJTERSRU4oYnVz ZG1hX3N5c2N0bF90cmVlX3RvcChieikpLCBPSURfQVVUTywKKwkgICAgImxvd2FkZHIiLCBDVExG TEFHX1JELCBiei0+bG93YWRkcmlkLCAwLCAiIik7CisJU1lTQ1RMX0FERF9VQVVUTyhidXNkbWFf c3lzY3RsX3RyZWUoYnopLAorCSAgICBTWVNDVExfQ0hJTERSRU4oYnVzZG1hX3N5c2N0bF90cmVl X3RvcChieikpLCBPSURfQVVUTywKKwkgICAgImFsaWdubWVudCIsIENUTEZMQUdfUkQsICZiei0+ YWxpZ25tZW50LCAiIik7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CithbGxvY19i b3VuY2VfcGFnZXMoYnVzX2RtYV90YWdfdCBkbWF0LCB1X2ludCBudW1wYWdlcykKK3sKKwlzdHJ1 Y3QgYm91bmNlX3pvbmUgKmJ6OworCWludCBjb3VudDsKKworCWJ6ID0gZG1hdC0+Ym91bmNlX3pv bmU7CisJY291bnQgPSAwOworCXdoaWxlIChudW1wYWdlcyA+IDApIHsKKwkJc3RydWN0IGJvdW5j ZV9wYWdlICpicGFnZTsKKworCQlicGFnZSA9IChzdHJ1Y3QgYm91bmNlX3BhZ2UgKiltYWxsb2Mo c2l6ZW9mKCpicGFnZSksIE1fREVWQlVGLAorCQkJCQkJICAgICBNX05PV0FJVCB8IE1fWkVSTyk7 CisKKwkJaWYgKGJwYWdlID09IE5VTEwpCisJCQlicmVhazsKKwkJYnBhZ2UtPnZhZGRyID0gKHZt X29mZnNldF90KWNvbnRpZ21hbGxvYyhQQUdFX1NJWkUsIE1fREVWQlVGLAorCQkJCQkJCSBNX05P V0FJVCwgMHVsLAorCQkJCQkJCSBiei0+bG93YWRkciwKKwkJCQkJCQkgUEFHRV9TSVpFLAorCQkJ CQkJCSAwKTsKKwkJaWYgKGJwYWdlLT52YWRkciA9PSAwKSB7CisJCQlmcmVlKGJwYWdlLCBNX0RF VkJVRik7CisJCQlicmVhazsKKwkJfQorCQlicGFnZS0+YnVzYWRkciA9IHBtYXBfa2V4dHJhY3Qo YnBhZ2UtPnZhZGRyKTsKKwkJbXR4X2xvY2soJmJvdW5jZV9sb2NrKTsKKwkJU1RBSUxRX0lOU0VS VF9UQUlMKCZiei0+Ym91bmNlX3BhZ2VfbGlzdCwgYnBhZ2UsIGxpbmtzKTsKKwkJdG90YWxfYnBh Z2VzKys7CisJCWJ6LT50b3RhbF9icGFnZXMrKzsKKwkJYnotPmZyZWVfYnBhZ2VzKys7CisJCW10 eF91bmxvY2soJmJvdW5jZV9sb2NrKTsKKwkJY291bnQrKzsKKwkJbnVtcGFnZXMtLTsKKwl9CisJ cmV0dXJuIChjb3VudCk7Cit9CisKK3N0YXRpYyBpbnQKK3Jlc2VydmVfYm91bmNlX3BhZ2VzKGJ1 c19kbWFfdGFnX3QgZG1hdCwgYnVzX2RtYW1hcF90IG1hcCwgaW50IGNvbW1pdCkKK3sKKwlzdHJ1 Y3QgYm91bmNlX3pvbmUgKmJ6OworCWludCBwYWdlczsKKworCW10eF9hc3NlcnQoJmJvdW5jZV9s b2NrLCBNQV9PV05FRCk7CisJYnogPSBkbWF0LT5ib3VuY2Vfem9uZTsKKwlwYWdlcyA9IE1JTihi ei0+ZnJlZV9icGFnZXMsIG1hcC0+cGFnZXNuZWVkZWQgLSBtYXAtPnBhZ2VzcmVzZXJ2ZWQpOwor CWlmIChjb21taXQgPT0gMCAmJiBtYXAtPnBhZ2VzbmVlZGVkID4gKG1hcC0+cGFnZXNyZXNlcnZl ZCArIHBhZ2VzKSkKKwkJcmV0dXJuIChtYXAtPnBhZ2VzbmVlZGVkIC0gKG1hcC0+cGFnZXNyZXNl cnZlZCArIHBhZ2VzKSk7CisJYnotPmZyZWVfYnBhZ2VzIC09IHBhZ2VzOworCWJ6LT5yZXNlcnZl ZF9icGFnZXMgKz0gcGFnZXM7CisJbWFwLT5wYWdlc3Jlc2VydmVkICs9IHBhZ2VzOworCXBhZ2Vz ID0gbWFwLT5wYWdlc25lZWRlZCAtIG1hcC0+cGFnZXNyZXNlcnZlZDsKKworCXJldHVybiAocGFn ZXMpOworfQorCitzdGF0aWMgYnVzX2FkZHJfdAorYWRkX2JvdW5jZV9wYWdlKGJ1c19kbWFfdGFn X3QgZG1hdCwgYnVzX2RtYW1hcF90IG1hcCwgdm1fb2Zmc2V0X3QgdmFkZHIsCisJCWJ1c19hZGRy X3QgYWRkciwgYnVzX3NpemVfdCBzaXplKQoreworCXN0cnVjdCBib3VuY2Vfem9uZSAqYno7CisJ c3RydWN0IGJvdW5jZV9wYWdlICpicGFnZTsKKworCUtBU1NFUlQoZG1hdC0+Ym91bmNlX3pvbmUg IT0gTlVMTCwgKCJubyBib3VuY2Ugem9uZSBpbiBkbWEgdGFnIikpOworCUtBU1NFUlQobWFwICE9 IE5VTEwgJiYgbWFwICE9ICZub2JvdW5jZV9kbWFtYXAsCisJICAgICgiYWRkX2JvdW5jZV9wYWdl OiBiYWQgbWFwICVwIiwgbWFwKSk7CisKKwlieiA9IGRtYXQtPmJvdW5jZV96b25lOworCWlmICht YXAtPnBhZ2VzbmVlZGVkID09IDApCisJCXBhbmljKCJhZGRfYm91bmNlX3BhZ2U6IG1hcCBkb2Vz bid0IG5lZWQgYW55IHBhZ2VzIik7CisJbWFwLT5wYWdlc25lZWRlZC0tOworCisJaWYgKG1hcC0+ cGFnZXNyZXNlcnZlZCA9PSAwKQorCQlwYW5pYygiYWRkX2JvdW5jZV9wYWdlOiBtYXAgZG9lc24n dCBuZWVkIGFueSBwYWdlcyIpOworCW1hcC0+cGFnZXNyZXNlcnZlZC0tOworCisJbXR4X2xvY2so JmJvdW5jZV9sb2NrKTsKKwlicGFnZSA9IFNUQUlMUV9GSVJTVCgmYnotPmJvdW5jZV9wYWdlX2xp c3QpOworCWlmIChicGFnZSA9PSBOVUxMKQorCQlwYW5pYygiYWRkX2JvdW5jZV9wYWdlOiBmcmVl IHBhZ2UgbGlzdCBpcyBlbXB0eSIpOworCisJU1RBSUxRX1JFTU9WRV9IRUFEKCZiei0+Ym91bmNl X3BhZ2VfbGlzdCwgbGlua3MpOworCWJ6LT5yZXNlcnZlZF9icGFnZXMtLTsKKwliei0+YWN0aXZl X2JwYWdlcysrOworCW10eF91bmxvY2soJmJvdW5jZV9sb2NrKTsKKworCWlmIChkbWF0LT5jb21t b24uZmxhZ3MgJiBCVVNfRE1BX0tFRVBfUEdfT0ZGU0VUKSB7CisJCS8qIFBhZ2Ugb2Zmc2V0IG5l ZWRzIHRvIGJlIHByZXNlcnZlZC4gKi8KKwkJYnBhZ2UtPnZhZGRyIHw9IGFkZHIgJiBQQUdFX01B U0s7CisJCWJwYWdlLT5idXNhZGRyIHw9IGFkZHIgJiBQQUdFX01BU0s7CisJfQorCWJwYWdlLT5k YXRhdmFkZHIgPSB2YWRkcjsKKwlicGFnZS0+ZGF0YWFkZHIgPSBhZGRyOworCWJwYWdlLT5kYXRh Y291bnQgPSBzaXplOworCVNUQUlMUV9JTlNFUlRfVEFJTCgmKG1hcC0+YnBhZ2VzKSwgYnBhZ2Us IGxpbmtzKTsKKwlyZXR1cm4gKGJwYWdlLT5idXNhZGRyKTsKK30KKworc3RhdGljIHZvaWQKK2Zy ZWVfYm91bmNlX3BhZ2UoYnVzX2RtYV90YWdfdCBkbWF0LCBzdHJ1Y3QgYm91bmNlX3BhZ2UgKmJw YWdlKQoreworCXN0cnVjdCBidXNfZG1hbWFwICptYXA7CisJc3RydWN0IGJvdW5jZV96b25lICpi ejsKKworCWJ6ID0gZG1hdC0+Ym91bmNlX3pvbmU7CisJYnBhZ2UtPmRhdGF2YWRkciA9IDA7CisJ YnBhZ2UtPmRhdGFjb3VudCA9IDA7CisJaWYgKGRtYXQtPmNvbW1vbi5mbGFncyAmIEJVU19ETUFf S0VFUF9QR19PRkZTRVQpIHsKKwkJLyoKKwkJICogUmVzZXQgdGhlIGJvdW5jZSBwYWdlIHRvIHN0 YXJ0IGF0IG9mZnNldCAwLiAgT3RoZXIgdXNlcworCQkgKiBvZiB0aGlzIGJvdW5jZSBwYWdlIG1h eSBuZWVkIHRvIHN0b3JlIGEgZnVsbCBwYWdlIG9mCisJCSAqIGRhdGEgYW5kL29yIGFzc3VtZSBp dCBzdGFydHMgb24gYSBwYWdlIGJvdW5kYXJ5LgorCQkgKi8KKwkJYnBhZ2UtPnZhZGRyICY9IH5Q QUdFX01BU0s7CisJCWJwYWdlLT5idXNhZGRyICY9IH5QQUdFX01BU0s7CisJfQorCisJbXR4X2xv Y2soJmJvdW5jZV9sb2NrKTsKKwlTVEFJTFFfSU5TRVJUX0hFQUQoJmJ6LT5ib3VuY2VfcGFnZV9s aXN0LCBicGFnZSwgbGlua3MpOworCWJ6LT5mcmVlX2JwYWdlcysrOworCWJ6LT5hY3RpdmVfYnBh Z2VzLS07CisJaWYgKChtYXAgPSBTVEFJTFFfRklSU1QoJmJvdW5jZV9tYXBfd2FpdGluZ2xpc3Qp KSAhPSBOVUxMKSB7CisJCWlmIChyZXNlcnZlX2JvdW5jZV9wYWdlcyhtYXAtPmRtYXQsIG1hcCwg MSkgPT0gMCkgeworCQkJU1RBSUxRX1JFTU9WRV9IRUFEKCZib3VuY2VfbWFwX3dhaXRpbmdsaXN0 LCBsaW5rcyk7CisJCQlTVEFJTFFfSU5TRVJUX1RBSUwoJmJvdW5jZV9tYXBfY2FsbGJhY2tsaXN0 LAorCQkJICAgIG1hcCwgbGlua3MpOworCQkJYnVzZG1hX3N3aV9wZW5kaW5nID0gMTsKKwkJCWJ6 LT50b3RhbF9kZWZlcnJlZCsrOworCQkJc3dpX3NjaGVkKHZtX2loLCAwKTsKKwkJfQorCX0KKwlt dHhfdW5sb2NrKCZib3VuY2VfbG9jayk7Cit9CisKK3ZvaWQKK2J1c2RtYV9zd2kodm9pZCkKK3sK KwlidXNfZG1hX3RhZ190IGRtYXQ7CisJc3RydWN0IGJ1c19kbWFtYXAgKm1hcDsKKworCW10eF9s b2NrKCZib3VuY2VfbG9jayk7CisJd2hpbGUgKChtYXAgPSBTVEFJTFFfRklSU1QoJmJvdW5jZV9t YXBfY2FsbGJhY2tsaXN0KSkgIT0gTlVMTCkgeworCQlTVEFJTFFfUkVNT1ZFX0hFQUQoJmJvdW5j ZV9tYXBfY2FsbGJhY2tsaXN0LCBsaW5rcyk7CisJCW10eF91bmxvY2soJmJvdW5jZV9sb2NrKTsK KwkJZG1hdCA9IG1hcC0+ZG1hdDsKKwkJKGRtYXQtPmNvbW1vbi5sb2NrZnVuYykoZG1hdC0+Y29t bW9uLmxvY2tmdW5jYXJnLCBCVVNfRE1BX0xPQ0spOworCQlidXNfZG1hbWFwX2xvYWRfbWVtKG1h cC0+ZG1hdCwgbWFwLCAmbWFwLT5tZW0sCisJCSAgICBtYXAtPmNhbGxiYWNrLCBtYXAtPmNhbGxi YWNrX2FyZywgQlVTX0RNQV9XQUlUT0spOworCQkoZG1hdC0+Y29tbW9uLmxvY2tmdW5jKShkbWF0 LT5jb21tb24ubG9ja2Z1bmNhcmcsCisJCSAgICBCVVNfRE1BX1VOTE9DSyk7CisJCW10eF9sb2Nr KCZib3VuY2VfbG9jayk7CisJfQorCW10eF91bmxvY2soJmJvdW5jZV9sb2NrKTsKK30KKworc3Ry dWN0IGJ1c19kbWFfaW1wbCBidXNfZG1hX2JvdW5jZV9pbXBsID0geworCS50YWdfY3JlYXRlID0g Ym91bmNlX2J1c19kbWFfdGFnX2NyZWF0ZSwKKwkudGFnX2Rlc3Ryb3kgPSBib3VuY2VfYnVzX2Rt YV90YWdfZGVzdHJveSwKKwkubWFwX2NyZWF0ZSA9IGJvdW5jZV9idXNfZG1hbWFwX2NyZWF0ZSwK KwkubWFwX2Rlc3Ryb3kgPSBib3VuY2VfYnVzX2RtYW1hcF9kZXN0cm95LAorCS5tZW1fYWxsb2Mg PSBib3VuY2VfYnVzX2RtYW1lbV9hbGxvYywKKwkubWVtX2ZyZWUgPSBib3VuY2VfYnVzX2RtYW1l bV9mcmVlLAorCS5sb2FkX3BoeXMgPSBib3VuY2VfYnVzX2RtYW1hcF9sb2FkX3BoeXMsCisJLmxv YWRfYnVmZmVyID0gYm91bmNlX2J1c19kbWFtYXBfbG9hZF9idWZmZXIsCisJLmxvYWRfbWEgPSBi dXNfZG1hbWFwX2xvYWRfbWFfdHJpdiwKKwkubWFwX3dhaXRvayA9IGJvdW5jZV9idXNfZG1hbWFw X3dhaXRvaywKKwkubWFwX2NvbXBsZXRlID0gYm91bmNlX2J1c19kbWFtYXBfY29tcGxldGUsCisJ Lm1hcF91bmxvYWQgPSBib3VuY2VfYnVzX2RtYW1hcF91bmxvYWQsCisJLm1hcF9zeW5jID0gYm91 bmNlX2J1c19kbWFtYXBfc3luYworfTsKZGlmZiAtLWdpdCBhL3N5cy9hcm0vYXJtL2J1c2RtYV9t YWNoZGVwLWNvaGVyZW50LmMgYi9zeXMvYXJtL2FybS9idXNkbWFfbWFjaGRlcC1jb2hlcmVudC5j Cm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjJlMWVjZGIKLS0tIC9kZXYvbnVs bAorKysgYi9zeXMvYXJtL2FybS9idXNkbWFfbWFjaGRlcC1jb2hlcmVudC5jCkBAIC0wLDAgKzEs MzU5IEBACisvKi0KKyAqIENvcHlyaWdodCAoYykgMTk5NywgMTk5OCBKdXN0aW4gVC4gR2liYnMu CisgKiBDb3B5cmlnaHQgKGMpIDIwMTMgVGhlIEZyZWVCU0QgRm91bmRhdGlvbgorICogQWxsIHJp Z2h0cyByZXNlcnZlZC4KKyAqCisgKiBUaGlzIHNvZnR3YXJlIHdhcyBkZXZlbG9wZWQgYnkgS29u c3RhbnRpbiBCZWxvdXNvdiA8a2liQEZyZWVCU0Qub3JnPgorICogdW5kZXIgc3BvbnNvcnNoaXAg ZnJvbSB0aGUgRnJlZUJTRCBGb3VuZGF0aW9uLgorICoKKyAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1 c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorICogbW9kaWZp Y2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRp b25zCisgKiBhcmUgbWV0OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11 c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9m IGNvbmRpdGlvbnMsIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIsCisgKiAgICB3aXRob3V0 IG1vZGlmaWNhdGlvbiwgaW1tZWRpYXRlbHkgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgZmlsZS4K KyAqIDIuIFRoZSBuYW1lIG9mIHRoZSBhdXRob3IgbWF5IG5vdCBiZSB1c2VkIHRvIGVuZG9yc2Ug b3IgcHJvbW90ZSBwcm9kdWN0cworICogICAgZGVyaXZlZCBmcm9tIHRoaXMgc29mdHdhcmUgd2l0 aG91dCBzcGVjaWZpYyBwcmlvciB3cml0dGVuIHBlcm1pc3Npb24uCisgKgorICogVEhJUyBTT0ZU V0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVUSE9SIEFORCBDT05UUklCVVRPUlMgYGBBUyBJUycn IEFORAorICogQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJV VCBOT1QgTElNSVRFRCBUTywgVEhFCisgKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRB QklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQorICogQVJFIERJU0NM QUlNRUQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJ QUJMRSBGT1IKKyAqIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBF WEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5P VCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisgKiBPUiBTRVJW SUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQ VElPTikKKyAqIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwg V0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xV RElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisgKiBPVVQg T0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJ QklMSVRZIE9GCisgKiBTVUNIIERBTUFHRS4KKyAqLworCisjaW5jbHVkZSA8c3lzL2NkZWZzLmg+ CitfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CisKKyNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KKyNpbmNs dWRlIDxzeXMvc3lzdG0uaD4KKyNpbmNsdWRlIDxzeXMvbWFsbG9jLmg+CisjaW5jbHVkZSA8c3lz L2J1cy5oPgorI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KKyNpbmNsdWRlIDxzeXMva3RyLmg+Cisj aW5jbHVkZSA8c3lzL2xvY2suaD4KKyNpbmNsdWRlIDxzeXMvbWVtZGVzYy5oPgorI2luY2x1ZGUg PHN5cy9tdXRleC5oPgorI2luY2x1ZGUgPHN5cy91aW8uaD4KKyNpbmNsdWRlIDx2bS92bS5oPgor I2luY2x1ZGUgPHZtL3ZtX2V4dGVybi5oPgorI2luY2x1ZGUgPHZtL3BtYXAuaD4KKyNpbmNsdWRl IDxtYWNoaW5lL2J1cy5oPgorI2luY2x1ZGUgPG1hY2hpbmUvYnVzZG1hX2ltcGwuaD4KKworLyoK KyAqIENvbnZlbmllbmNlIGZ1bmN0aW9uIGZvciBtYW5pcHVsYXRpbmcgZHJpdmVyIGxvY2tzIGZy b20gYnVzZG1hIChkdXJpbmcKKyAqIGJ1c2RtYV9zd2ksIGZvciBleGFtcGxlKS4gIERyaXZlcnMg dGhhdCBkb24ndCBwcm92aWRlIHRoZWlyIG93biBsb2NrcworICogc2hvdWxkIHNwZWNpZnkgJkdp YW50IHRvIGRtYXQtPmxvY2tmdW5jYXJnLiAgRHJpdmVycyB0aGF0IHVzZSB0aGVpciBvd24KKyAq IG5vbi1tdXRleCBsb2NraW5nIHNjaGVtZSBkb24ndCBoYXZlIHRvIHVzZSB0aGlzIGF0IGFsbC4K KyAqLwordm9pZAorYnVzZG1hX2xvY2tfbXV0ZXgodm9pZCAqYXJnLCBidXNfZG1hX2xvY2tfb3Bf dCBvcCkKK3sKKwlzdHJ1Y3QgbXR4ICpkbXR4OworCisJZG10eCA9IChzdHJ1Y3QgbXR4ICopYXJn OworCXN3aXRjaCAob3ApIHsKKwljYXNlIEJVU19ETUFfTE9DSzoKKwkJbXR4X2xvY2soZG10eCk7 CisJCWJyZWFrOworCWNhc2UgQlVTX0RNQV9VTkxPQ0s6CisJCW10eF91bmxvY2soZG10eCk7CisJ CWJyZWFrOworCWRlZmF1bHQ6CisJCXBhbmljKCJVbmtub3duIG9wZXJhdGlvbiAweCV4IGZvciBi dXNkbWFfbG9ja19tdXRleCEiLCBvcCk7CisJfQorfQorCisvKgorICogZGZsdF9sb2NrIHNob3Vs ZCBuZXZlciBnZXQgY2FsbGVkLiAgSXQgZ2V0cyBwdXQgaW50byB0aGUgZG1hIHRhZyB3aGVuCisg KiBsb2NrZnVuYyA9PSBOVUxMLCB3aGljaCBpcyBvbmx5IHZhbGlkIGlmIHRoZSBtYXBzIHRoYXQg YXJlIGFzc29jaWF0ZWQKKyAqIHdpdGggdGhlIHRhZyBhcmUgbWVhbnQgdG8gbmV2ZXIgYmUgZGVm ZXJlZC4KKyAqIFhYWCBTaG91bGQgaGF2ZSBhIHdheSB0byBpZGVudGlmeSB3aGljaCBkcml2ZXIg aXMgcmVzcG9uc2libGUgaGVyZS4KKyAqLwordm9pZAorYnVzX2RtYV9kZmx0X2xvY2sodm9pZCAq YXJnLCBidXNfZG1hX2xvY2tfb3BfdCBvcCkKK3sKKworCXBhbmljKCJkcml2ZXIgZXJyb3I6IGJ1 c2RtYSBkZmx0X2xvY2sgY2FsbGVkIik7Cit9CisKKy8qCisgKiBSZXR1cm4gdHJ1ZSBpZiBhIG1h dGNoIGlzIG1hZGUuCisgKgorICogVG8gZmluZCBhIG1hdGNoIHdhbGsgdGhlIGNoYWluIG9mIGJ1 c19kbWFfdGFnX3QncyBsb29raW5nIGZvciAncGFkZHInLgorICoKKyAqIElmIHBhZGRyIGlzIHdp dGhpbiB0aGUgYm91bmRzIG9mIHRoZSBkbWEgdGFnIHRoZW4gY2FsbCB0aGUgZmlsdGVyIGNhbGxi YWNrCisgKiB0byBjaGVjayBmb3IgYSBtYXRjaCwgaWYgdGhlcmUgaXMgbm8gZmlsdGVyIGNhbGxi YWNrIHRoZW4gYXNzdW1lIGEgbWF0Y2guCisgKi8KK2ludAorYnVzX2RtYV9ydW5fZmlsdGVyKHN0 cnVjdCBidXNfZG1hX3RhZ19jb21tb24gKnRjLCBidXNfYWRkcl90IHBhZGRyKQoreworCWludCBy ZXR2YWw7CisKKwlyZXR2YWwgPSAwOworCWRvIHsKKwkJaWYgKCgocGFkZHIgPiB0Yy0+bG93YWRk ciAmJiBwYWRkciA8PSB0Yy0+aGlnaGFkZHIpIHx8CisJCSAgICAoKHBhZGRyICYgKHRjLT5hbGln bm1lbnQgLSAxKSkgIT0gMCkpICYmCisJCSAgICAodGMtPmZpbHRlciA9PSBOVUxMIHx8CisJCSAg ICAoKnRjLT5maWx0ZXIpKHRjLT5maWx0ZXJhcmcsIHBhZGRyKSAhPSAwKSkKKwkJCXJldHZhbCA9 IDE7CisKKwkJdGMgPSB0Yy0+cGFyZW50OwkJCisJfSB3aGlsZSAocmV0dmFsID09IDAgJiYgdGMg IT0gTlVMTCk7CisJcmV0dXJuIChyZXR2YWwpOworfQorCitpbnQKK2NvbW1vbl9idXNfZG1hX3Rh Z19jcmVhdGUoc3RydWN0IGJ1c19kbWFfdGFnX2NvbW1vbiAqcGFyZW50LAorICAgIGJ1c19zaXpl X3QgYWxpZ25tZW50LCBidXNfYWRkcl90IGJvdW5kYXJ5LCBidXNfYWRkcl90IGxvd2FkZHIsCisg ICAgYnVzX2FkZHJfdCBoaWdoYWRkciwgYnVzX2RtYV9maWx0ZXJfdCAqZmlsdGVyLCB2b2lkICpm aWx0ZXJhcmcsCisgICAgYnVzX3NpemVfdCBtYXhzaXplLCBpbnQgbnNlZ21lbnRzLCBidXNfc2l6 ZV90IG1heHNlZ3N6LCBpbnQgZmxhZ3MsCisgICAgYnVzX2RtYV9sb2NrX3QgKmxvY2tmdW5jLCB2 b2lkICpsb2NrZnVuY2FyZywgc2l6ZV90IHN6LCB2b2lkICoqZG1hdCkKK3sKKwl2b2lkICpuZXd0 YWc7CisJc3RydWN0IGJ1c19kbWFfdGFnX2NvbW1vbiAqY29tbW9uOworCisJS0FTU0VSVChzeiA+ PSBzaXplb2Yoc3RydWN0IGJ1c19kbWFfdGFnX2NvbW1vbiksICgic3oiKSk7CisJLyogQmFzaWMg c2FuaXR5IGNoZWNraW5nICovCisJaWYgKGJvdW5kYXJ5ICE9IDAgJiYgYm91bmRhcnkgPCBtYXhz ZWdzeikKKwkJbWF4c2Vnc3ogPSBib3VuZGFyeTsKKwlpZiAobWF4c2Vnc3ogPT0gMCkKKwkJcmV0 dXJuIChFSU5WQUwpOworCS8qIFJldHVybiBhIE5VTEwgdGFnIG9uIGZhaWx1cmUgKi8KKwkqZG1h dCA9IE5VTEw7CisKKwluZXd0YWcgPSBtYWxsb2Moc3osIE1fREVWQlVGLCBNX1pFUk8gfCBNX05P V0FJVCk7CisJaWYgKG5ld3RhZyA9PSBOVUxMKSB7CisJCUNUUjQoS1RSX0JVU0RNQSwgIiVzIHJl dHVybmVkIHRhZyAlcCB0YWcgZmxhZ3MgMHgleCBlcnJvciAlZCIsCisJCSAgICBfX2Z1bmNfXywg bmV3dGFnLCAwLCBFTk9NRU0pOworCQlyZXR1cm4gKEVOT01FTSk7CisJfQorCisJY29tbW9uID0g bmV3dGFnOworCWNvbW1vbi0+aW1wbCA9ICZidXNfZG1hX2JvdW5jZV9pbXBsOworCWNvbW1vbi0+ cGFyZW50ID0gcGFyZW50OworCWNvbW1vbi0+YWxpZ25tZW50ID0gYWxpZ25tZW50OworCWNvbW1v bi0+Ym91bmRhcnkgPSBib3VuZGFyeTsKKwljb21tb24tPmxvd2FkZHIgPSB0cnVuY19wYWdlKCh2 bV9wYWRkcl90KWxvd2FkZHIpICsgKFBBR0VfU0laRSAtIDEpOworCWNvbW1vbi0+aGlnaGFkZHIg PSB0cnVuY19wYWdlKCh2bV9wYWRkcl90KWhpZ2hhZGRyKSArIChQQUdFX1NJWkUgLSAxKTsKKwlj b21tb24tPmZpbHRlciA9IGZpbHRlcjsKKwljb21tb24tPmZpbHRlcmFyZyA9IGZpbHRlcmFyZzsK Kwljb21tb24tPm1heHNpemUgPSBtYXhzaXplOworCWNvbW1vbi0+bnNlZ21lbnRzID0gbnNlZ21l bnRzOworCWNvbW1vbi0+bWF4c2Vnc3ogPSBtYXhzZWdzejsKKwljb21tb24tPmZsYWdzID0gZmxh Z3M7CisJY29tbW9uLT5yZWZfY291bnQgPSAxOyAvKiBDb3VudCBvdXJzZWxmICovCisJaWYgKGxv Y2tmdW5jICE9IE5VTEwpIHsKKwkJY29tbW9uLT5sb2NrZnVuYyA9IGxvY2tmdW5jOworCQljb21t b24tPmxvY2tmdW5jYXJnID0gbG9ja2Z1bmNhcmc7CisJfSBlbHNlIHsKKwkJY29tbW9uLT5sb2Nr ZnVuYyA9IGJ1c19kbWFfZGZsdF9sb2NrOworCQljb21tb24tPmxvY2tmdW5jYXJnID0gTlVMTDsK Kwl9CisKKwkvKiBUYWtlIGludG8gYWNjb3VudCBhbnkgcmVzdHJpY3Rpb25zIGltcG9zZWQgYnkg b3VyIHBhcmVudCB0YWcgKi8KKwlpZiAocGFyZW50ICE9IE5VTEwpIHsKKwkJY29tbW9uLT5pbXBs ID0gcGFyZW50LT5pbXBsOworCQljb21tb24tPmxvd2FkZHIgPSBNSU4ocGFyZW50LT5sb3dhZGRy LCBjb21tb24tPmxvd2FkZHIpOworCQljb21tb24tPmhpZ2hhZGRyID0gTUFYKHBhcmVudC0+aGln aGFkZHIsIGNvbW1vbi0+aGlnaGFkZHIpOworCQlpZiAoY29tbW9uLT5ib3VuZGFyeSA9PSAwKQor CQkJY29tbW9uLT5ib3VuZGFyeSA9IHBhcmVudC0+Ym91bmRhcnk7CisJCWVsc2UgaWYgKHBhcmVu dC0+Ym91bmRhcnkgIT0gMCkgeworCQkJY29tbW9uLT5ib3VuZGFyeSA9IE1JTihwYXJlbnQtPmJv dW5kYXJ5LAorCQkJICAgIGNvbW1vbi0+Ym91bmRhcnkpOworCQl9CisJCWlmIChjb21tb24tPmZp bHRlciA9PSBOVUxMKSB7CisJCQkvKgorCQkJICogU2hvcnQgY2lyY3VpdCBsb29raW5nIGF0IG91 ciBwYXJlbnQgZGlyZWN0bHkKKwkJCSAqIHNpbmNlIHdlIGhhdmUgZW5jYXBzdWxhdGVkIGFsbCBv ZiBpdHMgaW5mb3JtYXRpb24KKwkJCSAqLworCQkJY29tbW9uLT5maWx0ZXIgPSBwYXJlbnQtPmZp bHRlcjsKKwkJCWNvbW1vbi0+ZmlsdGVyYXJnID0gcGFyZW50LT5maWx0ZXJhcmc7CisJCQljb21t b24tPnBhcmVudCA9IHBhcmVudC0+cGFyZW50OworCQl9CisJCWF0b21pY19hZGRfaW50KCZwYXJl bnQtPnJlZl9jb3VudCwgMSk7CisJfQorCSpkbWF0ID0gY29tbW9uOworCXJldHVybiAoMCk7Cit9 CisKKy8qCisgKiBBbGxvY2F0ZSBhIGRldmljZSBzcGVjaWZpYyBkbWFfdGFnLgorICovCitpbnQK K2J1c19kbWFfdGFnX2NyZWF0ZShidXNfZG1hX3RhZ190IHBhcmVudCwgYnVzX3NpemVfdCBhbGln bm1lbnQsCisgICAgYnVzX2FkZHJfdCBib3VuZGFyeSwgYnVzX2FkZHJfdCBsb3dhZGRyLCBidXNf YWRkcl90IGhpZ2hhZGRyLAorICAgIGJ1c19kbWFfZmlsdGVyX3QgKmZpbHRlciwgdm9pZCAqZmls dGVyYXJnLCBidXNfc2l6ZV90IG1heHNpemUsCisgICAgaW50IG5zZWdtZW50cywgYnVzX3NpemVf dCBtYXhzZWdzeiwgaW50IGZsYWdzLCBidXNfZG1hX2xvY2tfdCAqbG9ja2Z1bmMsCisgICAgdm9p ZCAqbG9ja2Z1bmNhcmcsIGJ1c19kbWFfdGFnX3QgKmRtYXQpCit7CisJc3RydWN0IGJ1c19kbWFf dGFnX2NvbW1vbiAqdGM7CisJaW50IGVycm9yOworCisJaWYgKHBhcmVudCA9PSBOVUxMKSB7CisJ CWVycm9yID0gYnVzX2RtYV9ib3VuY2VfaW1wbC50YWdfY3JlYXRlKHBhcmVudCwgYWxpZ25tZW50 LAorCQkgICAgYm91bmRhcnksIGxvd2FkZHIsIGhpZ2hhZGRyLCBmaWx0ZXIsIGZpbHRlcmFyZywg bWF4c2l6ZSwKKwkJICAgIG5zZWdtZW50cywgbWF4c2Vnc3osIGZsYWdzLCBsb2NrZnVuYywgbG9j a2Z1bmNhcmcsIGRtYXQpOworCX0gZWxzZSB7CisJCXRjID0gKHN0cnVjdCBidXNfZG1hX3RhZ19j b21tb24gKilwYXJlbnQ7CisJCWVycm9yID0gdGMtPmltcGwtPnRhZ19jcmVhdGUocGFyZW50LCBh bGlnbm1lbnQsCisJCSAgICBib3VuZGFyeSwgbG93YWRkciwgaGlnaGFkZHIsIGZpbHRlciwgZmls dGVyYXJnLCBtYXhzaXplLAorCQkgICAgbnNlZ21lbnRzLCBtYXhzZWdzeiwgZmxhZ3MsIGxvY2tm dW5jLCBsb2NrZnVuY2FyZywgZG1hdCk7CisJfQorCXJldHVybiAoZXJyb3IpOworfQorCitpbnQK K2J1c19kbWFfdGFnX2Rlc3Ryb3koYnVzX2RtYV90YWdfdCBkbWF0KQoreworCXN0cnVjdCBidXNf ZG1hX3RhZ19jb21tb24gKnRjOworCisJdGMgPSAoc3RydWN0IGJ1c19kbWFfdGFnX2NvbW1vbiAq KWRtYXQ7CisJcmV0dXJuICh0Yy0+aW1wbC0+dGFnX2Rlc3Ryb3koZG1hdCkpOworfQorCisvKgor ICogQWxsb2NhdGUgYSBoYW5kbGUgZm9yIG1hcHBpbmcgZnJvbSBrdmEvdXZhL3BoeXNpY2FsCisg KiBhZGRyZXNzIHNwYWNlIGludG8gYnVzIGRldmljZSBzcGFjZS4KKyAqLworaW50CitidXNfZG1h bWFwX2NyZWF0ZShidXNfZG1hX3RhZ190IGRtYXQsIGludCBmbGFncywgYnVzX2RtYW1hcF90ICpt YXBwKQoreworCXN0cnVjdCBidXNfZG1hX3RhZ19jb21tb24gKnRjOworCisJdGMgPSAoc3RydWN0 IGJ1c19kbWFfdGFnX2NvbW1vbiAqKWRtYXQ7CisJcmV0dXJuICh0Yy0+aW1wbC0+bWFwX2NyZWF0 ZShkbWF0LCBmbGFncywgbWFwcCkpOworfQorCisvKgorICogRGVzdHJveSBhIGhhbmRsZSBmb3Ig bWFwcGluZyBmcm9tIGt2YS91dmEvcGh5c2ljYWwKKyAqIGFkZHJlc3Mgc3BhY2UgaW50byBidXMg ZGV2aWNlIHNwYWNlLgorICovCitpbnQKK2J1c19kbWFtYXBfZGVzdHJveShidXNfZG1hX3RhZ190 IGRtYXQsIGJ1c19kbWFtYXBfdCBtYXApCit7CisJc3RydWN0IGJ1c19kbWFfdGFnX2NvbW1vbiAq dGM7CisKKwl0YyA9IChzdHJ1Y3QgYnVzX2RtYV90YWdfY29tbW9uICopZG1hdDsKKwlyZXR1cm4g KHRjLT5pbXBsLT5tYXBfZGVzdHJveShkbWF0LCBtYXApKTsKK30KKworCisvKgorICogQWxsb2Nh dGUgYSBwaWVjZSBvZiBtZW1vcnkgdGhhdCBjYW4gYmUgZWZmaWNpZW50bHkgbWFwcGVkIGludG8K KyAqIGJ1cyBkZXZpY2Ugc3BhY2UgYmFzZWQgb24gdGhlIGNvbnN0cmFpbnRzIGxpdGVkIGluIHRo ZSBkbWEgdGFnLgorICogQSBkbWFtYXAgdG8gZm9yIHVzZSB3aXRoIGRtYW1hcF9sb2FkIGlzIGFs c28gYWxsb2NhdGVkLgorICovCitpbnQKK2J1c19kbWFtZW1fYWxsb2MoYnVzX2RtYV90YWdfdCBk bWF0LCB2b2lkKiogdmFkZHIsIGludCBmbGFncywKKyAgICBidXNfZG1hbWFwX3QgKm1hcHApCit7 CisJc3RydWN0IGJ1c19kbWFfdGFnX2NvbW1vbiAqdGM7CisKKwl0YyA9IChzdHJ1Y3QgYnVzX2Rt YV90YWdfY29tbW9uICopZG1hdDsKKwlyZXR1cm4gKHRjLT5pbXBsLT5tZW1fYWxsb2MoZG1hdCwg dmFkZHIsIGZsYWdzLCBtYXBwKSk7Cit9CisKKy8qCisgKiBGcmVlIGEgcGllY2Ugb2YgbWVtb3J5 IGFuZCBpdCdzIGFsbG9jaWF0ZWQgZG1hbWFwLCB0aGF0IHdhcyBhbGxvY2F0ZWQKKyAqIHZpYSBi dXNfZG1hbWVtX2FsbG9jLiAgTWFrZSB0aGUgc2FtZSBjaG9pY2UgZm9yIGZyZWUvY29udGlnZnJl ZS4KKyAqLwordm9pZAorYnVzX2RtYW1lbV9mcmVlKGJ1c19kbWFfdGFnX3QgZG1hdCwgdm9pZCAq dmFkZHIsIGJ1c19kbWFtYXBfdCBtYXApCit7CisJc3RydWN0IGJ1c19kbWFfdGFnX2NvbW1vbiAq dGM7CisKKwl0YyA9IChzdHJ1Y3QgYnVzX2RtYV90YWdfY29tbW9uICopZG1hdDsKKwl0Yy0+aW1w bC0+bWVtX2ZyZWUoZG1hdCwgdmFkZHIsIG1hcCk7Cit9CisKKy8qCisgKiBVdGlsaXR5IGZ1bmN0 aW9uIHRvIGxvYWQgYSBwaHlzaWNhbCBidWZmZXIuICBzZWdwIGNvbnRhaW5zCisgKiB0aGUgc3Rh cnRpbmcgc2VnbWVudCBvbiBlbnRyYWNlLCBhbmQgdGhlIGVuZGluZyBzZWdtZW50IG9uIGV4aXQu CisgKi8KK2ludAorX2J1c19kbWFtYXBfbG9hZF9waHlzKGJ1c19kbWFfdGFnX3QgZG1hdCwgYnVz X2RtYW1hcF90IG1hcCwgdm1fcGFkZHJfdCBidWYsCisgICAgYnVzX3NpemVfdCBidWZsZW4sIGlu dCBmbGFncywgYnVzX2RtYV9zZWdtZW50X3QgKnNlZ3MsIGludCAqc2VncCkKK3sKKwlzdHJ1Y3Qg YnVzX2RtYV90YWdfY29tbW9uICp0YzsKKworCXRjID0gKHN0cnVjdCBidXNfZG1hX3RhZ19jb21t b24gKilkbWF0OworCXJldHVybiAodGMtPmltcGwtPmxvYWRfcGh5cyhkbWF0LCBtYXAsIGJ1Ziwg YnVmbGVuLCBmbGFncywgc2VncywKKwkgICAgc2VncCkpOworfQorCitpbnQKK19idXNfZG1hbWFw X2xvYWRfbWEoYnVzX2RtYV90YWdfdCBkbWF0LCBidXNfZG1hbWFwX3QgbWFwLCBzdHJ1Y3Qgdm1f cGFnZSAqKm1hLAorICAgIGJ1c19zaXplX3QgdGxlbiwgaW50IG1hX29mZnMsIGludCBmbGFncywg YnVzX2RtYV9zZWdtZW50X3QgKnNlZ3MsCisgICAgaW50ICpzZWdwKQoreworCXN0cnVjdCBidXNf ZG1hX3RhZ19jb21tb24gKnRjOworCisJdGMgPSAoc3RydWN0IGJ1c19kbWFfdGFnX2NvbW1vbiAq KWRtYXQ7CisJcmV0dXJuICh0Yy0+aW1wbC0+bG9hZF9tYShkbWF0LCBtYXAsIG1hLCB0bGVuLCBt YV9vZmZzLCBmbGFncywKKwkgICAgc2Vncywgc2VncCkpOworfQorCisvKgorICogVXRpbGl0eSBm dW5jdGlvbiB0byBsb2FkIGEgbGluZWFyIGJ1ZmZlci4gIHNlZ3AgY29udGFpbnMKKyAqIHRoZSBz dGFydGluZyBzZWdtZW50IG9uIGVudHJhY2UsIGFuZCB0aGUgZW5kaW5nIHNlZ21lbnQgb24gZXhp dC4KKyAqLworaW50CitfYnVzX2RtYW1hcF9sb2FkX2J1ZmZlcihidXNfZG1hX3RhZ190IGRtYXQs IGJ1c19kbWFtYXBfdCBtYXAsIHZvaWQgKmJ1ZiwKKyAgICBidXNfc2l6ZV90IGJ1ZmxlbiwgcG1h cF90IHBtYXAsIGludCBmbGFncywgYnVzX2RtYV9zZWdtZW50X3QgKnNlZ3MsCisgICAgaW50ICpz ZWdwKQoreworCXN0cnVjdCBidXNfZG1hX3RhZ19jb21tb24gKnRjOworCisJdGMgPSAoc3RydWN0 IGJ1c19kbWFfdGFnX2NvbW1vbiAqKWRtYXQ7CisJcmV0dXJuICh0Yy0+aW1wbC0+bG9hZF9idWZm ZXIoZG1hdCwgbWFwLCBidWYsIGJ1ZmxlbiwgcG1hcCwgZmxhZ3MsIHNlZ3MsCisJICAgIHNlZ3Ap KTsKK30KKwordm9pZAorX19idXNfZG1hbWFwX3dhaXRvayhidXNfZG1hX3RhZ190IGRtYXQsIGJ1 c19kbWFtYXBfdCBtYXAsCisgICAgc3RydWN0IG1lbWRlc2MgKm1lbSwgYnVzX2RtYW1hcF9jYWxs YmFja190ICpjYWxsYmFjaywgdm9pZCAqY2FsbGJhY2tfYXJnKQoreworCXN0cnVjdCBidXNfZG1h X3RhZ19jb21tb24gKnRjOworCisJdGMgPSAoc3RydWN0IGJ1c19kbWFfdGFnX2NvbW1vbiAqKWRt YXQ7CisJdGMtPmltcGwtPm1hcF93YWl0b2soZG1hdCwgbWFwLCBtZW0sIGNhbGxiYWNrLCBjYWxs YmFja19hcmcpOworfQorCitidXNfZG1hX3NlZ21lbnRfdCAqCitfYnVzX2RtYW1hcF9jb21wbGV0 ZShidXNfZG1hX3RhZ190IGRtYXQsIGJ1c19kbWFtYXBfdCBtYXAsCisgICAgYnVzX2RtYV9zZWdt ZW50X3QgKnNlZ3MsIGludCBuc2VncywgaW50IGVycm9yKQoreworCXN0cnVjdCBidXNfZG1hX3Rh Z19jb21tb24gKnRjOworCisJdGMgPSAoc3RydWN0IGJ1c19kbWFfdGFnX2NvbW1vbiAqKWRtYXQ7 CisJcmV0dXJuICh0Yy0+aW1wbC0+bWFwX2NvbXBsZXRlKGRtYXQsIG1hcCwgc2VncywgbnNlZ3Ms IGVycm9yKSk7Cit9CisKKy8qCisgKiBSZWxlYXNlIHRoZSBtYXBwaW5nIGhlbGQgYnkgbWFwLgor ICovCit2b2lkCitfYnVzX2RtYW1hcF91bmxvYWQoYnVzX2RtYV90YWdfdCBkbWF0LCBidXNfZG1h bWFwX3QgbWFwKQoreworCXN0cnVjdCBidXNfZG1hX3RhZ19jb21tb24gKnRjOworCisJdGMgPSAo c3RydWN0IGJ1c19kbWFfdGFnX2NvbW1vbiAqKWRtYXQ7CisJdGMtPmltcGwtPm1hcF91bmxvYWQo ZG1hdCwgbWFwKTsKK30KKwordm9pZAorX2J1c19kbWFtYXBfc3luYyhidXNfZG1hX3RhZ190IGRt YXQsIGJ1c19kbWFtYXBfdCBtYXAsIGJ1c19kbWFzeW5jX29wX3Qgb3ApCit7CisJc3RydWN0IGJ1 c19kbWFfdGFnX2NvbW1vbiAqdGM7CisKKwl0YyA9IChzdHJ1Y3QgYnVzX2RtYV90YWdfY29tbW9u ICopZG1hdDsKKwl0Yy0+aW1wbC0+bWFwX3N5bmMoZG1hdCwgbWFwLCBvcCk7Cit9CmRpZmYgLS1n aXQgYS9zeXMvYXJtL2luY2x1ZGUvYnVzZG1hX2ltcGwuaCBiL3N5cy9hcm0vaW5jbHVkZS9idXNk bWFfaW1wbC5oCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjdiODljMjEKLS0t IC9kZXYvbnVsbAorKysgYi9zeXMvYXJtL2luY2x1ZGUvYnVzZG1hX2ltcGwuaApAQCAtMCwwICsx LDk2IEBACisvKi0KKyAqIENvcHlyaWdodCAoYykgMjAxMyBUaGUgRnJlZUJTRCBGb3VuZGF0aW9u CisgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAqIFRoaXMgc29mdHdhcmUgd2FzIGRldmVs b3BlZCBieSBLb25zdGFudGluIEJlbG91c292IDxraWJARnJlZUJTRC5vcmc+CisgKiB1bmRlciBz cG9uc29yc2hpcCBmcm9tIHRoZSBGcmVlQlNEIEZvdW5kYXRpb24uCisgKgorICogUmVkaXN0cmli dXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0 CisgKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93 aW5nIGNvbmRpdGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291 cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0 aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgorICog Mi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92 ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRo ZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKKyAqICAgIGRvY3VtZW50YXRpb24gYW5kL29y IG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCisgKgorICog VEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVUSE9SIEFORCBDT05UUklCVVRPUlMg YGBBUyBJUycnIEFORAorICogQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNM VURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisgKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0Yg TUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQorICog QVJFIERJU0NMQUlNRUQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVU T1JTIEJFIExJQUJMRQorICogRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBT UEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElO RywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisg KiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNT IElOVEVSUlVQVElPTikKKyAqIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJ QUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRP UlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZ CisgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0Yg VEhFIFBPU1NJQklMSVRZIE9GCisgKiBTVUNIIERBTUFHRS4KKyAqCisgKiAkRnJlZUJTRCQKKyAq LworCisjaWZuZGVmCV9fQVJNX0JVU0RNQV9JTVBMX0gKKyNkZWZpbmUJX19BUk1fQlVTRE1BX0lN UExfSAorCitzdHJ1Y3QgYnVzX2RtYV90YWdfY29tbW9uIHsKKwlzdHJ1Y3QgYnVzX2RtYV9pbXBs ICppbXBsOworCXN0cnVjdCBidXNfZG1hX3RhZ19jb21tb24gKnBhcmVudDsKKwlidXNfc2l6ZV90 CSAgYWxpZ25tZW50OworCWJ1c19hZGRyX3QJICBib3VuZGFyeTsKKwlidXNfYWRkcl90CSAgbG93 YWRkcjsKKwlidXNfYWRkcl90CSAgaGlnaGFkZHI7CisJYnVzX2RtYV9maWx0ZXJfdCAqZmlsdGVy OworCXZvaWQJCSAqZmlsdGVyYXJnOworCWJ1c19zaXplX3QJICBtYXhzaXplOworCXVfaW50CQkg IG5zZWdtZW50czsKKwlidXNfc2l6ZV90CSAgbWF4c2Vnc3o7CisJaW50CQkgIGZsYWdzOworCWJ1 c19kbWFfbG9ja190CSAqbG9ja2Z1bmM7CisJdm9pZAkJICpsb2NrZnVuY2FyZzsKKwlpbnQJCSAg cmVmX2NvdW50OworfTsKKworc3RydWN0IGJ1c19kbWFfaW1wbCB7CisJaW50ICgqdGFnX2NyZWF0 ZSkoYnVzX2RtYV90YWdfdCBwYXJlbnQsCisJICAgIGJ1c19zaXplX3QgYWxpZ25tZW50LCBidXNf YWRkcl90IGJvdW5kYXJ5LCBidXNfYWRkcl90IGxvd2FkZHIsCisJICAgIGJ1c19hZGRyX3QgaGln aGFkZHIsIGJ1c19kbWFfZmlsdGVyX3QgKmZpbHRlciwKKwkgICAgdm9pZCAqZmlsdGVyYXJnLCBi dXNfc2l6ZV90IG1heHNpemUsIGludCBuc2VnbWVudHMsCisJICAgIGJ1c19zaXplX3QgbWF4c2Vn c3osIGludCBmbGFncywgYnVzX2RtYV9sb2NrX3QgKmxvY2tmdW5jLAorCSAgICB2b2lkICpsb2Nr ZnVuY2FyZywgYnVzX2RtYV90YWdfdCAqZG1hdCk7CisJaW50ICgqdGFnX2Rlc3Ryb3kpKGJ1c19k bWFfdGFnX3QgZG1hdCk7CisJaW50ICgqbWFwX2NyZWF0ZSkoYnVzX2RtYV90YWdfdCBkbWF0LCBp bnQgZmxhZ3MsIGJ1c19kbWFtYXBfdCAqbWFwcCk7CisJaW50ICgqbWFwX2Rlc3Ryb3kpKGJ1c19k bWFfdGFnX3QgZG1hdCwgYnVzX2RtYW1hcF90IG1hcCk7CisJaW50ICgqbWVtX2FsbG9jKShidXNf ZG1hX3RhZ190IGRtYXQsIHZvaWQqKiB2YWRkciwgaW50IGZsYWdzLAorCSAgICBidXNfZG1hbWFw X3QgKm1hcHApOworCXZvaWQgKCptZW1fZnJlZSkoYnVzX2RtYV90YWdfdCBkbWF0LCB2b2lkICp2 YWRkciwgYnVzX2RtYW1hcF90IG1hcCk7CisJaW50ICgqbG9hZF9tYSkoYnVzX2RtYV90YWdfdCBk bWF0LCBidXNfZG1hbWFwX3QgbWFwLAorCSAgICBzdHJ1Y3Qgdm1fcGFnZSAqKm1hLCBidXNfc2l6 ZV90IHRsZW4sIGludCBtYV9vZmZzLCBpbnQgZmxhZ3MsCisJICAgIGJ1c19kbWFfc2VnbWVudF90 ICpzZWdzLCBpbnQgKnNlZ3ApOworCWludCAoKmxvYWRfcGh5cykoYnVzX2RtYV90YWdfdCBkbWF0 LCBidXNfZG1hbWFwX3QgbWFwLAorCSAgICB2bV9wYWRkcl90IGJ1ZiwgYnVzX3NpemVfdCBidWZs ZW4sIGludCBmbGFncywKKwkgICAgYnVzX2RtYV9zZWdtZW50X3QgKnNlZ3MsIGludCAqc2VncCk7 CisJaW50ICgqbG9hZF9idWZmZXIpKGJ1c19kbWFfdGFnX3QgZG1hdCwgYnVzX2RtYW1hcF90IG1h cCwKKwkgICAgdm9pZCAqYnVmLCBidXNfc2l6ZV90IGJ1ZmxlbiwgcG1hcF90IHBtYXAsIGludCBm bGFncywKKwkgICAgYnVzX2RtYV9zZWdtZW50X3QgKnNlZ3MsIGludCAqc2VncCk7CisJdm9pZCAo Km1hcF93YWl0b2spKGJ1c19kbWFfdGFnX3QgZG1hdCwgYnVzX2RtYW1hcF90IG1hcCwKKwkgICAg c3RydWN0IG1lbWRlc2MgKm1lbSwgYnVzX2RtYW1hcF9jYWxsYmFja190ICpjYWxsYmFjaywKKwkg ICAgdm9pZCAqY2FsbGJhY2tfYXJnKTsKKwlidXNfZG1hX3NlZ21lbnRfdCAqKCptYXBfY29tcGxl dGUpKGJ1c19kbWFfdGFnX3QgZG1hdCwgYnVzX2RtYW1hcF90IG1hcCwKKwkgICAgYnVzX2RtYV9z ZWdtZW50X3QgKnNlZ3MsIGludCBuc2VncywgaW50IGVycm9yKTsKKwl2b2lkICgqbWFwX3VubG9h ZCkoYnVzX2RtYV90YWdfdCBkbWF0LCBidXNfZG1hbWFwX3QgbWFwKTsKKwl2b2lkICgqbWFwX3N5 bmMpKGJ1c19kbWFfdGFnX3QgZG1hdCwgYnVzX2RtYW1hcF90IG1hcCwKKwkgICAgYnVzX2RtYXN5 bmNfb3BfdCBvcCk7Cit9OworCit2b2lkIGJ1c19kbWFfZGZsdF9sb2NrKHZvaWQgKmFyZywgYnVz X2RtYV9sb2NrX29wX3Qgb3ApOworaW50IGJ1c19kbWFfcnVuX2ZpbHRlcihzdHJ1Y3QgYnVzX2Rt YV90YWdfY29tbW9uICpkbWF0LCBidXNfYWRkcl90IHBhZGRyKTsKK2ludCBjb21tb25fYnVzX2Rt YV90YWdfY3JlYXRlKHN0cnVjdCBidXNfZG1hX3RhZ19jb21tb24gKnBhcmVudCwKKyAgICBidXNf c2l6ZV90IGFsaWdubWVudCwKKyAgICBidXNfYWRkcl90IGJvdW5kYXJ5LCBidXNfYWRkcl90IGxv d2FkZHIsIGJ1c19hZGRyX3QgaGlnaGFkZHIsCisgICAgYnVzX2RtYV9maWx0ZXJfdCAqZmlsdGVy LCB2b2lkICpmaWx0ZXJhcmcsIGJ1c19zaXplX3QgbWF4c2l6ZSwKKyAgICBpbnQgbnNlZ21lbnRz LCBidXNfc2l6ZV90IG1heHNlZ3N6LCBpbnQgZmxhZ3MsIGJ1c19kbWFfbG9ja190ICpsb2NrZnVu YywKKyAgICB2b2lkICpsb2NrZnVuY2FyZywgc2l6ZV90IHN6LCB2b2lkICoqZG1hdCk7CisKK2V4 dGVybiBzdHJ1Y3QgYnVzX2RtYV9pbXBsIGJ1c19kbWFfYm91bmNlX2ltcGw7CisKKyNlbmRpZgpk aWZmIC0tZ2l0IGEvc3lzL2NvbmYvZmlsZXMuYXJtIGIvc3lzL2NvbmYvZmlsZXMuYXJtCmluZGV4 IGYwM2QyYTEuLjVhYTMyN2YgMTAwNjQ0Ci0tLSBhL3N5cy9jb25mL2ZpbGVzLmFybQorKysgYi9z eXMvY29uZi9maWxlcy5hcm0KQEAgLTI1LDggKzI1LDEwIEBAIGFybS9hcm0vYmxvY2tpby5TCQlz dGFuZGFyZAogYXJtL2FybS9idXNfc3BhY2VfYXNtX2dlbmVyaWMuUwlzdGFuZGFyZAogYXJtL2Fy bS9idXNfc3BhY2VfYmFzZS5jCW9wdGlvbmFsCWZkdAogYXJtL2FybS9idXNfc3BhY2VfZ2VuZXJp Yy5jCXN0YW5kYXJkCi1hcm0vYXJtL2J1c2RtYV9tYWNoZGVwLXY0LmMgCW9wdGlvbmFsCSFhcm12 NgotYXJtL2FybS9idXNkbWFfbWFjaGRlcC12Ni5jIAlvcHRpb25hbAlhcm12NgorYXJtL2FybS9i dXNkbWFfbWFjaGRlcC12NC5jCQlvcHRpb25hbAkhYXJtdjYKK2FybS9hcm0vYnVzZG1hX21hY2hk ZXAtdjYuYwkJb3B0aW9uYWwJYXJtdjYgIWFybV9kbWFfY29oZXJlbnQKK2FybS9hcm0vYnVzZG1h X21hY2hkZXAtY29oZXJlbnQuYyAJb3B0aW9uYWwJYXJtdjYgYXJtX2RtYV9jb2hlcmVudAorYXJt L2FybS9idXNkbWFfYm91bmNlLmMgCQlvcHRpb25hbAlhcm12NiBhcm1fZG1hX2NvaGVyZW50CiBh cm0vYXJtL2NvcHlzdHIuUwkJc3RhbmRhcmQKIGFybS9hcm0vY3B1ZnVuYy5jCQlzdGFuZGFyZAog YXJtL2FybS9jcHVmdW5jX2FzbS5TCQlzdGFuZGFyZApkaWZmIC0tZ2l0IGEvc3lzL2NvbmYvb3B0 aW9ucy5hcm0gYi9zeXMvY29uZi9vcHRpb25zLmFybQppbmRleCAyZDhmNDc0Li41MDEyYjE5IDEw MDY0NAotLS0gYS9zeXMvY29uZi9vcHRpb25zLmFybQorKysgYi9zeXMvY29uZi9vcHRpb25zLmFy bQpAQCAtMSw2ICsxLDcgQEAKICMkRnJlZUJTRCQKIEFSTVY2CQkJb3B0X2dsb2JhbC5oCiBBUk1f Q0FDSEVfTE9DS19FTkFCTEUJb3B0X2dsb2JhbC5oCitBUk1fRE1BX0NPSEVSRU5UCW9wdF9nbG9i YWwuaAogQVJNX0tFUk5fRElSRUNUTUFQCW9wdF92bS5oCiBBUk1fTDJfUElQVAkJb3B0X2dsb2Jh bC5oCiBBUk1fTDJfUFJFRkVUQ0gJCW9wdF9nbG9iYWwuaAotLSAKMi40LjYKCg== --001a113ec89c0de2a2054c074ca8-- From owner-freebsd-arm@freebsd.org Fri Mar 31 14:11:57 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB071D275E8 for ; Fri, 31 Mar 2017 14:11:57 +0000 (UTC) (envelope-from regantechservicesinc@gmail.com) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 64F2CD23 for ; Fri, 31 Mar 2017 14:11:57 +0000 (UTC) (envelope-from regantechservicesinc@gmail.com) Received: by mail-qt0-x231.google.com with SMTP id x35so66054311qtc.2 for ; Fri, 31 Mar 2017 07:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=cdtgVvoDy7ZvY7wW1kTTibIyw1gbEpJDU9/8aALn7mA=; b=vVVxuhKdpgedpUDTFg7Hojua76FdHD56WP4igRYW72InG5N4qIVM6xyuR/fmeIiiQR QJv+Ri6gsXa1HYgrVcPOdejqIFw+F1+ym0NomRueHHIjzXcNkoQtv4C+YNWZMZPLxWPq ncTXsCHAqeLSIYmIKuRsXsCiIpDlSIgpCVBgt+4nmC9E8QoOvibPbil8/J8PhgVpz2XO QE6hAIfeaRjlQBXbeZJtb1YNoAZQlTTydbJ1oOGCeWLaiwPm8YVc/XRHTGxkudPu506Q 5vzKA+r3qUbJd/vdQKO50baD/kmkqmAmysNNm9SRSjzLZwOM6klbttPnSMrsuREtdb6g 5eBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cdtgVvoDy7ZvY7wW1kTTibIyw1gbEpJDU9/8aALn7mA=; b=sm7JfRTugKWPA7yAhCNz9vTquOhxXcCC2spHH/fOK9wlsnFz/J56q9OXwRK0y07Ms7 Ix8h3tRlbXmvIzo3K2Wl+MLrgBp7diPj2gqzS8JZlf5mg/VRw/vTPdJIMvQMY0aQe6YS 98e3TRJO77kMIyyR7kD5imO4dUKq9RfEcQX5bVh5vuXCta+Gi85UGB0W3COlnUQ9OWr9 G06J/mz80RFd7AItutNVtqP6fnGozIA/RZkqMrGe5PXLnkf54rGXzjoQ+HqjciQZLCIh /UV6vveh1YgdVCA3EP1+kAvvcB9K8kaymmFMFZ+kz7/ej77SlmxPSCB9sWTTAl8g4rqM zscw== X-Gm-Message-State: AFeK/H0r8eDG91BCbQRFWfCaCbwH3Ibt6HqcXlB6oRaAEfvj1XsvsKESoHRlKwH+n+qyB+nX/pxHyoeKgwQ4QQ== X-Received: by 10.200.46.77 with SMTP id s13mr2864838qta.88.1490969516353; Fri, 31 Mar 2017 07:11:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.53.141 with HTTP; Fri, 31 Mar 2017 07:11:55 -0700 (PDT) From: DJ Regan Date: Fri, 31 Mar 2017 09:11:55 -0500 Message-ID: Subject: Current state of FreeBSD iMX6 porting efforts? To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 14:11:57 -0000 According to wiki page... https://wiki.freebsd.org/FreeBSD/arm/imx6/ ...the last update of 'what works' vs 'what still needs to be done', was... FreeBSD/arm/imx6 (last edited 2015-02-02 01:54:07 by IanLepore ) ...what is the current state of iMX6 development? And, where can I start to help? :) Thanks, --DJ Regan From owner-freebsd-arm@freebsd.org Fri Mar 31 15:48:34 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91B0DD27007 for ; Fri, 31 Mar 2017 15:48:34 +0000 (UTC) (envelope-from fieldcoil@gmail.com) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 60AC5B5D for ; Fri, 31 Mar 2017 15:48:34 +0000 (UTC) (envelope-from fieldcoil@gmail.com) Received: by mail-pg0-x22d.google.com with SMTP id g2so73858327pge.3 for ; Fri, 31 Mar 2017 08:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=UvSAGH3V5mFdAUwuuxYnBxyZ+oUzVaOoVvpvJhEq5Fg=; b=R3iPsWov0CzkYo1Q/qqz4T8e7gpcem67rX89US13a1XLFQT2bd9wS2EV/moVpDw2jq HUsAwZzgMI+YuVJ3locFPF0rrFDOohzh6BdjvALw8fes8EpQmHDNQ06v4nvee+AUVTXe A8VR0C1oXFIJDKthy9hz0Fae5BHCwm7y9bjXzyMmVZ9rx8301L1rLuFX7zyNSdcuNHYh 5R3Aq6hRyDUfazNz383y0T3/WhpSFzlKiAx5EIuk6QJ0nJwaS1GaIpPUOJtVtP3aEHyI vOFUFphrG+sYGsucX0xf3+PkSnSKIwl86JtHXOekw8nQxzN8qN+CfUoIYWb1wOIK73qL 0e4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UvSAGH3V5mFdAUwuuxYnBxyZ+oUzVaOoVvpvJhEq5Fg=; b=DxTbklu/A7knnLD1c149BYr7+Kgz5mWdaGkZJqQNTw9OOnIuMX7PFLT4CXP6da4nA9 I5GF5U10r1/2sNRrp2EvOUv5WyIIFn6L4A6oxYYVl4YWNIUIKiEOCWQ9C5R7WRUR6lBE IDr++gFRahXH07eJs5O56OYrBR3895gOsfA0TQnr8Ds9PAxxEgqdOVnAv78ZkMuxpQaL etqSYvzzWfjFc2taHYc5Mqidmm2HvxZJ/0enlkPtgmawu4amP2sC0v1S+YZZKTmNyQkm c8P+l/18qrwMYKdLhDeN2+VcHtTLeCRmJXnI4Yq1muj8wy6YahjozQAuvIaSzJ2qz9J9 TbKg== X-Gm-Message-State: AFeK/H1SGnT2rZuYGgbAXdHs4vEdUsMqwdvI+yfz9rqBzrG7uXJrHt345/3niWG2o4kSRXugw9yR0PIg4PUOAA== X-Received: by 10.98.218.76 with SMTP id w12mr3601967pfl.162.1490975313699; Fri, 31 Mar 2017 08:48:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.141 with HTTP; Fri, 31 Mar 2017 08:48:13 -0700 (PDT) From: Wei Yao Date: Fri, 31 Mar 2017 08:48:13 -0700 Message-ID: Subject: Anyone installed FreeBSD on Raspberry Pi Zero W? To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 15:48:34 -0000 Hi FreeBSD folks, I recently got a PRi Zero W. It can boot with Raspbian. I'd like to try FreeBSD on it. However, it halt at U-Boot prompt. And I cannot enter any command by a USB keyboard. Please see attached photo. =E2=80=8B I have tried several different images. All of them have the same issue. 1. official FreeBSD armv6-RPI-B image downloaded from: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/12.0 2. RaspBSD armv6-12.0-RPI-B image downlaoded from: http://download.raspbsd.org/ 3. A self built image by using crochet (board configuration: RaspberryPi) https://github.com/freebsd/crochet Did anyone install FreeBSD on your RPi 0 W? Any suggestions are welcome! Thnaks! ------------------------------------ Wei Yao __o _`\<,_ fieldcoil(AT)gmail.com (*)/ (*) ------------------------------------ From owner-freebsd-arm@freebsd.org Fri Mar 31 23:43:11 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70CCCD27D62 for ; Fri, 31 Mar 2017 23:43:11 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2044DB88 for ; Fri, 31 Mar 2017 23:43:11 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: by mail-yb0-x22a.google.com with SMTP id m133so19450436ybb.1 for ; Fri, 31 Mar 2017 16:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-disposition:in-reply-to; bh=cX+wXqhCVAegA/Qxht5+aMIdTKGcRmVUvBqS5mn7jMA=; b=tzF+rTbVnnbaXT2lXMoih8L6vo/MQu5woMmPsHFQ0W7SgMCVjcNbZdL6VVMFcSWDO8 MQ+ZZlXlwGbplGF/DjyPmJTyZR7CZNcMh+vlg7TgIhJmZPKHRNPNTc8LzQrm5xZbnDX4 70MyeMI9nu+6Qvnl/9fjXVFq0Xv1VFsIGFOSUg/YbBJswKmLNBipyXepxxiO41kbkFW/ PcUnMM+qVBo/Kl59+w0DJK/U2aDthQ33O6ChegMNAxwxm4qFK2umrjn1Zhed8QuiRaLi eLO0F5BDs9E5tQalbIcpBCv6c2THgjKu0NJydM/hBgWOiI3JQ5/BGHQ4yzpWZSHzUTCq HJVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:reply-to :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=cX+wXqhCVAegA/Qxht5+aMIdTKGcRmVUvBqS5mn7jMA=; b=WN/mzPQgQTiDd3CIJe37cjRtG/Yew/03jc5hxP+oBQ6ff6BEb5QzLAyg30Ar7UlqTP H5vai5cCGo6oj2xq5fPEUMbON0JfhCL8+y6vtVnodagZJJT3qzhzBwqxHVH4jaP3VRfY 4lZYl7DMWHHWw8c+KZ//ZoF7U9JuH2s7T4uPQmeDrCVgGLYCTwUURFTUbrfO+9KmrI6X t+Xaslpm/H02fgFX+fmvh49rL/akvyzkHL97izNfd7HVzaXRBGGYKYHJJdVClTTao6E7 sxd8nytgewWP2wVYto2LVADUrbhJtTyrhh7M+VkZTz6VwEm3Sjo/9TVFxmk+kenLCAj7 tpSQ== X-Gm-Message-State: AFeK/H32/OnY03uYrQ/j+OzaXCz9Mc2moGNdmkRKdOoLDl28CZMc1DwWzvbTCj6JvunwHQ== X-Received: by 10.37.86.5 with SMTP id k5mr4084460ybb.66.1491003789462; Fri, 31 Mar 2017 16:43:09 -0700 (PDT) Received: from jrl.uk.to (cm-84.211.229.154.getinternet.no. [84.211.229.154]) by smtp.gmail.com with ESMTPSA id y187sm2675346ywe.49.2017.03.31.16.43.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 16:43:08 -0700 (PDT) Date: Sat, 1 Apr 2017 01:42:16 +0200 From: Rasmus Liland To: Jan Sieka , freebsd-arm Subject: Re: DB-88F6XXX kernel on 88F6281_A0 (GoFlex Net) Message-ID: <20170331234216.GA16657@jrl.uk.to> Reply-To: Rasmus Liland Mail-Followup-To: Jan Sieka , freebsd-arm References: <20170330232907.GA21389@jrl.uk.to> <888745.43951.qm@web101706.mail.ssk.yahoo.co.jp> <20170331094127.GA29618@jrl.uk.to> <20170331111538.GB31398@jrl.uk.to> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170331111538.GB31398@jrl.uk.to> X-GPG-Key-Server: http://pgp.mit.edu X-GPG-Key-FingerPrint: DD51 6042 15B2 DC18 B546 B847 9807 9AF9 3DFD 5DF7 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 23:43:11 -0000 On 2017-03-31 13:15 +0200, Rasmus Liland wrote: > On 2017-03-31 12:45 +0200, Jan Sieka wrote: > > How much memory (RAM) do you have on your board? > > > > I'm recalling that sometimes when we tried to load FreeBSD > > kernel under the wrong address we were overwriting the U-Boot > > in the RAM thus we observed stalled tftp load. So the > > question is what is the address under which the U-Boot is > > copied to the memory on your board. > > U-Boot announces the amount of DRAM to 128MiB, and 256MiB of > NAND. Is there any U-boot command I can run to show some of the > memory mapping to determine the new addresses? Unable to calculate the addresses myself, I found in U-boot already stated address variables of Linux kernel /boot/uImage and ramdisk /uInitrd to be respecively addr_kern=0x680000, and addr_rd=0x1100000, which is an offset of 5568KiB. As stated earlier, it is possible to load kernel.bin from address 0x600000, perhaps 0x680000 is just enough. Will try this, reporting back in some hours. /Rasmus From owner-freebsd-arm@freebsd.org Sat Apr 1 10:07:27 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 005D0D274CD for ; Sat, 1 Apr 2017 10:07:27 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 80A95B0A for ; Sat, 1 Apr 2017 10:07:26 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: by mail-wr0-x229.google.com with SMTP id l43so122447344wre.1 for ; Sat, 01 Apr 2017 03:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=dnQtxzMg1mCnSDl6tLAsPCLbEujhLsuS4RTTfqw+UuI=; b=RmXWK/PaSLG/uU12eCRhkcDae21sT3By1N53k9qGejJj+Mduf0u3FsJskjbNIq5wlQ 5QeysZ14wi1seP2eRNhkh2POGAFmpbJdYOcRAcylQNw1Q8cAg0fmcAQXD4y+zd+zNkGK vi58SVPSpQLlchf6IscybywiyMcyhqFC2jFprYzpN31+58HiqgqyGrwFmJfKsKiTAh7S bSKlzX72lzCue6/6LMuMh4Bzz/odSurwWSjzvrZkxTZqJ/rysdd/iVLibV9gVSkDkRyM 1EyAbnl7WWk/6XeTj8+LAF+Wp3/0hmdpjxj+QB0n7t9goRwm6vsAJq9AsrAWSqArdSPI a2DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:reply-to :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=dnQtxzMg1mCnSDl6tLAsPCLbEujhLsuS4RTTfqw+UuI=; b=pOS0Q98jfvGxihraRRjZC2fYQq9xNH+G5PZY+QPUFfle69G/YvHs29Nf3/FQLSmL5M FVwx6msFocjIYg0vjCZNoh3ADz3NutTvSrCtn/WXWo2T8NlVjnU55aQSItWGWmb3Jx5D 3LvB6cyPFDkAW0/nqZJ6QiTkQB7M9ZRkaDQlls3TH9WDROTGju3NkFi7E+G/E5h8VekC SefjUBD3jLXc2+0BpWj9ObE/JcxSRYp2VJcqzNIsboNInh57c7XPszU2YTVpAgUC0+bK gHZcavSjHSY4FP7wHyTeGGCAvFbP0wcwlsazdKlPpcxbjWCqkTvGsjvEmk8guPoDfcv7 Cw3w== X-Gm-Message-State: AFeK/H0REpeKsWk0e9xh46DN2mmukdsr+6AjtaG24BR6rhrlPiVSmtUWo9lns/N2wS3gEQ== X-Received: by 10.223.178.66 with SMTP id y2mr6935380wra.161.1491041243030; Sat, 01 Apr 2017 03:07:23 -0700 (PDT) Received: from jrl.uk.to (cm-84.211.229.154.getinternet.no. [84.211.229.154]) by smtp.gmail.com with ESMTPSA id s27sm5229438wra.69.2017.04.01.03.07.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Apr 2017 03:07:22 -0700 (PDT) Date: Sat, 1 Apr 2017 12:06:31 +0200 From: Rasmus Liland To: Jan Sieka , Mori Hiroki , freebsd-arm Subject: [SOLUTION] DB-88F6XXX kernel on 88F6281_A0 (GoFlex Net) Message-ID: <20170401100631.GA29011@jrl.uk.to> Reply-To: Rasmus Liland Mail-Followup-To: Jan Sieka , Mori Hiroki , freebsd-arm References: <20170330232907.GA21389@jrl.uk.to> <888745.43951.qm@web101706.mail.ssk.yahoo.co.jp> <20170331094127.GA29618@jrl.uk.to> <20170331111538.GB31398@jrl.uk.to> <20170331234216.GA16657@jrl.uk.to> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170331234216.GA16657@jrl.uk.to> X-GPG-Key-Server: http://pgp.mit.edu X-GPG-Key-FingerPrint: DD51 6042 15B2 DC18 B546 B847 9807 9AF9 3DFD 5DF7 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 10:07:27 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2017-04-01 01:42 +0200, Rasmus Liland wrote: > > Unable to calculate the addresses myself, I found in U-boot > already stated address variables of Linux kernel /boot/uImage and > ramdisk /uInitrd to be respecively addr_kern=0x680000, and > addr_rd=0x1100000, which is an offset of 5568KiB. > > As stated earlier, it is possible to load kernel.bin from address > 0x600000, perhaps 0x680000 is just enough. Will try this, > reporting back in some hours. GUYS!!! IT'S BOOTING!!! The proper way of booting is: · Taking the DOCKSTAR kernel, ripping out the IPSEC_NAT_T to make it compile at all (why this module does not compile on TARGET_ARCH=arm despite being enabled in this stock kernel I do not know) · Loading resulting kernel.bin to address 0x1100000, which is the address already defined in $addr_rd to normally load the Linux ramdisk uInitrd /Rasmus --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="success_DOCKSTAR.diff" --- DOCKSTAR 2017-03-31 12:30:26.752632000 +0200 +++ DOCKSTARWOIPSECNATT 2017-04-01 10:33:02.845141000 +0200 @@ -118,7 +118,6 @@ # IPSec device enc options IPSEC -options IPSEC_NAT_T options TCP_SIGNATURE # include support for RFC 2385 # IPFW --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="success_dmesg.txt" Marvell>> dhcp BOOTP broadcast 1 *** Unhandled DHCP Option in OFFER/ACK: 28 *** Unhandled DHCP Option in OFFER/ACK: 28 DHCP client bound to address 10.6.6.26 *** Warning: no boot file name; using '0A06061A.img' Using egiga0 device TFTP from server 10.6.6.1; our IP address is 10.6.6.26 Filename '0A06061A.img'. Load address: 0x800000 Loading: * TFTP error: 'File not found' (1) Not retrying... Marvell>> printenv addr_rd addr_rd=0x1100000 Marvell>> tftpboot $addr_rd dockstarwoipsecnatt Using egiga0 device TFTP from server 10.6.6.1; our IP address is 10.6.6.26 Filename 'dockstarwoipsecnatt'. Load address: 0x1100000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ########################################################### done Bytes transferred = 6587876 (6485e4 hex) Marvell>> go $addr_rd ## Starting application at 0x01100000 ... Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-STABLE #0 r316330: Sat Apr 1 10:45:38 CEST 2017 root@node:/usr/obj/arm.arm/usr/src/stable/11/sys/DOCKSTARWOIPSECNATT arm FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on LLVM 3.9.1) CPU: Feroceon 88FR131 rev 1 (**unknown 4** core) Little-endian DC enabled IC disabled WA disabled DC streaming enabled BTB disabled L2 enabled L2 prefetch enabled WB enabled LABT branch prediction disabled 16KB/32B 4-way instruction cache 16KB/32B 4-way write-back-locking-C data cache real memory = 134213632 (127 MB) avail memory = 122802176 (117 MB) SOC: Marvell 88F6281 rev A1, TClock 200MHz Instruction cache prefetch disabled, data cache prefetch disabled 256KB 4-way set-associative write-through unified L2 cache random: entropy device external interface ofwbus0: simplebus0: on ofwbus0 cpulist0: on ofwbus0 cpu0: on cpulist0 localbus0: on ofwbus0 ic0: mem 0x20200-0x2023b on simplebus0 timer0: mem 0x20300-0x2032f irq 1 on simplebus0 Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 gpio0: mem 0x10100-0x1011f irq 35,36,37,38,39,40,41 on simplebus0 rtc0: mem 0x10300-0x10307 on simplebus0 twsi0: mem 0x11000-0x1101f irq 43 on simplebus0 iicbus0: on twsi0 iic0: on iicbus0 mge0: mem 0x72000-0x73fff irq 12,13,14,11,46 on simplebus0 mge0: PHY0 attached, phy_sc points to mge0 mge0: Ethernet address: 00:10:75:26:68:44 miibus0: on mge0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto uart0: <16550 or compatible> mem 0x12000-0x1201f irq 33 on simplebus0 uart0: console (1056,n,8,1) uart1: <16550 or compatible> mem 0x12100-0x1211f irq 34 on simplebus0 cesa0: mem 0x30000-0x30fff,0x3d000-0x3dfff irq 22 on simplebus0 ehci0: mem 0x50000-0x50fff irq 48,19 on simplebus0 usbus0: EHCI version 1.0 usbus0 on ehci0 cryptosoft0: Timecounters tick every 10.000 msec ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to accept, logging disabled DUMMYNET 0 with IPv6 initialized (100409) load_dn_sched dn_sched PRIO loaded load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded load_dn_sched dn_sched WF2Q+ loaded load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched FQ_CODEL loaded load_dn_sched dn_sched FQ_PIE loaded load_dn_aqm dn_aqm CODEL loaded load_dn_aqm dn_aqm PIE loaded usbus0: 480Mbps High Speed USB v2.0 Trying to mount root from ufs:/dev/da0s1a []... Root mount waiting for: usbus0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered mountroot: waiting for device /dev/da0s1a... Mounting from ufs:/dev/da0s1a failed with error 19. Loader variables: Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> --X1bOJ3K7DJ5YkBrT-- From owner-freebsd-arm@freebsd.org Sat Apr 1 19:42:36 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20AC1D29B40 for ; Sat, 1 Apr 2017 19:42:36 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D59D2FB for ; Sat, 1 Apr 2017 19:42:35 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: by mail-lf0-x244.google.com with SMTP id x137so9968213lff.1 for ; Sat, 01 Apr 2017 12:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=uGmnLJZmdGVVJ2i2iiAvVvfJU7H8BfmyRaNSkJDfaHI=; b=WEqT6JGGUlOxr+oMdvOGaVfbqm74Ga/FD0+5GfqOFX55CbgPwAuQPdYRiB6e7X7fX6 p39GMypOqkgZs29GE3jz8X5k6/Ny44VKvoNwQOzYfp+8kq0E8zwVFlC3nD3Z+FsJEoqI l9zasEB4eOYRYpII0oSbxFAQgKdHKdBK+RLdUzyxJ/c5mpB2t6hGoH8d40Ok48UXuHwj oQG/QX32LHYnkogYMYBB/AtE0bdzZY9OMaDKGRMifhmYOtQIvomNWw9AquaztZi72cK2 AdvQJ1IIk5uOF+ZAWV3Oy3HI2Is6DB8rowUVORc0avi65qWd1AYEzfJVyC+SjBImToGm FZJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:reply-to :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=uGmnLJZmdGVVJ2i2iiAvVvfJU7H8BfmyRaNSkJDfaHI=; b=IgjAE6O98B+7Gwp6ONnLl5mgANUo59h97J70rmjyFfdWhfFvIAUZT/CePUvmwspFct GeEe/B4SxJM5TRY1nzmcZZGm29ECFzV8DuwhxxHiwtuACuInyy4LF9firu6lGaW0PnxV qxtHFxPLfl46nAePoZXpHAfrkHUb2hG9tfAg503Gk/BysH52mrcCTg3MsKz6LXMejQ2s fbvrampTMHhymqgmeJWNwGSuJZ7rdf8sP+XH5heNw/kVaCHL6R3mRfX9lGqxHa5TTZ2j m2XAl4KHCJ082OS2znhc4biyoLBLB8zTnqe56kQc7NziSQ4GuI+Ddvt9EKjB5BseTFYU 6mbQ== X-Gm-Message-State: AFeK/H3OH5LbVXSZzinNYE8hXJTX0ZBZ80VIENksfdOo+EBWACt91mGCQhYsn9//u/wUvw== X-Received: by 10.46.19.26 with SMTP id 26mr2863807ljt.117.1491075752372; Sat, 01 Apr 2017 12:42:32 -0700 (PDT) Received: from jrl.uk.to (cm-84.211.229.154.getinternet.no. [84.211.229.154]) by smtp.gmail.com with ESMTPSA id r70sm1678869lfi.67.2017.04.01.12.42.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Apr 2017 12:42:31 -0700 (PDT) Date: Sat, 1 Apr 2017 21:41:41 +0200 From: Rasmus Liland To: Jan Sieka , Mori Hiroki Cc: freebsd-arm Subject: Re: [SOLUTION] DB-88F6XXX kernel on 88F6281_A0 (GoFlex Net) Message-ID: <20170401194141.GA2825@jrl.uk.to> Reply-To: Rasmus Liland Mail-Followup-To: Jan Sieka , Mori Hiroki , freebsd-arm References: <20170330232907.GA21389@jrl.uk.to> <888745.43951.qm@web101706.mail.ssk.yahoo.co.jp> <20170331094127.GA29618@jrl.uk.to> <20170331111538.GB31398@jrl.uk.to> <20170331234216.GA16657@jrl.uk.to> <20170401100631.GA29011@jrl.uk.to> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170401100631.GA29011@jrl.uk.to> X-GPG-Key-Server: http://pgp.mit.edu X-GPG-Key-FingerPrint: DD51 6042 15B2 DC18 B546 B847 9807 9AF9 3DFD 5DF7 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 19:42:36 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2017-04-01 12:06 +0200, Rasmus Liland wrote: > · Taking the DOCKSTAR kernel, ripping out the IPSEC_NAT_T to > make it compile at all (why this module does not compile on > TARGET_ARCH=arm despite being enabled in this stock kernel I > do not know) > > · Loading resulting kernel.bin to address 0x1100000, which is > the address already defined in $addr_rd to normally load the > Linux ramdisk uInitrd By browsing around the mailing list, I found this seven year old email from Milan https://lists.freebsd.org/pipermail/freebsd-arm/2010-October/002604.html thus, I added his sata group to a new goflex.dts file based on the old dockstar.dts (see attachment) which still has not evolved much away from the sheevaplug file he edited back then. I also ripped out ipfw and added dtrace. This was such a lot of fun! /Rasmus --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="success_dmesg_mvs.txt" U-Boot 2010.09 (Feb 16 2011 - 18:42:02) UBIT v0.6 by Jeff Doozan and Peter Carmichael SoC: Kirkwood 88F6281_A0 DRAM: 128 MiB NAND: 256 MiB In: serial Out: serial Err: serial Net: egiga0 88E1116 Initialized on egiga0 Creating 1 MTD partitions on "nand0": 0x000002500000-0x000010000000 : "mtd=3" UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 129024 bytes UBI: smallest flash I/O unit: 2048 UBI: sub-page size: 512 UBI: VID header offset: 512 (aligned 512) UBI: data offset: 2048 UBI: fixable bit-flip detected at PEB 1750 UBI: attached mtd1 to ubi0 UBI: MTD device name: "mtd=3" UBI: MTD device size: 219 MiB UBI: number of good PEBs: 1752 UBI: number of bad PEBs: 0 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold: 4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 0 UBI: available PEBs: 1731 UBI: total number of reserved PEBs: 21 UBI: number of PEBs reserved for bad PEB handling: 17 UBI: max/mean erase counter: 2/1 UBIFS error (pid 0): ubifs_get_sb: cannot open "ubi:silent", error -19 Error reading superblock on volume 'ubi:silent'! UBIFS not mounted, use ubifs mount to mount volume first! Using egiga0 device ping failed; host 10.10.10.5 is not alive (Re)start USB... USB: Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 1 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 Marvell>> dhcp BOOTP broadcast 1 *** Unhandled DHCP Option in OFFER/ACK: 28 *** Unhandled DHCP Option in OFFER/ACK: 28 DHCP client bound to address 10.6.6.26 *** Warning: no boot file name; using '0A06061A.img' Using egiga0 device TFTP from server 10.6.6.1; our IP address is 10.6.6.26 Filename '0A06061A.img'. Load address: 0x800000 Loading: * TFTP error: 'File not found' (1) Not retrying... Marvell>> tftpboot $addr_rd goflex Using egiga0 device TFTP from server 10.6.6.1; our IP address is 10.6.6.26 Filename 'goflex'. Load address: 0x1100000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ########################################### done Bytes transferred = 5392104 (5246e8 hex) Marvell>> go $addr_rd ## Starting application at 0x01100000 ... Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-STABLE #11 r316330: Sat Apr 1 18:54:23 CEST 2017 root@node:/usr/obj/arm.arm/usr/src/stable/11/sys/GOFLEX arm FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on LLVM 3.9.1) CPU: Feroceon 88FR131 rev 1 (**unknown 4** core) Little-endian DC enabled IC disabled WA disabled DC streaming enabled BTB disabled L2 enabled L2 prefetch enabled WB enabled LABT branch prediction disabled 16KB/32B 4-way instruction cache 16KB/32B 4-way write-back-locking-C data cache real memory = 134213632 (127 MB) avail memory = 124002304 (118 MB) SOC: Marvell 88F6281 rev A1, TClock 200MHz Instruction cache prefetch disabled, data cache prefetch disabled 256KB 4-way set-associative write-through unified L2 cache random: entropy device external interface ofwbus0: simplebus0: on ofwbus0 cpulist0: on ofwbus0 cpu0: on cpulist0 localbus0: on ofwbus0 nand0: mem 0xf9300000-0xf93fffff on localbus0 nandbus0: on nand0 onand0: on nandbus0 onand0: No BBT found. Prescan chip... #onand0: Bad block(40) onand0: Bad block(41) onand0: Bad block(42) onand0: Bad block(43) onand0: Bad block(44) onand0: Bad block(45) onand0: Bad block(46) onand0: Bad block(47) onand0: Bad block(48) onand0: Bad block(49) onand0: Bad block(50) onand0: Bad block(51) onand0: Bad block(52) onand0: Bad block(53) onand0: Bad block(54) onand0: Bad block(55) onand0: Bad block(56) onand0: Bad block(57) onand0: Bad block(58) onand0: Bad block(59) onand0: Bad block(60) onand0: Bad block(61) onand0: Bad block(62) onand0: Bad block(63) onand0: Bad block(64) onand0: Bad block(65) onand0: Bad block(66) onand0: Bad block(67) onand0: Bad block(68) onand0: Bad block(69) onand0: Bad block(70) onand0: Bad block(71) onand0: Bad block(72) onand0: Bad block(73) onand0: Bad block(74) onand0: Bad block(75) onand0: Bad block(76) onand0: Bad block(77) onand0: Bad block(78) onand0: Bad block(79) onand0: Bad block(80) onand0: Bad block(81) onand0: Bad block(82) onand0: Bad block(83) onand0: Bad block(84) onand0: Bad block(85) onand0: Bad block(86) onand0: Bad block(87) onand0: Bad block(88) onand0: Bad block(89) onand0: Bad block(90) onand0: Bad block(91) onand0: Bad block(92) onand0: Bad block(93) onand0: Bad block(94) onand0: Bad block(95) onand0: Bad block(96) onand0: Bad block(97) onand0: Bad block(98) onand0: Bad block(99) onand0: Bad block(100) #onand0: Bad block(101) onand0: Bad block(102) onand0: Bad block(103) onand0: Bad block(104) onand0: Bad block(105) onand0: Bad block(106) onand0: Bad block(107) onand0: Bad block(108) onand0: Bad block(109) onand0: Bad block(110) onand0: Bad block(111) onand0: Bad block(112) onand0: Bad block(113) onand0: Bad block(114) onand0: Bad block(115) onand0: Bad block(116) onand0: Bad block(117) onand0: Bad block(118) onand0: Bad block(119) onand0: Bad block(120) onand0: Bad block(121) onand0: Bad block(122) onand0: Bad block(123) onand0: Bad block(124) onand0: Bad block(125) onand0: Bad block(126) onand0: Bad block(127) onand0: Bad block(128) onand0: Bad block(129) onand0: Bad block(130) onand0: Bad block(131) onand0: Bad block(132) onand0: Bad block(133) onand0: Bad block(134) onand0: Bad block(135) onand0: Bad block(136) onand0: Bad block(137) onand0: Bad block(138) onand0: Bad block(139) onand0: Bad block(140) onand0: Bad block(141) onand0: Bad block(142) onand0: Bad block(143) onand0: Bad block(144) onand0: Bad block(145) onand0: Bad block(146) onand0: Bad block(147) onand0: Bad block(148) onand0: Bad block(149) onand0: Bad block(150) onand0: Bad block(151) onand0: Bad block(152) onand0: Bad block(153) onand0: Bad block(154) onand0: Bad block(155) onand0: Bad block(156) onand0: Bad block(157) onand0: Bad block(158) onand0: Bad block(159) onand0: Bad block(160) onand0: Bad block(161) onand0: Bad block(162) onand0: Bad block(163) onand0: Bad block(164) onand0: Bad block(165) onand0: Bad block(166) onand0: Bad block(167) onand0: Bad block(168) onand0: Bad block(169) onand0: Bad block(170) onand0: Bad block(171) onand0: Bad block(172) onand0: Bad block(173) onand0: Bad block(174) onand0: Bad block(175) onand0: Bad block(176) onand0: Bad block(177) onand0: Bad block(178) onand0: Bad block(179) onand0: Bad block(180) onand0: Bad block(181) onand0: Bad block(182) onand0: Bad block(183) onand0: Bad block(184) onand0: Bad block(185) onand0: Bad block(186) onand0: Bad block(187) onand0: Bad block(188) onand0: Bad block(189) onand0: Bad block(190) onand0: Bad block(191) onand0: Bad block(192) onand0: Bad block(193) onand0: Bad block(194) onand0: Bad block(195) onand0: Bad block(196) onand0: Bad block(197) onand0: Bad block(198) onand0: Bad block(199) onand0: Bad block(200) #onand0: Bad block(201) onand0: Bad block(202) onand0: Bad block(203) onand0: Bad block(204) onand0: Bad block(205) onand0: Bad block(206) onand0: Bad block(207) onand0: Bad block(208) onand0: Bad block(209) onand0: Bad block(210) onand0: Bad block(211) onand0: Bad block(212) onand0: Bad block(213) onand0: Bad block(214) onand0: Bad block(215) onand0: Bad block(216) onand0: Bad block(217) onand0: Bad block(218) onand0: Bad block(219) onand0: Bad block(220) onand0: Bad block(221) onand0: Bad block(222) onand0: Bad block(223) onand0: Bad block(224) onand0: Bad block(225) onand0: Bad block(226) onand0: Bad block(227) onand0: Bad block(228) onand0: Bad block(229) onand0: Bad block(230) onand0: Bad block(231) onand0: Bad block(232) onand0: Bad block(233) onand0: Bad block(234) onand0: Bad block(235) onand0: Bad block(236) onand0: Bad block(237) onand0: Bad block(238) onand0: Bad block(239) onand0: Bad block(240) onand0: Bad block(241) onand0: Bad block(242) onand0: Bad block(243) onand0: Bad block(244) onand0: Bad block(245) onand0: Bad block(246) onand0: Bad block(247) onand0: Bad block(248) onand0: Bad block(249) onand0: Bad block(250) onand0: Bad block(251) onand0: Bad block(252) onand0: Bad block(253) onand0: Bad block(254) onand0: Bad block(255) onand0: Bad block(256) onand0: Bad block(257) onand0: Bad block(258) onand0: Bad block(259) onand0: Bad block(260) onand0: Bad block(261) onand0: Bad block(262) onand0: Bad block(263) onand0: Bad block(264) onand0: Bad block(265) onand0: Bad block(266) onand0: Bad block(267) onand0: Bad block(268) onand0: Bad block(269) onand0: Bad block(270) onand0: Bad block(271) onand0: Bad block(272) onand0: Bad block(273) onand0: Bad block(274) onand0: Bad block(275) onand0: Bad block(276) onand0: Bad block(277) onand0: Bad block(278) onand0: Bad block(279) onand0: Bad block(280) onand0: Bad block(281) onand0: Bad block(282) onand0: Bad block(283) onand0: Bad block(284) onand0: Bad block(285) onand0: Bad block(286) onand0: Bad block(287) onand0: Bad block(288) onand0: Bad block(289) onand0: Bad block(290) onand0: Bad block(291) onand0: Bad block(292) onand0: Bad block(293) onand0: Bad block(294) onand0: Bad block(295) ################## ic0: mem 0x20200-0x2023b on simplebus0 timer0: mem 0x20300-0x2032f irq 1 on simplebus0 Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 gpio0: mem 0x10100-0x1011f irq 35,36,37,38,39,40,41 on simplebus0 rtc0: mem 0x10300-0x10307 on simplebus0 twsi0: mem 0x11000-0x1101f irq 43 on simplebus0 iicbus0: on twsi0 iic0: on iicbus0 mge0: mem 0x72000-0x73fff irq 12,13,14,11,46 on simplebus0 mge0: PHY0 attached, phy_sc points to mge0 mge0: Ethernet address: 00:10:75:26:68:44 miibus0: on mge0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto uart0: <16550 or compatible> mem 0x12000-0x1201f irq 33 on simplebus0 uart0: console (1056,n,8,1) uart1: <16550 or compatible> mem 0x12100-0x1211f irq 34 on simplebus0 cesa0: mem 0x30000-0x30fff,0x3d000-0x3dfff irq 22 on simplebus0 ehci0: mem 0x50000-0x50fff irq 48,19 on simplebus0 usbus0: EHCI version 1.0 usbus0 on ehci0 mvs0: mem 0x80000-0x85fff irq 21 on simplebus0 mvs0: Gen-IIe, 2 3Gbps ports, Port Multiplier supported with FBS mvsch0: at channel 0 on mvs0 mvsch1: at channel 1 on mvs0 cryptosoft0: Timecounters tick every 10.000 msec usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ada0 at mvsch1 bus 0 scbus1 target 0 lun 0 ada0: ATA8-ACS SATA 3.x device ada0: Serial Number WD-WX61AB52YARF ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 715404MB (1465149168 512 byte sectors) Trying to mount root from ufs:/dev/ufs/kirkwoodroot []... uhub0: 1 port with 1 removable, self powered /etc/rc: WARNING: hostid: unable to figure out a UUID from DMI data, generating a new one Setting hostuuid: 65b98826-bfde-11d3-9568-001075266844. Setting hostid: 0x68d9fd01. Starting file system checks: Mounting local filesystems:. ELF ldconfig path: /lib /usr/lib /usr/lib/compat random: unblocking device. Setting hostname: uruk. Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED Feeding entropy: . mge0: link state changed to UP Starting Network: lo0 mge0 enc0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=21 mge0: flags=8843 metric 0 mtu 1500 options=8000b ether 00:10:75:26:68:44 media: Ethernet autoselect (1000baseT ) status: active nd6 options=29 enc0: flags=0<> metric 0 mtu 1536 groups: enc nd6 options=29 Starting devd. Starting Network: enc0. enc0: flags=0<> metric 0 mtu 1536 groups: enc nd6 options=29 Starting dhclient. DHCPDISCOVER on mge0 to 255.255.255.255 port 67 interval 5 DHCPOFFER from 10.6.6.1 DHCPREQUEST on mge0 to 255.255.255.255 port 67 DHCPACK from 10.6.6.1 bound to 10.6.6.26 -- renewal in 21600 seconds. add host 127.0.0.1: gateway lo0 fib 0: route already in table add host ::1: gateway lo0 fib 0: route already in table add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Generating host.conf. Creating and/or trimming log files. Starting syslogd. Clearing /tmp (X related). Updating motd:. Mounting late filesystems:. Starting ntpd. Generating RSA host key. 2048 SHA256:SfFGKrfY+B+9YvNl1IAl/Ah16cBelwUP+ZrAEUhy3Ao root@uruk (RSA) Generating ECDSA host key. 256 SHA256:/76LXsrpoZk06L8OCovaByaS8rbBi4pgImru0t/H0MQ root@uruk (ECDSA) Generating ED25519 host key. 256 SHA256:wm6eeGoXMgnLsKGhL4cQuwRAZ3GUOTjvPrXe0xBuzOI root@uruk (ED25519) Performing sanity check on sshd configuration. Starting sshd. Starting sendmail_submit. Starting sendmail_msp_queue. Starting cron. Sat Jan 1 00:00 FreeBSD/arm (uruk) (ttyu0) login: --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="success_GOFLEX.diff" --- DOCKSTAR 2017-03-31 12:30:26.752632000 +0200 +++ GOFLEX 2017-04-01 20:10:43.480437000 +0200 @@ -19,7 +19,7 @@ # #NO_UNIVERSE -ident DOCKSTAR +ident GOFLEX include "std.arm" include "../mv/kirkwood/std.db88f6xxx" @@ -31,9 +31,6 @@ options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support -options NFSCL # Network Filesystem Client -options NFSLOCKD # Network Lock Manager -#options NFS_ROOT # NFS usable as /, requires NFSCL options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 filesystem options NULLFS # NULL filesystem @@ -48,21 +45,10 @@ options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions -# Enable these options for nfs root configured via BOOTP. -#options BOOTP -#options BOOTP_NFSROOT -#options BOOTP_NFSV3 -#options BOOTP_WIRED_TO=mge0 - -# If not using BOOTP, use something like one of these... -#options ROOTDEVNAME=\"ufs:/dev/da0a\" -options ROOTDEVNAME=\"ufs:/dev/da0s1a\" -#options ROOTDEVNAME=\"ufs:/dev/da0p10\" -#options ROOTDEVNAME=\"nfs:192.168.0.254/dreamplug\" +options ROOTDEVNAME=\"ufs:/dev/ufs/kirkwoodroot\" # Misc pseudo devices device bpf # Required for DHCP -device firmware # firmware(9) required for USB wlan device gif # IPv6 and IPv4 tunneling device loop # Network loopback device md # Memory/malloc disk @@ -71,7 +57,6 @@ device tun # Packet tunnel. device ether # Required for all ethernet devices device vlan # 802.1Q VLAN support -device wlan # 802.11 WLAN support # cam support for umass and ahci device scbus @@ -92,23 +77,18 @@ device usb # Basic usb support device ehci # USB host controller device umass # Mass storage -device uhid # Human-interface devices -device rum # Ralink Technology RT2501USB wireless NICs -device uath # Atheros AR5523 wireless NICs -device ural # Ralink Technology RT2500USB wireless NICs -device zyd # ZyDAS zb1211/zb1211b wireless NICs -device urtw # Realtek RTL8187B/L USB -device upgt # Conexant/Intersil PrismGT SoftMAC USB -device u3g # USB-based 3G modems (Option, Huawei, Sierra) # I2C (TWSI) device iic device iicbus device twsi -# Sound -device sound -device snd_uaudio +# SATA +device mvs +device ahci + +# NAND +#device nand #crypto device cesa # Marvell security engine @@ -118,18 +98,13 @@ # IPSec device enc options IPSEC -options IPSEC_NAT_T options TCP_SIGNATURE # include support for RFC 2385 -# IPFW -options IPFIREWALL -options IPFIREWALL_DEFAULT_TO_ACCEPT -options IPFIREWALL_VERBOSE -options IPFIREWALL_VERBOSE_LIMIT=100 -options IPFIREWALL_NAT -options LIBALIAS -options DUMMYNET -options IPDIVERT +# DTrace +options KDTRACE_HOOKS +options DDB_CTF +makeoptions DEBUG=-g +makeoptions WITH_CTF=1 #PF device pf @@ -153,4 +128,4 @@ # Flattened Device Tree options FDT # Configure using FDT/DTB data options FDT_DTB_STATIC -makeoptions FDT_DTS_FILE=dockstar.dts +makeoptions FDT_DTS_FILE=goflex.dts --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="success_goflex.dts.diff" --- dockstar.dts 2017-03-31 12:28:49.296360000 +0200 +++ goflex.dts 2017-04-01 20:21:27.895671000 +0200 @@ -227,6 +227,13 @@ interrupts = <5 6 7 8>; interrupt-parent = <&PIC>; }; + + sata@80000 { + compatible = "mrvl,sata"; + reg = <0x80000 0x6000>; + interrupts = <21>; + interrupt-parent = <&PIC>; + }; }; SRAM: sram@fd000000 { --0OAP2g/MAC+5xKAE-- From owner-freebsd-arm@freebsd.org Sat Apr 1 23:00:40 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9248DD29233 for ; Sat, 1 Apr 2017 23:00:40 +0000 (UTC) (envelope-from ash@aeria.net) Received: from death.aeria.net (death.aeria.net [205.134.176.45]) by mx1.freebsd.org (Postfix) with ESMTP id 65FC7643 for ; Sat, 1 Apr 2017 23:00:40 +0000 (UTC) (envelope-from ash@aeria.net) X-Comment: SPF not applicable to localhost connection - skipped check Received: from localhost (localhost [127.0.0.1]) by death.aeria.net (Postfix) with ESMTP id 51A314E738 for ; Sat, 1 Apr 2017 23:00:33 +0000 (UTC) From: ash To: Subject: BBB spi dts follow up Date: Sat, 01 Apr 2017 23:00:32 +0000 MIME-Version: 1.0 Message-ID: <3b095b47-f3fb-488f-92f3-518e69d282c1@aeria.net> Organization: aeria User-Agent: Trojita Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 23:00:40 -0000 I decompiled the stock dts to get started with: #dtc -I dtb -O dts /boot/dtb/beaglebone-black.dtb https://lists.freebsd.org/pipermail/svn-src-head/2016-March/084091.html mentions pin configuration and a patchset for lighting up the spi1=20 peripheral, this may be a job for figuring out the correct overlay and=20 rebuilding the dts from within the tree.. hrmmm. Inferred this entry from other spi dts defs in sys/boot/ofw/dts without=20 much shame about it being the correct part yet. #diff new.dts orig.dts =20= :root:/home:21:47:07:484beaglebone 800,816d799 < /*## >ash XXX frobnicate the pin=20 settings the hard way; i can do without the preprocess, thanks cscope < // replace with an this overlay=20 patch eventially, after carefully reviweing the ds < #define AM33XX_IOPAD(pa, val) =20= OMAP_IOPAD_OFFSET((pa), 0x0800) (val) < #define OMAP_IOPAD_OFFSET(pa,=20 offset) (((pa) & 0xffff) - (offset)) < #pinmux_spi1_pins { < #pinctrl-single,pins =3D < < # AM33XX_IOPAD(0x964,=20 PIN_INPUT_PULLUP | MUX_MODE2) eCAP0_in_PWM0_out.spi1_cs1=20 < # AM33XX_IOPAD(0x990,=20 PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcasp0_aclkx.spi1_sclk=20 < # AM33XX_IOPAD(0x994,=20 PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcasp0_fsx.spi1_d0 - miso=20 < # AM33XX_IOPAD(0x998,=20 PIN_INPUT_PULLUP | MUX_MODE3) /* mcasp0_axr0.spi1_d1 - mosi=20 < # AM33XX_IOPAD(0x99c,=20 PIN_INPUT_PULLUP | MUX_MODE3) /* mcasp0_ahclkr.spi1_cs0=20 < #=20 < #define PIN_INPUT_PULLUP =20 (INPUT_EN | PULL_UP) < #define PIN_INPUT_PULLDOWN =20 (PULL_ENA | INPUT_EN) < #define INPUT_EN (1=20= << 5)=20 < #define PULL_ENA (1=20= << 3) < #define PULL_UP (1=20= << 4) 818,838d800 < #define MUX_MODE2 2 < #define MUX_MODE3 3 < needed modes:=20 <=20 < PIN_INPUT_PULLUP | MUX_MODE2 =3D dc=20= -e '16o 2 5 ^ 2 4 ^ 2 ++ p' =3D 0x32 < PIN_INPUT_PULLDOWN | MUX_MODE3 =3D=20= dc -e '16o 2 5 ^ 2 3 ^ 3 + + p' =3D 0x2B < PIN_INPUT_PULLUP | MUX_MODE3 =3D =3D = dc=20 -e '16o 2 5 ^ 2 4 ^ 3 ++ p' =3D 0x33 < */ <=20 < pinmux_spi1_pins {=20 < pinctrl-single,pins =3D <=20 0x164 0x32 0x190 0x2B 0x194 0x2B 0x198 0x33 0x19C 0x33 >; <=20 < /* what's the rest of this=20= phandle stuff for? < =20 http://elinux.org/Device_Tree_Mysteries#Phandle < Most device trees in Device=20= Tree Syntax (DTS) (see Appendix A) will not contain explicit < phandle properties. The DTC=20= tool automatically inserts the phandle properties when the DTS < is compiled into the binary=20= DTB format. - < - ignore adn dtb generator=20= should write it for me?*/ < };=20 < /* never again - how do I use the=20= overlays??? */=20 <=20 1737,1739c1699 < status =3D "okay"; /* >ash was disabled */ < pinctrl-names =3D "default"; /*>ash reference pin=20 config*/ < /*>nope for overlay pinctrl-0 =3D <&spi1_pins>; */ --- > status =3D "disabled"; 1742,1749d1701 < fnord-flash@0 { < #address-cells =3D <1>; < #size-cells =3D <1>; < compatible =3D "st,m25p128",=20 "jedec,spi-nor"; < reg =3D <0>; /* Chip select 0 */ < spi-max-frequency =3D <50000000>; < m25p,fast-read; < }; Rebuild the dts: dtc -I dts -O dtb new.dts > out.dtb cp to /boot/dtb/out.dtb so we can get at it at boottime without overwriting=20= default; still nervous about rewiring the device tree without supervision.=20= I'm sure that I'm going to leave myself without a main oscilator.=20 *reboot, escape to our loader ( not U-boot,which seems to honor it's own=20 different dts' in /boot/msdos/dts)=20 loader> load -t dtb boot/dtb/out.dtb boot/dtb/out.dtb size=3D0xcca8 =20 I'll fix loader.conf after I'm more confident about the solution. then from dmesg:=20 spibus0: on spi0 spibus0: at cs 0 mode 0 ofwdump -a ... Node 0x68cc: spi@481a0000 Node 0x69f0: fnord-flash@0 ... Good news from in sysctl:=20 ... dev.spibus.0.%pnpinfo:=20 dev.spibus.0.%location:=20 dev.spibus.0.%driver: spibus dev.spibus.0.%desc: OFW SPI bus dev.spibus.%parent:=20 dev.spi.0.%parent: simplebus0 dev.spi.0.%pnpinfo: name=3Dspi@481a0000 compat=3Dti,omap4-mcspi dev.spi.0.%location:=20 dev.spi.0.%driver: spi dev.spi.0.%desc: TI McSPI controller dev.spi.%parent:=20 ... But still no /dev/spi0 device. Any pointers are welcome. Is this the time I write a driver or find one in tree that will attach to=20= the 'unknown card' entry. Is it possible to defer the driver load so perhaps i could poke around=20 this at boot time?: dtrace -n 'fbt::*ti_spi*:entry fbt::spibus*:entry' --=20 -ash From owner-freebsd-arm@freebsd.org Sat Apr 1 23:13:31 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1E6DD296D4 for ; Sat, 1 Apr 2017 23:13:31 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 99FEBE3 for ; Sat, 1 Apr 2017 23:13:31 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cuSCz-000DDq-4k; Sat, 01 Apr 2017 16:13:31 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v31NDOJu050829; Sat, 1 Apr 2017 16:13:24 -0700 (PDT) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Sat, 1 Apr 2017 16:13:24 -0700 From: Oleksandr Tymoshenko To: ash Cc: freebsd-arm@freebsd.org Subject: Re: BBB spi dts follow up Message-ID: <20170401231324.GA50794@bluezbox.com> References: <3b095b47-f3fb-488f-92f3-518e69d282c1@aeria.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3b095b47-f3fb-488f-92f3-518e69d282c1@aeria.net> X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: ash (ash@aeria.net) wrote: > I decompiled the stock dts to get started with: > > #dtc -I dtb -O dts /boot/dtb/beaglebone-black.dtb ... skipped ... > But still no /dev/spi0 device. Any pointers are welcome. There is no /dev/spi0 in FreeBSD at the moment. The only way to access SPI from userland is by using spigen device. With later HEAD builds (post r314934) you can load it as a module: "kldload spigen" otherwise you'll need to add it to kernel config as a "device spigen". [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: github.com] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 23:13:31 -0000 ash (ash@aeria.net) wrote: > I decompiled the stock dts to get started with: > > #dtc -I dtb -O dts /boot/dtb/beaglebone-black.dtb ... skipped ... > But still no /dev/spi0 device. Any pointers are welcome. There is no /dev/spi0 in FreeBSD at the moment. The only way to access SPI from userland is by using spigen device. With later HEAD builds (post r314934) you can load it as a module: "kldload spigen" otherwise you'll need to add it to kernel config as a "device spigen". spigen functionality is very limited, you can't specify SPI mode or CS line. General procedure is to open /dev/spigen0 with O_RDWR and then use ioctls to transfer data. You can use this example as a simple reference: https://github.com/gonzoua/freebsd-embedded-demos/blob/master/libssd1306/ssd1306_spi.c#L86 -- gonzo