From owner-freebsd-arm@FreeBSD.ORG Sun Jan 12 06:01:34 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0A30357; Sun, 12 Jan 2014 06:01:34 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 88F3D1775; Sun, 12 Jan 2014 06:01:34 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id bj1so2573430pad.36 for ; Sat, 11 Jan 2014 22:01:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=cYLrFrKrBdlOlqB/790pO2mKclbopafEBiWyv/Oli10=; b=xrK4BgJVcYlCnzJ+PJJMh4IOn5yW7N2CnVwaIwdhtXy1/9H6GVzPiDSsblL4aGasMd n6z6EORn+MJ9ywxof+55NVyKdwU2LjMvG2LrTNDPTO0XQpzrBkTRq4nBS6XmIzCF2yEd DmWvE8ab4vFBnjL8b72Az2pPyYN6FhgUfu4aOpbwTa0WfUU7/lQXgIpuffrslV/wi5iA P1StJP0OWNR+uJrQpTeX3MU/sEdDEgO1Q2O8er9wMjMuinSJvQAEnRFYPncl4P7Sxmif lumHg2dlHXv6LCrg3DHDTgS1WDGnCJRdPmOWehRJ1OcbVA5Jd1fBiV8ws97NMiI2JaJ/ hvHA== X-Received: by 10.66.43.135 with SMTP id w7mr21828593pal.97.1389506494233; Sat, 11 Jan 2014 22:01:34 -0800 (PST) Received: from [10.0.0.116] (76-244-36-134.lightspeed.sntcca.sbcglobal.net. [76.244.36.134]) by mx.google.com with ESMTPSA id vn10sm28615812pbc.21.2014.01.11.22.01.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 11 Jan 2014 22:01:32 -0800 (PST) References: <1382734990.1170.132.camel@revolution.hippie.lan> <1382738462.1170.153.camel@revolution.hippie.lan> <1389153310.1158.349.camel@revolution.hippie.lan> Mime-Version: 1.0 (1.0) In-Reply-To: <1389153310.1158.349.camel@revolution.hippie.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <71A23BDB-671B-4D66-84C5-23A978CF8BA9@gmail.com> X-Mailer: iPad Mail (11B554a) From: Steve Subject: Re: Dreamplug stable/10 usb - sd file transfer corruption error - cache related? Date: Sat, 11 Jan 2014 22:01:34 -0800 To: Ian Lepore Cc: "freebsd-arm@FreeBSD.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 06:01:34 -0000 Ian, Thanks for testing this out on your setup. Given that you can't reproduce t= he problem, I guess it's either a bug that's been eliminated from the 10 sta= ble branch over the last few months, or some specific problem with my hardwa= re (maybe driver issue specific to my thumb drive). If I get a chance to re= visit this and get any useful data out of it I'll let you know. - Steven Sent from my iPad > On Jan 7, 2014, at 7:55 PM, Ian Lepore wrote: >=20 > Oddly enough, I never forgot about this, I just never got to it until > today. I put a concerted effort into getting data corruption on > usb->usb copying of files and even entire filesystems, and couldn't get > a glitch. I used the external sdcard (da1) and a thumb drive. I used > 'mtree -ck md5' on both source and destination, then diff'd the results, > and the files were all identical. >=20 > I tested with 11-current (@r260393) and 10-stable (@r260394) on my > DreamPlug, compiled with clang-eabi in both cases. >=20 > -- Ian >=20 >> On Fri, 2013-10-25 at 18:40 -0700, Steven Lee wrote: >> Ian, thanks for taking a look to see if you can recreate the problem. In= >> case it makes any difference in behavior, the >> command I used for the transfer was: >>=20 >> (dump -0Lf - /) | (cd /mnt/flash_root ; restore -rf -) >>=20 >> with /dev/da2s2 mounted at / and /dev/da0s2 mounted at /mnt/flash_root >>=20 >> Regards, >>=20 >> Steve >>> On Fri, Oct 25, 2013 at 3:01 PM, Ian Lepore wrote: >>>=20 >>> That old advice was based on bugs in old code that has been fixed. I've= >>> just been double-checking that the various fixes are in 10 (some of them= >>> were things I submitted a PR for before I became a committer). I'm not >>> sure about the usb driver, but there have been big changes in the dma >>> cache coherency code between 9 and 10, although much of that is the >>> fixes I was alluding to. >>>=20 >>> Basically what you're doing is a usb->usb copy, I'll see if I can >>> recreate the corruption on my dreamplug here the same way. >>>=20 >>> -- Ian >>>=20 >>>> On Fri, 2013-10-25 at 14:38 -0700, Steven Lee wrote: >>>> ---------- Forwarded message ---------- >>>> From: Steven Lee >>>> Date: Fri, Oct 25, 2013 at 2:37 PM >>>> Subject: Re: Dreamplug stable/10 usb - sd file transfer corruption erro= r >>> - >>>> cache related? >>>> To: Ian Lepore >>>>=20 >>>>=20 >>>> Ian, thanks for your reply. >>>>=20 >>>> I am using the DREAMPLUG-1001 stock kernel config, and you are right th= e >>>> internal sd card shows up as a usb device, /dev/da0. >>>>=20 >>>> As I mentioned, I tried modifying pmap.c as per one of your suggestions= >>> to >>>> an earlier poster / problem, but it didn't seem to help the issue. I >>>> changed the pmap_pte_init_arm10() function to look like the >>>> pmap_pte_init_arm9() function. >>>>=20 >>>> Any other thoughts about things to try? Since it seems like this is a >>>> regression between 9 and 10, are you aware of any specific cache relate= d >>>> changes to the usb driver between the branches? >>>>=20 >>>> - Steve >>>>=20 >>>>=20 >>>>> On Fri, Oct 25, 2013 at 2:03 PM, Ian Lepore wrote: >>>>>=20 >>>>>> On Fri, 2013-10-25 at 13:37 -0700, Steven Lee wrote: >>>>>> Hello, >>>>>>=20 >>>>>> In the process of upgrading my Dreamplug from the stable/9 branch to >>> the >>>>>> stable/10 branch, I have run into a fairly >>>>>> significant file corruption problem. The steps that create this >>> problem >>>>>> are as follows: >>>>>>=20 >>>>>> 1. Cross-compile the kernel and buildworld from the stable/10 branch >>> on a >>>>>> separate host. >>>>>> 2. Install the kernel and installworld on a usb stick drive >>>>>> 3. Boot the Dreamplug from the usb drive >>>>>>=20 >>>>>> There are no problems that show up to this point, the Dreamplug boots= >>>>> with >>>>>> no errors. >>>>>>=20 >>>>>> 4. Copy the kernel from the usb drive to the internal sd card >>>>>> 5. Copy the root filesystem from the usb drive to the internal sd >>> card >>>>>> using (dump | restore) >>>>>>=20 >>>>>> It is at step 5 that the error manifests itself, as I found that >>>>>> approximately 20 shell scripts in the /etc/rc.d directory >>>>>> had been randomly corrupted with strings of null characters (in >>> groups of >>>>>> 32). I assume that the rest of the file system >>>>>> was compromised in a similar fashion. The bug is repeatable, >>> however the >>>>>> corruption is somewhat random, so >>>>>> each time different files are corrupted in different places. >>>>>>=20 >>>>>> When I followed the exact same steps from the stable/9 branch, the >>>>> problem >>>>>> did not occur, so there is clearly some >>>>>> type of regression error between the 9 and 10 branches. >>>>>>=20 >>>>>> After searching through the arm mailing list, I attempted to work >>> around >>>>>> the problem by: >>>>>> - mounting the file systems with -o noclusterr -o noclusterrw >>>>>> - mounting the file systems with -o sync >>>>>> - as per comments on bug arm/158950, attempted to modify the pmap.c >>>>>> functions to change the cache from >>>>>> write-back mode to write-through mode >>>>>>=20 >>>>>> but all of these attempts were ineffective. >>>>>>=20 >>>>>> Given that I am relatively new to FreeBSD, I was hoping to get any >>>>> insights >>>>>> as to any next steps that might make >>>>>> sense in terms of either working around the problem, narrowing down >>> the >>>>>> bug, or any obvious rookie mistakes I >>>>>> am making before I give up and revert back to the 9 branch. >>>>>>=20 >>>>>> Thanks for your help! >>>>>>=20 >>>>>> Regards, >>>>>=20 >>>>> On my dreamplug (model 1001) both the internal and external sd cards >>> are >>>>> actually usb devices (they show up as /dev/da0 and da1, not mmcsd0/1).= >>>>> I'm not sure if that's true on all models or not. >>>>>=20 >>>>> Are you using the stock kernel config (DREAMPLUG-1001)? If not, have >>>>> you got "option USB_HOST_ALIGN=3D32" in your kernel config? >>>>>=20 >>>>> Corruption in 32 byte chunks is almost always partial cacheline flush >>>>> problems, but I haven't seen that happen on dreamplug for a long time >>>>> (and when I did see it, it was with a sata drive). >>>>>=20 >>>>> -- Ian >>>> _______________________________________________ >>>> 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" >=20 >=20 From owner-freebsd-arm@FreeBSD.ORG Sun Jan 12 11:25:28 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D1F5724; Sun, 12 Jan 2014 11:25:28 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D5FE9194D; Sun, 12 Jan 2014 11:25:27 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id b13so5379395wgh.19 for ; Sun, 12 Jan 2014 03:25:26 -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=istksU+DBBDptg2iacA3uhD4DJqdAK1oMyGUW3z2pY4=; b=rLUD+/8H/tUfoguhRqEKnH9QDxOe8/E50WqdiHG4aujyIIcTUswXZp2IvTFF1NFx1n jDtXKv4jzTY2R3H+Q1r2xZsv5vlHNj8M4JZX1tOHCwZ4+had+Jx9SFRA1dR3Ff8M147b sFNzBJyvTZgE+SZMJltg0BFiVXa3ZYmTSalJzj+e1gNlYsuL6IQIBH8KvziAo6KEvBBE LJaDfVmwFJXzGUNmlx39A7urCuBCSR62rHDPjuPD0+QXnv/MHyrLDZb8MqCTAt2bj8WU jx8VqaBO1bdJz0Yub51b75sraF74ST28XifEqgNbqk4LfSxEci9XbyS4wAZwFPF+dFF6 5qEg== MIME-Version: 1.0 X-Received: by 10.180.12.115 with SMTP id x19mr10635296wib.49.1389525926157; Sun, 12 Jan 2014 03:25:26 -0800 (PST) Received: by 10.217.114.10 with HTTP; Sun, 12 Jan 2014 03:25:26 -0800 (PST) In-Reply-To: <20140111205303.GZ46596@funkthat.com> References: <201311210108.rAL18AoQ051365@svn.freebsd.org> <20131221061048.GC99167@funkthat.com> <20140108071643.GB99167@funkthat.com> <1389197091.1158.370.camel@revolution.hippie.lan> <20140108173909.GF99167@funkthat.com> <20140110230241.GS46596@funkthat.com> <20140111135156.251a70fa@bender.Home> <20140111205303.GZ46596@funkthat.com> Date: Sun, 12 Jan 2014 12:25:26 +0100 Message-ID: Subject: Re: svn commit: r258412 - in head/sys/arm: at91 econa s3c2xx0 sa11x0 xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa From: Berislav Purgar To: Andrew Turner , Ian Lepore , "freebsd-arm@freebsd.org" , andrew@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 11:25:28 -0000 On Sat, Jan 11, 2014 at 9:53 PM, John-Mark Gurney wrote: > > I have verified that this patch allows me to boot a kernel till it > mounts root... As I haven't put together a root fs yet, I can't say > if it goes to single/multiuser yet... > > Thanks! > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > 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" > Hello . I confirm that this patch works but i got panic when traying to mount root fs . NFS ROOT: 10.42.1.1:/data/freebsd/gateworks Interface npe0 IP-Address 10.42.1.15 Broadcast 10.42.1.255 Setting hostuuid: de4c14a8-7b7b-11e3-b57a-00d012035923. Setting hostid: 0x3b43b7a9. No suitable dump device was found. Entropy harvesting: interrupts ethernet point_to_point swi. Starting file system checks: Fatal kernel mode data abort: 'Alignment Fault 3' trapframe: 0xcd17dc90 FSR=00000003, FAR=c120926c, spsr=60000013 r0 =00000000, r1 =0000026c, r2 =00000000, r3 =00000000 r4 =00000000, r5 =00000000, r6 =c12867e0, r7 =c122fec0 r8 =c10dc100, r9 =00000000, r10=00000001, r11=c1209000 r12=c0666c38, ssp=cd17dce0, slr=000000f9, pc =c046fa08 [ thread pid 63 tid 100046 ] Stopped at vn_seek+0x298: und 0xe18b20f1 full dump is here : http://pastebin.com/HPHFgeFs http://pastebin.com/tu6gKaGb Beri From owner-freebsd-arm@FreeBSD.ORG Sun Jan 12 19:45:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F56DF2B for ; Sun, 12 Jan 2014 19:45:40 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 33D6C1B38 for ; Sun, 12 Jan 2014 19:45:40 +0000 (UTC) Received: from bender.Home (97e07ae8.skybroadband.com [151.224.122.232]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 476185E303 for ; Sun, 12 Jan 2014 19:45:39 +0000 (UTC) Date: Sun, 12 Jan 2014 19:45:32 +0000 From: Andrew Turner To: freebsd-arm@freebsd.org Subject: Using VFP registers in the msun fenv functions Message-ID: <20140112194532.27366e43@bender.Home> 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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 19:45:40 -0000 I'm working on merging in my hard-float changes into head. As part of this I have updated msun to use both the softfloat and, when available, the vfp environment. I've done minimal testing, i.e. compiling and running a simple rootfs with it. I would appreciate it if people with more knowledge in this area could check over the patch, and try to run it against any floating-point code they have to check it still works as expected. The patch is available from [1] Andrew [1] http://people.freebsd.org/~andrew/armv6fenv2.diff From owner-freebsd-arm@FreeBSD.ORG Mon Jan 13 05:52:24 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41C04B82; Mon, 13 Jan 2014 05:52:24 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EB6021586; Mon, 13 Jan 2014 05:52:23 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s0D5qG5H021046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Jan 2014 21:52:16 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s0D5qFXc021045; Sun, 12 Jan 2014 21:52:15 -0800 (PST) (envelope-from jmg) Date: Sun, 12 Jan 2014 21:52:15 -0800 From: John-Mark Gurney To: Berislav Purgar Subject: Re: svn commit: r258412 - in head/sys/arm: at91 econa s3c2xx0 sa11x0 xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa Message-ID: <20140113055215.GB2982@funkthat.com> Mail-Followup-To: Berislav Purgar , Andrew Turner , Ian Lepore , "freebsd-arm@freebsd.org" References: <201311210108.rAL18AoQ051365@svn.freebsd.org> <20131221061048.GC99167@funkthat.com> <20140108071643.GB99167@funkthat.com> <1389197091.1158.370.camel@revolution.hippie.lan> <20140108173909.GF99167@funkthat.com> <20140110230241.GS46596@funkthat.com> <20140111135156.251a70fa@bender.Home> <20140111205303.GZ46596@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 12 Jan 2014 21:52:16 -0800 (PST) Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 05:52:24 -0000 Berislav Purgar wrote this message on Sun, Jan 12, 2014 at 12:25 +0100: > On Sat, Jan 11, 2014 at 9:53 PM, John-Mark Gurney wrote: > > > I have verified that this patch allows me to boot a kernel till it > > mounts root... As I haven't put together a root fs yet, I can't say > > if it goes to single/multiuser yet... > > I confirm that this patch works but i got panic when traying to mount root > fs . > > NFS ROOT: 10.42.1.1:/data/freebsd/gateworks > > Interface npe0 IP-Address 10.42.1.15 Broadcast 10.42.1.255 > > Setting hostuuid: de4c14a8-7b7b-11e3-b57a-00d012035923. > > Setting hostid: 0x3b43b7a9. > > No suitable dump device was found. > > Entropy harvesting: interrupts ethernet point_to_point swi. > > Starting file system checks: > > Fatal kernel mode data abort: 'Alignment Fault 3' > > trapframe: 0xcd17dc90 > > FSR=00000003, FAR=c120926c, spsr=60000013 > > r0 =00000000, r1 =0000026c, r2 =00000000, r3 =00000000 > > r4 =00000000, r5 =00000000, r6 =c12867e0, r7 =c122fec0 > > r8 =c10dc100, r9 =00000000, r10=00000001, r11=c1209000 > > r12=c0666c38, ssp=cd17dce0, slr=000000f9, pc =c046fa08 > > > > [ thread pid 63 tid 100046 ] > > Stopped at vn_seek+0x298: und 0xe18b20f1 > > > full dump is here : > http://pastebin.com/HPHFgeFs > http://pastebin.com/tu6gKaGb So, I was able to reproduce this... und 0xe18b20f1 is actually strd, and it's trying to store a 64bit value into a misaligned pointer... We are casting td_retval to an off_t, but td_retval is a register_t (or 32bit aligned) and off_t is a 64bit value. It became unaligned a number of months ago... I was able to boot using this patch: Index: sys/sys/proc.h =================================================================== --- sys/sys/proc.h (revision 260580) +++ sys/sys/proc.h (working copy) @@ -300,7 +300,7 @@ TDS_RUNQ, TDS_RUNNING } td_state; /* (t) thread state */ - register_t td_retval[2]; /* (k) Syscall aux returns. */ + register_t td_retval[2] __aligned(sizeof(off_t)); /* (k) Syscall aux returns. */ struct callout td_slpcallout; /* (h) Callout for sleep. */ struct trapframe *td_frame; /* (k) */ struct vm_object *td_kstack_obj;/* (a) Kstack object. */ I'll bring this up on -arch... The other option we could do is change td_retval into a union of td_retval and an off_t, and do the access that way, which is probably the best as it solves an aliasing issue too, BUT we'd be forced to either define td_retval to access through the union, or change all the uses of td_retval... On the way coming up, I get: pid 639 (newsyslog), uid 0: exited on signal 4 (core dumped) Illegal instruction (core dumped) which I'll take a look at shortly, but more importantly, as sshd comes up, I get: panic: vm_page_alloc: page 0xc0805db0 is wired I can't get a bt from the crash though, as this is what I get: db> bt Tracing pid 793 tid 100054 td 0xc10db960 db_trace_self() at db_trace_self pc = 0xc05564d0 lr = 0xc055655c (db_trace_thread+0x50) sp = 0xc09578c0 fp = 0xc03cc32c db_trace_thread() at db_trace_thread+0x50 pc = 0xc055655c lr = 0xc022b4d4 (db_command_init+0x620) sp = 0xc0957920 fp = 0xc03cc32c db_command_init() at db_command_init+0x620 pc = 0xc022b4d4 lr = 0xc022abac (db_skip_to_eol+0x480) sp = 0xc0957938 fp = 0xc03cc32c r4 = 0xc066fcd4 r5 = 0x00000000 db_skip_to_eol() at db_skip_to_eol+0x480 pc = 0xc022abac lr = 0xc022ad14 (db_command_loop+0x5c) sp = 0xc09579d8 fp = 0xc03cc32c r4 = 0xc09579ec r5 = 0xc066ffa4 r6 = 0x00000000 r7 = 0x00000000 r8 = 0x00000001 r10 = 0x600000d3 db_command_loop() at db_command_loop+0x5c pc = 0xc022ad14 lr = 0xc022d15c (X_db_sym_numargs+0xec) sp = 0xc09579e0 fp = 0xc03cc32c X_db_sym_numargs() at X_db_sym_numargs+0xec pc = 0xc022d15c lr = 0xc03cc56c (kdb_trap+0xa4) sp = 0xc0957af8 fp = 0xc03cc32c r4 = 0xc0957b90 kdb_trap() at kdb_trap+0xa4 pc = 0xc03cc56c lr = 0xc0567dc8 (undefinedinstruction+0x2d8) sp = 0xc0957b18 fp = 0xc03cc32c r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000000 r7 = 0xc0957b90 r8 = 0xe7ffffff r10 = 0xe7ffffff undefinedinstruction() at undefinedinstruction+0x2d8 pc = 0xc0567dc8 lr = 0xc0558218 (exception_exit) sp = 0xc0957b90 fp = 0xc06012c8 r4 = 0xffffffff r5 = 0xffff1004 r6 = 0xc06b9494 r7 = 0xc0957c14 r8 = 0xc10db960 r9 = 0x00000001 r10 = 0x00000000 exception_exit() at exception_exit pc = 0xc0558218 lr = 0xc03cc324 (kdb_enter+0x38) sp = 0xc0957be4 fp = 0xc06012c8 r0 = 0x00000012 r1 = 0x60000013 r2 = 0xc06c785c r3 = 0xc06b94c0 r4 = 0xc05d2898 r5 = 0xc0601dc0 r6 = 0xc06b9494 r7 = 0xc0957c14 r8 = 0xc10db960 r9 = 0x00000001 r10 = 0x00000000 r12 = 0xc05cfb50 kdb_enter() at kdb_enter+0x44 pc = 0xc03cc330 lr = 0xc0601dc0 (0xc0601dc0) sp = 0xc0957bec fp = 0xc06012c8 r4 = 0xc039a144 xscale_event_codes_size() at 0xc0601dc0 pc = 0xc0601dc0 lr = 0x00000000 (0) sp = 0xc0957bf4 fp = 0xc06012c8 Unable to unwind into user mode Though, I don't think user mode should start there.. there should be a few more frames... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon Jan 13 11:06:42 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FA3C5E3 for ; Mon, 13 Jan 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 30B601139 for ; Mon, 13 Jan 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0DB6g7u095777 for ; Mon, 13 Jan 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0DB6fNo095775 for freebsd-arm@FreeBSD.org; Mon, 13 Jan 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 13 Jan 2014 11:06:41 GMT Message-Id: <201401131106.s0DB6fNo095775@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 11:06:42 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/185617 arm 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBon o arm/185046 arm [armv6] issues with dhclient/sshd and jemalloc on rasp o arm/184078 arm cross installworld missing include files o arm/183926 arm Crash when ctrl-c while process is enter o arm/183740 arm mutex on some arm hardware requires dcache enabled o arm/183668 arm Panic when read unalign in ddb o arm/182544 arm [patch] ARM busdma_machdep-v6.c o arm/182060 arm make buildworld fails on Raspberry PI o arm/181722 arm gdb on ARM unable to sensibly debug core file from ass o arm/181718 arm threads caused hung on ARM/RPI o arm/181601 arm Sporadic failure of root mount on ARM/Raspberry o arm/180080 arm Unmapped buffers on ARMv7 big-RAM boards o arm/179688 arm [patch] [rpi] serial console eats some characters at m o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177685 arm [kernel] [patch] Correct return type and usage of at91 o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o arm/175803 arm building xdev for arm failing o arm/173617 arm Dreamplug exhibits eSATA file corruption using network o kern/171096 arm [arm][xscale][ixp]Allow 16bit access on PCI bus o arm/166256 arm build fail in pmap.c o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o ports/161044 arm devel/icu does not build on arm o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) p arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on 33 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Jan 13 14:23:35 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 985E4DB6 for ; Mon, 13 Jan 2014 14:23:35 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 53460136C for ; Mon, 13 Jan 2014 14:23:35 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1W2iQP-000Hry-Gq; Mon, 13 Jan 2014 14:23:33 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s0DENUuU037050; Mon, 13 Jan 2014 07:23:30 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 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+EurkRL3873nCLDtnBsoNI Subject: Re: svn commit: r258412 - in head/sys/arm: at91 econa s3c2xx0 sa11x0 xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa From: Ian Lepore To: John-Mark Gurney In-Reply-To: <20140113055215.GB2982@funkthat.com> References: <201311210108.rAL18AoQ051365@svn.freebsd.org> <20131221061048.GC99167@funkthat.com> <20140108071643.GB99167@funkthat.com> <1389197091.1158.370.camel@revolution.hippie.lan> <20140108173909.GF99167@funkthat.com> <20140110230241.GS46596@funkthat.com> <20140111135156.251a70fa@bender.Home> <20140111205303.GZ46596@funkthat.com> <20140113055215.GB2982@funkthat.com> Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Jan 2014 07:23:30 -0700 Message-ID: <1389623010.1230.3.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 14:23:35 -0000 On Sun, 2014-01-12 at 21:52 -0800, John-Mark Gurney wrote: [...] > > which I'll take a look at shortly, but more importantly, as sshd > comes up, I get: > panic: vm_page_alloc: page 0xc0805db0 is wired > > I can't get a bt from the crash though, as this is what I get: > db> bt > Tracing pid 793 tid 100054 td 0xc10db960 > db_trace_self() at db_trace_self > pc = 0xc05564d0 lr = 0xc055655c (db_trace_thread+0x50) > sp = 0xc09578c0 fp = 0xc03cc32c > db_trace_thread() at db_trace_thread+0x50 > pc = 0xc055655c lr = 0xc022b4d4 (db_command_init+0x620) > sp = 0xc0957920 fp = 0xc03cc32c > db_command_init() at db_command_init+0x620 > pc = 0xc022b4d4 lr = 0xc022abac (db_skip_to_eol+0x480) > sp = 0xc0957938 fp = 0xc03cc32c > r4 = 0xc066fcd4 r5 = 0x00000000 > db_skip_to_eol() at db_skip_to_eol+0x480 > pc = 0xc022abac lr = 0xc022ad14 (db_command_loop+0x5c) > sp = 0xc09579d8 fp = 0xc03cc32c > r4 = 0xc09579ec r5 = 0xc066ffa4 > r6 = 0x00000000 r7 = 0x00000000 > r8 = 0x00000001 r10 = 0x600000d3 > db_command_loop() at db_command_loop+0x5c > pc = 0xc022ad14 lr = 0xc022d15c (X_db_sym_numargs+0xec) > sp = 0xc09579e0 fp = 0xc03cc32c > X_db_sym_numargs() at X_db_sym_numargs+0xec > pc = 0xc022d15c lr = 0xc03cc56c (kdb_trap+0xa4) > sp = 0xc0957af8 fp = 0xc03cc32c > r4 = 0xc0957b90 > kdb_trap() at kdb_trap+0xa4 > pc = 0xc03cc56c lr = 0xc0567dc8 (undefinedinstruction+0x2d8) > sp = 0xc0957b18 fp = 0xc03cc32c > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0x00000000 r7 = 0xc0957b90 > r8 = 0xe7ffffff r10 = 0xe7ffffff > undefinedinstruction() at undefinedinstruction+0x2d8 > pc = 0xc0567dc8 lr = 0xc0558218 (exception_exit) > sp = 0xc0957b90 fp = 0xc06012c8 > r4 = 0xffffffff r5 = 0xffff1004 > r6 = 0xc06b9494 r7 = 0xc0957c14 > r8 = 0xc10db960 r9 = 0x00000001 > r10 = 0x00000000 > exception_exit() at exception_exit > pc = 0xc0558218 lr = 0xc03cc324 (kdb_enter+0x38) > sp = 0xc0957be4 fp = 0xc06012c8 > r0 = 0x00000012 r1 = 0x60000013 > r2 = 0xc06c785c r3 = 0xc06b94c0 > r4 = 0xc05d2898 r5 = 0xc0601dc0 > r6 = 0xc06b9494 r7 = 0xc0957c14 > r8 = 0xc10db960 r9 = 0x00000001 > r10 = 0x00000000 r12 = 0xc05cfb50 > kdb_enter() at kdb_enter+0x44 > pc = 0xc03cc330 lr = 0xc0601dc0 (0xc0601dc0) > sp = 0xc0957bec fp = 0xc06012c8 > r4 = 0xc039a144 > xscale_event_codes_size() at 0xc0601dc0 > pc = 0xc0601dc0 lr = 0x00000000 (0) > sp = 0xc0957bf4 fp = 0xc06012c8 > Unable to unwind into user mode > > Though, I don't think user mode should start there.. there should be > a few more frames... It looks like the unwinding ran into a corrupted stack. Unable to unwind into user mode happens when the saved PC in the next stack frame has an address < 0xc0000000. Another sign of brokeness is that xscale_event_codes_size is data, not code (the tracer just looks up and prints the nearest symbol to the address it's looking for). -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Jan 13 15:30:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 623F31B4; Mon, 13 Jan 2014 15:30:49 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E6376199D; Mon, 13 Jan 2014 15:30:48 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s0DFI4bn055864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Jan 2014 16:18:05 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id s0DFI2Ld035646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Jan 2014 16:18:02 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id s0DFI2Mq009626; Mon, 13 Jan 2014 16:18:02 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s0DFI2aG009625; Mon, 13 Jan 2014 16:18:02 +0100 (CET) (envelope-from ticso) Date: Mon, 13 Jan 2014 16:18:02 +0100 From: Bernd Walter To: Tim Kientzle Subject: Re: Obtaining an RPi with Micron RAM? Message-ID: <20140113151802.GD89905@cicely7.cicely.de> References: <5E418613-8869-4FD5-AF8F-3E1BF6DE0412@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E418613-8869-4FD5-AF8F-3E1BF6DE0412@freebsd.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm ml X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 15:30:49 -0000 On Sat, Jan 11, 2014 at 10:48:55AM -0800, Tim Kientzle wrote: > Apparently, different RPis have different RAM chips which > require slightly different boot support. > > I'd like to test some boot changes across the different > board versions but don't know where to obtain an RPi > with the Micron RAM. (The new one I just bought has > the same Samsung RAM as my old one.) > > If you have an RPi with "M" logo on the RAM chip, > could you please reply direct to me and let me know > *where* you bought it from so I can get one of my own? > > If you happen to be located near me (I'm in the SF Bay Area) > and would be willing to swap, that would be even better. Just checked - my older 256MB have Samsung RAM. I got my boards via Farnell. AFAIK RS-Electronic has it's own production line, so probably they use(d) Micron RAM. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon Jan 13 21:34:38 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 234A59D9 for ; Mon, 13 Jan 2014 21:34:38 +0000 (UTC) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E0E511A63 for ; Mon, 13 Jan 2014 21:34:37 +0000 (UTC) Received: by mail-ig0-f175.google.com with SMTP id uq10so3950340igb.2 for ; Mon, 13 Jan 2014 13:34:31 -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:content-transfer-encoding:message-id:references :to; bh=izVDfxAweviO2bfxWfaMszpsnDg0M0KK60oT3zzoaCs=; b=KcE1HNFTHFD6s6UivB3L2rU0Sabv5JsEqaNzuQYzFRuKhX8wDWb1Nxhm+qKyNlUCgR wKa3lpUfG89JMRCWRkMoIc2smJ+Dswu0KPq5u1gwy2IgyntdaH/9jKBM8ip8p4qVo1mY RYoibVD7270b9A+VW+dTHaitR4B++TfD1RKYUylAvy2oEQeVStQKWW1/jO2cnSGbSk7D g+J5wBGdun/GisLrhVJf2YdWHl1mHg6D7ICv54rTEflpr4vA145cy75TijeKwd7mpGNC Lw7ub7N94TEt/wVxv0A1/NCICa5qoA4uKhJ9nvULa4Squzd4mLOJQdnhLABnXgvJYL7x p/vg== X-Gm-Message-State: ALoCoQnH0b3xIUhwdj9hvWYF9chExyWudMq62RVzaMFkyVk0wm0mvDcH76vudVI0jyX9uKK7Wmx8 X-Received: by 10.50.100.170 with SMTP id ez10mr21023278igb.15.1389648871013; Mon, 13 Jan 2014 13:34:31 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id gc2sm20434930igd.6.2014.01.13.13.34.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Jan 2014 13:34:30 -0800 (PST) Sender: Warner Losh Subject: Re: Using VFP registers in the msun fenv functions Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20140112194532.27366e43@bender.Home> Date: Mon, 13 Jan 2014 14:34:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1EEB0662-E528-4E36-8A39-B5804AD89132@bsdimp.com> References: <20140112194532.27366e43@bender.Home> To: Andrew Turner X-Mailer: Apple Mail (2.1085) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 21:34:38 -0000 Hi Andrew, Thanks for tackling this... On Jan 12, 2014, at 12:45 PM, Andrew Turner wrote: > [1] http://people.freebsd.org/~andrew/armv6fenv2.diff I noticed several constructs like +int feclearexcept(int __excepts) +{ + + if (_libc_arm_fpu_present) + __vfp_feclearexcept(__excepts); + __softfp_feclearexcept(__excepts); + + return (0); +} where you do the softfp thing unconditionally. Why is that, and is it = intentional? Warner From owner-freebsd-arm@FreeBSD.ORG Mon Jan 13 22:19:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD7ABD47 for ; Mon, 13 Jan 2014 22:19:05 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id BE0021E8C for ; Mon, 13 Jan 2014 22:19:05 +0000 (UTC) Received: from bender.Home (97e07ae8.skybroadband.com [151.224.122.232]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 674725E303; Mon, 13 Jan 2014 22:18:57 +0000 (UTC) Date: Mon, 13 Jan 2014 22:18:49 +0000 From: Andrew Turner To: Warner Losh Subject: Re: Using VFP registers in the msun fenv functions Message-ID: <20140113221849.099275ca@bender.Home> In-Reply-To: <1EEB0662-E528-4E36-8A39-B5804AD89132@bsdimp.com> References: <20140112194532.27366e43@bender.Home> <1EEB0662-E528-4E36-8A39-B5804AD89132@bsdimp.com> 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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 22:19:05 -0000 On Mon, 13 Jan 2014 14:34:28 -0700 Warner Losh wrote: > Hi Andrew, > > Thanks for tackling this... > > On Jan 12, 2014, at 12:45 PM, Andrew Turner wrote: > > [1] http://people.freebsd.org/~andrew/armv6fenv2.diff > > I noticed several constructs like > > +int feclearexcept(int __excepts) > +{ > + > + if (_libc_arm_fpu_present) > + __vfp_feclearexcept(__excepts); > + __softfp_feclearexcept(__excepts); > + > + return (0); > +} > > where you do the softfp thing unconditionally. Why is that, and is it > intentional? As this is for the soft-float ABI we still use the softfloat code. Because of this there are a number of places where we still need to call into the softfloat version of these functions. i.e. just because _libc_arm_fpu_present is set there is no guarantee we will use the VFP unit in any helper functions. Andrew From owner-freebsd-arm@FreeBSD.ORG Mon Jan 13 22:37:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C57444C; Mon, 13 Jan 2014 22:37:49 +0000 (UTC) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1BA901FDB; Mon, 13 Jan 2014 22:37:49 +0000 (UTC) Received: by mail-pb0-f46.google.com with SMTP id ma3so2384872pbc.19 for ; Mon, 13 Jan 2014 14:37:48 -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=j0qzycpc6EKDXdkf00+02TbBDVaxN0xlwknWYSQHjnA=; b=d2jt7pFCBDpPF+r0uvoLrk4ZTOjxH0vL3PuJIxV3C/1JD39pWFg/NtFe+4tKWR7LPX oMFfPKlXoUN+1oKBIne3yFjo5QNKZCBxVmDbXt7/BO7FqHgRZCHhNwVxNsvx13NRqwmw CyFn3iKmn4BoeZUJ+IsYWmWuZh8050oqj+OWPHRJ2sviiDDe6r2slilCNg3h7AfBfwnU AhJ5a8cmSGqII4e0PWO7qteo27+2sKvSlz8y+TmmeFMVr2ut1Mv5G99JMU5DN2m5rnTV E189Pik/XRzMTjKSe3l0oq3xN/viMR5wCKcB/S5FrozrsO1DkedF7xjxGbwmoe5tslqf aphg== MIME-Version: 1.0 X-Received: by 10.66.123.5 with SMTP id lw5mr32963559pab.83.1389652668751; Mon, 13 Jan 2014 14:37:48 -0800 (PST) Sender: johny.mattsson@gmail.com Received: by 10.70.61.232 with HTTP; Mon, 13 Jan 2014 14:37:48 -0800 (PST) In-Reply-To: <5E418613-8869-4FD5-AF8F-3E1BF6DE0412@freebsd.org> References: <5E418613-8869-4FD5-AF8F-3E1BF6DE0412@freebsd.org> Date: Tue, 14 Jan 2014 09:37:48 +1100 X-Google-Sender-Auth: u16Ac4QVUtsqIkrBYycPWaijnSc Message-ID: Subject: Re: Obtaining an RPi with Micron RAM? From: Johny Mattsson To: Tim Kientzle Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm ml X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 22:37:49 -0000 On 12 January 2014 05:48, Tim Kientzle wrote: > Apparently, different RPis have different RAM chips which > require slightly different boot support. > > I'd like to test some boot changes across the different > board versions but don't know where to obtain an RPi > with the Micron RAM. (The new one I just bought has > the same Samsung RAM as my old one.) > The most comprehensive list of the different revisions of Pi that I'm aware of is found here: http://elinux.org/RaspberryPi_Boards Only RS has used Micron RAM it seems, and it might even be the current production run since the boards are listed as not having the F1/F2 polyfuses. Cheers, /Johny From owner-freebsd-arm@FreeBSD.ORG Tue Jan 14 21:01:21 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A771B9B for ; Tue, 14 Jan 2014 21:01:21 +0000 (UTC) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2969418DE for ; Tue, 14 Jan 2014 21:01:20 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id t60so961824wes.32 for ; Tue, 14 Jan 2014 13:01:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=1TbpAhb4lxt76CWwhJDZBmQx877iqtHxRw5FiCJ8RR4=; b=fmxFrrOMS9uHLCLP/0HMKUxvz/MZB09lvH+o53VwXW7/bGqa023f/wx102eRQ4zThk v3QME3s4kkp45tgQ//sxQKW6KAZn+IfA5RDuWe2/gRnwDJJE3R5Y7dP8PeOi0sikV3M+ 7YUSYFRoSvVP21NBSgKt22e9IkLLLCkAaiDA8iTtxe9PeoFJg3Iow1jEj98RUewy5Y3K mP5962n7YOBeWll8RuiAB2L0izC5l7+2h1L1wwiemweS5MGG31RvHksaQYMQZjaVgORt Yy0fjm6Fhc31C7m4sX1hmnMUiCx/hIpU55gYNYvzfH30qZrTp6ykU6HqacCo97AaiXWr ZSyg== X-Gm-Message-State: ALoCoQnoOnMGUnwwzB99Dyv69/tWWWj7JDgNAqdvwI5BBwIvKXKO4tYc3bGp1LOffMc8yM8/HjzV X-Received: by 10.180.79.38 with SMTP id g6mr4885327wix.60.1389733273106; Tue, 14 Jan 2014 13:01:13 -0800 (PST) Received: from belegaer.uk.xensource.com. ([185.25.64.249]) by mx.google.com with ESMTPSA id md9sm25006951wic.1.2014.01.14.13.01.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Jan 2014 13:01:12 -0800 (PST) From: Julien Grall To: freebsd-xen@freebsd.org, xen-devel@lists.xen.org, gibbs@freebsd.org, freebsd-arm@FreeBSD.org Subject: [RFC] Add support for Xen ARM guest on FreeBSD Date: Tue, 14 Jan 2014 21:01:07 +0000 Message-Id: <1389733267-20822-1-git-send-email-julien.grall@linaro.org> X-Mailer: git-send-email 1.7.10.4 Cc: stefano.stabellini@eu.citrix.com, ian.campbell@citrix.com, roger.pau@citrix.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 21:01:21 -0000 Hello, During the last couple of months I have been working on porting FreeBSD on Xen on ARM. It's my first big project on FreeBSD and I'm not sure if I have cc the right MLs and people. If not, could somebody point me to the right email address? With this patch series I'm able to boot FreeBSD with a single VCPU on every 32 bits platform supported by Xen. The patch series is divided in 5 parts: * #1-#12: Clean up and bug fix with some options * #13-#17: Update the Xen interface to Xen 4.4 and fix compilation * #18-#32: Update Xen code to support ARM guest * #33-#38: Update ARM code to support Xen guest * #39-#40: Add platform code to support ARM guest I have pushed a branch on my git based on Royger's pvh work version 10: git clone git://xenbits.xen.org/people/julieng/freebsd.git -b xen-arm http://xenbits.xen.org/gitweb/?p=people/julieng/freebsd.git;a=shortlog;h=refs/heads/xen-arm If needed, I can send the patch one by one the different mailing list. This new support brings 2 open questions (for both Xen and FreeBSD community). When a new guest is created, the toolstack will generated a device tree which will contains: - The amount of memory - The description of the platform (gic, timer, hypervisor node) - PSCI node for SMP bringup Until now, Xen on ARM supported only Linux-based OS. When the support of device tree was added in Xen for guest, we chose to use Linux device tree bindings (gic, timer,...). It seems that FreeBSD choose a different way to implement device tree: - strictly respect ePAR (for interrupt-parent property) - gic bindings different (only 1 interrupt cell) I would like to come with a common device tree specification (bindings, ...) across every operating system. I know the Linux community is working on having a device tree bindings out of the kernel tree. Does FreeBSD community plan to work with Linux community for this purpose? As specified early, the device tree can vary accross Xen version and user input (eg the memory). I have noticed few places (mainly the timer) where the IRQs number are harcoded. In the long-term, it would be nice to see FreeBSD booting out-of-box (eg the device tree is directly provided by the board firmware). I plan to add support for Device Tree loading via Linux Boot ABI, it the way that Xen use to boot a new guest. The second question is related to memory attribute for page table. The early page table setup by FreeBSD are using Write-Through memory attribute which result to a likely random (not every time the same place) crash before the real page table are initialized. Replacing Write-Through by Write-Back made FreeBSD boot correctly. Even today, I have no idea if it's a requirement from Xen or a bug (either in Xen or FreeBSD). The code is taking its first faltering steps, therefore the TODO is quite big: - Try the code on x86 architecture. I did lots of rework for the event channels code and didn't even try to compile - Clean up event channel code - Clean up xen control code - Add support for Device Tree loading via Linux Boot ABI - Fixing crashing on userspace. Could be related to the patch series "arm SMP on Cortex-A15" - Add guest SMP support - DOM0 support? Any help, comments, questions are welcomed. Sincerely yours, ============= Instruction to test FreeBSD on Xen on ARM =========== Xen upstream tree doesn't fully support ELF loading for ARM. You will need to recompile the tools with the following 2 patches: - https://patches.linaro.org/22228/ - https://patches.linaro.org/22227/ To compile and boot Xen on your board, you can refer to the wiki page: http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions The instruction to compile FreeBSD for Xen on ARM: $ truncate -s 512 xenvm.img $ sudo mdconfig -f xenvm.img -u0 $ sudo newfs /dev/md0 $ sudo mount /dev/md0 /mnt $ sudo make TARGET_ARCH=armv6 kernel-toolchain $ sudo make TARGET_ARCH=armv6 KERNCONF=XENHVM buildkernel $ sudo make TARGET_ARCH=armv6 buildworld $ sudo make TARGET_ARCH=armv6 DESTDIR=/mnt installworld distribution $ echo "/dev/xbd0 / ufs rw 1 1" > /mnt/etc/fstab $ vi /mnt/etc/ttys (add the line 'xc0 "/usr/libexec/getty Pc" xterm on secure") $ sudo umount /mnt $ sudo mdconfig -d u0 Then you can copy the rootfs and the kernel to DOM 0 on your board. To boot the a FreeBSD your will required the following configuration file $ cat freebsd.xl kernel="kernel" memory=64 name="freebsd" vcpus=1 autoballon="off" disk=[ 'phy:/dev/loop0,xvda,w' ] $ losetup /dev/loop0 xenvm.img $ xl create freebsd.xl $ xl console freebsd Julien Grall (40): xen/netfront: Don't need to include machine/intr_machdep.h xen/blkfront: Don't need to include machine/intr_machdep.h xen/control: Remove include machine/intr_machdep.h xen: Define xen_intr_handle_upcall in common headers xen: Remove duplicate features.h header in i386 arch xen/hypercall: Allow HYPERVISOR_console_write to take a const string xen/timer: Make xen timer optional xen/console: Fix build when DDB is enabled xen/console: clean up identify callback xen/xenstore: xs_probe should return BUS_PROBE_NOWILDCARD xen/control: xctlr_probe shoud return BUS_PROBE_NOWILDCARD xen/hypervisor: Be sure to set __XEN_INTERFACE_VERSION__ xen/interface: Update interface to Xen 4.4 headers xen: Bump __XEN_INTERFACE_VERSION__ to 4.3 xen/baloon: Fix compilation with Xen 4.4 headers xen/netfront: Fix compilation with Xen 4.4 headers xen/gnttab: Fix compilation with Xen 4.4 headers xen/ballon: Use correct type for frame list xen/netback: Fix printf format for xen_pfn_t xen/netfront: Use the correct type for rx_pfn_array xen/gnttab: Use the right type for the frames xen/gnttab: Export resume_frames xen/gnttab: Add a guard for xenpci functions xen/netfront: Define PTE flags per architecture xen/control: Implement suspend has panic for ARM xen: Introduce xen_pmap xen: move x86/xen/xenpv.c in dev/xen/xenpv.c xen/xenpv: Only add isa for x86 architecture xen/xenpv: Protect xenpci code by DEV_XENPCI xen: move xen_intr.c to common code xen/evtchn: Rework the event channels handler to make it generic xen/console: handle console for HVM arm/timer: Handle timer with no clock-frequency property arm/timer: WORKAROUND The timer should support DT... arm: Detect new revision for cortex A15 arm: add ELFNOTE macro arm: Implement disable_intr arm: Use Write-Back as memory attribute for early page table dts: Add xenvm.dts arm: Add xenhvm platform sys/amd64/conf/GENERIC | 4 +- sys/amd64/include/apicvar.h | 1 - sys/amd64/include/xen/hypercall.h | 2 +- sys/amd64/include/xen/xen-os.h | 2 + sys/amd64/include/xen/xenpmap.h | 2 +- sys/arm/arm/cpufunc.c | 2 + sys/arm/arm/generic_timer.c | 12 +- sys/arm/arm/locore.S | 4 +- sys/arm/conf/XENHVM | 97 +++ sys/arm/include/armreg.h | 2 + sys/arm/include/asmacros.h | 26 + sys/arm/include/cpufunc.h | 6 + sys/arm/include/xen/hypercall.h | 50 ++ sys/arm/include/xen/synch_bitops.h | 52 ++ sys/arm/include/xen/xen-os.h | 29 + sys/arm/include/xen/xenfunc.h | 4 + sys/arm/include/xen/xenvar.h | 14 + sys/arm/xenhvm/elf.S | 12 + sys/arm/xenhvm/files.xenhvm | 18 + sys/arm/xenhvm/hypercall.S | 107 +++ sys/arm/xenhvm/xen-dt.c | 148 ++++ sys/arm/xenhvm/xenhvm_machdep.c | 132 ++++ sys/boot/fdt/dts/xenvm.dts | 77 ++ sys/conf/files | 4 +- sys/conf/options | 3 + sys/conf/options.arm | 1 + sys/dev/xen/balloon/balloon.c | 6 +- sys/dev/xen/blkfront/blkfront.c | 1 - sys/dev/xen/console/console.c | 28 +- sys/dev/xen/console/xencons_ring.c | 41 +- sys/dev/xen/control/control.c | 19 +- sys/dev/xen/netback/netback.c | 6 +- sys/dev/xen/netfront/netfront.c | 15 +- sys/dev/xen/xenpci/xenpci.c | 2 +- sys/dev/xen/xenpv.c | 133 ++++ sys/i386/conf/GENERIC | 4 +- sys/i386/conf/XEN | 1 + sys/i386/include/apicvar.h | 1 - sys/i386/include/xen/features.h | 22 - sys/i386/include/xen/hypercall.h | 2 +- sys/i386/include/xen/xen-os.h | 2 + sys/i386/include/xen/xenvar.h | 2 +- sys/i386/xen/xen_machdep.c | 2 +- sys/x86/xen/xen_intr.c | 1241 ------------------------------- sys/x86/xen/xenpv.c | 128 ---- sys/xen/gnttab.c | 23 +- sys/xen/hypervisor.h | 3 +- sys/xen/interface/arch-arm.h | 259 +++++-- sys/xen/interface/arch-arm/hvm/save.h | 2 +- sys/xen/interface/arch-x86/hvm/save.h | 25 +- sys/xen/interface/arch-x86/xen-mca.h | 2 +- sys/xen/interface/arch-x86/xen-x86_32.h | 2 +- sys/xen/interface/arch-x86/xen-x86_64.h | 2 +- sys/xen/interface/arch-x86/xen.h | 31 +- sys/xen/interface/callback.h | 4 +- sys/xen/interface/dom0_ops.h | 2 +- sys/xen/interface/domctl.h | 65 +- sys/xen/interface/elfnote.h | 10 +- sys/xen/interface/event_channel.h | 5 +- sys/xen/interface/features.h | 16 +- sys/xen/interface/gcov.h | 115 +++ sys/xen/interface/grant_table.h | 8 +- sys/xen/interface/hvm/hvm_xs_strings.h | 80 ++ sys/xen/interface/hvm/ioreq.h | 20 +- sys/xen/interface/hvm/params.h | 14 +- sys/xen/interface/hvm/pvdrivers.h | 47 ++ sys/xen/interface/hvm/save.h | 4 +- sys/xen/interface/io/blkif.h | 104 ++- sys/xen/interface/io/console.h | 2 +- sys/xen/interface/io/fbif.h | 2 +- sys/xen/interface/io/kbdif.h | 2 +- sys/xen/interface/io/netif.h | 47 +- sys/xen/interface/io/pciif.h | 3 +- sys/xen/interface/io/protocols.h | 5 +- sys/xen/interface/io/tpmif.h | 68 +- sys/xen/interface/io/usbif.h | 1 - sys/xen/interface/io/vscsiif.h | 42 +- sys/xen/interface/io/xenbus.h | 20 +- sys/xen/interface/io/xs_wire.h | 7 +- sys/xen/interface/kexec.h | 7 +- sys/xen/interface/mem_event.h | 4 +- sys/xen/interface/memory.h | 80 +- sys/xen/interface/nmi.h | 7 +- sys/xen/interface/physdev.h | 33 +- sys/xen/interface/platform.h | 27 +- sys/xen/interface/sched.h | 87 ++- sys/xen/interface/sysctl.h | 47 +- sys/xen/interface/tmem.h | 2 +- sys/xen/interface/trace.h | 93 ++- sys/xen/interface/vcpu.h | 2 +- sys/xen/interface/version.h | 6 +- sys/xen/interface/xen-compat.h | 2 +- sys/xen/interface/xen.h | 128 +++- sys/xen/interface/xenoprof.h | 2 +- sys/xen/interface/xsm/flask_op.h | 8 + sys/xen/xen-os.h | 2 +- sys/xen/xen_intr.c | 1072 ++++++++++++++++++++++++++ sys/xen/xen_intr.h | 8 +- sys/xen/xenstore/xenstore.c | 4 +- 99 files changed, 3339 insertions(+), 1791 deletions(-) create mode 100644 sys/arm/conf/XENHVM create mode 100644 sys/arm/include/xen/hypercall.h create mode 100644 sys/arm/include/xen/synch_bitops.h create mode 100644 sys/arm/include/xen/xen-os.h create mode 100644 sys/arm/include/xen/xenfunc.h create mode 100644 sys/arm/include/xen/xenvar.h create mode 100644 sys/arm/xenhvm/elf.S create mode 100644 sys/arm/xenhvm/files.xenhvm create mode 100644 sys/arm/xenhvm/hypercall.S create mode 100644 sys/arm/xenhvm/xen-dt.c create mode 100644 sys/arm/xenhvm/xenhvm_machdep.c create mode 100644 sys/boot/fdt/dts/xenvm.dts create mode 100644 sys/dev/xen/xenpv.c delete mode 100644 sys/i386/include/xen/features.h delete mode 100644 sys/x86/xen/xen_intr.c delete mode 100644 sys/x86/xen/xenpv.c create mode 100644 sys/xen/interface/gcov.h create mode 100644 sys/xen/interface/hvm/hvm_xs_strings.h create mode 100644 sys/xen/interface/hvm/pvdrivers.h create mode 100644 sys/xen/xen_intr.c -- 1.8.0 From owner-freebsd-arm@FreeBSD.ORG Wed Jan 15 00:06:24 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 156C2244 for ; Wed, 15 Jan 2014 00:06:24 +0000 (UTC) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BE249184B for ; Wed, 15 Jan 2014 00:06:23 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s0F06G2p084269 for ; Tue, 14 Jan 2014 19:06:21 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <52D5D0F8.9050205@m5p.com> Date: Tue, 14 Jan 2014 19:06:16 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: Re: Raspberry Pi: still getting prefetch aborts References: <52BB73B4.5030000@m5p.com> In-Reply-To: <52BB73B4.5030000@m5p.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Tue, 14 Jan 2014 19:06:21 -0500 (EST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 00:06:24 -0000 On 12/25/13 19:09, George Mitchell wrote: > FreeBSD 10.0-PRERELEASE (RPI-B) #0 r259866M: Wed Dec 25 17:26:28 EST 2013 > (M because I selected serial output in RPI-B) > > /usr/ports is NFS mounted from elsewhere. > [Long description of prefetch abort] [...] Well, that got a deafeningly silent response. I finally copied my /usr/ports onto the SD card instead of NFS mounting it, and now my port build is chugging along happily so far. So the problem, whatever it is, is triggered by NFS. -- George From owner-freebsd-arm@FreeBSD.ORG Wed Jan 15 00:23:24 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01530B7C for ; Wed, 15 Jan 2014 00:23:24 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B4C8A19A4 for ; Wed, 15 Jan 2014 00:23:23 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id c9so377130qcz.27 for ; Tue, 14 Jan 2014 16:23:22 -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=HZjPFSmoqwaT4wbH0hzPSP7O4Gj6jGylHDeUOl4FcfA=; b=wmGdYhzFwLpsCQAyAuLUgNFdydd+bp2nNHBTg4MBtz3s3W7RoX2WuzD/zL0mdrKWJs DdSMHDCcL8LaC50itJpMuIB9khbN3HPINhCb5kPNa5q0NQDQuBMHOf2u2fZYEEe+NCML YQDPH56yWm7PUi0NDkoXH5i+OJf+BObF/tynV9xyJ3HEI1YmvE26Djqtxj/ojjnx8mku Nw+VN3BypN+MJssJHTNrabFjDvNo1Yy9AE/cVbzAadWINt1Gi1etezFuazyPQFrNOLwo jhXdeTGd6KoipS3gZ5dUt2C59KJDgaDyt3gUofQ3jm7jm+tfRid3JI6+rLxiZKggHtWU r9Yw== MIME-Version: 1.0 X-Received: by 10.224.16.72 with SMTP id n8mr2975821qaa.76.1389745402893; Tue, 14 Jan 2014 16:23:22 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Tue, 14 Jan 2014 16:23:22 -0800 (PST) In-Reply-To: <52D5D0F8.9050205@m5p.com> References: <52BB73B4.5030000@m5p.com> <52D5D0F8.9050205@m5p.com> Date: Tue, 14 Jan 2014 16:23:22 -0800 X-Google-Sender-Auth: -1zYYwrWlBXqwRFfEBFt6yXYEHU Message-ID: Subject: Re: Raspberry Pi: still getting prefetch aborts From: Adrian Chadd To: George Mitchell Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 00:23:24 -0000 Please be more persistent and loud. :) -a On 14 January 2014 16:06, George Mitchell wrote: > On 12/25/13 19:09, George Mitchell wrote: >> >> FreeBSD 10.0-PRERELEASE (RPI-B) #0 r259866M: Wed Dec 25 17:26:28 EST 2013 >> (M because I selected serial output in RPI-B) >> >> /usr/ports is NFS mounted from elsewhere. >> [Long description of prefetch abort] [...] > > > Well, that got a deafeningly silent response. I finally copied my > /usr/ports onto the SD card instead of NFS mounting it, and now my > port build is chugging along happily so far. So the problem, > whatever it is, is triggered by NFS. -- George > > > _______________________________________________ > 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 Wed Jan 15 01:27:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6411B881 for ; Wed, 15 Jan 2014 01:27:26 +0000 (UTC) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 47E3A1F28 for ; Wed, 15 Jan 2014 01:27:26 +0000 (UTC) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id 3B2214008B for ; Wed, 15 Jan 2014 00:51:40 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Wed, 15 Jan 2014 00:51:40 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 0CC96602A1; Wed, 15 Jan 2014 00:51:40 +0000 (UTC) MIME-Version: 1.0 Date: Tue, 14 Jan 2014 16:51:39 -0800 To: freebsd-arm@freebsd.org Subject: another raspberry pi with sdhc timeout too large! From: "Dave Ng" Message-Id: <20140115005140.0CC96602A1@smtp.hushmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 01:27:26 -0000 At last I have a happy and booting FreeBSD on my Raspberry Pi. Awesome! However I have the big stream of timeout too large messages that have been reported by others. I gather that the card type needs to be added to some device ID list? Could someone give me a pointer on where to find and edit that? I have no problem building my own image afterwards. Thanks! Oh and here is my card -8GB at mmc0 25.0MHz/4bit/65535-block Sent using Hushmail From owner-freebsd-arm@FreeBSD.ORG Wed Jan 15 01:26:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D113727 for ; Wed, 15 Jan 2014 01:26:35 +0000 (UTC) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5305E1F0C for ; Wed, 15 Jan 2014 01:26:35 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id to1so1433542ieb.16 for ; Tue, 14 Jan 2014 17:26:28 -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:content-transfer-encoding:message-id:references :to; bh=+4JJGpGzvrdmRsYJC2le9nkdPo2M0GbBqZE4IUfdtLA=; b=Ya32rAMyzKPU3RlMdpIeD9ntsNvwXTvoUqHQ8hZhrHRxUqyqHnS2n9Ob6liS2tt0QR wtB5styrpec8Lx2EdsNafgibKfjATqZqWV0xp9iSvw1o6MfydlZljChE1upbp6bFtzMY y3KbNepfY4P3k5palp0/1aDZaSkmsSZCMWTxk0J0kvzftyE0LwAvgtuj6tIQWBPzkMi+ tkgQVQI/iegfA2vfw6cvkx1M9Fjmzm9X4vMYNeJ0INbR7yWNQ6urck9sjeD71JyXC34g KJS7EnmhrMRloSkJvoNQD0Es6y+yNfQIksepSz+ht82vrlUg/rpKHlYDjieJOMAoHZHl WuBg== X-Gm-Message-State: ALoCoQkJbYpclpf+1LD5PLGBGJfIbaVjUXEXp4LRCpamlA76i6HNL6ad6aGbbA3Yzuecmhtq6tJV X-Received: by 10.50.50.70 with SMTP id a6mr6024319igo.1.1389749188092; Tue, 14 Jan 2014 17:26:28 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id gc2sm26851224igd.6.2014.01.14.17.26.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Jan 2014 17:26:27 -0800 (PST) Sender: Warner Losh Subject: Re: [RFC] Add support for Xen ARM guest on FreeBSD Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1389733267-20822-1-git-send-email-julien.grall@linaro.org> Date: Tue, 14 Jan 2014 18:26:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <24851B79-7EC7-4E3A-94DB-4B9B86FDFFFC@bsdimp.com> References: <1389733267-20822-1-git-send-email-julien.grall@linaro.org> To: Julien Grall X-Mailer: Apple Mail (2.1085) Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org, freebsd-xen@freebsd.org, freebsd-arm@FreeBSD.org, gibbs@freebsd.org, roger.pau@citrix.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 01:26:35 -0000 On Jan 14, 2014, at 2:01 PM, Julien Grall wrote: > This new support brings 2 open questions (for both Xen and FreeBSD = community). > When a new guest is created, the toolstack will generated a device = tree which > will contains: > - The amount of memory > - The description of the platform (gic, timer, hypervisor node) > - PSCI node for SMP bringup >=20 > Until now, Xen on ARM supported only Linux-based OS. When the support = of > device tree was added in Xen for guest, we chose to use Linux device = tree > bindings (gic, timer,...). It seems that FreeBSD choose a different = way to > implement device tree: > - strictly respect ePAR (for interrupt-parent property) > - gic bindings different (only 1 interrupt cell) >=20 > I would like to come with a common device tree specification = (bindings, ...) > across every operating system. I know the Linux community is working = on having > a device tree bindings out of the kernel tree. Does FreeBSD community = plan to > work with Linux community for this purpose? We generally try to follow the common definitions for the FDT stuff. = There are a few cases where we either lack the feature set of Linux, or = where the Linux folks are moving quickly and changing the underlying = definitions where we wait for the standards to mature before we = implement. In some cases, where maturity hasn't happened, or where the = bindings are overly Linux centric (which in theory they aren't supposed = to be, but sometimes wind up that way). where we've not implemented = things. > As specified early, the device tree can vary accross Xen version and = user input > (eg the memory). I have noticed few places (mainly the timer) where = the IRQs > number are harcoded. These cases should be viewed as bugs in FreeBSD, I believe. One of the = goals that has wide support, at leas tin theory, is that we can boot = with an unaltered Linux FDT. This goal is some time in the future. > In the long-term, it would be nice to see FreeBSD booting out-of-box = (eg the > device tree is directly provided by the board firmware). I plan to add = support > for Device Tree loading via Linux Boot ABI, it the way that Xen use to = boot a > new guest. That would be most welcome. > The second question is related to memory attribute for page table. The = early > page table setup by FreeBSD are using Write-Through memory attribute = which > result to a likely random (not every time the same place) crash before = the > real page table are initialized. > Replacing Write-Through by Write-Back made FreeBSD boot correctly. = Even today, > I have no idea if it's a requirement from Xen or a bug (either in Xen = or > FreeBSD). There were some problems with pages being setup improperly for the = mutexes to operate properly. Have you confirmed this on a recent version = of FreeBSD? > The code is taking its first faltering steps, therefore the TODO is = quite big: > - Try the code on x86 architecture. I did lots of rework for the = event > channels code and didn't even try to compile > - Clean up event channel code > - Clean up xen control code > - Add support for Device Tree loading via Linux Boot ABI > - Fixing crashing on userspace. Could be related to the patch > series "arm SMP on Cortex-A15" > - Add guest SMP support > - DOM0 support? >=20 > Any help, comments, questions are welcomed. I think this is great! We'd love to work with you to make this happen. Warner > Sincerely yours, >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Instruction to test FreeBSD on = Xen on ARM =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [trimmed]= From owner-freebsd-arm@FreeBSD.ORG Wed Jan 15 13:56:52 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0CE38A9 for ; Wed, 15 Jan 2014 13:56:52 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C49D615C6 for ; Wed, 15 Jan 2014 13:56:52 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1W3Qxf-000DA8-7v; Wed, 15 Jan 2014 13:56:51 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s0FDulsY039480; Wed, 15 Jan 2014 06:56:47 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 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/s8H33LMzGIC4Cxadd4SkR Subject: Re: Raspberry Pi: still getting prefetch aborts From: Ian Lepore To: George Mitchell In-Reply-To: <52D5D0F8.9050205@m5p.com> References: <52BB73B4.5030000@m5p.com> <52D5D0F8.9050205@m5p.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Jan 2014 06:56:47 -0700 Message-ID: <1389794207.1230.27.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 13:56:53 -0000 On Tue, 2014-01-14 at 19:06 -0500, George Mitchell wrote: > On 12/25/13 19:09, George Mitchell wrote: > > FreeBSD 10.0-PRERELEASE (RPI-B) #0 r259866M: Wed Dec 25 17:26:28 EST 2013 > > (M because I selected serial output in RPI-B) > > > > /usr/ports is NFS mounted from elsewhere. > > [Long description of prefetch abort] [...] > > Well, that got a deafeningly silent response. I finally copied my > /usr/ports onto the SD card instead of NFS mounting it, and now my > port build is chugging along happily so far. So the problem, > whatever it is, is triggered by NFS. -- George I've been consistantly unable to reproduce the userland crash you see on rpi, even though the tracebacks and all make it look a lot like the wrong-endian kernel crashes I see on Wandboard (although my gut tells me it's not really the same problem). My setup is a lot like yours, with nfs-mounted filesystems, but when I build ports that way it either works fine, or the port builds die for other reasons. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Jan 15 16:24:27 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 886B89FC for ; Wed, 15 Jan 2014 16:24:27 +0000 (UTC) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 161FD15D9 for ; Wed, 15 Jan 2014 16:24:26 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id l18so1966302wgh.11 for ; Wed, 15 Jan 2014 08:24:18 -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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oFqgP2bYNTmnHFB2wz8dF2DyDmx5LNBdt4iOM+2CgZ0=; b=DD0UcZjnq5tLDiZ+RbB1uWx7mZsSDs04lHpNux8caMTDnky3tWd4VEO4ciE6W0yBcb olSNwJv6ySg3oDrSh07fcqjmaFGphcLQWCYPVB1Np+gIlvvlbca12OHj1woF7YzUgs6F vuFbrldwHmd96Em1BP8JZC2f1juikZ5F5GYV7QCCaqp9rXBRiG/P2MaUSkXRuZ5DV9TZ XSnqSpxLCVwl8zne/V0gBFOKnImXVLvlZoFjT8Uwx/9qqXPz8o7J0bI4Gw4H9zUe1JaW merTHhxZ5pZ/vjBJz7mUSx8f9D73wO6YtRBpdItw/S6Zp8sK5bQid1aTSdd2nRhi8FY5 6XyQ== X-Gm-Message-State: ALoCoQmnl+U3d3gO4YSi0BrP2ARzWgvowdZrafJR8ceZMmrzrbqTveKrX0pGYGvqMdHviCjJqMsG X-Received: by 10.194.63.134 with SMTP id g6mr3273698wjs.46.1389803057418; Wed, 15 Jan 2014 08:24:17 -0800 (PST) Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id y8sm3685838wje.12.2014.01.15.08.24.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Jan 2014 08:24:16 -0800 (PST) Message-ID: <52D6B62A.9000208@linaro.org> Date: Wed, 15 Jan 2014 16:24:10 +0000 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131104 Icedove/17.0.10 MIME-Version: 1.0 To: Warner Losh Subject: Re: [RFC] Add support for Xen ARM guest on FreeBSD References: <1389733267-20822-1-git-send-email-julien.grall@linaro.org> <24851B79-7EC7-4E3A-94DB-4B9B86FDFFFC@bsdimp.com> In-Reply-To: <24851B79-7EC7-4E3A-94DB-4B9B86FDFFFC@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org, freebsd-xen@freebsd.org, freebsd-arm@FreeBSD.org, gibbs@freebsd.org, roger.pau@citrix.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 16:24:27 -0000 On 01/15/2014 01:26 AM, Warner Losh wrote: > > On Jan 14, 2014, at 2:01 PM, Julien Grall wrote: >> This new support brings 2 open questions (for both Xen and FreeBSD community). >> When a new guest is created, the toolstack will generated a device tree which >> will contains: >> - The amount of memory >> - The description of the platform (gic, timer, hypervisor node) >> - PSCI node for SMP bringup >> >> Until now, Xen on ARM supported only Linux-based OS. When the support of >> device tree was added in Xen for guest, we chose to use Linux device tree >> bindings (gic, timer,...). It seems that FreeBSD choose a different way to >> implement device tree: >> - strictly respect ePAR (for interrupt-parent property) >> - gic bindings different (only 1 interrupt cell) >> >> I would like to come with a common device tree specification (bindings, ...) >> across every operating system. I know the Linux community is working on having >> a device tree bindings out of the kernel tree. Does FreeBSD community plan to >> work with Linux community for this purpose? > > We generally try to follow the common definitions for the FDT stuff. > There are a few cases where we either lack the feature set of Linux, or > where the Linux folks are moving quickly and changing the underlying definitions > where we wait for the standards to mature before we implement. In some cases, where > maturity hasn't happened, or where the bindings are overly Linux centric (which in > theory they aren't supposed to be, but sometimes wind up that way). where we've not > implemented things. As I understand main bindings (gic, timer) are set in stone and won't change. Ian Campbell has a repository with all the ARM bindings here: http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git; a=tree;f=Bindings/arm To compare the difference between the DT provided by Xen, and the one correctly parsed by FreeBSD - Xen: http://xenbits.xen.org/people/julieng/xenvm-4.2.dts - FreeBSD: http://xenbits.xen.org/people/julieng/xenvm-bsd.dts >From Xen side: - Every device should move under a simple-bus. I think it's harmless for Linux side. - How about hypervisor node? IHMO this node should also live under the simple-bus. >From FreeBSD side: - GIC and Timer bindings needs to be handled correctly (see below the problem for the GIC) - Less stricter about interrupt-parent property. Eg, look at the grant-parent if there is no property interrupt-parent - If the hypervisor doesn't live under simple-bus, the interrupt/memory retrieving should be moved from simple-bus to nexus? Before the revision r260282 (I have added Nathan on cc), I was able to use the Linux GIC bindings (see http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git;a=blob;f=Bindings/arm/gic.txt) without any issue. It seems the fdt bus, now consider the number of interrupt cells is always 1. >> As specified early, the device tree can vary accross Xen version and user input >> (eg the memory). I have noticed few places (mainly the timer) where the IRQs >> number are harcoded. > > These cases should be viewed as bugs in FreeBSD, I believe. One of the goals > that has wide support, at leas tin theory, is that we can boot with an unaltered > Linux FDT. This goal is some time in the future. The timer interrupt used by FreeBSD doesn't match the one used by Xen (secure vs non-secure interrupt). This should be easily resolved by retrieving the interrupt from the device tree. Is there a particular reason to use the secure interrupt for the timer? > >> The second question is related to memory attribute for page table. The early >> page table setup by FreeBSD are using Write-Through memory attribute which >> result to a likely random (not every time the same place) crash before the >> real page table are initialized. >> Replacing Write-Through by Write-Back made FreeBSD boot correctly. Even today, >> I have no idea if it's a requirement from Xen or a bug (either in Xen or >> FreeBSD). > > There were some problems with pages being setup improperly for the mutexes > to operate properly. Have you confirmed this on a recent version of FreeBSD? I have checkout the freeBSD branch last week. I'm not sure to understand the relation with mutexes. The symptoms I have is mostly data/prefetch abort receive to FreeBSD. Could it be related? >> The code is taking its first faltering steps, therefore the TODO is quite big: >> - Try the code on x86 architecture. I did lots of rework for the event >> channels code and didn't even try to compile >> - Clean up event channel code >> - Clean up xen control code >> - Add support for Device Tree loading via Linux Boot ABI >> - Fixing crashing on userspace. Could be related to the patch >> series "arm SMP on Cortex-A15" >> - Add guest SMP support >> - DOM0 support? >> >> Any help, comments, questions are welcomed. > > I think this is great! We'd love to work with you to make this happen. > > Warner > >> Sincerely yours, >> >> ============= Instruction to test FreeBSD on Xen on ARM =========== > [trimmed] > -- Julien Grall From owner-freebsd-arm@FreeBSD.ORG Wed Jan 15 17:55:34 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31475475 for ; Wed, 15 Jan 2014 17:55:34 +0000 (UTC) Received: from mail-pa0-x24d.google.com (mail-pa0-x24d.google.com [IPv6:2607:f8b0:400e:c03::24d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0C0AF11A7 for ; Wed, 15 Jan 2014 17:55:34 +0000 (UTC) Received: by mail-pa0-f77.google.com with SMTP id fb1so14970pad.8 for ; Wed, 15 Jan 2014 09:55:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:message-id:date:subject:from:to:content-type; bh=xvHnV/bOFwwSfSc0QLbp87qUt3t9AW3H05G6Afrh328=; b=tfpEDk4Klahm5UH3ITOGWTA/AljvxaIKUoVIT90ussfc6Uz5b9brYo2EisKJHuYPIj YA0FlkBfTGyzP3QpcAfG1jrKNDt4u5pPLitjKWFW+sSBJjpjC6j0+LCH69GBoTFkZbvp hZPAyPe+b7qHZPGbLm1yOQ/h/+eFG+rW+PK0PqUmXZYIWk6Fdfka5OuTdL2FnFOZ+nr6 OLH7NlEXjKxluhD9zgxH3/x9Rtb/nOORSyfLARzD5lJHTzOLHtJnsawtxP/9wnWvUw05 1UMFp4qVbtQbzTyeyajy841oPZ2iNdawQA1/ZxEPQdOSn36TEDNvi4gPFB8V0GEBQNbt ND6A== MIME-Version: 1.0 X-Received: by 10.66.222.105 with SMTP id ql9mr1458412pac.9.1389808533549; Wed, 15 Jan 2014 09:55:33 -0800 (PST) Message-ID: <047d7b5dae5af2ba3604f0060378@google.com> Date: Wed, 15 Jan 2014 17:55:33 +0000 Subject: www.freebsd.org From: Ava Hobbs To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 17:55:34 -0000 DQoNCkhpLA0KDQpJIGp1c3Qgd2FudGVkIHRvIHNlbmQgeW91IGEgcXVpY2sgbm90ZS4gV2l0aCBh IGZldyBzaW1wbGUgY2hhbmdlcyB0byBtYWtlDQp5b3VyIHNpdGUgbW9yZSBTRU8tZnJpZW5kbHkg SZJtIHN1cmUgeW91IGNhbiBjb252ZXJ0IG1vcmUgdmlzaXRvcnMgaW50bw0KbGVhZHMgYW5kIGdl dCBpdCBwbGFjZWQgaGlnaGVyIGluIHRoZSBvcmdhbmljIHNlYXJjaCByZXN1bHRzLCBmb3Iga2V5 d29yZHMNCnRoYXQgbWF0dGVyIHRvIHlvdSB0aGUgbW9zdC4NCg0KV2UgYXJlIFVTQSBiYXNlZCBj b21wYW55IHdpdGggYSBncmVhdCBpbi1ob3VzZSB0ZWNobmljYWwgdGVhbSB3aG8gcmVhbGx5DQpr bm93IHRoZWlyIHN0dWZmIGFib3V0IHNlYXJjaCBlbmdpbmUgb3B0aW1pemF0aW9uLg0KDQpXb3Vs ZCB5b3UgbGlrZSBhIGJpdCBtb3JlIGluZm9ybWF0aW9uIGFib3V0IGhvdyB0byBnaXZlIHlvdXIg d2Vic2l0ZSBhDQpib29zdCB3aXRoIGJldHRlciBTRU8/DQoNCkJlc3QgcmVnYXJkcywNCg0KQXZh IEhvYmJzDQpTRU8vV0VCIFNwZWNpYWxpc3QNCg0KW2ltYWdlOiBMaW5rZWRJbl0gW2ltYWdlOiBG YWNlYm9va10gW2ltYWdlOiBUd2l0dGVyXSBbaW1hZ2U6IFNreXBlXQ0KICAgICAgICAgICAgIFMg ICBFICBPICAgICAgICAgICAgKlNlYXJjaCBFbmdpbmUgT3B0aW1pemF0aW9uKg0KDQpXZSByZXNw ZWN0IHlvdXIgcHJpdmFjeSBhbmQgd2FudCB0byBtYWtlIHN1cmUgeW91IGFyZSBhd2FyZSBvZiBh IGZldw0KdGhpbmdzLiBCeSByZXBseWluZyB0byB0aGlzIGVtYWlsLCB5b3UgYXV0aG9yaXplIG91 ciBVU0EgYWZmaWxpYXRlcyB0aGF0DQpjYW4gaGVscCB3aXRoIHlvdXIgcHJvamVjdCB0byBjYWxs IHlvdSBhdCB0aGUgbnVtYmVyIHlvdSBwcm92aWRlZCwgYW5kIHlvdQ0KdW5kZXJzdGFuZCB0aGF0 IHRoZXkgbWF5IHVzZSBhdXRvbWF0ZWQgcGhvbmUgdGVjaG5vbG9neSB0byBjYWxsIHlvdS4gQXQg bm8NCnRpbWUgYXJlIHlvdSByZXF1aXJlZCB0byBtYWtlIGEgcHVyY2hhc2UuDQo= From owner-freebsd-arm@FreeBSD.ORG Thu Jan 16 00:41:39 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7DAE7EE; Thu, 16 Jan 2014 00:41:39 +0000 (UTC) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 538871858; Thu, 16 Jan 2014 00:41:39 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s0G0fWEj093207; Wed, 15 Jan 2014 19:41:37 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <52D72ABC.4080502@m5p.com> Date: Wed, 15 Jan 2014 19:41:32 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Raspberry Pi: still getting prefetch aborts References: <52BB73B4.5030000@m5p.com> <52D5D0F8.9050205@m5p.com> <1389794207.1230.27.camel@revolution.hippie.lan> In-Reply-To: <1389794207.1230.27.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Wed, 15 Jan 2014 19:41:37 -0500 (EST) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 00:41:39 -0000 On 01/15/14 08:56, Ian Lepore wrote: > On Tue, 2014-01-14 at 19:06 -0500, George Mitchell wrote: >> On 12/25/13 19:09, George Mitchell wrote: >>> FreeBSD 10.0-PRERELEASE (RPI-B) #0 r259866M: Wed Dec 25 17:26:28 EST 2013 >>> (M because I selected serial output in RPI-B) >>> >>> /usr/ports is NFS mounted from elsewhere. >>> [Long description of prefetch abort] [...] >> >> Well, that got a deafeningly silent response. I finally copied my >> /usr/ports onto the SD card instead of NFS mounting it, and now my >> port build is chugging along happily so far. So the problem, >> whatever it is, is triggered by NFS. -- George > > I've been consistantly unable to reproduce the userland crash you see on > rpi, even though the tracebacks and all make it look a lot like the > wrong-endian kernel crashes I see on Wandboard (although my gut tells me > it's not really the same problem). My setup is a lot like yours, with > nfs-mounted filesystems, but when I build ports that way it either works > fine, or the port builds die for other reasons. > > -- Ian > Well, for me, I still get the abort if /usr/ports is NFS-mounted. (To be more precise, in case it is a factor, I'm running the automounter and /usr/ports is a symbolic link to /host/sullivan/usr/local/pi/ports.) Build version: FreeBSD 10.0-PRERELEASE #0 r260564M svn version in /usr/ports: 337160 cd /usr/ports/ports-mgmt/pkg make gives an immediate prefetch abort 100% of the time. Putting /usr/ports on my SD card has gotten me a substantial part of the way through installing print/cups, though I have seen one freeze-up with no debugger prompt on the serial port and no response to a break. -- George From owner-freebsd-arm@FreeBSD.ORG Thu Jan 16 01:56:42 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54A1F49B; Thu, 16 Jan 2014 01:56:42 +0000 (UTC) Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1D8941EDC; Thu, 16 Jan 2014 01:56:41 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MZH00D001DU6600@smtpauth3.wiscmail.wisc.edu>; Wed, 15 Jan 2014 19:56:34 -0600 (CST) X-Spam-PmxInfo: Server=avs-3, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.16.15115, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from comporellon.tachypleus.net (adsl-76-208-68-77.dsl.mdsnwi.sbcglobal.net [76.208.68.77]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MZH00C1I1E6XC00@smtpauth3.wiscmail.wisc.edu>; Wed, 15 Jan 2014 19:56:32 -0600 (CST) Message-id: <52D73C4E.2080306@freebsd.org> Date: Wed, 15 Jan 2014 19:56:30 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 To: Julien Grall , Warner Losh Subject: Re: [RFC] Add support for Xen ARM guest on FreeBSD References: <1389733267-20822-1-git-send-email-julien.grall@linaro.org> <24851B79-7EC7-4E3A-94DB-4B9B86FDFFFC@bsdimp.com> <52D6B62A.9000208@linaro.org> In-reply-to: <52D6B62A.9000208@linaro.org> Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org, freebsd-xen@freebsd.org, freebsd-arm@FreeBSD.org, gibbs@freebsd.org, roger.pau@citrix.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 01:56:42 -0000 On 01/15/14 10:24, Julien Grall wrote: > On 01/15/2014 01:26 AM, Warner Losh wrote: >> On Jan 14, 2014, at 2:01 PM, Julien Grall wrote: >>> This new support brings 2 open questions (for both Xen and FreeBSD community). >>> When a new guest is created, the toolstack will generated a device tree which >>> will contains: >>> - The amount of memory >>> - The description of the platform (gic, timer, hypervisor node) >>> - PSCI node for SMP bringup >>> >>> Until now, Xen on ARM supported only Linux-based OS. When the support of >>> device tree was added in Xen for guest, we chose to use Linux device tree >>> bindings (gic, timer,...). It seems that FreeBSD choose a different way to >>> implement device tree: >>> - strictly respect ePAR (for interrupt-parent property) >>> - gic bindings different (only 1 interrupt cell) >>> >>> I would like to come with a common device tree specification (bindings, ...) >>> across every operating system. I know the Linux community is working on having >>> a device tree bindings out of the kernel tree. Does FreeBSD community plan to >>> work with Linux community for this purpose? >> We generally try to follow the common definitions for the FDT stuff. >> There are a few cases where we either lack the feature set of Linux, or >> where the Linux folks are moving quickly and changing the underlying > definitions >> where we wait for the standards to mature before we implement. In some > cases, where >> maturity hasn't happened, or where the bindings are overly Linux > centric (which in >> theory they aren't supposed to be, but sometimes wind up that way). > where we've not >> implemented things. > As I understand main bindings (gic, timer) are set in stone and won't > change. Ian Campbell has a repository with all the ARM bindings here: > http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git; > a=tree;f=Bindings/arm > > To compare the difference between the DT provided by Xen, and the one > correctly parsed by FreeBSD > - Xen: http://xenbits.xen.org/people/julieng/xenvm-4.2.dts > - FreeBSD: http://xenbits.xen.org/people/julieng/xenvm-bsd.dts > > >From Xen side: > - Every device should move under a simple-bus. I think it's harmless > for Linux side. > - How about hypervisor node? IHMO this node should also live under the > simple-bus. > > >From FreeBSD side: > - GIC and Timer bindings needs to be handled correctly (see below the > problem for the GIC) > - Less stricter about interrupt-parent property. Eg, look at the > grant-parent if there is no property interrupt-parent > - If the hypervisor doesn't live under simple-bus, the interrupt/memory > retrieving should be moved from simple-bus to nexus? > > Before the revision r260282 (I have added Nathan on cc), I was able to > use the Linux GIC bindings (see > http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git;a=blob;f=Bindings/arm/gic.txt) > without any issue. > > It seems the fdt bus, now consider the number of interrupt cells is > always 1. > > Thanks for the CC. Could you explain what you mean by "grant-parent" etc? "interrupt-parent" is a fundamental part of the way PAPR (and ePAPR) work, so I'm very very hesitant to start guessing. I think things have broken for you because some (a lot, actually) of OF code does not expect #interrupt-cells to be more than 2. Some APIs might need updating, which I'll try to take care of. Could you tell me what the difference between SPI and PPI is, by the way? On the subject of simple-bus, they usually aren't necessary. For example, all hypervisor devices on IBM hardware live under /vdevice, which is attached to the device tree root. They don't use MMIO, so simple-bus doesn't really make sense. How does Xen communicate with the OS in these devices? -Nathan From owner-freebsd-arm@FreeBSD.ORG Thu Jan 16 12:57:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68CD5104; Thu, 16 Jan 2014 12:57:08 +0000 (UTC) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1DF3215DF; Thu, 16 Jan 2014 12:57:06 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,667,1384300800"; d="scan'208";a="91345743" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 16 Jan 2014 12:57:04 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id 14.2.342.4; Thu, 16 Jan 2014 07:57:03 -0500 Received: from kaball.uk.xensource.com ([10.80.2.59]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1W3mVL-0004Ut-BY; Thu, 16 Jan 2014 12:57:03 +0000 Date: Thu, 16 Jan 2014 12:56:03 +0000 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Nathan Whitehorn Subject: Re: [Xen-devel] [RFC] Add support for Xen ARM guest on FreeBSD In-Reply-To: <52D73C4E.2080306@freebsd.org> Message-ID: References: <1389733267-20822-1-git-send-email-julien.grall@linaro.org> <24851B79-7EC7-4E3A-94DB-4B9B86FDFFFC@bsdimp.com> <52D6B62A.9000208@linaro.org> <52D73C4E.2080306@freebsd.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-DLP: MIA2 X-Mailman-Approved-At: Thu, 16 Jan 2014 15:01:36 +0000 Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org, freebsd-xen@freebsd.org, freebsd-arm@FreeBSD.org, gibbs@freebsd.org, roger.pau@citrix.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 12:57:08 -0000 On Wed, 15 Jan 2014, Nathan Whitehorn wrote: > On 01/15/14 10:24, Julien Grall wrote: > > On 01/15/2014 01:26 AM, Warner Losh wrote: > > > On Jan 14, 2014, at 2:01 PM, Julien Grall wrote: > > > > This new support brings 2 open questions (for both Xen and FreeBSD > > > > community). > > > > When a new guest is created, the toolstack will generated a device tree > > > > which > > > > will contains: > > > > - The amount of memory > > > > - The description of the platform (gic, timer, hypervisor node) > > > > - PSCI node for SMP bringup > > > > > > > > Until now, Xen on ARM supported only Linux-based OS. When the support of > > > > device tree was added in Xen for guest, we chose to use Linux device > > > > tree > > > > bindings (gic, timer,...). It seems that FreeBSD choose a different way > > > > to > > > > implement device tree: > > > > - strictly respect ePAR (for interrupt-parent property) > > > > - gic bindings different (only 1 interrupt cell) > > > > > > > > I would like to come with a common device tree specification (bindings, > > > > ...) > > > > across every operating system. I know the Linux community is working on > > > > having > > > > a device tree bindings out of the kernel tree. Does FreeBSD community > > > > plan to > > > > work with Linux community for this purpose? > > > We generally try to follow the common definitions for the FDT stuff. > > > There are a few cases where we either lack the feature set of Linux, or > > > where the Linux folks are moving quickly and changing the underlying > > definitions > > > where we wait for the standards to mature before we implement. In some > > cases, where > > > maturity hasn't happened, or where the bindings are overly Linux > > centric (which in > > > theory they aren't supposed to be, but sometimes wind up that way). > > where we've not > > > implemented things. > > As I understand main bindings (gic, timer) are set in stone and won't > > change. Ian Campbell has a repository with all the ARM bindings here: > > http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git; > > a=tree;f=Bindings/arm > > > > To compare the difference between the DT provided by Xen, and the one > > correctly parsed by FreeBSD > > - Xen: http://xenbits.xen.org/people/julieng/xenvm-4.2.dts > > - FreeBSD: http://xenbits.xen.org/people/julieng/xenvm-bsd.dts > > > > >From Xen side: > > - Every device should move under a simple-bus. I think it's harmless > > for Linux side. > > - How about hypervisor node? IHMO this node should also live under the > > simple-bus. > > > > >From FreeBSD side: > > - GIC and Timer bindings needs to be handled correctly (see below the > > problem for the GIC) > > - Less stricter about interrupt-parent property. Eg, look at the > > grant-parent if there is no property interrupt-parent > > - If the hypervisor doesn't live under simple-bus, the > > interrupt/memory > > retrieving should be moved from simple-bus to nexus? > > > > Before the revision r260282 (I have added Nathan on cc), I was able to > > use the Linux GIC bindings (see > > http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git;a=blob;f=Bindings/arm/gic.txt) > > without any issue. > > > > It seems the fdt bus, now consider the number of interrupt cells is > > always 1. > > > > > > Thanks for the CC. Could you explain what you mean by "grant-parent" etc? > "interrupt-parent" is a fundamental part of the way PAPR (and ePAPR) work, so > I'm very very hesitant to start guessing. I think things have broken for you > because some (a lot, actually) of OF code does not expect #interrupt-cells to > be more than 2. Some APIs might need updating, which I'll try to take care of. > Could you tell me what the difference between SPI and PPI is, by the way? SPI: Shared Peripheral Interrupt PPI: Private Peripheral Interrupt PPIs are per processor interrupts. > On the subject of simple-bus, they usually aren't necessary. For example, all > hypervisor devices on IBM hardware live under /vdevice, which is attached to > the device tree root. They don't use MMIO, so simple-bus doesn't really make > sense. How does Xen communicate with the OS in these devices? The PPI and the memory region advertized under the Xen hypervisor node on device tree are used to setup the basic infrastructure (grant table, event channels) needed by Xen paravirtualized devices. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 16 16:10:59 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60F1813C; Thu, 16 Jan 2014 16:10:59 +0000 (UTC) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1B49F1AC6; Thu, 16 Jan 2014 16:10:57 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,668,1384300800"; d="scan'208";a="91428093" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 16 Jan 2014 16:10:50 +0000 Received: from [10.80.2.80] (10.80.2.80) by FTLPEX01CL02.citrite.net (10.13.107.79) with Microsoft SMTP Server id 14.2.342.4; Thu, 16 Jan 2014 11:10:49 -0500 Message-ID: <1389888647.6697.22.camel@kazak.uk.xensource.com> Subject: Re: [RFC] Add support for Xen ARM guest on FreeBSD From: Ian Campbell To: Julien Grall Date: Thu, 16 Jan 2014 16:10:47 +0000 In-Reply-To: <52D6B62A.9000208@linaro.org> References: <1389733267-20822-1-git-send-email-julien.grall@linaro.org> <24851B79-7EC7-4E3A-94DB-4B9B86FDFFFC@bsdimp.com> <52D6B62A.9000208@linaro.org> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.2.80] X-DLP: MIA1 Cc: stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org, freebsd-xen@freebsd.org, freebsd-arm@FreeBSD.org, gibbs@freebsd.org, roger.pau@citrix.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 16:10:59 -0000 On Wed, 2014-01-15 at 16:24 +0000, Julien Grall wrote: > As I understand main bindings (gic, timer) are set in stone and won't > change. Ian Campbell has a repository with all the ARM bindings here: > http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git;a=tree;f=Bindings/arm FYI this tree is automatically extracted from the bindings in the Linux source, because long term we would like to split them out from Linux and try and standardize some (if not all) of them. This is exactly because these bindings should not be OS specific... Ian. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 16 22:26:48 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C8F69A5; Thu, 16 Jan 2014 22:26:48 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D3EAE1FCB; Thu, 16 Jan 2014 22:26:42 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s0GMQYl7086669; Fri, 17 Jan 2014 00:26:34 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s0GMQX3r086475; Thu, 16 Jan 2014 22:26:33 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 16 Jan 2014 22:26:33 GMT Message-Id: <201401162226.s0GMQX3r086475@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 22:26:48 -0000 TB --- 2014-01-16 22:00:51 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-01-16 22:00:51 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-01-16 22:00:51 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-01-16 22:00:51 - cleaning the object tree TB --- 2014-01-16 22:00:51 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-01-16 22:01:42 - At svn revision 260795 TB --- 2014-01-16 22:01:43 - building world TB --- 2014-01-16 22:01:43 - CROSS_BUILD_TESTING=YES TB --- 2014-01-16 22:01:43 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-16 22:01:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-16 22:01:43 - SRCCONF=/dev/null TB --- 2014-01-16 22:01:43 - TARGET=arm TB --- 2014-01-16 22:01:43 - TARGET_ARCH=arm TB --- 2014-01-16 22:01:43 - TZ=UTC TB --- 2014-01-16 22:01:43 - __MAKE_CONF=/dev/null TB --- 2014-01-16 22:01:43 - cd /src TB --- 2014-01-16 22:01:43 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jan 16 22:01:54 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools [...] c++ -O2 -pipe -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen -I. -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGDeclCXX.cpp -o CGDeclCXX.o c++ -O2 -pipe -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen -I. -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGException.cpp -o CGException.o c++ -O2 -pipe -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen -I. -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExpr.cpp -o CGExpr.o /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExpr.cpp: In member function 'void clang::CodeGen::CodeGenFunction::EmitStoreThroughLValue(clang::CodeGen::RValue, clang::CodeGen::LValue, bool)': /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGExpr.cpp:1423: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[3]: stopped in /src/lib/clang/libclangcodegen *** Error code 1 Stop. bmake[2]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-01-16 22:26:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-16 22:26:32 - ERROR: failed to build world TB --- 2014-01-16 22:26:32 - 1125.90 user 416.50 system 1541.30 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Fri Jan 17 00:36:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E36D26C for ; Fri, 17 Jan 2014 00:36:48 +0000 (UTC) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B1770192E for ; Fri, 17 Jan 2014 00:36:47 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id l18so1228815wgh.5 for ; Thu, 16 Jan 2014 16:36:40 -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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4wXhBVEK9bu6kQV4qJr65d7sAYxtH2FVJr6eGR3jehM=; b=Pfd+6u5bKCsezYIG0UcNIuLeXH/VIFAyKUM6F0zcV6vSbpK9bK9omUC4/ABLaQb/CY 2lLKkXeQQWw+OIlJazFHMVJQGLYwRR4v7wyO8c9Au7xnGe34YLCdG6BP3fRMdF1/27eh UPfrE10FcfZ5LBxCXmexIhjqmCw7n3NpL2p4hbfpCT0Gaoee7apfD66hsj5AY0BdERpY J174x9x91TDqMvdxtEheH/0VBknJeMFXPGZEJwBHT5Rv3CJHGwQcKVqYLZtLp3jLYRlB 3Z/buOVuxmGmXZeYZPL3pbcHt8Bmjn+8CfHDKFLWCmBQosW9QuHk2IpkbHAW+ZoMqq3v u3zA== X-Gm-Message-State: ALoCoQl0XBIm+P/DagTsmuJQbANWOslcKh8U2XQbW1RUSkhf3QSYgRmhLkqEEEudcKm1w2YYXGXJ X-Received: by 10.180.80.103 with SMTP id q7mr30118wix.14.1389919000069; Thu, 16 Jan 2014 16:36:40 -0800 (PST) Received: from [192.168.0.2] (cpc8-cmbg15-2-0-cust169.5-4.cable.virginm.net. [86.30.140.170]) by mx.google.com with ESMTPSA id ea4sm402202wib.7.2014.01.16.16.36.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Jan 2014 16:36:39 -0800 (PST) Message-ID: <52D87B15.5090208@linaro.org> Date: Fri, 17 Jan 2014 00:36:37 +0000 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nathan Whitehorn , Warner Losh Subject: Re: [RFC] Add support for Xen ARM guest on FreeBSD References: <1389733267-20822-1-git-send-email-julien.grall@linaro.org> <24851B79-7EC7-4E3A-94DB-4B9B86FDFFFC@bsdimp.com> <52D6B62A.9000208@linaro.org> <52D73C4E.2080306@freebsd.org> In-Reply-To: <52D73C4E.2080306@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org, freebsd-xen@freebsd.org, freebsd-arm@FreeBSD.org, gibbs@freebsd.org, roger.pau@citrix.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 00:36:48 -0000 On 01/16/2014 01:56 AM, Nathan Whitehorn wrote: > > Thanks for the CC. Could you explain what you mean by "grant-parent" > etc? "interrupt-parent" is a fundamental part of the way PAPR (and > ePAPR) work, so I'm very very hesitant to start guessing. I think things > have broken for you because some (a lot, actually) of OF code does not > expect #interrupt-cells to be more than 2. Some APIs might need > updating, which I'll try to take care of. Could you tell me what the > difference between SPI and PPI is, by the way? Sorry, I also made some typoes in my explanation so it was not clear. interrupt-parent is a property in a device node which links this node to an interrupt controller (in our case the GIC controller). The way to handle it on Linux and the ePAR is different: - ePAR (chapter 2.4) says: The physical wiring of an interrupt source to an interrupt controller is represented in the device tree with the interrupt-parent property. Nodes that represent interrupt-generating devices contain an interrupt-parent property which has a phandle value that points to the device to which the device's interrupts are routed, typically an interrupt controller. If an interrupt-generating device does not have an interrupt-parent property, its interrupt parent is assumed to be its device tree parent. From my understanding, it's mandatory to have an interrupt-parent property on each device node which is using interrupts. If it doesn't exist it will assume that the parent is interrupt controller. If I'm mistaken, at least FreeBSD handle the interrupt-parent property in this way. - Linux implementation will look at to the node, if the property doesn't exists, it will check if the ancestor has this property ... So the device tree below is valid on Linux, but not on FreeBSD: / { interrupt-parent = &gic gic: gic@10 { ... } timer@1 { interrupts = <...> } } Most of shipped device tree use this trick. IanC: I was reading the linux binding documentation (devicetree/booting-without-of.txt VII.2) and it seems that the explanation differs from the implementation, right? For the #interrupt-cells property, the problem starts in fdt_intr_to_rl (sys/dev/fdt/fdt_common.c:476). ofw_bus_map_intr is called always with the first cells of the interrupt no matter the number of cells specified by #interrupt-cells. > On the subject of simple-bus, they usually aren't necessary. For > example, all hypervisor devices on IBM hardware live under /vdevice, > which is attached to the device tree root. They don't use MMIO, so > simple-bus doesn't really make sense. How does Xen communicate with the > OS in these devices? > -Nathan As I understand, only the simple bus code (see simplebus_attach) is translating the interrupts in the device on a resource. So if you have a node directly attached to the root node with interrupts and MMIO, the driver won't be able to retrieve and translate the interrupts via bus_alloc_resources. In the Xen device tree, we have an hypervisor node directly attach to the root which contains both MMIO and interrupt used by Xen to communicate with the guest. -- Julien Grall From owner-freebsd-arm@FreeBSD.ORG Fri Jan 17 04:04:52 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2B6E9AB; Fri, 17 Jan 2014 04:04:52 +0000 (UTC) Received: from smtpauth2.wiscmail.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9C90E19A0; Fri, 17 Jan 2014 04:04:51 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MZI00E00YYQG100@smtpauth2.wiscmail.wisc.edu>; Thu, 16 Jan 2014 21:04:43 -0600 (CST) X-Spam-PmxInfo: Server=avs-2, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.17.25115, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from comporellon.tachypleus.net (adsl-76-208-68-77.dsl.mdsnwi.sbcglobal.net [76.208.68.77]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MZI00CCNZ7TJI00@smtpauth2.wiscmail.wisc.edu>; Thu, 16 Jan 2014 21:04:43 -0600 (CST) Message-id: <52D89DC9.7050303@freebsd.org> Date: Thu, 16 Jan 2014 21:04:41 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 To: Julien Grall , Warner Losh Subject: Re: [RFC] Add support for Xen ARM guest on FreeBSD References: <1389733267-20822-1-git-send-email-julien.grall@linaro.org> <24851B79-7EC7-4E3A-94DB-4B9B86FDFFFC@bsdimp.com> <52D6B62A.9000208@linaro.org> <52D73C4E.2080306@freebsd.org> <52D87B15.5090208@linaro.org> In-reply-to: <52D87B15.5090208@linaro.org> Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org, freebsd-xen@freebsd.org, freebsd-arm@FreeBSD.org, gibbs@freebsd.org, roger.pau@citrix.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 04:04:52 -0000 On 01/16/14 18:36, Julien Grall wrote: > > > On 01/16/2014 01:56 AM, Nathan Whitehorn wrote: >> >> Thanks for the CC. Could you explain what you mean by "grant-parent" >> etc? "interrupt-parent" is a fundamental part of the way PAPR (and >> ePAPR) work, so I'm very very hesitant to start guessing. I think things >> have broken for you because some (a lot, actually) of OF code does not >> expect #interrupt-cells to be more than 2. Some APIs might need >> updating, which I'll try to take care of. Could you tell me what the >> difference between SPI and PPI is, by the way? > > Sorry, I also made some typoes in my explanation so it was not clear. > > interrupt-parent is a property in a device node which links this node > to an interrupt controller (in our case the GIC controller). > > The way to handle it on Linux and the ePAR is different: > - ePAR (chapter 2.4) says: > The physical wiring of an interrupt source to an interrupt controller > is represented in the device tree with the interrupt-parent property. > Nodes that represent interrupt-generating devices contain an > interrupt-parent property which has a phandle value that points to the > device to which the device's interrupts are routed, typically an > interrupt controller. If an interrupt-generating device does not have > an interrupt-parent property, its interrupt parent is assumed to be > its device tree parent. > From my understanding, it's mandatory to have an interrupt-parent > property on each device node which is using interrupts. If it doesn't > exist it will assume that the parent is interrupt controller. > If I'm mistaken, at least FreeBSD handle the interrupt-parent property > in this way. > - Linux implementation will look at to the node, if the property > doesn't exists, it will check if the ancestor has this property ... > So the device tree below is valid on Linux, but not on FreeBSD: > > / { > interrupt-parent = &gic > > gic: gic@10 > { > ... > } > > timer@1 > { > interrupts = <...> > } > } > > Most of shipped device tree use this trick. > > IanC: I was reading the linux binding documentation > (devicetree/booting-without-of.txt VII.2) and it seems that the > explanation differs from the implementation, right? > > For the #interrupt-cells property, the problem starts in > fdt_intr_to_rl (sys/dev/fdt/fdt_common.c:476). ofw_bus_map_intr is > called always with the first cells of the interrupt no matter the > number of cells specified by #interrupt-cells. The specification is actually a little unclear on this point, but FreeBSD follows the same rules as Linux in any case. Most, if not all, FreeBSD code should check any ancestor at this point as well. In particular fdt_intr_to_rl does this. What it *doesn't* do is allow #interrupt-cells to be larger than 2. I'll fix this this weekend. >> On the subject of simple-bus, they usually aren't necessary. For >> example, all hypervisor devices on IBM hardware live under /vdevice, >> which is attached to the device tree root. They don't use MMIO, so >> simple-bus doesn't really make sense. How does Xen communicate with the >> OS in these devices? >> -Nathan > > As I understand, only the simple bus code (see simplebus_attach) is > translating the interrupts in the device on a resource. > So if you have a node directly attached to the root node with > interrupts and MMIO, the driver won't be able to retrieve and > translate the interrupts via bus_alloc_resources. Why not? nexus on ARM, MIPS, PowerPC, and sparc64 can do this. > In the Xen device tree, we have an hypervisor node directly attach to > the root which contains both MMIO and interrupt used by Xen to > communicate with the guest. > OK. This should be fine, though simplebus would also work if you use MMIO. -Nathan From owner-freebsd-arm@FreeBSD.ORG Fri Jan 17 09:29:28 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AB021D5; Fri, 17 Jan 2014 09:29:28 +0000 (UTC) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 30A361FCD; Fri, 17 Jan 2014 09:29:26 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,670,1384300800"; d="scan'208";a="93794219" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP; 17 Jan 2014 09:29:24 +0000 Received: from [10.80.2.80] (10.80.2.80) by FTLPEX01CL03.citrite.net (10.13.107.80) with Microsoft SMTP Server id 14.2.342.4; Fri, 17 Jan 2014 04:29:24 -0500 Message-ID: <1389950962.6697.33.camel@kazak.uk.xensource.com> Subject: Re: [RFC] Add support for Xen ARM guest on FreeBSD From: Ian Campbell To: Julien Grall Date: Fri, 17 Jan 2014 09:29:22 +0000 In-Reply-To: <52D87B15.5090208@linaro.org> References: <1389733267-20822-1-git-send-email-julien.grall@linaro.org> <24851B79-7EC7-4E3A-94DB-4B9B86FDFFFC@bsdimp.com> <52D6B62A.9000208@linaro.org> <52D73C4E.2080306@freebsd.org> <52D87B15.5090208@linaro.org> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.2.80] X-DLP: MIA1 Cc: stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org, freebsd-xen@freebsd.org, freebsd-arm@FreeBSD.org, gibbs@freebsd.org, roger.pau@citrix.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 09:29:28 -0000 On Fri, 2014-01-17 at 00:36 +0000, Julien Grall wrote: > > On 01/16/2014 01:56 AM, Nathan Whitehorn wrote: > > > > Thanks for the CC. Could you explain what you mean by "grant-parent" > > etc? "interrupt-parent" is a fundamental part of the way PAPR (and > > ePAPR) work, so I'm very very hesitant to start guessing. I think things > > have broken for you because some (a lot, actually) of OF code does not > > expect #interrupt-cells to be more than 2. Some APIs might need > > updating, which I'll try to take care of. Could you tell me what the > > difference between SPI and PPI is, by the way? > > Sorry, I also made some typoes in my explanation so it was not clear. > > interrupt-parent is a property in a device node which links this node to > an interrupt controller (in our case the GIC controller). > > The way to handle it on Linux and the ePAR is different: > - ePAR (chapter 2.4) says: > The physical wiring of an interrupt source to an interrupt controller is > represented in the device tree with the interrupt-parent property. Nodes > that represent interrupt-generating devices contain an > interrupt-parent property which has a phandle value that points to the > device to which the device's interrupts are routed, typically an > interrupt controller. If an interrupt-generating device does not have > an interrupt-parent property, its interrupt parent is assumed to be its > device tree parent. > From my understanding, it's mandatory to have an interrupt-parent > property on each device node which is using interrupts. If it doesn't > exist it will assume that the parent is interrupt controller. > If I'm mistaken, at least FreeBSD handle the interrupt-parent property > in this way. > - Linux implementation will look at to the node, if the property > doesn't exists, it will check if the ancestor has this property ... > > So the device tree below is valid on Linux, but not on FreeBSD: > > / { > interrupt-parent = &gic > > gic: gic@10 > { > ... > } > > timer@1 > { > interrupts = <...> > } > } > > Most of shipped device tree use this trick. > > IanC: I was reading the linux binding documentation > (devicetree/booting-without-of.txt VII.2) and it seems that the > explanation differs from the implementation, right? I vaguely recall someone saying that the Linux behaviour was a quirk of some real PPC system which supplied a DTB which required this behaviour which has leaked into the other platforms. It does also sound like a useful extension to the spec which makes the dtb easier to write. The right place to discuss this would probably be either #devicetree on freenode or devicetree@vger.kernel.org. > > On the subject of simple-bus, they usually aren't necessary. For > > example, all hypervisor devices on IBM hardware live under /vdevice, > > which is attached to the device tree root. They don't use MMIO, so > > simple-bus doesn't really make sense. How does Xen communicate with the > > OS in these devices? > > -Nathan > > As I understand, only the simple bus code (see simplebus_attach) is > translating the interrupts in the device on a resource. > So if you have a node directly attached to the root node with interrupts > and MMIO, the driver won't be able to retrieve and translate the > interrupts via bus_alloc_resources. Is the root node not considered to be a "top-level simple-bus" with a 1:1 mapping of MMIO and interrupts? (Linux seems to treat it this way, but I haven't trawled the docs for a spec reference to back that behaviour up). I take it BSD doesn't do this? Ian. From owner-freebsd-arm@FreeBSD.ORG Fri Jan 17 13:45:33 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AA4A7D3 for ; Fri, 17 Jan 2014 13:45:33 +0000 (UTC) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8E80814C5 for ; Fri, 17 Jan 2014 13:45:32 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id u57so4590827wes.1 for ; Fri, 17 Jan 2014 05:45:24 -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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=o20v3u1W/AFMqlLmKwxjEwoJnXnNjVeiKZVFU838MHA=; b=SqEERapbycfj6dmNKJy6flBgyyNo8txxF0TMpy3436fGzuygG3dOztynG6LBVggYJi cKiyep7dCTlu3HQKlx55cXE+CyG9gwdmJSJCbtKqynzKKObX0l2fbXqUIy/ugTA8xQ5t YsIyylRov4lm/zZvs92BIXLy7M6n6uAtnFmaRmpSQfwwfO93DROerpze9iP6Aj9oi5rn 7fnh7m6fgf0Swc7iH/DzBzuX47nQ9C+yyRQ/6Te8jL7jfWbPm0Mu1XhCJUiSVhx82VFB 5sO0z0DBw7nzTd2haETuLD5K/+ZFE8ym2X9g0wB0AJIgx3zsVZqEfZ0BVv0siZg+cIej IQTA== X-Gm-Message-State: ALoCoQmRdlE+FhJFZDaJZ+Kv9nktyk8+ppaYJfBbbzaK0ZF8n9q3zFtXJDVhWL+kNnGh0f5nDmUN X-Received: by 10.180.160.166 with SMTP id xl6mr2472944wib.43.1389966324694; Fri, 17 Jan 2014 05:45:24 -0800 (PST) Received: from [192.168.0.2] (cpc8-cmbg15-2-0-cust169.5-4.cable.virginm.net. [86.30.140.170]) by mx.google.com with ESMTPSA id dm2sm3286200wib.8.2014.01.17.05.45.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Jan 2014 05:45:23 -0800 (PST) Message-ID: <52D933F2.8000101@linaro.org> Date: Fri, 17 Jan 2014 13:45:22 +0000 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nathan Whitehorn , Warner Losh Subject: Re: [RFC] Add support for Xen ARM guest on FreeBSD References: <1389733267-20822-1-git-send-email-julien.grall@linaro.org> <24851B79-7EC7-4E3A-94DB-4B9B86FDFFFC@bsdimp.com> <52D6B62A.9000208@linaro.org> <52D73C4E.2080306@freebsd.org> <52D87B15.5090208@linaro.org> <52D89DC9.7050303@freebsd.org> In-Reply-To: <52D89DC9.7050303@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org, freebsd-xen@freebsd.org, freebsd-arm@FreeBSD.org, gibbs@freebsd.org, roger.pau@citrix.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 13:45:33 -0000 On 01/17/2014 03:04 AM, Nathan Whitehorn wrote: > On 01/16/14 18:36, Julien Grall wrote: > > The specification is actually a little unclear on this point, but > FreeBSD follows the same rules as Linux in any case. Most, if not all, > FreeBSD code should check any ancestor at this point as well. In > particular fdt_intr_to_rl does this. What it *doesn't* do is allow > #interrupt-cells to be larger than 2. I'll fix this this weekend. Thanks, for working on this part. Another things to take into account: the first cell doesn't always contain the interrupt. With the Linux binding (#interrupt-cells == 3) - cell 1: 1 or 0 (PPI vs SPI) - cell 2: relative IRQ number to the start of PPI/SPI - cell 3: cpu mask + interrupt flags (edge/level...) >>> On the subject of simple-bus, they usually aren't necessary. For >>> example, all hypervisor devices on IBM hardware live under /vdevice, >>> which is attached to the device tree root. They don't use MMIO, so >>> simple-bus doesn't really make sense. How does Xen communicate with the >>> OS in these devices? >>> -Nathan >> >> As I understand, only the simple bus code (see simplebus_attach) is >> translating the interrupts in the device on a resource. >> So if you have a node directly attached to the root node with >> interrupts and MMIO, the driver won't be able to retrieve and >> translate the interrupts via bus_alloc_resources. > > Why not? nexus on ARM, MIPS, PowerPC, and sparc64 can do this. I have noticed at least one issue (which is not related to my problem): - When the OFW nexus translate IRQ (with #interrupt-cells > 1), the rid will be equal to 0, 0 + #interrupt-cells, ... So the number will be discontinued. Rather than on simple-bus for the same device, the rid will be 0, 1, 2... For my issue, I will look at it again this week-end. BTW when I look to the FDT (sys/dev/fdt_common.c) and the ofw (sys/dev/ofw_nexus.c) code, I have notice that lots of code are duplicated. It would be nice to have common helper to avoid duplicate code and issue for the future :). -- Julien Grall From owner-freebsd-arm@FreeBSD.ORG Fri Jan 17 13:49:44 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7420C86D for ; Fri, 17 Jan 2014 13:49:44 +0000 (UTC) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0318314F2 for ; Fri, 17 Jan 2014 13:49:43 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id l18so1779852wgh.5 for ; Fri, 17 Jan 2014 05:49:42 -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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gptWh6SCeZgU4ox3TMfLGNjiaIT4/FIrU9bsOrmbQ3o=; b=MJcmXHfJkbIDL0viXCZXfJF8CoN2d68l+WmCO1B3CY4qSN3wQZ+o/ux58CYsAGCB29 qtsv0PXxtA8tsp/EFv7v+liNiEUnF28/ee2iO3QosjefKZ8ZlGw2Xd4UpJwlmCoredqf FnuTtOsWuJp2PEO8oMSrgye71Zy2ExXkuK0j9QxKSdny/gtkWAPeectpsl/wgDtFTgEh SeJUz40SCPhCFtDG8umck2cRTAWkLbLDdHW9tlc8c34GN/IHusBwlB8quB9NIS/1kyno zHW27RyZx5x4NafL1mmrslHnZFq5q5RLlX5KuXkOHvYgcfVhKauA6vnwFKPinvv0sVRB DCHg== X-Gm-Message-State: ALoCoQlj9uzptbYT4yk7/1ThhFOIVGrkZ6g2Sqz2rGDNubXuZ/fehmmbzyPGYUpCzx5AiRFp283V X-Received: by 10.194.92.7 with SMTP id ci7mr2157335wjb.58.1389966582419; Fri, 17 Jan 2014 05:49:42 -0800 (PST) Received: from [192.168.0.2] (cpc8-cmbg15-2-0-cust169.5-4.cable.virginm.net. [86.30.140.170]) by mx.google.com with ESMTPSA id x4sm3327855wif.0.2014.01.17.05.49.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Jan 2014 05:49:41 -0800 (PST) Message-ID: <52D934F4.709@linaro.org> Date: Fri, 17 Jan 2014 13:49:40 +0000 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ian Campbell Subject: Re: [RFC] Add support for Xen ARM guest on FreeBSD References: <1389733267-20822-1-git-send-email-julien.grall@linaro.org> <24851B79-7EC7-4E3A-94DB-4B9B86FDFFFC@bsdimp.com> <52D6B62A.9000208@linaro.org> <52D73C4E.2080306@freebsd.org> <52D87B15.5090208@linaro.org> <1389950962.6697.33.camel@kazak.uk.xensource.com> In-Reply-To: <1389950962.6697.33.camel@kazak.uk.xensource.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org, freebsd-xen@freebsd.org, freebsd-arm@FreeBSD.org, gibbs@freebsd.org, roger.pau@citrix.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 13:49:44 -0000 On 01/17/2014 09:29 AM, Ian Campbell wrote: > On Fri, 2014-01-17 at 00:36 +0000, Julien Grall wrote: >> >> On 01/16/2014 01:56 AM, Nathan Whitehorn wrote: >>> On the subject of simple-bus, they usually aren't necessary. For >>> example, all hypervisor devices on IBM hardware live under /vdevice, >>> which is attached to the device tree root. They don't use MMIO, so >>> simple-bus doesn't really make sense. How does Xen communicate with the >>> OS in these devices? >>> -Nathan >> >> As I understand, only the simple bus code (see simplebus_attach) is >> translating the interrupts in the device on a resource. >> So if you have a node directly attached to the root node with interrupts >> and MMIO, the driver won't be able to retrieve and translate the >> interrupts via bus_alloc_resources. > > Is the root node not considered to be a "top-level simple-bus" with a > 1:1 mapping of MMIO and interrupts? (Linux seems to treat it this way, > but I haven't trawled the docs for a spec reference to back that > behaviour up). I take it BSD doesn't do this? There is 2 different paths on FreeBSD to decode interrupt/MMIO (depending if you are under the root node or a simple-bus node). Most of the code is duplicated but there are some parts which differs (for instance interrupt decoding, see my answer to Nathan). I will look at closer to the code this week-end and see if I can fix it. -- Julien Grall From owner-freebsd-arm@FreeBSD.ORG Fri Jan 17 15:27:30 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C00A894C; Fri, 17 Jan 2014 15:27:30 +0000 (UTC) Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8879B1E00; Fri, 17 Jan 2014 15:27:30 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MZJ00200X9S0G00@smtpauth4.wiscmail.wisc.edu>; Fri, 17 Jan 2014 09:27:23 -0600 (CST) X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.17.151815, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from comporellon.tachypleus.net (adsl-76-208-68-77.dsl.mdsnwi.sbcglobal.net [76.208.68.77]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MZJ00D54XLLZ510@smtpauth4.wiscmail.wisc.edu>; Fri, 17 Jan 2014 09:27:23 -0600 (CST) Message-id: <52D94BD9.5020209@freebsd.org> Date: Fri, 17 Jan 2014 09:27:21 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 To: Julien Grall , Warner Losh Subject: Re: [RFC] Add support for Xen ARM guest on FreeBSD References: <1389733267-20822-1-git-send-email-julien.grall@linaro.org> <24851B79-7EC7-4E3A-94DB-4B9B86FDFFFC@bsdimp.com> <52D6B62A.9000208@linaro.org> <52D73C4E.2080306@freebsd.org> <52D87B15.5090208@linaro.org> <52D89DC9.7050303@freebsd.org> <52D933F2.8000101@linaro.org> In-reply-to: <52D933F2.8000101@linaro.org> Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org, freebsd-xen@freebsd.org, freebsd-arm@FreeBSD.org, gibbs@freebsd.org, roger.pau@citrix.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 15:27:30 -0000 On 01/17/14 07:45, Julien Grall wrote: > > > On 01/17/2014 03:04 AM, Nathan Whitehorn wrote: >> On 01/16/14 18:36, Julien Grall wrote: >> >> The specification is actually a little unclear on this point, but >> FreeBSD follows the same rules as Linux in any case. Most, if not all, >> FreeBSD code should check any ancestor at this point as well. In >> particular fdt_intr_to_rl does this. What it *doesn't* do is allow >> #interrupt-cells to be larger than 2. I'll fix this this weekend. > > Thanks, for working on this part. > > Another things to take into account: the first cell doesn't always > contain the interrupt. > With the Linux binding (#interrupt-cells == 3) > - cell 1: 1 or 0 (PPI vs SPI) > - cell 2: relative IRQ number to the start of PPI/SPI > - cell 3: cpu mask + interrupt flags (edge/level...) > ` Yep. This will require a little API redesign, but shouldn't be that bad. >>>> On the subject of simple-bus, they usually aren't necessary. For >>>> example, all hypervisor devices on IBM hardware live under /vdevice, >>>> which is attached to the device tree root. They don't use MMIO, so >>>> simple-bus doesn't really make sense. How does Xen communicate with >>>> the >>>> OS in these devices? >>>> -Nathan >>> >>> As I understand, only the simple bus code (see simplebus_attach) is >>> translating the interrupts in the device on a resource. >>> So if you have a node directly attached to the root node with >>> interrupts and MMIO, the driver won't be able to retrieve and >>> translate the interrupts via bus_alloc_resources. >> >> Why not? nexus on ARM, MIPS, PowerPC, and sparc64 can do this. > > I have noticed at least one issue (which is not related to my problem): > - When the OFW nexus translate IRQ (with #interrupt-cells > 1), the > rid will be equal to 0, 0 + #interrupt-cells, ... So the number will > be discontinued. Rather than on simple-bus for the same device, the > rid will be 0, 1, 2... Interesting. I'll investigate. > For my issue, I will look at it again this week-end. > > BTW when I look to the FDT (sys/dev/fdt_common.c) and the ofw > (sys/dev/ofw_nexus.c) code, I have notice that lots of code are > duplicated. > > It would be nice to have common helper to avoid duplicate code and > issue for the future :). > I'm in the middle of cleaning all this up (which is how I'm on the hook for breaking your case!). Most of fdt_common.c is not long for this world. -Nathan From owner-freebsd-arm@FreeBSD.ORG Sat Jan 18 00:24:58 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9C1A3A8 for ; Sat, 18 Jan 2014 00:24:58 +0000 (UTC) Received: from kithrup.com (Kithrup.COM [64.142.31.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 97A1E1974 for ; Sat, 18 Jan 2014 00:24:58 +0000 (UTC) Received: from kithrup.com (localhost [127.0.0.1]) by kithrup.com (8.14.4/8.14.4) with ESMTP id s0HNwlRw008623 for ; Fri, 17 Jan 2014 15:58:47 -0800 (PST) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.14.4/8.14.4/Submit) id s0HNwlM2008622 for freebsd-arm@FreeBSD.org; Fri, 17 Jan 2014 15:58:47 -0800 (PST) (envelope-from sef) Date: Fri, 17 Jan 2014 15:58:47 -0800 (PST) From: Sean Eric Fagan Message-Id: <201401172358.s0HNwlM2008622@kithrup.com> To: freebsd-arm@FreeBSD.org Subject: dtrace X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 00:24:58 -0000 I'm dumb, I guess. I can't figure out what's needed for dtrace to work. I've got the various modules compiled, and the libraries and utilities, and "dtrace -l" shows lots of trace points, but if I try to actually trace anything, it sadly hangs the pi. Suggestions? From owner-freebsd-arm@FreeBSD.ORG Sat Jan 18 14:18:23 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90D4A6D2 for ; Sat, 18 Jan 2014 14:18:23 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 63F17149B for ; Sat, 18 Jan 2014 14:18:23 +0000 (UTC) Received: from 63-234-219-145.dia.static.qwest.net ([63.234.219.145]:41466 helo=[172.26.54.242]) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1W4Wj7-0001Jl-F2; Sat, 18 Jan 2014 09:18:21 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: dtrace From: George Neville-Neil In-Reply-To: <201401172358.s0HNwlM2008622@kithrup.com> Date: Sat, 18 Jan 2014 09:18:21 -0500 Content-Transfer-Encoding: 7bit Message-Id: <37F5A376-4A86-4675-9319-9C6D0B11CB7E@neville-neil.com> References: <201401172358.s0HNwlM2008622@kithrup.com> To: Sean Eric Fagan X-Mailer: Apple Mail (2.1827) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 14:18:23 -0000 On Jan 17, 2014, at 18:58 , Sean Eric Fagan wrote: > I'm dumb, I guess. I can't figure out what's needed for dtrace to > work. > > I've got the various modules compiled, and the libraries and utilities, > and "dtrace -l" shows lots of trace points, but if I try to actually > trace anything, it sadly hangs the pi. > > Suggestions? Panic the box and get us a back trace. Best, George From owner-freebsd-arm@FreeBSD.ORG Sat Jan 18 19:46:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 821BD8F5; Sat, 18 Jan 2014 19:46:51 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5684E1A9A; Sat, 18 Jan 2014 19:46:50 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s0IJkojx084244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Jan 2014 11:46:50 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s0IJknHu084243; Sat, 18 Jan 2014 11:46:49 -0800 (PST) (envelope-from jmg) Date: Sat, 18 Jan 2014 11:46:49 -0800 From: John-Mark Gurney To: Andrew Turner , Ian Lepore , "freebsd-arm@freebsd.org" Subject: Re: svn commit: r258412 - in head/sys/arm: at91 econa s3c2xx0 sa11x0 xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa Message-ID: <20140118194649.GQ75135@funkthat.com> Mail-Followup-To: Andrew Turner , Ian Lepore , "freebsd-arm@freebsd.org" References: <201311210108.rAL18AoQ051365@svn.freebsd.org> <20131221061048.GC99167@funkthat.com> <20140108071643.GB99167@funkthat.com> <1389197091.1158.370.camel@revolution.hippie.lan> <20140108173909.GF99167@funkthat.com> <20140110230241.GS46596@funkthat.com> <20140111135156.251a70fa@bender.Home> <20140111205303.GZ46596@funkthat.com> <20140113055215.GB2982@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140113055215.GB2982@funkthat.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 18 Jan 2014 11:46:50 -0800 (PST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 19:46:51 -0000 John-Mark Gurney wrote this message on Sun, Jan 12, 2014 at 21:52 -0800: > which I'll take a look at shortly, but more importantly, as sshd > comes up, I get: > panic: vm_page_alloc: page 0xc0805db0 is wired > > I can't get a bt from the crash though, as this is what I get: > db> bt > Tracing pid 793 tid 100054 td 0xc10db960 > db_trace_self() at db_trace_self > pc = 0xc05564d0 lr = 0xc055655c (db_trace_thread+0x50) > sp = 0xc09578c0 fp = 0xc03cc32c > db_trace_thread() at db_trace_thread+0x50 > pc = 0xc055655c lr = 0xc022b4d4 (db_command_init+0x620) > sp = 0xc0957920 fp = 0xc03cc32c > db_command_init() at db_command_init+0x620 > pc = 0xc022b4d4 lr = 0xc022abac (db_skip_to_eol+0x480) > sp = 0xc0957938 fp = 0xc03cc32c > r4 = 0xc066fcd4 r5 = 0x00000000 > db_skip_to_eol() at db_skip_to_eol+0x480 > pc = 0xc022abac lr = 0xc022ad14 (db_command_loop+0x5c) > sp = 0xc09579d8 fp = 0xc03cc32c > r4 = 0xc09579ec r5 = 0xc066ffa4 > r6 = 0x00000000 r7 = 0x00000000 > r8 = 0x00000001 r10 = 0x600000d3 > db_command_loop() at db_command_loop+0x5c > pc = 0xc022ad14 lr = 0xc022d15c (X_db_sym_numargs+0xec) > sp = 0xc09579e0 fp = 0xc03cc32c > X_db_sym_numargs() at X_db_sym_numargs+0xec > pc = 0xc022d15c lr = 0xc03cc56c (kdb_trap+0xa4) > sp = 0xc0957af8 fp = 0xc03cc32c > r4 = 0xc0957b90 > kdb_trap() at kdb_trap+0xa4 > pc = 0xc03cc56c lr = 0xc0567dc8 (undefinedinstruction+0x2d8) > sp = 0xc0957b18 fp = 0xc03cc32c > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0x00000000 r7 = 0xc0957b90 > r8 = 0xe7ffffff r10 = 0xe7ffffff > undefinedinstruction() at undefinedinstruction+0x2d8 > pc = 0xc0567dc8 lr = 0xc0558218 (exception_exit) > sp = 0xc0957b90 fp = 0xc06012c8 > r4 = 0xffffffff r5 = 0xffff1004 > r6 = 0xc06b9494 r7 = 0xc0957c14 > r8 = 0xc10db960 r9 = 0x00000001 > r10 = 0x00000000 > exception_exit() at exception_exit > pc = 0xc0558218 lr = 0xc03cc324 (kdb_enter+0x38) > sp = 0xc0957be4 fp = 0xc06012c8 > r0 = 0x00000012 r1 = 0x60000013 > r2 = 0xc06c785c r3 = 0xc06b94c0 > r4 = 0xc05d2898 r5 = 0xc0601dc0 > r6 = 0xc06b9494 r7 = 0xc0957c14 > r8 = 0xc10db960 r9 = 0x00000001 > r10 = 0x00000000 r12 = 0xc05cfb50 > kdb_enter() at kdb_enter+0x44 > pc = 0xc03cc330 lr = 0xc0601dc0 (0xc0601dc0) > sp = 0xc0957bec fp = 0xc06012c8 > r4 = 0xc039a144 > xscale_event_codes_size() at 0xc0601dc0 > pc = 0xc0601dc0 lr = 0x00000000 (0) > sp = 0xc0957bf4 fp = 0xc06012c8 > Unable to unwind into user mode > > Though, I don't think user mode should start there.. there should be > a few more frames... I'm blocked on this... I can't do anymore work on making armeb work till someone helps me figure out the above. Even if I disable sshd, it just panics a little later in the boot process. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sat Jan 18 23:41:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF1CEEF6 for ; Sat, 18 Jan 2014 23:41:54 +0000 (UTC) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4F26E1AA1 for ; Sat, 18 Jan 2014 23:41:54 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id g10so2042785wiw.7 for ; Sat, 18 Jan 2014 15:41:46 -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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=h76klGEasTqnnGciDyydOIaeOjOmyJ0mgLXev17A2ug=; b=I75UFRDjues9/BFXvqt5/fqatDoKs6V8adiTEMgva1k9oJn7jWV8Wsvw3JoZ1ju8M0 UZD0TD+qBpAJs3JyQwJxDsNzt3Co3e/ctEPH5CSBBgLkOeU5QDfLGXqc5shPrOD2p9k7 GsFqGBKpK5M5xDHcP0kOO2wciEKK3Uy/7TsyKLV8/ScRC2AKNUprfFtehJZ1q6EB4pi4 /9IoqaI+bL4ayNpjaOcse28rjhy2s4bhal7qIGzak5tHnVrJLjAXApDRbAfEJiGOT9xo XDvJcrX6TtA6Kko16JZysTngYmW+97TMmO62z0wzKNKotyKHLjWmC5ULV7TA23yrXXxX jInA== X-Gm-Message-State: ALoCoQmCL/WMM7RWxFKDI8yTwq5BVrkFk6kJqgR1TfOJcniL5n8ScjAwPFat3iMG9uCCB+sURqEi X-Received: by 10.194.175.202 with SMTP id cc10mr8113022wjc.48.1390088506777; Sat, 18 Jan 2014 15:41:46 -0800 (PST) Received: from [192.168.0.2] (cpc8-cmbg15-2-0-cust169.5-4.cable.virginm.net. [86.30.140.170]) by mx.google.com with ESMTPSA id w1sm16375423wix.1.2014.01.18.15.41.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 18 Jan 2014 15:41:46 -0800 (PST) Message-ID: <52DB1138.6010804@linaro.org> Date: Sat, 18 Jan 2014 23:41:44 +0000 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nathan Whitehorn , Warner Losh Subject: Re: [RFC] Add support for Xen ARM guest on FreeBSD References: <1389733267-20822-1-git-send-email-julien.grall@linaro.org> <24851B79-7EC7-4E3A-94DB-4B9B86FDFFFC@bsdimp.com> <52D6B62A.9000208@linaro.org> <52D73C4E.2080306@freebsd.org> <52D87B15.5090208@linaro.org> <52D89DC9.7050303@freebsd.org> In-Reply-To: <52D89DC9.7050303@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org, freebsd-xen@freebsd.org, freebsd-arm@FreeBSD.org, gibbs@freebsd.org, roger.pau@citrix.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 23:41:54 -0000 Hello Nathan, On 01/17/2014 03:04 AM, Nathan Whitehorn wrote: > On 01/16/14 18:36, Julien Grall wrote: >> >> >> On 01/16/2014 01:56 AM, Nathan Whitehorn wrote: >> As I understand, only the simple bus code (see simplebus_attach) is >> translating the interrupts in the device on a resource. >> So if you have a node directly attached to the root node with >> interrupts and MMIO, the driver won't be able to retrieve and >> translate the interrupts via bus_alloc_resources. > Why not? nexus on ARM, MIPS, PowerPC, and sparc64 can do this. I have digged into the code to find the reason of my issue. FreeBSD is receiving a VM fault when the driver (xen-dt) is trying to setup the IRQ. This is because the GIC is not yet initialized but FreeBSD asks to unmask the IRQ (sys/arm/arm/gic.c:306). With this problem, all device nodes that are before the GIC in the device tree can't have interrupts. For instance this simple device will segfault on FreeBSD: / { mybus { compatible = "simple-bus"; mynode { interrupt-parent = &gic; interrupts = <...>; }; gic: gic@xxxx { interrupt-controller; } }; }; The node "mynode" will have to move after the GIC to be able to work correctly. -- Julien Grall