From owner-freebsd-arm@FreeBSD.ORG Sun Jan 11 01:03:37 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32A1D28E for ; Sun, 11 Jan 2015 01:03:37 +0000 (UTC) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9027DC31 for ; Sun, 11 Jan 2015 01:03:35 +0000 (UTC) Received: from [208.184.220.60] (helo=macbook-air-3.dolby.net) by id.bluezbox.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YA6wC-000AsU-Uk for freebsd-arm@freebsd.org; Sat, 10 Jan 2015 17:03:30 -0800 From: Oleksandr Tymoshenko Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: xdev-links names and clang Message-Id: <2CBEDF87-5932-417B-99DB-19B476B0A032@bluezbox.com> Date: Sat, 10 Jan 2015 17:02:56 -0800 To: "freebsd-arm@freebsd.org List" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Sender: gonzo@id.bluezbox.com X-Spam-Level: / X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Hello, I got bit by weird problem when tried to run application built with CC set to armv6-freebsd-cc. It crashed in qsort's compare function and when I tried to debug it it started crashing in all weird places. [...] Content analysis details: (-0.2 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] 2.7 DNS_FROM_AHBL_RHSBL RBL: Envelope sender listed in dnsbl.ahbl.org 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: pastebin.com] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 01:03:37 -0000 Hello, I got bit by weird problem when tried to run application built with CC set to armv6-freebsd-cc. It crashed in qsort's compare function and when I tried to debug it it started crashing in all weird places. The same app built with CC set to "cc" in buldenv worked fine. Turned out that clang determines it's target triplet based on the name of executable file. And armv6-freebsd-cc generated by xdev-links does not match the default one. ln -s /usr/armv6-freebsd/usr/bin/cc cc ln -s /usr/armv6-freebsd/usr/bin/cc armv6-frebsd-cc ln -s /usr/armv6-freebsd/usr/bin/cc armv6-gnueabi-freebsd11.0-cc default target for these three links would be different % ./cc -v FreeBSD clang version 3.5.0 (tags/RELEASE_350/final 216957) 20141124 Target: armv6--freebsd11.0-gnueabi Thread model: posix % ./armv6-freebsd-cc -v FreeBSD clang version 3.5.0 (tags/RELEASE_350/final 216957) 20141124 Target: armv6--freebsd Thread model: posix % ./armv6-gnueabi-freebsd11.0-cc -v FreeBSD clang version 3.5.0 (tags/RELEASE_350/final 216957) 20141124 Target: armv6--freebsd11.0-gnueabi Thread model: posix I generated default #defines for them using "$CC -dM -E - < /dev/null" and they look different enough to mess things up Full diff between second and first: http://pastebin.com/GLtsQfuv Default includes for armv6-freebsd-cc have __FreeBSD__ set to 8, __ARM_EABI__ is undefined and wchar_t defines are different too. Should we update xdev-links logic to match clang's target triplets? -- gonzo From owner-freebsd-arm@FreeBSD.ORG Sun Jan 11 04:03:08 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77CD2905 for ; Sun, 11 Jan 2015 04:03:08 +0000 (UTC) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EACFE06 for ; Sun, 11 Jan 2015 04:03:07 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 9C2616811E for ; Sun, 11 Jan 2015 12:57:42 +0900 (JST) Received: from artemis (unknown [172.18.0.21]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id 8939F68118 for ; Sun, 11 Jan 2015 12:57:42 +0900 (JST) Message-ID: <8B52D212B8274A619E32AB455C941860@ad.peach.ne.jp> From: "Daisuke Aoyama" To: References: In-Reply-To: Subject: Re: NAS4Free on Raspberry Pi and ARM problems Date: Sun, 11 Jan 2015 12:57:39 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 04:03:08 -0000 Hi all, I've made probably final test image of NAS4Free. This contains workaround patches which solve previous failures such as: "[Bug 181601] Sporadic failure of root mount on ARM/Raspberry" http://lists.freebsd.org/pipermail/freebsd-arm/2014-December/009866.html "C++ exceptions in freebsd-arm doesn't seem to work" http://lists.freebsd.org/pipermail/freebsd-arm/2014-August/008994.html Now clang 3.5 and NAS4Free work well. Thank you for importing clang 3.5. NAS4Free has been built by 100% clang. (u-boot was built by clang 3.4 at last year) You can get latest test image of NAS4Free 9.3.0.2 for RPi(1GB SD card) from: http://www.peach.ne.jp/archives/nas4free/test/NAS4Free-rpi-SD-9.3.0.2.1295-20150111.img.gz If it works well on broken SD cards, I will create separated patches against latest FreeBSD source. If you have broken cards, please help checking SD cards. Simply, write above image and boot it! Try to dd from mmcsd0 like this from console menu #6: (expect over 12.5MB/s) # dd if=/dev/mmcsd0 of=/dev/null bs=1m count=64 Changes since 9.3.0.2.1214: base image of FreeBSD is switched to clang 3.5 version. finished to import both ports/firefly (iTunes/DAAP) and ports/fuppes (DLNA/UPnP). resolved c++ exception (avoid smartctl core dump). add workaround HS mode (solves failure HS detection) improve DMA mode of SDHCI access. fix wrong word access in bcm2835_sdhci. change loader.conf to set hw.bcm2835.sdhci.hs=1. change system partition size. add extra partition. include all NAS4Free changes. (now all WebGUI code is merged in trunk@SVN) -------------------------------------------------------------------------------------- How to use extra partition: If you write NAS4Free to SD card of 2GB or more capacity, you can use extra partition as data area. Boot any version of NAS4Free or FreeBSD based on 11-CURRENT. Insert SD card written new version to USB card reader, then attach to booted host. If your card is detected as da0, run following commands: (please replace da0 with your USB card reader's device) # gpart resize -i4 da0 # gpart resize -a4m -i1 da0s4 # newfs -U -j /dev/da0s4a Now you have formatted data area in the end of SD card. Note: You can't modify correctly after booting. Using USB card reader before booting is very important. After booting resized new version, go to "Disks|Management" and click "Import disks". Next, go to "Disks|Mount Point|Management", and add mount point. Select "Disk" -> your SD card, "Partition type" -> MBR partition, "Partition number" -> 4, "Mount point name" -> any string. Click Add button. Finally, apply the change. Now above /dev/da0s4a is mounted on /mnt/. You can add shares on it. -------------------------------------------------------------------------------------- Unchecked/Unresolved problems: >Internal LAN driver cause timeout. >>kernel: smsc0: warning: MII read timeout >>kernel: smsc0: warning: Failed to read register 0x114 I didn't see it on r276645 kernel. -------------------------------------------------------------------------------------- HS mode booting tested cards: HanyeTech 64GB UHS-I mmcsd0: 65GB at mmc0 50.0MHz/4bit/65535-block Transcend 32GB UHS-I TS32GSDU1 mmcsd0: 32GB at mmc0 50.0MHz/4bit/65535-block TOSHIBA EXCERIA TypeHD 32GB UHS-I SD-H32GR7WA3 mmcsd0: 32GB at mmc0 50.0MHz/4bit/65535-block SAMSUNG EVO 16GB UHS-I MB-SP16D/JPEC mmcsd0: 16GB at mmc0 50.0MHz/4bit/65535-block TOSHIBA microSD 16GB UHS-I SD-C016GR7AR30 mmcsd0: 16GB at mmc0 50.0MHz/4bit/65535-block KINGMAX 8GB Class10 KM-SDHC10X8G mmcsd0: 8GB at mmc0 50.0MHz/4bit/65535-bloc Amazon Basics 8GB Class10 mmcsd0: 8GB at mmc0 50.0MHz/4bit/65535-block IO DATA microSD 4GB Class4 BMS-4G4A mmcsd0: 4GB at mmc0 50.0MHz/4bit/65535-block -------------------------------------------------------------------------------------- dd result of SD-H32GR7WA3: # dd if=/dev/mmcsd0 of=/dev/null bs=1m count=64 64+0 records in 64+0 records out 67108864 bytes transferred in 2.961009 secs (22664188 bytes/sec) # dd if=/dev/zero of=/dev/mmcsd0s2b bs=1m count=64 64+0 records in 64+0 records out 67108864 bytes transferred in 4.815796 secs (13935155 bytes/sec) -------------------------------------------------------------------------------------- Enjoy NAS4Free world yourself. Thanks, -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Sun Jan 11 18:30:19 2015 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 71803E for ; Sun, 11 Jan 2015 18:30:19 +0000 (UTC) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1479F65 for ; Sun, 11 Jan 2015 18:30:18 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id u56so15683743wes.2 for ; Sun, 11 Jan 2015 10:30:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=zKqEvDZgRG+ERPNRuxhvu0ax4zqYyX8MR6e5I+yO1tE=; b=D4zfv9h8EVQG2gF4ZjtLBBZ6I9ceWtrbpRO6ea0Zs/2xma/rr2Dl1xvr2a9sD/irrk 5zrfuz8bs6QfdPRkFLkmMf1k+b7iuEmIN/n78GIwGVUIlvajvLlXhwZehh4F9egcwBuz PImQRXTbP+L0HZgNHzSzNhaVqD23AWJnPYTc2xda7qPN+z2Epo8YZt7liOIx+fofklJA rTGZRsmT7EFDfpdtG/yRKqlgCfnakENizHcMgcjHzii67R0m5Sz7h7cM4PHBitQvg7uK KsLOSoZDmpRBFLmu2rM8t0WXjmimmJWzrPOlECAj6t07I5QKNc/J0/XPypGYaOmYkAQK G3DQ== X-Gm-Message-State: ALoCoQkwKsIVtUFCdCXH8cpw9XQy4zCeMBC7bk1hq7+pOHQNLKpC/Ysj3YpKAgLhTAIdkTLW6vrh MIME-Version: 1.0 X-Received: by 10.194.84.105 with SMTP id x9mr22677235wjy.17.1420999362512; Sun, 11 Jan 2015 10:02:42 -0800 (PST) Received: by 10.217.95.3 with HTTP; Sun, 11 Jan 2015 10:02:42 -0800 (PST) Date: Sun, 11 Jan 2015 11:02:42 -0700 Message-ID: Subject: Soekris 4501 IRQ 5 interrupt storm on FreeBSD-11 From: Tom Everett To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 18:30:19 -0000 I recently did a build and I'm now seeing this problem. I don't recall this issue previously. Does anyone have any insight into what may have changed? POST: 012345689bcefghipsajklnopqr,,,tvwxy comBIOS ver. 1.33 20080103 Copyright (C) 2000-2007 Soekris Engineering. net45xx 0064 Mbyte Memory CPU Elan SC520 133 Mhz Pri Mas SanDisk SDCFX-016G LBA Xlt 1024--63 15625 Mbyte Slot Vend Dev ClassRev Cmd Stat CL LT HT Base1 Base2 Int ------------------------------------------------------------------- 0:00:0 1022 3000 06000000 0006 2280 00 00 00 00000000 00000000 0:18:0 100B 0020 02000000 0107 0290 00 3F 00 0000E001 A0000000 10 0:19:0 100B 0020 02000000 0107 0290 00 3F 00 0000E101 A0001000 11 0:20:0 100B 0020 02000000 0107 0290 00 3F 00 0000E201 A0002000 05 1 Seconds to automatic boot. Press Ctrl-P for entering Monitor. /boot/config: -h Consoles: serial port BIOS drive C: is disk0 BIOS 639kB/64512kB available memory FreeBSD/x86 bootstrap loader, Revision 1.1 (tom@bernice, Sat Jan 10 18:29:47 MST 2015) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0xf9a4fc data=0xde7ec+0x1c7a98 syms=[0x4+0xd8ff0+0x4+0x1611cd] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r276949M: Sat Jan 10 19:16:08 MST 2015 tom@bernice:/tank/home/tom/freebsd/crochet-freebsd/work/obj/i386.i386/tank/home/tom/freebsd/src/FreeBSDHead/head/sys/SOEKRIS i386 FreeBSD clang version 3.5.0 (tags/RELEASE_350/final 216957) 20141124 WARNING: WITNESS option enabled, expect reduced performance. VT: running with driver "vga". CPU: AMD Enhanced Am486DX4/Am5x86 Write-Back (486-class CPU) Origin="AuthenticAMD" Id=0x494 Family=0x4 Model=0x9 Stepping=4 Features=0x1 real memory = 67108864 (64 MB) avail memory = 34369536 (32 MB) random device not loaded/active; using insecure pseudo-random number generator random: entropy device infrastructure driver random: selecting highest priority adaptor kbd1 at kbdmux0 module_register_init: MOD_LOAD (vesa, 0xc0fc1710, 0) error 19 random: SOFT: yarrow init() random: selecting highest priority adaptor ACPI BIOS Error (bug): A valid RSDP was not found (20140926/tbxfroot-260) ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. vtvga0: on motherboard sysctl machdep.i8254_freq=1189161 returns 0 Timecounter "ELAN" frequency 8192000 Hz quality 1000 pcib0 pcibus 0 on motherboard pci0: on pcib0 sis0: port 0xe000-0xe0ff mem 0xa0000000-0xa0000fff irq 10 at device 18.0 on pci0 sis0: Silicon Revision: DP83816A miibus0: on sis0 nsphyter0: PHY 0 on miibus0 nsphyter0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:00:24:c8:d4:d4 sis1: port 0xe100-0xe1ff mem 0xa0001000-0xa0001fff irq 11 at device 19.0 on pci0 sis1: Silicon Revision: DP83816A miibus1: on sis1 nsphyter1: PHY 0 on miibus1 nsphyter1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis1: Ethernet address: 00:00:24:c8:d4:d5 sis2: port 0xe200-0xe2ff mem 0xa0002000-0xa0002fff irq 5 at device 20.0 on pci0 sis2: Silicon Revision: DP83816A miibus2: on sis2 nsphyter2: PHY 0 on miibus2 nsphyter2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis2: Ethernet address: 00:00:24:c8:d4:d6 cpu0 on motherboard isa0: on motherboard pmtimer0 on isa0 orm0: at iomem 0xc8000-0xd0fff pnpid ORM0000 on isa0 ata0: at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1: at port 0x170-0x177,0x376 irq 15 on isa0 atrtc0: at port 0x70 irq 8 on isa0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: at port 0x40 on isa0 Timecounter "i8254" frequency 1189161 Hz quality 0 Event timer "i8254" frequency 1189161 Hz quality 100 ppc0: parallel port not found. uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 Timecounters tick every 1.000 msec interrupt storm detected on "irq5:"; throttling interrupt source Elan-mmcr driver: MMCR at 0xc2f2e000. PPS support. Elan-mmcr Soekris net45xx comBIOS ver. 1.33 20080103 Copyright (C) 2000-2007 ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: CFA-0 device ada0: Serial Number AJZ061813191928 ada0: 16.700MB/s transfers (PIO4, PIO 512bytes) ada0: 15259MB (31250432 512 byte sectors: 16H 63S/T 31002C) ada0: Previously was known as ad0 interrupt storm detected on "irq5:"; throttling interrupt source random: unblocking device. WARNING: WITNESS option enabled, expect reduced performance. interrupt storm detected on "irq5:"; throttling interrupt source interrupt storm detected on "irq5:"; throttling interrupt source Trying to mount root from ufs:/dev/ada0s1a [rw,noatime]... WARNING: / was not properly dismounted interrupt storm detected on "irq5:"; throttling interrupt source interrupt storm detected on "irq5:"; throttling interrupt source interrupt storm detected on "irq5:"; throttling interrupt source interrupt storm detected on "irq5:"; throttling interrupt source interrupt storm detected on "irq5:"; throttling interrupt source interrupt storm detected on "irq5:"; throttling interrupt source interrupt storm detected on "irq5:"; throttling interrupt source interrupt storm detected on "irq5:"; throttling interrupt source -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Mon Jan 12 02:49:03 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37876522 for ; Mon, 12 Jan 2015 02:49:03 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0D4B729F for ; Mon, 12 Jan 2015 02:49:02 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1YAV3r-000AHz-S7; Mon, 12 Jan 2015 02:49:00 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t0C2mvQt045370; Sun, 11 Jan 2015 19:48:58 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/Ccs6mzG6oMqfURg759o4D Message-ID: <1421030937.14601.153.camel@freebsd.org> Subject: Re: read(2) into some addresses doesn't return data on RPi From: Ian Lepore To: Peter Jeremy Date: Sun, 11 Jan 2015 19:48:57 -0700 In-Reply-To: <20150110060412.GE77914@server.rulingia.com> References: <20150110060412.GE77914@server.rulingia.com> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 02:49:03 -0000 On Sat, 2015-01-10 at 17:04 +1100, Peter Jeremy wrote: > Trying to access the boot partition using mtools consistently fails on my > RPi because the kernel is returning NULs for the first sector. The second > sector is correct. If I use dd(2) then the expected data is returned. > > This is running 11-current r276818 (but ISTR seeing it on older kernels). > > I did some digging and found that read(2)s of the SD card device return > successful but do not actually write anything to the buffer for some > addresses (and they happen to contain all NULs in mtools). This doesn't > appear to affect reads of normal files. > > Running the attached program on /dev/mmcsd0s1 gave me the following results: > - There are no partial reads. Either all 512 bytes are updated or none are. > - There are two blocks of addresses 0xbfff0e00 thru 0xbfff0e00 and 0xbfff2e00 > thru 0xbfff2e00 where reads work on a 32-byte alignment but not otherwise. > - Reads consistently fail between 0xbfff1e08 and 0xbfff1ff8 > - Reads consistently fail between 0xbfff3e08 and 0xbfff3f?? (I got a hang). > - The program never completes. In 3 runs, I've gotten: > - panic: null_fetch_syscall_args > - kernel hang > - panic: malloc: bad malloc type magic > I don't have a serial console and so can't debug kernel panics. > > Putting that together, it seems to related to accesses that aren't cache-line > aligned and cross page boundaries but I'm not sure why it behaves differently > at different page boundaries. The hangs/panics suggest that it's writing to > random other kernel addresses instead. > > Does this ring a bell for anyone? > This turned out to be two problems, both fixed now as of r277038. The first problem was that the driver wasn't able to handle a dma that was split across two physically discontiguous pages, and when an IO isn't aligned to a cacheline the arm busdma logic that auto-bounces it inherently ends up setting up a split buffer. Since the dma tag required a single buffer, the mapping operation would fail with EFBIG. The second problem was that the rpi sdhci driver was completely ignoring the status of the busdma mapping calls, so after a failed mapping it would do the dma anyway, using who-knows-what for a dma address, leading to later panics or crashes due to corrupted memory. So first I made it handle errors better, then I made it able to handle an IO that crosses page boundaries. I couldn't have done any of it without that program that recreated the failure and confirmed the fix, thanks Peter! -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Jan 12 06:00:07 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4007A81E for ; Mon, 12 Jan 2015 06:00:07 +0000 (UTC) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 175F89A4 for ; Mon, 12 Jan 2015 06:00:07 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id va8so20873422obc.3 for ; Sun, 11 Jan 2015 22:00:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DiMSp9U7WuLahMjBZHRozBk0MMx8//FwSrmSBLTvDNA=; b=gEIp6bFbFrB2hMyeiOoSI4lT03SIvh+gjZ0TMKMQrSFeO3cv08uH3KfMUqdACrZNwO v/1TPxjvd3N3tYDzdoa76fC7335rY1K7QFMoDBRelGzEcPNouVv0l0qCj1FRy527ENdo m8WASnYN4hBPPgZNsi0d9Pcuzjr0gLYbixerSr1waKlr+L62RSbSd6++sqWLSul6+GjX aDD222vMrRLoWV/xw2Ip+6MIjU+rW9eGN+gdYFQOTeR5QXPtNzIFuU48tWWUnMoqutQR nFRCgCIE29Yiowd3AbQ9QKJuuDz3o8qP1ZvH86UC3+tKdHKROr2NgjDcUAb9QFS6fq5D WlZg== MIME-Version: 1.0 X-Received: by 10.202.75.202 with SMTP id y193mr3020929oia.12.1421042405454; Sun, 11 Jan 2015 22:00:05 -0800 (PST) Received: by 10.182.78.231 with HTTP; Sun, 11 Jan 2015 22:00:05 -0800 (PST) Date: Mon, 12 Jan 2015 14:00:05 +0800 Message-ID: Subject: booting on RK3288 board From: Ganbold Tsagaankhuu To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 06:00:07 -0000 Hi, Just wanted to share boot success on T-Firefly board ( http://www.t-firefly.com/en/): https://github.com/tsgan/rockchip/blob/master/RK3288/rk3288-dmesg-multi-user.txt It has Rockchip RK3288 SoC (quad core Cortex A17), unfortunately there is down side, no public Doc/TRM released yet. The basic support codes need to be polished. Ganbold From owner-freebsd-arm@FreeBSD.ORG Mon Jan 12 16:52:55 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47B90126 for ; Mon, 12 Jan 2015 16:52:55 +0000 (UTC) Received: from mail-yk0-f180.google.com (mail-yk0-f180.google.com [209.85.160.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 003A3858 for ; Mon, 12 Jan 2015 16:52:54 +0000 (UTC) Received: by mail-yk0-f180.google.com with SMTP id 9so9669116ykp.11 for ; Mon, 12 Jan 2015 08:52:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=FR3uJjPgoVDwEXh5H95n5t5dG8bkIjCE44VAunqUtqE=; b=eAPLMGwLZlZ20mGXxQg8XvJVumgdBRpAd6jQNusVo1gCDQXkupbVv3obrAUj28Na96 5a2JIsnnC59VZqP9R1ugDR8CIvujfSSc5arIM2wT9MTUb6vNpMSLjaSObpxPp6DU80b+ NfW7gxAUvJLmIhRBZVj3NNG+JWqaWyy8Na9uVkV2FfCw37PkT37muVWX7J2fZgN4umjP uwyywrjAcFDoxeGLS4lRaPhdFMVmcdqM/JuOJF4ZFZUxOghXRoTK2inGcx3ubYysRyZd 6gLAhJejnDmeHaQlGHswLBktrgobW6CajcMNBE8ZqJrJOK8/sQPubT+qGiA0wCeB9tMN rlMA== X-Gm-Message-State: ALoCoQmK7RyNN4z5UPsOQIQJ5kv7cku/UDm82reMkANgnOm5WZ3BZI4oadCu3fO/slY74CsWJFST X-Received: by 10.236.32.129 with SMTP id o1mr23088627yha.196.1421081568266; Mon, 12 Jan 2015 08:52:48 -0800 (PST) Received: from [10.64.26.9] ([69.53.236.236]) by mx.google.com with ESMTPSA id i27sm10892054yha.1.2015.01.12.08.52.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Jan 2015 08:52:47 -0800 (PST) Sender: Warner Losh Subject: Re: Issue with arm cross compiler xdev on FreeBSD 10.1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_52DB5EEE-8BFE-4B69-AC59-CED4FF62F317"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: Date: Mon, 12 Jan 2015 09:52:44 -0700 Message-Id: References: To: Kai Noetzel X-Mailer: Apple Mail (2.1993) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 16:52:55 -0000 --Apple-Mail=_52DB5EEE-8BFE-4B69-AC59-CED4FF62F317 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think there=E2=80=99s an issue with head. I keep running into the = acle-compat.h issue but when I look for it I can=E2=80=99t reproduce it. Warner > On Jan 10, 2015, at 1:42 AM, Kai Noetzel = wrote: >=20 > I retried to build the arm cross compiler with the sources of 10.1. It = took > a while but the following worked: >=20 > svn co http://svn.freebsd.org/base/release/10.1.0/ /usr/src2 > make XDEV=3Darm XDEV_ARCH=3Darmv6 WITH_GCC=3D1 xdev >=20 > .... > sh /usr/src2/tools/install.sh -C -o root -g wheel -m 444 libln.a > //usr/armv6-freebsd/usr/lib > //usr/armv6-freebsd/usr/lib/libl.a -> = //usr/armv6-freebsd/usr/lib/libln.a > //usr/armv6-freebsd/usr/lib/libfl.a -> = //usr/armv6-freebsd/usr/lib/libln.a > cd //usr/armv6-freebsd/usr/bin; mkdir -p ../../../../usr/bin; for i = in *; > do ln -sf ../..//usr/armv6-freebsd/usr/bin/$i > ../../../../usr/bin/armv6-freebsd-$i; ln -sf > ../..//usr/armv6-freebsd/usr/bin/$i > ../../../../usr/bin/armv6-freebsd10.1-$i; done >=20 > Is there an issue with head or am I doing something wrong? >=20 >=20 > On Fri, Jan 9, 2015 at 11:52 PM, Kai Noetzel = wrote: >=20 >> Hi Warner, >>=20 >> I tried to issue your command and it ran for quite a while but = stopped >> finally with the following error: >>=20 >> cc -c -O -pipe -DTARGET_ARM_EABI -DIN_GCC -DIN_LIBGCC2 >> -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT >> -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include >> -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config >> -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. >> -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -Dinhibit_libc >> -fno-inline -std=3Dgnu99 -fheinous-gnu-extensions = -Qunused-arguments >> -fvisibility=3Dhidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3D3= >> -DElfW=3D__ElfN -o libunwind.o >> /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/arm/libunwind.S >> = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/arm/libunwind.S:29:10:= >> fatal error: 'machine/acle-compat.h' file not found >> #include >> ^ >> 1 error generated. >> *** Error code 1 >>=20 >> Stop. >> make[4]: stopped in /usr/src/gnu/lib/libgcc >> *** Error code 1 >>=20 >> Stop. >> make[3]: stopped in /usr/src >> *** Error code 1 >>=20 >> Stop. >> make[2]: stopped in /usr/src >> *** Error code 1 >>=20 >> Stop. >> make[1]: stopped in /usr/src >> *** Error code 1 >>=20 >> Stop. >> make: stopped in /usr/src >>=20 >> On Fri, Jan 9, 2015 at 11:30 PM, Warner Losh wrote: >>=20 >>> Let=E2=80=99s get back to basics=E2=80=A6 >>>=20 >>> can you do the following? >>>=20 >>> make buildworld TARGET_ARCH=3Darmv6 WITHOUT_CLANG=3Dt >>> WITHOUT_CLANG_BOOTSTRAP=3Dt WITH_GCC=3Dt WITH_GCC_BOOTSTRAP=3Dt >>>=20 >>> ???? >>>=20 >>> Warner >>>=20 >>>=20 >>>=20 >>>> On Jan 9, 2015, at 3:26 PM, Kai Noetzel = wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> I'm having issues trying to build the arm cross compiler on the >>> following >>>> system: >>>>=20 >>>> root@bsdcompy:/usr/src # uname -a >>>> FreeBSD bsdcompy 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue = Nov >>> 11 >>>> 21:02:49 UTC 2014 >>>> root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC >>>> amd64 >>>>=20 >>>> I checked out: >>>>=20 >>>> svn co http://svn.freebsd.org/base/head /usr/src >>>>=20 >>>> When I run: >>>>=20 >>>> root@bsdcompy:/usr/src # make XDEV=3Darm XDEV_ARCH=3Darmv6 = WITH_GCC=3D1 xdev >>>>=20 >>>> I get the following error: >>>>=20 >>>> ...... >>>> =3D=3D=3D> xdev lib/libelftc (obj,depend,all) >>>> =3D=3D=3D> xdev usr.bin/addr2line (obj,depend,all) >>>> cc -O2 -pipe >>>> -I/usr/src/usr.bin/addr2line/../../contrib/elftoolchain/libelftc >>>> -I/usr/src/usr.bin/addr2line/../../contrib/elftoolchain/common >>> -std=3Dgnu99 >>>> -fstack-protector -Qunused-arguments -c >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:105:39: >>>> error: passing 'Dwarf_Error' (aka 'struct _Dwarf_Error') to = parameter of >>>> incompatible type 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); = take >>> the >>>> address >>>> with & >>>> warnx("dwarf_tag: %s", dwarf_errmsg(de)); >>>> ^~ >>>> & >>>> /usr/include/libdwarf.h:122:39: note: passing argument to parameter = here >>>> const char *dwarf_errmsg(Dwarf_Error *); >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:119:14: >>>> error: use of undeclared identifier 'DW_DLV_ERROR' >>>> if (ret =3D=3D DW_DLV_ERROR) >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:122:8: >>>> warning: implicit declaration of function 'dwarf_formstring' is = invalid >>> in >>>> C99 [-Wimplicit-function-declaration] >>>> if (dwarf_formstring(sub_at, &func0, &de)) >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:136:7: >>>> warning: implicit declaration of function 'dwarf_global_formref' is >>> invalid >>>> in C99 [-Wimplicit-function-declaration] >>>> if (dwarf_global_formref(spec_at, &ref, &de)) >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:138:7: >>>> warning: implicit declaration of function 'dwarf_offdie' is invalid = in >>> C99 >>>> [-Wimplicit-function-declaration] >>>> if (dwarf_offdie(dbg, ref, &spec_die, &de)) >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:150:13: >>>> error: use of undeclared identifier 'DW_DLV_ERROR' >>>> if (ret =3D=3D DW_DLV_ERROR) >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:151:54: >>>> error: passing 'Dwarf_Error' (aka 'struct _Dwarf_Error') to = parameter of >>>> incompatible type 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); = take >>> the >>>> address >>>> with & >>>> errx(EXIT_FAILURE, "dwarf_child: %s", = dwarf_errmsg(de)); >>>> ^~ >>>> & >>>> /usr/include/libdwarf.h:122:39: note: passing argument to parameter = here >>>> const char *dwarf_errmsg(Dwarf_Error *); >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:157:13: >>>> error: use of undeclared identifier 'DW_DLV_ERROR' >>>> if (ret =3D=3D DW_DLV_ERROR) >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:158:58: >>>> error: passing 'Dwarf_Error' (aka 'struct _Dwarf_Error') to = parameter of >>>> incompatible type 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); = take >>> the >>>> address >>>> with & >>>> errx(EXIT_FAILURE, "dwarf_siblingof: %s", >>> dwarf_errmsg(de)); >>>> = ^~ >>>> = & >>>> /usr/include/libdwarf.h:122:39: note: passing argument to parameter = here >>>> const char *dwarf_errmsg(Dwarf_Error *); >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:189:22: >>>> error: passing 'Dwarf_Error' (aka 'struct _Dwarf_Error') to = parameter of >>>> incompatible type 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); = take >>> the >>>> address >>>> with & >>>> dwarf_errmsg(de)); >>>> ^~ >>>> & >>>> /usr/include/libdwarf.h:122:39: note: passing argument to parameter = here >>>> const char *dwarf_errmsg(Dwarf_Error *); >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:210:7: >>>> warning: implicit declaration of function 'dwarf_srclines' is = invalid in >>>> C99 [-Wimplicit-function-declaration] >>>> if (dwarf_srclines(die, &lbuf, &lcount, &de) !=3D >>> DW_DLV_OK) { >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:211:45: >>>> error: passing 'Dwarf_Error' (aka 'struct _Dwarf_Error') to = parameter of >>>> incompatible type 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); = take >>> the >>>> address >>>> with & >>>> warnx("dwarf_srclines: %s", = dwarf_errmsg(de)); >>>> ^~ >>>> & >>>> /usr/include/libdwarf.h:122:39: note: passing argument to parameter = here >>>> const char *dwarf_errmsg(Dwarf_Error *); >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:219:8: >>>> warning: implicit declaration of function 'dwarf_lineaddr' is = invalid in >>>> C99 [-Wimplicit-function-declaration] >>>> if (dwarf_lineaddr(lbuf[i], &lineaddr, &de)) = { >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:221:22: >>>> error: passing 'Dwarf_Error' (aka 'struct _Dwarf_Error') to = parameter of >>>> incompatible type 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); = take >>> the >>>> address >>>> with & >>>> dwarf_errmsg(de)); >>>> ^~ >>>> & >>>> /usr/include/libdwarf.h:122:39: note: passing argument to parameter = here >>>> const char *dwarf_errmsg(Dwarf_Error *); >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:224:8: >>>> warning: implicit declaration of function 'dwarf_lineno' is invalid = in >>> C99 >>>> [-Wimplicit-function-declaration] >>>> if (dwarf_lineno(lbuf[i], &lineno, &de)) { >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:226:22: >>>> error: passing 'Dwarf_Error' (aka 'struct _Dwarf_Error') to = parameter of >>>> incompatible type 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); = take >>> the >>>> address >>>> with & >>>> dwarf_errmsg(de)); >>>> ^~ >>>> & >>>> /usr/include/libdwarf.h:122:39: note: passing argument to parameter = here >>>> const char *dwarf_errmsg(Dwarf_Error *); >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:229:8: >>>> warning: implicit declaration of function 'dwarf_linesrc' is = invalid in >>> C99 >>>> [-Wimplicit-function-declaration] >>>> if (dwarf_linesrc(lbuf[i], &file0, &de)) { >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:231:22: >>>> error: passing 'Dwarf_Error' (aka 'struct _Dwarf_Error') to = parameter of >>>> incompatible type 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); = take >>> the >>>> address >>>> with & >>>> dwarf_errmsg(de)); >>>> ^~ >>>> & >>>> /usr/include/libdwarf.h:122:39: note: passing argument to parameter = here >>>> const char *dwarf_errmsg(Dwarf_Error *); >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:269:14: >>>> error: use of undeclared identifier 'DW_DLV_ERROR' >>>> if (ret =3D=3D DW_DLV_ERROR) >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:271:21: >>>> error: passing 'Dwarf_Error' (aka 'struct _Dwarf_Error') to = parameter of >>>> incompatible type 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); = take >>> the >>>> address >>>> with & >>>> dwarf_errmsg(de)); >>>> ^~ >>>> & >>>> /usr/include/libdwarf.h:122:39: note: passing argument to parameter = here >>>> const char *dwarf_errmsg(Dwarf_Error *); >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:387:46: >>>> error: too many arguments to function call, expected 4, have 6 >>>> if (dwarf_init(fd, DW_DLC_READ, NULL, NULL, &dbg, &de)) >>>> ~~~~~~~~~~ ^~~~~~~~~ >>>> /usr/include/libdwarf.h:144:1: note: 'dwarf_init' declared here >>>> int dwarf_init(int, int, Dwarf_Debug *, Dwarf_Error *); >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:388:53: >>>> error: passing 'Dwarf_Error' (aka 'struct _Dwarf_Error') to = parameter of >>>> incompatible type 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); = take >>> the >>>> address >>>> with & >>>> errx(EXIT_FAILURE, "dwarf_init: %s", = dwarf_errmsg(de)); >>>> ^~ >>>> & >>>> /usr/include/libdwarf.h:122:39: note: passing argument to parameter = here >>>> const char *dwarf_errmsg(Dwarf_Error *); >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:390:6: >>>> warning: implicit declaration of function 'dwarf_get_elf' is = invalid in >>> C99 >>>> [-Wimplicit-function-declaration] >>>> if (dwarf_get_elf(dbg, &e, &de) !=3D DW_DLV_OK) >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:391:56: >>>> error: passing 'Dwarf_Error' (aka 'struct _Dwarf_Error') to = parameter of >>>> incompatible type 'Dwarf_Error *' (aka 'struct _Dwarf_Error *'); = take >>> the >>>> address >>>> with & >>>> errx(EXIT_FAILURE, "dwarf_get_elf: %s", >>> dwarf_errmsg(de)); >>>> = ^~ >>>> = & >>>> /usr/include/libdwarf.h:122:39: note: passing argument to parameter = here >>>> const char *dwarf_errmsg(Dwarf_Error *); >>>> ^ >>>>=20 >>> = /usr/src/usr.bin/addr2line/../../contrib/elftoolchain/addr2line/addr2line.= c:407:15: >>>> warning: incompatible pointer types passing 'Dwarf_Debug' (aka = 'struct >>>> _Dwarf_Debug *') to parameter of type 'Dwarf_Debug *' >>>> (aka 'struct _Dwarf_Debug **'); take the address with & >>>> [-Wincompatible-pointer-types] >>>> dwarf_finish(dbg, &de); >>>> ^~~ >>>> & >>>> /usr/include/libdwarf.h:141:32: note: passing argument to parameter = here >>>> int dwarf_finish(Dwarf_Debug *, Dwarf_Error *); >>>> ^ >>>> 9 warnings and 16 errors generated. >>>> *** Error code 1 >>>>=20 >>>> Stop. >>>> make[2]: stopped in /usr/src/usr.bin/addr2line >>>> *** Error code 1 >>>>=20 >>>> Stop. >>>> make[1]: stopped in /usr/src >>>> *** Error code 1 >>>>=20 >>>> Stop. >>>> make: stopped in /usr/src >>>>=20 >>>> Would be great if someone could take a look. >>>> Thanks in advance. >>>>=20 >>>> Best, >>>> Kai >>>> _______________________________________________ >>>> freebsd-arm@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >>>=20 >>>=20 >>=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --Apple-Mail=_52DB5EEE-8BFE-4B69-AC59-CED4FF62F317 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUs/vdAAoJEGwc0Sh9sBEAK0IP/0UtE2pVLw7DiFO4o3oDsDkW Aqb76H3FuHdzj4jJnjx3MyPDxjCvK14bO/1gqdMBy+OUE75n+cDo6YmTAzFhlgwD b8OStbD1iALyB1l05krbui5uGc6kbbSfT+JpBRb3DEWRZ37YQw7j+u8hWWxBTQoH wS2WDEXR1/giUXR7qE/fq7YVlDNy6VmWDkwJwk3vMg2SYc7OKTyaZSOMCoc7q4oG ALBD+p4ZB/n/nyVdr2GpUIY24/BxighpO7B3C9pZrG2rAGWXByAOCDJ5NSA+93tS mMMzKNigmj8/+BYWoEXpc+EpDb4IQaAtegE/c8WhkESPW0Y8RZHHF/aaeBxsRw8X sQ8iF5lynDYZ1XBRxn3U9o6O12EFFXTgWdh3ppHyJb8gPbOddVQekoJgM/HOu/fy vLnbkObwkdff20bWe3uSxLi9gNv2ZjzF7dTIqC4FyV7ZOo/8KSBDgyak/GC9ypcs RjlMUm58hEziE4P3s/h5WZG0QRun+8g6ghGBhMAC7aMUB3Y3CYAPu99dwJ7PqIYn 1PO3vQ9h2hexAep1vQMWHbJ4Uvsfgo95X7reOKgMY1LEpQz4Poc1IOIqkEZ8nO5K +kNZYOY2TL0hFvIa+itVSMjLkkNWDb+M8D/XTIyr3XL4qMnNs8SMDa89gpcTQBhs E2uFJQJOppVFSiPDyPnR =Stn0 -----END PGP SIGNATURE----- --Apple-Mail=_52DB5EEE-8BFE-4B69-AC59-CED4FF62F317-- From owner-freebsd-arm@FreeBSD.ORG Mon Jan 12 18:54:25 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5337F7C9; Mon, 12 Jan 2015 18:54:25 +0000 (UTC) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps.rulingia.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DE36BAAA; Mon, 12 Jan 2015 18:54:23 +0000 (UTC) Received: from server.rulingia.com (c220-239-242-83.belrs5.nsw.optusnet.com.au [220.239.242.83]) by vps.rulingia.com (8.14.9/8.14.9) with ESMTP id t0CIrnNj065383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 13 Jan 2015 05:53:54 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.9/8.14.9) with ESMTP id t0CIrh5Q076278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Jan 2015 05:53:43 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.9/8.14.9/Submit) id t0CIrhig076277; Tue, 13 Jan 2015 05:53:43 +1100 (AEDT) (envelope-from peter) Date: Tue, 13 Jan 2015 05:53:43 +1100 From: Peter Jeremy To: Ian Lepore Subject: Re: read(2) into some addresses doesn't return data on RPi Message-ID: <20150112185343.GA80289@server.rulingia.com> References: <20150110060412.GE77914@server.rulingia.com> <1421030937.14601.153.camel@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <1421030937.14601.153.camel@freebsd.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 18:54:25 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2015-Jan-11 19:48:57 -0700, Ian Lepore wrote: >On Sat, 2015-01-10 at 17:04 +1100, Peter Jeremy wrote: >> Trying to access the boot partition using mtools consistently fails on my >> RPi because the kernel is returning NULs for the first sector. The seco= nd >> sector is correct. If I use dd(2) then the expected data is returned. =2E.. >This turned out to be two problems, both fixed now as of r277038. Thank you for that. --=20 Peter Jeremy --SUOF0GtieIMvvwua Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUtBg3XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0nsIP/3YttMjkoEX+7MGpEQiUMkln RqFl9ZxGet0322DgG/93pRShO28ch3BNDAUukSr5E/wlQZWjTcPU1ZiN0pveTtBw inmH8T0YKGLXfprJgMaiXZZC6hSKisWrIGcV8R2HBlDCuEU0pq223lLuKksb15Y6 rp9lB5naAg+L4GG4ffs6jky4yR1BlMBKEHQqb21nWFlMufc0qs9hYsm+Puzx527C 17RR3XCTTGxnoaIxnOGCZ1E4FXWjFlaOk8DSgYemGVkXlAmRfmr+VfjEcTU3XHKI 3gq4bNdKK1AiiuNyuOp7zufrpXkYgzs8QXCaTqJs1DAMamfBF1thdaP9r1ZzkhOw 2Vsh/u1DUNSCliCJk8FLi7+6REmh7gP3+5lKp/4Cl7OYSx6oDjg9cSRETbMYrqxe KAv8klmM/ZqXdGoAr760K3uGeeio7CTzRB4pfkSy/UHhaOe7rOuibUCE8dVNR8pF OCesKa0k25+HIO0cEO3UzeC826DoSZmWiHG4T+2GF6cXaHpDIlJauiwkpsonI8YT I8dcFNk+Qiycx9M9UFkON8OG6fx+/FF/ct7PolA9Npd6avU/vYqrNIRoTI443v+N csSljvomu1rwuM2fceInUJ9PFjVAMWUJqZvmcCSZET648EAhJppqrvMWffRXDC4T Xiu1ltFZZqR/DVCSvqhU =40hK -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From owner-freebsd-arm@FreeBSD.ORG Mon Jan 12 20:42:24 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B33AEC59 for ; Mon, 12 Jan 2015 20:42:24 +0000 (UTC) Received: from bsdpad.com (xc1.bsdpad.com [195.154.136.64]) (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 79602AE3 for ; Mon, 12 Jan 2015 20:42:23 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bsdpad.com) by bsdpad.com with smtp (Exim 4.83 (FreeBSD)) (envelope-from ) id 1YAlkr-000IjE-TB; Mon, 12 Jan 2015 20:38:30 +0000 Received: by bsdpad.com (nbSMTP-1.00) for uid 1001 br@bsdpad.com; Mon, 12 Jan 2015 20:38:29 +0000 (GMT) Date: Mon, 12 Jan 2015 20:38:29 +0000 From: Ruslan Bukin To: Ganbold Tsagaankhuu Subject: Re: booting on RK3288 board Message-ID: <20150112203829.GA71938@bsdpad.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 20:42:24 -0000 Cool. Any luck with dwc(4) driver to run on rockchip? Ruslan On Mon, Jan 12, 2015 at 02:00:05PM +0800, Ganbold Tsagaankhuu wrote: > Hi, > > Just wanted to share boot success on T-Firefly board ( > http://www.t-firefly.com/en/): > > https://github.com/tsgan/rockchip/blob/master/RK3288/rk3288-dmesg-multi-user.txt > > It has Rockchip RK3288 SoC (quad core Cortex A17), unfortunately there is > down side, no public Doc/TRM released yet. > > The basic support codes need to be polished. > > Ganbold > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Mon Jan 12 21:24:05 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F08C9B70 for ; Mon, 12 Jan 2015 21:24:04 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D22DAF21 for ; Mon, 12 Jan 2015 21:24:04 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0CLO4tl082522 for ; Mon, 12 Jan 2015 21:24:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196660] [arm] multimedia/gstreamer1-libav fails to compile Date: Mon, 12 Jan 2015 21:24:04 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Ports Framework X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 21:24:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196660 Bug ID: 196660 Summary: [arm] multimedia/gstreamer1-libav fails to compile Product: Ports & Packages Version: Latest Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Ports Framework Assignee: freebsd-ports-bugs@FreeBSD.org Reporter: sbruno@FreeBSD.org CC: freebsd-arm@FreeBSD.org, portmgr@FreeBSD.org libavcodec/aacsbr.c:389:16: warning: variable 'max_qmf_subbands' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] } else if (sbr->sample_rate >= 48000) ^~~~~~~~~~~~~~~~~~~~~~~~~ libavcodec/aacsbr.c:392:33: note: uninitialized use occurs here if (sbr->k[2] - sbr->k[0] > max_qmf_subbands) { ^~~~~~~~~~~~~~~~ libavcodec/aacsbr.c:389:12: note: remove the 'if' if its condition is always true } else if (sbr->sample_rate >= 48000) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libavcodec/aacsbr.c:324:40: note: initialize the variable 'max_qmf_subbands' to silence this warning unsigned int temp, max_qmf_subbands; ^ = 0 CC libavcodec/ac3dec_data.o CC libavcodec/ac3dsp.o CC libavcodec/ac3enc.o CC libavcodec/ac3enc_fixed.o CC libavcodec/ac3enc_float.o CC libavcodec/ac3tab.o CC libavcodec/acelp_filters.o CC libavcodec/acelp_pitch_delay.o CC libavcodec/acelp_vectors.o CC libavcodec/adpcm.o CC libavcodec/adpcm_data.o CC libavcodec/adpcmenc.o CC libavcodec/adx.o CC libavcodec/adxdec.o CC libavcodec/adx_parser.o CC libavcodec/adxenc.o CC libavcodec/aic.o CC libavcodec/alac.o CC libavcodec/alac_data.o CC libavcodec/alacenc.o CC libavcodec/allcodecs.o CC libavcodec/alsdec.o CC libavcodec/amrnbdec.o CC libavcodec/amrwbdec.o CC libavcodec/anm.o 1 warning generated. CC libavcodec/ansi.o CC libavcodec/apedec.o CC libavcodec/arm/aacpsdsp_init_arm.o AS libavcodec/arm/ac3dsp_arm.o AS libavcodec/arm/ac3dsp_armv6.o :19:9: error: unknown directive ldr gp, .Lpicoff\@ ^ :7:9: note: while in macro instantiation ldpic gp, _GLOBAL_OFFSET_TABLE_ ^ libavcodec/arm/ac3dsp_armv6.S:29:9: note: while in macro instantiation movrelx r4, ff_ac3_bin_to_band_tab, r11 ^ :2:1: error: unknown directive .Lpic\@: ^ :7:9: note: while in macro instantiation ldpic gp, _GLOBAL_OFFSET_TABLE_ ^ libavcodec/arm/ac3dsp_armv6.S:29:9: note: while in macro instantiation movrelx r4, ff_ac3_bin_to_band_tab, r11 ^ :10:48: error: unbalanced parentheses in macro argument def_pic _GLOBAL_OFFSET_TABLE_ - (.Lpic\@ + (8 >> 0)), .Lpicoff\@ ^ :7:9: note: while in macro instantiation ldpic gp, _GLOBAL_OFFSET_TABLE_ ^ libavcodec/arm/ac3dsp_armv6.S:29:9: note: while in macro instantiation movrelx r4, ff_ac3_bin_to_band_tab, r11 ^ :13:25: error: unexpected token in argument list ldr r4, .Lpicoff\@ ^ libavcodec/arm/ac3dsp_armv6.S:29:9: note: while in macro instantiation movrelx r4, ff_ac3_bin_to_band_tab, r11 ^ :1:1: error: unknown directive .altmacro ^ :15:9: note: while in macro instantiation def_pic ff_ac3_bin_to_band_tab(GOT), .Lpicoff\@ ^ libavcodec/arm/ac3dsp_armv6.S:29:9: note: while in macro instantiation movrelx r4, ff_ac3_bin_to_band_tab, r11 ^ :1:16: error: expected identifier in '.macro' directive .macro put_pic_%.Lpic_idx ^ :2:9: note: while in macro instantiation do_def_pic %.Lpic_idx, ff_ac3_bin_to_band_tab(GOT), .Lpicoff\ ^ :15:9: note: while in macro instantiation def_pic ff_ac3_bin_to_band_tab(GOT), .Lpicoff\@ ^ libavcodec/arm/ac3dsp_armv6.S:29:9: note: while in macro instantiation movrelx r4, ff_ac3_bin_to_band_tabCC libavcodec/arm/ac3dsp_init_arm.o , r11 ^ :2:11: error: unknown token in expression .if %.Lpic_idx ^ :2:9: note: while in macro instantiation do_def_pic %.Lpic_idx, ff_ac3_bin_to_band_tab(GOT), .Lpicoff\ ^ :15:9: note: while in macro instantiation def_pic ff_ac3_bin_to_band_tab(GOT), .Lpicoff\@ ^ libavcodec/arm/ac3dsp_armv6.S:29:9: note: while in macro instantiation movrelx r4, ff_ac3_bin_to_band_tab, r11 ^ :3:9: error: unknown directive .altmacro ^ :2:9: note: while in macro instantiation do_def_pic %.Lpic_idx, ff_ac3_bin_to_band_tab(GOT), .Lpicoff\ ^ :15:9: note: while in macro instantiation def_pic ff_ac3_bin_to_band_tab(GOT), .Lpicoff\@ ^ libavcodec/arm/ac3dsp_armv6.S:29:9: note: while in macro instantiation movrelx r4, ff_ac3_bin_to_band_tab, r11 ^ :1:9: error: unexpected token in operand put_pic_%(%.Lpic_idx-1) ^ :4:9: note: while in macro instantiation put_pic %(%.Lpic_idx - 1) ^ :2:9: note: while in macro instantiation do_def_pic %.Lpic_idx, ff_ac3_bin_to_band_tab(GOT), .Lpicoff\ ^ :15:9: note: while in macro instantiation def_pic ff_ac3_bin_to_band_tab(GOT), .Lpicoff\@ ^ libavcodec/arm/ac3dsp_armv6.S:29:9: note: while in macro instantiation movrelx r4, ff_ac3_bin_to_band_tab, r11 ^ :5:9: error: unknown directive .noaltmacro ^ :2:9: note: while in macro instantiation do_def_pic %.Lpic_idx, ff_ac3_bin_to_band_tab(GOT), .Lpicoff\ ^ :15:9: note: while in macro instantiation def_pic ff_ac3_bin_to_band_tab(GOT), .Lpicoff\@ ^ libavcodec/arm/ac3dsp_armv6.S:29:9: note: while in macro instantiation movrelx r4, ff_ac3_bin_to_band_tab, r11 ^ :7:1: error: unknown directive .Lpicoff\: .word ff_ac3_bin_to_band_tab(GOT) ^ :2:9: note: while in macro instantiation do_def_pic %.Lpic_idx, ff_ac3_bin_to_band_tab(GOT), .Lpicoff\ Makefile:47: recipe for target 'libavcodec/arm/ac3dsp_arm.o' failed ^ :15:9: note: while in macro instantiation def_pic ff_ac3_bin_to_band_tab(GOT), .Lpicoff\@ ^ libavcodec/arm/ac3dsp_armv6.S:29:9: note: while in macro instantiation movrelx r4, ff_ac3_bin_to_band_tab, r11 ^ :8:25: error: unexpected token in '.purgem' directive .purgem put_pic_%.Lpic_idx ^ :2:9: note: while in macro instantiation do_def_pic %.Lpic_idx, ff_ac3_bin_to_band_tab(GOT), .Lpicoff\ ^ :15:9: note: while in macro instantiation def_pic ff_ac3_band_start_tab(GOT), .Lpicoff\@ ^ /tmp/ac3dsp_armv6-361f97.s:271:9: note: while in macro instantiation movrelx lr, ff_ac3_band_start_tab ^ :7:1: error: unknown directive .Lpicoff\: .word ff_ac3_band_start_tab(GOT) ^ :2:9: note: while in macro instantiation do_def_pic %.Lpic_idx, ff_ac3_band_start_tab(GOT), .Lpicoff\ ^ :15:9: note: while in macro instantiation def_pic ff_ac3_band_start_tab(GOT), .Lpicoff\@ ^ /tmp/ac3dsp_armv6-361f97.s:271:9: note: while in macro instantiation movrelx lr, ff_ac3_band_start_tab ^ :8:25: error: unexpected token in '.purgem' directive .purgem put_pic_%.Lpic_idx ^ :2:9: note: while in macro instantiation do_def_pic %.Lpic_idx, ff_ac3_band_start_tab(GOT), .Lpicoff\ ^ :15:9: note: while in macro instantiation def_pic ff_ac3_band_start_tab(GOT), .Lpicoff\@ ^ /tmp/ac3dsp_armv6-361f97.s:271:9: note: while in macro instantiation movrelx lr, ff_ac3_band_start_tab ^ :3:9: error: unknown directive .noaltmacro ^ :15:9: note: while in macro instantiation def_pic ff_ac3_band_start_tab(GOT), .Lpicoff\@ ^ /tmp/ac3dsp_armv6-361f97.s:271:9: note: while in macro instantiation movrelx lr, ff_ac3_band_start_tab ^ :3:9: error: unknown directive .altmacro ^ /tmp/ac3dsp_armv6-361f97.s:325:1: note: while in macro instantiation endfunc ^ :1:9: error: unexpected token in operand put_pic_%(.Lpic_idx-1) ^ :4:9: note: while in macro instantiation put_pic %(.Lpic_idx - 1) ^ /tmp/ac3dsp_armv6-361f97.s:325:1: note: while in macro instantiation endfunc ^ :5:9: error: unknown directive .noaltmacro ^ /tmp/ac3dsp_armv6-361f97.s:325:1: note: while in macro instantiation endfunc ^ :8:9: error: unknown directive .endfunc ^ /tmp/ac3dsp_armv6-361f97.s:325:1: note: while in macro instantiation endfunc ^ Makefile:47: recipe for target 'libavcodec/arm/ac3dsp_armv6.o' failed gmake[6]: *** [libavcodec/arm/ac3dsp_armv6.o] Error 1 1 warning generated. gmake[6]: Leaving directory '/wrkdirs/usr/ports/multimedia/gstreamer1-libav/work/gst-libav-1.4.5/gst-libs/ext/libav' Makefile:657: recipe for target 'all-local' failed gmake[5]: *** [all-local] Error 2 gmake[5]: Leaving directory '/wrkdirs/usr/ports/multimedia/gstreamer1-libav/work/gst-libav-1.4.5/gst-libs/ext' Makefile:451: recipe for target 'all-recursive' failed gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory '/wrkdirs/usr/ports/multimedia/gstreamer1-libav/work/gst-libav-1.4.5/gst-libs/ext' Makefile:437: recipe for target 'all-recursive' failed gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory '/wrkdirs/usr/ports/multimedia/gstreamer1-libav/work/gst-libav-1.4.5/gst-libs' Makefile:530: recipe for target 'all-recursive' failed gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory '/wrkdirs/usr/ports/multimedia/gstreamer1-libav/work/gst-libav-1.4.5' Makefile:458: recipe for target 'all' failed gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory '/wrkdirs/usr/ports/multimedia/gstreamer1-libav/work/gst-libav-1.4.5' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/multimedia/gstreamer1-libav -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Mon Jan 12 21:24:20 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BB0CBEE for ; Mon, 12 Jan 2015 21:24:20 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 82F72F24 for ; Mon, 12 Jan 2015 21:24:20 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0CLOK9S082609 for ; Mon, 12 Jan 2015 21:24:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196660] [arm] multimedia/gstreamer1-libav fails to compile Date: Mon, 12 Jan 2015 21:24:20 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Ports Framework X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_severity Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 21:24:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196660 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Affects Only Me |Affects Some People -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Mon Jan 12 21:29:35 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BEFEFC2 for ; Mon, 12 Jan 2015 21:29:35 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 83989F63 for ; Mon, 12 Jan 2015 21:29:35 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0CLTZ9A084567 for ; Mon, 12 Jan 2015 21:29:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196660] [arm] multimedia/gstreamer1-libav fails to compile Date: Mon, 12 Jan 2015 21:29:35 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Ports Framework X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 21:29:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196660 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dim@FreeBSD.org --- Comment #1 from Sean Bruno --- Not sure if this is fixable outside of using --no-integrated-as without reworking the asm. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue Jan 13 03:22:17 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E75E0EF9; Tue, 13 Jan 2015 03:22:16 +0000 (UTC) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A8E35A67; Tue, 13 Jan 2015 03:22:16 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id nt9so549773obb.10; Mon, 12 Jan 2015 19:22:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VmXqVyjvkLKq/DewbYx3uc06ZhnVp/Ne6MzturYnSHs=; b=TwZDMlNe+VBVC9OhT3p593rjwzlWdnHpvwqzGJEFn10LGWSNFCH76QIKr3pKNE8k2r RLRN19Hs0EzQRozEzBJh2IcAmjcHkb4EQu3LYTRLicNu/bdgIUaCpEvIe6rPHmlzC4Ae cuLVnz8B3iKTyh1Zecg/EGW7huT3gXc/+jP90vjBx9rtNpHjNtx+Y/r+Lrwn2vBpUzfI dIRkpv+1yYuQEqYIzChz0jFclVwFhca+sZhRklWjrBoE3UzZRW2DEJyTOJf51Ps/ldFq 1EwOVDCU18t5dar/6BuOuT5bhmUPk5k2nVAwi5VsIxkX6Z/Fwj0YY0qv4lBbhciC0f3d jmuA== MIME-Version: 1.0 X-Received: by 10.182.165.202 with SMTP id za10mr14321357obb.8.1421119335571; Mon, 12 Jan 2015 19:22:15 -0800 (PST) Received: by 10.182.78.231 with HTTP; Mon, 12 Jan 2015 19:22:15 -0800 (PST) In-Reply-To: <20150112203829.GA71938@bsdpad.com> References: <20150112203829.GA71938@bsdpad.com> Date: Tue, 13 Jan 2015 11:22:15 +0800 Message-ID: Subject: Re: booting on RK3288 board From: Ganbold Tsagaankhuu To: Ruslan Bukin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 03:22:17 -0000 On Tue, Jan 13, 2015 at 4:38 AM, Ruslan Bukin wrote: > Cool. Any luck with dwc(4) driver to run on rockchip? > Didn't try it yet, I will try when I get a chance. Ganbold > > Ruslan > > On Mon, Jan 12, 2015 at 02:00:05PM +0800, Ganbold Tsagaankhuu wrote: > > Hi, > > > > Just wanted to share boot success on T-Firefly board ( > > http://www.t-firefly.com/en/): > > > > > https://github.com/tsgan/rockchip/blob/master/RK3288/rk3288-dmesg-multi-user.txt > > > > It has Rockchip RK3288 SoC (quad core Cortex A17), unfortunately there is > > down side, no public Doc/TRM released yet. > > > > The basic support codes need to be polished. > > > > Ganbold > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > From owner-freebsd-arm@FreeBSD.ORG Tue Jan 13 10:45:32 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 845B3124 for ; Tue, 13 Jan 2015 10:45:32 +0000 (UTC) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46AF6A48 for ; Tue, 13 Jan 2015 10:45:32 +0000 (UTC) Received: by mail-oi0-f48.google.com with SMTP id u20so1715478oif.7 for ; Tue, 13 Jan 2015 02:45:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7fwzP3/koEU6z8C6UNrLCcgda07jvkugB3xxOKGZTvg=; b=sa3+Y5LEZqIJ9akmb2OYSmGRPSso0xnzsHn+6G+kp2z1rSzUTWimnyTw3gzkAxYhm+ dXOoq8tBq+s/d8iLlWwxh2IAouL5YWcC+xVISc/ztKS4PF2mpUAOjxTj6A2+4sDUCRUs 1eA4fr6gkQD29pVg7G2H35ucRxJIb/27azarcq1rQNZK1gO/DUu0gKdoYKQPN8XXOgTh emxNXtzZril8xGkd1u6AgwhpIztHGs1R5EjhR9dbeMJVVDuhUEVEMJ963XWJFU+jy+M9 BQn4VZogDPHrY759W+GGhTszAxfvGrOXQz/CvWuGG1t3ZAoPp3qL4AiUjrR96+BQJE2K NGvg== MIME-Version: 1.0 X-Received: by 10.60.161.105 with SMTP id xr9mr20295504oeb.1.1421145931709; Tue, 13 Jan 2015 02:45:31 -0800 (PST) Received: by 10.182.78.231 with HTTP; Tue, 13 Jan 2015 02:45:31 -0800 (PST) In-Reply-To: References: Date: Tue, 13 Jan 2015 18:45:31 +0800 Message-ID: Subject: Re: booting on RK3288 board From: Ganbold Tsagaankhuu To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 10:45:32 -0000 On Mon, Jan 12, 2015 at 2:00 PM, Ganbold Tsagaankhuu wrote: > Hi, > > Just wanted to share boot success on T-Firefly board ( > http://www.t-firefly.com/en/): > > > https://github.com/tsgan/rockchip/blob/master/RK3288/rk3288-dmesg-multi-user.txt > > It has Rockchip RK3288 SoC (quad core Cortex A17) > Replying to myself, actually it is A12. Ganbold > , unfortunately there is down side, no public Doc/TRM released yet. > > The basic support codes need to be polished. > > Ganbold > From owner-freebsd-arm@FreeBSD.ORG Tue Jan 13 11:19:17 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 128737D5 for ; Tue, 13 Jan 2015 11:19:17 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id E8F53D91 for ; Tue, 13 Jan 2015 11:19:16 +0000 (UTC) Received: from bender (97e078e7.skybroadband.com [151.224.120.231]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 87B9173000; Tue, 13 Jan 2015 11:19:15 +0000 (UTC) Date: Tue, 13 Jan 2015 11:19:08 +0000 From: Andrew Turner To: Ganbold Tsagaankhuu Subject: Re: booting on RK3288 board Message-ID: <20150113111908.060482ca@bender> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 11:19:17 -0000 On Tue, 13 Jan 2015 18:45:31 +0800 Ganbold Tsagaankhuu wrote: > On Mon, Jan 12, 2015 at 2:00 PM, Ganbold Tsagaankhuu > wrote: > > > Hi, > > > > Just wanted to share boot success on T-Firefly board ( > > http://www.t-firefly.com/en/): > > > > > > https://github.com/tsgan/rockchip/blob/master/RK3288/rk3288-dmesg-multi-user.txt > > > > It has Rockchip RK3288 SoC (quad core Cortex A17) > > > > > Replying to myself, actually it is A12. It looks like most sites saying it is a Cortex-A17 are wrong. We found this because the ID register was returning a different value to what is documented in the Cortex-A17 TRM. There doesn't appear to be a public TRM for the Cortex-A12, but the Linux source shows what Ganbold got was for the A12. As far as I know the main difference between the A12 and A17 is the latter is able to be part of a big little system. Andrew From owner-freebsd-arm@FreeBSD.ORG Wed Jan 14 16:09:56 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 133AE47D for ; Wed, 14 Jan 2015 16:09:56 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EEEB160E for ; Wed, 14 Jan 2015 16:09:55 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0EG9tMS047218 for ; Wed, 14 Jan 2015 16:09:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196660] [arm] multimedia/gstreamer1-libav fails to compile Date: Wed, 14 Jan 2015 16:09:55 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Ports Framework X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: mikael.urankar@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 16:09:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196660 mikael.urankar@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mikael.urankar@gmail.com --- Comment #2 from mikael.urankar@gmail.com --- Created attachment 151625 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=151625&action=edit disable clang integrated assembler clang integrated assembler does not support GNU AS assembler directives, libav authors suggest to use gas-preprocessor to feed clang (cf https://patches.libav.org/patch/50894/) I think the easiest solution is to disable clang integrated assembler (cf attached patch) -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Wed Jan 14 21:46:18 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67A244AD for ; Wed, 14 Jan 2015 21:46:18 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CF7FDF for ; Wed, 14 Jan 2015 21:46:18 +0000 (UTC) Received: from [192.168.1.200] (p508F28EF.dip0.t-ipconnect.de [80.143.40.239]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 8820F1C104357 for ; Wed, 14 Jan 2015 22:46:14 +0100 (CET) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Raspberry Pi stability improved Message-Id: Date: Wed, 14 Jan 2015 22:46:13 +0100 To: freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 21:46:18 -0000 Dear all, I just wanted you let you know that FreeBSD head on the Raspberry Pi is much more stable now. I've tested r277054 and was able to portsnap fetch and extract and build the ports for git/subversion/vim without any problems using a Raspberry Pi B with an SD card. It took a day or two... All tests I did before where less stable. Most of the times the machine crashed when doing the portsnap stuff. Best regards Michael From owner-freebsd-arm@FreeBSD.ORG Wed Jan 14 22:12:04 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82597195 for ; Wed, 14 Jan 2015 22:12:04 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6911C6E2 for ; Wed, 14 Jan 2015 22:12:04 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0EMC4Or083329 for ; Wed, 14 Jan 2015 22:12:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196660] [arm] multimedia/gstreamer1-libav fails to compile Date: Wed, 14 Jan 2015 22:12:04 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Ports Framework X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 22:12:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196660 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |maintainer-feedback? -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 15 01:11:20 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE7821DB for ; Thu, 15 Jan 2015 01:11:20 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D5774D15 for ; Thu, 15 Jan 2015 01:11:20 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0F1BKaE022231 for ; Thu, 15 Jan 2015 01:11:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196660] [arm] multimedia/gstreamer1-libav fails to compile Date: Thu, 15 Jan 2015 01:11:20 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: component Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 01:11:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196660 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Ports Framework |Individual Port(s) -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 15 13:51:19 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F235B2BF for ; Thu, 15 Jan 2015 13:51:18 +0000 (UTC) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 90D49648 for ; Thu, 15 Jan 2015 13:51:18 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id dc16so11057078qab.1 for ; Thu, 15 Jan 2015 05:51:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3PBA24Z1pDIZyQlMmqOjzMd75vya31dVmaP2xwgq+Aw=; b=Xy62c99FrD53D/EekFBXaNHitOt2YMxUQngZhNyNpto03cPJym2+p1RtRSTSvN2eDZ N79SEuL+FhWfKUM3n/RtcX0O+Tq5ZDnCoj8eb+TcR/MIHQfCF+20hScUy4T1SPqhAYxF WfsyU9vVYRJvspDmjFuxDTw0GhaXzBm5SK9Q30lzZhNCg+1Qd03kzatFO+BwxG0Yafca Pwob9K+/zzvNFuoUbTfTp4WqZqxRzedbXn11LZKyXxp2eIsFv32dZN8uE86pw4pYoRjp shfZM8SSlIrSAmWJrBv9Vs2FgXLw4BvnbFYAwRXjOeI9ATQhGY7nsVAyM0cAi3F6Orzv Kzsw== MIME-Version: 1.0 X-Received: by 10.140.109.68 with SMTP id k62mr987995qgf.99.1421329877560; Thu, 15 Jan 2015 05:51:17 -0800 (PST) Received: by 10.140.82.180 with HTTP; Thu, 15 Jan 2015 05:51:17 -0800 (PST) Date: Thu, 15 Jan 2015 14:51:17 +0100 Message-ID: Subject: interrupt framework From: Svatopluk Kraus To: freebsd-arm@freebsd.org Content-Type: multipart/mixed; boundary=001a113ad13c76bebd050cb126db X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 13:51:19 -0000 --001a113ad13c76bebd050cb126db Content-Type: text/plain; charset=UTF-8 Hi community, I and Michal Meloun have done some work on ARM interrupt framework and this is the result. We've started with intrng project with Ian's WIP changes, have looked at Andrew's ARM64 git repository, and this is how we think an interrupt framework should look like. We've implemented it with removable interrupt controllers in mind (PCI world). It's not finished from this point of view, however some functions are more complex because of it. It's tested on pandaboard and only GIC is implemented now. There is no problem to implement it to other controllers. We are open to questions and can finish our work considering any comments. Whoever is waiting for ARM interrupt framework as we were, you are welcome to test it. Whoever is welcome. The patches are done against FreeBSD-11-current revision 277210. There are two new files. ARM_INTRNG option must be added to board configuration file for new framework. There are still some things not implemented and some things which should be discussed like PPI support. For example, how to enable PPI interrupt on other CPUs when they are already running? We keep in mind that an interrupt framework should be helpfull but general enough to not dictate interrupt controlles too much. Thus we try to keep some things as much separated as possible. Each interrupt is represented by an interrupt source (ISRC) in the framework. An ISRC is described by an interrupt number which is much more an unique resource handle - totally independent on internal representation of interrupts in any interrupt controller. An interrupt is described by cells in FDT world. The cells can be decoded only by associated interrupt controller and as such, they are transparent for interrupt framework. The framework provides arm_fdt_map_irq() function which maps this transparent cells to an interrupt number. It creates an ISRC, saves cells on it, and once when associated interrupt controller is registered, it provides the ISRC with cells into the controller. It's a controller responsibility to save an ISRC associated with cells. An ISRC is transparent for any controller. However, an controller can set/get its data to/from an ISRC. Further, an controller should set a name to an ISRC according to internal representation of associated interrupt. An controller interrupt dispatch function can call framework only if it has associated ISRC to received interrupt. For legacy reason, there is arm_namespace_map_irq() function. An interrupt is described by namespace type and a number from the namespace. It's intented for use with no FDT drivers. Now, it's used for mapping an IPI on a controller. We think that it's better to call chained controllers (with filter only) without MI interrupt framework overhead, so we implemented shortcut. It could be utilized by INTR_SOLO flag during bus_setup_intr(). Only an interrupt controller can really know its position in interrupt controller's tree. So root controller must claim itself as a root. In FDT world, according to ePAPR approved version 1.1 from 08 April 2011, page 30: "The root of the interrupt tree is determined when traversal of the interrupt tree reaches an interrupt controller node without an interrupts property and thus no explicit interrupt parent." Thus there are no need for any non-standard things in DTS files. Svata --001a113ad13c76bebd050cb126db Content-Type: text/plain; charset=US-ASCII; name="intrng_onwahe1.diff" Content-Disposition: attachment; filename="intrng_onwahe1.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i4y6trgc0 SW5kZXg6IHN5cy9hcm0vYXJtL2dpYy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9hcm0vYXJtL2dpYy5j CShyZXZpc2lvbiAyNzcyMTApCisrKyBzeXMvYXJtL2FybS9naWMuYwkod29ya2luZyBjb3B5KQpA QCAtMzQsNiArMzQsOCBAQAogI2luY2x1ZGUgPHN5cy9jZGVmcy5oPgogX19GQlNESUQoIiRGcmVl QlNEJCIpOwogCisjaW5jbHVkZSAib3B0X3BsYXRmb3JtLmgiCisKICNpbmNsdWRlIDxzeXMvcGFy YW0uaD4KICNpbmNsdWRlIDxzeXMvc3lzdG0uaD4KICNpbmNsdWRlIDxzeXMvYnVzLmg+CkBAIC00 MCw2ICs0Miw3IEBACiAjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgogI2luY2x1ZGUgPHN5cy9rdHIu aD4KICNpbmNsdWRlIDxzeXMvbW9kdWxlLmg+CisjaW5jbHVkZSA8c3lzL21hbGxvYy5oPgogI2lu Y2x1ZGUgPHN5cy9ybWFuLmg+CiAjaW5jbHVkZSA8c3lzL3BjcHUuaD4KICNpbmNsdWRlIDxzeXMv cHJvYy5oPgpAQCAtNTUsNiArNTgsMTEgQEAKICNpbmNsdWRlIDxkZXYvb2Z3L29md19idXMuaD4K ICNpbmNsdWRlIDxkZXYvb2Z3L29md19idXNfc3Vici5oPgogCisjaWZkZWYgQVJNX0lOVFJORwor I2luY2x1ZGUgPHN5cy9zY2hlZC5oPgorI2luY2x1ZGUgInBpY19pZi5oIgorI2VuZGlmCisKIC8q IFdlIGFyZSB1c2luZyBHSUN2MiByZWdpc3RlciBuYW1pbmcgKi8KIAogLyogRGlzdHJpYnV0b3Ig UmVnaXN0ZXJzICovCkBAIC04Myw4ICs5MSw4IEBACiAjZGVmaW5lIEdJQ0NfQUJQUgkJMHgwMDFD CQkJLyogdjEgSUNDQUJQUiAqLwogI2RlZmluZSBHSUNDX0lJRFIJCTB4MDBGQwkJCS8qIHYxIElD Q0lJRFIqLwogCi0jZGVmaW5lCUdJQ19GSVJTVF9JUEkJCSAwCS8qIElycXMgMC0xNSBhcmUgU0dJ cy9JUElzLiAqLwotI2RlZmluZQlHSUNfTEFTVF9JUEkJCTE1CisjZGVmaW5lCUdJQ19GSVJTVF9T R0kJCSAwCS8qIElycXMgMC0xNSBhcmUgU0dJcy9JUElzLiAqLworI2RlZmluZQlHSUNfTEFTVF9T R0kJCTE1CiAjZGVmaW5lCUdJQ19GSVJTVF9QUEkJCTE2CS8qIElycXMgMTYtMzEgYXJlIHByaXZh dGUgKHBlciAqLwogI2RlZmluZQlHSUNfTEFTVF9QUEkJCTMxCS8qIGNvcmUpIHBlcmlwaGVyYWwg aW50ZXJydXB0cy4gKi8KICNkZWZpbmUJR0lDX0ZJUlNUX1NQSQkJMzIJLyogSXJxcyAzMisgYXJl IHNoYXJlZCBwZXJpcGhlcmFscy4gKi8KQEAgLTk4LDggKzEwNiwyMyBAQAogI2RlZmluZSBHSUNE X0lDRkdSX1RSSUdfRURHRQkoMSA8PCAxKQogI2RlZmluZSBHSUNEX0lDRkdSX1RSSUdfTUFTSwkw eDIKIAorI2lmZGVmIEFSTV9JTlRSTkcKKyNkZWZpbmUgR0lDX0lOVFJOQU1FX0xFTgkzMgorCitz dHJ1Y3QgYXJtX2dpY19pcnEgeworCXN0cnVjdCBhcm1faXJxc3JjICoJZ2lfaXNyYzsKKwljaGFy CQkJZ2lfbmFtZVtHSUNfSU5UUk5BTUVfTEVOXTsKK307CisKK3N0YXRpYyBpbnQgYXJtX2dpY19p bnRyKHZvaWQgKiwgc3RydWN0IHRyYXBmcmFtZSAqKTsKKyNlbmRpZgorCiBzdHJ1Y3QgYXJtX2dp Y19zb2Z0YyB7CiAJZGV2aWNlX3QJCWdpY19kZXY7CisjaWZkZWYgQVJNX0lOVFJORworCXZvaWQg KgkJCWdpY19pbnRyaGFuZDsKKwlzdHJ1Y3QgYXJtX2dpY19pcnEgKglnaWNfaXJxczsKKyNlbmRp ZgogCXN0cnVjdCByZXNvdXJjZSAqCWdpY19yZXNbM107CiAJYnVzX3NwYWNlX3RhZ190CQlnaWNf Y19ic3Q7CiAJYnVzX3NwYWNlX3RhZ190CQlnaWNfZF9ic3Q7CkBAIC0xMTMsMTAgKzEzNiwxMyBA QAogc3RhdGljIHN0cnVjdCByZXNvdXJjZV9zcGVjIGFybV9naWNfc3BlY1tdID0gewogCXsgU1lT X1JFU19NRU1PUlksCTAsCVJGX0FDVElWRSB9LAkvKiBEaXN0cmlidXRvciByZWdpc3RlcnMgKi8K IAl7IFNZU19SRVNfTUVNT1JZLAkxLAlSRl9BQ1RJVkUgfSwJLyogQ1BVIEludGVycnVwdCBJbnRm LiByZWdpc3RlcnMgKi8KKyNpZmRlZiBBUk1fSU5UUk5HCisJeyBTWVNfUkVTX0lSUSwJICAwLCBS Rl9BQ1RJVkUgfCBSRl9PUFRJT05BTCB9LCAvKiBQYXJlbnQgaW50ZXJydXB0ICovCisjZW5kaWYK IAl7IC0xLCAwIH0KIH07CiAKLXN0YXRpYyBzdHJ1Y3QgYXJtX2dpY19zb2Z0YyAqYXJtX2dpY19z YyA9IE5VTEw7CitzdGF0aWMgc3RydWN0IGFybV9naWNfc29mdGMgKmdpY19zYyA9IE5VTEw7CiAK ICNkZWZpbmUJZ2ljX2NfcmVhZF80KF9zYywgX3JlZykJCVwKICAgICBidXNfc3BhY2VfcmVhZF80 KChfc2MpLT5naWNfY19ic3QsIChfc2MpLT5naWNfY19ic2gsIChfcmVnKSkKQEAgLTEyNyw5ICsx NTMsMTEgQEAKICNkZWZpbmUJZ2ljX2Rfd3JpdGVfNChfc2MsIF9yZWcsIF92YWwpCQlcCiAgICAg YnVzX3NwYWNlX3dyaXRlXzQoKF9zYyktPmdpY19kX2JzdCwgKF9zYyktPmdpY19kX2JzaCwgKF9y ZWcpLCAoX3ZhbCkpCiAKKyNpZm5kZWYgQVJNX0lOVFJORwogc3RhdGljIGludCBnaWNfY29uZmln X2lycShpbnQgaXJxLCBlbnVtIGludHJfdHJpZ2dlciB0cmlnLAogICAgIGVudW0gaW50cl9wb2xh cml0eSBwb2wpOwogc3RhdGljIHZvaWQgZ2ljX3Bvc3RfZmlsdGVyKHZvaWQgKik7CisjZW5kaWYK IAogc3RhdGljIHN0cnVjdCBvZndfY29tcGF0X2RhdGEgY29tcGF0X2RhdGFbXSA9IHsKIAl7ImFy bSxnaWMiLAkJdHJ1ZX0sCS8qIE5vbi1zdGFuZGFyZCwgdXNlZCBpbiBGcmVlQlNEIGR0cy4gKi8K QEAgLTE1NSwxMCArMTgzLDU4IEBACiAJcmV0dXJuIChCVVNfUFJPQkVfREVGQVVMVCk7CiB9CiAK KyNpZmRlZiBBUk1fSU5UUk5HCitzdGF0aWMgaW5saW5lIHZvaWQKK2dpY19pcnFfdW5tYXNrKHN0 cnVjdCBhcm1fZ2ljX3NvZnRjICpzYywgdV9pbnQgaXJxKQoreworCisJZ2ljX2Rfd3JpdGVfNChz YywgR0lDRF9JU0VOQUJMRVIoaXJxID4+IDUpLCAoMVVMIDw8IChpcnEgJiAweDFGKSkpOworfQor CitzdGF0aWMgaW5saW5lIHZvaWQKK2dpY19pcnFfbWFzayhzdHJ1Y3QgYXJtX2dpY19zb2Z0YyAq c2MsIHVfaW50IGlycSkKK3sKKworCWdpY19kX3dyaXRlXzQoc2MsIEdJQ0RfSUNFTkFCTEVSKGly cSA+PiA1KSwgKDFVTCA8PCAoaXJxICYgMHgxRikpKTsKK30KKyNlbmRpZgorCisjaWZkZWYgU01Q CisjaWZkZWYgQVJNX0lOVFJORwogc3RhdGljIHZvaWQKIGFybV9naWNfaW5pdF9zZWNvbmRhcnko ZGV2aWNlX3QgZGV2KQogewogCXN0cnVjdCBhcm1fZ2ljX3NvZnRjICpzYyA9IGRldmljZV9nZXRf c29mdGMoZGV2KTsKKwl1X2ludCBpcnE7CisKKwlmb3IgKGlycSA9IDA7IGlycSA8IHNjLT5uaXJx czsgaXJxICs9IDQpCisJCWdpY19kX3dyaXRlXzQoc2MsIEdJQ0RfSVBSSU9SSVRZUihpcnEgPj4g MiksIDApOworCisJLyogU2V0IGFsbCB0aGUgaW50ZXJydXB0cyB0byBiZSBpbiBHcm91cCAwIChz ZWN1cmUpICovCisJZm9yIChpcnEgPSAwOyBpcnEgPCBzYy0+bmlycXM7IGlycSArPSAzMikgewor CQlnaWNfZF93cml0ZV80KHNjLCBHSUNEX0lHUk9VUFIoaXJxID4+IDUpLCAwKTsKKwl9CisKKwkv KiBFbmFibGUgQ1BVIGludGVyZmFjZSAqLworCWdpY19jX3dyaXRlXzQoc2MsIEdJQ0NfQ1RMUiwg MSk7CisKKwkvKiBTZXQgcHJpb3JpdHkgbWFzayByZWdpc3Rlci4gKi8KKwlnaWNfY193cml0ZV80 KHNjLCBHSUNDX1BNUiwgMHhmZik7CisKKwkvKiBFbmFibGUgaW50ZXJydXB0IGRpc3RyaWJ1dGlv biAqLworCWdpY19kX3dyaXRlXzQoc2MsIEdJQ0RfQ1RMUiwgMHgwMSk7CisKKwkvKiBVbm1hc2sg YXR0YWNoZWQgUFBJIGludGVycnVwdHMuICovCisJZm9yIChpcnEgPSBHSUNfRklSU1RfUFBJOyBp cnEgPD0gR0lDX0xBU1RfUFBJOyBpcnErKykgeworCQlpZiAoc2MtPmdpY19pcnFzW2lycV0uZ2lf aXNyYyAhPSBOVUxMKQorCQkJZ2ljX2lycV91bm1hc2soc2MsIGlycSk7CisJfQorfQorI2Vsc2UK K3N0YXRpYyB2b2lkCithcm1fZ2ljX2luaXRfc2Vjb25kYXJ5KGRldmljZV90IGRldikKK3sKKwlz dHJ1Y3QgYXJtX2dpY19zb2Z0YyAqc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CiAJaW50IGk7 CiAKIAlmb3IgKGkgPSAwOyBpIDwgc2MtPm5pcnFzOyBpICs9IDQpCkBAIC0xODUsNyArMjYxLDEw IEBACiAJZ2ljX2Rfd3JpdGVfNChzYywgR0lDRF9JU0VOQUJMRVIoMjkgPj4gNSksICgxVUwgPDwg KDI5ICYgMHgxRikpKTsKIAlnaWNfZF93cml0ZV80KHNjLCBHSUNEX0lTRU5BQkxFUigzMCA+PiA1 KSwgKDFVTCA8PCAoMzAgJiAweDFGKSkpOwogfQorI2VuZGlmIC8qIEFSTV9JTlRSTkcgKi8KKyNl bmRpZiAvKiBTTVAgKi8KIAorI2lmbmRlZiBBUk1fSU5UUk5HCiBpbnQKIGdpY19kZWNvZGVfZmR0 KHVpbnQzMl90IGlwYXJlbnQsIHVpbnQzMl90ICppbnRyLCBpbnQgKmludGVycnVwdCwKICAgICBp bnQgKnRyaWcsIGludCAqcG9sKQpAQCAtMjMwLDYgKzMwOSw3IEBACiAJfQogCXJldHVybiAoMCk7 CiB9CisjZW5kaWYKIAogc3RhdGljIGludAogYXJtX2dpY19hdHRhY2goZGV2aWNlX3QgZGV2KQpA QCAtMjM4LDcgKzMxOCw3IEBACiAJaW50CQlpOwogCXVpbnQzMl90CWljY2lpZHI7CiAKLQlpZiAo YXJtX2dpY19zYykKKwlpZiAoZ2ljX3NjKQogCQlyZXR1cm4gKEVOWElPKTsKIAogCXNjID0gZGV2 aWNlX2dldF9zb2Z0YyhkZXYpOwpAQCAtMjQ5LDcgKzMyOSw3IEBACiAJfQogCiAJc2MtPmdpY19k ZXYgPSBkZXY7Ci0JYXJtX2dpY19zYyA9IHNjOworCWdpY19zYyA9IHNjOwogCiAJLyogSW5pdGlh bGl6ZSBtdXRleCAqLwogCW10eF9pbml0KCZzYy0+bXV0ZXgsICJHSUMgbG9jayIsICIiLCBNVFhf U1BJTik7CkBAIC0yNjksOSArMzQ5LDE0IEBACiAJc2MtPm5pcnFzID0gZ2ljX2RfcmVhZF80KHNj LCBHSUNEX1RZUEVSKTsKIAlzYy0+bmlycXMgPSAzMiAqICgoc2MtPm5pcnFzICYgMHgxZikgKyAx KTsKIAorI2lmZGVmIEFSTV9JTlRSTkcKKwlzYy0+Z2ljX2lycXMgPSBtYWxsb2Moc2MtPm5pcnFz ICogc2l6ZW9mICgqc2MtPmdpY19pcnFzKSwgTV9ERVZCVUYsCisJICAgIE1fV0FJVE9LIHwgTV9a RVJPKTsKKyNlbHNlCiAJLyogU2V0IHVwIGZ1bmN0aW9uIHBvaW50ZXJzICovCiAJYXJtX3Bvc3Rf ZmlsdGVyID0gZ2ljX3Bvc3RfZmlsdGVyOwogCWFybV9jb25maWdfaXJxID0gZ2ljX2NvbmZpZ19p cnE7CisjZW5kaWYKIAogCWljY2lpZHIgPSBnaWNfY19yZWFkXzQoc2MsIEdJQ0NfSUlEUik7CiAJ ZGV2aWNlX3ByaW50ZihkZXYsInBuIDB4JXgsIGFyY2ggMHgleCwgcmV2IDB4JXgsIGltcGxlbWVu dGVyIDB4JXggaXJxcyAldVxuIiwKQEAgLTMwNywxMSArMzkyLDQyOSBAQAogCiAJLyogRW5hYmxl IGludGVycnVwdCBkaXN0cmlidXRpb24gKi8KIAlnaWNfZF93cml0ZV80KHNjLCBHSUNEX0NUTFIs IDB4MDEpOworI2lmbmRlZiBBUk1fSU5UUk5HCisJcmV0dXJuICgwKTsKKyNlbHNlCisJLyoKKwkg KiBOb3csIHdoZW4gZXZlcnl0aGluZyBpcyBpbml0aWFsaXplZCwgaXQncyByaWdodCB0aW1lIHRv CisJICogcmVnaXN0ZXIgaW50ZXJydXB0IGNvbnRyb2xsZXIgdG8gaW50ZXJydXB0IGZyYW1lZm9y ay4KKwkgKi8KKwlpZiAoYXJtX3JlZ2lzdGVyX3BpYyhkZXYpICE9IDApIHsKKwkJZGV2aWNlX3By aW50ZihkZXYsICJjb3VsZCBub3QgcmVnaXN0ZXIgSUNcbiIpOworCQlnb3RvIGNsZWFudXA7CisJ fQogCisJaWYgKHNjLT5naWNfcmVzWzJdID09IE5VTEwpIHsKKwkJaWYgKGFybV9pcnFfc2V0X3Jv b3QoZGV2LCBhcm1fZ2ljX2ludHIsIHNjLAorCQkgICAgR0lDX0xBU1RfU0dJIC0gR0lDX0ZJUlNU X1NHSSArIDEpICE9IDApIHsKKwkJCWRldmljZV9wcmludGYoZGV2LCAiY291bGQgbm90IHNldCBQ SUMgYXMgYSByb290XG4iKTsKKwkJCWFybV91bnJlZ2lzdGVyX3BpYyhkZXYpOworCQkJZ290byBj bGVhbnVwOworCQl9CisJfSBlbHNlIHsKKwkJaWYgKGJ1c19zZXR1cF9pbnRyKGRldiwgc2MtPmdp Y19yZXNbMl0sIElOVFJfVFlQRV9NSVNDIHwKKwkJICAgIElOVFJfU09MTywgKHZvaWQqKWFybV9n aWNfaW50ciwgTlVMTCwgc2MsCisJCSAgICAmc2MtPmdpY19pbnRyaGFuZCkpIHsKKwkJCWRldmlj ZV9wcmludGYoZGV2LCAiY291bGQgbm90IHNldHVwIGlycSBoYW5kbGVyXG4iKTsKKwkJCWFybV91 bnJlZ2lzdGVyX3BpYyhkZXYpOworCQkJZ290byBjbGVhbnVwOworCQl9CisJfQorCiAJcmV0dXJu ICgwKTsKKworY2xlYW51cDoKKwkvKgorCSAqIFhYWCAtIG5vdCBpbXBsZW1lbnRlZCBhcm1fZ2lj X2RldGFjaCgpIHNob3VsZCBiZSBjYWxsZWQgIQorCSAqLworCWlmIChzYy0+Z2ljX2lycXMgIT0g TlVMTCkKKwkJZnJlZShzYy0+Z2ljX2lycXMsIE1fREVWQlVGKTsKKwlidXNfcmVsZWFzZV9yZXNv dXJjZXMoZGV2LCBhcm1fZ2ljX3NwZWMsIHNjLT5naWNfcmVzKTsKKwlyZXR1cm4oRU5YSU8pOwor I2VuZGlmCiB9CiAKKyNpZmRlZiBBUk1fSU5UUk5HCiBzdGF0aWMgaW50Cithcm1fZ2ljX2ludHIo dm9pZCAqYXJnLCBzdHJ1Y3QgdHJhcGZyYW1lICp0ZikKK3sKKwlzdHJ1Y3QgYXJtX2dpY19zb2Z0 YyAqc2MgPSAoc3RydWN0IGFybV9naWNfc29mdGMgKilhcmc7CisJc3RydWN0IGFybV9naWNfaXJx ICpnaTsKKwl1aW50MzJfdCBpcnFfYWN0aXZlX3JlZywgaXJxOworCisJaXJxX2FjdGl2ZV9yZWcg PSBnaWNfY19yZWFkXzQoc2MsIEdJQ0NfSUFSKTsKKwlpcnEgPSBpcnFfYWN0aXZlX3JlZyAmIDB4 M0ZGOworCisJLyoKKwkgKiAxLiBFT0kgbXVzdCBiZSBkb25lIGhlcmUgYXMgdGhlIG90aGVyIGJp dHMgKGkuZS4gQ1BVIG51bWJlciksIG5vdAorCSAqICAgIGp1c3QgdGhlIElSUSBudW1iZXIgYXJl IHJlcXVpcmVkLCBhbmQgd2UgZG8gbm90IGhhdmUgYSBtZXRob2QKKwkgKiAgICBob3cgdG8gcGFz cyB0aGlzIGluZm9ybWF0aW9uIHRvIGRpc3BhdGNoIGZ1bmN0aW9uLgorCSAqIDIuIEVPSSBtdXN0 IGJlIGRvbmUgb24gc2FtZSBDUFUsIHdoZXJlIGludGVycnVwdCBoYXMgZmlyZWQuIFRodXMKKwkg KiAgICB3ZSBtdXN0IGVuc3VyZSB0aGF0IGludGVycnVwdGVkIHRocmVhZCBkb2VzIG5vdCBtaWdy YXRlIHRvCisJICogICAgYW5vdGhlciBDUFUuCisJICogMy4gRU9JIGNhbm5vdCBiZSBkZWxheWVk IGJ5IGFueSBwcmVlbXB0aW9uLCB3aGljaCBjb3VsZCBoYXBwZW4gb24KKwkgKiAgICBjcml0aWNh bF9leGl0KCkgdXNlZCBpbiBNSSBpbnRyIGNvZGUsIHdoZW4gaW50ZXJydXB0IHRocmVhZCBpcwor CSAqICAgIHNjaGVkdWxlZC4gU2VlIG5leHQgcG9pbnQuCisJICogNC4gSVBJX1JFTkRFWlZPVVMg YXNzdW1lcyB0aGF0IG5vIHByZWVtcHRpb24gaXMgcGVybWl0dGVkIGR1cmluZworCSAqICAgIGFu IGFjdGlvbiBhbmQgYW55IHVzZSBvZiBjcml0aWNhbF9leGl0KCkgY291bGQgYnJlYWsgdGhpcwor CSAqICAgIGFzc3VtcHRpb24uIFNlZSBjb21tZW50cyB3aXRoaW4gc21wX3JlbmRlenZvdXNfYWN0 aW9uKCkuCisJICovCisKKwlpZiAoaXJxID49IHNjLT5uaXJxcykgeworCQlkZXZpY2VfcHJpbnRm KHNjLT5naWNfZGV2LCAiU3B1cmlvdXMgaW50ZXJydXB0IGRldGVjdGVkXG4iKTsKKwkJZ2ljX2Nf d3JpdGVfNChzYywgR0lDQ19FT0lSLCBpcnFfYWN0aXZlX3JlZyk7CisJCXJldHVybiAoMCk7CisJ fQorCisJZ2kgPSAmc2MtPmdpY19pcnFzW2lycV07CisJaWYgKGdpLT5naV9pc3JjID09IE5VTEwp IHsKKwkJZGV2aWNlX3ByaW50ZihzYy0+Z2ljX2RldiwgIlN0cmF5IGludGVycnVwdCAldSBkZXRl Y3RlZFxuIiwgaXJxKTsKKwkJZ2ljX2lycV9tYXNrKHNjLCBpcnEpOworCQlnaWNfY193cml0ZV80 KHNjLCBHSUNDX0VPSVIsIGlycV9hY3RpdmVfcmVnKTsKKwkJcmV0dXJuICgwKTsKKwl9CisKKwkv KgorCSAqIE5vdGUgdGhhdCBHSUNfRklSU1RfU0dJIGlzIHplcm8gYW5kIGlzIG5vdCB1c2VkIGlu ICdpZicgc3RhdGVtZW50CisJICogYXMgY29tcGlsZXIgY29tcGxhaW5zIHRoYXQgY29tcGFyaW5n IHVfaW50ID49IDAgaXMgYWx3YXlzIHRydWUuCisJICovCisJaWYgKGlycSA8PSBHSUNfTEFTVF9T R0kpIHsKKyNpZmRlZiBTTVAKKwkJLyogQ2FsbCBFT0kgZm9yIGFsbCBJUEkgYmVmb3JlIGRpc3Bh dGNoLiAqLworCQlnaWNfY193cml0ZV80KHNjLCBHSUNDX0VPSVIsIGlycV9hY3RpdmVfcmVnKTsK KwkJYXJtX2Rpc3BhdGNoX3NnaShnaS0+Z2lfaXNyYywgdGYpOworCQlyZXR1cm4gKEZJTFRFUl9I QU5ETEVEKTsKKyNlbHNlCisJCXByaW50ZigiU0dJICV1IG9uIFVQIHN5c3RlbSBkZXRlY3RlZFxu IiwgaXJxIC0gR0lDX0ZJUlNUX1NHSSk7CisJCWdpY19jX3dyaXRlXzQoc2MsIEdJQ0NfRU9JUiwg aXJxX2FjdGl2ZV9yZWcpOworCQlyZXR1cm4gKDApOworI2VuZGlmCisJfQorCisJY3JpdGljYWxf ZW50ZXIoKTsKKwlpZiAoaXJxIDw9IEdJQ19MQVNUX1BQSSkKKwkJYXJtX2Rpc3BhdGNoX3BwaShn aS0+Z2lfaXNyYywgdGYpOworCWVsc2UKKwkJYXJtX2Rpc3BhdGNoX3NwaShnaS0+Z2lfaXNyYywg dGYpOworCWdpY19jX3dyaXRlXzQoc2MsIEdJQ0NfRU9JUiwgaXJxX2FjdGl2ZV9yZWcpOworCWNy aXRpY2FsX2V4aXQoKTsKKwlhcm1faXJxX21lbW9yeV9iYXJyaWVyKGlycSk7CisJcmV0dXJuIChG SUxURVJfSEFORExFRCk7Cit9CisKK3N0YXRpYyBpbnQKK2dpY19uYW1lc3BhY2VfdG9faXJxKHN0 cnVjdCBhcm1fZ2ljX3NvZnRjICpzYywgdV9pbnQgdHlwZSwgdV9pbnQgbnVtLAorICAgIHVfaW50 ICppcnFwKQoreworCXVfaW50IGlycTsKKworCWlmICh0eXBlID09IElTUkNUX1NHSSkKKwkJaXJx ID0gR0lDX0ZJUlNUX1NHSSArIG51bTsKKwllbHNlIGlmICh0eXBlID09IElTUkNUX1BQSSkKKwkJ aXJxID0gR0lDX0ZJUlNUX1BQSSArIG51bTsKKwllbHNlIGlmICh0eXBlID09IElTUkNUX1NQSSkK KwkJaXJxID0gR0lDX0ZJUlNUX1NQSSArIG51bTsKKwllbHNlCisJCXJldHVybiAoRUlOVkFMKTsK KworCWlmIChpcnEgPj0gc2MtPm5pcnFzKQorCQlyZXR1cm4gKEVJTlZBTCk7CisKKwkqaXJxcCA9 IGlycTsKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CitnaWNfaXJxX3RvX25hbWVzcGFj ZShzdHJ1Y3QgYXJtX2dpY19zb2Z0YyAqc2MsIHVfaW50IGlycSwgdV9pbnQgKnR5cGVwLAordV9p bnQgKm51bXApCit7CisKKwlpZiAoaXJxIDw9IEdJQ19MQVNUX1NHSSkgeworCQkqdHlwZXAgPSBJ U1JDVF9TR0k7CisJCSpudW1wID0gaXJxIC0gR0lDX0ZJUlNUX1NHSTsKKwl9IGVsc2UgaWYgKGly cSA8PSBHSUNfTEFTVF9QUEkpIHsKKwkJKnR5cGVwID0gSVNSQ1RfUFBJOworCQkqbnVtcCA9IGly cSAtIEdJQ19GSVJTVF9QUEk7CisJfSBlbHNlIGlmIChpcnEgPCBzYy0+bmlycXMpIHsKKwkJKnR5 cGVwID0gSVNSQ1RfU1BJOworCQkqbnVtcCA9IGlycSAtIEdJQ19GSVJTVF9TUEk7CisJfSBlbHNl CisJCXJldHVybiAoRUlOVkFMKTsKKworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBpbnQKK2dp Y19hdHRhY2hfaXNyYyhzdHJ1Y3QgYXJtX2dpY19zb2Z0YyAqc2MsIHN0cnVjdCBhcm1faXJxc3Jj ICppc3JjLCB1X2ludCBpcnEpCit7CisJc3RydWN0IGFybV9naWNfaXJxICpnaSA9ICZzYy0+Z2lj X2lycXNbaXJxXTsKKworCWlmIChnaS0+Z2lfaXNyYyA9PSBpc3JjKQorCQlyZXR1cm4gKDApOwor CisJaWYgKGdpLT5naV9pc3JjICE9IE5VTEwpCisJCXJldHVybiAoRUVYSVNUKTsKKworCWlmIChp cnEgPD0gR0lDX0xBU1RfU0dJKQorCQlzbnByaW50ZihnaS0+Z2lfbmFtZSwgR0lDX0lOVFJOQU1F X0xFTiwgIiVzKHNnaSV1KSIsCisJCSAgICBkZXZpY2VfZ2V0X25hbWV1bml0KHNjLT5naWNfZGV2 KSwgaXJxIC0gR0lDX0ZJUlNUX1NHSSk7CisJZWxzZSBpZiAoaXJxIDw9IEdJQ19MQVNUX1BQSSkK KwkJc25wcmludGYoZ2ktPmdpX25hbWUsIEdJQ19JTlRSTkFNRV9MRU4sICIlcyhwcGkldSkiLAor CQkgICAgZGV2aWNlX2dldF9uYW1ldW5pdChzYy0+Z2ljX2RldiksIGlycSAtIEdJQ19GSVJTVF9Q UEkpOworCWVsc2UKKwkJc25wcmludGYoZ2ktPmdpX25hbWUsIEdJQ19JTlRSTkFNRV9MRU4sICIl cyhzcGkldSkiLAorCQkgICAgZGV2aWNlX2dldF9uYW1ldW5pdChzYy0+Z2ljX2RldiksIGlycSAt IEdJQ19GSVJTVF9TUEkpOworCisJYXJtX2lycV9zZXRfZGF0YShpc3JjLCAodm9pZCAqKWlycSk7 CisJYXJtX2lycV9zZXRfbmFtZShpc3JjLCBnaS0+Z2lfbmFtZSk7CisKKwlnaS0+Z2lfaXNyYyA9 IGlzcmM7CisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIGludAorZ2ljX2RldGFjaF9pc3JjKHN0 cnVjdCBhcm1fZ2ljX3NvZnRjICpzYywgc3RydWN0IGFybV9pcnFzcmMgKmlzcmMsIHVfaW50IGly cSkKK3sKKwlzdHJ1Y3QgYXJtX2dpY19pcnEgKmdpID0gJnNjLT5naWNfaXJxc1tpcnFdOworCisJ aWYgKGlycSA+PSBzYy0+bmlycXMgfHwgZ2ktPmdpX2lzcmMgIT0gaXNyYykKKwkJcmV0dXJuIChF SU5WQUwpOworCisJYXJtX2lycV9zZXRfZGF0YShpc3JjLCBOVUxMKTsKKwlhcm1faXJxX3NldF9u YW1lKGlzcmMsIE5VTEwpOworCisJZ2ktPmdpX2lzcmMgPSBOVUxMOworCXJldHVybiAoMCk7Cit9 CisKK3N0YXRpYyBpbnQKK2FybV9naWNfbWFwKGRldmljZV90IGRldiwgc3RydWN0IGFybV9pcnFz cmMgKmlzcmMsIHVfaW50IHR5cGUsIHVfaW50IG51bSkKK3sKKwlzdHJ1Y3QgYXJtX2dpY19zb2Z0 YyAqc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJdV9pbnQgaXJxOworCWludCBlcnJvcjsK KworCWVycm9yID0gZ2ljX25hbWVzcGFjZV90b19pcnEoc2MsIHR5cGUsIG51bSwgJmlycSk7CisJ aWYgKGVycm9yICE9IDApCisJCXJldHVybiAoZXJyb3IpOworCisJcmV0dXJuIChnaWNfYXR0YWNo X2lzcmMoc2MsIGlzcmMsIGlycSkpOworfQorCitzdGF0aWMgdm9pZAorZ2ljX2NvbmZpZyhzdHJ1 Y3QgYXJtX2dpY19zb2Z0YyAqc2MsIHVfaW50IGlycSwgZW51bSBpbnRyX3RyaWdnZXIgdHJpZywK KyAgICBlbnVtIGludHJfcG9sYXJpdHkgcG9sKQoreworCXVpbnQzMl90IHJlZzsKKwl1aW50MzJf dCBtYXNrOworCisJaWYgKGlycSA8IEdJQ19GSVJTVF9TUEkpCisJCXJldHVybjsKKworCW10eF9s b2NrX3NwaW4oJnNjLT5tdXRleCk7CisKKwlyZWcgPSBnaWNfZF9yZWFkXzQoc2MsIEdJQ0RfSUNG R1IoaXJxID4+IDQpKTsKKwltYXNrID0gKHJlZyA+PiAyKihpcnEgJSAxNikpICYgMHgzOworCisJ aWYgKHBvbCA9PSBJTlRSX1BPTEFSSVRZX0xPVykgeworCQltYXNrICY9IH5HSUNEX0lDRkdSX1BP TF9NQVNLOworCQltYXNrIHw9IEdJQ0RfSUNGR1JfUE9MX0xPVzsKKwl9IGVsc2UgaWYgKHBvbCA9 PSBJTlRSX1BPTEFSSVRZX0hJR0gpIHsKKwkJbWFzayAmPSB+R0lDRF9JQ0ZHUl9QT0xfTUFTSzsK KwkJbWFzayB8PSBHSUNEX0lDRkdSX1BPTF9ISUdIOworCX0KKworCWlmICh0cmlnID09IElOVFJf VFJJR0dFUl9MRVZFTCkgeworCQltYXNrICY9IH5HSUNEX0lDRkdSX1RSSUdfTUFTSzsKKwkJbWFz ayB8PSBHSUNEX0lDRkdSX1RSSUdfTFZMOworCX0gZWxzZSBpZiAodHJpZyA9PSBJTlRSX1RSSUdH RVJfRURHRSkgeworCQltYXNrICY9IH5HSUNEX0lDRkdSX1RSSUdfTUFTSzsKKwkJbWFzayB8PSBH SUNEX0lDRkdSX1RSSUdfRURHRTsKKwl9CisKKwkvKiBTZXQgbWFzayAqLworCXJlZyA9IHJlZyAm IH4oMHgzIDw8IDIqKGlycSAlIDE2KSk7CisJcmVnID0gcmVnIHwgKG1hc2sgPDwgMiooaXJxICUg MTYpKTsKKwlnaWNfZF93cml0ZV80KHNjLCBHSUNEX0lDRkdSKGlycSA+PiA0KSwgcmVnKTsKKwor CW10eF91bmxvY2tfc3Bpbigmc2MtPm11dGV4KTsKK30KKworI2lmZGVmIEZEVAorc3RhdGljIGlu dAorYXJtX2dpY19tYXBfZmR0KGRldmljZV90IGRldiwgc3RydWN0IGFybV9pcnFzcmMgKmlzcmMs IHBjZWxsX3QgKmNlbGxzLAorICAgIHVfaW50IG5jZWxscykKK3sKKwlzdHJ1Y3QgYXJtX2dpY19z b2Z0YyAqc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJdV9pbnQgaXJxLCB0eXBlLCBudW0s IHRyaXBvbDsKKwllbnVtIGludHJfdHJpZ2dlciB0cmlnOworCWVudW0gaW50cl9wb2xhcml0eSBw b2w7CisJaW50IGVycm9yOworCisJaWYgKG5jZWxscyA9PSAxKSB7CisJCWlycSA9IGNlbGxzWzBd OworCisJCWVycm9yID0gZ2ljX2lycV90b19uYW1lc3BhY2Uoc2MsIGlycSwgJnR5cGUsICZudW0p OworCQlpZiAoZXJyb3IgIT0gMCkKKwkJCXJldHVybiAoZXJyb3IpOworCisJCXBvbCA9IElOVFJf UE9MQVJJVFlfQ09ORk9STTsKKwkJdHJpZyA9IElOVFJfVFJJR0dFUl9DT05GT1JNOworCX0gZWxz ZSB7CisKKwkJdHlwZSA9IGNlbGxzWzBdID09IDAgPyBJU1JDVF9TUEkgOiBJU1JDVF9QUEk7CisJ CW51bSA9IGNlbGxzWzFdOworCisJCWVycm9yID0gZ2ljX25hbWVzcGFjZV90b19pcnEoc2MsIHR5 cGUsIG51bSwgJmlycSk7CisJCWlmIChlcnJvciAhPSAwKQorCQkJcmV0dXJuIChlcnJvcik7CisK KwkJLyoKKwkJICogSW4gaW50clsyXSwgYml0c1szOjBdIGFyZSB0cmlnZ2VyIHR5cGUgYW5kIGxl dmVsIGZsYWdzLgorCQkgKiAgIDEgPSBsb3ctdG8taGlnaCBlZGdlIHRyaWdnZXJlZAorCQkgKiAg IDIgPSBoaWdoLXRvLWxvdyBlZGdlIHRyaWdnZXJlZAorCQkgKiAgIDQgPSBhY3RpdmUgaGlnaCBs ZXZlbC1zZW5zaXRpdmUKKwkJICogICA4ID0gYWN0aXZlIGxvdyBsZXZlbC1zZW5zaXRpdmUKKwkJ ICogVGhlIGhhcmR3YXJlIG9ubHkgc3VwcG9ydHMgYWN0aXZlLWhpZ2gtbGV2ZWwgb3IgcmlzaW5n LWVkZ2UuCisJCSAqLworCQl0cmlwb2wgPSBjZWxsc1syXTsKKwkJaWYgKHRyaXBvbCAmIDB4MGEp IHsKKwkJCXByaW50ZigidW5zdXBwb3J0ZWQgdHJpZ2dlci9wb2xhcml0eSBjb25maWd1cmF0aW9u ICIKKwkJCSAgICAiMHglMnhcbiIsIHRyaXBvbCAmIDB4MGYpOworCQkJcmV0dXJuIChFTk9UU1VQ KTsKKwkJfQorCQlwb2wgID0gSU5UUl9QT0xBUklUWV9DT05GT1JNOworCQlpZiAodHJpcG9sICYg MHgwMSkKKwkJCXRyaWcgPSBJTlRSX1RSSUdHRVJfRURHRTsKKwkJZWxzZQorCQkJdHJpZyA9IElO VFJfVFJJR0dFUl9MRVZFTDsKKwl9CisKKwllcnJvciA9IGdpY19hdHRhY2hfaXNyYyhzYywgaXNy YywgaXJxKTsKKwlpZiAoZXJyb3IgIT0gMCkKKwkJcmV0dXJuIChlcnJvcik7CisKKwlhcm1faXJx X3NldF9uYW1lc3BhY2UoaXNyYywgdHlwZSwgbnVtKTsKKworCWdpY19jb25maWcoc2MsIGlycSwg dHJpZywgcG9sKTsKKwlyZXR1cm4gKDApOworfQorI2VuZGlmCisKK3N0YXRpYyBpbnQKK2FybV9n aWNfdW5tYXAoZGV2aWNlX3QgZGV2LCBzdHJ1Y3QgYXJtX2lycXNyYyAqaXNyYykKK3sKKwlzdHJ1 Y3QgYXJtX2dpY19zb2Z0YyAqc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJdV9pbnQgaXJx OworCisJaXJxID0gKHVfaW50KWFybV9pcnFfZ2V0X2RhdGEoaXNyYyk7CisJcmV0dXJuIChnaWNf ZGV0YWNoX2lzcmMoc2MsIGlzcmMsIGlycSkpOworfQorCitzdGF0aWMgaW50Cithcm1fZ2ljX2Jp bmQoZGV2aWNlX3QgZGV2LCBzdHJ1Y3QgYXJtX2lycXNyYyAqaXNyYywgY3B1c2V0X3QgY3B1bWFz aykKK3sKKworCXJldHVybiAoRU9QTk9UU1VQUCk7IC8qIGZvciBub3cgKi8KK30KKworc3RhdGlj IGludAorYXJtX2dpY19jb25maWcoZGV2aWNlX3QgZGV2LCBzdHJ1Y3QgYXJtX2lycXNyYyAqaXNy YywgZW51bSBpbnRyX3RyaWdnZXIgdHJpZywKKyAgICBlbnVtIGludHJfcG9sYXJpdHkgcG9sKQor eworCXN0cnVjdCBhcm1fZ2ljX3NvZnRjICpzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKKwl1 X2ludCBpcnE7CisKKwkvKiBYWFggbW92ZSB0aGVzZSBjaGVja3MgdG8gZnJhbWV3b3JrICovCisJ aWYgKCh0cmlnICE9IElOVFJfVFJJR0dFUl9FREdFKSAmJiAodHJpZyAhPSBJTlRSX1RSSUdHRVJf TEVWRUwpICYmCisJICAgICh0cmlnICE9IElOVFJfVFJJR0dFUl9DT05GT1JNKSkKKwkJcmV0dXJu IChFSU5WQUwpOworCWlmICgocG9sICE9IElOVFJfUE9MQVJJVFlfSElHSCkgJiYgKHBvbCAhPSBJ TlRSX1BPTEFSSVRZX0xPVykgJiYKKwkgICAgKHBvbCAhPSBJTlRSX1BPTEFSSVRZX0NPTkZPUk0p KQorCQlyZXR1cm4gKEVJTlZBTCk7CisKKwlpcnEgPSAodV9pbnQpYXJtX2lycV9nZXRfZGF0YShp c3JjKTsKKwlpZiAoaXJxID49IHNjLT5uaXJxcyB8fCBzYy0+Z2ljX2lycXNbaXJxXS5naV9pc3Jj ICE9IGlzcmMpCisJCXJldHVybiAoRUlOVkFMKTsKKworCWdpY19jb25maWcoc2MsIGlycSwgdHJp ZywgcG9sKTsKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgdm9pZAorYXJtX2dpY19lbmFibGUo ZGV2aWNlX3QgZGV2LCBzdHJ1Y3QgYXJtX2lycXNyYyAqaXNyYykKK3sKKwlzdHJ1Y3QgYXJtX2dp Y19zb2Z0YyAqc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJdV9pbnQgaXJxOworCisJaXJx ID0gKHVfaW50KWFybV9pcnFfZ2V0X2RhdGEoaXNyYyk7CisJaWYgKGlycSA+PSBzYy0+bmlycXMg fHwgc2MtPmdpY19pcnFzW2lycV0uZ2lfaXNyYyAhPSBpc3JjKQorCQlyZXR1cm47CisKKwlpZiAo aXJxIDw9IEdJQ19MQVNUX1NHSSkKKwkJcmV0dXJuOyAvKiB2MiBJTVBMRU1FTlRBVElPTiBERUZJ TkVEICovCisKKwlhcm1faXJxX21lbW9yeV9iYXJyaWVyKGlycSk7CisJZ2ljX2lycV91bm1hc2so c2MsIGlycSk7Cit9CisKK3N0YXRpYyB2b2lkCithcm1fZ2ljX2Rpc2FibGUoZGV2aWNlX3QgZGV2 LCBzdHJ1Y3QgYXJtX2lycXNyYyAqaXNyYykKK3sKKwlzdHJ1Y3QgYXJtX2dpY19zb2Z0YyAqc2Mg PSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJdV9pbnQgaXJxOworCisJaXJxID0gKHVfaW50KWFy bV9pcnFfZ2V0X2RhdGEoaXNyYyk7CisJaWYgKGlycSA+PSBzYy0+bmlycXMgfHwgc2MtPmdpY19p cnFzW2lycV0uZ2lfaXNyYyAhPSBpc3JjKQorCQlyZXR1cm47CisKKwlpZiAoaXJxIDw9IEdJQ19M QVNUX1NHSSkKKwkJcmV0dXJuOyAvKiB2MiBJTVBMRU1FTlRBVElPTiBERUZJTkVEICovCisKKwln aWNfaXJxX21hc2soc2MsIGlycSk7Cit9CisKK3N0YXRpYyB2b2lkCithcm1fZ2ljX3ByZV9pdGhy ZWFkKGRldmljZV90IGRldiwgc3RydWN0IGFybV9pcnFzcmMgKmlzcmMpCit7CisKKwlhcm1fZ2lj X2Rpc2FibGUoZGV2LCBpc3JjKTsKK30KKworc3RhdGljIHZvaWQKK2FybV9naWNfcG9zdF9pdGhy ZWFkKGRldmljZV90IGRldiwgc3RydWN0IGFybV9pcnFzcmMgKmlzcmMpCit7CisKKwlhcm1fZ2lj X2VuYWJsZShkZXYsIGlzcmMpOworfQorCitzdGF0aWMgdm9pZAorYXJtX2dpY19wb3N0X2ZpbHRl cihkZXZpY2VfdCBkZXYsIHN0cnVjdCBhcm1faXJxc3JjICppc3JjKQoreworCisJLyogRU9JIG11 c3QgYmUgZG9uZSBpbiBjb250cm9sbGVyJ3MgaW50ZXJydXB0IHJvdXRpbmUuICovCit9CisKKyNp ZmRlZiBTTVAKK3N0YXRpYyB2b2lkCithcm1fZ2ljX2lwaV9zZW5kKGRldmljZV90IGRldiwgc3Ry dWN0IGFybV9pcnFzcmMgKmlzcmMsIGNwdXNldF90IGNwdXMpCit7CisJc3RydWN0IGFybV9naWNf c29mdGMgKnNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCXVpbnQzMl90IGlycSwgdmFsID0g MCwgaTsKKworCWlycSA9ICh1X2ludClhcm1faXJxX2dldF9kYXRhKGlzcmMpOworCWlmIChpcnEg Pj0gc2MtPm5pcnFzIHx8IHNjLT5naWNfaXJxc1tpcnFdLmdpX2lzcmMgIT0gaXNyYykKKwkJcmV0 dXJuOworCisJZm9yIChpID0gMDsgaSA8IE1BWENQVTsgaSsrKQorCQlpZiAoQ1BVX0lTU0VUKGks ICZjcHVzKSkKKwkJCXZhbCB8PSAxIDw8ICgxNiArIGkpOworCisJZ2ljX2Rfd3JpdGVfNChzYywg R0lDRF9TR0lSKDApLCB2YWwgfCBpcnEpOworfQorI2VuZGlmCisjZWxzZQorc3RhdGljIGludAog YXJtX2dpY19uZXh0X2lycShzdHJ1Y3QgYXJtX2dpY19zb2Z0YyAqc2MsIGludCBsYXN0X2lycSkK IHsKIAl1aW50MzJfdCBhY3RpdmVfaXJxOwpAQCAtMzIzLDcgKzgyNiw3IEBACiAJICogYml0cyAo aWUgQ1BVIG51bWJlciksIG5vdCBqdXN0IHRoZSBJUlEgbnVtYmVyLCBhbmQgd2UgZG8gbm90CiAJ ICogaGF2ZSB0aGlzIGluZm9ybWF0aW9uIGxhdGVyLgogCSAqLwotCWlmICgoYWN0aXZlX2lycSAm IDB4M2ZmKSA8PSBHSUNfTEFTVF9JUEkpCisJaWYgKChhY3RpdmVfaXJxICYgMHgzZmYpIDw9IEdJ Q19MQVNUX1NHSSkKIAkJZ2ljX2Nfd3JpdGVfNChzYywgR0lDQ19FT0lSLCBhY3RpdmVfaXJxKTsK IAlhY3RpdmVfaXJxICY9IDB4M0ZGOwogCkBAIC0zOTYsNyArODk5LDcgQEAKIAlzdHJ1Y3QgYXJt X2dpY19zb2Z0YyAqc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CiAKIAlnaWNfZF93cml0ZV80 KHNjLCBHSUNEX0lDRU5BQkxFUihpcnEgPj4gNSksICgxVUwgPDwgKGlycSAmIDB4MUYpKSk7Ci0J Z2ljX2Nfd3JpdGVfNChzYywgR0lDQ19FT0lSLCBpcnEpOworCWdpY19jX3dyaXRlXzQoc2MsIEdJ Q0NfRU9JUiwgaXJxKTsgLyogWFhYIC0gbm90IGFsbG93ZWQgKi8KIH0KIAogc3RhdGljIHZvaWQK QEAgLTQwNCw3ICs5MDcsNyBAQAogewogCXN0cnVjdCBhcm1fZ2ljX3NvZnRjICpzYyA9IGRldmlj ZV9nZXRfc29mdGMoZGV2KTsKIAotCWlmIChpcnEgPiBHSUNfTEFTVF9JUEkpCisJaWYgKGlycSA+ IEdJQ19MQVNUX1NHSSkKIAkJYXJtX2lycV9tZW1vcnlfYmFycmllcihpcnEpOwogCiAJZ2ljX2Rf d3JpdGVfNChzYywgR0lDRF9JU0VOQUJMRVIoaXJxID4+IDUpLCAoMVVMIDw8IChpcnEgJiAweDFG KSkpOwpAQCAtNDUxLDEwICs5NTQsMTAgQEAKIHN0YXRpYyB2b2lkCiBnaWNfcG9zdF9maWx0ZXIo dm9pZCAqYXJnKQogewotCXN0cnVjdCBhcm1fZ2ljX3NvZnRjICpzYyA9IGFybV9naWNfc2M7CisJ c3RydWN0IGFybV9naWNfc29mdGMgKnNjID0gZ2ljX3NjOwogCXVpbnRwdHJfdCBpcnEgPSAodWlu dHB0cl90KSBhcmc7CiAKLQlpZiAoaXJxID4gR0lDX0xBU1RfSVBJKQorCWlmIChpcnEgPiBHSUNf TEFTVF9TR0kpCiAJCWFybV9pcnFfbWVtb3J5X2JhcnJpZXIoaXJxKTsKIAlnaWNfY193cml0ZV80 KHNjLCBHSUNDX0VPSVIsIGlycSk7CiB9CkBAIC00NjMsNyArOTY2LDcgQEAKIGdpY19jb25maWdf aXJxKGludCBpcnEsIGVudW0gaW50cl90cmlnZ2VyIHRyaWcsIGVudW0gaW50cl9wb2xhcml0eSBw b2wpCiB7CiAKLQlyZXR1cm4gKGFybV9naWNfY29uZmlnKGFybV9naWNfc2MtPmdpY19kZXYsIGly cSwgdHJpZywgcG9sKSk7CisJcmV0dXJuIChhcm1fZ2ljX2NvbmZpZyhnaWNfc2MtPmdpY19kZXYs IGlycSwgdHJpZywgcG9sKSk7CiB9CiAKIHZvaWQKQEAgLTQ3MCw3ICs5NzMsNyBAQAogYXJtX21h c2tfaXJxKHVpbnRwdHJfdCBuYikKIHsKIAotCWFybV9naWNfbWFzayhhcm1fZ2ljX3NjLT5naWNf ZGV2LCBuYik7CisJYXJtX2dpY19tYXNrKGdpY19zYy0+Z2ljX2RldiwgbmIpOwogfQogCiB2b2lk CkBAIC00NzcsNyArOTgwLDcgQEAKIGFybV91bm1hc2tfaXJxKHVpbnRwdHJfdCBuYikKIHsKIAot CWFybV9naWNfdW5tYXNrKGFybV9naWNfc2MtPmdpY19kZXYsIG5iKTsKKwlhcm1fZ2ljX3VubWFz ayhnaWNfc2MtPmdpY19kZXYsIG5iKTsKIH0KIAogaW50CkBAIC00ODQsNyArOTg3LDcgQEAKIGFy bV9nZXRfbmV4dF9pcnEoaW50IGxhc3RfaXJxKQogewogCi0JcmV0dXJuIChhcm1fZ2ljX25leHRf aXJxKGFybV9naWNfc2MsIGxhc3RfaXJxKSk7CisJcmV0dXJuIChhcm1fZ2ljX25leHRfaXJxKGdp Y19zYywgbGFzdF9pcnEpKTsKIH0KIAogdm9pZApAQCAtNDkxLDcgKzk5NCw3IEBACiBhcm1faW5p dF9zZWNvbmRhcnlfaWModm9pZCkKIHsKIAotCWFybV9naWNfaW5pdF9zZWNvbmRhcnkoYXJtX2dp Y19zYy0+Z2ljX2Rldik7CisJYXJtX2dpY19pbml0X3NlY29uZGFyeShnaWNfc2MtPmdpY19kZXYp OwogfQogCiAjaWZkZWYgU01QCkBAIC00OTksNyArMTAwMiw3IEBACiBwaWNfaXBpX3NlbmQoY3B1 c2V0X3QgY3B1cywgdV9pbnQgaXBpKQogewogCi0JYXJtX2dpY19pcGlfc2VuZChhcm1fZ2ljX3Nj LT5naWNfZGV2LCBjcHVzLCBpcGkpOworCWFybV9naWNfaXBpX3NlbmQoZ2ljX3NjLT5naWNfZGV2 LCBjcHVzLCBpcGkpOwogfQogCiBpbnQKQEAgLTUwNiw3ICsxMDA5LDcgQEAKIHBpY19pcGlfcmVh ZChpbnQgaSkKIHsKIAotCXJldHVybiAoYXJtX2dpY19pcGlfcmVhZChhcm1fZ2ljX3NjLT5naWNf ZGV2LCBpKSk7CisJcmV0dXJuIChhcm1fZ2ljX2lwaV9yZWFkKGdpY19zYy0+Z2ljX2RldiwgaSkp OwogfQogCiB2b2lkCkBAIC01MTMsMTQgKzEwMTYsMzQgQEAKIHBpY19pcGlfY2xlYXIoaW50IGlw aSkKIHsKIAotCWFybV9naWNfaXBpX2NsZWFyKGFybV9naWNfc2MtPmdpY19kZXYsIGlwaSk7CisJ YXJtX2dpY19pcGlfY2xlYXIoZ2ljX3NjLT5naWNfZGV2LCBpcGkpOwogfQogI2VuZGlmCisjZW5k aWYgLyogQVJNX0lOVFJORyAqLwogCiBzdGF0aWMgZGV2aWNlX21ldGhvZF90IGFybV9naWNfbWV0 aG9kc1tdID0gewogCS8qIERldmljZSBpbnRlcmZhY2UgKi8KIAlERVZNRVRIT0QoZGV2aWNlX3By b2JlLAkJYXJtX2dpY19wcm9iZSksCiAJREVWTUVUSE9EKGRldmljZV9hdHRhY2gsCWFybV9naWNf YXR0YWNoKSwKKyNpZmRlZiBBUk1fSU5UUk5HCisJLyogSW50ZXJydXB0IGNvbnRyb2xsZXIgaW50 ZXJmYWNlICovCisJREVWTUVUSE9EKHBpY19tYXAsCQlhcm1fZ2ljX21hcCksCisjaWZkZWYgRkRU CisJREVWTUVUSE9EKHBpY19tYXBfZmR0LAkJYXJtX2dpY19tYXBfZmR0KSwKKyNlbmRpZgorCURF Vk1FVEhPRChwaWNfdW5tYXAsCQlhcm1fZ2ljX3VubWFwKSwKKwlERVZNRVRIT0QocGljX2JpbmQs CQlhcm1fZ2ljX2JpbmQpLAorCURFVk1FVEhPRChwaWNfY29uZmlnLAkJYXJtX2dpY19jb25maWcp LAorCURFVk1FVEhPRChwaWNfZGlzYWJsZSwJCWFybV9naWNfZGlzYWJsZSksCisJREVWTUVUSE9E KHBpY19lbmFibGUsCQlhcm1fZ2ljX2VuYWJsZSksCisJREVWTUVUSE9EKHBpY19wcmVfaXRocmVh ZCwJYXJtX2dpY19wcmVfaXRocmVhZCksCisJREVWTUVUSE9EKHBpY19wb3N0X2l0aHJlYWQsCWFy bV9naWNfcG9zdF9pdGhyZWFkKSwKKwlERVZNRVRIT0QocGljX3Bvc3RfZmlsdGVyLAlhcm1fZ2lj X3Bvc3RfZmlsdGVyKSwKKyNpZmRlZiBTTVAKKwlERVZNRVRIT0QocGljX2luaXRfc2Vjb25kYXJ5 LAlhcm1fZ2ljX2luaXRfc2Vjb25kYXJ5KSwKKwlERVZNRVRIT0QocGljX2lwaV9zZW5kLAkJYXJt X2dpY19pcGlfc2VuZCksCisjZW5kaWYKKyNlbmRpZgogCXsgMCwgMCB9CiB9OwogCkluZGV4OiBz eXMvYXJtL2FybS9tcF9tYWNoZGVwLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2FybS9hcm0vbXBfbWFj aGRlcC5jCShyZXZpc2lvbiAyNzcyMTApCisrKyBzeXMvYXJtL2FybS9tcF9tYWNoZGVwLmMJKHdv cmtpbmcgY29weSkKQEAgLTczLDcgKzczLDkgQEAKIC8qIFNldCB0byAxIG9uY2Ugd2UncmUgcmVh ZHkgdG8gbGV0IHRoZSBBUHMgb3V0IG9mIHRoZSBwZW4uICovCiB2b2xhdGlsZSBpbnQgYXBzX3Jl YWR5ID0gMDsKIAorI2lmbmRlZiBBUk1fSU5UUk5HCiBzdGF0aWMgaW50IGlwaV9oYW5kbGVyKHZv aWQgKmFyZyk7CisjZW5kaWYKIHZvaWQgc2V0X3N0YWNrcHRycyhpbnQgY3B1KTsKIAogLyogVGVt cG9yYXJ5IHZhcmlhYmxlcyBmb3IgaW5pdF9zZWNvbmRhcnkoKSAgKi8KQEAgLTE0OSw3ICsxNTEs NiBAQAogewogCXN0cnVjdCBwY3B1ICpwYzsKIAl1aW50MzJfdCBsb29wX2NvdW50ZXI7Ci0JaW50 IHN0YXJ0ID0gMCwgZW5kID0gMDsKIAogCWNwdV9zZXR1cChOVUxMKTsKIAlzZXR0dGIocG1hcF9w YSk7CkBAIC0xOTksMTggKzIwMCw2IEBACiAKIAltdHhfdW5sb2NrX3NwaW4oJmFwX2Jvb3RfbXR4 KTsKIAotCS8qIEVuYWJsZSBpcGkgKi8KLSNpZmRlZiBJUElfSVJRX1NUQVJUCi0Jc3RhcnQgPSBJ UElfSVJRX1NUQVJUOwotI2lmZGVmIElQSV9JUlFfRU5ECi0gIAllbmQgPSBJUElfSVJRX0VORDsK LSNlbHNlCi0JZW5kID0gSVBJX0lSUV9TVEFSVDsKLSNlbmRpZgotI2VuZGlmCi0JCQkJCi0JZm9y IChpbnQgaSA9IHN0YXJ0OyBpIDw9IGVuZDsgaSsrKQotCQlhcm1fdW5tYXNrX2lycShpKTsKIAll bmFibGVfaW50ZXJydXB0cyhQU1JfSSk7CiAKIAlsb29wX2NvdW50ZXIgPSAwOwpAQCAtMjMzLDYg KzIyMiwxMDggQEAKIAkvKiBOT1RSRUFDSEVEICovCiB9CiAKKyNpZmRlZiBBUk1fSU5UUk5HCitz dGF0aWMgdm9pZAoraXBpX3JlbmRlenZvdXModm9pZCAqZHVtbXkgX191bnVzZWQpCit7CisKKwlD VFIwKEtUUl9TTVAsICJJUElfUkVOREVaVk9VUyIpOworCXNtcF9yZW5kZXp2b3VzX2FjdGlvbigp OworfQorCitzdGF0aWMgdm9pZAoraXBpX2FzdCh2b2lkICpkdW1teSBfX3VudXNlZCkKK3sKKwor CUNUUjAoS1RSX1NNUCwgIklQSV9BU1QiKTsKK30KKworc3RhdGljIHZvaWQKK2lwaV9zdG9wKHZv aWQgKmR1bW15IF9fdW51c2VkKQoreworCXVfaW50IGNwdTsKKworCS8qCisJICogSVBJX1NUT1Bf SEFSRCBpcyBtYXBwZWQgdG8gSVBJX1NUT1AuCisJICovCisJQ1RSMChLVFJfU01QLCAiSVBJX1NU T1Agb3IgSVBJX1NUT1BfSEFSRCIpOworCisJY3B1ID0gUENQVV9HRVQoY3B1aWQpOworCXNhdmVj dHgoJnN0b3BwY2JzW2NwdV0pOworCisJLyoKKwkgKiBDUFVzIGFyZSBzdG9wcGVkIHdoZW4gZW50 ZXJpbmcgdGhlIGRlYnVnZ2VyIGFuZCBhdAorCSAqIHN5c3RlbSBzaHV0ZG93biwgYm90aCBldmVu dHMgd2hpY2ggY2FuIHByZWNlZGUgYQorCSAqIHBhbmljIGR1bXAuICBGb3IgdGhlIGR1bXAgdG8g YmUgY29ycmVjdCwgYWxsIGNhY2hlcworCSAqIG11c3QgYmUgZmx1c2hlZCBhbmQgaW52YWxpZGF0 ZWQsIGJ1dCBvbiBBUk0gdGhlcmUncworCSAqIG5vIHdheSB0byBicm9hZGNhc3QgYSB3Ymludl9h bGwgdG8gb3RoZXIgY29yZXMuCisJICogSW5zdGVhZCwgd2UgaGF2ZSBlYWNoIGNvcmUgZG8gdGhl IGxvY2FsIHdiaW52X2FsbCBhcworCSAqIHBhcnQgb2Ygc3RvcHBpbmcgdGhlIGNvcmUuICBUaGUg Y29yZSByZXF1ZXN0aW5nIHRoZQorCSAqIHN0b3Agd2lsbCBkbyB0aGUgbDIgY2FjaGUgZmx1c2gg YWZ0ZXIgYWxsIG90aGVyIGNvcmVzCisJICogaGF2ZSBkb25lIHRoZWlyIGwxIGZsdXNoZXMgYW5k IHN0b3BwZWQuCisJICovCisJY3B1X2lkY2FjaGVfd2JpbnZfYWxsKCk7CisKKwkvKiBJbmRpY2F0 ZSB3ZSBhcmUgc3RvcHBlZCAqLworCUNQVV9TRVRfQVRPTUlDKGNwdSwgJnN0b3BwZWRfY3B1cyk7 CisKKwkvKiBXYWl0IGZvciByZXN0YXJ0ICovCisJd2hpbGUgKCFDUFVfSVNTRVQoY3B1LCAmc3Rh cnRlZF9jcHVzKSkKKwkJY3B1X3NwaW53YWl0KCk7CisKKwlDUFVfQ0xSX0FUT01JQyhjcHUsICZz dGFydGVkX2NwdXMpOworCUNQVV9DTFJfQVRPTUlDKGNwdSwgJnN0b3BwZWRfY3B1cyk7CisJQ1RS MChLVFJfU01QLCAiSVBJX1NUT1AgKHJlc3RhcnQpIik7Cit9CisKK3N0YXRpYyB2b2lkCitpcGlf cHJlZW1wdCh2b2lkICphcmcpCit7CisJc3RydWN0IHRyYXBmcmFtZSAqb2xkZnJhbWU7CisJc3Ry dWN0IHRocmVhZCAqdGQ7CisKKwljcml0aWNhbF9lbnRlcigpOworCXRkID0gY3VydGhyZWFkOwor CXRkLT50ZF9pbnRyX25lc3RpbmdfbGV2ZWwrKzsKKwlvbGRmcmFtZSA9IHRkLT50ZF9pbnRyX2Zy YW1lOworCXRkLT50ZF9pbnRyX2ZyYW1lID0gKHN0cnVjdCB0cmFwZnJhbWUgKilhcmc7CisKKwlD VFIxKEtUUl9TTVAsICIlczogSVBJX1BSRUVNUFQiLCBfX2Z1bmNfXyk7CisJc2NoZWRfcHJlZW1w dCh0ZCk7CisKKwl0ZC0+dGRfaW50cl9mcmFtZSA9IG9sZGZyYW1lOworCXRkLT50ZF9pbnRyX25l c3RpbmdfbGV2ZWwtLTsKKwljcml0aWNhbF9leGl0KCk7Cit9CisKK3N0YXRpYyB2b2lkCitpcGlf aGFyZGNsb2NrKHZvaWQgKmFyZykKK3sKKwlzdHJ1Y3QgdHJhcGZyYW1lICpvbGRmcmFtZTsKKwlz dHJ1Y3QgdGhyZWFkICp0ZDsKKworCWNyaXRpY2FsX2VudGVyKCk7CisJdGQgPSBjdXJ0aHJlYWQ7 CisJdGQtPnRkX2ludHJfbmVzdGluZ19sZXZlbCsrOworCW9sZGZyYW1lID0gdGQtPnRkX2ludHJf ZnJhbWU7CisJdGQtPnRkX2ludHJfZnJhbWUgPSAoc3RydWN0IHRyYXBmcmFtZSAqKWFyZzsKKwor CUNUUjEoS1RSX1NNUCwgIiVzOiBJUElfSEFSRENMT0NLIiwgX19mdW5jX18pOworCWhhcmRjbG9j a2ludHIoKTsKKworCXRkLT50ZF9pbnRyX2ZyYW1lID0gb2xkZnJhbWU7CisJdGQtPnRkX2ludHJf bmVzdGluZ19sZXZlbC0tOworCWNyaXRpY2FsX2V4aXQoKTsKK30KKworc3RhdGljIHZvaWQKK2lw aV90bGIodm9pZCAqZHVtbXkgX191bnVzZWQpCit7CisKKwlDVFIxKEtUUl9TTVAsICIlczogSVBJ X1RMQiIsIF9fZnVuY19fKTsKKwljcHVmdW5jcy5jZl90bGJfZmx1c2hJRCgpOworfQorI2Vsc2UK IHN0YXRpYyBpbnQKIGlwaV9oYW5kbGVyKHZvaWQgKmFyZykKIHsKQEAgLTMwOCwxNSArMzk5LDI4 IEBACiAKIAlyZXR1cm4gKEZJTFRFUl9IQU5ETEVEKTsKIH0KKyNlbmRpZgogCiBzdGF0aWMgdm9p ZAogcmVsZWFzZV9hcHModm9pZCAqZHVtbXkgX191bnVzZWQpCiB7CiAJdWludDMyX3QgbG9vcF9j b3VudGVyOworI2lmbmRlZiBBUk1fSU5UUk5HCiAJaW50IHN0YXJ0ID0gMCwgZW5kID0gMDsKKyNl bmRpZgogCiAJaWYgKG1wX25jcHVzID09IDEpCiAJCXJldHVybjsKKworI2lmZGVmIEFSTV9JTlRS TkcKKwlhcm1fc2V0dXBfaXBpaGFuZGxlcihJUElfUkVOREVaVk9VUywgTlVMTCwgaXBpX3JlbmRl enZvdXMsIE5VTEwsIDApOworCWFybV9zZXR1cF9pcGloYW5kbGVyKElQSV9BU1QsIE5VTEwsIGlw aV9hc3QsIE5VTEwsIDApOworCWFybV9zZXR1cF9pcGloYW5kbGVyKElQSV9TVE9QLCBOVUxMLCBp cGlfc3RvcCwgTlVMTCwgMCk7CisJYXJtX3NldHVwX2lwaWhhbmRsZXIoSVBJX1BSRUVNUFQsIE5V TEwsIGlwaV9wcmVlbXB0LCBOVUxMLCAwKTsKKwlhcm1fc2V0dXBfaXBpaGFuZGxlcihJUElfSEFS RENMT0NLLCBOVUxMLCBpcGlfaGFyZGNsb2NrLCBOVUxMLCAwKTsKKwlhcm1fc2V0dXBfaXBpaGFu ZGxlcihJUElfVExCLCBOVUxMLCBpcGlfdGxiLCBOVUxMLCAwKTsKKworI2Vsc2UKICNpZmRlZiBJ UElfSVJRX1NUQVJUCiAJc3RhcnQgPSBJUElfSVJRX1NUQVJUOwogI2lmZGVmIElQSV9JUlFfRU5E CkBAIC0zNDEsNiArNDQ1LDcgQEAKIAkJLyogRW5hYmxlIGlwaSAqLwogCQlhcm1fdW5tYXNrX2ly cShpKTsKIAl9CisjZW5kaWYKIAlhdG9taWNfc3RvcmVfcmVsX2ludCgmYXBzX3JlYWR5LCAxKTsK IAogCXByaW50ZigiUmVsZWFzZSBBUHNcbiIpOwpJbmRleDogc3lzL2FybS9hcm0vbmV4dXMuYwo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09Ci0tLSBzeXMvYXJtL2FybS9uZXh1cy5jCShyZXZpc2lvbiAyNzcyMTApCisrKyBz eXMvYXJtL2FybS9uZXh1cy5jCSh3b3JraW5nIGNvcHkpCkBAIC0yNTEsOSArMjUxLDEyIEBACiB7 CiAJaW50IHJldCA9IEVOT0RFVjsKIAorI2lmZGVmIEFSTV9JTlRSTkcKKwlyZXQgPSBhcm1faW50 cm5nX2NvbmZpZ19pcnEoaXJxLCB0cmlnLCBwb2wpOworI2Vsc2UKIAlpZiAoYXJtX2NvbmZpZ19p cnEpCiAJCXJldCA9ICgqYXJtX2NvbmZpZ19pcnEpKGlycSwgdHJpZywgcG9sKTsKLQorI2VuZGlm CiAJcmV0dXJuIChyZXQpOwogfQogCkBAIC0yNjcsOSArMjcwLDE0IEBACiAJCWZsYWdzIHw9IElO VFJfRVhDTDsKIAogCWZvciAoaXJxID0gcm1hbl9nZXRfc3RhcnQocmVzKTsgaXJxIDw9IHJtYW5f Z2V0X2VuZChyZXMpOyBpcnErKykgeworI2lmIGRlZmluZWQoQVJNX0lOVFJORykKKwkJYXJtX3Nl dHVwX2lycWhhbmRsZXIoY2hpbGQsIGZpbHQsIGludHIsIGFyZywgaXJxLCBmbGFncywKKwkJICAg IGNvb2tpZXApOworI2Vsc2UKIAkJYXJtX3NldHVwX2lycWhhbmRsZXIoZGV2aWNlX2dldF9uYW1l dW5pdChjaGlsZCksCiAJCSAgICBmaWx0LCBpbnRyLCBhcmcsIGlycSwgZmxhZ3MsIGNvb2tpZXAp OwogCQlhcm1fdW5tYXNrX2lycShpcnEpOworI2VuZGlmCiAJfQogCXJldHVybiAoMCk7CiB9CkBA IC0yNzgsNyArMjg2LDExIEBACiBuZXh1c190ZWFyZG93bl9pbnRyKGRldmljZV90IGRldiwgZGV2 aWNlX3QgY2hpbGQsIHN0cnVjdCByZXNvdXJjZSAqciwgdm9pZCAqaWgpCiB7CiAKKyNpZiBkZWZp bmVkKEFSTV9JTlRSTkcpCisJcmV0dXJuIChhcm1fcmVtb3ZlX2lycWhhbmRsZXIoY2hpbGQsIHJt YW5fZ2V0X3N0YXJ0KHIpLCBpaCkpOworI2Vsc2UKIAlyZXR1cm4gKGFybV9yZW1vdmVfaXJxaGFu ZGxlcihybWFuX2dldF9zdGFydChyKSwgaWgpKTsKKyNlbmRpZgogfQogCiAKSW5kZXg6IHN5cy9h cm0vaW5jbHVkZS9mZHQuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvYXJtL2luY2x1ZGUvZmR0LmgJKHJl dmlzaW9uIDI3NzIxMCkKKysrIHN5cy9hcm0vaW5jbHVkZS9mZHQuaAkod29ya2luZyBjb3B5KQpA QCAtMzIsNiArMzIsNyBAQAogI2lmbmRlZiBfTUFDSElORV9GRFRfSF8KICNkZWZpbmUgX01BQ0hJ TkVfRkRUX0hfCiAKKyNpbmNsdWRlICJvcHRfcGxhdGZvcm0uaCIKICNpbmNsdWRlIDxkZXYvb2Z3 L29wZW5maXJtLmg+CiAKICNpbmNsdWRlIDx2bS92bS5oPgpAQCAtNDAsMTIgKzQxLDI1IEBACiAj aW5jbHVkZSA8bWFjaGluZS9idXMuaD4KICNpbmNsdWRlIDxtYWNoaW5lL2ludHIuaD4KIAorI2lm ZGVmIEFSTV9JTlRSTkcKKwogLyogTWF4IGludGVycnVwdCBudW1iZXIgKi8KKyNkZWZpbmUJRkRU X0lOVFJfTUFYCSgweGZmZmYpCisKKy8qIE1hcCBwaGFuZGxlL2ludHBpbiBwYWlyIHRvIGdsb2Jh bCBJUlEgbnVtYmVyICovCisjZGVmaW5lCUZEVF9NQVBfSVJRKG5vZGUsIHBpbikJKGFybV9mZHRf bWFwX2lycShub2RlLCBwaW4pKQorI2RlZmluZQlGRFRfREVTQ1JJQkVfSVJRKGlycSkJKGFybV9k ZXNjcmliZV9pcnEoaXJxKSkKKworI2Vsc2UKKworLyogTWF4IGludGVycnVwdCBudW1iZXIgKi8K ICNkZWZpbmUgRkRUX0lOVFJfTUFYCU5JUlEKIAogLyogTWFwIHBoYW5kbGUvaW50cGluIHBhaXIg dG8gZ2xvYmFsIElSUSBudW1iZXIgKi8KICNkZWZpbmUJRkRUX01BUF9JUlEobm9kZSwgcGluKQko cGluKQogCisjZW5kaWYgLyogQVJNX0lOVFJORyAqLworCiAvKgogICogQnVzIHNwYWNlIHRhZy4g WFhYIGVuZGlhbmVzcyBpbmZvIG5lZWRzIHRvIGJlIGRlcml2ZWQgZnJvbSB0aGUgYmxvYi4KICAq LwpJbmRleDogc3lzL2FybS9pbmNsdWRlL2ludHIuaAo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvYXJtL2lu Y2x1ZGUvaW50ci5oCShyZXZpc2lvbiAyNzcyMTApCisrKyBzeXMvYXJtL2luY2x1ZGUvaW50ci5o CSh3b3JraW5nIGNvcHkpCkBAIC00Myw2ICs0Myw2OCBAQAogI2luY2x1ZGUgPGRldi9vZncvb3Bl bmZpcm0uaD4KICNlbmRpZgogCisjaWZkZWYgQVJNX0lOVFJORworCisjaWZuZGVmIE5JUlEKKyNk ZWZpbmUJTklSUQkJMTAyNAkvKiBYWFggLSBJdCBzaG91bGQgYmUgYW4gb3B0aW9uLiAqLworI2Vu ZGlmCisKKyNkZWZpbmUJSU5UUl9TT0xPCUlOVFJfTUQxCisKK3N0cnVjdCBhcm1faXJxc3JjOwor dHlwZWRlZiBpbnQgYXJtX2lycV9maWx0ZXJfdCh2b2lkICphcmcsIHN0cnVjdCB0cmFwZnJhbWUg KnRmKTsKKworI2RlZmluZSBJU1JDVF9OT05FCTAKKyNkZWZpbmUgSVNSQ1RfU1BJCTEKKyNkZWZp bmUgSVNSQ1RfUFBJCTIKKyNkZWZpbmUgSVNSQ1RfU0dJCTMKKworI2RlZmluZSBJU1JDRl9OQU1F U1BBQ0UJMHgwMDAxCisjZGVmaW5lIElTUkNGX0ZEVAkweDAwMDIKKyNkZWZpbmUgSVNSQ0ZfTUFQ UEVECTB4MDAwNAorCit2b2lkIGFybV9kaXNwYXRjaF9zcGkoc3RydWN0IGFybV9pcnFzcmMgKmlz cmMsIHN0cnVjdCB0cmFwZnJhbWUgKnRmKTsKKyNkZWZpbmUgYXJtX2Rpc3BhdGNoX3BwaQlhcm1f ZGlzcGF0Y2hfc3BpCisKK3VfaW50IGFybV9uYW1lc3BhY2VfbWFwX2lycShkZXZpY2VfdCBkZXYs IHVpbnQ4X3QgdHlwZSwgdWludDE2X3QgbnVtKTsKKwordm9pZCogYXJtX2lycV9nZXRfZGF0YShz dHJ1Y3QgYXJtX2lycXNyYyAqaXNyYyk7Cit2b2lkIGFybV9pcnFfc2V0X2RhdGEoc3RydWN0IGFy bV9pcnFzcmMgKmlzcmMsIHZvaWQgKmRhdGEpOwordm9pZCBhcm1faXJxX3NldF9uYW1lKHN0cnVj dCBhcm1faXJxc3JjICppc3JjLCBjb25zdCBjaGFyICpuYW1lKTsKK3ZvaWQgYXJtX2lycV9zZXRf bmFtZXNwYWNlKHN0cnVjdCBhcm1faXJxc3JjICppc3JjLCB1aW50OF90IHR5cGUsIHVpbnQxNl90 IG51bSk7CisKK2ludCBhcm1faXJxX3NldF9yb290KGRldmljZV90IGRldiwgYXJtX2lycV9maWx0 ZXJfdCAqZmlsdGVyLCB2b2lkICphcmcsCisgICAgdV9pbnQgaXBpY291bnQpOworCitpbnQgYXJt X3JlZ2lzdGVyX3BpYyhkZXZpY2VfdCBkZXYpOworaW50IGFybV91bnJlZ2lzdGVyX3BpYyhkZXZp Y2VfdCBkZXYpOworCitpbnQgYXJtX3NldHVwX2lycWhhbmRsZXIoZGV2aWNlX3QgZGV2LCBkcml2 ZXJfZmlsdGVyX3QsIGRyaXZlcl9pbnRyX3QsIHZvaWQgKiwKKyAgICB1X2ludCwgaW50LCB2b2lk ICoqKTsKK2ludCBhcm1fcmVtb3ZlX2lycWhhbmRsZXIoZGV2aWNlX3QgZGV2LCB1X2ludCwgdm9p ZCAqKTsKK2ludCBhcm1faW50cm5nX2NvbmZpZ19pcnEodV9pbnQsIGVudW0gaW50cl90cmlnZ2Vy LCBlbnVtIGludHJfcG9sYXJpdHkpOworCitjb25zdCBjaGFyICphcm1fZGVzY3JpYmVfaXJxKHVf aW50IGlycSk7CisKKyNpZmRlZiBGRFQKK3VfaW50IGFybV9mZHRfbWFwX2lycShwaGFuZGxlX3Qs IHBjZWxsX3QgKiwgdV9pbnQpOworI2VuZGlmCisKKyNpZmRlZiBTTVAKK3R5cGVkZWYgdm9pZCBh cm1faXBpX2ZpbHRlcl90KHZvaWQgKik7CisKK3ZvaWQgYXJtX2Rpc3BhdGNoX3NnaShzdHJ1Y3Qg YXJtX2lycXNyYyAqaXNyYywgc3RydWN0IHRyYXBmcmFtZSAqdGYpOworCisjZGVmaW5lIEFTSUZf Tk9BTExPQwkweDAwMDEKKworaW50IGFybV9zZXR1cF9pcGloYW5kbGVyKHVfaW50IGlwaSwgY2hh ciAqbmFtZSwgYXJtX2lwaV9maWx0ZXJfdCAqZmlsdGVyLAorICAgIHZvaWQgKmFyZywgdV9pbnQg ZmxhZ3MpOworCit2b2lkIGFybV9pbml0X3NlY29uZGFyeV9waWModm9pZCk7CisjZW5kaWYKKwor I2Vsc2UgLyogQVJNX0lOVFJORyAqLworCiAvKiBYWFggbW92ZSB0byBzdGQuKiBmaWxlcz8gKi8K ICNpZmRlZiBDUFVfWFNDQUxFXzgxMzQyCiAjZGVmaW5lIE5JUlEJCTEyOApAQCAtNzEsNyArMTMz LDYgQEAKICNkZWZpbmUgTklSUQkJMzIKICNlbmRpZgogCi0KIGludCBhcm1fZ2V0X25leHRfaXJx KGludCk7CiB2b2lkIGFybV9tYXNrX2lycSh1aW50cHRyX3QpOwogdm9pZCBhcm1fdW5tYXNrX2ly cSh1aW50cHRyX3QpOwpAQCAtODMsOCArMTQ0LDYgQEAKIGV4dGVybiBpbnQgKCphcm1fY29uZmln X2lycSkoaW50IGlycSwgZW51bSBpbnRyX3RyaWdnZXIgdHJpZywKICAgICBlbnVtIGludHJfcG9s YXJpdHkgcG9sKTsKIAotdm9pZCBhcm1faXJxX21lbW9yeV9iYXJyaWVyKHVpbnRwdHJfdCk7Ci0K IHZvaWQgYXJtX2luaXRfc2Vjb25kYXJ5X2ljKHZvaWQpOwogaW50ICBnaWNfZGVjb2RlX2ZkdCh1 aW50MzJfdCBpcGFyZW50bm9kZSwgdWludDMyX3QgKmludHJjZWxscywgaW50ICppbnRlcnJ1cHQs CiAgICAgaW50ICp0cmlnLCBpbnQgKnBvbCk7CkBAIC05Myw0ICsxNTIsOCBAQAogaW50IGFybV9m ZHRfbWFwX2lycShwaGFuZGxlX3QsIHBjZWxsX3QgKiwgaW50KTsKICNlbmRpZgogCisjZW5kaWYg LyogQVJNX0lOVFJORyAqLworCit2b2lkIGFybV9pcnFfbWVtb3J5X2JhcnJpZXIodWludHB0cl90 KTsKKwogI2VuZGlmCS8qIF9NQUNISU5FX0lOVFJfSCAqLwpJbmRleDogc3lzL2FybS9pbmNsdWRl L3NtcC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9hcm0vaW5jbHVkZS9zbXAuaAkocmV2aXNpb24gMjc3 MjEwKQorKysgc3lzL2FybS9pbmNsdWRlL3NtcC5oCSh3b3JraW5nIGNvcHkpCkBAIC02LDYgKzYs MTggQEAKICNpbmNsdWRlIDxzeXMvX2NwdXNldC5oPgogI2luY2x1ZGUgPG1hY2hpbmUvcGNiLmg+ CiAKKyNpZmRlZiBBUk1fSU5UUk5HCitlbnVtIHsKKwlJUElfQVNULAorCUlQSV9QUkVFTVBULAor CUlQSV9SRU5ERVpWT1VTLAorCUlQSV9TVE9QLAorCUlQSV9TVE9QX0hBUkQgPSBJUElfU1RPUCwg LyogVGhlc2UgYXJlIHN5bm9ueW1zIG9uIGFybS4gKi8KKwlJUElfSEFSRENMT0NLLAorCUlQSV9U TEIsCisJQVJNX0lQSV9DT1VOVAorfTsKKyNlbHNlCiAjZGVmaW5lIElQSV9BU1QJCTAKICNkZWZp bmUgSVBJX1BSRUVNUFQJMgogI2RlZmluZSBJUElfUkVOREVaVk9VUwkzCkBAIC0xMyw2ICsyNSw3 IEBACiAjZGVmaW5lIElQSV9TVE9QX0hBUkQJNAogI2RlZmluZSBJUElfSEFSRENMT0NLCTYKICNk ZWZpbmUgSVBJX1RMQgkJNworI2VuZGlmCiAKIHZvaWQJaW5pdF9zZWNvbmRhcnkoaW50IGNwdSk7 CiB2b2lkCW1wZW50cnkodm9pZCk7CkBAIC0yMyw4ICszNiwxMCBAQAogCiAvKiBQSUMgaW50ZXJm YWNlICovCiB2b2lkCXBpY19pcGlfc2VuZChjcHVzZXRfdCBjcHVzLCB1X2ludCBpcGkpOworI2lm bmRlZiBBUk1fSU5UUk5HCiB2b2lkCXBpY19pcGlfY2xlYXIoaW50IGlwaSk7CiBpbnQJcGljX2lw aV9yZWFkKGludCBhcmcpOworI2VuZGlmCiAKIC8qIFBsYXRmb3JtIGludGVyZmFjZSAqLwogdm9p ZAlwbGF0Zm9ybV9tcF9zZXRtYXhpZCh2b2lkKTsKSW5kZXg6IHN5cy9hcm0vdGkvb21hcDQvb21h cDRfbXAuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvYXJtL3RpL29tYXA0L29tYXA0X21wLmMJKHJldmlz aW9uIDI3NzIxMCkKKysrIHN5cy9hcm0vdGkvb21hcDQvb21hcDRfbXAuYwkod29ya2luZyBjb3B5 KQpAQCAtNDEsNyArNDEsMTIgQEAKIHZvaWQKIHBsYXRmb3JtX21wX2luaXRfc2Vjb25kYXJ5KHZv aWQpCiB7CisKKyNpZmRlZiBBUk1fSU5UUk5HCisJYXJtX2luaXRfc2Vjb25kYXJ5X3BpYygpOwor I2Vsc2UKIAlhcm1faW5pdF9zZWNvbmRhcnlfaWMoKTsKKyNlbmRpZgogfQogCiB2b2lkCkluZGV4 OiBzeXMvY29uZi9maWxlcy5hcm0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2NvbmYvZmlsZXMuYXJtCShy ZXZpc2lvbiAyNzcyMTApCisrKyBzeXMvY29uZi9maWxlcy5hcm0JKHdvcmtpbmcgY29weSkKQEAg LTI5LDcgKzI5LDggQEAKIGFybS9hcm0vaWRlbnRjcHUuYwkJc3RhbmRhcmQKIGFybS9hcm0vaW5f Y2tzdW0uYwkJb3B0aW9uYWwJaW5ldCB8IGluZXQ2CiBhcm0vYXJtL2luX2Nrc3VtX2FybS5TCQlv cHRpb25hbAlpbmV0IHwgaW5ldDYKLWFybS9hcm0vaW50ci5jCQkJc3RhbmRhcmQKK2FybS9hcm0v aW50ci5jCQkJb3B0aW9uYWwJIWFybV9pbnRybmcKK2FybS9hcm0vaW50cm5nLmMJCW9wdGlvbmFs CWFybV9pbnRybmcKIGFybS9hcm0vbG9jb3JlLlMJCXN0YW5kYXJkCW5vLW9iagogYXJtL2FybS9t YWNoZGVwLmMJCXN0YW5kYXJkCiBhcm0vYXJtL21lbS5jCQkJb3B0aW9uYWwJbWVtCkBAIC0zNyw2 ICszOCw3IEBACiBhcm0vYXJtL21wX21hY2hkZXAuYwkJb3B0aW9uYWwJc21wCiBhcm0vYXJtL25l eHVzLmMJCQlzdGFuZGFyZAogYXJtL2FybS9waHlzbWVtLmMJCXN0YW5kYXJkCithcm0vYXJtL3Bp Y19pZi5tCQlvcHRpb25hbAlhcm1faW50cm5nCiBhcm0vYXJtL3BsMTkwLmMJCQlvcHRpb25hbAlw bDE5MAogYXJtL2FybS9wbDMxMC5jCQkJb3B0aW9uYWwJcGwzMTAKIGFybS9hcm0vcGxhdGZvcm0u YwkJb3B0aW9uYWwJcGxhdGZvcm0KSW5kZXg6IHN5cy9jb25mL29wdGlvbnMuYXJtCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KLS0tIHN5cy9jb25mL29wdGlvbnMuYXJtCShyZXZpc2lvbiAyNzcyMTApCisrKyBzeXMvY29u Zi9vcHRpb25zLmFybQkod29ya2luZyBjb3B5KQpAQCAtMiw2ICsyLDcgQEAKIEFSTTlfQ0FDSEVf V1JJVEVfVEhST1VHSAlvcHRfZ2xvYmFsLmgKIEFSTVY2CQkJb3B0X2dsb2JhbC5oCiBBUk1fQ0FD SEVfTE9DS19FTkFCTEUJb3B0X2dsb2JhbC5oCitBUk1fSU5UUk5HCQlvcHRfZ2xvYmFsLmgKIEFS TV9LRVJOX0RJUkVDVE1BUAlvcHRfdm0uaAogQVJNX0wyX1BJUFQJCW9wdF9nbG9iYWwuaAogQVJN X01BTllfQk9BUkQJCW9wdF9nbG9iYWwuaApJbmRleDogc3lzL2Rldi9mZHQvc2ltcGxlYnVzLmMK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gc3lzL2Rldi9mZHQvc2ltcGxlYnVzLmMJKHJldmlzaW9uIDI3NzIxMCkK KysrIHN5cy9kZXYvZmR0L3NpbXBsZWJ1cy5jCSh3b3JraW5nIGNvcHkpCkBAIC0zOCw2ICszOCw4 IEBACiAjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzLmg+CiAjaW5jbHVkZSA8ZGV2L29mdy9vZndf YnVzX3N1YnIuaD4KIAorI2luY2x1ZGUgPG1hY2hpbmUvZmR0Lmg+CisKIHN0cnVjdCBzaW1wbGVi dXNfcmFuZ2UgewogCXVpbnQ2NF90IGJ1czsKIAl1aW50NjRfdCBob3N0OwpAQCAtNjgsNiArNzAs OSBAQAogICAgIGludCAqLCB1X2xvbmcsIHVfbG9uZywgdV9sb25nLCB1X2ludCk7CiBzdGF0aWMg dm9pZAkJc2ltcGxlYnVzX3Byb2JlX25vbWF0Y2goZGV2aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGls ZCk7CiBzdGF0aWMgaW50CQlzaW1wbGVidXNfcHJpbnRfY2hpbGQoZGV2aWNlX3QgYnVzLCBkZXZp Y2VfdCBjaGlsZCk7CisjaWZkZWYgQVJNX0lOVFJORworc3RhdGljIGludAkJc2ltcGxlYnVzX3By aW50X2lycXMoc3RydWN0IHJlc291cmNlX2xpc3QgKnJsKTsKKyNlbmRpZgogCiAvKgogICogb2Z3 X2J1cyBpbnRlcmZhY2UKQEAgLTM0NCw3ICszNDksMTEgQEAKIAogCXJ2ID0gMDsKIAlydiArPSBy ZXNvdXJjZV9saXN0X3ByaW50X3R5cGUoJmRpLT5ybCwgIm1lbSIsIFNZU19SRVNfTUVNT1JZLCAi JSNseCIpOworI2lmZGVmIEFSTV9JTlRSTkcKKwlydiArPSBzaW1wbGVidXNfcHJpbnRfaXJxcygm ZGktPnJsKTsKKyNlbHNlCiAJcnYgKz0gcmVzb3VyY2VfbGlzdF9wcmludF90eXBlKCZkaS0+cmws ICJpcnEiLCBTWVNfUkVTX0lSUSwgIiVsZCIpOworI2VuZGlmCiAJcmV0dXJuIChydik7CiB9CiAK QEAgLTM4MywzICszOTIsMjYgQEAKIAlydiArPSBidXNfcHJpbnRfY2hpbGRfZm9vdGVyKGJ1cywg Y2hpbGQpOwogCXJldHVybiAocnYpOwogfQorCisjaWZkZWYgQVJNX0lOVFJORworc3RhdGljIGlu dAorc2ltcGxlYnVzX3ByaW50X2lycXMoc3RydWN0IHJlc291cmNlX2xpc3QgKnJsKQoreworCXN0 cnVjdCByZXNvdXJjZV9saXN0X2VudHJ5ICpybGU7CisJaW50IHByaW50ZWQsIHJldHZhbDsKKwor CXByaW50ZWQgPSAwOworCXJldHZhbCA9IDA7CisKKwlTVEFJTFFfRk9SRUFDSChybGUsIHJsLCBs aW5rKSB7CisJCWlmIChybGUtPnR5cGUgIT0gU1lTX1JFU19JUlEpCisJCQljb250aW51ZTsKKwor CQlyZXR2YWwgKz0gcHJpbnRmKCIlcyIsIHByaW50ZWQgPyAiLCIgOiAiIGlycSAiKTsKKwkJcmV0 dmFsICs9IHByaW50ZigiJXMiLCBGRFRfREVTQ1JJQkVfSVJRKHJsZS0+c3RhcnQpKTsKKwkJcHJp bnRlZCsrOworCX0KKworCXJldHVybiAocmV0dmFsKTsKK30KKyNlbmRpZgo= --001a113ad13c76bebd050cb126db Content-Type: application/octet-stream; name="pic_if.m" Content-Disposition: attachment; filename="pic_if.m" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i4y6ugkb1 Iy0KIyBDb3B5cmlnaHQgKGMpIDIwMTIgSmFrdWIgV29qY2llY2ggS2xhbWEgPGpjZWVsQEZyZWVC U0Qub3JnPgojIEFsbCByaWdodHMgcmVzZXJ2ZWQuCiMKIyBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNl IGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKIyBtb2RpZmljYXRp b24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMK IyBhcmUgbWV0OgojIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFp biB0aGUgYWJvdmUgY29weXJpZ2h0CiMgICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9u cyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgojIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBi aW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CiMgICAgbm90aWNl LCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGlu IHRoZQojICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3 aXRoIHRoZSBkaXN0cmlidXRpb24uCiMKIyBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRI RSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECiMgQU5ZIEVYUFJFU1MgT1Ig SU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCiMg SU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQ QVJUSUNVTEFSIFBVUlBPU0UKIyBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRI RSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQojIEZPUiBBTlkgRElSRUNULCBJTkRJ UkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCiMg REFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNV QlNUSVRVVEUgR09PRFMKIyBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJ VFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKIyBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5Z IFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAojIExJQUJJ TElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5H IElOIEFOWSBXQVkKIyBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFE VklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCiMgU1VDSCBEQU1BR0UuCiMKIyAkRnJlZUJTRCQK IwoKI2luY2x1ZGUgIm9wdF9wbGF0Zm9ybS5oIgoKI2luY2x1ZGUgPHN5cy9idXMuaD4KI2luY2x1 ZGUgPHN5cy9jcHVzZXQuaD4KI2luY2x1ZGUgPGRldi9vZncvb3BlbmZpcm0uaD4KI2luY2x1ZGUg PG1hY2hpbmUvZnJhbWUuaD4KI2luY2x1ZGUgPG1hY2hpbmUvaW50ci5oPgoKSU5URVJGQUNFIHBp YzsKCkNPREUgewoJc3RhdGljIGludCBudWxsX3BpY19iaW5kKGRldmljZV90IGRldiwgc3RydWN0 IGFybV9pcnFzcmMgKmlzcmMsCgkgICAgY3B1c2V0X3QgY3B1bWFzaykKCXsKCQlyZXR1cm4gKEVP UE5PVFNVUFApOwoJfQoKCXN0YXRpYyB2b2lkIG51bGxfcGljX2luaXRfc2Vjb25kYXJ5KGRldmlj ZV90IGRldikKCXsKCQlyZXR1cm47Cgl9CgoJc3RhdGljIHZvaWQgbnVsbF9waWNfaXBpX3NlbmQo ZGV2aWNlX3QgZGV2LCBjcHVzZXRfdCBjcHVzLCB1X2ludCBpcGkpCgl7CgkJcmV0dXJuOwoJfQp9 OwoKTUVUSE9EIGludCBiaW5kIHsKCWRldmljZV90CQlkZXY7CglzdHJ1Y3QgYXJtX2lycXNyYwkq aXNyYzsKCWNwdXNldF90CQljcHVtYXNrOwp9IERFRkFVTFQgbnVsbF9waWNfYmluZDsKCk1FVEhP RCBpbnQgY29uZmlnIHsKCWRldmljZV90CQlkZXY7CglzdHJ1Y3QgYXJtX2lycXNyYwkqaXNyYzsK CWVudW0gaW50cl90cmlnZ2VyCXRyaWc7CgllbnVtIGludHJfcG9sYXJpdHkJcG9sOwp9OwoKTUVU SE9EIGludCBtYXAgewoJZGV2aWNlX3QJCWRldjsKCXN0cnVjdCBhcm1faXJxc3JjCSppc3JjOwoJ dV9pbnQJCQl0eXBlOwoJdV9pbnQJCQludW07Cn07CgojaWZkZXQgRkRUCk1FVEhPRCBpbnQgbWFw X2ZkdCB7CglkZXZpY2VfdAkJZGV2OwoJc3RydWN0IGFybV9pcnFzcmMJKmlzcmM7CglwY2VsbF90 CQkJKmNlbGxzOwoJdV9pbnQJCQluY2VsbHM7Cn07CiNlbmRpZgoKTUVUSE9EIGludCB1bm1hcCB7 CglkZXZpY2VfdAkJZGV2OwoJc3RydWN0IGFybV9pcnFzcmMJKmlzcmM7Cn07CgpNRVRIT0Qgdm9p ZCBkaXNhYmxlIHsKCWRldmljZV90CQlkZXY7CglzdHJ1Y3QgYXJtX2lycXNyYwkqaXNyYzsKfTsK Ck1FVEhPRCB2b2lkIGVuYWJsZSB7CglkZXZpY2VfdAkJZGV2OwoJc3RydWN0IGFybV9pcnFzcmMJ KmlzcmM7Cn07CgpNRVRIT0Qgdm9pZCBwcmVfaXRocmVhZCB7CglkZXZpY2VfdAkJZGV2OwoJc3Ry dWN0IGFybV9pcnFzcmMJKmlzcmM7Cn07CgpNRVRIT0Qgdm9pZCBwb3N0X2l0aHJlYWQgewoJZGV2 aWNlX3QJCWRldjsKCXN0cnVjdCBhcm1faXJxc3JjCSppc3JjOwp9OwoKTUVUSE9EIHZvaWQgcG9z dF9maWx0ZXIgewoJZGV2aWNlX3QJCWRldjsKCXN0cnVjdCBhcm1faXJxc3JjCSppc3JjOwp9OwoK TUVUSE9EIHZvaWQgaW5pdF9zZWNvbmRhcnkgewoJZGV2aWNlX3QJZGV2Owp9IERFRkFVTFQgbnVs bF9waWNfaW5pdF9zZWNvbmRhcnk7CgpNRVRIT0Qgdm9pZCBpcGlfc2VuZCB7CglkZXZpY2VfdAkJ ZGV2OwoJc3RydWN0IGFybV9pcnFzcmMJKmlzcmM7CgljcHVzZXRfdAkJY3B1czsKfSBERUZBVUxU IG51bGxfcGljX2lwaV9zZW5kOwoK --001a113ad13c76bebd050cb126db-- From owner-freebsd-arm@FreeBSD.ORG Thu Jan 15 16:31:45 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5798FDCB for ; Thu, 15 Jan 2015 16:31:45 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 3B73CB24 for ; Thu, 15 Jan 2015 16:31:44 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id t0FGVZ00013648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Jan 2015 08:31:36 -0800 Message-ID: <54B7EB67.6010702@freebsd.org> Date: Thu, 15 Jan 2015 08:31:35 -0800 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: interrupt framework References: In-Reply-To: X-Sonic-CAuth: UmFuZG9tSVboWSKzPGiV1xetyw+wDS3RM26bfU/hs+XNezxSl2v8QqTgKJu9nfkBEofQm1n6jooieGxtkEcL5Ae6sCVmKXuCHmhCjOHiDeI= X-Sonic-ID: C;vCPp+NOc5BGjT/CsS5uE/A== M;DvFB+dOc5BGjT/CsS5uE/A== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 16:31:45 -0000 On 01/15/15 05:51, Svatopluk Kraus wrote: > Hi community, > > I and Michal Meloun have done some work on ARM interrupt framework and > this is the result. > > We've started with intrng project with Ian's WIP changes, have looked > at Andrew's ARM64 git repository, and this is how we think an > interrupt framework should look like. We've implemented it with > removable interrupt controllers in mind (PCI world). It's not finished > from this point of view, however some functions are more complex > because of it. > > It's tested on pandaboard and only GIC is implemented now. There is no > problem to implement it to other controllers. We are open to questions > and can finish our work considering any comments. Whoever is waiting > for ARM interrupt framework as we were, you are welcome to test it. > Whoever is welcome. The patches are done against FreeBSD-11-current > revision 277210. There are two new files. > > ARM_INTRNG option must be added to board configuration file for new framework. > > There are still some things not implemented and some things which > should be discussed like PPI support. For example, how to enable PPI > interrupt on other CPUs when they are already running? > > We keep in mind that an interrupt framework should be helpfull but > general enough to not dictate interrupt controlles too much. Thus we > try to keep some things as much separated as possible. Each interrupt > is represented by an interrupt source (ISRC) in the framework. An ISRC > is described by an interrupt number which is much more an unique > resource handle - totally independent on internal representation of > interrupts in any interrupt controller. This is a good design. > An interrupt is described by cells in FDT world. The cells can be > decoded only by associated interrupt controller and as such, they are > transparent for interrupt framework. The framework provides > arm_fdt_map_irq() function which maps this transparent cells to an > interrupt number. It creates an ISRC, saves cells on it, and once when > associated interrupt controller is registered, it provides the ISRC > with cells into the controller. > > It's a controller responsibility to save an ISRC associated with > cells. An ISRC is transparent for any controller. However, an > controller can set/get its data to/from an ISRC. Further, an > controller should set a name to an ISRC according to internal > representation of associated interrupt. I'm assuming you are referring to arm_describe_irq? I had three comments on that: 1. Can you please make it part of the same API as ofw_bus_map_irq() rather than an out-of-band thing? This will let other platforms use it. 2. Once you've done that, you can remove all the #ifdef from simplebus. I would strongly prefer it not gain platform-specific #ifdef. 3. We should not be adding new things to machine/fdt.h unless they are really internal platforms APIs for reading the FDT. And even then, the header should probably disappear soon. FDT_MAP_IRQ() is used only in arm/intr.c, for example, and should be replaced by a direct invocation of arm_fdt_map_intr(). arm_describe_irq() should not join it there. > An controller interrupt dispatch function can call framework only if > it has associated ISRC to received interrupt. > > For legacy reason, there is arm_namespace_map_irq() function. An > interrupt is described by namespace type and a number from the > namespace. It's intented for use with no FDT drivers. Now, it's used > for mapping an IPI on a controller. > > We think that it's better to call chained controllers (with filter > only) without MI interrupt framework overhead, so we implemented > shortcut. It could be utilized by INTR_SOLO flag during > bus_setup_intr(). Can you describe the shortcut? We never ended up needing something like this on PowerPC. > Only an interrupt controller can really know its position in interrupt > controller's tree. So root controller must claim itself as a root. In > FDT world, according to ePAPR approved version 1.1 from 08 April 2011, > page 30: > > "The root of the interrupt tree is determined when traversal of the > interrupt tree reaches an interrupt controller node without an > interrupts property and thus no explicit interrupt parent." > > Thus there are no need for any non-standard things in DTS files. Right, this is what we did on PPC. -Nathan > Svata > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Thu Jan 15 18:16:02 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95EC7675 for ; Thu, 15 Jan 2015 18:16:02 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D0D3A73 for ; Thu, 15 Jan 2015 18:16:02 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0FIG2gY091252 for ; Thu, 15 Jan 2015 18:16:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196660] [arm] multimedia/gstreamer1-libav fails to compile Date: Thu, 15 Jan 2015 18:16:02 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 18:16:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196660 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |freebsd-multimedia@FreeBSD. | |org --- Comment #3 from Sean Bruno --- I will commit this if there's no objections. Fixes build on head for ARMv6 -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 15 18:16:10 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DBD37FF for ; Thu, 15 Jan 2015 18:16:10 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 846EEA7B for ; Thu, 15 Jan 2015 18:16:10 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0FIGAZT091334 for ; Thu, 15 Jan 2015 18:16:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196660] [arm] multimedia/gstreamer1-libav fails to compile Date: Thu, 15 Jan 2015 18:16:10 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 18:16:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196660 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 15 18:45:58 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C7391CD for ; Thu, 15 Jan 2015 18:45:58 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 237DDDD1 for ; Thu, 15 Jan 2015 18:45:58 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0FIjwjt048615 for ; Thu, 15 Jan 2015 18:45:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196774] multimedia/mplayer: fails to build on armv6 Date: Thu, 15 Jan 2015 18:45:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: riggs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 18:45:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196774 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |freebsd-arm@FreeBSD.org, | |freebsd-multimedia@FreeBSD. | |org Status|New |In Progress --- Comment #2 from Sean Bruno --- confirmed, commit when ready. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 15 18:46:23 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A28EF249 for ; Thu, 15 Jan 2015 18:46:23 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 89794DD7 for ; Thu, 15 Jan 2015 18:46:23 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0FIkNkg048737 for ; Thu, 15 Jan 2015 18:46:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196775] multimedia/ffmpeg: fails to build on armv6 Date: Thu, 15 Jan 2015 18:46:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: multimedia@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 18:46:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196775 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress CC| |freebsd-arm@FreeBSD.org --- Comment #2 from Sean Bruno --- If there's no current owner of this, I'll commit it. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 15 18:48:56 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C8334FC for ; Thu, 15 Jan 2015 18:48:56 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 241EEE05 for ; Thu, 15 Jan 2015 18:48:56 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0FImuau049607 for ; Thu, 15 Jan 2015 18:48:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196776] multimedia/libav: fails to build on armv6 Date: Thu, 15 Jan 2015 18:48:56 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 18:48:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196776 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress CC| |freebsd-arm@FreeBSD.org, | |freebsd-multimedia@FreeBSD. | |org --- Comment #1 from Sean Bruno --- Confirmed, I'll take this if there's no objections. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 15 19:26:39 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36C1328A for ; Thu, 15 Jan 2015 19:26:39 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 1ADC22E6 for ; Thu, 15 Jan 2015 19:26:38 +0000 (UTC) Received: from bender.lan (97e078e7.skybroadband.com [151.224.120.231]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id A4AD273000; Thu, 15 Jan 2015 19:26:31 +0000 (UTC) Date: Thu, 15 Jan 2015 19:26:24 +0000 From: Andrew Turner To: Svatopluk Kraus Subject: Re: interrupt framework Message-ID: <20150115192624.122066dd@bender.lan> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 19:26:39 -0000 On Thu, 15 Jan 2015 14:51:17 +0100 Svatopluk Kraus wrote: > Hi community, > > I and Michal Meloun have done some work on ARM interrupt framework and > this is the result. I haven't ad a chance to look though it yet, but how does this compare with what is currently on the arm_intrng branch? I've also taken Ian's WIP change and cleaned it up so it will build with the current interrupt framework. I've also been working on allowing the simplebus changes to work on architectures that aren't arm. I'm planning on importing the branch into head soon, after fixing the last few cross-arch issues, to allow for wider testing. Andrew From owner-freebsd-arm@FreeBSD.ORG Thu Jan 15 22:42:55 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0048B3E5; Thu, 15 Jan 2015 22:42:54 +0000 (UTC) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ADF0ABA9; Thu, 15 Jan 2015 22:42:54 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id v8so13214206qal.8; Thu, 15 Jan 2015 14:42:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4KXmoYn4yn+vhsx2xMC5atSKR2GI96f+pkGx2XUWOVo=; b=ILtL1WgjbT5CwJ+tl4Fix9TJYhXslotLQq+N89fFWADVFo5MhlnjfxRn6JQ1LsLfX/ D7SJKiDcox2Uq0AZiEGUwIVNLrQxR4Vn8Pt9hdIeS9nP8sz5vmwWPaivH6yGowWLQB5Q iIJ8d5Sg/wec1P9purTa2lwGrKntoPAMpaW+0Bc03S/rC5FKiXOa/GzD+FhuIGfykddJ +HyTUsWv4Kfmafpv3CGswGW1aAWLAFrtbnmI4is887GMkElzv/bWJFXOS5O3zF1sNYHm OeZSonaQh1I8yzYEp0faartpZiWNenBKQG5dmGNn4KONp+uMnKvqymDPM+GEJVRzIcJ6 A0+A== MIME-Version: 1.0 X-Received: by 10.140.39.167 with SMTP id v36mr19321732qgv.77.1421361773851; Thu, 15 Jan 2015 14:42:53 -0800 (PST) Received: by 10.140.82.180 with HTTP; Thu, 15 Jan 2015 14:42:53 -0800 (PST) In-Reply-To: <54B7EB67.6010702@freebsd.org> References: <54B7EB67.6010702@freebsd.org> Date: Thu, 15 Jan 2015 23:42:53 +0100 Message-ID: Subject: Re: interrupt framework From: Svatopluk Kraus To: Nathan Whitehorn Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 22:42:55 -0000 On Thu, Jan 15, 2015 at 5:31 PM, Nathan Whitehorn wrote: > > On 01/15/15 05:51, Svatopluk Kraus wrote: >> >> Hi community, >> >> I and Michal Meloun have done some work on ARM interrupt framework and >> this is the result. >> >> We've started with intrng project with Ian's WIP changes, have looked >> at Andrew's ARM64 git repository, and this is how we think an >> interrupt framework should look like. We've implemented it with >> removable interrupt controllers in mind (PCI world). It's not finished >> from this point of view, however some functions are more complex >> because of it. >> >> It's tested on pandaboard and only GIC is implemented now. There is no >> problem to implement it to other controllers. We are open to questions >> and can finish our work considering any comments. Whoever is waiting >> for ARM interrupt framework as we were, you are welcome to test it. >> Whoever is welcome. The patches are done against FreeBSD-11-current >> revision 277210. There are two new files. >> >> ARM_INTRNG option must be added to board configuration file for new >> framework. >> >> There are still some things not implemented and some things which >> should be discussed like PPI support. For example, how to enable PPI >> interrupt on other CPUs when they are already running? >> >> We keep in mind that an interrupt framework should be helpfull but >> general enough to not dictate interrupt controlles too much. Thus we >> try to keep some things as much separated as possible. Each interrupt >> is represented by an interrupt source (ISRC) in the framework. An ISRC >> is described by an interrupt number which is much more an unique >> resource handle - totally independent on internal representation of >> interrupts in any interrupt controller. > > > This is a good design. > >> An interrupt is described by cells in FDT world. The cells can be >> decoded only by associated interrupt controller and as such, they are >> transparent for interrupt framework. The framework provides >> arm_fdt_map_irq() function which maps this transparent cells to an >> interrupt number. It creates an ISRC, saves cells on it, and once when >> associated interrupt controller is registered, it provides the ISRC >> with cells into the controller. >> >> It's a controller responsibility to save an ISRC associated with >> cells. An ISRC is transparent for any controller. However, an >> controller can set/get its data to/from an ISRC. Further, an >> controller should set a name to an ISRC according to internal >> representation of associated interrupt. > > > I'm assuming you are referring to arm_describe_irq? I had three comments on > that: > 1. Can you please make it part of the same API as ofw_bus_map_irq() rather > than an out-of-band thing? This will let other platforms use it. > 2. Once you've done that, you can remove all the #ifdef from simplebus. I > would strongly prefer it not gain platform-specific #ifdef. > 3. We should not be adding new things to machine/fdt.h unless they are > really internal platforms APIs for reading the FDT. And even then, the > header should probably disappear soon. FDT_MAP_IRQ() is used only in > arm/intr.c, for example, and should be replaced by a direct invocation of > arm_fdt_map_intr(). arm_describe_irq() should not join it there. > Hmm, we was not aware of that as we have taken something what was already designed this way. However, it's not problem to arrange things according to you comments. >> An controller interrupt dispatch function can call framework only if >> it has associated ISRC to received interrupt. >> >> For legacy reason, there is arm_namespace_map_irq() function. An >> interrupt is described by namespace type and a number from the >> namespace. It's intented for use with no FDT drivers. Now, it's used >> for mapping an IPI on a controller. >> >> We think that it's better to call chained controllers (with filter >> only) without MI interrupt framework overhead, so we implemented >> shortcut. It could be utilized by INTR_SOLO flag during >> bus_setup_intr(). > > > Can you describe the shortcut? We never ended up needing something like this > on PowerPC. > In standard MI interrupt framework, an interrupt event is created for an interrupt and intr_event_handle() is called to handle an interrupt when it comes. Many things happen in this functions before real filters and/or handlers are called. In former design, when controllers are chained, it's done on each of them - on each layer. So if a controller is fast enough and handles interrupts by a filter, we can call the filter without MI framework overhead. Thus we save time and stack space. And we do not have a problem to pass trapframe thru chained controllers. Further, it can be utilized by any interrupt where time is critical. >> Only an interrupt controller can really know its position in interrupt >> controller's tree. So root controller must claim itself as a root. In >> FDT world, according to ePAPR approved version 1.1 from 08 April 2011, >> page 30: >> >> "The root of the interrupt tree is determined when traversal of the >> interrupt tree reaches an interrupt controller node without an >> interrupts property and thus no explicit interrupt parent." >> >> Thus there are no need for any non-standard things in DTS files. > > > Right, this is what we did on PPC. > -Nathan > >> Svata >> >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Thu Jan 15 22:49:18 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 626E14F7 for ; Thu, 15 Jan 2015 22:49:18 +0000 (UTC) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1CA15C20 for ; Thu, 15 Jan 2015 22:49:18 +0000 (UTC) Received: by mail-qg0-f42.google.com with SMTP id q107so524411qgd.1 for ; Thu, 15 Jan 2015 14:49:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yXUTRBZFLPly3BALGFDkrAaFVEUdJ2j6Uj/DHbrICSg=; b=B4EhiPstkf18DEDjjHZ1WWFuilQGAolxQQ0KYYZ3lLRgyMRHtbYkNqw9Aus/Z9J9JB 9FYLOCWput8+EEDGYRnzoE1+H48dYpDtS/Aykv+w+uIaeFez1RFZW+bAL+2xRPuN3XVL F/zJiv4iD2rrB2AKqHd0C1Wf/3kkq0cKtnVVuYSxCal2aSKgDMymze43CLcxFFFnxMm8 wagwkAnuh8KWG5VLrx0S9M9/79zvBC4D2tr/gVWkao2oidX/FMV0raqrenvyXaFx778e 7eQo9WTtcioBWCHC81w+ABVDHhft5Z+aGF7cVirgA6TFU9tyv/+L1TE+2WfM2Ef3ZOVN AdUQ== MIME-Version: 1.0 X-Received: by 10.224.15.78 with SMTP id j14mr20860035qaa.0.1421362157309; Thu, 15 Jan 2015 14:49:17 -0800 (PST) Received: by 10.140.82.180 with HTTP; Thu, 15 Jan 2015 14:49:17 -0800 (PST) In-Reply-To: <20150115192624.122066dd@bender.lan> References: <20150115192624.122066dd@bender.lan> Date: Thu, 15 Jan 2015 23:49:17 +0100 Message-ID: Subject: Re: interrupt framework From: Svatopluk Kraus To: Andrew Turner Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 22:49:18 -0000 On Thu, Jan 15, 2015 at 8:26 PM, Andrew Turner wrote: > On Thu, 15 Jan 2015 14:51:17 +0100 > Svatopluk Kraus wrote: > >> Hi community, >> >> I and Michal Meloun have done some work on ARM interrupt framework and >> this is the result. > > I haven't ad a chance to look though it yet, but how does this compare > with what is currently on the arm_intrng branch? I've also taken Ian's > WIP change and cleaned it up so it will build with the current > interrupt framework. I've also been working on allowing the simplebus > changes to work on architectures that aren't arm. > I did not look at arm_intrng branch recently, so if there is any change this year I missed it. However, in general, the codes do same work but in slightly different way. However, IMHO, our design is more simple, more general, and more complete. > I'm planning on importing the branch into head soon, after fixing the > last few cross-arch issues, to allow for wider testing. > > Andrew Do what you must do. However, I think that our design is worth the look. Maybe it needs some polishing, but it's certainly worth the look. Svata From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 11:44:23 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34030BB4 for ; Fri, 16 Jan 2015 11:44:23 +0000 (UTC) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E27D75F3 for ; Fri, 16 Jan 2015 11:44:22 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id l6so12496035qcy.13 for ; Fri, 16 Jan 2015 03:44:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ik+b2NY+sZFhC+8oPWMdgaqK8cQhydHSnzLFetdY7rE=; b=D/NLhBQ2to3+hCLns10rKplT13z4qz+eOt9BgGnD7ERoLd7I5xc6rP0nF1zLailKlv 5NqBy3RWzuS7yn1bCXpS0fW3G+U5UXSpnHTIqJOLu7BIEJ++TDGpcLKy16nXZMcWMs/9 O7vUF6FkC7QHZZiXR4BiENBiHg3k5kmRy5H7CnxlEla9lyVh4jFWrRzHfxV7ar26TAUh TyrjWWs/9vnmmYvCKK4ujrgDdniw4Rs/sDbg9Mn0jcTmWspc/jRkBNAqK7Y7+jzfYzdt dBcDam9yxyeMw5p924K7v88vHlS722As1i3sYh5uBw/pVYjGYyANLLmFKWfCzRs1qMpN 1p8Q== MIME-Version: 1.0 X-Received: by 10.224.166.71 with SMTP id l7mr24370319qay.50.1421408662102; Fri, 16 Jan 2015 03:44:22 -0800 (PST) Received: by 10.140.82.180 with HTTP; Fri, 16 Jan 2015 03:44:22 -0800 (PST) In-Reply-To: <20150115192624.122066dd@bender.lan> References: <20150115192624.122066dd@bender.lan> Date: Fri, 16 Jan 2015 12:44:22 +0100 Message-ID: Subject: Re: interrupt framework From: Svatopluk Kraus To: Andrew Turner Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 11:44:23 -0000 On Thu, Jan 15, 2015 at 8:26 PM, Andrew Turner wrote: > On Thu, 15 Jan 2015 14:51:17 +0100 > Svatopluk Kraus wrote: > >> Hi community, >> >> I and Michal Meloun have done some work on ARM interrupt framework and >> this is the result. > > I haven't ad a chance to look though it yet, but how does this compare > with what is currently on the arm_intrng branch? I've also taken Ian's > WIP change and cleaned it up so it will build with the current > interrupt framework. I've also been working on allowing the simplebus > changes to work on architectures that aren't arm. > > I'm planning on importing the branch into head soon, after fixing the > last few cross-arch issues, to allow for wider testing. > > Andrew I looked at arm_intrng project this morning and more concrete remarks are here about difference between that and our design. (1) I do not think that nexus as root interrupt controller is good abstraction. All nexus PIC methods are empty. But mainly, an interrupt framework should be responsible of dispatching interrupts on first (root) level. Not nexus. In case of vector interrupts, again, it should be coded in framework not in nexus. And framework has no usage from knowing that nexus is root interrupt controller device. Thus in our design, nexus is not root interrupt controller. (2) Only root controller can do IPIs. In your design, nexus is root controller, so real root controller must claim that can do IPIs. (2) Unmasking IPI in init_secondary is useless as that is done in release_aps(). (3) In our design, we use separated IPI handlers as each of them needs different handling. See for example comments in smp_rendezvous_action(). (4) Using of critical_section() is not allowed for some IPIs. So using intr_event_handle() for IPIs is not wanted certainly in you design. (4) We do not use pic_ipi_read(). It's controller responsibility to serve IPIs interrupt, even if there could come more IPIs on one interrupt. (5) On GIC, EOI cannot be done in post_filter method as according to manual the register value used for EIO must correspond to most recent read value from active interrupt register. For example, in our design there is a possibility to save read value to ISRC and use it in post_filter method. However, we do not do that in GIC now. It's just a few things from quick look now which are different in our design. However, my intention is not read our code on behalf of you. I still think that our design is more general mainly and can serve for interrupt controllers better. Svata From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 12:03:26 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19FCA496 for ; Fri, 16 Jan 2015 12:03:26 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id F2A9D856 for ; Fri, 16 Jan 2015 12:03:25 +0000 (UTC) Received: from bender.lan (97e078e7.skybroadband.com [151.224.120.231]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id B672273000; Fri, 16 Jan 2015 12:03:24 +0000 (UTC) Date: Fri, 16 Jan 2015 12:03:15 +0000 From: Andrew Turner To: Svatopluk Kraus Subject: Re: interrupt framework Message-ID: <20150116120315.7f343f66@bender.lan> In-Reply-To: References: <20150115192624.122066dd@bender.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 12:03:26 -0000 On Fri, 16 Jan 2015 12:44:22 +0100 Svatopluk Kraus wrote: ... > It's just a few things from quick look now which are different in our > design. However, my intention is not read our code on behalf of you. I > still think that our design is more general mainly and can serve for > interrupt controllers better. I was asking on the differences as I'm already in the process of importing the arm_intrng project branch as I need something like it on arm64. It is also based on the same code from Jakub and Ian, I haven't looked at changing the design, just cleaning up the code to import into head. I would be happy to merge your code instead, along with my existing cleanups, however I would need to know why I should spend time on it as opposed to the current development branch. If we do decide to with your change I would like to import it into the arm_intrng project branch first to assist the import into head. Andrew From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 15:34:42 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1219679A for ; Fri, 16 Jan 2015 15:34:42 +0000 (UTC) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D3A0DF0 for ; Fri, 16 Jan 2015 15:34:41 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id lf10so24895158pab.4 for ; Fri, 16 Jan 2015 07:34:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=YBH5tXv7mJsXaqXE6f4qUKCW08F0yVwCT+J5oBZP1lw=; b=fkA8+W+gkEk7V+q5pSKhZLHYdCdClPm8WvKDMfX2zXGDeEdmuxNwQP3FRdrinGdQGV rmSeMBDmwTfcNTDQYIqkgprOumtrXiWtHr0l7yfrLnpG4KWztRUDR32FvbbPrNCXXpfR 98kC+/dcotqjBdcb3ymK9sN3kUFW69OO5Cry/GwR7tSGj9AJksM47Sod3olr2r1S/jLm r065nv4LlWPbORGvBoKuWsp9hvMLXONLYzwMoQsj4oLaYJR7yBFDCwZ2ZeT4dgcAu6Rb fcSVLwfU6iz0uFRaeQ9WS9mDF4rEE7834TLebxj5NsC1noQzczleh0V/vO6Ish2+3Oi7 N5Gw== X-Gm-Message-State: ALoCoQnkQvRScaafnVSWO4wQYozfFjMBE2FEOkpNwyrgCxpFHYdDuT0BfWvqMkKipx6PRSPU6s19 X-Received: by 10.66.159.42 with SMTP id wz10mr23875466pab.8.1421422475737; Fri, 16 Jan 2015 07:34:35 -0800 (PST) Received: from lglt-rottaway.corp.netflix.com ([69.53.236.236]) by mx.google.com with ESMTPSA id ua7sm4424848pab.37.2015.01.16.07.34.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Jan 2015 07:34:34 -0800 (PST) Sender: Warner Losh Subject: Re: interrupt framework Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_661B2A50-D00F-415F-8037-0334B40915D6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: <20150116120315.7f343f66@bender.lan> Date: Fri, 16 Jan 2015 08:34:32 -0700 Message-Id: <6E33C7B5-F784-4604-9F09-9FEDB1EFBE56@bsdimp.com> References: <20150115192624.122066dd@bender.lan> <20150116120315.7f343f66@bender.lan> To: Andrew Turner X-Mailer: Apple Mail (2.1993) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 15:34:42 -0000 --Apple-Mail=_661B2A50-D00F-415F-8037-0334B40915D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 16, 2015, at 5:03 AM, Andrew Turner = wrote: >=20 > On Fri, 16 Jan 2015 12:44:22 +0100 > Svatopluk Kraus wrote: > ... >> It's just a few things from quick look now which are different in our >> design. However, my intention is not read our code on behalf of you. = I >> still think that our design is more general mainly and can serve for >> interrupt controllers better. >=20 > I was asking on the differences as I'm already in the process of > importing the arm_intrng project branch as I need something like it on > arm64. It is also based on the same code from Jakub and Ian, I haven't > looked at changing the design, just cleaning up the code to import = into > head. >=20 > I would be happy to merge your code instead, along with my existing > cleanups, however I would need to know why I should spend time on it = as > opposed to the current development branch. If we do decide to with = your > change I would like to import it into the arm_intrng project branch > first to assist the import into head. My first look at Svatopluk=E2=80=99s code and summaries, on its surface = it seems to be a simpler, more generalized and more effective design than intern. It avoids some additional overhead that=E2=80=99s always troubled me = about intern that I=E2=80=99ve not had the time to make good suggestions to overcome. = It looks (again on its surface) easier to bring to all the architectures as well. I haven=E2=80=99t tried to use the code so I can=E2=80=99t comment on = its stability. So of course I can=E2=80=99t measure the differences in interrupt latencies between = the two. Both of these factors would be the kind of data that would help drive the = decision of which one to adapt. Warner --Apple-Mail=_661B2A50-D00F-415F-8037-0334B40915D6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUuS+IAAoJEGwc0Sh9sBEAQLEQAJFGhkdV6qK95lokyahXiEPA ccY4VevBONUAhWRvkvbqOj3lsxQFVxK3k6ddCe62Zd15+QsfmeiYTnGqfvZA6qaq cR9F7LCpp2HxFvlrSTGxcSAHNxBdf4cKeWFqwtStv0gZsGfnkkbOeXp+cj9bvLQ5 x/2XptFXVT9wpQ46N90v1NDHbNryIMpYuTpPu3eAe8fEeeZoUzx7+tVQ4YJRkDpU ckHXaWe6nwOGFKBoofvyulSbXVH7QlmaRyuZeDlVhpSfGanwRQOva2lmWyoeV0jg l5S7pIUgajjHfvlBr3zZjo3MaE29TOe0efo6MM1eUhPM+aTdExG0pSXuKzKu6805 20fikLrVvvLKwfYxQm9hMiQClQQ58Rwe03jghBH5NU4reo9YZMdSVQCRkedWqxUV xhy82qEHSy2eFti1flXA2TAldoS9dL1L24/BfCNKmqnJaHC+sLMpy2JCVDwFHcYK SpYR8LzjxxK13KFxC9bQTu4Sae/i8CJ4RHaC0zepC9h2lXFFMvJeEC6+hxzGBqqW SzR7teqvWj3j/1WkU/M0c0WBf6n0Tl6zi4MebPPF8K4n5cMvLLG5EIxJUD5jLHI1 h2GkrEdI7FFWwun2B7hQrw71RDaa4y4KsVffJ1mtz2Z/nJDn1Ew12QP5qpa4RBFG fvH9/ekaEe6ngELz4lie =+86/ -----END PGP SIGNATURE----- --Apple-Mail=_661B2A50-D00F-415F-8037-0334B40915D6-- From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 16:08:56 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB00A931 for ; Fri, 16 Jan 2015 16:08:56 +0000 (UTC) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8380478D for ; Fri, 16 Jan 2015 16:08:56 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id x3so17644431qcv.8 for ; Fri, 16 Jan 2015 08:08:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xwoNLAkTH885SgVrZxwiE8VT7NUywz9J+UbiHxn3Fso=; b=dhUWQzrXE7fVyfps+JDs6hXmzuUchzKxy//QK9F1EWRH/iM3HV38OPzBiwODdyDp6a YHokMT+WEM8snq/Cp6r125kHByYwYWdt5EPHv5vTApjiXPvRXYNrI0hGMKLKO2gFcKbR DWLON7v5/PvpihChChmyrfGfWschTWinxJ3YGCeouAxNRzxeTs/0PMrvIR6/xWHI8ffv VYpxKhTVKIhS5GfrvCPrD0N8uSW39adSN4Ei/nHi+SkOqHNaN+4QN5iOuaXr4X91gE/n eVy7IFDmjwFVboXVvdhCyYb0kphSaijTFRyH8R0phonCSTwuD1AZCflGK8uH3YE5annT Glsw== MIME-Version: 1.0 X-Received: by 10.224.61.1 with SMTP id r1mr5555870qah.0.1421424534871; Fri, 16 Jan 2015 08:08:54 -0800 (PST) Received: by 10.140.82.180 with HTTP; Fri, 16 Jan 2015 08:08:54 -0800 (PST) In-Reply-To: <20150116120315.7f343f66@bender.lan> References: <20150115192624.122066dd@bender.lan> <20150116120315.7f343f66@bender.lan> Date: Fri, 16 Jan 2015 17:08:54 +0100 Message-ID: Subject: Re: interrupt framework From: Svatopluk Kraus To: Andrew Turner Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 16:08:57 -0000 On Fri, Jan 16, 2015 at 1:03 PM, Andrew Turner wrote: > On Fri, 16 Jan 2015 12:44:22 +0100 > Svatopluk Kraus wrote: > ... >> It's just a few things from quick look now which are different in our >> design. However, my intention is not read our code on behalf of you. I >> still think that our design is more general mainly and can serve for >> interrupt controllers better. > > I was asking on the differences as I'm already in the process of > importing the arm_intrng project branch as I need something like it on > arm64. It is also based on the same code from Jakub and Ian, I haven't > looked at changing the design, just cleaning up the code to import into > head. > > I would be happy to merge your code instead, along with my existing > cleanups, however I would need to know why I should spend time on it as > opposed to the current development branch. If we do decide to with your > change I would like to import it into the arm_intrng project branch > first to assist the import into head. > > Andrew Well, this is the main difference in our design: (1) We use one global table for all interrupt sources for framework needs. Each interrupt source is allocated only once and has been assigned to unique interrupt number from the beginning. (2) We do not use per controller tables for interrupt sources in framework. It's controller responsibility to keep interrupt sources inside itself according to mapping that is transparent for framework. Further, we assume that a controller can need an internal data for its interrupt sources, so it needs to keep it in some form anyhow. Thus why to have one table for controller's interrupt sources in framework and one table for controller's interrupt sources data in controller. (3) A controller sets names to its interrupt sources. Only controller knows how an interrupt sources should be named. (4) We have three interrupt dispatch function. The need for extra IPI dispatch function I already described in previous email. However, PPI interrupts are quite different of SPI interrupts too. Now, the handling is same but we assume that could change. For example, PPI can be different on each CPU. Anyhow, PPI should be discussed more. (5) We only enable used PPI on other CPUs. (6) We only need to keep track of controllers (except the root one) to have translation from phandle_t to device_t in FDT case. There are more small differencies, different optimalizations and hacks which works, but the main thing is how the interrupt sources are organized. If you deside to give our design a try, we have no problem to arrange it to get general satisfaction. Svata From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 16:19:23 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F655B51 for ; Fri, 16 Jan 2015 16:19:23 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 51034895 for ; Fri, 16 Jan 2015 16:19:22 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1YC9cC-000LQL-8o; Fri, 16 Jan 2015 16:19:16 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t0GGJDbk000973; Fri, 16 Jan 2015 09:19:13 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+gCpXHjQyvwtu4nuiqcBLy Message-ID: <1421425153.14601.289.camel@freebsd.org> Subject: Re: interrupt framework From: Ian Lepore To: Warner Losh Date: Fri, 16 Jan 2015 09:19:13 -0700 In-Reply-To: <6E33C7B5-F784-4604-9F09-9FEDB1EFBE56@bsdimp.com> References: <20150115192624.122066dd@bender.lan> <20150116120315.7f343f66@bender.lan> <6E33C7B5-F784-4604-9F09-9FEDB1EFBE56@bsdimp.com> Content-Type: text/plain; charset="iso-8859-7" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id t0GGJDbk000973 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 16:19:23 -0000 On Fri, 2015-01-16 at 08:34 -0700, Warner Losh wrote: > > On Jan 16, 2015, at 5:03 AM, Andrew Turner wro= te: > >=20 > > On Fri, 16 Jan 2015 12:44:22 +0100 > > Svatopluk Kraus wrote: > > ... > >> It's just a few things from quick look now which are different in ou= r > >> design. However, my intention is not read our code on behalf of you.= I > >> still think that our design is more general mainly and can serve for > >> interrupt controllers better. > >=20 > > I was asking on the differences as I'm already in the process of > > importing the arm_intrng project branch as I need something like it o= n > > arm64. It is also based on the same code from Jakub and Ian, I haven'= t > > looked at changing the design, just cleaning up the code to import in= to > > head. > >=20 > > I would be happy to merge your code instead, along with my existing > > cleanups, however I would need to know why I should spend time on it = as > > opposed to the current development branch. If we do decide to with yo= ur > > change I would like to import it into the arm_intrng project branch > > first to assist the import into head. >=20 > My first look at Svatopluk=A2s code and summaries, on its surface it se= ems > to be a simpler, more generalized and more effective design than intern. > It avoids some additional overhead that=A2s always troubled me about in= tern > that I=A2ve not had the time to make good suggestions to overcome. It l= ooks > (again on its surface) easier to bring to all the architectures as well. >=20 > I haven=A2t tried to use the code so I can=A2t comment on its stability= . So of course > I can=A2t measure the differences in interrupt latencies between the tw= o. Both of > these factors would be the kind of data that would help drive the decis= ion of which > one to adapt. >=20 > Warner I haven't looked at Svata's work recently, but in general he started with the same sources that are now in the intrng branch and finished work I was in the middle of (redoing IPI stuff) when I had to set it aside. Based on other work done recently by Svata and Michal, I can only imagine that they've improved on Jakub's and my earlier effort. My main concern for importing anything (Svata's version or the current intrng branch) is for the Marvell code. It's the one that's a bit different than other modern arm systems, for example it's the reason we had the somewhat strange design for handling IPIs in the current code. Unfortunately, I think none of us have hardare for testing except the folks at Semihalf. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 16:25:07 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 385ECC54 for ; Fri, 16 Jan 2015 16:25:07 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A6D995E for ; Fri, 16 Jan 2015 16:25:06 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1YC9hp-000Pj3-FQ; Fri, 16 Jan 2015 16:25:05 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t0GGP2MC001021; Fri, 16 Jan 2015 09:25:02 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+v50L+GLbjC1Exio5thOVW Message-ID: <1421425502.14601.294.camel@freebsd.org> Subject: Re: interrupt framework From: Ian Lepore To: Svatopluk Kraus Date: Fri, 16 Jan 2015 09:25:02 -0700 In-Reply-To: References: <20150115192624.122066dd@bender.lan> <20150116120315.7f343f66@bender.lan> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 16:25:07 -0000 On Fri, 2015-01-16 at 17:08 +0100, Svatopluk Kraus wrote: > On Fri, Jan 16, 2015 at 1:03 PM, Andrew Turner wrote: > > On Fri, 16 Jan 2015 12:44:22 +0100 > > Svatopluk Kraus wrote: > > ... > >> It's just a few things from quick look now which are different in our > >> design. However, my intention is not read our code on behalf of you. I > >> still think that our design is more general mainly and can serve for > >> interrupt controllers better. > > > > I was asking on the differences as I'm already in the process of > > importing the arm_intrng project branch as I need something like it on > > arm64. It is also based on the same code from Jakub and Ian, I haven't > > looked at changing the design, just cleaning up the code to import into > > head. > > > > I would be happy to merge your code instead, along with my existing > > cleanups, however I would need to know why I should spend time on it as > > opposed to the current development branch. If we do decide to with your > > change I would like to import it into the arm_intrng project branch > > first to assist the import into head. > > > > Andrew > > > Well, this is the main difference in our design: > > (1) We use one global table for all interrupt sources for framework > needs. Each interrupt source is allocated only once and has been > assigned to unique interrupt number from the beginning. > While we don't have any existing examples of it, interrupt controllers can actually come and go at runtime; they can be associated with hotplug hardware. An example would be something like an i2c-based gpio extender that can generate interrupts on its gpio pins. Does the single global table allow for hotplug things to be added? Even trickier, what about when those things disappear later? I don't think we need to support this right away, I'm just asking if supporting it some day will be impossible or not. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 16:44:26 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24AA4F98 for ; Fri, 16 Jan 2015 16:44:26 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 08A81B82 for ; Fri, 16 Jan 2015 16:44:25 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id t0GGiGSK013331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 16 Jan 2015 08:44:17 -0800 Message-ID: <54B93FE0.7040403@freebsd.org> Date: Fri, 16 Jan 2015 08:44:16 -0800 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: interrupt framework References: In-Reply-To: X-Sonic-CAuth: UmFuZG9tSVaMrUuZprICf0GzGmuZmm0iMyAojzB8Jsj72BMj+k0JfW0VDSwacT3/4RmXgPNpDiE6CEe3ana9Z3gh7YdhfS/d/KCdXdrNWes= X-Sonic-ID: C;pM3S6J6d5BGb4PCsS5uE/A== M;7hEw6Z6d5BGb4PCsS5uE/A== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 16:44:26 -0000 I think you missed attaching intrng.c. I'd be interested in taking a look at it. -Nathan On 01/15/15 05:51, Svatopluk Kraus wrote: > Hi community, > > I and Michal Meloun have done some work on ARM interrupt framework and > this is the result. > > We've started with intrng project with Ian's WIP changes, have looked > at Andrew's ARM64 git repository, and this is how we think an > interrupt framework should look like. We've implemented it with > removable interrupt controllers in mind (PCI world). It's not finished > from this point of view, however some functions are more complex > because of it. > > It's tested on pandaboard and only GIC is implemented now. There is no > problem to implement it to other controllers. We are open to questions > and can finish our work considering any comments. Whoever is waiting > for ARM interrupt framework as we were, you are welcome to test it. > Whoever is welcome. The patches are done against FreeBSD-11-current > revision 277210. There are two new files. > > ARM_INTRNG option must be added to board configuration file for new framework. > > There are still some things not implemented and some things which > should be discussed like PPI support. For example, how to enable PPI > interrupt on other CPUs when they are already running? > > We keep in mind that an interrupt framework should be helpfull but > general enough to not dictate interrupt controlles too much. Thus we > try to keep some things as much separated as possible. Each interrupt > is represented by an interrupt source (ISRC) in the framework. An ISRC > is described by an interrupt number which is much more an unique > resource handle - totally independent on internal representation of > interrupts in any interrupt controller. > > An interrupt is described by cells in FDT world. The cells can be > decoded only by associated interrupt controller and as such, they are > transparent for interrupt framework. The framework provides > arm_fdt_map_irq() function which maps this transparent cells to an > interrupt number. It creates an ISRC, saves cells on it, and once when > associated interrupt controller is registered, it provides the ISRC > with cells into the controller. > > It's a controller responsibility to save an ISRC associated with > cells. An ISRC is transparent for any controller. However, an > controller can set/get its data to/from an ISRC. Further, an > controller should set a name to an ISRC according to internal > representation of associated interrupt. > > An controller interrupt dispatch function can call framework only if > it has associated ISRC to received interrupt. > > For legacy reason, there is arm_namespace_map_irq() function. An > interrupt is described by namespace type and a number from the > namespace. It's intented for use with no FDT drivers. Now, it's used > for mapping an IPI on a controller. > > We think that it's better to call chained controllers (with filter > only) without MI interrupt framework overhead, so we implemented > shortcut. It could be utilized by INTR_SOLO flag during > bus_setup_intr(). > > Only an interrupt controller can really know its position in interrupt > controller's tree. So root controller must claim itself as a root. In > FDT world, according to ePAPR approved version 1.1 from 08 April 2011, > page 30: > > "The root of the interrupt tree is determined when traversal of the > interrupt tree reaches an interrupt controller node without an > interrupts property and thus no explicit interrupt parent." > > Thus there are no need for any non-standard things in DTS files. > > Svata > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 17:12:36 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92B69AE9 for ; Fri, 16 Jan 2015 17:12:36 +0000 (UTC) Received: from mout3.freenet.de (mout3.freenet.de [IPv6:2001:748:100:40::2:5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 502FFEBD for ; Fri, 16 Jan 2015 17:12:36 +0000 (UTC) Received: from [195.4.92.141] (helo=mjail1.freenet.de) by mout3.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.82 #2) id 1YCARl-000337-9t for freebsd-arm@freebsd.org; Fri, 16 Jan 2015 18:12:33 +0100 Received: from localhost ([::1]:53581 helo=mjail1.freenet.de) by mjail1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.82 #2) id 1YCARl-0002wA-0B for freebsd-arm@freebsd.org; Fri, 16 Jan 2015 18:12:33 +0100 Received: from mx12.freenet.de ([195.4.92.22]:46518) by mjail1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.82 #2) id 1YCAPc-0001DZ-F7 for freebsd-arm@freebsd.org; Fri, 16 Jan 2015 18:10:20 +0100 Received: from p5ddd5591.dip0.t-ipconnect.de ([93.221.85.145]:49652 helo=[127.0.0.1]) by mx12.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:DHE-RSA-AES128-SHA:128) (port 587) (Exim 4.82 #2) id 1YCAPb-0001UV-SL for freebsd-arm@freebsd.org; Fri, 16 Jan 2015 18:10:20 +0100 Message-ID: <54B945FB.10609@freenet.de> Date: Fri, 16 Jan 2015 18:10:19 +0100 From: =?UTF-8?B?TWFudWVsIFN0w7xobg==?= User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: mmap-issue Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 150116-0, 16.01.2015), Outbound message X-Antivirus-Status: Clean X-Originated-At: 93.221.85.145!49652 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 17:12:36 -0000 Hi, I'm seeing unexpected behavior using mmap( /dev/mem ) on my beaglebone black. It seems to me, that writing to/reading from this mapped pointer does not immediatly take effect. The code looks like this: #define GPIO1 0x4804C000 #define CLR_REG 0x190 #define SET_REG 0x194 #define LED0 21 #define LED1 22 #define LED2 23 #define LED3 24 int fd = open( "/dev/mem", O_RDWR ); int pagesize = getpagesize(); volatile uint32_t* ptr = mmap( 0, pagesize, PROT_READ | PROT_WRITE, MAP_SHARED, fd, GPIO1_ADDR ); ptr[SET_REG] = LED0 << 1; I mapped for testing purposes the AM335x-GPIO-registers from /dev/mem. Writing into these mmap'ed registers for toggling some LEDs does not immediatly take effect. I have to call it several times to get one LED-toggle. Is there any data caching I'm missing? Thanks for hints. From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 17:42:46 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 279AB699 for ; Fri, 16 Jan 2015 17:42:46 +0000 (UTC) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B4A5E2E4 for ; Fri, 16 Jan 2015 17:42:45 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hi2so5418686wib.2 for ; Fri, 16 Jan 2015 09:42:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=c76QnRzNUg/vbrtrv+ESG9coQtxsPjrWz0xFJF0oq6I=; b=BuWQOoUV0CKR8sQEIkeFPfvMlnG/rt2bguvmVF8kFXI6F/Dur7QgV3ldg1ethGjWE4 pPFksk/hLOrdW6C8vuX2n35PSZLFrJXjUCfPRUvzjoTyvBoWEHybZL/KRW7i79CPYn0q Mv0c9+o7i2j8Ne3er+88jxaS8MkZ9PurUkvQyC18opZXlAhogpsCCnnBq7Mu5tHvNrOh DV7vsu8F5uQddvMf9rvFSeD+/MLQBHAH2DEvcmmP8q6NFwTOVt7ESJqAnnZNEhZj4A1Q 00zLD5yi34SFS2DTOuv52StMk9L4Ccg3tdI2de5iLpOKzNQ9OjtxoRLB2C6zJ5WFF6lK 7KOQ== X-Gm-Message-State: ALoCoQnaMbXiPJJy99hB+hkIEhyNySxpRCBHVnSbHrklMCFoL1/54Fhk/d+DCrCn2tbbdsPQPVln X-Received: by 10.194.78.204 with SMTP id d12mr31297325wjx.37.1421430158180; Fri, 16 Jan 2015 09:42:38 -0800 (PST) Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id n3sm6907786wja.36.2015.01.16.09.42.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Jan 2015 09:42:37 -0800 (PST) Message-ID: <54B94D71.90403@linaro.org> Date: Fri, 16 Jan 2015 17:42:09 +0000 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: Svatopluk Kraus , freebsd-arm@freebsd.org, Roger Pau Monne Subject: Re: interrupt framework References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 17:42:46 -0000 On 15/01/15 13:51, Svatopluk Kraus wrote: > Hi community, Hello, > I and Michal Meloun have done some work on ARM interrupt framework and > this is the result. > > We've started with intrng project with Ian's WIP changes, have looked > at Andrew's ARM64 git repository, and this is how we think an > interrupt framework should look like. We've implemented it with > removable interrupt controllers in mind (PCI world). It's not finished > from this point of view, however some functions are more complex > because of it. Is there any plan to make this framework generic across all the architectures? Some of our drivers as to create new interrupt controllers to handle event channel, it's an event notifications provided by Xen which is very similar to an interrupt (eoi/mask/unmask...). They are used by virtual devices in order to send/receive interrupts. The current code [1] already supports x86 which has a similar framework [2]. If your framework is used on all the architecture (especially ARM, ARM64 and x86), it would allow us to share the code between the architectures supported by Xen. Regards, [1] sys/x86/xen/xen_intr.c [2] sys/x86/x86/intr_machdep.c -- Julien Grall From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 18:10:03 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C65037A for ; Fri, 16 Jan 2015 18:10:03 +0000 (UTC) Received: from nm26-vm5.bullet.mail.ne1.yahoo.com (nm26-vm5.bullet.mail.ne1.yahoo.com [98.138.91.248]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 016EF861 for ; Fri, 16 Jan 2015 18:10:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1421431801; bh=A45M0IPp3lXOE3Dlpzgt2863uxPOFtfXKtv8ywVZs1I=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=X1LUwQNpXhmn6rBck5SAFze8pL48qQlJznqQRsyXgg0Kypa6udn2n6IGABFvjmHVVK2V2GjDz+fBJdXZbkFpth1GK6lt9jF0ocYYSZ0IKC68vOiLuloEOvXqij6EwJy2b0vz+SOk6ADxOUb75Q9G+4Pkp/UY8kwiy4ZmMh7EoYdFcNvhXF3HDjY2HhuTB9GThTDYnSCzyot6NrS6bTBvIIbEteweuz7/PSESyvisugyYYB8EZJ4ovmMjNK9o8o4wQBGK03RAg9SKxT1rGS1INYk8naCf8BJsE6MMkAxxZM3G17zqwj8u/yzMUdGeL2EfIacEmkdWdZguB8gH+EOFOA== Received: from [98.138.100.102] by nm26.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jan 2015 18:10:01 -0000 Received: from [98.138.226.127] by tm101.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jan 2015 18:10:01 -0000 Received: from [127.0.0.1] by smtp206.mail.ne1.yahoo.com with NNFMP; 16 Jan 2015 18:10:01 -0000 X-Yahoo-Newman-Id: 789558.43560.bm@smtp206.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: k_nl3agVM1kQxf9wIvyNqJnQlfGmTEXkfhLdA3ntjVVlmVS 5ros9id4.A1x_FTRUXy6Th4_jMNCzw2ksrPLJJn5E4AlHKCkyJNSXxHPXTMu 3Kf4ifmhF47o2zXQs5ncOWWLGeVFr3LGRzie3KX.BXxA0H1rtZyJQB7.LHoi f7X1vkzlwlcMEFA2v64b6e4WbO_on0V39mrwgThOHtDXK55yjnaDTLqgbYZF oniLvWXzDyPQoRMiFtvpT4.PL0PGZdLmRhgEDAsQ5RCqRM5LHXfDhtyMr.nx 9wNI49raLp.TkFjtHB0ewG6Pi_kyUL4M_.jcbpOIW3MqjGmMRxNpxEozAX1W Fq3UuYs9ZxxsmCQJJ2m_C1fBrWEz25Tu3KE9B.ZUEXv5xZCdiTv6m401R0u7 ecuQrkzGiZZHsi4y_nDUQ4SCsjx2tiugD1spxHBnkLWyUhb6rbojPAaUJnrA VBYuCGtc82TPEItP4em69BpL3nIyu3fl6Vfgb3hqkPRdwVKoLIH.5HreVqAR uEXWLcYkttc0otU2aMqq3lmN0h6Jlz0ixQIg.PtNGIyHIOJYgT7r9toRGzQ- - X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- Content-Type: multipart/mixed; boundary="Apple-Mail=_AAA02F0E-6E78-48B1-876D-03D6F8DE722D" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: mmap-issue From: Thomas Skibo In-Reply-To: <54B945FB.10609@freenet.de> Date: Fri, 16 Jan 2015 10:09:59 -0800 Message-Id: References: <54B945FB.10609@freenet.de> To: =?utf-8?Q?Manuel_St=C3=BChn?= X-Mailer: Apple Mail (2.1993) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 18:10:03 -0000 --Apple-Mail=_AAA02F0E-6E78-48B1-876D-03D6F8DE722D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 16, 2015, at 9:10 AM, Manuel St=C3=BChn = wrote: >=20 >=20 > I mapped for testing purposes the AM335x-GPIO-registers from /dev/mem. > Writing into these mmap'ed registers for toggling some LEDs does not = immediatly take effect. I have to call it several times to get one = LED-toggle. Is there any data caching I'm missing? >=20 > Thanks for hints. >=20 Yes. On arm, /dev/mem always maps pages into user space with the data = cache enabled. I=E2=80=99ve run into this too. To work around it, I ported some code from another architecture (I = can=E2=80=99t remember which) into sys/arm/arm/mem.c to allow = memcontrol(8) to declare some physical addresses as uncacheable. I = don=E2=80=99t know if this is a proper long-term solution. This patch has been lying around on my computer for a while and so I = haven=E2=80=99t tested it in a while. ------- Thomas Skibo thomasskibo@sbcglobal.net --Apple-Mail=_AAA02F0E-6E78-48B1-876D-03D6F8DE722D Content-Disposition: attachment; filename=patch.memrange.txt Content-Type: text/plain; name="patch.memrange.txt" Content-Transfer-Encoding: quoted-printable Index: sys/arm/arm/mem.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/arm/arm/mem.c (revision 269763) +++ sys/arm/arm/mem.c (working copy) @@ -68,9 +68,21 @@ /* * Used in /dev/mem drivers and elsewhere */ +static void arm_mrinit(struct mem_range_softc *); +static int arm_mrset(struct mem_range_softc *, struct mem_range_desc *, = int *); + MALLOC_DEFINE(M_MEMDESC, "memdesc", "memory range descriptors"); =20 -struct mem_range_softc mem_range_softc; +static struct mem_range_ops arm_mem_range_ops =3D { + arm_mrinit, + arm_mrset, + NULL, + NULL +}; +struct mem_range_softc mem_range_softc =3D { + &arm_mem_range_ops, + 0, 0, NULL +};=20 =20 /* ARGSUSED */ int @@ -152,12 +164,132 @@ =20 int memmmap(struct cdev *dev, vm_ooffset_t offset, vm_paddr_t *paddr, - int prot __unused, vm_memattr_t *memattr __unused) + int prot __unused, vm_memattr_t *memattr) { - if (dev2unit(dev) =3D=3D CDEV_MINOR_MEM) + int i; + + if (dev2unit(dev) =3D=3D CDEV_MINOR_KMEM) + *paddr =3D vtophys(offset); + else if (dev2unit(dev) =3D=3D CDEV_MINOR_MEM) { *paddr =3D offset; - else if (dev2unit(dev) =3D=3D CDEV_MINOR_KMEM) - *paddr =3D vtophys(offset); + + for (i =3D 0; i < mem_range_softc.mr_ndesc; i++) { + if ((mem_range_softc.mr_desc[i].mr_flags & + MDF_ACTIVE) !=3D 0 && + offset >=3D = mem_range_softc.mr_desc[i].mr_base && + offset < mem_range_softc.mr_desc[i].mr_base = + + mem_range_softc.mr_desc[i].mr_len && + (mem_range_softc.mr_desc[i].mr_flags & + MDF_ATTRMASK) =3D=3D MDF_UNCACHEABLE) { + *memattr =3D VM_MEMATTR_UNCACHEABLE; + break; + } + } + } /* else panic! */ return (0); } + +static void +arm_mrinit(struct mem_range_softc *sc) +{ + sc->mr_cap =3D 0; + sc->mr_ndesc =3D 8; /* XXX: Should be dynamically expandable */ + sc->mr_desc =3D malloc(sc->mr_ndesc * sizeof(struct = mem_range_desc), + M_MEMDESC, M_NOWAIT | M_ZERO); + if (sc->mr_desc =3D=3D NULL) + panic("%s: malloc returns NULL", __func__); +} + +static int +arm_mrset(struct mem_range_softc *sc, struct mem_range_desc *desc, int = *arg) +{ + int i; + + switch(*arg) { + case MEMRANGE_SET_UPDATE: + for (i =3D 0; i < sc->mr_ndesc; i++) { + if (!sc->mr_desc[i].mr_len) { + sc->mr_desc[i] =3D *desc; + sc->mr_desc[i].mr_flags |=3D MDF_ACTIVE; + return (0); + } + if (sc->mr_desc[i].mr_base =3D=3D desc->mr_base = && + sc->mr_desc[i].mr_len =3D=3D desc->mr_len) + return (EEXIST); + } + return (ENOSPC); + case MEMRANGE_SET_REMOVE: + for (i =3D 0; i < sc->mr_ndesc; i++) + if (sc->mr_desc[i].mr_base =3D=3D desc->mr_base = && + sc->mr_desc[i].mr_len =3D=3D desc->mr_len) { + bzero(&sc->mr_desc[i], = sizeof(sc->mr_desc[i])); + return (0); + } + return (ENOENT); + default: + return (EOPNOTSUPP); + } + + return (0); +} + +/* + * Operations for changing memory attributes. + * + * This is basically just an ioctl shim for mem_range_attr_get + * and mem_range_attr_set. + */ +/* ARGSUSED */ +int=20 +memioctl(struct cdev *dev __unused, u_long cmd, caddr_t data, int = flags, + struct thread *td) +{ + int nd, error =3D 0; + struct mem_range_op *mo =3D (struct mem_range_op *)data; + struct mem_range_desc *md; +=09 + /* is this for us? */ + if ((cmd !=3D MEMRANGE_GET) && + (cmd !=3D MEMRANGE_SET)) + return (ENOTTY); + + /* any chance we can handle this? */ + if (mem_range_softc.mr_op =3D=3D NULL) + return (EOPNOTSUPP); + + /* do we have any descriptors? */ + if (mem_range_softc.mr_ndesc =3D=3D 0) + return (ENXIO); + + switch (cmd) { + case MEMRANGE_GET: + nd =3D imin(mo->mo_arg[0], mem_range_softc.mr_ndesc); + if (nd > 0) { + md =3D (struct mem_range_desc *) + malloc(nd * sizeof(struct = mem_range_desc), + M_MEMDESC, M_WAITOK); + error =3D mem_range_attr_get(md, &nd); + if (!error) + error =3D copyout(md, mo->mo_desc,=20 + nd * sizeof(struct = mem_range_desc)); + free(md, M_MEMDESC); + } + else + nd =3D mem_range_softc.mr_ndesc; + mo->mo_arg[0] =3D nd; + break; + =09 + case MEMRANGE_SET: + md =3D (struct mem_range_desc *)malloc(sizeof(struct = mem_range_desc), + M_MEMDESC, = M_WAITOK); + error =3D copyin(mo->mo_desc, md, sizeof(struct = mem_range_desc)); + /* clamp description string */ + md->mr_owner[sizeof(md->mr_owner) - 1] =3D 0; + if (error =3D=3D 0) + error =3D mem_range_attr_set(md, = &mo->mo_arg[0]); + free(md, M_MEMDESC); + break; + } + return (error); +} Index: sys/arm/include/memdev.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/arm/include/memdev.h (revision 269763) +++ sys/arm/include/memdev.h (working copy) @@ -34,7 +34,7 @@ =20 d_open_t memopen; d_read_t memrw; +d_ioctl_t memioctl; d_mmap_t memmmap; -#define memioctl (d_ioctl_t *)NULL =20 #endif /* _MACHINE_MEMDEV_H_ */ --Apple-Mail=_AAA02F0E-6E78-48B1-876D-03D6F8DE722D-- From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 18:13:43 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C672C44F for ; Fri, 16 Jan 2015 18:13:43 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B06E948 for ; Fri, 16 Jan 2015 18:13:43 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1YCBOv-000Jp2-C6; Fri, 16 Jan 2015 18:13:41 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t0GIDdN9001965; Fri, 16 Jan 2015 11:13:40 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19VlaTS/qWJISkYMaYrcEJ2 Message-ID: <1421432019.14601.302.camel@freebsd.org> Subject: Re: mmap-issue From: Ian Lepore To: Manuel =?ISO-8859-1?Q?St=FChn?= Date: Fri, 16 Jan 2015 11:13:39 -0700 In-Reply-To: <54B945FB.10609@freenet.de> References: <54B945FB.10609@freenet.de> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id t0GIDdN9001965 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 18:13:43 -0000 On Fri, 2015-01-16 at 18:10 +0100, Manuel St=FChn wrote: > Hi, >=20 > I'm seeing unexpected behavior using mmap( /dev/mem ) on my beaglebone=20 > black. It seems to me, that writing to/reading from this mapped pointer= =20 > does not immediatly take effect. The code looks like this: >=20 > #define GPIO1 0x4804C000 > #define CLR_REG 0x190 > #define SET_REG 0x194 > #define LED0 21 > #define LED1 22 > #define LED2 23 > #define LED3 24 >=20 > int fd =3D open( "/dev/mem", O_RDWR ); >=20 > int pagesize =3D getpagesize(); >=20 > volatile uint32_t* ptr =3D > mmap( 0, pagesize, PROT_READ | PROT_WRITE, MAP_SHARED, fd, GPIO1_ADDR )= ; >=20 > ptr[SET_REG] =3D LED0 << 1; >=20 >=20 > I mapped for testing purposes the AM335x-GPIO-registers from /dev/mem. > Writing into these mmap'ed registers for toggling some LEDs does not=20 > immediatly take effect. I have to call it several times to get one=20 > LED-toggle. Is there any data caching I'm missing? >=20 > Thanks for hints. My gut-level reply is "Don't try to access hardware registers like that, you're only going to run into problems" (as you already have). But I've just been informed that linux allows such things. It seems crazy to me to allow userland access to the same hardware that freebsd drivers are trying to work with. So I think the right answer is that you should investigate using gpioctl and libgpio and the /dev/gpiocN devices. The direct answer to the problem you're seeing is probably that you need to flush the L2 cache write buffers to ensure that the writes make it all the way to the hardware, and there is no userland API for doing that. You may also be running into a problem related to an ARM restriction that a given physical address must not be mapped twice using different memory attributes, and those address ranges are already mapped by the kernel as Device memory, so remapping them as Normal memory via /dev/mem may result in the dreaded "undefined behavior." -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 18:48:53 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF56D6BA for ; Fri, 16 Jan 2015 18:48:53 +0000 (UTC) Received: from mwork.nabble.com (mwork.nabble.com [162.253.133.43]) by mx1.freebsd.org (Postfix) with ESMTP id BAA62D8E for ; Fri, 16 Jan 2015 18:48:53 +0000 (UTC) Received: from msam.nabble.com (unknown [162.253.133.85]) by mwork.nabble.com (Postfix) with ESMTP id D3A9810C2F1F for ; Fri, 16 Jan 2015 10:48:49 -0800 (PST) Date: Fri, 16 Jan 2015 11:48:47 -0700 (MST) From: Scott Ellis To: freebsd-arm@freebsd.org Message-ID: <1421434127781-5981309.post@n5.nabble.com> Subject: OMAP4 broken with r277215 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 18:48:53 -0000 I'm having problems booting systems built with r277215 on my OMAP4 boards. I haven't tried any other ARM boards. Systems built with r277214 are fine. r277215 committed some changes to loader for Xen multiboot support. I'm pretty sure the panic is coming from uboot_vm_translate() in sys/boot/uboot/lib/copy.c Rebuilding with some debugging now to track down the caller, but maybe someone has already fixed this. The boot hangs like this U-Boot SPL 2014.10 (Jan 16 2015 - 07:01:57) OMAP4430 ES2.3 reading u-boot.img reading u-boot.img U-Boot 2014.10 (Jan 16 2015 - 07:01:57) CPU : OMAP4430 ES2.3 Board: duovero I2C: ready DRAM: 1 GiB WARNING: Caches not enabled MMC: OMAP SD/MMC: 0 reading u-boot.env ** Unable to read "u-boot.env" from mmc0:1 ** Using default environment Net: smc911x-0 Warning: smc911x-0 using MAC address from net device reading uEnv.txt ** Unable to read file uEnv.txt ** Hit any key to stop autoboot: 0 Booting from: mmc 0 ubldr reading ubldr 262362 bytes read in 26 ms (9.6 MiB/s) ## Starting application at 0x88000074 ... Consoles: U-Boot console Compatible U-Boot API signature found @bef562a8 FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@fbsd, Fri Jan 16 11:59:13 EST 2015) DRAM: 1024MB MMC Device 1 not found MMC Device 1 not found Number of U-Boot devices: 2 U-Boot env: loaderdev='mmc 0' Found U-Boot device: disk Checking unit=0 slice= partition=... good. / /boot/kernel/kernel data=0x618688+0x43978 syms=[0x4+0x5f030+0x4+0x5a3d5] panic: Address offset 0x40000001 bigger than size 0x40000000 --> Press a key on the console to reboot <-- -- View this message in context: http://freebsd.1045724.n5.nabble.com/OMAP4-broken-with-r277215-tp5981309.html Sent from the freebsd-arm mailing list archive at Nabble.com. From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 19:10:55 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A5712DE for ; Fri, 16 Jan 2015 19:10:55 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EF9E7F8 for ; Fri, 16 Jan 2015 19:10:54 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1YCCIG-0004mx-Vh; Fri, 16 Jan 2015 19:10:53 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t0GJApTS002485; Fri, 16 Jan 2015 12:10:51 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+4KwdJhr3sgyv9tcBOxvUW Message-ID: <1421435451.14601.309.camel@freebsd.org> Subject: Re: OMAP4 broken with r277215 From: Ian Lepore To: Scott Ellis Date: Fri, 16 Jan 2015 12:10:51 -0700 In-Reply-To: <1421434127781-5981309.post@n5.nabble.com> References: <1421434127781-5981309.post@n5.nabble.com> Content-Type: multipart/mixed; boundary="=-rAwItr/nFANCf1CsU1Vz" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 19:10:55 -0000 --=-rAwItr/nFANCf1CsU1Vz Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, 2015-01-16 at 11:48 -0700, Scott Ellis wrote: > I'm having problems booting systems built with r277215 on my > OMAP4 boards. I haven't tried any other ARM boards. > > Systems built with r277214 are fine. > > r277215 committed some changes to loader for Xen multiboot support. > > I'm pretty sure the panic is coming from uboot_vm_translate() in > sys/boot/uboot/lib/copy.c > > Rebuilding with some debugging now to track down the caller, but > maybe someone has already fixed this. > > The boot hangs like this > > U-Boot SPL 2014.10 (Jan 16 2015 - 07:01:57) > OMAP4430 ES2.3 > reading u-boot.img > reading u-boot.img > > > U-Boot 2014.10 (Jan 16 2015 - 07:01:57) > > CPU : OMAP4430 ES2.3 > Board: duovero > I2C: ready > DRAM: 1 GiB > WARNING: Caches not enabled > MMC: OMAP SD/MMC: 0 > reading u-boot.env > > ** Unable to read "u-boot.env" from mmc0:1 ** > Using default environment > > Net: smc911x-0 > Warning: smc911x-0 using MAC address from net device > > reading uEnv.txt > ** Unable to read file uEnv.txt ** > Hit any key to stop autoboot: 0 > Booting from: mmc 0 ubldr > reading ubldr > 262362 bytes read in 26 ms (9.6 MiB/s) > ## Starting application at 0x88000074 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @bef562a8 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (root@fbsd, Fri Jan 16 11:59:13 EST 2015) > > DRAM: 1024MB > MMC Device 1 not found > MMC Device 1 not found > Number of U-Boot devices: 2 > U-Boot env: loaderdev='mmc 0' > Found U-Boot device: disk > Checking unit=0 slice= partition=... good. > / > /boot/kernel/kernel data=0x618688+0x43978 syms=[0x4+0x5f030+0x4+0x5a3d5] > panic: Address offset 0x40000001 bigger than size 0x40000000 > > --> Press a key on the console to reboot <-- Yeah, it's broken. A fix will be committed after a make universe completes, I'll attach the patch so you can get working again until then. -- Ian --=-rAwItr/nFANCf1CsU1Vz Content-Disposition: inline; filename="ubldrfix.diff" Content-Type: text/x-patch; name="ubldrfix.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit diff --git a/sys/boot/common/load_elf.c b/sys/boot/common/load_elf.c index 6860815..4c801e9 100644 --- a/sys/boot/common/load_elf.c +++ b/sys/boot/common/load_elf.c @@ -77,7 +77,7 @@ static int __elfN(lookup_symbol)(struct preloaded_file *mp, elf_file_t ef, const static int __elfN(reloc_ptr)(struct preloaded_file *mp, elf_file_t ef, Elf_Addr p, void *val, size_t len); static int __elfN(parse_modmetadata)(struct preloaded_file *mp, elf_file_t ef, - u_int64_t p_start, u_int64_t p_end); + Elf_Addr p_start, Elf_Addr p_end); static symaddr_fn __elfN(symaddr); static char *fake_modname(const char *name); @@ -300,7 +300,7 @@ __elfN(loadimage)(struct preloaded_file *fp, elf_file_t ef, u_int64_t off) Elf_Size size; u_int fpcopy; Elf_Sym sym; - u_int64_t p_start, p_end; + Elf_Addr p_start, p_end; dp = NULL; shdr = NULL; @@ -712,7 +712,7 @@ __elfN(load_modmetadata)(struct preloaded_file *fp, u_int64_t dest) Elf_Shdr *sh_data[2]; char *shstrtab = NULL; size_t size; - u_int64_t p_start, p_end; + Elf_Addr p_start, p_end; bzero(&ef, sizeof(struct elf_file)); ef.fd = -1; @@ -820,7 +820,7 @@ out: int __elfN(parse_modmetadata)(struct preloaded_file *fp, elf_file_t ef, - u_int64_t p_start, u_int64_t p_end) + Elf_Addr p_start, Elf_Addr p_end) { struct mod_metadata md; #if (defined(__i386__) || defined(__powerpc__)) && __ELF_WORD_SIZE == 64 --=-rAwItr/nFANCf1CsU1Vz-- From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 19:14:10 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFC065AC for ; Fri, 16 Jan 2015 19:14:10 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 9626F1CB for ; Fri, 16 Jan 2015 19:14:10 +0000 (UTC) Received: from zeppelin.tachypleus.net (airbears2-136-152-142-65.AirBears2.Berkeley.EDU [136.152.142.65]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id t0GJE3OL011150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 16 Jan 2015 11:14:03 -0800 Message-ID: <54B962FB.3060705@freebsd.org> Date: Fri, 16 Jan 2015 11:14:03 -0800 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: interrupt framework References: <54B94D71.90403@linaro.org> In-Reply-To: <54B94D71.90403@linaro.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZJJH8U6X51YdTlVKkAlZLzy0GWiQ98E3x4TrtyNRnHDa9zE3ZThqlh/AXzrF2+fATwj+/1pCfvvy4+2rgST3KSR1gEdGFwPgw= X-Sonic-ID: C;YC+V1bOd5BGordmh1eMT4g== M;sg/H1bOd5BGordmh1eMT4g== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 19:14:10 -0000 On 01/16/15 09:42, Julien Grall wrote: > On 15/01/15 13:51, Svatopluk Kraus wrote: >> Hi community, > Hello, > >> I and Michal Meloun have done some work on ARM interrupt framework and >> this is the result. >> >> We've started with intrng project with Ian's WIP changes, have looked >> at Andrew's ARM64 git repository, and this is how we think an >> interrupt framework should look like. We've implemented it with >> removable interrupt controllers in mind (PCI world). It's not finished >> from this point of view, however some functions are more complex >> because of it. > Is there any plan to make this framework generic across all the > architectures? > > Some of our drivers as to create new interrupt controllers to handle > event channel, it's an event notifications provided by Xen which is very > similar to an interrupt (eoi/mask/unmask...). They are used by virtual > devices in order to send/receive interrupts. > > The current code [1] already supports x86 which has a similar > framework [2]. > > If your framework is used on all the architecture (especially ARM, ARM64 > and x86), it would allow us to share the code between the architectures > supported by Xen. > > Regards, > > [1] sys/x86/xen/xen_intr.c > [2] sys/x86/x86/intr_machdep.c > This is very similar to the existing PowerPC code (a little better, based on a first glance) and should be adaptable at least to there. -Nathan From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 22:34:35 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BEB5D298 for ; Fri, 16 Jan 2015 22:34:35 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A5CAD9F8 for ; Fri, 16 Jan 2015 22:34:35 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0GMYZie068021 for ; Fri, 16 Jan 2015 22:34:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196660] [arm] multimedia/gstreamer1-libav fails to compile Date: Fri, 16 Jan 2015 22:34:35 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 22:34:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196660 --- Comment #4 from commit-hook@freebsd.org --- A commit references this bug: Author: sbruno Date: Fri Jan 16 22:34:23 UTC 2015 New revision: 377204 URL: https://svnweb.freebsd.org/changeset/ports/377204 Log: These ports utilize GAS assembly and probably won't ever change. For the ARM case, do not use -integrated-as. PR: 196660 196774 196775 196776 Submitted by: mikael.urankar@gmail.com Approved by: mentor (inplicit) Changes: head/multimedia/ffmpeg/Makefile head/multimedia/gstreamer1-libav/Makefile head/multimedia/libav/Makefile head/multimedia/mplayer/Makefile -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 22:34:39 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46E77309 for ; Fri, 16 Jan 2015 22:34:39 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2D522A06 for ; Fri, 16 Jan 2015 22:34:39 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0GMYd0P068078 for ; Fri, 16 Jan 2015 22:34:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196775] multimedia/ffmpeg: fails to build on armv6 Date: Fri, 16 Jan 2015 22:34:39 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: multimedia@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 22:34:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196775 --- Comment #3 from commit-hook@freebsd.org --- A commit references this bug: Author: sbruno Date: Fri Jan 16 22:34:24 UTC 2015 New revision: 377204 URL: https://svnweb.freebsd.org/changeset/ports/377204 Log: These ports utilize GAS assembly and probably won't ever change. For the ARM case, do not use -integrated-as. PR: 196660 196774 196775 196776 Submitted by: mikael.urankar@gmail.com Approved by: mentor (inplicit) Changes: head/multimedia/ffmpeg/Makefile head/multimedia/gstreamer1-libav/Makefile head/multimedia/libav/Makefile head/multimedia/mplayer/Makefile -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 22:34:41 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0061335F for ; Fri, 16 Jan 2015 22:34:40 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DC41BA0C for ; Fri, 16 Jan 2015 22:34:40 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0GMYeq3068110 for ; Fri, 16 Jan 2015 22:34:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196776] multimedia/libav: fails to build on armv6 Date: Fri, 16 Jan 2015 22:34:40 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 22:34:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196776 --- Comment #2 from commit-hook@freebsd.org --- A commit references this bug: Author: sbruno Date: Fri Jan 16 22:34:24 UTC 2015 New revision: 377204 URL: https://svnweb.freebsd.org/changeset/ports/377204 Log: These ports utilize GAS assembly and probably won't ever change. For the ARM case, do not use -integrated-as. PR: 196660 196774 196775 196776 Submitted by: mikael.urankar@gmail.com Approved by: mentor (inplicit) Changes: head/multimedia/ffmpeg/Makefile head/multimedia/gstreamer1-libav/Makefile head/multimedia/libav/Makefile head/multimedia/mplayer/Makefile -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 22:34:37 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9EB02B5 for ; Fri, 16 Jan 2015 22:34:37 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D18D9A03 for ; Fri, 16 Jan 2015 22:34:37 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0GMYbl9068067 for ; Fri, 16 Jan 2015 22:34:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196774] multimedia/mplayer: fails to build on armv6 Date: Fri, 16 Jan 2015 22:34:37 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: riggs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 22:34:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196774 --- Comment #3 from commit-hook@freebsd.org --- A commit references this bug: Author: sbruno Date: Fri Jan 16 22:34:24 UTC 2015 New revision: 377204 URL: https://svnweb.freebsd.org/changeset/ports/377204 Log: These ports utilize GAS assembly and probably won't ever change. For the ARM case, do not use -integrated-as. PR: 196660 196774 196775 196776 Submitted by: mikael.urankar@gmail.com Approved by: mentor (inplicit) Changes: head/multimedia/ffmpeg/Makefile head/multimedia/gstreamer1-libav/Makefile head/multimedia/libav/Makefile head/multimedia/mplayer/Makefile -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 22:34:54 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95621507 for ; Fri, 16 Jan 2015 22:34:54 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C8D6A18 for ; Fri, 16 Jan 2015 22:34:54 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0GMYsVE068185 for ; Fri, 16 Jan 2015 22:34:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196660] [arm] multimedia/gstreamer1-libav fails to compile Date: Fri, 16 Jan 2015 22:34:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 22:34:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196660 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 22:35:31 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 412DC5BA for ; Fri, 16 Jan 2015 22:35:31 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 28333A2C for ; Fri, 16 Jan 2015 22:35:31 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0GMZVof068455 for ; Fri, 16 Jan 2015 22:35:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196774] multimedia/mplayer: fails to build on armv6 Date: Fri, 16 Jan 2015 22:35:31 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: riggs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 22:35:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196774 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|In Progress |Closed -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 22:35:47 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A341F635 for ; Fri, 16 Jan 2015 22:35:47 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 89EE0A31 for ; Fri, 16 Jan 2015 22:35:47 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0GMZl48068536 for ; Fri, 16 Jan 2015 22:35:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196775] multimedia/ffmpeg: fails to build on armv6 Date: Fri, 16 Jan 2015 22:35:47 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: multimedia@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 22:35:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196775 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|In Progress |Closed -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 22:36:17 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA4A56C7 for ; Fri, 16 Jan 2015 22:36:17 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D20C2A43 for ; Fri, 16 Jan 2015 22:36:17 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0GMaHEk068788 for ; Fri, 16 Jan 2015 22:36:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 196776] multimedia/libav: fails to build on armv6 Date: Fri, 16 Jan 2015 22:36:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 22:36:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196776 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 23:34:55 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 739CD1CB; Fri, 16 Jan 2015 23:34:55 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E5B7F97; Fri, 16 Jan 2015 23:34:55 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id n12so1161042wgh.9; Fri, 16 Jan 2015 15:34:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=umxtFma3dLSgFYqzY9iBAbLM3n6xnYfxSDAE9aDvgyE=; b=HWO+Ud4YQ2Fh8pbJC1cwz9IoV4+vWFh5aO4vZilXg2APz2rkwB4rK63jAYoXOVOAVy 9eUkTMAaHFRwIXj/PQ3v2qG3fHs3ag+1iQThWXPIkET2pyN9D3Dt8lJCLmzdZFNrNFka a548z/EjEB/P4lCt7CnONsEmbDyZjvkYI9MxqP0ERF/PTVWWAv32FVUDHrtBo0+RtUgu 8aBK4QTl454Cas7IJcN8hAzxs8TT8Gb2OfGMz3zDFmWPRe0U3ed0td1FUgSrHlErOXEh 4u26YNZjs4tZ6Q9quDDzcl3ZnYj1MeOI0WQlbqAtpkT2UpZHef7B2ghUjNrFgm/l4BhQ 8Glw== MIME-Version: 1.0 X-Received: by 10.180.74.15 with SMTP id p15mr10960929wiv.29.1421451293583; Fri, 16 Jan 2015 15:34:53 -0800 (PST) Sender: johny.mattsson@gmail.com Received: by 10.27.82.83 with HTTP; Fri, 16 Jan 2015 15:34:53 -0800 (PST) In-Reply-To: <1421432019.14601.302.camel@freebsd.org> References: <54B945FB.10609@freenet.de> <1421432019.14601.302.camel@freebsd.org> Date: Sat, 17 Jan 2015 10:34:53 +1100 X-Google-Sender-Auth: mgspsCOTto0VGuYdCOn3cMxNYV0 Message-ID: Subject: Re: mmap-issue From: Johny Mattsson To: Ian Lepore Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 23:34:55 -0000 On 17 January 2015 at 05:13, Ian Lepore wrote: > My gut-level reply is "Don't try to access hardware registers like that, > you're only going to run into problems" (as you already have). But I've > just been informed that linux allows such things. Indeed it does, and what a life^Wproject-saver it can be! Only last year I had to deal with an existing large-scale deployment (100,000s of devices) where a peripheral on the SPI bus had a hardware bug where it could intermittently "lose" a clock pulse and get itself completely out of sync on the bus. Being able to quietly pull the SPI control from the driver and do a little dance on the clock and data lines in GPIO mode before returning control to the driver saved the day on that one. A few years before that, we had some extremely performance sensitive network I/O to deal with, where we effectively had a driver stub which allocated the resources and then allowed them to be mmap()ed into userspace for direct hardware control. Given the complexity of the system, it wasn't considered viable to have this processing done in the kernel. Another case is the Linux Raspberry Pi userpace library libbcm2835 which provides gpio control (among other things), similar to what you'd get normally through /sys/class/gpio but with two major distinctions: (a) it provides access to pull-up/downs, which is not normally available in Linux, and (b) it provides a whole different level of performance compared to going through the kernel. > It seems crazy to me > to allow userland access to the same hardware that freebsd drivers are > trying to work with. > Absolutely, and you can't complain if things break when you do. But having the ability to pull stunts like this is gold. Cheers, /Johny From owner-freebsd-arm@FreeBSD.ORG Sat Jan 17 03:48:39 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C58CD6AA for ; Sat, 17 Jan 2015 03:48:39 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8422ACE0 for ; Sat, 17 Jan 2015 03:48:38 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1YCKNI-0000Ka-Ri; Sat, 17 Jan 2015 03:48:37 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t0H3mZdM006761; Fri, 16 Jan 2015 20:48:35 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19p8qnkbBERA8ActfQyN0dK Message-ID: <1421466515.14601.323.camel@freebsd.org> Subject: Re: mmap-issue From: Ian Lepore To: Johny Mattsson Date: Fri, 16 Jan 2015 20:48:35 -0700 In-Reply-To: References: <54B945FB.10609@freenet.de> <1421432019.14601.302.camel@freebsd.org> Content-Type: multipart/mixed; boundary="=-unJQW8/bIhpk1ulCm/5l" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 03:48:40 -0000 --=-unJQW8/bIhpk1ulCm/5l Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sat, 2015-01-17 at 10:34 +1100, Johny Mattsson wrote: > On 17 January 2015 at 05:13, Ian Lepore wrote: > > > My gut-level reply is "Don't try to access hardware registers like that, > > you're only going to run into problems" (as you already have). But I've > > just been informed that linux allows such things. > > > Indeed it does, and what a life^Wproject-saver it can be! Only last year I > had to deal with an existing large-scale deployment (100,000s of devices) > where a peripheral on the SPI bus had a hardware bug where it could > intermittently "lose" a clock pulse and get itself completely out of sync > on the bus. Being able to quietly pull the SPI control from the driver and > do a little dance on the clock and data lines in GPIO mode before returning > control to the driver saved the day on that one. > > A few years before that, we had some extremely performance sensitive > network I/O to deal with, where we effectively had a driver stub which > allocated the resources and then allowed them to be mmap()ed into userspace > for direct hardware control. Given the complexity of the system, it wasn't > considered viable to have this processing done in the kernel. > That's a very different thing... a driver that exists primarily to give userland access to hardware can be written to map the memory correctly and presumably won't be accessing the hardware concurrently with userland and so on. It's a bit safer than just using /dev/mem to start bashing on hardware without any cooperation from the bits of the OS doing the same. Anyway, after glancing at the code implementing /dev/mem on freebsd arm I think it's woefully incomplete. It's basically a copy of the i386 code, which means it assumes that caches take care of themselves at some hardware level. What we need is something more like the PowerPC implementation that supports the ioctls documented in mem(4) for setting up uncached mappings. All in all, I think it could take a while to fix this properly. For the near term, the attached patch may be a reasonable(ish) hack to get device access to work. (Its drawback is that it can only detect device memory if it's part of the statically-mapped resources for the platform. On the plus side, for beaglebone all device memory is statically mapped in ti_machdep.c.) This is completely untested other than "it compiles." -- Ian --=-unJQW8/bIhpk1ulCm/5l Content-Disposition: inline; filename="devmem_uncacheable_hack.diff" Content-Type: text/x-patch; name="devmem_uncacheable_hack.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/arm/arm/mem.c =================================================================== --- sys/arm/arm/mem.c (revision 277262) +++ sys/arm/arm/mem.c (working copy) @@ -62,6 +62,7 @@ __FBSDID("$FreeBSD$"); #include #include +#include #include #include @@ -152,7 +153,7 @@ memrw(struct cdev *dev, struct uio *uio, int flags int memmmap(struct cdev *dev, vm_ooffset_t offset, vm_paddr_t *paddr, - int prot __unused, vm_memattr_t *memattr __unused) + int prot __unused, vm_memattr_t *memattr) { if (dev2unit(dev) == CDEV_MINOR_MEM) *paddr = offset; @@ -159,5 +160,7 @@ memmmap(struct cdev *dev, vm_ooffset_t offset, vm_ else if (dev2unit(dev) == CDEV_MINOR_KMEM) *paddr = vtophys(offset); /* else panic! */ + if (arm_devmap_ptov(*paddr, 4) != NULL) + *memattr = VM_MEMATTR_UNCACHEABLE; return (0); } --=-unJQW8/bIhpk1ulCm/5l-- From owner-freebsd-arm@FreeBSD.ORG Sat Jan 17 03:54:03 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CFA0717 for ; Sat, 17 Jan 2015 03:54:03 +0000 (UTC) Received: from mail.FoxValley.net (mail.FoxValley.net [64.135.192.34]) by mx1.freebsd.org (Postfix) with SMTP id EB2C3D8B for ; Sat, 17 Jan 2015 03:54:02 +0000 (UTC) Received: (qmail 19780 invoked from network) for freebsd-arm@freebsd.org; 16 Jan 2015 21:53:56 -0600 Received: from 97-118-51-160.hlrn.qwest.net (HELO ?192.168.1.3?) (draymond@97.118.51.160) by mail.foxvalley.net with SMTP; 16 Jan 2015 21:53:56 -0600 Message-ID: <54B9DCD1.3040306@foxvalley.net> Date: Fri, 16 Jan 2015 20:53:53 -0700 From: Dan Raymond User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: mount_smbfs Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 03:54:03 -0000 Any reason why mount_smbfs is missing? # ls -la /sbin/mount* -r-xr-xr-x 1 root wheel 20628 Nov 24 05:30 /sbin/mount -r-xr-xr-x 1 root wheel 10156 Nov 24 05:30 /sbin/mount_cd9660 -r-xr-xr-x 1 root wheel 14324 Nov 24 05:30 /sbin/mount_fusefs -r-xr-xr-x 2 root wheel 12200 Nov 24 05:30 /sbin/mount_mfs -r-xr-xr-x 1 root wheel 10896 Nov 24 05:30 /sbin/mount_msdosfs -r-xr-xr-x 2 root wheel 21164 Nov 24 05:30 /sbin/mount_nfs -r-xr-xr-x 1 root wheel 7200 Nov 24 05:30 /sbin/mount_nullfs -r-xr-xr-x 2 root wheel 21164 Nov 24 05:30 /sbin/mount_oldnfs -r-xr-xr-x 1 root wheel 8772 Nov 24 05:30 /sbin/mount_udf -r-xr-xr-x 1 root wheel 7852 Nov 24 05:30 /sbin/mount_unionfs From owner-freebsd-arm@FreeBSD.ORG Sat Jan 17 04:31:40 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4FB89AD6 for ; Sat, 17 Jan 2015 04:31:40 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtpout001.mac.com [17.172.220.236]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 25715224 for ; Sat, 17 Jan 2015 04:31:39 +0000 (UTC) Received: from [10.0.1.3] (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NIB00H1H0KEET20@st11p02mm-asmtp001.mac.com> for freebsd-arm@freebsd.org; Sat, 17 Jan 2015 04:31:29 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-01-17_01:2015-01-16,2015-01-17,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412080000 definitions=main-1501170048 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: mount_smbfs From: Rui Paulo In-reply-to: <54B9DCD1.3040306@foxvalley.net> Date: Fri, 16 Jan 2015 20:31:25 -0800 Content-transfer-encoding: quoted-printable Message-id: <4759EAA0-D4AA-4923-9350-B7E753819169@me.com> References: <54B9DCD1.3040306@foxvalley.net> To: Dan Raymond X-Mailer: Apple Mail (2.1993) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 04:31:40 -0000 On Jan 16, 2015, at 19:53, Dan Raymond wrote: >=20 > Any reason why mount_smbfs is missing? >=20 > # ls -la /sbin/mount* > -r-xr-xr-x 1 root wheel 20628 Nov 24 05:30 /sbin/mount > -r-xr-xr-x 1 root wheel 10156 Nov 24 05:30 /sbin/mount_cd9660 > -r-xr-xr-x 1 root wheel 14324 Nov 24 05:30 /sbin/mount_fusefs > -r-xr-xr-x 2 root wheel 12200 Nov 24 05:30 /sbin/mount_mfs > -r-xr-xr-x 1 root wheel 10896 Nov 24 05:30 /sbin/mount_msdosfs > -r-xr-xr-x 2 root wheel 21164 Nov 24 05:30 /sbin/mount_nfs > -r-xr-xr-x 1 root wheel 7200 Nov 24 05:30 /sbin/mount_nullfs > -r-xr-xr-x 2 root wheel 21164 Nov 24 05:30 /sbin/mount_oldnfs > -r-xr-xr-x 1 root wheel 8772 Nov 24 05:30 /sbin/mount_udf > -r-xr-xr-x 1 root wheel 7852 Nov 24 05:30 /sbin/mount_unionfs Probably because no one tested it on arm. Does it work for you if you = build it manually? -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Sat Jan 17 07:47:47 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A781B59 for ; Sat, 17 Jan 2015 07:47:47 +0000 (UTC) Received: from spazito3.arvixevps.com (spazito3.arvixevps.com [108.175.154.180]) (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 699F45FD for ; Sat, 17 Jan 2015 07:47:47 +0000 (UTC) Received: from diariodoestadoms by spazito3.arvixevps.com with local (Exim 4.84) (envelope-from ) id 1YCO6l-000CjH-Q6 for freebsd-arm@freebsd.org; Fri, 16 Jan 2015 23:47:47 -0800 To: freebsd-arm@freebsd.org Subject: Dear Beloved From: Madam Abra Jericho. Reply-To: mrsabrajerichofamily@gmail.com MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: Date: Fri, 16 Jan 2015 23:47:47 -0800 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - spazito3.arvixevps.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [505 504] / [47 12] X-AntiAbuse: Sender Address Domain - spazito3.arvixevps.com X-Get-Message-Sender-Via: spazito3.arvixevps.com: authenticated_id: diariodoestadoms/only user confirmed/virtual account not confirmed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 07:47:47 -0000 Dear Beloved I am Madam Abra Jericho.A complete citizen of the Philippines, widow to the late Mr Mayor Jericho who was a victim of the terrorist attack in my country.We were married for 7 years without a child and my late husband was a government contractor. Before his death he had a foreign account in Germany the sum of $7.8M. This deposit was coded under a secret arrangement as a family treasure. This means that the security company does not know the real content of this trunk box which he distinguished and deposited with a security company in Germany I want you to do me a favor to receive this funds to a safe account in your country or any safer place as the beneficiary. I have plans to do investment in your country,like real estate and industrial production and I plead you take it as personal task to assist the widow like me. This is my reason for writing to you.Please if you are willing to assist me indicate your interest in replying. Yours Madam Abra Jericho From owner-freebsd-arm@FreeBSD.ORG Sat Jan 17 13:58:50 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90803B2F; Sat, 17 Jan 2015 13:58:50 +0000 (UTC) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47F62B6B; Sat, 17 Jan 2015 13:58:50 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id k15so19024565qaq.9; Sat, 17 Jan 2015 05:58:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PFI/Xy+PXaOpuDoWeuXGWnyZUEj+6oEq8Sg0RiYThA8=; b=tQpvrssrUyBeekZV2FG/6E8qKZo6LXIOMuV/UzJ7wRhI/D+wpQ7OMt1tHUYYX0lU9A Jo0w8RCn+1088OqfQ31HJJxhWaqirSbUd0Em6nu+Js5KmVy6mbxww1EPsWSFI5c7hMg1 4tYdGhSNuOdQK4vywcRNLE74gzvtDLtteHIEPAZ3sDJ8Y8tpnumbaVc0za+IsA4JOdNU +EK1oY+kvqCKsTTf4O7x0o9Vps/KdcNHmxIfD+dHugIe/rX3YvNKfy+dgbQZrQrxIQ1b FlAdbq6EblvOeg9uRRYiRLMyMmDdCgb+goFY7oirRRMIrRFXbqoxzJQHkflMyeM+9Hn2 9TYA== MIME-Version: 1.0 X-Received: by 10.224.135.138 with SMTP id n10mr22492722qat.45.1421503129484; Sat, 17 Jan 2015 05:58:49 -0800 (PST) Received: by 10.140.82.180 with HTTP; Sat, 17 Jan 2015 05:58:49 -0800 (PST) In-Reply-To: <1421425153.14601.289.camel@freebsd.org> References: <20150115192624.122066dd@bender.lan> <20150116120315.7f343f66@bender.lan> <6E33C7B5-F784-4604-9F09-9FEDB1EFBE56@bsdimp.com> <1421425153.14601.289.camel@freebsd.org> Date: Sat, 17 Jan 2015 14:58:49 +0100 Message-ID: Subject: Re: interrupt framework From: Svatopluk Kraus To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 13:58:50 -0000 On Fri, Jan 16, 2015 at 5:19 PM, Ian Lepore wrote: > On Fri, 2015-01-16 at 08:34 -0700, Warner Losh wrote: >> > On Jan 16, 2015, at 5:03 AM, Andrew Turner wrot= e: >> > >> > On Fri, 16 Jan 2015 12:44:22 +0100 >> > Svatopluk Kraus wrote: >> > ... >> >> It's just a few things from quick look now which are different in our >> >> design. However, my intention is not read our code on behalf of you. = I >> >> still think that our design is more general mainly and can serve for >> >> interrupt controllers better. >> > >> > I was asking on the differences as I'm already in the process of >> > importing the arm_intrng project branch as I need something like it on >> > arm64. It is also based on the same code from Jakub and Ian, I haven't >> > looked at changing the design, just cleaning up the code to import int= o >> > head. >> > >> > I would be happy to merge your code instead, along with my existing >> > cleanups, however I would need to know why I should spend time on it a= s >> > opposed to the current development branch. If we do decide to with you= r >> > change I would like to import it into the arm_intrng project branch >> > first to assist the import into head. >> >> My first look at Svatopluk=E2=80=99s code and summaries, on its surface = it seems >> to be a simpler, more generalized and more effective design than intern. >> It avoids some additional overhead that=E2=80=99s always troubled me abo= ut intern >> that I=E2=80=99ve not had the time to make good suggestions to overcome.= It looks >> (again on its surface) easier to bring to all the architectures as well. >> >> I haven=E2=80=99t tried to use the code so I can=E2=80=99t comment on it= s stability. So of course >> I can=E2=80=99t measure the differences in interrupt latencies between t= he two. Both of >> these factors would be the kind of data that would help drive the decisi= on of which >> one to adapt. >> >> Warner > > I haven't looked at Svata's work recently, but in general he started > with the same sources that are now in the intrng branch and finished > work I was in the middle of (redoing IPI stuff) when I had to set it > aside. Based on other work done recently by Svata and Michal, I can > only imagine that they've improved on Jakub's and my earlier effort. > > My main concern for importing anything (Svata's version or the current > intrng branch) is for the Marvell code. It's the one that's a bit > different than other modern arm systems, for example it's the reason we > had the somewhat strange design for handling IPIs in the current code. > Unfortunately, I think none of us have hardare for testing except the > folks at Semihalf. > > -- Ian > We have looked at Marvell code before and think that all the strange design for handling IPIs in the current code could be moved to interrupt controller where it should be. It's the way we go. To not put internal things of any controller to framework and to not dictate various hacks done for one controller to others. Svata From owner-freebsd-arm@FreeBSD.ORG Sat Jan 17 14:07:58 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58C9CBD9; Sat, 17 Jan 2015 14:07:58 +0000 (UTC) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1112FC39; Sat, 17 Jan 2015 14:07:58 +0000 (UTC) Received: by mail-qg0-f45.google.com with SMTP id q107so661664qgd.4; Sat, 17 Jan 2015 06:07:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4z7dJV7zRlsLJB2mqzu3ilbn3YNWsEbHhOxacOcGF3k=; b=sIN1n4DXl0NnwXkOC2iJqGnyWmNhCV3Kj33r0lkn4flA5o+pdkYuSlvAFt/afEwWMN RFSF62MlUPMw57VpqsbshmKVuFwJSRkxVnOZ5q09zqUYUUXDksvPxTCTkmWrCg1AVz+V aKQsV2Zi6rjhQV965OmNQ0eNlJsld6BQZLzhvm88rcnWGh+BhDtfioXUuW6pcqw/YhKC F23b11vH8l+mv0P5VBhoaN1G/S9H0CR4Kuw5+RjuYma5ndCRYUQU7t0I7rrLKFv18zFx n4n4pBKnC/tXqFQCDlyVQUll8mcg04vOqoFj4FiMWkpMGo6qgy8fAnksbY+C/jDPQ9Fv GfpA== MIME-Version: 1.0 X-Received: by 10.224.67.132 with SMTP id r4mr34690222qai.1.1421503677185; Sat, 17 Jan 2015 06:07:57 -0800 (PST) Received: by 10.140.82.180 with HTTP; Sat, 17 Jan 2015 06:07:57 -0800 (PST) In-Reply-To: <1421425502.14601.294.camel@freebsd.org> References: <20150115192624.122066dd@bender.lan> <20150116120315.7f343f66@bender.lan> <1421425502.14601.294.camel@freebsd.org> Date: Sat, 17 Jan 2015 15:07:57 +0100 Message-ID: Subject: Re: interrupt framework From: Svatopluk Kraus To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 14:07:58 -0000 On Fri, Jan 16, 2015 at 5:25 PM, Ian Lepore wrote: > On Fri, 2015-01-16 at 17:08 +0100, Svatopluk Kraus wrote: >> On Fri, Jan 16, 2015 at 1:03 PM, Andrew Turner wrote: >> > On Fri, 16 Jan 2015 12:44:22 +0100 >> > Svatopluk Kraus wrote: >> > ... >> >> It's just a few things from quick look now which are different in our >> >> design. However, my intention is not read our code on behalf of you. I >> >> still think that our design is more general mainly and can serve for >> >> interrupt controllers better. >> > >> > I was asking on the differences as I'm already in the process of >> > importing the arm_intrng project branch as I need something like it on >> > arm64. It is also based on the same code from Jakub and Ian, I haven't >> > looked at changing the design, just cleaning up the code to import into >> > head. >> > >> > I would be happy to merge your code instead, along with my existing >> > cleanups, however I would need to know why I should spend time on it as >> > opposed to the current development branch. If we do decide to with your >> > change I would like to import it into the arm_intrng project branch >> > first to assist the import into head. >> > >> > Andrew >> >> >> Well, this is the main difference in our design: >> >> (1) We use one global table for all interrupt sources for framework >> needs. Each interrupt source is allocated only once and has been >> assigned to unique interrupt number from the beginning. >> > > While we don't have any existing examples of it, interrupt controllers > can actually come and go at runtime; they can be associated with hotplug > hardware. An example would be something like an i2c-based gpio extender > that can generate interrupts on its gpio pins. > > Does the single global table allow for hotplug things to be added? Even > trickier, what about when those things disappear later? I don't think > we need to support this right away, I'm just asking if supporting it > some day will be impossible or not. > > -- Ian > > Yes, we keep it in our minds. Michal reminds me of that at least once a day. ;) However, you know, we are in kernel. Interrupt framework does not support a removing of an interrupt handler (mean disappearing of handler code) without disabling of its source. The same way an interrupt controller cannot be detached without some actions done before. Svata From owner-freebsd-arm@FreeBSD.ORG Sat Jan 17 15:41:32 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F5AA1C9 for ; Sat, 17 Jan 2015 15:41:32 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 59B537C3 for ; Sat, 17 Jan 2015 15:41:32 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id bm13so19191943qab.0 for ; Sat, 17 Jan 2015 07:41:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yTKa2UXolt2fPHlPr55VLfAbna8hMvloaaxfNhtUQcY=; b=ZAE+qBMaJEZYNf4T3UVAhmxcp9IYOoObx8hxC9SJEQWvGFZXSM4WaPXms+OEDkYgcX zTagfZMLyY7htr8ezEO097KQ66mzqH7iscsMLplU8NQR/GUXe3coTJIwNjFLjBtEPqNV GELQiSfKDZKqUDMV16RiR8BASb9ewr07oI+/PJTVTluCWBC3faErBI5pxHSw8ZaxspiU yFWqAh9wyZT/I7PKPguNEs0bWo1VTSZ9WNnrimeO7uK/AcHETsSbDi2/gaFauqXwql0E Hcax+ROqO6HkxhCsiPovyDNuEgdF4UX9N0HUGmn8t6xQFBJbNIEiXEkKmVPU/BCKd4Ki ELDA== MIME-Version: 1.0 X-Received: by 10.224.95.71 with SMTP id c7mr10372976qan.70.1421509291535; Sat, 17 Jan 2015 07:41:31 -0800 (PST) Received: by 10.140.82.180 with HTTP; Sat, 17 Jan 2015 07:41:31 -0800 (PST) In-Reply-To: <54B94D71.90403@linaro.org> References: <54B94D71.90403@linaro.org> Date: Sat, 17 Jan 2015 16:41:31 +0100 Message-ID: Subject: Re: interrupt framework From: Svatopluk Kraus To: Julien Grall Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm@freebsd.org, Roger Pau Monne X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 15:41:32 -0000 On Fri, Jan 16, 2015 at 6:42 PM, Julien Grall wrote: > On 15/01/15 13:51, Svatopluk Kraus wrote: >> Hi community, > > Hello, > >> I and Michal Meloun have done some work on ARM interrupt framework and >> this is the result. >> >> We've started with intrng project with Ian's WIP changes, have looked >> at Andrew's ARM64 git repository, and this is how we think an >> interrupt framework should look like. We've implemented it with >> removable interrupt controllers in mind (PCI world). It's not finished >> from this point of view, however some functions are more complex >> because of it. > > Is there any plan to make this framework generic across all the > architectures? > > Some of our drivers as to create new interrupt controllers to handle > event channel, it's an event notifications provided by Xen which is very > similar to an interrupt (eoi/mask/unmask...). They are used by virtual > devices in order to send/receive interrupts. > > The current code [1] already supports x86 which has a similar > framework [2]. > > If your framework is used on all the architecture (especially ARM, ARM64 > and x86), it would allow us to share the code between the architectures > supported by Xen. > > Regards, > > [1] sys/x86/xen/xen_intr.c > [2] sys/x86/x86/intr_machdep.c > > -- > Julien Grall Yes, I forgot to get a credit to sys/x86/x86/intr_machdep.c as this is what we know for a long time. It's inspired us certainly. Thus our designs are very close from some points of view. And we have no problem to make some common interrupt framework across more architectures. However, if we will push too hard, the result could become too complex. And that is not our aim. We like simple frameworks if it's possible. Anyhow, it's not only about us. I do not know XEN architecture, so maybe I describe ARM architecture needs and you would tell me if there is a way for common framework. In ARM, interrupt tree is not same as bus (memory) tree. In other words, when you will go down a tree to its root thru standard bus methods because of looking for your interrupt controller, you likely will not find it. Thus there must be some other method how to describe where your controller is. In current, FTD is used for that. However, when FDT data is read, any interrupt controller does not have to be attached. Thus interrupt sources and their numbers are allocated in the order how are coded in FDT. (1) An interrupt source is allocated before its controller is attached in general. Thus an interrupt number (vector) must be allocated by framework itself and so must be its interrupt source. This interrupt number is more like resource handle and has nothing to do with a way how an interrupt source is represented in hardware. (2) As an interrupt number is transparent for a controller, a mapping function must exist for each type of interrupt description. On the other hand, considering identical points of our designs: (1) an interrupt source as a transparent framework description of an interrupt is common, (2) keeping interrupt sources in one global table is common, (3) using an interrupt source as an argument in controllers methods is common, (4) most controllers methods are common, however we use KOBJ methods instead of table of functions, (5) MI interrupt framework (kern_intr.c) using is common. Is it enough for some kind of common framework? I can imagine that standard bus methods like bus_setupintr() could be same to some extent, mapping functions could be same, controller's managing functions could be same, hmm, it looks that quite a lot of things could be same. However, it could just look like that on first look now. Svata From owner-freebsd-arm@FreeBSD.ORG Sat Jan 17 17:14:51 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7444F73 for ; Sat, 17 Jan 2015 17:14:51 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 95FCFFE7 for ; Sat, 17 Jan 2015 17:14:51 +0000 (UTC) Received: from zeppelin.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id t0HHEnt7007251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 17 Jan 2015 09:14:49 -0800 Message-ID: <54BA9888.1020303@freebsd.org> Date: Sat, 17 Jan 2015 09:14:48 -0800 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: interrupt framework References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYILl9qPw3xce2Zt8o804jovXr6kZaugHBorHa+gGpBtXZIGoEehJHJunia8SLV2Jc1CImXZkNBSuciPnnJatZxGrFByeyhSCI= X-Sonic-ID: C;wC+fV2ye5BG43Nmh1eMT4g== M;fLP6V2ye5BG43Nmh1eMT4g== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 17:14:51 -0000 On 01/15/15 05:51, Svatopluk Kraus wrote: > Hi community, > > I and Michal Meloun have done some work on ARM interrupt framework and > this is the result. > > We've started with intrng project with Ian's WIP changes, have looked > at Andrew's ARM64 git repository, and this is how we think an > interrupt framework should look like. We've implemented it with > removable interrupt controllers in mind (PCI world). It's not finished > from this point of view, however some functions are more complex > because of it. > > It's tested on pandaboard and only GIC is implemented now. There is no > problem to implement it to other controllers. We are open to questions > and can finish our work considering any comments. Whoever is waiting > for ARM interrupt framework as we were, you are welcome to test it. > Whoever is welcome. The patches are done against FreeBSD-11-current > revision 277210. There are two new files. > > ARM_INTRNG option must be added to board configuration file for new framework. > > There are still some things not implemented and some things which > should be discussed like PPI support. For example, how to enable PPI > interrupt on other CPUs when they are already running? > > We keep in mind that an interrupt framework should be helpfull but > general enough to not dictate interrupt controlles too much. Thus we > try to keep some things as much separated as possible. Each interrupt > is represented by an interrupt source (ISRC) in the framework. An ISRC > is described by an interrupt number which is much more an unique > resource handle - totally independent on internal representation of > interrupts in any interrupt controller. > > An interrupt is described by cells in FDT world. The cells can be > decoded only by associated interrupt controller and as such, they are > transparent for interrupt framework. The framework provides > arm_fdt_map_irq() function which maps this transparent cells to an > interrupt number. It creates an ISRC, saves cells on it, and once when > associated interrupt controller is registered, it provides the ISRC > with cells into the controller. > > It's a controller responsibility to save an ISRC associated with > cells. An ISRC is transparent for any controller. However, an > controller can set/get its data to/from an ISRC. Further, an > controller should set a name to an ISRC according to internal > representation of associated interrupt. > > An controller interrupt dispatch function can call framework only if > it has associated ISRC to received interrupt. > > For legacy reason, there is arm_namespace_map_irq() function. An > interrupt is described by namespace type and a number from the > namespace. It's intented for use with no FDT drivers. Now, it's used > for mapping an IPI on a controller. > > We think that it's better to call chained controllers (with filter > only) without MI interrupt framework overhead, so we implemented > shortcut. It could be utilized by INTR_SOLO flag during > bus_setup_intr(). > > Only an interrupt controller can really know its position in interrupt > controller's tree. So root controller must claim itself as a root. In > FDT world, according to ePAPR approved version 1.1 from 08 April 2011, > page 30: > > "The root of the interrupt tree is determined when traversal of the > interrupt tree reaches an interrupt controller node without an > interrupts property and thus no explicit interrupt parent." > > Thus there are no need for any non-standard things in DTS files. > > Svata > I took a look through intrng.c and had a couple comments about the FDT mapping stuff: 1. You use the device tree node handles as lookup keys rather than xref handles. These are not necessarily stable, so you should use xref handles instead. 2. If you make change (1), you don't depend on any OF_* stuff and can use the same code with the PIC node ID as an opaque key on non-FDT platforms. We do this on PowerPC as well, which has been very useful. It will also save some #ifdef. -Nathan From owner-freebsd-arm@FreeBSD.ORG Sat Jan 17 18:15:07 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0CB1C1E9 for ; Sat, 17 Jan 2015 18:15:07 +0000 (UTC) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CAA5F8AC for ; Sat, 17 Jan 2015 18:15:05 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 070796811E for ; Sun, 18 Jan 2015 03:14:57 +0900 (JST) Received: from artemis (unknown [172.18.0.21]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id D7A2268118 for ; Sun, 18 Jan 2015 03:14:56 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: References: <8B52D212B8274A619E32AB455C941860@ad.peach.ne.jp> In-Reply-To: <8B52D212B8274A619E32AB455C941860@ad.peach.ne.jp> Subject: Re: NAS4Free on Raspberry Pi and ARM problems Date: Sun, 18 Jan 2015 03:14:56 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 18:15:07 -0000 Hello, I have uploaded new version and recreated NAS4Free image based on it. All NAS4Free kernel changes are merged to r277169-20150114. Latest patched FreeBSD image by crochet-freebsd: http://www.peach.ne.jp/archives/rpi/FreeBSD-armv6-11.0-RPI-B-test22-r277169-20150114.img.gz http://www.peach.ne.jp/archives/rpi/patch/src-r277169-20150114.patch.gz Also, you can get latest test image of NAS4Free 9.3.0.2 for RPi(1GB SD card) from: http://www.peach.ne.jp/archives/nas4free/test/NAS4Free-rpi-SD-9.3.0.2.1300-20150116.img.gz You can upgrade NAS4Free from WebGUI by using this image: http://www.peach.ne.jp/archives/nas4free/test/NAS4Free-rpi-embedded-9.3.0.2.1300-20150116.img.xz Changes since 9.3.0.2.1295: switched to u-boot 2015.01 upgraded Netatalk 2.2.5 to 3.1.7 For other changes, please see SVN comit log Enjoy NAS4Free world yourself. Regards, -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Sat Jan 17 18:46:21 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4FD89759; Sat, 17 Jan 2015 18:46:21 +0000 (UTC) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1588FB2B; Sat, 17 Jan 2015 18:46:21 +0000 (UTC) Received: by mail-ob0-f169.google.com with SMTP id vb8so23700028obc.0; Sat, 17 Jan 2015 10:46:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BH6E56fjJ9PzQ7FmZP0e3wyHicOTCwzvbIKGT209y8s=; b=FPeLWJ7YCsfpMJP4yov7NmG1P6xqbgx4LzET+RtCwzrEH/av+qrqOJfQ3GUphAXABG m9UmtTz8rzwwqGYujCX44JDSWpP9rEbq0qOfK7T3dC+rYOOrMHaCcZT6o2InULCbx/S6 Zro+haeEEnEO3WS+HRsV+2JZJklZHWa+4rO1aAQ4zwIuw2tavY7Ni+3QH+jJgBHyvoql SaFETKlra4AaFXJlLBTnzn2cdZustTRsYdPKhb4Jfe4yymFx5NdsMz/SlkMoNg6oUOn1 ycu30lWyX/onowltpLQJMndqXVlYFIIGORQAGegoVLJUCDTikPmRX6j92eBeWPAJV3My oIZQ== MIME-Version: 1.0 X-Received: by 10.60.229.163 with SMTP id sr3mr13234561oec.29.1421520380357; Sat, 17 Jan 2015 10:46:20 -0800 (PST) Received: by 10.76.86.42 with HTTP; Sat, 17 Jan 2015 10:46:20 -0800 (PST) In-Reply-To: References: Date: Sat, 17 Jan 2015 18:46:20 +0000 Message-ID: Subject: Re: Raspberry Pi stability improved From: "Sevan / Venture37" To: Michael Tuexen Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 18:46:21 -0000 On 14 January 2015 at 21:46, Michael Tuexen wrote: > Dear all, > > I just wanted you let you know that FreeBSD head on the Raspberry Pi > is much more stable now. I've tested r277054 and was able to > portsnap fetch and extract and build the ports for git/subversion/vim > without any problems using a Raspberry Pi B with an SD card. > It took a day or two... > All tests I did before where less stable. Most of the times the machine > crashed when doing the portsnap stuff. Hi Michael, That's really cool, I look forward to trying new snapshots, by the way, what sorts of issues needed to be resolved to stablise it? Sevan / Venture37 From owner-freebsd-arm@FreeBSD.ORG Sat Jan 17 19:21:06 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B08ACA9 for ; Sat, 17 Jan 2015 19:21:06 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C2AB4E15 for ; Sat, 17 Jan 2015 19:21:05 +0000 (UTC) Received: from [192.168.1.200] (p54818DD9.dip0.t-ipconnect.de [84.129.141.217]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 237BC1C104355; Sat, 17 Jan 2015 20:21:01 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: Raspberry Pi stability improved From: Michael Tuexen In-Reply-To: Date: Sat, 17 Jan 2015 20:20:58 +0100 Content-Transfer-Encoding: 7bit Message-Id: <68465952-447A-4509-B97C-7C1BAE1FFF5D@freebsd.org> References: To: Sevan / Venture37 X-Mailer: Apple Mail (2.1993) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 19:21:06 -0000 > On 17 Jan 2015, at 19:46, Sevan / Venture37 wrote: > > On 14 January 2015 at 21:46, Michael Tuexen wrote: >> Dear all, >> >> I just wanted you let you know that FreeBSD head on the Raspberry Pi >> is much more stable now. I've tested r277054 and was able to >> portsnap fetch and extract and build the ports for git/subversion/vim >> without any problems using a Raspberry Pi B with an SD card. >> It took a day or two... >> All tests I did before where less stable. Most of the times the machine >> crashed when doing the portsnap stuff. > > > Hi Michael, > That's really cool, I look forward to trying new snapshots, by the > way, what sorts of issues needed to be resolved to stablise it? I'm not sure what you are asking... It is now very stable (it didn't crash at all up to now). I guess https://svnweb.freebsd.org/changeset/base/277038 made a difference... Best regards Michael > > > Sevan / Venture37 > From owner-freebsd-arm@FreeBSD.ORG Sat Jan 17 20:04:41 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96214793; Sat, 17 Jan 2015 20:04:41 +0000 (UTC) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26FDB223; Sat, 17 Jan 2015 20:04:41 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id l61so3660819wev.8; Sat, 17 Jan 2015 12:04:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1LxeXSsvxZ8SCoQvJFaHf+OVLPier7o9IcVMvv/Uoak=; b=WdFivBODh8c6+BtXu9+LwkpwwGxkZEq1vSBj9Pj/037bYwW3oZ8Xb+yjfcBO0TjgIL HIQpUYX3LKNF5VzSUGjmRMCbk3SJNekgs2tOPhDTBi+xIyZqRQbnSc6QMj7NyvGO4NXm JhU5FL0Vf4FM6GdJ6ZA194v7Fmap+EsfcWr8qiNdZ8QIb2UFg0I7MN5agko+Bac0jLor ZZ3w2at+oY/+BtWudxTj/Ywrsz3/PyMLW6JZD9ElrxPr6ksgemopqA4vJ6yeZ0HV+Rye cMqr5wVqBp9xSAWKcubKoKmSRnwXVxTtn6Q8OnOkNNrWZPcS7Fopp7vpt7NAEzACF/Cd qIlQ== X-Received: by 10.180.205.163 with SMTP id lh3mr19132305wic.63.1421525079641; Sat, 17 Jan 2015 12:04:39 -0800 (PST) Received: from Sevans-MacBook-Pro.local (cpc3-dals5-0-0-cust240.20-2.cable.virginm.net. [77.103.176.241]) by mx.google.com with ESMTPSA id fp2sm7838163wib.8.2015.01.17.12.04.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Jan 2015 12:04:38 -0800 (PST) Message-ID: <54BAC055.9050107@gmail.com> Date: Sat, 17 Jan 2015 20:04:37 +0000 From: Sevan / Venture37 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Michael Tuexen Subject: Re: Raspberry Pi stability improved References: <68465952-447A-4509-B97C-7C1BAE1FFF5D@freebsd.org> In-Reply-To: <68465952-447A-4509-B97C-7C1BAE1FFF5D@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 20:04:41 -0000 On 17/01/2015 19:20, Michael Tuexen wrote: > I'm not sure what you are asking... It is now very stable (it didn't > crash at all up to now). I guess > https://svnweb.freebsd.org/changeset/base/277038 > made a difference... I was asking for more technical background to the problem which was solved, for me it has been a long standing issue. portsnap alfred has never succeeded sucessfully on my Pi so I was pleased to read your post as it would result in a hard lock whenever I tried it. Sevan / Venture37