From owner-freebsd-arm@FreeBSD.ORG Sun Dec 23 05:07:11 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AC14F5E5 for ; Sun, 23 Dec 2012 05:07:11 +0000 (UTC) (envelope-from wynkoop@wa3yre.wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4E0E88FC13 for ; Sun, 23 Dec 2012 05:07:10 +0000 (UTC) Received: from mail.wynn.com (mail.wynn.com [199.89.147.3]) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id qBN5726S095101 for ; Sun, 23 Dec 2012 00:07:02 -0500 (EST) (envelope-from wynkoop@wa3yre.wynn.com) Received: from mail.wynn.com ([199.89.147.3] helo=mail.wynn.com) by ASSP-nospam; 23 Dec 2012 00:07:02 -0500 Received: (from wynkoop@localhost) by mail.wynn.com (8.14.3/8.14.3/Submit) id qBN572su095100 for freebsd-arm@freebsd.org; Sun, 23 Dec 2012 00:07:02 -0500 (EST) (envelope-from wynkoop) Message-Id: <201212230507.qBN572su095100@mail.wynn.com> Subject: beaglebone usb problems To: freebsd-arm@freebsd.org Date: Sun, 23 Dec 2012 00:07:02 -0500 (EST) Sender: wynkoop@wa3yre.wynn.com From: wynkoop@wynn.com X-Mailer: ELM [version 2.4ME+ PL124c (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 05:07:11 -0000 Greeting- Today I grabbed the lattest kernel and usreland sources with csup onto my beaglebone with the idea of building a kernel that would support usb. I used the default BEAGLEBOARD config file that I found in the ARM branch of /usr/src/sys. After a crash on building because of lack of memory I got the new kernel built and installed by adding some swap space. Not the best thing to do to an SD card, but a needed evil. I completed the build of the kernel and installed it. Upon reboot the system is still not seeing the USB BUS. I have verified that it sees the USB bus under the provided gnu/linux distribution. [ 0.553985] usbcore: registered new interface driver cdc_acm [ 0.554077] usbcore: registered new interface driver usblp [ 0.554138] usbcore: registered new interface driver cdc_wdm [ 0.554199] usbcore: registered new interface driver uas [ 0.554321] usbcore: registered new interface driver usb-storage [ 0.554412] usbcore: registered new interface driver libusual [ 0.561981] usbcore: registered new interface driver usbhid [ 0.561981] usbhid: USB HID core driver [ 0.562927] usbcore: registered new interface driver snd-usb-audio [ 0.673187] usb 1-1: new high-speed USB device number 2 using musb-hdrc [ 0.813659] usb 1-1: New USB device found, idVendor=0781, idProduct=5573 [ 0.813690] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 0.813690] usb 1-1: Product: Staples [ 0.813690] usb 1-1: Manufacturer: [ 0.813720] usb 1-1: SerialNumber: 4C532000070802101254 [ 0.815277] scsi0 : usb-storage 1-1:1.0 [ 2.234497] musb-hdrc musb-hdrc.0: MUSB HDRC host driver [ 2.234527] musb-hdrc musb-hdrc.0: new USB bus registered, assigned bus number 2 [ 2.234649] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 [ 2.234649] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.234680] usb usb2: Product: MUSB HDRC host driver [ 2.234680] usb usb2: Manufacturer: Linux 3.2.28 musb-hcd [ 2.234680] usb usb2: SerialNumber: musb-hdrc.0 root@beaglebone:~# Plugging in a supported USB wifi device under Linux produced the following: [ 246.557800] usb 1-1: USB disconnect, device number 2 [ 253.454040] usb 1-1: new high-speed USB device number 3 using musb-hdrc [ 253.747406] usb 1-1: New USB device found, idVendor=2001, idProduct=3c00 [ 253.747436] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 253.747467] usb 1-1: Product: 802.11g WLAN Adapter [ 253.747467] usb 1-1: Manufacturer: ANI [ 253.828186] cfg80211: Calling CRDA to update world regulatory domain [ 254.014068] usb 1-1: reset high-speed USB device number 3 using musb-hdrc [ 254.325317] ieee80211 phy0: Selected rate control algorithm 'pid' [ 254.326263] Registered led device: rt2500usb-phy0::radio [ 254.326385] Registered led device: rt2500usb-phy0::quality [ 254.342895] usbcore: registered new interface driver rt2500usb [ 254.505523] ADDRCONF(NETDEV_UP): wlan0: link is not ready root@beaglebone:~# ifconfig wlan0 wlan0 Link encap:Ethernet HWaddr 00:13:46:97:95:ED UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) So I think I can say the hardware is working. Under FreeBSD 10 we see the following: root@beaglebone:~ # dmesg | grep -i usb am335x_pmic0: TPS65217B ver 1.1 powered by USB and AC root@beaglebone:~ # In other words we do not even see the bus let alone any wifi or storage device inserted into the bus. My kernel config has the needed stuff I believe. Here is the snippit. # USB support device usb options USB_DEBUG #options USB_REQ_DEBUG #options USB_VERBOSE device musb device umass device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) # Ethernet device loop device ether device mii device smscphy device cpsw device bpf # USB ethernet support, requires miibus device miibus device axe # ASIX Electronics USB Ethernet This test was done under FreeBSD 10 built from sources updated today I can not even see any usb bus let alone any devices. Does anyone have ideas? Thanks! -Brett From owner-freebsd-arm@FreeBSD.ORG Sun Dec 23 09:58:24 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D8802D8 for ; Sun, 23 Dec 2012 09:58:24 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id 4306A8FC17 for ; Sun, 23 Dec 2012 09:58:23 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 194250154; Sun, 23 Dec 2012 10:58:16 +0100 From: Hans Petter Selasky To: Ralf Wenk Subject: Re: Fwd: Re: EHCI on armv6 with Write-Back caches Date: Sun, 23 Dec 2012 10:59:52 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <201212201956.47884.hselasky@c2i.net> <201212211520.46822.hselasky@c2i.net> In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201212231059.52064.hselasky@c2i.net> Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 09:58:24 -0000 On Sunday 23 December 2012 00:06:04 Ralf Wenk wrote: > > On Friday 21 December 2012 01:18:57 Oleksandr Tymoshenko wrote: > > > On 12/20/2012 10:56 AM, Hans Petter Selasky wrote: > > > > FYI - please test! > > > > > > > > ---------- Forwarded Message ---------- > > > > > > > > Subject: Re: EHCI on armv6 with Write-Back caches > > > > Date: Thursday 20 December 2012, 19:46:34 > > > > From: Hans Petter Selasky > > > > To: Warner Losh > > > > CC: Andrew Turner , Oleksandr Tymoshenko > > > > , freebsd-usb@freebsd.org, alfred@freebsd.org, > > > > freebsd- wireless@freebsd.org > > > > > > > > Hi, > > > > > > > > I've run some basic tests over here (x86) which passed after some > > > > patch modifications. Please test and verify for your ARM targets: > > > > > > > > http://svnweb.freebsd.org/changeset/base/244500 > > > > http://svnweb.freebsd.org/changeset/base/244503 > > > > > > > > Please also verify that upgt and uwrt and uath still works like > > > > expected. > > > > > > > > --HPS > > > > > > if_smsc fails with following diagnostics: > > > smsc0: error: allocating USB transfers failed > > > > > > The problem is that Bulk-In transfer buffer is 5 pages long but tag's > > > boundary limitation is > > > a page and it's impossible to allocate 5 pages without crossing page > > > boundary > > > > Can you try again using this patch: > > > > http://svnweb.freebsd.org/changeset/base/244535 > > Since revision 244503 I get an error after inserting an USB-stick in about > 50% of the cases. The problem is still there with revision 244535. > My latest test was with revision 244582. > > The kernel messages are: > > root@raspberry-pi:~ # ugen0.4: at usbus0 > umass0: on > usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4101 > umass0:0:0:-1: Attached to scbus0 > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > (probe0:umass-sim0:0:0:0): Retrying command > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > (probe0:umass-sim0:0:0:0): Retrying command > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > (probe0:umass-sim0:0:0:0): Retrying command > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > (probe0:umass-sim0:0:0:0): Retrying command > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted > ugen0.4: at usbus0 (disconnected) > umass0: at uhub1, port 3, addr 4 (disconnected) > > When things go well they are: > > root@raspberry-pi:~ # ugen0.4: at usbus0 > umass0: on > usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4101 > umass0:0:0:-1: Attached to scbus0 > > root@raspberry-pi:~ # da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Removable Direct Access SCSI-2 device > da0: 40.000MB/s transfers > da0: 3817MB (7818240 512 byte sectors: 255H 63S/T 486C) > > But even then there is something wrong now: > > root@raspberry-pi:~ # gpart show da0 > => 34 7818173 da0 GPT (3.7G) > 34 2097152 1 freebsd-ufs (1.0G) > 2097186 5721021 - free - (2.7G) > > root@raspberry-pi:~ # mount /dev/da0p1 /mnt > g_vfs_done():da0p1[READ(offset=65536, length=8192)]error = 6 > mount: /dev/da0p1: Device not configured > > > I am using a RPI-B kernel configuration with serial boot console and added > options MSDOSFS and GEOM_PART_GPT. With older revisions they worked. The > USB-stick is OK. I verified that with my PC. Hi, Can you figure out which revision was causing this regression? BTW: src/sys/dev/usb/usb_transfer.c Change: if (!xfer->flags.ext_buffer) { #if USB_HAVE_BUSDMA struct usb_page_search page_info; struct usb_page_cache *pc; Into: if (!xfer->flags.ext_buffer) { #if 0 struct usb_page_search page_info; struct usb_page_cache *pc; And only this one. Any difference? --HPS From owner-freebsd-arm@FreeBSD.ORG Sun Dec 23 10:38:39 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2501398E for ; Sun, 23 Dec 2012 10:38:39 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id 7AD578FC12 for ; Sun, 23 Dec 2012 10:38:37 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 362020910; Sun, 23 Dec 2012 11:38:29 +0100 From: Hans Petter Selasky To: freebsd-arm@freebsd.org Subject: Re: Fwd: Re: EHCI on armv6 with Write-Back caches Date: Sun, 23 Dec 2012 11:40:05 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <201212201956.47884.hselasky@c2i.net> <201212231059.52064.hselasky@c2i.net> In-Reply-To: <201212231059.52064.hselasky@c2i.net> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201212231140.05327.hselasky@c2i.net> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 10:38:39 -0000 On Sunday 23 December 2012 10:59:52 Hans Petter Selasky wrote: > On Sunday 23 December 2012 00:06:04 Ralf Wenk wrote: > > > On Friday 21 December 2012 01:18:57 Oleksandr Tymoshenko wrote: > > > > On 12/20/2012 10:56 AM, Hans Petter Selasky wrote: > > > > > FYI - please test! > > > > > > > > > > ---------- Forwarded Message ---------- > > > > > > > > > > Subject: Re: EHCI on armv6 with Write-Back caches > > > > > Date: Thursday 20 December 2012, 19:46:34 > > > > > From: Hans Petter Selasky > > > > > To: Warner Losh > > > > > CC: Andrew Turner , Oleksandr Tymoshenko > > > > > , freebsd-usb@freebsd.org, alfred@freebsd.org, > > > > > freebsd- wireless@freebsd.org > > > > > > > > > > Hi, > > > > > > > > > > I've run some basic tests over here (x86) which passed after some > > > > > patch modifications. Please test and verify for your ARM targets: > > > > > > > > > > http://svnweb.freebsd.org/changeset/base/244500 > > > > > http://svnweb.freebsd.org/changeset/base/244503 > > > > > > > > > > Please also verify that upgt and uwrt and uath still works like > > > > > expected. > > > > > > > > > > --HPS > > > > > > > > if_smsc fails with following diagnostics: > > > > smsc0: error: allocating USB transfers failed > > > > > > > > The problem is that Bulk-In transfer buffer is 5 pages long but tag's > > > > boundary limitation is > > > > a page and it's impossible to allocate 5 pages without crossing page > > > > boundary > > > > > > Can you try again using this patch: > > > > > > http://svnweb.freebsd.org/changeset/base/244535 > > > > Since revision 244503 I get an error after inserting an USB-stick in > > about 50% of the cases. The problem is still there with revision 244535. > > My latest test was with revision 244582. > > > > The kernel messages are: > > > > root@raspberry-pi:~ # ugen0.4: at usbus0 > > umass0: on > > usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4101 > > umass0:0:0:-1: Attached to scbus0 > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an > > error (probe0:umass-sim0:0:0:0): Retrying command > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an > > error (probe0:umass-sim0:0:0:0): Retrying command > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an > > error (probe0:umass-sim0:0:0:0): Retrying command > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an > > error (probe0:umass-sim0:0:0:0): Retrying command > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an > > error (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted > > ugen0.4: at usbus0 (disconnected) > > umass0: at uhub1, port 3, addr 4 (disconnected) > > > > When things go well they are: > > > > root@raspberry-pi:~ # ugen0.4: at usbus0 > > umass0: on > > usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4101 > > umass0:0:0:-1: Attached to scbus0 > > > > root@raspberry-pi:~ # da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > > da0: Removable Direct Access SCSI-2 > > device da0: 40.000MB/s transfers > > da0: 3817MB (7818240 512 byte sectors: 255H 63S/T 486C) > > > > But even then there is something wrong now: > > > > root@raspberry-pi:~ # gpart show da0 > > => 34 7818173 da0 GPT (3.7G) > > > > 34 2097152 1 freebsd-ufs (1.0G) > > > > 2097186 5721021 - free - (2.7G) > > > > root@raspberry-pi:~ # mount /dev/da0p1 /mnt > > g_vfs_done():da0p1[READ(offset=65536, length=8192)]error = 6 > > mount: /dev/da0p1: Device not configured > > > > > > I am using a RPI-B kernel configuration with serial boot console and > > added options MSDOSFS and GEOM_PART_GPT. With older revisions they > > worked. The USB-stick is OK. I verified that with my PC. > > Hi, > > Can you figure out which revision was causing this regression? > > BTW: src/sys/dev/usb/usb_transfer.c > > Change: > > if (!xfer->flags.ext_buffer) { > #if USB_HAVE_BUSDMA > struct usb_page_search page_info; > struct usb_page_cache *pc; > > > Into: > > if (!xfer->flags.ext_buffer) { > #if 0 > struct usb_page_search page_info; > struct usb_page_cache *pc; > > And only this one. > > Any difference? > Hi, Can you run usbdump and collect USB traces from the failing and non-failing case. Then remove the timestamps using "sed" and do a diff. --HPS From owner-freebsd-arm@FreeBSD.ORG Sun Dec 23 10:41:59 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D83CBABD for ; Sun, 23 Dec 2012 10:41:59 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id 4F40D8FC15 for ; Sun, 23 Dec 2012 10:41:58 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 362021716; Sun, 23 Dec 2012 11:41:57 +0100 From: Hans Petter Selasky To: freebsd-arm@freebsd.org Subject: Re: Fwd: Re: EHCI on armv6 with Write-Back caches Date: Sun, 23 Dec 2012 11:43:33 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <201212201956.47884.hselasky@c2i.net> <201212231059.52064.hselasky@c2i.net> <201212231140.05327.hselasky@c2i.net> In-Reply-To: <201212231140.05327.hselasky@c2i.net> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201212231143.33127.hselasky@c2i.net> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 10:41:59 -0000 On Sunday 23 December 2012 11:40:05 Hans Petter Selasky wrote: > On Sunday 23 December 2012 10:59:52 Hans Petter Selasky wrote: > > On Sunday 23 December 2012 00:06:04 Ralf Wenk wrote: > > > > On Friday 21 December 2012 01:18:57 Oleksandr Tymoshenko wrote: > > > > > On 12/20/2012 10:56 AM, Hans Petter Selasky wrote: > > > > > > FYI - please test! > > > > > > > > > > > > ---------- Forwarded Message ---------- > > > > > > > > > > > > Subject: Re: EHCI on armv6 with Write-Back caches > > > > > > Date: Thursday 20 December 2012, 19:46:34 > > > > > > From: Hans Petter Selasky > > > > > > To: Warner Losh > > > > > > CC: Andrew Turner , Oleksandr Tymoshenko > > > > > > , freebsd-usb@freebsd.org, alfred@freebsd.org, > > > > > > freebsd- wireless@freebsd.org > > > > > > > > > > > > Hi, > > > > > > > > > > > > I've run some basic tests over here (x86) which passed after some > > > > > > patch modifications. Please test and verify for your ARM targets: > > > > > > > > > > > > http://svnweb.freebsd.org/changeset/base/244500 > > > > > > http://svnweb.freebsd.org/changeset/base/244503 > > > > > > > > > > > > Please also verify that upgt and uwrt and uath still works like > > > > > > expected. > > > > > > > > > > > > --HPS > > > > > > > > > > if_smsc fails with following diagnostics: > > > > > smsc0: error: allocating USB transfers failed > > > > > > > > > > The problem is that Bulk-In transfer buffer is 5 pages long but > > > > > tag's boundary limitation is > > > > > a page and it's impossible to allocate 5 pages without crossing > > > > > page boundary > > > > > > > > Can you try again using this patch: > > > > > > > > http://svnweb.freebsd.org/changeset/base/244535 > > > > > > Since revision 244503 I get an error after inserting an USB-stick in > > > about 50% of the cases. The problem is still there with revision > > > 244535. My latest test was with revision 244582. > > > > > > The kernel messages are: > > > > > > root@raspberry-pi:~ # ugen0.4: at usbus0 > > > umass0: on > > > usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4101 > > > umass0:0:0:-1: Attached to scbus0 > > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > > > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an > > > error (probe0:umass-sim0:0:0:0): Retrying command > > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > > > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an > > > error (probe0:umass-sim0:0:0:0): Retrying command > > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > > > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an > > > error (probe0:umass-sim0:0:0:0): Retrying command > > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > > > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an > > > error (probe0:umass-sim0:0:0:0): Retrying command > > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > > > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an > > > error (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted > > > ugen0.4: at usbus0 (disconnected) > > > umass0: at uhub1, port 3, addr 4 (disconnected) > > > > > > When things go well they are: > > > > > > root@raspberry-pi:~ # ugen0.4: at usbus0 > > > umass0: on > > > usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4101 > > > umass0:0:0:-1: Attached to scbus0 > > > > > > root@raspberry-pi:~ # da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > > > da0: Removable Direct Access SCSI-2 > > > device da0: 40.000MB/s transfers > > > da0: 3817MB (7818240 512 byte sectors: 255H 63S/T 486C) > > > > > > But even then there is something wrong now: > > > > > > root@raspberry-pi:~ # gpart show da0 > > > => 34 7818173 da0 GPT (3.7G) > > > > > > 34 2097152 1 freebsd-ufs (1.0G) > > > > > > 2097186 5721021 - free - (2.7G) > > > > > > root@raspberry-pi:~ # mount /dev/da0p1 /mnt > > > g_vfs_done():da0p1[READ(offset=65536, length=8192)]error = 6 > > > mount: /dev/da0p1: Device not configured > > > > > > > > > I am using a RPI-B kernel configuration with serial boot console and > > > added options MSDOSFS and GEOM_PART_GPT. With older revisions they > > > worked. The USB-stick is OK. I verified that with my PC. > > > > Hi, > > > > Can you figure out which revision was causing this regression? > > > > BTW: src/sys/dev/usb/usb_transfer.c > > > > Change: > > if (!xfer->flags.ext_buffer) { > > > > #if USB_HAVE_BUSDMA > > > > struct usb_page_search page_info; > > struct usb_page_cache *pc; > > > > Into: > > if (!xfer->flags.ext_buffer) { > > > > #if 0 > > > > struct usb_page_search page_info; > > struct usb_page_cache *pc; > > > > And only this one. > > > > Any difference? > > Hi, > > Can you run usbdump and collect USB traces from the failing and non-failing > case. Then remove the timestamps using "sed" and do a diff. > Use: usbdump -i usbusX -vvvv > a.txt --HPS From owner-freebsd-arm@FreeBSD.ORG Sun Dec 23 16:34:59 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A53903AB for ; Sun, 23 Dec 2012 16:34:59 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5E3018FC15 for ; Sun, 23 Dec 2012 16:34:58 +0000 (UTC) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1TmoVu-006dJs-2Y; Sun, 23 Dec 2012 17:34:58 +0100 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 From: Ralf Wenk To: freebsd-arm@freebsd.org Subject: Re: Fwd: Re: EHCI on armv6 with Write-Back caches In-reply-to: <201212231143.33127.hselasky@c2i.net> References: <201212201956.47884.hselasky@c2i.net> <201212231059.52064.hselasky@c2i.net> <201212231140.05327.hselasky@c2i.net> <201212231143.33127.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Dec 2012 17:34:57 +0100 Message-Id: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 16:34:59 -0000 > On Sunday 23 December 2012 11:40:05 Hans Petter Selasky wrote: > > On Sunday 23 December 2012 10:59:52 Hans Petter Selasky wrote: > > > On Sunday 23 December 2012 00:06:04 Ralf Wenk wrote: > > > > > On Friday 21 December 2012 01:18:57 Oleksandr Tymoshenko wrote: > > > > > > On 12/20/2012 10:56 AM, Hans Petter Selasky wrote: > > > > > > > FYI - please test! > > > > > > > > > > > > > > ---------- Forwarded Message ---------- > > > > > > > > > > > > > > Subject: Re: EHCI on armv6 with Write-Back caches > > > > > > > Date: Thursday 20 December 2012, 19:46:34 > > > > > > > From: Hans Petter Selasky > > > > > > > To: Warner Losh > > > > > > > CC: Andrew Turner , Oleksandr Tymoshenko > > > > > > > , freebsd-usb@freebsd.org, alfred@freebsd.org, > > > > > > > freebsd- wireless@freebsd.org > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I've run some basic tests over here (x86) which passed after some > > > > > > > patch modifications. Please test and verify for your ARM targets: > > > > > > > > > > > > > > http://svnweb.freebsd.org/changeset/base/244500 > > > > > > > http://svnweb.freebsd.org/changeset/base/244503 > > > > > > > > > > > > > > Please also verify that upgt and uwrt and uath still works like > > > > > > > expected. > > > > > > > > > > > > > > --HPS > > > > > > > > > > > > if_smsc fails with following diagnostics: > > > > > > smsc0: error: allocating USB transfers failed > > > > > > > > > > > > The problem is that Bulk-In transfer buffer is 5 pages long but > > > > > > tag's boundary limitation is > > > > > > a page and it's impossible to allocate 5 pages without crossing > > > > > > page boundary > > > > > > > > > > Can you try again using this patch: > > > > > > > > > > http://svnweb.freebsd.org/changeset/base/244535 > > > > > > > > Since revision 244503 I get an error after inserting an USB-stick in > > > > about 50% of the cases. The problem is still there with revision > > > > 244535. My latest test was with revision 244582. > > > > > > > > The kernel messages are: > > > > > > > > root@raspberry-pi:~ # ugen0.4: at usbus0 > > > > umass0: on > > > > usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4101 > > > > umass0:0:0:-1: Attached to scbus0 > > > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > > > > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an > > > > error (probe0:umass-sim0:0:0:0): Retrying command > > > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > > > > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an > > > > error (probe0:umass-sim0:0:0:0): Retrying command > > > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > > > > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an > > > > error (probe0:umass-sim0:0:0:0): Retrying command > > > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > > > > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an > > > > error (probe0:umass-sim0:0:0:0): Retrying command > > > > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > > > > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an > > > > error (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted > > > > ugen0.4: at usbus0 (disconnected) > > > > umass0: at uhub1, port 3, addr 4 (disconnected) > > > > > > > > When things go well they are: > > > > > > > > root@raspberry-pi:~ # ugen0.4: at usbus0 > > > > umass0: on > > > > usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4101 > > > > umass0:0:0:-1: Attached to scbus0 > > > > > > > > root@raspberry-pi:~ # da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > > > > da0: Removable Direct Access SCSI-2 > > > > device da0: 40.000MB/s transfers > > > > da0: 3817MB (7818240 512 byte sectors: 255H 63S/T 486C) > > > > > > > > But even then there is something wrong now: > > > > > > > > root@raspberry-pi:~ # gpart show da0 > > > > => 34 7818173 da0 GPT (3.7G) > > > > > > > > 34 2097152 1 freebsd-ufs (1.0G) > > > > > > > > 2097186 5721021 - free - (2.7G) > > > > > > > > root@raspberry-pi:~ # mount /dev/da0p1 /mnt > > > > g_vfs_done():da0p1[READ(offset=65536, length=8192)]error = 6 > > > > mount: /dev/da0p1: Device not configured > > > > > > > > > > > > I am using a RPI-B kernel configuration with serial boot console and > > > > added options MSDOSFS and GEOM_PART_GPT. With older revisions they > > > > worked. The USB-stick is OK. I verified that with my PC. > > > > > > Hi, > > > > > > Can you figure out which revision was causing this regression? Not without doing a search by trying different revisions. Which will take some time. > > > BTW: src/sys/dev/usb/usb_transfer.c > > > > > > Change: > > > if (!xfer->flags.ext_buffer) { > > > > > > #if USB_HAVE_BUSDMA > > > > > > struct usb_page_search page_info; > > > struct usb_page_cache *pc; > > > > > > Into: > > > if (!xfer->flags.ext_buffer) { > > > > > > #if 0 > > > > > > struct usb_page_search page_info; > > > struct usb_page_cache *pc; > > > > > > And only this one. > > > > > > Any difference? unfortunately not. > > Hi, > > > > Can you run usbdump and collect USB traces from the failing and non-failing > > case. Then remove the timestamps using "sed" and do a diff. > > > > Use: > > usbdump -i usbusX -vvvv > a.txt Got both, but the diff is still large after removing the timestamps. Around 14346 lines out of 18837 for the failed and 30886 for the OK case. As I don't know what lines I can ignore to reduce the size of the diff without ruin the information I will send you both dumps off the list. Ralf From owner-freebsd-arm@FreeBSD.ORG Sun Dec 23 21:38:49 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4A0C2165 for ; Sun, 23 Dec 2012 21:38:49 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp4.clear.net.nz (smtp4.clear.net.nz [203.97.37.64]) by mx1.freebsd.org (Postfix) with ESMTP id 09F3A8FC12 for ; Sun, 23 Dec 2012 21:38:48 +0000 (UTC) Received: from mxin1-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp4.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MFI00G9N6SFXN40@smtp4.clear.net.nz> for freebsd-arm@freebsd.org; Mon, 24 Dec 2012 10:38:40 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO localhost) ([202.0.48.19]) by smtpin1.paradise.net.nz with ESMTP; Mon, 24 Dec 2012 10:38:38 +1300 Date: Mon, 24 Dec 2012 10:38:25 +1300 From: Andrew Turner Subject: Raspberry Pi EABI test image To: freebsd-arm@freebsd.org Message-id: <20121224103825.086cd584@fubar.geek.nz> MIME-version: 1.0 X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; i386-portbld-freebsd8.1) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Pirate: Arrrr X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 21:38:49 -0000 I have made a test image built from the EABI branch for the Raspberry Pi. It is available from: http://people.freebsd.org/~andrew/rpi/rpi-eabi-r244581.img.xz I would appreciate it if people with a Raspberry Pi could test this as I am likely to start merging EABI support into head early next year. As far as I can tell everything should work with the exception of gdb which is known to be broken. To load the image you need to uncompress the file and run a command similar to: dd if=rpi-eabi-r244581.img of=/dev/mmcsd0 Changing the of= device as required for your system. The SD card should boot into FreeBSD with the console on the HDMI port and a login prompt on the UART. Andrew From owner-freebsd-arm@FreeBSD.ORG Sun Dec 23 21:58:41 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 237DEB6C for ; Sun, 23 Dec 2012 21:58:41 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp3.clear.net.nz (smtp3.clear.net.nz [203.97.33.64]) by mx1.freebsd.org (Postfix) with ESMTP id D74E08FC12 for ; Sun, 23 Dec 2012 21:58:40 +0000 (UTC) Received: from mxin3-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MFI00D747PK0Q30@smtp3.clear.net.nz> for freebsd-arm@freebsd.org; Mon, 24 Dec 2012 10:58:32 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO localhost) ([202.0.48.19]) by smtpin32.paradise.net.nz with ESMTP; Mon, 24 Dec 2012 10:58:32 +1300 Date: Mon, 24 Dec 2012 10:58:19 +1300 From: Andrew Turner Subject: Re: svn commit: r244640 - in head/contrib/llvm/tools/clang/lib: Basic Driver In-reply-to: <201212232141.qBNLfeNM072760@svn.freebsd.org> To: freebsd-arm@freebsd.org Message-id: <20121224105819.61698ad3@fubar.geek.nz> MIME-version: 1.0 X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; i386-portbld-freebsd8.1) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Pirate: Arrrr References: <201212232141.qBNLfeNM072760@svn.freebsd.org> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 21:58:41 -0000 On Sun, 23 Dec 2012 21:41:40 +0000 (UTC) Andrew Turner wrote: > Author: andrew > Date: Sun Dec 23 21:41:39 2012 > New Revision: 244640 > URL: http://svnweb.freebsd.org/changeset/base/244640 > > Log: > Pull in r170096 from upstream clang trunk: > > Initial support for FreeBSD on ARM. > With this commit we have experimental clang support for ARM. To test you can add "-DWITH_CLANG -DWITH_CLANG_IS_CC" to you make commands when building the toolchain, e.g. with buildworld, toolchain or kernel-toolchain. I've tested userland and the kernel on a PandaBoard and haven't noticed any issues. All going well my plan is to set WITH_CLANG as the default early next year and WITH_CLANG_IS_CC some time later. Andrew From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 00:05:55 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 780D3D53 for ; Mon, 24 Dec 2012 00:05:55 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id 10A728FC14 for ; Mon, 24 Dec 2012 00:05:54 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id qBO05m4r062736 for ; Sun, 23 Dec 2012 19:05:53 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <50D79C5C.1000704@m5p.com> Date: Sun, 23 Dec 2012 19:05:48 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20121125 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Raspberry Pi EABI test image References: <20121224103825.086cd584@fubar.geek.nz> In-Reply-To: <20121224103825.086cd584@fubar.geek.nz> 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]); Sun, 23 Dec 2012 19:05:54 -0500 (EST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 00:05:55 -0000 On 12/23/12 16:38, Andrew Turner wrote: > I have made a test image built from the EABI branch for the Raspberry > Pi. It is available from: > http://people.freebsd.org/~andrew/rpi/rpi-eabi-r244581.img.xz > > I would appreciate it if people with a Raspberry Pi could test this as > I am likely to start merging EABI support into head early next year. As > far as I can tell everything should work with the exception of gdb > which is known to be broken. > > To load the image you need to uncompress the file and run a command > similar to: > dd if=rpi-eabi-r244581.img of=/dev/mmcsd0 > > Changing the of= device as required for your system. The SD card should > boot into FreeBSD with the console on the HDMI port and a login prompt > on the UART. > > Andrew > _______________________________________________ > 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" > Your image works for me. I don't have an appropriate serial cable, so I connected a USB keyboard. There are some rough edges, but they aren't new with this image: Every so often, a key release event from the USB keyboard is dropped and I get a sequence of repeated characters until I type something else. I think an occasional key press is dropped as well, but I'm such a bad typist that I'm not sure. Although rc.conf says ue0_config="DHCP"', dhclient doesn't run. I can run it manually, and then everything network-related works. I NFS-mounted a /usr/ports tree and installed portmaster. When I tried "portmaster -BDg sysutils/LPRng", it died trying to run something called autom4te while working on libtool. What would we need to do to get a driver for the pulse-width modulation audio port? The lack of a visible cursor on the screen is a major annoyance. Nevertheless, thanks for providing the image! -- George Mitchell From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 00:22:57 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2261BB for ; Mon, 24 Dec 2012 00:22:57 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by mx1.freebsd.org (Postfix) with ESMTP id 752278FC12 for ; Mon, 24 Dec 2012 00:22:56 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id bj3so3816788pad.28 for ; Sun, 23 Dec 2012 16:22:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:x-x-sender:to:cc:subject:in-reply-to :message-id:references:user-agent:mime-version:content-type :x-gm-message-state; bh=MBCwf05DwGqYCM45Cih6/F2x9xScFQ0qDCgMUHgMC8M=; b=m1hzx3qb8cFNy6LO0eGKfjsB9TvlabMtX7Xv+Kq/VgfaynbveP0Ohx67GCQPeLZxma TsT9w6aB29tQyXukzBMemzHMnf0fEMgxv4zTEjTFuewUn6yeBZMbcXqioD4Q/Eb05fW9 iMbIf1Ka7gBl1JMfbp+14E+z8jo5w/XSuVmzVvbv3PVeksbxhB9XlCYcEp5DI1oNmkoj goLkJnVaTiay3hwxP19qQoSBg8w1FE9RQX/0GtWSQjjwtbdkiTLZUzSuT6AFefP3VsNO WLdPIlAIUGx+slTlbBUQ/ewu6TO3+hb3IAODjz6k+917hW72kMpMaDErtYZLzzya6Qm6 JVbg== X-Received: by 10.66.83.136 with SMTP id q8mr57987918pay.83.1356308576649; Sun, 23 Dec 2012 16:22:56 -0800 (PST) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by mx.google.com with ESMTPS id pj1sm11235205pbb.71.2012.12.23.16.22.53 (version=SSLv3 cipher=OTHER); Sun, 23 Dec 2012 16:22:55 -0800 (PST) Date: Sun, 23 Dec 2012 14:22:51 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Ian Lepore Subject: Re: Call for testing and review, busdma changes In-Reply-To: <1355085250.87661.345.camel@revolution.hippie.lan> Message-ID: References: <1355077061.87661.320.camel@revolution.hippie.lan> <1355085250.87661.345.camel@revolution.hippie.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQmUAttBSFCIQe198275wWM5cDfNpJuaZxOXHUm7dxPmHqyBFXEQ2DeyjbFjJG2spkYcZRix X-Mailman-Approved-At: Mon, 24 Dec 2012 00:38:28 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, John Baldwin , mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, kib@freebsd.org, sparc64@freebsd.org, arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 00:22:57 -0000 On Sun, 9 Dec 2012, Ian Lepore wrote: > On Sun, 2012-12-09 at 08:48 -1000, Jeff Roberson wrote: >> >> On Sun, 9 Dec 2012, Ian Lepore wrote: >> >>> On Sat, 2012-12-08 at 08:51 -1000, Jeff Roberson wrote: >>>> Hello, >>>> >>>> http://people.freebsd.org/~jeff/physbio.diff >>>> >>>> I have a relative large patch that reforms the busdma API so that new >>>> types may be added without modifying every architecture's >>>> busdma_machdep.c. It does this by unifying the bus_dmamap_load_buffer() >>>> routines so that they may be called from MI code. The MD busdma is then >>>> given a chance to do any final processing in the complete() callback. >>>> This patch also contains cam changes to unify the bus_dmamap_load* >>>> handling in cam drivers. >>>> >>>> The arm and mips implementations saw the largest changes since they have >>>> to track virtual addresses for sync(). Previously this was done in a type >>>> specific way. Now it is done in a generic way by recording the list of >>>> virtuals in the map. >>>> >>>> I have verified that this patch passes make universe which includes >>>> several kernel builds from each architecture. I suspect that if I broke >>>> anything your machine simply won't boot or will throw I/O errors. There >>>> is little subtlety, it is mostly refactoring. >>>> > > First an FYI, my replies to this thread aren't making it to the mailing > lists, except when quoted by someone replying to them. They're being > held for moderator approval because they're going to too many addresses. > >>> >>> Testing on armv4/v5 platforms, the patches applied and compiled cleanly, >>> but fault-abort with a NULL deref on what appears to be the first call >>> to bus_dmamap_load(). I'll dig deeper into debugging that after >>> browsing the new code so I can figure out where to start debugging. >> >> Can you give me the file and line of the fault? >> > > Better than that, I can give you patches (attached). There were two > little glitches... the allocated slist wasn't getting attached to the > map, and when building the slist in _bus_dmamap_load_buffer() the slist > needs to participate in the coalescing logic near the end of the loop. I understand the first problem. The second, I'm not sure about. When we're going through bounce pages we use virtual to virtual. Why do you need to flush the cache lines for the source addresses? The device will only do io to the bounce pages so they are the only that need other synchronization. > > I'm not positive the attached quick-fix is perfect, but it allows one of > my arm units here to boot and run and pass some basic IO smoke tests. > I'll be trying it on other arm platforms later today. > >>> >>> Just from an initial quick browsing of the new code for armv4, I notice >>> these things... >>> >>> The new routine __bus_dmamap_mayblock() does (*flags) |= BUS_DMA_WAITOK; >>> which is a no-op because BUS_DMA_WAITOK is zero. I'm not sure what the >>> intent was, but I think any modification of the WAIT-related flags would >>> be conceptually wrong because it overrides the caller's instructions on >>> whether or not to do a deferred load when resources aren't available. >> >> The intent of the original load function seems to be that it is always >> blocking. Most architectures force the flag. The mbuf and uio load >> routines don't support blocking at all because the callback lacks the >> information needed to restart the operation. >> > > The manpage states that bus_dmamap_load() never blocks for any reason. > The mbuf and uio flavors say they are variations of bus_dmapmap_load(); > I take the implication of that to mean that they also are defined as > never blocking. > > The docs then say that WAITOK vs. NOWAIT control the scheduling of a > deferred load, and that NOWAIT is forced in the mbuf and uio cases. > Your refactored code already handles that by adding NOWAIT to the > caller-specified flags for mbufs and uio. > > So the code will do the right thing now (with your patches), but only > because (*flags) |= BUS_DMA_WAITOK is a no-op. This code is problematic. We can only support WAITOK operations for bus_dmamap_load() because the callbacks from the swi when bounce pages are available can only remember one pointer. To fix this for real we'd have to remember the original type and call the appropriate load function again. This could be solved by having a { type, pointer, length } structure that is passed between the front and back-end. This would solve your mbuf problem as well. I think I will do this next. By the way I have an mbuf branch that pushes data and mbuf structure into separate cachelines. It's not only faster on arm and the like but on x86 as well. So someone should pursue this and you'd have way fewer partial line flushes. > >>> >>> The way you've refactored the mbuf-related load routines, the MD code is >>> no longer able to tell that it's an mbuf operation. This comes back to >>> what I said a few days ago... when you look at the current code on >>> various platforms you see a lot of false similarities. The code isn't >>> nearly identical because it really all needs to be the same, it's >>> because it was all copied from the same source, and it doesn't currently >>> work correctly on arm and mips. With your changes, the ability to >>> correct the implementation on those platforms is now gone. Perhaps this >>> can be fixed easily by defining some new flags that the MI routines can >>> OR-in to give the MD routines more info on what's happening. (Correcting >>> the mbuf sync handling on arm and mips requires that we know at sync >>> time that the buffers involved are mbufs, which means we need to know at >>> map-load time so we can set a flag or a type code or something in the >>> map that we can examine at sync time.) >> >> Why do you need to know it is an mbuf if you have a record of the virtual >> addresses? The only type specific information was used to find the >> addresses. See how arm's busdma_machdep-v6 ws implemented. >> > > Because there is a special rule for mbufs on VIVT-cache architectures: > the address of the data buffer is not aligned to a cacheline boundary, > but the sync code is allowed to treat the buffer as if it is aligned and > thus avoid invoking the partial cacheline flush algorithm. That > algorithm was shown a few months ago to be fatally flawed, and we're on > a path (albeit in super-slow-motion) to eliminate it. You can skip the sync because you know the information in the mbuf header is not necessary? > > I have patches to fix the mbuf partial sync and other things related to > partial sync problems, and my next step will be to try to rework them to > fit in with what you've done. Based on what I've seen so far in your > refactoring, I think just passing a flag to say it's an mbuf, from the > MI to the MD mapping routine, will provide enough info. I think I described a better approach above that will solve mutliple problems. Let me know what you think. Jeff > >>> >>>> The next step is to allow for dma loading of physical addresses. This >>>> will permit unmapped I/O. Which is a significant performance optimization >>>> targeted for 10.0. >>> >>> This sounds scary for arm and mips, or more specifically for VIVT cache >>> platforms that can only do a sync based on virtual addresses. Can you >>> talk some more about the plans for this? >> >> It will be for addresses which were never mapped into kva. To support >> unmaapped io. There will only be a need for bounce pages, no syncing. >> > > Can the pages be mapped into any non-kernel vmspaces? If they aren't > mapped into any vmspace at all, then I think there'll be no implications > for VIVT cache architectures. If they appear in any pmap at all then > there may be problems. > > -- Ian > > From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 00:55:34 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 045F281B for ; Mon, 24 Dec 2012 00:55:34 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp5.clear.net.nz (smtp5.clear.net.nz [203.97.33.68]) by mx1.freebsd.org (Postfix) with ESMTP id B444B8FC15 for ; Mon, 24 Dec 2012 00:55:32 +0000 (UTC) Received: from mxin1-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp5.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MFI006B7FWDHO20@smtp5.clear.net.nz> for freebsd-arm@freebsd.org; Mon, 24 Dec 2012 13:55:26 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO localhost) ([202.0.48.19]) by smtpin1.paradise.net.nz with ESMTP; Mon, 24 Dec 2012 13:55:25 +1300 Date: Mon, 24 Dec 2012 13:55:12 +1300 From: Andrew Turner Subject: Re: Raspberry Pi EABI test image In-reply-to: <50D79C5C.1000704@m5p.com> To: George Mitchell Message-id: <20121224135512.30c84b7c@fubar.geek.nz> MIME-version: 1.0 X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; i386-portbld-freebsd8.1) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Pirate: Arrrr References: <20121224103825.086cd584@fubar.geek.nz> <50D79C5C.1000704@m5p.com> Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 00:55:34 -0000 On Sun, 23 Dec 2012 19:05:48 -0500 George Mitchell wrote: > On 12/23/12 16:38, Andrew Turner wrote: > > I have made a test image built from the EABI branch for the > > Raspberry Pi. It is available from: > > http://people.freebsd.org/~andrew/rpi/rpi-eabi-r244581.img.xz > > > > I would appreciate it if people with a Raspberry Pi could test this > > as I am likely to start merging EABI support into head early next > > year. As far as I can tell everything should work with the > > exception of gdb which is known to be broken. > > > > To load the image you need to uncompress the file and run a command > > similar to: > > dd if=rpi-eabi-r244581.img of=/dev/mmcsd0 > > > > Changing the of= device as required for your system. The SD card > > should boot into FreeBSD with the console on the HDMI port and a > > login prompt on the UART. > > > > Andrew > > _______________________________________________ > > 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" > > > > Your image works for me. I don't have an appropriate serial cable, so > I connected a USB keyboard. > > There are some rough edges, but they aren't new with this image: > > Every so often, a key release event from the USB keyboard is dropped > and I get a sequence of repeated characters until I type something > else. I think an occasional key press is dropped as well, but I'm > such a bad typist that I'm not sure. This is a know issue with the usb driver. I don't know if there is a fix or workaround for it. > > Although rc.conf says ue0_config="DHCP"', dhclient doesn't run. I can > run it manually, and then everything network-related works. I've seen this before with other RPi images. > I NFS-mounted a /usr/ports tree and installed portmaster. When I > tried "portmaster -BDg sysutils/LPRng", it died trying to run > something called autom4te while working on libtool. This may or may not be an EABI issue, are you able to send through a log of the build? I can also see if I can reproduce it here. > What would we need to do to get a driver for the pulse-width > modulation audio port? > > The lack of a visible cursor on the screen is a major annoyance. It sounds like this is a problem with the RPi driver. Andrew From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 01:04:36 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E07459A7 for ; Mon, 24 Dec 2012 01:04:36 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 693348FC0C for ; Mon, 24 Dec 2012 01:04:36 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Tmw81-0005HK-0q; Sun, 23 Dec 2012 16:42:52 -0800 Message-ID: <50D7A504.10203@bluezbox.com> Date: Sun, 23 Dec 2012 16:42:44 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: wynkoop@wynn.com Subject: Re: beaglebone usb problems References: <201212230507.qBN572su095100@mail.wynn.com> In-Reply-To: <201212230507.qBN572su095100@mail.wynn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 12/22/2012 9:07 PM, wynkoop@wynn.com wrote: > Greeting- > > Today I grabbed the lattest kernel and usreland sources with csup onto my > beaglebone with the idea of building a kernel that would support usb. > > I used the default BEAGLEBOARD config file that I found in the ARM branch of > /usr/src/sys. After a crash on building because of lack of memory I got the > new kernel built and installed by adding some swap space. Not the best > thing to do to an SD card, but a needed evil. > > I completed the build of the kernel and installed it. Upon reboot the system > is still not seeing the USB BUS. > > I have verified that it sees the USB bus under the provided gnu/linux > distribution. > > [ 0.553985] usbcore: registered new interface driver cdc_acm > [ 0.554077] usbcore: registered new interface driver usblp > [ 0.554138] usbcore: registered new interface driver cdc_wdm > [ 0.554199] usbcore: registered new interface driver uas > [ 0.554321] usbcore: registered new interface driver usb-storage > [ 0.554412] usbcore: registered new interface driver libusual > [ 0.561981] usbcore: registered new interface driver usbhid > [ 0.561981] usbhid: USB HID core driver > [ 0.562927] usbcore: registered new interface driver snd-usb-audio > [ 0.673187] usb 1-1: new high-speed USB device number 2 using musb-hdrc > [ 0.813659] usb 1-1: New USB device found, idVendor=0781, idProduct=5573 > [ 0.813690] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > [ 0.813690] usb 1-1: Product: Staples > [ 0.813690] usb 1-1: Manufacturer: > [ 0.813720] usb 1-1: SerialNumber: 4C532000070802101254 > [ 0.815277] scsi0 : usb-storage 1-1:1.0 > [ 2.234497] musb-hdrc musb-hdrc.0: MUSB HDRC host driver > [ 2.234527] musb-hdrc musb-hdrc.0: new USB bus registered, assigned bus number 2 > [ 2.234649] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 > [ 2.234649] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > [ 2.234680] usb usb2: Product: MUSB HDRC host driver > [ 2.234680] usb usb2: Manufacturer: [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 01:04:36 -0000 On 12/22/2012 9:07 PM, wynkoop@wynn.com wrote: > Greeting- > > Today I grabbed the lattest kernel and usreland sources with csup onto my > beaglebone with the idea of building a kernel that would support usb. > > I used the default BEAGLEBOARD config file that I found in the ARM branch of > /usr/src/sys. After a crash on building because of lack of memory I got the > new kernel built and installed by adding some swap space. Not the best > thing to do to an SD card, but a needed evil. > > I completed the build of the kernel and installed it. Upon reboot the system > is still not seeing the USB BUS. > > I have verified that it sees the USB bus under the provided gnu/linux > distribution. > > [ 0.553985] usbcore: registered new interface driver cdc_acm > [ 0.554077] usbcore: registered new interface driver usblp > [ 0.554138] usbcore: registered new interface driver cdc_wdm > [ 0.554199] usbcore: registered new interface driver uas > [ 0.554321] usbcore: registered new interface driver usb-storage > [ 0.554412] usbcore: registered new interface driver libusual > [ 0.561981] usbcore: registered new interface driver usbhid > [ 0.561981] usbhid: USB HID core driver > [ 0.562927] usbcore: registered new interface driver snd-usb-audio > [ 0.673187] usb 1-1: new high-speed USB device number 2 using musb-hdrc > [ 0.813659] usb 1-1: New USB device found, idVendor=0781, idProduct=5573 > [ 0.813690] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > [ 0.813690] usb 1-1: Product: Staples > [ 0.813690] usb 1-1: Manufacturer: > [ 0.813720] usb 1-1: SerialNumber: 4C532000070802101254 > [ 0.815277] scsi0 : usb-storage 1-1:1.0 > [ 2.234497] musb-hdrc musb-hdrc.0: MUSB HDRC host driver > [ 2.234527] musb-hdrc musb-hdrc.0: new USB bus registered, assigned bus number 2 > [ 2.234649] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 > [ 2.234649] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > [ 2.234680] usb usb2: Product: MUSB HDRC host driver > [ 2.234680] usb usb2: Manufacturer: Linux 3.2.28 musb-hcd > [ 2.234680] usb usb2: SerialNumber: musb-hdrc.0 > root@beaglebone:~# > > Plugging in a supported USB wifi device under Linux produced the following: > > [ 246.557800] usb 1-1: USB disconnect, device number 2 > [ 253.454040] usb 1-1: new high-speed USB device number 3 using musb-hdrc > [ 253.747406] usb 1-1: New USB device found, idVendor=2001, idProduct=3c00 > [ 253.747436] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > [ 253.747467] usb 1-1: Product: 802.11g WLAN Adapter > [ 253.747467] usb 1-1: Manufacturer: ANI > [ 253.828186] cfg80211: Calling CRDA to update world regulatory domain > [ 254.014068] usb 1-1: reset high-speed USB device number 3 using musb-hdrc > [ 254.325317] ieee80211 phy0: Selected rate control algorithm 'pid' > [ 254.326263] Registered led device: rt2500usb-phy0::radio > [ 254.326385] Registered led device: rt2500usb-phy0::quality > [ 254.342895] usbcore: registered new interface driver rt2500usb > [ 254.505523] ADDRCONF(NETDEV_UP): wlan0: link is not ready > root@beaglebone:~# ifconfig wlan0 > > > wlan0 Link encap:Ethernet HWaddr 00:13:46:97:95:ED > UP BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > > > So I think I can say the hardware is working. > > Under FreeBSD 10 we see the following: > > root@beaglebone:~ # dmesg | grep -i usb > am335x_pmic0: TPS65217B ver 1.1 powered by USB and AC > root@beaglebone:~ # > > > In other words we do not even see the bus let alone any wifi or storage device > inserted into the bus. > > My kernel config has the needed stuff I believe. Here is the snippit. > > # USB support > device usb > options USB_DEBUG > #options USB_REQ_DEBUG > #options USB_VERBOSE > device musb > device umass > device scbus # SCSI bus (required for SCSI) > device da # Direct Access (disks) > > # Ethernet > device loop > device ether > device mii > device smscphy > device cpsw > device bpf > > # USB ethernet support, requires miibus > device miibus > device axe # ASIX Electronics USB Ethernet > > > > > This test was done under FreeBSD 10 built from sources updated today I can > not even see any usb bus let alone any devices. > > Does anyone have ideas? > I looked into it and it seems we do not have proper support for USB on BeagleBone. Although the general logic for MUSB is in the tree (dev/usb/controller/musb_otg.c) there is no actual driver part for AM335x, like musb_otg_atmelarm.c for Atmel devices. From what I saw in spec it shouldn't be really hard to get hardware-specific glue done for BeagleBone. Since there are two musb ports on AM335x device and some additional hardware involved the actual driver is slightly more complicated then just adding FDT entry and fdt glue, but not exceedingly hard either I will not have spare cycles for a week or two so if somebody with real hardware could get it done - that would be great. AM335x TRM: http://www.ti.com/lit/ug/spruh73g/spruh73g.pdf See chapter 16. From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 01:36:31 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF040C96 for ; Mon, 24 Dec 2012 01:36:31 +0000 (UTC) (envelope-from freebsd-arm@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 516A78FC15 for ; Mon, 24 Dec 2012 01:36:30 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id qBO1aPDc008850; Sun, 23 Dec 2012 20:36:25 -0500 (EST) (envelope-from freebsd-arm@wynn.com) Date: Sun, 23 Dec 2012 20:36:25 -0500 From: Brett Wynkoop To: Oleksandr Tymoshenko Subject: Re: beaglebone usb problems Message-ID: <20121223203625.3e6b9e64@ivory.wynn.com> In-Reply-To: <50D7A504.10203@bluezbox.com> References: <201212230507.qBN572su095100@mail.wynn.com> <50D7A504.10203@bluezbox.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 01:36:31 -0000 On Sun, 23 Dec 2012 16:42:44 -0800 Oleksandr Tymoshenko wrote: > I will not have spare cycles for a week or two so if somebody with > real hardware could > get it done - that would be great. > > AM335x TRM: http://www.ti.com/lit/ug/spruh73g/spruh73g.pdf > See chapter 16. > If anyone wants access to my beaglebone to work on this I can arrange console access to the box. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6924 718-717-5435 From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 01:41:02 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF7F9CE2 for ; Mon, 24 Dec 2012 01:41:02 +0000 (UTC) (envelope-from freebsd-arm@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6228C8FC0A for ; Mon, 24 Dec 2012 01:41:02 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id qBO1f1Bk008898; Sun, 23 Dec 2012 20:41:01 -0500 (EST) (envelope-from freebsd-arm@wynn.com) Date: Sun, 23 Dec 2012 20:41:01 -0500 From: Brett Wynkoop To: George Mitchell Subject: Re: Raspberry Pi EABI test image Message-ID: <20121223204101.2345559d@ivory.wynn.com> In-Reply-To: <50D79C5C.1000704@m5p.com> References: <20121224103825.086cd584@fubar.geek.nz> <50D79C5C.1000704@m5p.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 01:41:02 -0000 On Sun, 23 Dec 2012 19:05:48 -0500 George Mitchell wrote: > > Although rc.conf says ue0_config="DHCP"', dhclient doesn't run. I can > run it manually, and then everything network-related works. I bet this is not just a Pi issue as I have the same issue on the Beaglebone and have put a call to dhclient in /etc/rc.local as a workaround. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6924 718-717-5435 From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 01:52:07 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E65A2D74 for ; Mon, 24 Dec 2012 01:52:07 +0000 (UTC) (envelope-from johny.mattsson@gmail.com) Received: from mail-ia0-f176.google.com (mail-ia0-f176.google.com [209.85.210.176]) by mx1.freebsd.org (Postfix) with ESMTP id A37558FC12 for ; Mon, 24 Dec 2012 01:52:07 +0000 (UTC) Received: by mail-ia0-f176.google.com with SMTP id y26so5522078iab.7 for ; Sun, 23 Dec 2012 17:52:01 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4tgPJL4In4a7/TnI2m2UwqPyoJfHmBfNr/laX2N4Gb0=; b=oHaqm+HuEs90WpInCGOz4B8FauZGSddcoKhjplu5vzWoXWTQLqV8yF07INRPKUYZ0c 9lCbEcoSoPKFjSAXWg2Oo6i6gve/rHu+Vtjba5UG3O/4P+llHVK1B0ymZlJXXb+CsrXJ mBPuxdHEiAqiv0j+OKTpg4GFa/SUqJmH/XIB/TgP9kHCXiV95sALgZnkZrQvrnafrDpI fCRiMrWxFj2V8U7gBVl0SI1B6p1ohzXDvdAI5db/gdVu18y0quSNCGXX5WrSAtQOypSb HJSLRvoxk2aqSthpLBZ9ZDQc+EcliJSi+EVoK9eANZPYlFXBNWs/0fluokXuxzbCN9zO UawQ== MIME-Version: 1.0 Received: by 10.50.152.240 with SMTP id vb16mr13545467igb.90.1356313921116; Sun, 23 Dec 2012 17:52:01 -0800 (PST) Sender: johny.mattsson@gmail.com Received: by 10.42.135.138 with HTTP; Sun, 23 Dec 2012 17:52:00 -0800 (PST) In-Reply-To: <50D79C5C.1000704@m5p.com> References: <20121224103825.086cd584@fubar.geek.nz> <50D79C5C.1000704@m5p.com> Date: Mon, 24 Dec 2012 12:52:00 +1100 X-Google-Sender-Auth: fn-yUmOLHZXs8qD9VUqcoE2ra0U Message-ID: Subject: Re: Raspberry Pi EABI test image From: Johny Mattsson To: George Mitchell Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 01:52:08 -0000 On 24 December 2012 11:05, George Mitchell wrote: > Every so often, a key release event from the USB keyboard is dropped > and I get a sequence of repeated characters until I type something > else. I've seen this on Raspbian Linux as well, and it seemed to be related to the power (or lack there of) on the USB ports. I haven't encountered it since I did the "Pi-pass" mod to bypass the F1/F2 polyfuses on the USB ports (it's a Gen1 board). The keyboard in question was a run-o'-the-mill Microsoft USB keyboard. I'm not saying there aren't issues with the USB driver, just pointing out that FreeBSD isn't the only sufferer on this particular point. Regards, /Johny (who hasn't yet attempted FreeBSD on the Pi) From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 01:59:37 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 657A1DDE for ; Mon, 24 Dec 2012 01:59:37 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 42A308FC0A for ; Mon, 24 Dec 2012 01:59:31 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBO1xUFr071666 for ; Sun, 23 Dec 2012 18:59:31 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBO1xSqP070280; Sun, 23 Dec 2012 18:59:28 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Raspberry Pi EABI test image From: Ian Lepore To: Brett Wynkoop In-Reply-To: <20121223204101.2345559d@ivory.wynn.com> References: <20121224103825.086cd584@fubar.geek.nz> <50D79C5C.1000704@m5p.com> <20121223204101.2345559d@ivory.wynn.com> Content-Type: text/plain; charset="us-ascii" Date: Sun, 23 Dec 2012 18:59:28 -0700 Message-ID: <1356314368.1129.77.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 01:59:37 -0000 On Sun, 2012-12-23 at 20:41 -0500, Brett Wynkoop wrote: > On Sun, 23 Dec 2012 19:05:48 -0500 > George Mitchell wrote: > > > > > Although rc.conf says ue0_config="DHCP"', dhclient doesn't run. I can > > run it manually, and then everything network-related works. > > I bet this is not just a Pi issue as I have the same issue on the > Beaglebone and have put a call to dhclient in /etc/rc.local as a > workaround. > > -Brett > > Try ue0_config="SYNCDHCP" so that it gets started directly from the rc scripts instead of relying on devd. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 02:01:22 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B0CDE2C for ; Mon, 24 Dec 2012 02:01:22 +0000 (UTC) (envelope-from shurd@sasktel.net) Received: from mail129c7.megamailservers.com (mail129c7.megamailservers.com [69.49.98.229]) by mx1.freebsd.org (Postfix) with ESMTP id AA2878FC0C for ; Mon, 24 Dec 2012 02:01:21 +0000 (UTC) X-Authenticated-User: hurds.sasktel.net Received: from stephen.hurd.local (ip70-187-145-241.oc.oc.cox.net [70.187.145.241]) (authenticated bits=0) by mail129c7.megamailservers.com (8.13.6/8.13.1) with ESMTP id qBO21BTx023963; Sun, 23 Dec 2012 21:01:13 -0500 Message-ID: <50D7B767.8050800@sasktel.net> Date: Sun, 23 Dec 2012 18:01:11 -0800 From: Stephen Hurd User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121022 Firefox/16.0 SeaMonkey/2.13.1 MIME-Version: 1.0 To: Brett Wynkoop Subject: Re: Raspberry Pi EABI test image References: <20121224103825.086cd584@fubar.geek.nz> <50D79C5C.1000704@m5p.com> <20121223204101.2345559d@ivory.wynn.com> In-Reply-To: <20121223204101.2345559d@ivory.wynn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CSC: 0 X-CHA: v=1.1 cv=irLj17ZF5ABOTBuyAu2t31N+Nq5xiP0nh7CWcFrUZ/0= c=1 sm=1 a=sd1-78TbSwQA:10 a=qpO3MUKs40sA:10 a=YxfxW3ofkq8A:10 a=8nJEP1OIZ-IA:10 a=qWhSLQ/2FgUpSQgLv9E1tw==:17 a=m5QXn6DzAAAA:8 a=u4Swx86d_cZ4ozaQfIIA:9 a=wPNLvfGTeEIA:10 a=QgFUTDTavf4A:10 a=qWhSLQ/2FgUpSQgLv9E1tw==:117 X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A020204.50D7B76A.0002, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 02:01:22 -0000 Brett Wynkoop wrote: > On Sun, 23 Dec 2012 19:05:48 -0500 > George Mitchell wrote: > >> Although rc.conf says ue0_config="DHCP"', dhclient doesn't run. I can >> run it manually, and then everything network-related works. > I bet this is not just a Pi issue as I have the same issue on the > Beaglebone and have put a call to dhclient in /etc/rc.local as a > workaround. On my system, using "SYNCDHCP" works well. From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 02:01:46 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26200E5A for ; Mon, 24 Dec 2012 02:01:46 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by mx1.freebsd.org (Postfix) with ESMTP id E638E8FC12 for ; Mon, 24 Dec 2012 02:01:45 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id mc8so3714242pbc.32 for ; Sun, 23 Dec 2012 18:01:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=2bJZecuWJm5EG9pf86D0OU1/046TDfnPd8X0vMSJDwk=; b=hOYIYe+fame6tQCjqTjZir/IJYqamkWP/BFlGyeLGvFrChpR+5nNz+MEsbTMEjktE5 ed8kqXturtUtV0c6wUUB2mBkuacorZtgI+85ru0p4RYQa1hx2ez0xHYVHMwdp6sHkB4L bLhMOXTVFqyNwD8LRknyWsZFh1cg1K8t40BuwrjnlYEEcOlzI1OgMYm6BD1rkKr82vgs lDjepRlwejljTu2WCzgu6GSR5IFI+5ppj+kg4VMxeH1zytB+9NSopc0+pyAV+EoCpw7G ESFIJDfOl4Bj2L4q+Ygwnc2/Y87u+QrEl2hFjN/2jsUKQdeqJYoxL551Xpr5XO0pcis1 Dl6g== MIME-Version: 1.0 Received: by 10.68.129.233 with SMTP id nz9mr61632439pbb.139.1356314499219; Sun, 23 Dec 2012 18:01:39 -0800 (PST) Received: by 10.66.235.101 with HTTP; Sun, 23 Dec 2012 18:01:39 -0800 (PST) In-Reply-To: <6FC3E540-DEBD-4763-BB46-13F3422508E9@kientzle.com> References: <6FC3E540-DEBD-4763-BB46-13F3422508E9@kientzle.com> Date: Sun, 23 Dec 2012 18:01:39 -0800 Message-ID: Subject: Re: FreeBSD10-CURRENT r244480 hang while compiling lighttpd or any port From: Alie Tan To: Tim Kientzle X-Gm-Message-State: ALoCoQnqakHlaLnHUMjxGE9kdPoy/vz9nu97i0zoKE8z9I7PTJbNdqZt4jcnQII7Oovz7eB83Aj6 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 02:01:46 -0000 On Sat, Dec 22, 2012 at 12:23 AM, Tim Kientzle wrote: > > On Dec 21, 2012, at 12:00 AM, Alie Tan wrote: > > > > Anyone having hang issue while compiling any big port or portsnap fetch > > extract? > > On what system? > > Tim > > > Oops sorry. On Raspberry Pi 256 and 512 Regards, Alie T From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 02:04:05 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5B3F8EA9 for ; Mon, 24 Dec 2012 02:04:05 +0000 (UTC) (envelope-from shurd@sasktel.net) Received: from mail111c7.megamailservers.com (mail111c7.megamailservers.com [69.49.98.211]) by mx1.freebsd.org (Postfix) with ESMTP id ECB088FC0C for ; Mon, 24 Dec 2012 02:04:04 +0000 (UTC) X-Authenticated-User: hurds.sasktel.net Received: from stephen.hurd.local (ip70-187-145-241.oc.oc.cox.net [70.187.145.241]) (authenticated bits=0) by mail111c7.megamailservers.com (8.13.6/8.13.1) with ESMTP id qBO23tnO025158; Sun, 23 Dec 2012 21:03:57 -0500 Message-ID: <50D7B80B.2030106@sasktel.net> Date: Sun, 23 Dec 2012 18:03:55 -0800 From: Stephen Hurd User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121022 Firefox/16.0 SeaMonkey/2.13.1 MIME-Version: 1.0 To: Alie Tan Subject: Re: FreeBSD10-CURRENT r244480 hang while compiling lighttpd or any port References: <6FC3E540-DEBD-4763-BB46-13F3422508E9@kientzle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CSC: 0 X-CHA: v=1.1 cv=2sEl+nYIWn3GVGOYG7vvzr4q0iGv5BXujfxzLqGOH1s= c=1 sm=1 a=sd1-78TbSwQA:10 a=W-nA_WuoWwAA:10 a=YxfxW3ofkq8A:10 a=8nJEP1OIZ-IA:10 a=qWhSLQ/2FgUpSQgLv9E1tw==:17 a=umj3UH_-hbk645b1_P8A:9 a=wPNLvfGTeEIA:10 a=qWhSLQ/2FgUpSQgLv9E1tw==:117 X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A02020A.50D7B80D.00AE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: Tim Kientzle , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 02:04:05 -0000 Alie Tan wrote: >>> Anyone having hang issue while compiling any big port or portsnap fetch >>> extract? >> On what system? >> >> Tim >> > Oops sorry. On Raspberry Pi 256 and 512 I consistently do on my RPi 512, haven't looked into it yet though. From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 02:09:13 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 953AEEF4 for ; Mon, 24 Dec 2012 02:09:13 +0000 (UTC) (envelope-from shurd@sasktel.net) Received: from mail129c7.megamailservers.com (mail129c7.megamailservers.com [69.49.98.229]) by mx1.freebsd.org (Postfix) with ESMTP id 2EBC98FC0C for ; Mon, 24 Dec 2012 02:09:12 +0000 (UTC) X-Authenticated-User: hurds.sasktel.net Received: from stephen.hurd.local (ip70-187-145-241.oc.oc.cox.net [70.187.145.241]) (authenticated bits=0) by mail129c7.megamailservers.com (8.13.6/8.13.1) with ESMTP id qBO299Kh020707; Sun, 23 Dec 2012 21:09:10 -0500 Message-ID: <50D7B945.3050400@sasktel.net> Date: Sun, 23 Dec 2012 18:09:09 -0800 From: Stephen Hurd User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121022 Firefox/16.0 SeaMonkey/2.13.1 MIME-Version: 1.0 To: Alie Tan Subject: Re: FreeBSD10-CURRENT r244480 hang while compiling lighttpd or any port References: <6FC3E540-DEBD-4763-BB46-13F3422508E9@kientzle.com> <50D7B80B.2030106@sasktel.net> In-Reply-To: <50D7B80B.2030106@sasktel.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CSC: 0 X-CHA: v=1.1 cv=irLj17ZF5ABOTBuyAu2t31N+Nq5xiP0nh7CWcFrUZ/0= c=1 sm=1 a=sd1-78TbSwQA:10 a=W-nA_WuoWwAA:10 a=YxfxW3ofkq8A:10 a=8nJEP1OIZ-IA:10 a=qWhSLQ/2FgUpSQgLv9E1tw==:17 a=VEtkiNx1KMUG6Arh3C4A:9 a=wPNLvfGTeEIA:10 a=qWhSLQ/2FgUpSQgLv9E1tw==:117 X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A020204.50D7B947.004B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: Tim Kientzle , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 02:09:13 -0000 Stephen Hurd wrote: > Alie Tan wrote: >>>> Anyone having hang issue while compiling any big port or portsnap fetch >>>> extract? >>> On what system? >>> >>> Tim >>> >> Oops sorry. On Raspberry Pi 256 and 512 > I consistently do on my RPi 512, haven't looked into it yet though. The fs on mine is NFS mounted over IPv6, not local storage. From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 02:15:14 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0220BF for ; Mon, 24 Dec 2012 02:15:14 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 520018FC0A for ; Mon, 24 Dec 2012 02:15:14 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TmxZK-0005ta-Uw; Sun, 23 Dec 2012 18:15:13 -0800 Message-ID: <50D7BAA6.4020709@bluezbox.com> Date: Sun, 23 Dec 2012 18:15:02 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alie Tan Subject: Re: FreeBSD10-CURRENT r244480 hang while compiling lighttpd or any port References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 12/21/2012 12:00 AM, Alie Tan wrote: > Hi, > > Anyone having hang issue while compiling any big port or portsnap fetch > extract? > > Once hung, I cant SSH or press any key on keyboard anymore. > Do you have serial console? I saw several hangs and just pressing any key on serial console fixed the hang - NFS session re-established and build continued. I think there is some kind of problem with timer scheduling but haven't looked into it further yet. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 02:15:14 -0000 On 12/21/2012 12:00 AM, Alie Tan wrote: > Hi, > > Anyone having hang issue while compiling any big port or portsnap fetch > extract? > > Once hung, I cant SSH or press any key on keyboard anymore. > Do you have serial console? I saw several hangs and just pressing any key on serial console fixed the hang - NFS session re-established and build continued. I think there is some kind of problem with timer scheduling but haven't looked into it further yet. From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 02:21:54 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7AB161E2 for ; Mon, 24 Dec 2012 02:21:54 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 41D458FC0A for ; Mon, 24 Dec 2012 02:21:54 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi5so3825675pad.27 for ; Sun, 23 Dec 2012 18:21:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=GjPS9Ptvk0QNCLIeIcyFCZw1OUKgfdVQSRt6Xeh8ACA=; b=LTYufCQi4nU6W8YGL5le6uDs5fsroV66HTq3gFweQJ4DifUcfFcGoSBOwJD6iKjjsH TAeG5cKJpTcqHd0lRns/xl1F5UDYmCnJRGPbg380Iq9hSZBcqsiaLkzYpq7yBd0N2d1p nDVq4W8TsbJj0/XabyF148J5RTpKxDhoJapVvOf6VhkQEbbWlCNZrtyL77ATXNAPsdMS nWdnNPNtsM3La6D1LME/go9bovFBYPdCfSLq6lQh9QhLZlwaAn+W9NATMt5984D4hzyt HetOW2ENTKegjO7PTorNapQSifyliPqnZq+WV5/xsc3GCBEiTjNst47Q6KLQoMQB4P+w OyqA== MIME-Version: 1.0 Received: by 10.68.143.41 with SMTP id sb9mr63034851pbb.50.1356315713999; Sun, 23 Dec 2012 18:21:53 -0800 (PST) Received: by 10.66.235.101 with HTTP; Sun, 23 Dec 2012 18:21:53 -0800 (PST) In-Reply-To: <50D7B945.3050400@sasktel.net> References: <6FC3E540-DEBD-4763-BB46-13F3422508E9@kientzle.com> <50D7B80B.2030106@sasktel.net> <50D7B945.3050400@sasktel.net> Date: Sun, 23 Dec 2012 18:21:53 -0800 Message-ID: Subject: Re: FreeBSD10-CURRENT r244480 hang while compiling lighttpd or any port From: Alie Tan To: Stephen Hurd X-Gm-Message-State: ALoCoQnDPgLbbZS2v+4r5kzZ3J3DbrkSFNjxhMmnkQQ+gdXG9fsYM1iOQFJCScU+e6yiw4DgPk2O Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Tim Kientzle , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 02:21:54 -0000 Mine is UFS with BSD_ULE and here is my kernel config: include RPI-B ident RPI-Bnd nooptions KDB # Enable kernel debugger support. nooptions DDB # Support DDB. nooptions GDB # Support remote GDB. nooptions INVARIANTS nooptions INVARIANT_SUPPORT nooptions WITNESS nooptions WITNESS_SKIPSPIN On Sun, Dec 23, 2012 at 6:09 PM, Stephen Hurd wrote: > Stephen Hurd wrote: > > Alie Tan wrote: > >>>> Anyone having hang issue while compiling any big port or portsnap > fetch > >>>> extract? > >>> On what system? > >>> > >>> Tim > >>> > >> Oops sorry. On Raspberry Pi 256 and 512 > > I consistently do on my RPi 512, haven't looked into it yet though. > > The fs on mine is NFS mounted over IPv6, not local storage. > From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 02:49:18 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D6EA5A1 for ; Mon, 24 Dec 2012 02:49:18 +0000 (UTC) (envelope-from freebsd-arm@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 152788FC0A for ; Mon, 24 Dec 2012 02:49:16 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id qBO2nCbf009639; Sun, 23 Dec 2012 21:49:12 -0500 (EST) (envelope-from freebsd-arm@wynn.com) Date: Sun, 23 Dec 2012 21:49:12 -0500 From: Brett Wynkoop To: Ian Lepore , freebsd-arm@freebsd.org Subject: Re: Raspberry Pi EABI test image Message-ID: <20121223214912.23403d51@ivory.wynn.com> In-Reply-To: <1356314368.1129.77.camel@revolution.hippie.lan> References: <20121224103825.086cd584@fubar.geek.nz> <50D79C5C.1000704@m5p.com> <20121223204101.2345559d@ivory.wynn.com> <1356314368.1129.77.camel@revolution.hippie.lan> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 02:49:18 -0000 On Sun, 23 Dec 2012 18:59:28 -0700 Ian Lepore wrote: > On Sun, 2012-12-23 at 20:41 -0500, Brett Wynkoop wrote: > > On Sun, 23 Dec 2012 19:05:48 -0500 > > George Mitchell wrote: > > > > > > > > Although rc.conf says ue0_config="DHCP"', dhclient doesn't run. > > > I can run it manually, and then everything network-related works. > > > > I bet this is not just a Pi issue as I have the same issue on the > > Beaglebone and have put a call to dhclient in /etc/rc. > Try ue0_config="SYNCDHCP" so that it gets started directly from the rc > scripts instead of relying on devd. > > -- Ian > > Greeting- ifconfig_cpsw0="SYNCDHCP" in /etc/rc.conf did the trick on the beaglebone. Thanks! -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6924 718-717-5435 From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 03:31:26 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B98AF994 for ; Mon, 24 Dec 2012 03:31:26 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 4F0CB8FC14 for ; Mon, 24 Dec 2012 03:31:25 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.1.67]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Tmyl8-0006Ww-SA; Sun, 23 Dec 2012 19:31:25 -0800 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: EHCI on armv6 with Write-Back caches From: Oleksandr Tymoshenko In-Reply-To: <201212211520.46822.hselasky@c2i.net> Date: Sun, 23 Dec 2012 19:31:05 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <201212201956.47884.hselasky@c2i.net> <50D3AAF1.80609@bluezbox.com> <201212211520.46822.hselasky@c2i.net> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1499) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2012-12-21, at 6:20 AM, Hans Petter Selasky wrote: > On Friday 21 December 2012 01:18:57 Oleksandr Tymoshenko wrote: >> On 12/20/2012 10:56 AM, Hans Petter Selasky wrote: >>> FYI - please test! >>> >>> Forwarded Message >>> >>> Subject: Re: EHCI on armv6 with Write-Back caches >>> Date: Thursday 20 December 2012, 19:46:34 >>> From: Hans Petter Selasky >>> To: Warner Losh >>> CC: Andrew Turner , Oleksandr Tymoshenko >>> , freebsd-usb@freebsd.org, alfred@freebsd.org, >>> freebsd- wireless@freebsd.org >>> >>> Hi, >>> >>> I've run some basic tests over here (x86) which passed after some patch >>> modifications. Please test and verify for your ARM targets: >>> >>> http://svnweb.freebsd.org/changeset/base/244500 >>> http://svnweb.freebsd.org/changeset/base/244503 >>> >>> Please also verify that upgt and uwrt and uath still works like expected. >>> >>> --HPS >> >> if_smsc fails with following diagnostics: >> smsc0: error: allocating USB transfers failed >> >> The problem is that Bulk-In transfer buffer is 5 pages long but tag's >> boundary limitation is >> a page and it's impossible to allocate 5 pages without crossing page >> boundary > > Can you try again using this patch: > > http://svnweb.freebsd.org/changeset/base/244535 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 03:31:26 -0000 On 2012-12-21, at 6:20 AM, Hans Petter Selasky wrote: > On Friday 21 December 2012 01:18:57 Oleksandr Tymoshenko wrote: >> On 12/20/2012 10:56 AM, Hans Petter Selasky wrote: >>> FYI - please test! >>> >>> ---------- Forwarded Message ---------- >>> >>> Subject: Re: EHCI on armv6 with Write-Back caches >>> Date: Thursday 20 December 2012, 19:46:34 >>> From: Hans Petter Selasky >>> To: Warner Losh >>> CC: Andrew Turner , Oleksandr Tymoshenko >>> , freebsd-usb@freebsd.org, alfred@freebsd.org, >>> freebsd- wireless@freebsd.org >>> >>> Hi, >>> >>> I've run some basic tests over here (x86) which passed after some patch >>> modifications. Please test and verify for your ARM targets: >>> >>> http://svnweb.freebsd.org/changeset/base/244500 >>> http://svnweb.freebsd.org/changeset/base/244503 >>> >>> Please also verify that upgt and uwrt and uath still works like expected. >>> >>> --HPS >> >> if_smsc fails with following diagnostics: >> smsc0: error: allocating USB transfers failed >> >> The problem is that Bulk-In transfer buffer is 5 pages long but tag's >> boundary limitation is >> a page and it's impossible to allocate 5 pages without crossing page >> boundary > > Can you try again using this patch: > > http://svnweb.freebsd.org/changeset/base/244535 Seems to work now, thanks From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 10:13:28 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ADDE8B09 for ; Mon, 24 Dec 2012 10:13:28 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.c2i.net [212.247.154.226]) by mx1.freebsd.org (Postfix) with ESMTP id 314DE8FC0A for ; Mon, 24 Dec 2012 10:13:27 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 362787903; Mon, 24 Dec 2012 11:13:19 +0100 From: Hans Petter Selasky To: Ralf Wenk Subject: Re: Fwd: Re: EHCI on armv6 with Write-Back caches Date: Mon, 24 Dec 2012 11:14:54 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <201212201956.47884.hselasky@c2i.net> <201212231143.33127.hselasky@c2i.net> In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201212241114.54427.hselasky@c2i.net> Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 10:13:28 -0000 Hi, My fault. Fixed in: http://svnweb.freebsd.org/changeset/base/244650 Please try again! --HPS From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 11:06:40 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1059B5C6 for ; Mon, 24 Dec 2012 11:06:40 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id CFBB28FC1D for ; Mon, 24 Dec 2012 11:06:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qBOB6deK065965 for ; Mon, 24 Dec 2012 11:06:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBOB6dhD065963 for freebsd-arm@FreeBSD.org; Mon, 24 Dec 2012 11:06:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Dec 2012 11:06:39 GMT Message-Id: <201212241106.qBOB6dhD065963@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 11:06:40 -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/174461 arm [patch] Fix off-by-one in arm9/arm10 cache maintenance o arm/173617 arm Dreamplug exhibits eSATA file corruption using network o kern/171096 arm [arm][xscale][ixp]Allow 16bit access on PCI bus o arm/166256 arm build fail in pmap.c o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) p arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 p arm/134338 arm [patch] Lock GPIO accesses on ixp425 16 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 13:47:33 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC6FD435 for ; Mon, 24 Dec 2012 13:47:33 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) by mx1.freebsd.org (Postfix) with ESMTP id 75D618FC0C for ; Mon, 24 Dec 2012 13:47:32 +0000 (UTC) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1Tn8NQ-0023vC-98; Mon, 24 Dec 2012 14:47:32 +0100 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 From: Ralf Wenk To: Hans Petter Selasky Subject: Re: Fwd: Re: EHCI on armv6 with Write-Back caches In-reply-to: <201212241114.54427.hselasky@c2i.net> References: <201212201956.47884.hselasky@c2i.net> <201212231143.33127.hselasky@c2i.net> <201212241114.54427.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Dec 2012 14:47:30 +0100 Message-Id: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 13:47:33 -0000 > Hi, > > My fault. > > Fixed in: > > http://svnweb.freebsd.org/changeset/base/244650 > > Please try again! > > --HPS Hi, yes, that fixed it. Every plug in of or boot with the plugged in USB-stick was successful and the partition on the USB-stick is mountable again. Thank you very much. Ralf From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 15:58:08 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1FC869B for ; Mon, 24 Dec 2012 15:58:08 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id 8B14C8FC0C for ; Mon, 24 Dec 2012 15:58:08 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id qBOFw00A070117; Mon, 24 Dec 2012 10:58:06 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <50D87B88.6080504@m5p.com> Date: Mon, 24 Dec 2012 10:58:00 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20121125 Thunderbird/15.0.1 MIME-Version: 1.0 To: Andrew Turner Subject: Re: Raspberry Pi EABI test image References: <20121224103825.086cd584@fubar.geek.nz> <50D79C5C.1000704@m5p.com> <20121224135512.30c84b7c@fubar.geek.nz> In-Reply-To: <20121224135512.30c84b7c@fubar.geek.nz> Content-Type: multipart/mixed; boundary="------------020001060405040109000109" 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]); Mon, 24 Dec 2012 10:58:07 -0500 (EST) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 15:58:08 -0000 This is a multi-part message in MIME format. --------------020001060405040109000109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/23/12 19:55, Andrew Turner wrote: > On Sun, 23 Dec 2012 19:05:48 -0500 > George Mitchell wrote: > [...] >> Although rc.conf says ue0_config="DHCP"', dhclient doesn't run. I can >> run it manually, and then everything network-related works. > I've seen this before with other RPi images. > Changing DHCP to SYNCDHCP "fixes" the issue. I'll try to see if I can figure out why DHCP doesn't work. >> I NFS-mounted a /usr/ports tree and installed portmaster. When I >> tried "portmaster -BDg sysutils/LPRng", it died trying to run >> something called autom4te while working on libtool. > This may or may not be an EABI issue, are you able to send through a > log of the build? I can also see if I can reproduce it here. > Unfortunately, I didn't get that far this time -- it died in the configure stage of the libtool build. I still don't have a serial cable to connect with. Can you break into the kernel debugging with a USB keyboard? Once it was stuck, I could not change to another console with Alt-F2. Pinging the box caused the network interface LED to blink, but there wasn't any reply. I don't imagine the build log will help much, but I attached it anyway. -- George >> What would we need to do to get a driver for the pulse-width >> modulation audio port? >> >> The lack of a visible cursor on the screen is a major annoyance. > It sounds like this is a problem with the RPi driver. > > Andrew > --------------020001060405040109000109 Content-Type: application/octet-stream; name="typescript.xz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="typescript.xz" /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4EF9CoBdACmYykarec1wWuOyuHWSQFx0n4Zpm+xL 9wLACxPhO44K3tqlBtF8wyzgC/vrM+IcjyfIizQT8LfsT4iL/MYdzO1noxd//Z6b6ttSKkTy 1ET/S78xycZTaFx4YdxMCnzaB5ggzzdtdu4/qD0alM0Hb0hYWFx9Vz3i4UN0PH0BUbrmmep8 kSy+fFcl1CWOrdQs2/9QuM2aPFSp9zewSKq22pDd7neG1+z2nk38V1iBseIKR/F/c6vEhTjG 3zf+Rp+wiBIU69a3hvMqg/vnoKp314mJPfocn1pPePM9cFmg5/vc4UyNd2lxHvKqCxJlsclT TEGBjvzSoC/xAm//gXs7+zw2LtcCjdtl9ZLlvqoK7SCkZKs9X78kOQvJO4zfrRr+tIpfR7oV t66pfD3cBSvh1veWBdAbZMQJzP6LCthEdhqJNXFpP2qEtw4k+oG3oWJ+/FxVZ0HTM5iv/QtD sy6rgKx3Je88Pp+GHVcP/a3MEg9AcR7FEQoFWYmDpRK9/GF8iJVqTJuia2vT8QltaKTwaE+C /edKEyb7Arje8sBoI0ZDRJOVaaydCHGY2+vwJc9zci/GMG4/yWYHV+ryT9Fk8OIAwx6oysPQ mKAPVE537WUR2vtsGaniUJz1ckP/1LWh6ZrUfRaH24iNWqBX/PTGeTVUEM8vHUqaXdDv3g2+ G4TID5kecCJYnlxYruwZjgsHYU8Z5mu7wv4ZO/Qcn/WlIuI+X2S22Lfp914f43FxMAoH3y+n zp5EohFE0LoXf53zva9mlA1wSM31hTs3gsrt0n030tEQYiiutvyxOupd87Z++zg1SXW/sP0H mWnarYbrqNWPW1bz/DlysIiIEi16Aq5+wF4ery4BDoSR1aIvP7xCZSrozh4Z8ZwyLakinaHJ SsGTGlcXcUhc7ve3vK6c4/Xp7+NlI4pSYZLJSo0NAdjLqZRnqYK0B0yfCLtaImH4HR29FK9C GY9e3Kvov5NVNRdcXlWHSZdZzsvBf8B3/IpbrvDpFdq8M3Y5dwkl9+a1GFhebFyjD/DJwOVj ksmrn0z8yE1klTRyyT5f/OSyqW7jSK1qU1Pavn47+DMUuGMB8BfygSpJ+g262uEypNpP60QO R12bzeqDN0CjPQT6oJsizJ3UieoaMEvGgM/QY86OBVVdgCWdSEGOtgoWeZsjPCpZgWTfZlS1 Qa48+4CQyx/nzUO03hAwaw1er0cYLDbFxs+2hdelqYw8662OzEa07NAgf2dmvx1IAZ2+iWlX HCW96A8POVclR4sPS8nt7lJxCTMbN+85BCYIK0F3OcH5GEodybM5R6/T+NqxcNuMvx/hMrgu a7bqwXJ33jP9dmE5CgFBCB8PlbBHYI1bgfh+hEQwnnjL2dNc9jyaStk5EWaYGeNHzL/bOzCA 5JXiqACI5TAHiU+8MJq386jZfKNAUP683l53TnU+4hxQyaWOhrdwWp4l1MwwXXoSpbzAMoAA FkBFwT+8093Dkj8MeF6nJwtGOaX206nX4YwRY6VBLyCOUXv1n+K6mSt/apwCXTAfVeluUsB8 8LPeT4zwitH+tfiybxU6HdtK/AI5l3kcl2ioIUc7KhifQ0cehS3G447UoK2sF1yV0ny1OdjG EqyTPAy6AD5PYMF2o9BLZ7DnWmVgCdnr1Xq84duEU/tNTNf+opjvekzxQ4sFF3tvnAO0old/ Tce25G013zyn6EKcEPbRYwksbYE4/vs8PJVtmtnCQ94J/SS46sfq1cWOfGB4vlR5Rf5E55RX fiG55MMEBm3A0+K/yb4BnLe8Lx6Zv8pRGfa9PDCErqcG7Rzz+PrRJW2mOHD0Ps9m8RLiuGrj Z0MHY7XWO8u7DqWjQelRSgGsXH5IVaxVTWM9w1Ewmfbl6TXKuSq5ZIfcj3nxdJhc4UGhlxow pf1GC4MM+DJVSaOxIWqpxpNjeD/D/+GbOpkXK+HlYMfjGduHLfiNyN2IJh0CbySCUA9NWmBm uQvYMJg9Rbznv1SNhUx42jxYJvRU92cyGpT24Lkh4LpgnSLS0AmPeHQ45TfI8YcMuutf45Xm RRL/ApElhokF9fi4FZjAGkM4TDmPcxLWi4eJeABxlt4t0U1N0m2s6ZxmnP7yHctrkhb6Apbz 3Rwn6/P4u7kytD0NK6QLBTOqjWcbDbtqwd4AiHHqc8MVx5/kcgA55w/CAmt+TVKso+4WIckk qKzIb78UJ884URnvTeGpmYb4B0xoSd5MfRu+rJGnRFAkC2z+Eyxb0XR3mvkQLfDbvcWGG3lB Husgtnrl0mQlCs2BzeGozUfYcjWfCg4imWZi3YbaJ41m3lNtWoBHigA7uFitN+ZEEzl+Jtbw CvWc87l5C/xuETNNGL35t8QSJQ4sGQzZViwr7Mp0pFMybs3SmE5/NA07Bk8oJkgKFdch7q97 q7kNW6KGhQiPYzsfaPkYdLhsDgGNSJY8fwbRQA1WbDtBopjE1zfXVH7G1sYBn5qqQhKC3REW zp+D+Y/rgRYjof0Nm0/o8Mc044QtGdixQOYLa1Xr73X10Xms9NC5aJe9ls32nbyi+iIn+U6S hpzWT/9OUVCgII5gmaN3wxwAg6E4/EVcSz/CGzclPl7qhhU6sk6kzNQMsesdwwzax/sB38Xv FFxtNf5D6HNetyYX6oCAa8CNGLyFyPbBLIX7JeQQPOd0smzaT/S6mQTFRZYOIb2c17uv2Du8 Gom+zlNyUmEsSn4x5JvVnV0VquxlcRfFDbJSu0k9IYUht4mMn+QBy4N6jTM8o/djCD/lm4Lz xB6tpz7tlaygpsKWQ+xTtHJR5v7Y3vYVwu3/2sf5B2Sm8q+zcUmlb3HUKpEqFMTX1z3v6zoG kBv8yKsctxfD4C8+xE09NATOxhxI+sejdpJEcS+D18DcQ0WLAqNEEU18L5L4nj5tGUGpPmP+ IUAaJFs/6XAWow4PP/mAq43cHYb51fiwJBrfITwy9dgBAyLak2RmFFvq2+oo7xz+HXZWCUpS k+0JW/farcMq/k8JSrmEZ6hPB8GU8lF8+bUIM7PsV1HlrVdxww+QRc47yYsbcI5SuqondwPD XxI1rt0VwEyySyR7ZYOWesNuhI01ngfZmtdY5P5cRGFZBrZi0QbZAhBz6URGaTq8fP3Xecfz D4JD5na+pVdTEspwFK+dliRHKFkZmf5PHsN0JWIi0q0I97PRjwrWxvLQujrurB2V3yFTChU9 q6qEp5J/7dIxQqwGZTWLf2+GY9GvXLiVhcJoBlooNeBCJOy+6m8qYmyd6no5CRxn25vcde0/ 7JHDru5PoQkWo3bWIwWn+N9WITTw5U3N15kFRJNkPelV7PtOTIHa0E2oxr6j4WiZa/nglCru 6AZvuzPnVzOgJkMWea9h4tJum5tW9d82C/Bg8Cf2DCzYT/TqRKBc+z5OBetvqAyt10pdqUeu 3wi7adO+SPjtOefYW4haPo3SMxWPQ4/IkwpcHsOnTCxqBMkDmd0cPGAtZDv8VPKXOm822ngu TPEn1Tqh1HiRTiehkNcEivNclE7T4Vqc/9Fk68/qMR0Aj7p4bviJ5wlm7pQXH5k2bzwNfovD GTZZqi0Kfz/u4fvzuOUY6jWsXABra/saoJWQ2gABnBX+ggEALIXinLHEZ/sCAAAAAARZWg== --------------020001060405040109000109-- From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 16:41:23 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D6BA2C37 for ; Mon, 24 Dec 2012 16:41:23 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id 8126A8FC0A for ; Mon, 24 Dec 2012 16:41:23 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id qBOGfHIf070542; Mon, 24 Dec 2012 11:41:22 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <50D885AD.7010402@m5p.com> Date: Mon, 24 Dec 2012 11:41:17 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20121125 Thunderbird/15.0.1 MIME-Version: 1.0 Subject: Re: Raspberry Pi EABI test image References: <20121224103825.086cd584@fubar.geek.nz> <50D79C5C.1000704@m5p.com> <20121224135512.30c84b7c@fubar.geek.nz> <50D87B88.6080504@m5p.com> In-Reply-To: <50D87B88.6080504@m5p.com> Content-Type: multipart/mixed; boundary="------------010304030703090105090105" 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]); Mon, 24 Dec 2012 11:41:23 -0500 (EST) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 16:41:23 -0000 This is a multi-part message in MIME format. --------------010304030703090105090105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/24/12 10:58, George Mitchell wrote: > On 12/23/12 19:55, Andrew Turner wrote: >> On Sun, 23 Dec 2012 19:05:48 -0500 >> George Mitchell wrote: >> [...] >>> I NFS-mounted a /usr/ports tree and installed portmaster. When I >>> tried "portmaster -BDg sysutils/LPRng", it died trying to run >>> something called autom4te while working on libtool. >> This may or may not be an EABI issue, are you able to send through a >> log of the build? I can also see if I can reproduce it here. >> > Unfortunately, I didn't get that far this time -- it died in the > configure stage of the libtool build. [...] This time I was able to duplicate the problem; see attachment. -- George --------------010304030703090105090105 Content-Type: application/octet-stream; name="typescript.xz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="typescript.xz" /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4G8IDmVdACmYykarec1wWuOyuHWSQFx0n4Zpm+xL 9wLACxPhO48jd002Ov4fFS3GHzq1bJcb3S/dBl8XPyTJZHsEh63q156f9vDIreMNbdJg+zXb V0KcVQQDpKkURXOVWXUz6fUiBNCHPdJjoU0NJOMO5RmRFtPeSwmPJpvWkozN7XADcxtbYgbl zXidsfwVIW7lY6ifIloPz3mKL0PDiSQv0OEuRwHl/4zxOtXG3Q3p+GZvpHQvvea95u7v7fMJ 0hPp8UHm2hMoccDZ5t0zGIcuK2t/D8WNliEqCBbjALM8SUc4+Y3WVEczPDbBYEDkOfU7lLAO 0VFPwMt6pcTBJdSFa5gqikyuz+bRzRd8rxfPHWHLHBvPMIN1apeTziz+Dnezb4Q2cwfGTkRR 0TFhLJJS/QEW6Oe7YhdS2JGmwH4j1K5DDRaQ7J8ywf41l8/3tM2tmH7jI4hQB2TUtPb0Vbes wiio/9pWlOkL47IqftuJGvmZa1Ha6kI95b4P1SOC1Gd37GjdzI7WvbNJ8oMLv0fIqr63Syyv rL3sCRsozCe0MkyTzIq+fG4hFOMfMSuhM7UFFyKYnsilZMOPfWPT9ch9e9DYrPnhfzjqmUL4 gXUI0XN9V3+jhUAoCU3RVsiUtzB2F3XtuvnO19WDUoyRS56L8imSkkKFPSjEXKZqcPoDavRH kh76wT/hvx/z6jpkab8lnWu2QIdOifDMRWbCrZL+LxeVuinYYSJeuscxvu7vvnP5IXIr3YAf bzBlOZrqbpC14uT/oXHUsyRTiRpqe4R4/DiGdnwd8Q+8MPRGx2NrNDZVI+CTMfAkcLZLUCFZ C1kJliMT2tRutYkw9U00/+QQ8S4+qOVq+70l/goHIS0qBKEATd0ycXBB9jvAxnY+TwqIlw4h b+M200WRLG+/3klO+zasfrhfr5j+9DkxMt+BV4RwXzFqv1XbKOHSkvIYkvv5RRQhJQsTo5nI 37NEeO+FkrkJw1Jn1AirbJKpULkPtEkcF38l6FtuLGMDXZgy9KVxFFJ85JvxggeCUO5mmeAB VVtpqKNf41PZHQElp3uaqNRPR5vaMG5bIXCy5c8nlJNyHOZWoLtawA93/Emeo1GCZGacK4SO +r1QymYGQFlLA9OILu8gwfsTBF/jlJ2wNQg9pbePgkyVWcX9Q0ibL0s5e3iRmMFI4XlcdGn5 GOuqu2Un+BXBOXkcIH3v5LzYsgcTvuYWFAYmRIz6rq3C64ShibpscOnQKcx1zUjbgB1UKZQq NVf82W2EXrhKXwranaEDYHDGoXrW2B3hzmBoQZYiVOWRYwz14wLbPeAv/puIURp0ipDxuxcq Ql1cW4FC3fZbui3vNaLXJlCIv26psZt4Q55+HG7srtUaa8iuIMtz2TW5rXdKvLZWe/OcNOdY rNK4KYr0nqVBVhxtamKPDQLKdNdoVCGIAH194s1N3Upc+3dxO3M5aFwvxl4bMAv0AAK8lAKE sKQmT7ZavNA4PBGZBA1yN3DPuGYY28S5JNFw7RJfeEYJghX5JYrUdDmRQTdui5nI8DnMqjCq yXlnVpHUZz4s7oqHv1LWAkvIzCxTmRbyM8Rw/CvmVgw0FqYZd8BfbeKKXArM04tFdhYVgDqE zqZtmv1ogMQslVQOWfEO1IYnaFDo38mjGue9B0qj3HxYIg3fet0KwvWTpJ+OfQ6BQKk7s81s AKcJPhbeub/ueq+xRjGPN9jNG6Ct73CN7D6JzCuVpdv+tjR/RS3A3z02AV9I0WB3Vfxkn++q Tslf9NcWZRJmftZzp0tIMK+E5jBTEx+RHvRiqVxKNQk3JrnJnhkrXrALI6pwWXRGx5GyKNRs gRJzYify5KIlRutERGwt2YPUV+PnUe7zjs2nZXwnR0eIjlGtS9oFGQSAX6S6JjfOMgTpycdu JjcThVrJdYI6VL0XQi7yS5JsAckV8vPFe+spq5s5kZdsNkyZ42rG16AOEztEZbwINw2q3PvV ZYnXX89k57q4KYmUPFrglS8CMtmgZluvORy9Q7BrWXQpC9/0rPiQtGHNyVZcJWnYrNcwYQMn R+GIL7LxNyQZQ77A9NseyO8QysbU2FmQzbaBU5IQ+rgOtieaWSuTWtKRmVBFVh6rbu9uBz+0 ftUccumuz2VHYv2KHbeE84CtvfhscnR0DjTpT2Tify+gj67Yh2YbBtKSFMistuzIHoF3dUw/ qmqn3trfG5aGhjz72BkWTR/F1uknfdWK6OgBbOnx0lhjDh0zrSNG/v7/J2r+W3pf8C+pz4zF svOfWqwDsqmLoIaoVOanmtB34jQWgZEOoZLEzXkfbCZ5MRcvuqXGb/TVQHXv65ZGanUfGq0+ 9IaxV+wilRYb+nF8iTTRvfhynKl9/OxugFh0F4IQbitHRyWz52pudkTj2RQ8MkW7qu7ISb5C CkQgEvI0t7RQq49My997fjrzWlXKzM5x7FwcpBvnUtlqm5yXf32HGyG+L/zoFIplIlq7sqHV YPF/GdLUL0EU51TzBjrfMyCDaIVVmd6z7ecKHlZ6MtQo0Aul+GKD2JiIPyADPVHm/wn5EzwY 88iWttLyMLBlpohoZCcs/xSfZQaRPA4cdDB6Hgs624+hLMR/Nfy4MnQfVnubIsknuk+NyFMZ 7HHSjnQn6sMb2+w8aSBgpi+hZ4C3BomxUFf8cFICrrkMpn5+p+vP/YcnpOfS++OIwjb0LuFr VYa1lbTduBHwG0EjzPwiqOh9yXApzlcbnD6IzeUN3wlyW89U4JWJRKFfzbWgaSCNQWNDzSYW TkFFcgfe7wpQXvXpgksHvQVtqktg85pp+24RV6T1U6MRHDTIeMt4z34YYwZEdzyY8Gj/YH7I rsPe64/fo0GZayUypZm5qy4uuYptJUGFde0nAOc3Tg/H10i/tEAm5gt291HSf7eCufgkuMtu xDSV/xlcpJcKme+64NndSCYPErJvObIsAHMT8AGihtX3r1TCOMAxaoToUG4wi2gjGVQXy5bJ NprvqPC4VE3aDuHWpJ5XcXeCrb9x4uo0f4gOK5hnqJhqY0K0y+q+0y6wVf3HgovTkWuAB4BM Q57pnxi1DU45XLct+aedCarAK3HAOt3vat+gxj8ISaI990vFA5uORBn9RFMZtjIMZ0joQpoj JunJTmnRkkoh8qolG0H6H7N39KBbnDp7vQ4eSIxT2lgt+C/ejMCCo8aOATdLaLRjCyfmQ+2z nh+S6c54ubWmsQQETOXk/YqO8wjaMbofbLPk+asckCvRxi1YK1ISW1EBzwV1GlzyqyEQqaz2 7kTRRn2U4eI5G6nALW4LWFEptrbEUDgLSjU9daSH/9lriXH8w2JqlecTGMx3Nk+xpprKRu66 PMq6dj/RXNKCjsnhXrEblIoR15EeK+I4IqYx4r+VOvnr8dklS2BSALHJlRzm/oQJCmKe8f+M YCGrjMHSF2g/9fAyy4eTZ4Ks6uV/28L2x+iSsV8uXF4lYL6zplrPilVj9Tg0/uIJiQ4XHo2B UFEeJanzU6yTpvo00tnMXT5OoPNjQfHI1s+AS57/AP1h2k3UA27QgwZhePDn6C72fp7wS8Oq H4ud8C0ICvm6XZCHdzQdXi2qFn+NYx0sGrVkllIdoZuOYwFbB8DfK2wW4h3EuvzZb+Yagjmz czxscBfBcIt1gnXsuJKqRrOQDUrq57bTZAh+hqwGmMuzS3EFCNNmp3agBtPDHme8KX3pZzwg KAobv1CMWdyEo7CsK7bXkifL54XnAmQ7PEenELmRiMgc5obdOKeW+GT+JVuFlyGGiYGw6KXN zpEt1p4b9ESi4M2gH1+swSWyL70bwB+d7BfqYX+VFnqog4GTeSZ1rssfFxPpYd/HFG4S2Y2n H3R4XZZyAIP7opGHwIbmphFr1EqFyegoyDH0aOdkafXVsVvwtEBSA8WU6hVYz3AbqNo1o3wU ugngi49/jocBTnn90sVr3LeG3EQR5Viv/XI3ZVem5Huu2gFBRn8ikplkSTihUjeqSi57u+SL VLIR8GbjeTU8wRGejJIlMnMPJpcZyTVNxsaMYq2nhfDS8HBUpdNj/2KvWx/H4xXgezDV/xD/ SnicpADpQFxHygcoyoyAmXg1gew4ZSisUx/7rs1b1jJHo/FNO6FYV7pJUg9/8GySE2BAkCce O2awb6RgvKfyBnE16zBACeQlyhgB2ToW36EktPlopv0xdCZjIYf+rfHNUfv6dsEDJV1uRayi Hu6v4ST2oYnoD9UK8ytHhUFj00om5MvgjUOY/pfXPtt4giQcuYGg9f1aOyIuE4osxbqqrwSk Negfwb6xmIERFA/Xuyf0MTyRSMPw8W3cXWSChHvTTKF8UtpcNLM29THc8+bAHLVPiZDPbemw NSRiAs4BhnC0Ro1drBF0RXv/3afQz+2wEhKcp26bhrPRfd2BeE91qksZ1CNIBj5vH+YuzLmX NvTl/IFm7/oQHwurGR3kd9J1tFyrI9Elndj75y09fs1WgHzLZ2AF42cDaJ5cqRu/i4ETLTAI XHOT6DP37MARgpr9rjJjH/N57S7LhYbhws8qKpjDBiTDcZ8GTlqSOOSgh7kG7D6PvFfbwhKv mtpKpwCfiogXhhhl0537m6VS66sFdahQhVJFSUmHgZr/y8PFbKNhKggotiwm82lOESk23xiU U5b7NH8BiSmG10iImBEF9TNqYQDPal1j9wOFL8Oq3KUfX1Rx7KECWIuyY54DOeRQTBZaclG4 +YRSd2KtSLlRej15vcLtqmtJsivuxZp+9TUb6Uyr3GU4HYVn3W6BI7QNLm1kJdLoC/lzV/rG 8DPilFWhhC1kC4Z26X48IedbsRcM+EnS5LAW2TwsRzDRME4r1IUOBfrY+t4cUVs6M6Rhw9a8 tCTOvsZgIyYGL0rqRfmVjX5vhN7/aD+lmBa/ZVOi8KkiV+LVQUwtHUMpIvAAAAAAYteZ5pnB MXAAAYEdid4BAFmQlICxxGf7AgAAAAAEWVo= --------------010304030703090105090105-- From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 17:53:46 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 097C54AA for ; Mon, 24 Dec 2012 17:53:46 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id F07038FC13 for ; Mon, 24 Dec 2012 17:53:38 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBOHrb58081730 for ; Mon, 24 Dec 2012 10:53:37 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBOHrYSE071042; Mon, 24 Dec 2012 10:53:34 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Raspberry Pi EABI test image From: Ian Lepore To: George Mitchell In-Reply-To: <50D87B88.6080504@m5p.com> References: <20121224103825.086cd584@fubar.geek.nz> <50D79C5C.1000704@m5p.com> <20121224135512.30c84b7c@fubar.geek.nz> <50D87B88.6080504@m5p.com> Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Dec 2012 10:53:34 -0700 Message-ID: <1356371614.1129.114.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 17:53:46 -0000 On Mon, 2012-12-24 at 10:58 -0500, George Mitchell wrote: > On 12/23/12 19:55, Andrew Turner wrote: > > On Sun, 23 Dec 2012 19:05:48 -0500 > > George Mitchell wrote: > > [...] > >> Although rc.conf says ue0_config="DHCP"', dhclient doesn't run. I can > >> run it manually, and then everything network-related works. > > I've seen this before with other RPi images. > > > Changing DHCP to SYNCDHCP "fixes" the issue. I'll try to see if I can > figure out why DHCP doesn't work. > To look into why =DHCP doesn't work, look at devd and the devd rules to figure out why usb-based interfaces (apparently) aren't being handled. The way the rc system works these days, DHCP means "do 'ifconfig up' on the interface and let devd launch dhclient in response to that", and SYNCDHCP means "the rc system directly invokes dhclient immediately". -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 19:13:52 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3EA53B5 for ; Mon, 24 Dec 2012 19:13:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by mx1.freebsd.org (Postfix) with ESMTP id 6A9C18FC0C for ; Mon, 24 Dec 2012 19:13:51 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c13so9148315ieb.17 for ; Mon, 24 Dec 2012 11:13:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=qemV1HAh+KbTmqHAc+gdj2RlDZl2I/33Ge0iHed98SE=; b=m4yDQkEWY+SfZ2B3Kbv4IFkKhFpYZLWQw/v7+ox1iDDoxurdPhUUOm+5YxihrqkdRL hmVZiP2kZ6MBaCjgolpTuDfaai0+n5+NsxqfWfqpZlDZBAInH5a8+PbW8nBbLV4H2nC9 LnzHDujGhV3bR0ALYla+snNLFfwdW7uNU9C5P+Gk44n8pFW48D11BIwpdoSdgdHWGSu8 I0DE1vr2DrP7aOcwd29AH68/oqYzPoJM5YXIaGmbwoH7Y45UHrpoudhcn1d/T8Rtein1 ydMtCsr5pYnGqEric/v+BKrPiMp+LI7TgJ+3Fzq8SzaXC/1hKFD2jkTOXb+2/lZc4jW4 9MyQ== X-Received: by 10.43.17.199 with SMTP id qd7mr13328511icb.52.1356376425242; Mon, 24 Dec 2012 11:13:45 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id fv6sm22908389igc.17.2012.12.24.11.13.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Dec 2012 11:13:44 -0800 (PST) Sender: Warner Losh Subject: Re: Raspberry Pi EABI test image Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1356371614.1129.114.camel@revolution.hippie.lan> Date: Mon, 24 Dec 2012 12:13:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9727806D-8356-4A98-B609-9B86BC42795F@bsdimp.com> References: <20121224103825.086cd584@fubar.geek.nz> <50D79C5C.1000704@m5p.com> <20121224135512.30c84b7c@fubar.geek.nz> <50D87B88.6080504@m5p.com> <1356371614.1129.114.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlW2xGFuAFm+o25lu5orvVjz1ytwD5K5pn2amKQjCjlcHLHQxvDIn6qQGAGOPBg6EUnjh12 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 19:13:52 -0000 On Dec 24, 2012, at 10:53 AM, Ian Lepore wrote: > On Mon, 2012-12-24 at 10:58 -0500, George Mitchell wrote: >> On 12/23/12 19:55, Andrew Turner wrote: >>> On Sun, 23 Dec 2012 19:05:48 -0500 >>> George Mitchell wrote: >>> [...] >>>> Although rc.conf says ue0_config=3D"DHCP"', dhclient doesn't run. = I can >>>> run it manually, and then everything network-related works. >>> I've seen this before with other RPi images. >>>=20 >> Changing DHCP to SYNCDHCP "fixes" the issue. I'll try to see if I = can >> figure out why DHCP doesn't work. >>=20 >=20 > To look into why =3DDHCP doesn't work, look at devd and the devd rules = to > figure out why usb-based interfaces (apparently) aren't being handled. > The way the rc system works these days, DHCP means "do 'ifconfig up' = on > the interface and let devd launch dhclient in response to that", and > SYNCDHCP means "the rc system directly invokes dhclient immediately". Or alternatively, you can look at the early startup state of the ue0 = device and look for subtle differences between it and other interfaces. = For a short period of time it may throw some weird error that dhclient = isn't coping with. But check to make sure that there's a rule that's run when it happens. = Since devd has transitioned to the link messages that are independent of = device type, I don't think there's a difference there, but you never = know. Finally, you might try it on a laptop, since that's an easy test = environment... Warner From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 20:03:20 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4ACBB70 for ; Mon, 24 Dec 2012 20:03:20 +0000 (UTC) (envelope-from george@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id 938AB8FC12 for ; Mon, 24 Dec 2012 20:03:20 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id qBOK3Bsr072332; Mon, 24 Dec 2012 15:03:16 -0500 (EST) (envelope-from george@m5p.com) Message-ID: <50D8B4FF.3020201@m5p.com> Date: Mon, 24 Dec 2012 15:03:11 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20121125 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Raspberry Pi EABI test image References: <20121224103825.086cd584@fubar.geek.nz> <50D79C5C.1000704@m5p.com> <20121224135512.30c84b7c@fubar.geek.nz> <50D87B88.6080504@m5p.com> <1356371614.1129.114.camel@revolution.hippie.lan> In-Reply-To: <1356371614.1129.114.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]); Mon, 24 Dec 2012 15:03:17 -0500 (EST) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 20:03:21 -0000 On 12/24/12 12:53, Ian Lepore wrote: > On Mon, 2012-12-24 at 10:58 -0500, George Mitchell wrote: >> On 12/23/12 19:55, Andrew Turner wrote: >>> On Sun, 23 Dec 2012 19:05:48 -0500 >>> George Mitchell wrote: >>> [...] >>>> Although rc.conf says ue0_config="DHCP"', dhclient doesn't run. I can >>>> run it manually, and then everything network-related works. >>> I've seen this before with other RPi images. >>> >> Changing DHCP to SYNCDHCP "fixes" the issue. I'll try to see if I can >> figure out why DHCP doesn't work. >> > > To look into why =DHCP doesn't work, look at devd and the devd rules to > figure out why usb-based interfaces (apparently) aren't being handled. > The way the rc system works these days, DHCP means "do 'ifconfig up' on > the interface and let devd launch dhclient in response to that", and > SYNCDHCP means "the rc system directly invokes dhclient immediately". > > -- Ian > That sure explains it! rc.conf says devd_enable="NO". Removing this line causes DHCP to run as expected with ue0_config="DHCP". -- George From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 20:43:14 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 742BA1A7; Mon, 24 Dec 2012 20:43:14 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 08F738FC0C; Mon, 24 Dec 2012 20:43:07 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBOKh0jZ083430; Mon, 24 Dec 2012 13:43:00 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBOKgt31071102; Mon, 24 Dec 2012 13:42:55 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Call for testing and review, busdma changes From: Ian Lepore To: Jeff Roberson In-Reply-To: References: <1355077061.87661.320.camel@revolution.hippie.lan> <1355085250.87661.345.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Dec 2012 13:42:55 -0700 Message-ID: <1356381775.1129.181.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 24 Dec 2012 21:20:30 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, John Baldwin , mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, kib@freebsd.org, sparc64@freebsd.org, arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 20:43:14 -0000 On Sun, 2012-12-23 at 14:22 -1000, Jeff Roberson wrote: > On Sun, 9 Dec 2012, Ian Lepore wrote: > > > On Sun, 2012-12-09 at 08:48 -1000, Jeff Roberson wrote: > >> > >> On Sun, 9 Dec 2012, Ian Lepore wrote: > >> > >>> On Sat, 2012-12-08 at 08:51 -1000, Jeff Roberson wrote: > >>>> Hello, > >>>> > >>>> http://people.freebsd.org/~jeff/physbio.diff > >>>> [...] > >>> > >>> Testing on armv4/v5 platforms, the patches applied and compiled cleanly, > >>> but fault-abort with a NULL deref on what appears to be the first call > >>> to bus_dmamap_load(). I'll dig deeper into debugging that after > >>> browsing the new code so I can figure out where to start debugging. > >> > >> Can you give me the file and line of the fault? > >> > > > > Better than that, I can give you patches (attached). There were two > > little glitches... the allocated slist wasn't getting attached to the > > map, and when building the slist in _bus_dmamap_load_buffer() the slist > > needs to participate in the coalescing logic near the end of the loop. > > I understand the first problem. The second, I'm not sure about. When > we're going through bounce pages we use virtual to virtual. Why do you > need to flush the cache lines for the source addresses? The device will > only do io to the bounce pages so they are the only that need other > synchronization. > As I indicated in my following paragraph, I didn't think my fix for constructing the sync list was perfect, it was just good enough to allow more testing to progress. In particular I don't think it would be right if bouncing were required, but it never is on the arm platforms I have to test with. The logic in your patch didn't work in the normal non-bounce case. The main loop that does the mapping works on a single page at a time. For each page it decides whether to use a bounce page instead, then it either merges the page into the current segment if it can, or starts a new segment. Your patch has it create a new sync list entry for every non-bounced page, but the sync list is sized to maxsegs not maxpages. So your logic writes outside the bounds of the sync list array, and my logic includes the virtual ranges of pages that will be bounced in the sync list (which I think should be harmless anyway, just a bit inefficient). The logic is wrong in both cases, but since bouncing never happens on my hardware I knew my tweak would let me do more testing. In the past, I've never paid close attention to the bounce logic, I've tended to read around it as if it weren't there. Recently I've begun to look at it and the more I look the more I think that to the degree that it works at all, it works by accident. I think mostly the logic just never gets used on the arm platforms that people are working with, because there'd be more problems reported if it were. For example... there is no handling of the PREREAD case when syncing bounce pages. A POSTREAD invalidate is insufficient; if any of the cache lines are dirty at the time the DMA starts, there are several ways those lines can get written back to physical memory while the DMA is in progress, corrupting the data in the IO buffer. Another example... there is an unordered list of bounce pages which are substituted for real pages as needed, one page at a time. No attempt is made to ensure that a run of contiguous physical pages that need to be bounced turns into a corresponding single run of contiguous pages in the bounce zone. In other words, it seems like over time as the list becomes less ordered the bounce logic would increasingly create multi-segment DMA. The reason that seems like a problem is that on every system I've checked (arm and i386) getting to multi-user mode creates about 100 dma tags, and typically only 5 or 6 of those tags allow more than one segment. I understand that this is not "incorrect operation" of the busdma code, but it does seem to be circumstantial evidence that this logic isn't being exercised much, since it appears that few drivers can actually handle multi-segment DMA. While the work I've done so far on arm busdma has concentrated on the buffer allocation and correct operation of the sync routines in the non-bounce cases, I think I'll be looking closely at the map load (currently seems a bit inefficient) and bounce-handling logic soon. > > > > I'm not positive the attached quick-fix is perfect, but it allows one of > > my arm units here to boot and run and pass some basic IO smoke tests. > > I'll be trying it on other arm platforms later today. > > > >>> > >>> Just from an initial quick browsing of the new code for armv4, I notice > >>> these things... > >>> > >>> The new routine __bus_dmamap_mayblock() does (*flags) |= BUS_DMA_WAITOK; > >>> which is a no-op because BUS_DMA_WAITOK is zero. I'm not sure what the > >>> intent was, but I think any modification of the WAIT-related flags would > >>> be conceptually wrong because it overrides the caller's instructions on > >>> whether or not to do a deferred load when resources aren't available. > >> > >> The intent of the original load function seems to be that it is always > >> blocking. Most architectures force the flag. The mbuf and uio load > >> routines don't support blocking at all because the callback lacks the > >> information needed to restart the operation. > >> > > > > The manpage states that bus_dmamap_load() never blocks for any reason. > > The mbuf and uio flavors say they are variations of bus_dmapmap_load(); > > I take the implication of that to mean that they also are defined as > > never blocking. > > > > The docs then say that WAITOK vs. NOWAIT control the scheduling of a > > deferred load, and that NOWAIT is forced in the mbuf and uio cases. > > Your refactored code already handles that by adding NOWAIT to the > > caller-specified flags for mbufs and uio. > > > > So the code will do the right thing now (with your patches), but only > > because (*flags) |= BUS_DMA_WAITOK is a no-op. > > This code is problematic. We can only support WAITOK operations for > bus_dmamap_load() because the callbacks from the swi when bounce pages are > available can only remember one pointer. To fix this for real we'd have > to remember the original type and call the appropriate load function > again. This could be solved by having a { type, pointer, length } > structure that is passed between the front and back-end. This would solve > your mbuf problem as well. I think I will do this next. I'm lost here. I don't understand your point about only being able to remember one pointer. We only ever need to remember one pointer, because a map can only be associated with a single buffer at a time. The fact that a deferred load can't be easily implemented in the case of mbufs and uio might be why the manpage says the NOWAIT flag is implied in those cases. There's no reason why the busdma code can't handle deferred loading for mbufs and uio -- as you say, it seems to only involve storing a bit of extra info for the callback. I think the hard part of the problem is elsewhere. For a transmit mbuf that needs a deferred mapping, does the driver's interface to the network stack allow for the concept of "this call has neither suceeded nor failed, but either outcome is possible, I'll let you know later" (I have no idea what the answer to that is but I can see how it could quickly become complex for drivers and other higher layers to deal with). For a deferred uio mapping, what if the userland pmap is no longer valid when the callback happens? What if userland has freed the memory? I suspect the implied NOWAIT requirement exists to wish away the need to handle such things. My original point was that the WAITOK flag has a value of zero. Your code gives the impression that it forces all callers to accept a deferred mapping, overriding whatever flag they may have passed, but in fact it doesn't do anything at all. Hmm, I just looked at non-arm implementations more closely and I see that some of them have the same logic as your patches, they OR-in a zero in an apparent attempt to override the caller's flags. That's contrary to what the manpage says and IMO contrary to common sense -- if a caller has said that it is unable to handle a deferred mapping callback, it's unlikely that anything is going to work correctly if a deferred callback happens (in fact, it sounds like a crash or panic waiting to happen). I think the only reason the existing code hasn't caused problems is because the flag value is zero and it actually does nothing except mislead when you read it. > By the way I have an mbuf branch that pushes data and mbuf structure into > separate cachelines. It's not only faster on arm and the like but on x86 > as well. So someone should pursue this and you'd have way fewer partial > line flushes. > [...] > You can skip the [mbuf] sync because you know the information in the mbuf header > is not necessary? > Not exactly. In the general case, if the buffer isn't aligned and padded to a cacheline boundary, we don't know anything about the memory before and after the buffer which partially shares a cacheline we're about to operate on, so the existing code attempts to preserve the contents of that unknown memory across the sync operation. (It cannot possibly be reliably sucessful in doing so, but that's another story.) In the case of an mbuf, where the data area following the header is always misaligned to a cacheline, we do know something about the memory before the data buffer: we know that it's an mbuf header which will not be accessed by the cpu while the dma is in progress. Likewise if the length isn't a multiple of the line size we know the data after the mapped length is still part of a buffer which is allocated to a multiple of the line size and the cpu won't touch that memory during the dma. Using that knowledge we can handle a PREREAD or PREWRITE by doing a wbinv on the cacheline (this is no different than the general case), and then we can handle the POSTREAD as if the buffer were aligned. We don't have to attempt to preserve partial cachelines before/after the buffer because we know the cpu hasn't touched that memory during the dma, so no cache line load could have happened. In the changes you mentioned, how do you ensure the mbuf header and data end up in separate cache lines without compile-time knowledge of cache line size? Even if the embedded data buffer in an mbuf becomes cache-aligned, the special mbuf awareness will still be needed to handle the fact that the mapped data length may not be a multiple of the cache line size. We'll still need the special knowledge that it's an mbuf so that we can sync the entire last cacheline without attempting to preserve the part beyond the end of the dma buffer. (If this idea makes you vaguely uneasy, you're not alone. However, I've been assured by Scott and Warner that it's always safe to treat mbufs this way.) > > > > I have patches to fix the mbuf partial sync and other things related to > > partial sync problems, and my next step will be to try to rework them to > > fit in with what you've done. Based on what I've seen so far in your > > refactoring, I think just passing a flag to say it's an mbuf, from the > > MI to the MD mapping routine, will provide enough info. > > I think I described a better approach above that will solve mutliple > problems. Let me know what you think. > > Jeff In the long run we can't just reduce the incidence of partial cacheline flushes, they have to be eliminated completely. We can eliminate them for mbufs because of arbitrary rules for mbufs that are supposedly universally followed in the existing code already. We can also eliminate them for any buffers which are allocated by bus_dmamem_alloc(), basically for reasons similar to mbufs: we can ensure that allocated buffers are always aligned and padded appropriately, and establish a rule that says you must not allow any other access to memory in the allocated buffer during dma. Most especially that means you can't allocate a big buffer and sub-divide it in such a way that there is concurrent cpu and dma access, or multiple concurrent dma operations, within a single buffer returned by bus_dmamem_alloc(). Still unresolved is what to do about the remaining cases -- attempts to do dma in arbitrary buffers not obtained from bus_dmamem_alloc() which are not aligned and padded appropriately. There was some discussion a while back, but no clear resolution. I decided not to get bogged down by that fact and to fix the mbuf and allocated-buffer situations that we know how to deal with for now. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 23:18:50 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89463291 for ; Mon, 24 Dec 2012 23:18:50 +0000 (UTC) (envelope-from freebsd-arm@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 40ECF8FC0A for ; Mon, 24 Dec 2012 23:18:49 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id qBONITqa025392; Mon, 24 Dec 2012 18:18:29 -0500 (EST) (envelope-from freebsd-arm@wynn.com) Date: Mon, 24 Dec 2012 18:18:29 -0500 From: Brett Wynkoop To: Warner Losh Subject: Re: Raspberry Pi EABI test image Message-ID: <20121224181829.7a743510@ivory.wynn.com> In-Reply-To: <9727806D-8356-4A98-B609-9B86BC42795F@bsdimp.com> References: <20121224103825.086cd584@fubar.geek.nz> <50D79C5C.1000704@m5p.com> <20121224135512.30c84b7c@fubar.geek.nz> <50D87B88.6080504@m5p.com> <1356371614.1129.114.camel@revolution.hippie.lan> <9727806D-8356-4A98-B609-9B86BC42795F@bsdimp.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 23:18:50 -0000 On Mon, 24 Dec 2012 12:13:42 -0700 Warner Losh wrote: > Or alternatively, you can look at the early startup state of the ue0 > device and look for subtle differences between it and other > interfaces. For a short period of time it may throw some weird error > that dhclient isn't coping with. > I am not sure but the above might be a red herring. My interface on my BEAGLEBONE is cpsw0 and has the exact same issue. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6924 718-717-5435 From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 23:31:22 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0121D6E9 for ; Mon, 24 Dec 2012 23:31:21 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id ACB3A8FC0A for ; Mon, 24 Dec 2012 23:31:21 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id qBONVJgl025581; Mon, 24 Dec 2012 18:31:19 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Mon, 24 Dec 2012 18:31:19 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: Re: Raspberry Pi EABI test image Message-ID: <20121224183119.73868caa@ivory.wynn.com> In-Reply-To: <20121224181829.7a743510@ivory.wynn.com> References: <20121224103825.086cd584@fubar.geek.nz> <50D79C5C.1000704@m5p.com> <20121224135512.30c84b7c@fubar.geek.nz> <50D87B88.6080504@m5p.com> <1356371614.1129.114.camel@revolution.hippie.lan> <9727806D-8356-4A98-B609-9B86BC42795F@bsdimp.com> <20121224181829.7a743510@ivory.wynn.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 23:31:22 -0000 On Mon, 24 Dec 2012 18:18:29 -0500 Brett Wynkoop wrote: > On Mon, 24 Dec 2012 12:13:42 -0700 > Warner Losh wrote: > > > Or alternatively, you can look at the early startup state of the ue0 > > device and look for subtle differences between it and other > > interfaces. For a short period of time it may throw some weird > > error that dhclient isn't coping with. > > > > I am not sure but the above might be a red herring. My interface on my > BEAGLEBONE is cpsw0 and has the exact same issue. > > -Brett Greeting- Just changed my devd_enable to yes and all works as I expected with DHCP. My rc.conf set up with Tim's script had it off, but /etc/defaults/rc.conf had it on. Tim if you are on the list you might want to change that in the script. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6924 718-717-5435 From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 23:41:25 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7041872 for ; Mon, 24 Dec 2012 23:41:25 +0000 (UTC) (envelope-from shurd@sasktel.net) Received: from mail111c7.megamailservers.com (mail111c7.megamailservers.com [69.49.98.211]) by mx1.freebsd.org (Postfix) with ESMTP id 855338FC15 for ; Mon, 24 Dec 2012 23:41:25 +0000 (UTC) X-Authenticated-User: hurds.sasktel.net Received: from stephen.hurd.local (ip70-187-145-241.oc.oc.cox.net [70.187.145.241]) (authenticated bits=0) by mail111c7.megamailservers.com (8.13.6/8.13.1) with ESMTP id qBONfLrI021044; Mon, 24 Dec 2012 18:41:24 -0500 Message-ID: <50D8E820.3050400@sasktel.net> Date: Mon, 24 Dec 2012 15:41:20 -0800 From: Stephen Hurd User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121022 Firefox/16.0 SeaMonkey/2.13.1 MIME-Version: 1.0 To: Brett Wynkoop Subject: Re: Raspberry Pi EABI test image References: <20121224103825.086cd584@fubar.geek.nz> <50D79C5C.1000704@m5p.com> <20121224135512.30c84b7c@fubar.geek.nz> <50D87B88.6080504@m5p.com> <1356371614.1129.114.camel@revolution.hippie.lan> <9727806D-8356-4A98-B609-9B86BC42795F@bsdimp.com> <20121224181829.7a743510@ivory.wynn.com> <20121224183119.73868caa@ivory.wynn.com> In-Reply-To: <20121224183119.73868caa@ivory.wynn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CSC: 0 X-CHA: v=1.1 cv=2sEl+nYIWn3GVGOYG7vvzr4q0iGv5BXujfxzLqGOH1s= c=1 sm=1 a=sd1-78TbSwQA:10 a=qpO3MUKs40sA:10 a=YxfxW3ofkq8A:10 a=8nJEP1OIZ-IA:10 a=qWhSLQ/2FgUpSQgLv9E1tw==:17 a=w33rRxbrAAAA:8 a=7Qk2ozbKAAAA:8 a=ZR7jkc35gQMneaRTBWUA:9 a=wPNLvfGTeEIA:10 a=V5EgUw7NdT4A:10 a=cvZW9r6VXHAA:10 a=qWhSLQ/2FgUpSQgLv9E1tw==:117 X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A020203.50D8E824.0043, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 23:41:26 -0000 Brett Wynkoop wrote: > On Mon, 24 Dec 2012 18:18:29 -0500 > Brett Wynkoop wrote: > >> On Mon, 24 Dec 2012 12:13:42 -0700 >> Warner Losh wrote: >> >>> Or alternatively, you can look at the early startup state of the ue0 >>> device and look for subtle differences between it and other >>> interfaces. For a short period of time it may throw some weird >>> error that dhclient isn't coping with. >>> >> I am not sure but the above might be a red herring. My interface on my >> BEAGLEBONE is cpsw0 and has the exact same issue. >> >> -Brett > Greeting- > > Just changed my devd_enable to yes and all works as I expected with > DHCP. My rc.conf set up with Tim's script had it off, > but /etc/defaults/rc.conf had it on. > > Tim if you are on the list you might want to change that in the script. Or just switch to SYNCDHCP. No reason to run devd to do something that can be handled just as well without the extra process. From owner-freebsd-arm@FreeBSD.ORG Mon Dec 24 23:47:16 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DB188FC for ; Mon, 24 Dec 2012 23:47:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-f176.google.com (mail-ia0-f176.google.com [209.85.210.176]) by mx1.freebsd.org (Postfix) with ESMTP id 231FC8FC15 for ; Mon, 24 Dec 2012 23:47:15 +0000 (UTC) Received: by mail-ia0-f176.google.com with SMTP id y26so6161374iab.21 for ; Mon, 24 Dec 2012 15:47:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=Mnhpkz4RXCYDdK4dTGEDWsLj88DdX5f0lsRVQz8LCKs=; b=hGX+j9YjCXCTfJO5L6hjXKIVRO8gyAJsU47Njsvby6XZ9ICT8Zj24vRA35c4DZGgo5 ggH7JjQ2EXLyIpIbDRJkgoCyHoseJ9glSXApkkoKFUPIy183MmWIBkfhNE+EtSTZcoUF vIKAh/BX7ds540N/IZ6hUFGCUdp2IHDLM86uSAWYH7Lj9GcLtCaVdLK70lW1HLITTweV rb5jxBlrczkkHGnyhoOmGGUZRWahoellWo+lxyDqY77Rv7IO8i6sGCsDPZVLIRKyTm2T qIaDPGhtH44LPrc37lzvN8breqp6LQ4D0r41UcE/G/lYyaF8Ex2akClVYKWDogehgxA8 BpJA== X-Received: by 10.50.36.130 with SMTP id q2mr15400226igj.81.1356392835228; Mon, 24 Dec 2012 15:47:15 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id i9sm23398210igl.9.2012.12.24.15.47.13 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Dec 2012 15:47:14 -0800 (PST) Sender: Warner Losh Subject: Re: Raspberry Pi EABI test image Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <50D8E820.3050400@sasktel.net> Date: Mon, 24 Dec 2012 16:47:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121224103825.086cd584@fubar.geek.nz> <50D79C5C.1000704@m5p.com> <20121224135512.30c84b7c@fubar.geek.nz> <50D87B88.6080504@m5p.com> <1356371614.1129.114.camel@revolution.hippie.lan> <9727806D-8356-4A98-B609-9B86BC42795F@bsdimp.com> <20121224181829.7a743510@ivory.wynn.com> <20121224183119.73868caa@ivory.wynn.com> <50D8E820.3050400@sasktel.net> To: Stephen Hurd X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnRVjasWRAYn2Lk0b6hrv1awScV/mB0F0H/0L75oGRwX5tFLaOO7+mx3f6fSCgYi+7nZoY5 Cc: freebsd-arm@freebsd.org, Brett Wynkoop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 23:47:16 -0000 On Dec 24, 2012, at 4:41 PM, Stephen Hurd wrote: > Brett Wynkoop wrote: >> On Mon, 24 Dec 2012 18:18:29 -0500 >> Brett Wynkoop wrote: >>=20 >>> On Mon, 24 Dec 2012 12:13:42 -0700 >>> Warner Losh wrote: >>>=20 >>>> Or alternatively, you can look at the early startup state of the = ue0 >>>> device and look for subtle differences between it and other >>>> interfaces. For a short period of time it may throw some weird >>>> error that dhclient isn't coping with. >>>>=20 >>> I am not sure but the above might be a red herring. My interface on = my >>> BEAGLEBONE is cpsw0 and has the exact same issue. >>>=20 >>> -Brett >> Greeting- >>=20 >> Just changed my devd_enable to yes and all works as I expected with >> DHCP. My rc.conf set up with Tim's script had it off, >> but /etc/defaults/rc.conf had it on. >>=20 >> Tim if you are on the list you might want to change that in the = script. >=20 > Or just switch to SYNCDHCP. No reason to run devd to do something = that > can be handled just as well without the extra process. When you run w/o devd, there are many details that will be wrong with = the system that you'll have to puzzle over from time to time. Possible, = yes. Trouble Free? no. The system has been designed to work with devd = running, but not with it not running as much... Warner From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 00:00:38 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6240698D for ; Tue, 25 Dec 2012 00:00:38 +0000 (UTC) (envelope-from shurd@sasktel.net) Received: from mail119c7.megamailservers.com (mail119c7.megamailservers.com [69.49.98.219]) by mx1.freebsd.org (Postfix) with ESMTP id E4FD98FC12 for ; Tue, 25 Dec 2012 00:00:37 +0000 (UTC) X-Authenticated-User: hurds.sasktel.net Received: from stephen.hurd.local (ip70-187-145-241.oc.oc.cox.net [70.187.145.241]) (authenticated bits=0) by mail119c7.megamailservers.com (8.13.6/8.13.1) with ESMTP id qBP00XQJ005237; Mon, 24 Dec 2012 19:00:35 -0500 Message-ID: <50D8ECA1.60301@sasktel.net> Date: Mon, 24 Dec 2012 16:00:33 -0800 From: Stephen Hurd User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121022 Firefox/16.0 SeaMonkey/2.13.1 MIME-Version: 1.0 To: Warner Losh Subject: Re: Raspberry Pi EABI test image References: <20121224103825.086cd584@fubar.geek.nz> <50D79C5C.1000704@m5p.com> <20121224135512.30c84b7c@fubar.geek.nz> <50D87B88.6080504@m5p.com> <1356371614.1129.114.camel@revolution.hippie.lan> <9727806D-8356-4A98-B609-9B86BC42795F@bsdimp.com> <20121224181829.7a743510@ivory.wynn.com> <20121224183119.73868caa@ivory.wynn.com> <50D8E820.3050400@sasktel.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CSC: 0 X-CHA: v=1.1 cv=M/OfXiUT3yXeNaOuONSOHRsfWHstuXXEwp4jCZzxbHU= c=1 sm=1 a=sd1-78TbSwQA:10 a=qpO3MUKs40sA:10 a=YxfxW3ofkq8A:10 a=8nJEP1OIZ-IA:10 a=qWhSLQ/2FgUpSQgLv9E1tw==:17 a=gb1x_sv-a-nReN-2Y9kA:9 a=wPNLvfGTeEIA:10 a=qWhSLQ/2FgUpSQgLv9E1tw==:117 X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A020209.50D8ECA3.0084, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: freebsd-arm@freebsd.org, Brett Wynkoop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 00:00:38 -0000 Warner Losh wrote: >>> Greeting- >>> >>> Just changed my devd_enable to yes and all works as I expected with >>> DHCP. My rc.conf set up with Tim's script had it off, >>> but /etc/defaults/rc.conf had it on. >>> >>> Tim if you are on the list you might want to change that in the script. >> Or just switch to SYNCDHCP. No reason to run devd to do something that >> can be handled just as well without the extra process. > When you run w/o devd, there are many details that will be wrong with the system that you'll have to puzzle over from time to time. Possible, yes. Trouble Free? no. The system has been designed to work with devd running, but not with it not running as much... > > Warner Yeah, I'm assuming that there's a reason it was explicitly disabled. The dhcp client and USB keyboard support are the only things I see in the default devd.conf that could be applicable to a RPi that isn't going to have stuff hotplugged. From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 00:44:30 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33EA7430 for ; Tue, 25 Dec 2012 00:44:30 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) by mx1.freebsd.org (Postfix) with ESMTP id BC39C8FC15 for ; Tue, 25 Dec 2012 00:44:29 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 79DC239FA3 for ; Tue, 25 Dec 2012 09:35:07 +0900 (JST) Received: from artemis (unknown [172.18.0.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id 6593639D5E for ; Tue, 25 Dec 2012 09:35:07 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: References: In-Reply-To: Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Date: Tue, 25 Dec 2012 09:34:51 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 00:44:30 -0000 I've updated FreeBSD clang world for RPI based on svn r244663. (To save working time, drop EABI patch.) Now clang is 3.2 final. This version includes complete source tree of r244663. But the patch is not applied. You must apply the patch manually. This version has been confirmed that the kernel can be compiled by self and booting from it. You can get the pre-build image from my archives: http://www.peach.ne.jp/archives/rpi/ (At this time, freebsd-pi-clang-20121225.img.gz is the latest version.) Download and decompress it, then write it to SD. This image requires SD 4GB or more. I'm using as headless server. So, you need a serial console for seeing the boot log. If you need to change the value on it, please mount the second partition (e.g. /dev/da0s2a). If you want the video out, please remove the line of "set console=comconsole" in /boot/loader.rc. Using config is here: http://www.peach.ne.jp/archives/rpi/config/RPI-B-test9 Source(diff) and pacth is here: http://www.peach.ne.jp/archives/rpi/patch/ For more, please read this: http://lists.freebsd.org/pipermail/freebsd-arm/2012-December/004331.html tested /etc/make.conf: ---------------------------------------------------------------------- WITHOUT_X11=yes WITH_CLANG=yes WITH_CLANG_IS_CC=yes # For clang NO_WERROR= WERROR= CFLAGS=-O2 -fno-strict-aliasing -pipe -march=armv6z -mtune=arm1176jzf-s -mfloat-abi=soft COPTFLAGS=-O1 -fno-strict-aliasing -pipe -march=armv6z -mtune=arm1176jzf-s -mfloat-abi=soft ---------------------------------------------------------------------- How to build the kernel in RPI: # fetch -o /usr http://www.peach.ne.jp/archives/rpi/patch/src-244663-20121225.patch.gz # fetch -o /usr/src/sys/arm/conf http://www.peach.ne.jp/archives/rpi/config/RPI-B-test9 # cd /usr/src # gzcat /usr/src-244663-20121225.patch.gz | patch # make buildkernel KERNCONF=RPI-B-test9 (wait about 60 minutes :) If you want re-compile, you can try to use like this: # make buildkernel KERNCONF=RPI-B-test9 -DNO_CLEAN -DNO_CLEANDIR ---------------------------------------------------------------------- Enjoy clang world in Raspberry Pi! Thank you. -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 00:02:28 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E3119EB for ; Tue, 25 Dec 2012 00:02:28 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-da0-f48.google.com (mail-da0-f48.google.com [209.85.210.48]) by mx1.freebsd.org (Postfix) with ESMTP id 4B1708FC13 for ; Tue, 25 Dec 2012 00:02:28 +0000 (UTC) Received: by mail-da0-f48.google.com with SMTP id k18so3351016dae.7 for ; Mon, 24 Dec 2012 16:02:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:x-x-sender:to:cc:subject:in-reply-to :message-id:references:user-agent:mime-version:content-type :x-gm-message-state; bh=I0GFDKOg9qlcIkDxXnHwe8OKNN3dwd/o++IWhz6ZEpY=; b=kkrlU4t2V8ts7iAlk9lHFrU7LwGcSo5IA1bLqmPVvcx5kBjqVM6emz4Wssr/I48irD nuGmBhdQAHRebws2HbGCovf/ggOcFw+QRQ3KipcDhsGFwUPPYxPe2P3db/0YzrbwabVb xVxnr11tz96OJzk0d4LIipN2fUzxoKWA0/jl4Vp4swReOxCqeugivmJZhwIEjfeIN9BS /Oir9uuzZwOIylQp9jgwYrxwE09a4zw2lHYFbXg1aT3jnBd68HZkO9nc/LJTAElEuzWY jabPVJKwLBBMrrnv2n3tAf3IocU6AylwpsF6CrIuKQiL0m/aBczgVikwn1+R3VnOggRb AOPQ== X-Received: by 10.68.235.40 with SMTP id uj8mr70483044pbc.98.1356393747173; Mon, 24 Dec 2012 16:02:27 -0800 (PST) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by mx.google.com with ESMTPS id oi3sm13055733pbb.1.2012.12.24.16.02.23 (version=SSLv3 cipher=OTHER); Mon, 24 Dec 2012 16:02:26 -0800 (PST) Date: Mon, 24 Dec 2012 14:02:19 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Ian Lepore Subject: Re: Call for testing and review, busdma changes In-Reply-To: <1356390225.1129.217.camel@revolution.hippie.lan> Message-ID: References: <1355077061.87661.320.camel@revolution.hippie.lan> <1355085250.87661.345.camel@revolution.hippie.lan> <1356381775.1129.181.camel@revolution.hippie.lan> <1356390225.1129.217.camel@revolution.hippie.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQkG93Gz4x4FnuMr37kBGlkNPQOB/1z3TnWgx66d1FLx98/zP1voUv0xBRhAWt1z+YGOaCGE X-Mailman-Approved-At: Tue, 25 Dec 2012 01:27:00 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, John Baldwin , mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, kib@freebsd.org, sparc64@freebsd.org, arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 00:02:28 -0000 On Mon, 24 Dec 2012, Ian Lepore wrote: > On Mon, 2012-12-24 at 11:21 -1000, Jeff Roberson wrote: >> On Mon, 24 Dec 2012, Ian Lepore wrote: >> >>> On Sun, 2012-12-23 at 14:22 -1000, Jeff Roberson wrote: >>>> On Sun, 9 Dec 2012, Ian Lepore wrote: >>>> >>>>> On Sun, 2012-12-09 at 08:48 -1000, Jeff Roberson wrote: >>>>>> >>>>>> On Sun, 9 Dec 2012, Ian Lepore wrote: >>>>>> >>>>>>> On Sat, 2012-12-08 at 08:51 -1000, Jeff Roberson wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> http://people.freebsd.org/~jeff/physbio.diff >>>>>>>> >>> [...] >>>>>>> >>>>>>> Testing on armv4/v5 platforms, the patches applied and compiled cleanly, >>>>>>> but fault-abort with a NULL deref on what appears to be the first call >>>>>>> to bus_dmamap_load(). I'll dig deeper into debugging that after >>>>>>> browsing the new code so I can figure out where to start debugging. >>>>>> >>>>>> Can you give me the file and line of the fault? >>>>>> >>>>> >>>>> Better than that, I can give you patches (attached). There were two >>>>> little glitches... the allocated slist wasn't getting attached to the >>>>> map, and when building the slist in _bus_dmamap_load_buffer() the slist >>>>> needs to participate in the coalescing logic near the end of the loop. >>>> >>>> I understand the first problem. The second, I'm not sure about. When >>>> we're going through bounce pages we use virtual to virtual. Why do you >>>> need to flush the cache lines for the source addresses? The device will >>>> only do io to the bounce pages so they are the only that need other >>>> synchronization. >>>> >>> >>> As I indicated in my following paragraph, I didn't think my fix for >>> constructing the sync list was perfect, it was just good enough to allow >>> more testing to progress. In particular I don't think it would be right >>> if bouncing were required, but it never is on the arm platforms I have >>> to test with. >>> >>> The logic in your patch didn't work in the normal non-bounce case. The >>> main loop that does the mapping works on a single page at a time. For >>> each page it decides whether to use a bounce page instead, then it >>> either merges the page into the current segment if it can, or starts a >>> new segment. Your patch has it create a new sync list entry for every >>> non-bounced page, but the sync list is sized to maxsegs not maxpages. >>> >>> So your logic writes outside the bounds of the sync list array, and my >>> logic includes the virtual ranges of pages that will be bounced in the >>> sync list (which I think should be harmless anyway, just a bit >>> inefficient). The logic is wrong in both cases, but since bouncing >>> never happens on my hardware I knew my tweak would let me do more >>> testing. >> >> Ok, so I need to add coalescing and perhaps fix the bounds checking for >> virtual ranges. Correct? I can do that simply enough. I have some other >> changes I will make concurrently and then get another build that I would >> like you to test. Thank you for all the feedback so far. >> > > Okay, but did you see that Olivier committed my busdma changes recently? > It makes for a pretty significant by-hand merge with your work. I've > done that merge -- I think I sent it to you last week -- but what > Olivier committed was a wee bit different than what I merged with then. > I'm going to move this patch further along before I re-merge. I want to get buy in on the next set of API changes I'm going to make. > I think the little patch I sent originally to do the sync list > coalescing based on segments is probably good enough for now. It will > result in syncing virtual ranges that are actually being bounced, but > the arm code has always done that due to bugs (it skips the virtual > range sync only if the entire buffer fits in one bounce page). I will look at this next. mips has the same pattern and I want to make sure it's correct there too. > > I just had a close look at the armv6 implementation of mapping and > syncing for the first time, and... oh my. It's creating (malloc'ing!) a > sync list entry for every individual page of every mapped buffer. I > think it should be doing something more like my quickie-patch that bases > the sync list entries on the segments since it has to sync l2 cache > based on physical ranges for some chips. If you look at my branch I made the two arm busdma implementations identical in this regard. > >>> >>> In the past, I've never paid close attention to the bounce logic, I've >>> tended to read around it as if it weren't there. Recently I've begun to >>> look at it and the more I look the more I think that to the degree that >>> it works at all, it works by accident. I think mostly the logic just >>> never gets used on the arm platforms that people are working with, >>> because there'd be more problems reported if it were. >> >> I think it is even rarely used on x86 anymore. The number of poorly >> behaved DMA engines has been shrinking. >> >>> >>> For example... there is no handling of the PREREAD case when syncing >>> bounce pages. A POSTREAD invalidate is insufficient; if any of the >>> cache lines are dirty at the time the DMA starts, there are several ways >>> those lines can get written back to physical memory while the DMA is in >>> progress, corrupting the data in the IO buffer. >>> >>> Another example... there is an unordered list of bounce pages which are >>> substituted for real pages as needed, one page at a time. No attempt is >>> made to ensure that a run of contiguous physical pages that need to be >>> bounced turns into a corresponding single run of contiguous pages in the >>> bounce zone. In other words, it seems like over time as the list >>> becomes less ordered the bounce logic would increasingly create >>> multi-segment DMA. The reason that seems like a problem is that on >>> every system I've checked (arm and i386) getting to multi-user mode >>> creates about 100 dma tags, and typically only 5 or 6 of those tags >>> allow more than one segment. I understand that this is not "incorrect >>> operation" of the busdma code, but it does seem to be circumstantial >>> evidence that this logic isn't being exercised much, since it appears >>> that few drivers can actually handle multi-segment DMA. >>> >>> While the work I've done so far on arm busdma has concentrated on the >>> buffer allocation and correct operation of the sync routines in the >>> non-bounce cases, I think I'll be looking closely at the map load >>> (currently seems a bit inefficient) and bounce-handling logic soon. >> >> I'm shocked that we're sending I/O of larger than a page size to devices >> that only support 1 sg entry. Rather than memcpying and bouncing these >> drivers should be written to chop up the I/O themselves. For network >> devices they should not advertise jumbo frame support and for disk devices >> they can specify the maximum io size as one page already. The original >> pages that we send down would almost never be contiguous until very >> recently so this wouldn't have worked even without bounce pages. >> >>> >>>>> >>>>> I'm not positive the attached quick-fix is perfect, but it allows one of >>>>> my arm units here to boot and run and pass some basic IO smoke tests. >>>>> I'll be trying it on other arm platforms later today. >>>>> > [...] >>> The fact that a deferred load can't be easily implemented in the case of >>> mbufs and uio might be why the manpage says the NOWAIT flag is implied >>> in those cases. There's no reason why the busdma code can't handle >>> deferred loading for mbufs and uio -- as you say, it seems to only >>> involve storing a bit of extra info for the callback. I think the hard >>> part of the problem is elsewhere. For a transmit mbuf that needs a >>> deferred mapping, does the driver's interface to the network stack allow >>> for the concept of "this call has neither suceeded nor failed, but >>> either outcome is possible, I'll let you know later" (I have no idea >>> what the answer to that is but I can see how it could quickly become >>> complex for drivers and other higher layers to deal with). For a >>> deferred uio mapping, what if the userland pmap is no longer valid when >>> the callback happens? What if userland has freed the memory? I suspect >>> the implied NOWAIT requirement exists to wish away the need to handle >>> such things. >> >> Yes for uio the operation will have to be able to work on something other >> than the current pmap. Many busdma implementations remember the pmap >> because that could also be true when sync is called. Also actual uio >> operations to user pages are probably not initiated by anything in tree. >> Maybe some command interfaces for storage drivers. It is definitely an >> edge case. I would rather not support it but I guess it does make such >> things easier to implement and not require a copy. >> >> Most storage drivers have the logic that you describe above. They watch >> for EINPROGRESS. Then the callback can supply an error if the operation >> fails later. I would like to make this more uniform because cam drivers >> are about to support multiple different memory descriptors. It would be a >> shame if they each had different semantics. So I need deferred load of >> many types to work. >> > > Yeah, I've done some low-level storage driver stuff myself (mmc/sd) and > I can see how easy the deferred load solutions are to implement in that > sort of driver that's already structured to operate asychronously. I'm > not very familiar with how network hardware drivers interface with the > rest of the network stack. I have some idea, I'm just not sure of all > the subtleties involved and whether there are any implications for > something like a deferred load. > > This is one of those situations where I tend to say to myself... the > folks who designed this stuff and imposed the "no deferred load" > restriction on mbufs and uio but not other cases were not stupid or > lazy, so they must have had some other reason. I'd want to know what > that was before I went too far with trying to undo it. In network drivers you just discard the mbuf. Networks are lossy. If you persistently are out of bounce buffers you'll fail to transmit. The flags were manually or'd in for these consumers to simplify the implementation. I intend to change the underlying mechanism to support it but not the mbuf load wrappers. > >>> >>> My original point was that the WAITOK flag has a value of zero. Your >>> code gives the impression that it forces all callers to accept a >>> deferred mapping, overriding whatever flag they may have passed, but in >>> fact it doesn't do anything at all. >> >> Yes I realized that. I just made a commit to eliminate that on my branch. >> Thank you for pointing it out. >> >>> >>> Hmm, I just looked at non-arm implementations more closely and I see >>> that some of them have the same logic as your patches, they OR-in a zero >>> in an apparent attempt to override the caller's flags. That's contrary >>> to what the manpage says and IMO contrary to common sense -- if a caller >>> has said that it is unable to handle a deferred mapping callback, it's >>> unlikely that anything is going to work correctly if a deferred callback >>> happens (in fact, it sounds like a crash or panic waiting to happen). I >>> think the only reason the existing code hasn't caused problems is >>> because the flag value is zero and it actually does nothing except >>> mislead when you read it. >> >> Yes, they all seem to respect NOWAIT as well. So oring it in did nothing. >> >>> >>>> By the way I have an mbuf branch that pushes data and mbuf structure into >>>> separate cachelines. It's not only faster on arm and the like but on x86 >>>> as well. So someone should pursue this and you'd have way fewer partial >>>> line flushes. >>>> >>> [...] >>>> You can skip the [mbuf] sync because you know the information in the mbuf header >>>> is not necessary? >>>> >>> >>> Not exactly. In the general case, if the buffer isn't aligned and >>> padded to a cacheline boundary, we don't know anything about the memory >>> before and after the buffer which partially shares a cacheline we're >>> about to operate on, so the existing code attempts to preserve the >>> contents of that unknown memory across the sync operation. (It cannot >>> possibly be reliably sucessful in doing so, but that's another story.) >>> >>> In the case of an mbuf, where the data area following the header is >>> always misaligned to a cacheline, we do know something about the memory >>> before the data buffer: we know that it's an mbuf header which will not >>> be accessed by the cpu while the dma is in progress. Likewise if the >>> length isn't a multiple of the line size we know the data after the >>> mapped length is still part of a buffer which is allocated to a multiple >>> of the line size and the cpu won't touch that memory during the dma. >>> >>> Using that knowledge we can handle a PREREAD or PREWRITE by doing a >>> wbinv on the cacheline (this is no different than the general case), and >>> then we can handle the POSTREAD as if the buffer were aligned. We don't >>> have to attempt to preserve partial cachelines before/after the buffer >>> because we know the cpu hasn't touched that memory during the dma, so no >>> cache line load could have happened. >>> >>> In the changes you mentioned, how do you ensure the mbuf header and data >>> end up in separate cache lines without compile-time knowledge of cache >>> line size? >>> >>> Even if the embedded data buffer in an mbuf becomes cache-aligned, the >>> special mbuf awareness will still be needed to handle the fact that the >>> mapped data length may not be a multiple of the cache line size. We'll >>> still need the special knowledge that it's an mbuf so that we can sync >>> the entire last cacheline without attempting to preserve the part beyond >>> the end of the dma buffer. (If this idea makes you vaguely uneasy, >>> you're not alone. However, I've been assured by Scott and Warner that >>> it's always safe to treat mbufs this way.) >>> >> >> I understand now. It is safe in the usual cases but not in the general >> case. The mbuf API allows for 'ext bufs' which have reference to >> arbitrary external memory. There are no guarantees about the alignment of >> this memory or what comes before or after it. It could really be >> anything. In practice I think you'll be safe with all code that is in >> tree but I'm not 100% sure. >> > > The ext bufs are exactly the part that makes me vaguely uneasy, but I > figured I'd run with what I was told until it was proven unworkable. > > > [...] >>> >>> Still unresolved is what to do about the remaining cases -- attempts to >>> do dma in arbitrary buffers not obtained from bus_dmamem_alloc() which >>> are not aligned and padded appropriately. There was some discussion a >>> while back, but no clear resolution. I decided not to get bogged down >>> by that fact and to fix the mbuf and allocated-buffer situations that we >>> know how to deal with for now. >> >> It sounds like you're hitting the common cases. It seems ok to keep the >> partial flush logic for the less common cases and deal with the >> performance penalty. >> >> Jeff >> > > I've got to keep stressing... it's not a performance penalty thing, it's > a correct operation thing. Partial cacheline flush logic cannot be > written in a way that's guaranteed to always give correct results, > because the software can't prevent the hardware from doing an eviction > and writing back stale data even while the code that attempts to > preserve the data is running. Some day when all the other code is > right, the place where we currently detect a partial flush and try to > preserve the surrounding data will be a panic call. Until then we'll > keep relying on the partial flush usually working right by accident. I understand now. If you're sharing the line with someone who is active you can't do it safely just by flushing and cleaning before the DMA. They could re-dirty the page. I was just thinking about the sync operation and existing dirty data. Technically you should bounce in this case as well since it can't be made safe. Not bouncing for mbufs is a nice optimization I see. Jeff > > But yeah, taking care of the common cases first was my priority. > > -- Ian > > From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 03:13:18 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CBF3231C for ; Tue, 25 Dec 2012 03:13:18 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm19.bullet.mail.bf1.yahoo.com (nm19.bullet.mail.bf1.yahoo.com [98.139.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 67B9E8FC0A for ; Tue, 25 Dec 2012 03:13:18 +0000 (UTC) Received: from [98.139.215.140] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 25 Dec 2012 03:13:12 -0000 Received: from [98.139.213.3] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 25 Dec 2012 03:13:12 -0000 Received: from [127.0.0.1] by smtp103.mail.bf1.yahoo.com with NNFMP; 25 Dec 2012 03:13:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1356405192; bh=ienAAZglLtbBNsor83kO6OPNJsGRWpJRYSiVFT0tQqw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=wdoP2wMZR800NZ1nu3hDEgMbqcUgrU4R6p1JvMo4WC/4WqzUgf0YjR6BPTcpX+BVwbrF24rMf+rAPg/Kx66E0tVLSTnJbcLMc1uYaWiN8M2bKV1W0jZb9nzik4rjGahChw00xzosT/Hhwqn8DpBZDdMxrE46h/ihvMhbmAvaBmA= X-Yahoo-Newman-Id: 233465.49273.bm@smtp103.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: hDJW8PcVM1l0iy7KkxW1my2pYpqQMHhtseGfw0da88jRdvm gZ1.GIEeIuDLxMoMe6aCGrkTFDyGvMjfolt4MSQYbUHvixI7WwqtgfCbEzlv 4kLqDypbFZ5vpFWVoV7gyYLZblUnYRWwrs2Gjr2V1fyJPcbNsJd8Wg28c_tQ q4K6qDqcysRxLx5T9Wkmr33IxW9rtMUqLTqa9drxawgScADW.UHHqTQ4QLBx HYzNzh.Kj.gC72PUl1dTGcOXxQYgdyx3bZGc6piUmTNddjWRrdzJqYAtJ0x0 hA.2LykQZioWy1OE5732MLw3_Iv1HoKQP43wiYMzo3ty4muqFsvFf6SRvG.A 7R0oygCNlF_sEo.BBPQ96aF83fVlNqD1jZvbVwGbCQScWUg5tHORsjbTudGr j0m8y5OmDN.luvwy0VxK0eXgwKvqFwnYW1IVdtoHRHwVbJySQcYkpoUx_Ze7 RF3WY.CdyYvx7Tg-- X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- Received: from [172.20.10.3] (scott4long@70.193.200.44 with plain) by smtp103.mail.bf1.yahoo.com with SMTP; 24 Dec 2012 19:13:12 -0800 PST Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Call for testing and review, busdma changes From: Scott Long In-Reply-To: <1356390225.1129.217.camel@revolution.hippie.lan> Date: Mon, 24 Dec 2012 22:13:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2D98F70D-4031-4860-BABB-1F4663896234@yahoo.com> References: <1355077061.87661.320.camel@revolution.hippie.lan> <1355085250.87661.345.camel@revolution.hippie.lan> <1356381775.1129.181.camel@revolution.hippie.lan> <1356390225.1129.217.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Tue, 25 Dec 2012 03:28:41 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, John Baldwin , "mav@freebsd.org Motin" , "attilio@FreeBSD.org Rao" , Jeff Roberson , sparc64@freebsd.org, arm@freebsd.org, kib@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 03:13:18 -0000 On Dec 24, 2012, at 6:03 PM, Ian Lepore = wrote: >=20 > Yeah, I've done some low-level storage driver stuff myself (mmc/sd) = and > I can see how easy the deferred load solutions are to implement in = that > sort of driver that's already structured to operate asychronously. = I'm > not very familiar with how network hardware drivers interface with the > rest of the network stack. I have some idea, I'm just not sure of all > the subtleties involved and whether there are any implications for > something like a deferred load. >=20 > This is one of those situations where I tend to say to myself... the > folks who designed this stuff and imposed the "no deferred load" > restriction on mbufs and uio but not other cases were not stupid or > lazy, so they must have had some other reason. I'd want to know what > that was before I went too far with trying to undo it. >=20 Deferring is expensive from a latency standpoint. For disks, this = latency was comparatively small (until recent advances in SSD), so it = didn't matter, but it did matter with network devices. Also, network = drivers already had the concept of dropping mbufs due to resource = shortages, and the strict requirement of guaranteed transactions with = storage didn't apply. Deferring and freezing queues to guarantee = delivery order is a pain in the ass, so the decision was made that it = was cheaper to drop an mbuf on a resource shortage rather than defer. = As for uio's, they're the neglected part of the API and there's really = been no formal direction or master plan put into their evolution. = Anyways, that's my story and I'm sticking to it =3D-) Also, eliminating the concept of deferred load from mbufs then freed us = to look at ways to make the load operation cheaper. There's a lot of = code in _bus_dmamap_load_buffer() that is expensive, but a big one was = the indirect function pointer for the callback in the load wrappers. = The extra storage for filling in the temporary s/g list was also looked = at. Going with direct loads allowed me to remove these and reduce most = of the speed penalties. >=20 >>>=20 >>> Still unresolved is what to do about the remaining cases -- attempts = to >>> do dma in arbitrary buffers not obtained from bus_dmamem_alloc() = which >>> are not aligned and padded appropriately. There was some discussion = a >>> while back, but no clear resolution. I decided not to get bogged = down >>> by that fact and to fix the mbuf and allocated-buffer situations = that we >>> know how to deal with for now. >>=20 Why would these allocations not be handled as normal dynamic buffers = would with bus_dmamap_load()? Scott From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 07:23:47 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CA2DAF3 for ; Tue, 25 Dec 2012 07:23:47 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp5.clear.net.nz (smtp5.clear.net.nz [203.97.33.68]) by mx1.freebsd.org (Postfix) with ESMTP id B88BC8FC0A for ; Tue, 25 Dec 2012 07:23:46 +0000 (UTC) Received: from mxin3-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp5.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MFK0023SSJ7HA20@smtp5.clear.net.nz> for freebsd-arm@freebsd.org; Tue, 25 Dec 2012 20:23:39 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO localhost) ([202.0.48.19]) by smtpin32.paradise.net.nz with ESMTP; Tue, 25 Dec 2012 20:23:39 +1300 Date: Tue, 25 Dec 2012 20:23:26 +1300 From: Andrew Turner Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) In-reply-to: To: Daisuke Aoyama Message-id: <20121225202326.1488fc5d@fubar.geek.nz> MIME-version: 1.0 X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; i386-portbld-freebsd8.1) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Pirate: Arrrr References: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 07:23:47 -0000 On Tue, 25 Dec 2012 09:34:51 +0900 "Daisuke Aoyama" wrote: > I've updated FreeBSD clang world for RPI based on svn r244663. > (To save working time, drop EABI patch.) As of r244640 we should have clang support in head. Do you still need to patch clang after this revision? Andrew From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 11:38:57 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C0AAAA2B; Tue, 25 Dec 2012 11:38:57 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 76ABA8FC16; Tue, 25 Dec 2012 11:38:57 +0000 (UTC) Received: from terran (unknown [192.168.10.90]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPA id D3943C492D; Tue, 25 Dec 2012 13:38:49 +0200 (EET) Date: Tue, 25 Dec 2012 13:39:04 +0200 From: Aleksandr Rybalko To: arm@freebsd.org, mips@freebsd.org, ppc@freebsd.org Subject: FDT changes Message-Id: <20121225133904.8063fb1cd193b3078b9c7596@freebsd.org> X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 11:38:57 -0000 Hello embedded hackers! (I'm not on ppc@ list, so answer to all or CC me) I made small patch [0], it's give two features: 1. We see physical addresses, like on all other systems which not use FDT. 2. It's not panic on attempt to do bus_space_map on "reg" propertie (for cases when bus is SPI/I2C/etc.) Please-please-please, give me your comments. If nobody objects, I will commit it at the end of Jan 2013 (to not worry anyone on holidays :) ) [0] http://people.freebsd.org/~ray/2012-12-25_fdt_correct_resource.diff WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 11:57:26 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF6E0EE0 for ; Tue, 25 Dec 2012 11:57:26 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) by mx1.freebsd.org (Postfix) with ESMTP id B00398FC0A for ; Tue, 25 Dec 2012 11:57:26 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id CE23239FA3; Tue, 25 Dec 2012 20:57:24 +0900 (JST) Received: from artemis (unknown [172.18.0.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id B9AB839D5E; Tue, 25 Dec 2012 20:57:24 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: "Andrew Turner" References: <20121225202326.1488fc5d@fubar.geek.nz> In-Reply-To: <20121225202326.1488fc5d@fubar.geek.nz> Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Date: Tue, 25 Dec 2012 20:57:20 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 11:57:27 -0000 > As of r244640 we should have clang support in head. Do you still need > to patch clang after this revision? I didn't check/build it, but it seems that latest clang is OK for OABI. However, it cannot be used in arm kernel because of TSIZ limitation. (other default choice is my taste/fun, not requirements) Please check below files in the patch: sys/arm/include/vmparam.h sys/conf/options.arm In my case, at least MAXTSIZ=20MB is required for -O2 optimized world. (-O1, -O0 are required more than -O2, of course) So, changeable MAXTSIZ is useful for clang. Increasing MAXTSIZ might be better when clang build. But I don't know what value is appropriate. Note: the patch contains clang, ARM11 and RPI specific patches. P.S. Thank you for many of committing. Now binutils can be used without patch. -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 13:35:53 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29E88C76 for ; Tue, 25 Dec 2012 13:35:53 +0000 (UTC) (envelope-from jakub.klama@uj.edu.pl) Received: from mail1.uj.edu.pl (mail1.uj.edu.pl [149.156.89.193]) by mx1.freebsd.org (Postfix) with ESMTP id D231D8FC0A for ; Tue, 25 Dec 2012 13:35:52 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.10.1.245] ([83.19.65.138]) by mta.uoks.uj.edu.pl (Oracle Communications Messaging Server 7u4-27.01 (7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MFL000F89J7YL00@mta.uoks.uj.edu.pl> for freebsd-arm@freebsd.org; Tue, 25 Dec 2012 14:30:44 +0100 (CET) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.0 X-Antivirus-Code: 0x100000 Message-id: <50D9AA87.1010109@uj.edu.pl> Date: Tue, 25 Dec 2012 14:30:47 +0100 From: Jakub Klama User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 To: freebsd-arm@freebsd.org Subject: Re: FDT changes References: <20121225133904.8063fb1cd193b3078b9c7596@freebsd.org> In-reply-to: <20121225133904.8063fb1cd193b3078b9c7596@freebsd.org> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 13:35:53 -0000 W dniu 2012-12-25 12:39, Aleksandr Rybalko pisze: > Hello embedded hackers! > > (I'm not on ppc@ list, so answer to all or CC me) > > I made small patch [0], it's give two features: > 1. We see physical addresses, like on all other systems which not use > FDT. > 2. It's not panic on attempt to do bus_space_map on "reg" propertie > (for cases when bus is SPI/I2C/etc.) > > Please-please-please, give me your comments. > > If nobody objects, I will commit it at the end of Jan 2013 (to not > worry anyone on holidays :) ) > > [0] http://people.freebsd.org/~ray/2012-12-25_fdt_correct_resource.diff > Looks good for me, but what is the point in using pmap_mapdev() instead of more generic bus_space_map()? Jakub From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 13:49:18 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D14F1F6 for ; Tue, 25 Dec 2012 13:49:18 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 87F1E8FC0C for ; Tue, 25 Dec 2012 13:49:17 +0000 (UTC) Received: from terran (unknown [192.168.10.90]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id EA03BC492D; Tue, 25 Dec 2012 15:49:15 +0200 (EET) Date: Tue, 25 Dec 2012 15:49:30 +0200 From: Aleksandr Rybalko To: Jakub Klama Subject: Re: FDT changes Message-Id: <20121225154930.b9e55dc6bcc38c91ad11402e@ddteam.net> In-Reply-To: <50D9AA87.1010109@uj.edu.pl> References: <20121225133904.8063fb1cd193b3078b9c7596@freebsd.org> <50D9AA87.1010109@uj.edu.pl> X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 13:49:18 -0000 On Tue, 25 Dec 2012 14:30:47 +0100 Jakub Klama wrote: > W dniu 2012-12-25 12:39, Aleksandr Rybalko pisze: > > Hello embedded hackers! > > > > (I'm not on ppc@ list, so answer to all or CC me) > > > > I made small patch [0], it's give two features: > > 1. We see physical addresses, like on all other systems which not use > > FDT. > > 2. It's not panic on attempt to do bus_space_map on "reg" propertie > > (for cases when bus is SPI/I2C/etc.) > > > > Please-please-please, give me your comments. > > > > If nobody objects, I will commit it at the end of Jan 2013 (to not > > worry anyone on holidays :) ) > > > > [0] http://people.freebsd.org/~ray/2012-12-25_fdt_correct_resource.diff > > > Looks good for me, but what is the point in using pmap_mapdev() instead > of more generic bus_space_map()? > > Jakub > _______________________________________________ > 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" You are right, thanks! Patch updated. WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 15:51:59 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16540562 for ; Tue, 25 Dec 2012 15:51:59 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from smtp.getmail.no (smtp.getmail.no [84.208.15.66]) by mx1.freebsd.org (Postfix) with ESMTP id B95C18FC14 for ; Tue, 25 Dec 2012 15:51:58 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from get-mta-scan01.get.basefarm.net ([10.5.16.4]) by get-mta-out01.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0MFL0073RDAFQQ20@get-mta-out01.get.basefarm.net> for freebsd-arm@FreeBSD.org; Tue, 25 Dec 2012 15:51:51 +0100 (MET) Received: from get-mta-scan01.get.basefarm.net (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id EEF6D179BCDF_D9BD86B for ; Tue, 25 Dec 2012 14:51:50 +0000 (GMT) Received: from kg-v2.kg4.no (cm-84.215.134.159.getinternet.no [84.215.134.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by get-mta-scan01.get.basefarm.net (Sophos Email Appliance) with ESMTPSA id BEE3317A1211_D9BD86F for ; Tue, 25 Dec 2012 14:51:50 +0000 (GMT) Date: Tue, 25 Dec 2012 15:51:46 +0100 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Subject: Re: Raspberry Pi EABI test image Message-id: <20121225155146.fbf78a5415fc6ab093c564a3@getmail.no> In-reply-to: <20121224103825.086cd584@fubar.geek.nz> References: <20121224103825.086cd584@fubar.geek.nz> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 15:51:59 -0000 On Mon, 24 Dec 2012 10:38:25 +1300 Andrew Turner wrote: > I have made a test image built from the EABI branch for the Raspberry > Pi. It is available from: > http://people.freebsd.org/~andrew/rpi/rpi-eabi-r244581.img.xz The image works on my 256MB model B, and after changing from DHCP to SYNCDHCP in /etc/rc.conf and running /etc/netstart, it get's an ip address too. For some reason, I couldn't log in as root (yes, I had set a password on the root user) via ssh, but after creating another user with adduser, I could log in fine: $ uname -a FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r244579:244581: Sun Dec 23 11:55:04 NZDT 2012 andrew@bender:/usr/obj/arm.armv6/home/andrew/freebsd/repos/arm_eabi/sys/RPI-B arm HTH -- Torfinn Ingolfsen From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 17:22:09 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22397552 for ; Tue, 25 Dec 2012 17:22:09 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id C4B7B8FC14 for ; Tue, 25 Dec 2012 17:22:08 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id qBPHM2Pu081682 for ; Tue, 25 Dec 2012 12:22:07 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <50D9E0BA.4010507@m5p.com> Date: Tue, 25 Dec 2012 12:22:02 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20121125 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Raspberry Pi EABI test image References: <20121224103825.086cd584@fubar.geek.nz> <20121225155146.fbf78a5415fc6ab093c564a3@getmail.no> In-Reply-To: <20121225155146.fbf78a5415fc6ab093c564a3@getmail.no> 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, 25 Dec 2012 12:22:07 -0500 (EST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 17:22:09 -0000 On 12/25/12 09:51, Torfinn Ingolfsen wrote: > [...] > For some reason, I couldn't log in as root (yes, I had set a password on the root user) via ssh, That would be because the default "PermitRootLogin" setting for sshd is "no". -- George > but after creating another user with adduser, I could log in fine: > $ uname -a > FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r244579:244581: Sun Dec 23 11:55:04 NZDT 2012 andrew@bender:/usr/obj/arm.armv6/home/andrew/freebsd/repos/arm_eabi/sys/RPI-B arm > > HTH > From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 20:21:47 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64914C16 for ; Tue, 25 Dec 2012 20:21:47 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2ABFA8FC12 for ; Tue, 25 Dec 2012 20:21:46 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBPKLjQM098855 for ; Tue, 25 Dec 2012 13:21:46 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBPKLNIw072250 for ; Tue, 25 Dec 2012 13:21:23 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Raspberry Pi questions From: Ian Lepore To: freebsd-arm@freebsd.org Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Dec 2012 13:21:23 -0700 Message-ID: <1356466883.1144.8.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 20:21:47 -0000 I got my RPi running this morning, more or less. I used the boot partition from the latest image at http://www.peach.ne.jp/archives/rpi/ but I'm loading my own custom built kernel and world. I have a few questions... Can I get ubldr to load a kernel using tftp, bootp, etc? Are there any docs on ubldr in general? (Right now I'm skipping ubldr and using u-boot's DHCP command to load the kernel.) My RPi comes up with a random ethernet mac address on every boot, but when I look at the driver code it seems that there should be an address stored in an eeprom. Do I have to program that myself? When I try to use an nfs-mounted root I get "Mounting from nfs:172.22.42.240:/rpi failed with error 19." but if I mount root from the sdcard then after it gets to multiuser mode I can manually nfs-mount the same directory. Has anybody got an nfs-mounted root working? -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 20:37:35 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED9BAE3E for ; Tue, 25 Dec 2012 20:37:35 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 878428FC17 for ; Tue, 25 Dec 2012 20:37:35 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.1.67]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TnbFd-0005LA-EF; Tue, 25 Dec 2012 12:37:27 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Raspberry Pi questions From: Oleksandr Tymoshenko In-Reply-To: <1356466883.1144.8.camel@revolution.hippie.lan> Date: Tue, 25 Dec 2012 12:37:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <08125E73-C46A-4DDF-BFD8-59D5B86136B8@bluezbox.com> References: <1356466883.1144.8.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1499) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2012-12-25, at 12:21 PM, Ian Lepore wrote: > I got my RPi running this morning, more or less. I used the boot > partition from the latest image at http://www.peach.ne.jp/archives/rpi/ > but I'm loading my own custom built kernel and world. I have a few > questions... > > Can I get ubldr to load a kernel using tftp, bootp, etc? [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 20:37:36 -0000 On 2012-12-25, at 12:21 PM, Ian Lepore = wrote: > I got my RPi running this morning, more or less. I used the boot > partition from the latest image at = http://www.peach.ne.jp/archives/rpi/ > but I'm loading my own custom built kernel and world. I have a few > questions... >=20 > Can I get ubldr to load a kernel using tftp, bootp, etc? =20 Yes. ubldr checks U-Boot devices (SD and net), then tries to locate FFS partition on SD card and if fails - falls back to NFS/bootp. You can = fetch my image, boot partition there contains ubldr, FDT blob, config.txt and = boot scripts: http://people.freebsd.org/~gonzo/arm/rpi/freebsd-pi-r243778.img.gz > Are there any > docs on ubldr in general? (Right now I'm skipping ubldr and using > u-boot's DHCP command to load the kernel.) No, there are BSDCan slides by raj@ but as far as I know that's the only = bit of=20 documentation for ubldr. = http://www.bsdcan.org/2008/schedule/attachments/49_2008_uboot_freebsd.pdf > My RPi comes up with a random ethernet mac address on every boot, but > when I look at the driver code it seems that there should be an = address > stored in an eeprom. Do I have to program that myself? SMSC might or might not have EEPROM. The one in RPI does not have EEPROM so it's driver responsibility to set MAC address. There are = two options: get it from FDT blob or generate random. On Raspberry Pi it = works like this: firmware loads FDT blob at fixed address, fixes up board-specific info = like memory sizes, MAC address, board serial/revision. Then it loads u-boot, u-boot loads = ubldr, ubldr generates kernel meta-data, loads kernel and passes control to the = kernel.=20 Kernel gets FDT blob from meta-data and uses it to determine MAC = address. In order to make ubldr recognize FDT blob you'll need "fdt addr 0x100" = in /boot/loader.rc either on SD card FFS partition or on your NFS root.=20 >=20 > When I try to use an nfs-mounted root I get "Mounting from > nfs:172.22.42.240:/rpi failed with error 19." but if I mount root from > the sdcard then after it gets to multiuser mode I can manually = nfs-mount > the same directory. Has anybody got an nfs-mounted root working? This is most likely due to NFS version mismatch. We have nfs and = oldnfs for NFSv4 and NFSv3. I have working NFS root for raspberry pi. My = kernel config: options NFSCL #Network Filesystem Client=20 options NFS_ROOT #NFS usable as /, requires = NFSCLIENT options BOOTP_NFSROOT options BOOTP_COMPAT options BOOTP options BOOTP_NFSV3 options BOOTP_WIRED_TO=3Due0 I use FreeBSD 9.0 as NFS server.=20 From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 20:45:37 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DFA30F3C for ; Tue, 25 Dec 2012 20:45:37 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) by mx1.freebsd.org (Postfix) with ESMTP id A65928FC0A for ; Tue, 25 Dec 2012 20:45:37 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 7515939FA3; Wed, 26 Dec 2012 05:45:35 +0900 (JST) Received: from artemis (unknown [172.18.0.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id 5DE1C39D5E; Wed, 26 Dec 2012 05:45:35 +0900 (JST) Message-ID: <6D45D86A41B74B61ACC401F7B6C9E59F@ad.peach.ne.jp> From: "Daisuke Aoyama" To: "Ian Lepore" , References: <1356466883.1144.8.camel@revolution.hippie.lan> In-Reply-To: <1356466883.1144.8.camel@revolution.hippie.lan> Subject: Re: Raspberry Pi questions Date: Wed, 26 Dec 2012 05:45:31 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 20:45:37 -0000 > My RPi comes up with a random ethernet mac address on every boot, but > when I look at the driver code it seems that there should be an address > stored in an eeprom. Do I have to program that myself? Sorry, I forgot WITH_FDT option. You can build correct kernel by: # make buildkernel KERNCONF=RPI-B-test9 WITH_FDT=yes The mac address is provided by FDT. -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 20:51:26 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B1E41CF for ; Tue, 25 Dec 2012 20:51:26 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id B740F8FC0C for ; Tue, 25 Dec 2012 20:51:25 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.1.67]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TnbT8-0005TP-Oq; Tue, 25 Dec 2012 12:51:24 -0800 Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: Oleksandr Tymoshenko X-Priority: 3 In-Reply-To: Date: Tue, 25 Dec 2012 12:51:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Daisuke Aoyama X-Mailer: Apple Mail (2.1499) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2012-12-24, at 4:34 PM, Daisuke Aoyama wrote: > I've updated FreeBSD clang world for RPI based on svn r244663. > (To save working time, drop EABI patch.) > > Now clang is 3.2 final. This version includes complete source tree of r244663. > But the patch is not applied. You must apply the patch manually. > This version has been confirmed that the kernel can be compiled by self and booting from it. > > You can get the pre-build image from my archives: > > http://www.peach.ne.jp/archives/rpi/ > (At this time, freebsd-pi-clang-20121225.img.gz is the latest version.) > > Download and decompress it, then write it to SD. This image requires SD 4GB or more. > I'm using as headless server. So, you need a serial console for seeing the boot log. > If you need to change the value on it, please mount the second partition (e.g. /dev/da0s2a). > If you want the video out, please remove the line of "set console=comconsole" in /boot/loader.rc. > > Using config is here: > http://www.peach.ne.jp/archives/rpi/config/RPI-B-test9 > > Source(diff) and pacth is here: > http://www.peach.ne.jp/archives/rpi/patch/ [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 20:51:26 -0000 On 2012-12-24, at 4:34 PM, Daisuke Aoyama wrote: > I've updated FreeBSD clang world for RPI based on svn r244663. > (To save working time, drop EABI patch.) >=20 > Now clang is 3.2 final. This version includes complete source tree of = r244663. > But the patch is not applied. You must apply the patch manually. > This version has been confirmed that the kernel can be compiled by = self and booting from it. >=20 > You can get the pre-build image from my archives: >=20 > http://www.peach.ne.jp/archives/rpi/ > (At this time, freebsd-pi-clang-20121225.img.gz is the latest = version.) >=20 > Download and decompress it, then write it to SD. This image requires = SD 4GB or more. > I'm using as headless server. So, you need a serial console for seeing = the boot log. > If you need to change the value on it, please mount the second = partition (e.g. /dev/da0s2a). > If you want the video out, please remove the line of "set = console=3Dcomconsole" in /boot/loader.rc. >=20 > Using config is here: > http://www.peach.ne.jp/archives/rpi/config/RPI-B-test9 >=20 > Source(diff) and pacth is here: > http://www.peach.ne.jp/archives/rpi/patch/ Thanks! I'll integrate timer-related bits later this week, good catch!=20= spinlock_enter and spinlock_exit are intended to be used only in spinlock code and should be replaced by intr_disable/intr_restore there, = AFAIU,=20 The other bit I'm considering for merge is armv6 instruction for = managing interrupts/status. PTE sync - related part, Im not sure it's strictly required. We use WT = caches for page tables so we should be OK without implicit sync operations for them. I hope = somebody=20 more clueful can confirm/disprove this.=20 =20 From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 23:06:48 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C743EC5 for ; Tue, 25 Dec 2012 23:06:48 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id BAF938FC0A for ; Tue, 25 Dec 2012 23:06:47 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBPN6eJE000606 for ; Tue, 25 Dec 2012 16:06:41 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBPN6IEe072467; Tue, 25 Dec 2012 16:06:18 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Raspberry Pi questions From: Ian Lepore To: Oleksandr Tymoshenko In-Reply-To: <08125E73-C46A-4DDF-BFD8-59D5B86136B8@bluezbox.com> References: <1356466883.1144.8.camel@revolution.hippie.lan> <08125E73-C46A-4DDF-BFD8-59D5B86136B8@bluezbox.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Dec 2012 16:06:18 -0700 Message-ID: <1356476778.1144.20.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 23:06:48 -0000 On Tue, 2012-12-25 at 12:37 -0800, Oleksandr Tymoshenko wrote: > On 2012-12-25, at 12:21 PM, Ian Lepore wrote: > > > I got my RPi running this morning, more or less. I used the boot > > partition from the latest image at http://www.peach.ne.jp/archives/rpi/ > > but I'm loading my own custom built kernel and world. I have a few > > questions... > > > > Can I get ubldr to load a kernel using tftp, bootp, etc? > > Yes. ubldr checks U-Boot devices (SD and net), then tries to locate > FFS partition on SD card and if fails - falls back to NFS/bootp. You can fetch > my image, boot partition there contains ubldr, FDT blob, config.txt and boot scripts: > > http://people.freebsd.org/~gonzo/arm/rpi/freebsd-pi-r243778.img.gz This is so close to working. In u-boot I have an env var "usbethaddr" which contains what seems to be the right address (it's an RPi foundation oui). But still when booting via ubldr it generates a random address every time, apparently because smsc_fdt_find_mac() always returns zeroes (I added a printf to the smsc driver). If I hard-code the right mac address in the smsc driver I get all the way to multiuser mode. Also, when ubldr launches it immediately begins to load the kernel from sdcard before I can stop it. I have to wait for that to finish and then do "unload" then load the kernel from net0:. Can I create a file that contains different defaults or something? The amount of ram reported by kernel startup is only 128mb. u-boot says 384mb, that's not right either. U-Boot 2013.01-rc1-g6709570-dirty (Nov 30 2012 - 19:09:28) DRAM: 384 MiB WARNING: Caches not enabled MMC: bcm2835_sdhci: 0 Using default environment In: serial Out: lcd Err: lcd mbox: Timeout waiting for response bcm2835: Could not set USB power state Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 U-Boot> usb start (Re)start USB... USB0: Core Release: 2.80a scanning bus 0 for devices... 4 USB Device(s) found scanning usb for storage devices... Error condition at line 748: ACK 1 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found U-Boot> printenv arch=arm baudrate=115200 board=rpi_b board_name=rpi_b bootcmd=if mmc rescan ${mmcdev}; then if run loadbootenv; then run importbootenv; fi; if run loadbootscript; then run bootscript; fi; fi bootdelay=3 bootenv=uEnv.txt bootscript=echo Running bootscript from mmc${mmcdev} ...; source ${loadaddr} cpu=arm1176 ethact=sms0 importbootenv=echo Importing environment from mmc ...; env import -t $loadaddr $filesize loadaddr=0x00200000 loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv} loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr mmcdev=0 soc=bcm2835 stderr=serial,lcd stdin=serial stdout=serial,lcd usbethaddr=b8:27:eb:33:7c:02 vendor=raspberrypi Environment size: 706/16380 bytes U-Boot> boot reading uEnv.txt reading boot.scr 137 bytes read in 24411 ms (0 Bytes/s) Running bootscript from mmc0 ... ## Executing script at 00200000 reading ubldr 242834 bytes read in 77687 ms (2.9 KiB/s) ## Starting application at 0x02000054 ... Consoles: U-Boot console Compatible API signature found @17b662a8 Number of U-Boot devices: 3 FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@bsdbox, Sun Dec 2 13:49:40 PST 2012) DRAM: 384MB Device: disk - /boot/kernel/kernel data=0x3f2038+0x1f620 syms=[0x4+0x7dd50+0x4+0x5fb94] Hit [Enter] to boot immediately, or any other key for command prompt. Type '?' for a list of commands, 'help' for more detailed help. loader> unload loader> load net0:/boot/kernel/kernel Waiting for Ethernet connection... done. Waiting for Ethernet connection... done. net0:/boot/kernel/kernel data=0x38fcf8+0x20544 syms=[0x4+0x7e000+0x4+0x60b52] loader> boot fdt_start: 0x00468B50 Kernel entry at 0x100100... Kernel args: (null) KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #32 r244563M: Tue Dec 25 15:46:23 MST 2012 ilepore@revolution.hippie.lan:/local/build/staging/freebsd/rpi10/obj/arm.armv6/local/build/staging/freebsd/rpi10/src/sys/RPI-B-serial arm CPU: ARM1176JZ-S rev 7 (ARM11J core) Supported features: ARM_ISA THUMB2 JAZELLE ARMv4 Security_Ext WB enabled LABT branch prediction enabled 16KB/32B 4-way instruction cache 16KB/32B 4-way write-back-locking-C data cache real memory = 134217728 (128 MB) avail memory = 124751872 (118 MB) random device not loaded; using insecure entropy simplebus0: mem 0xf2000000-0xf2ffffff on fdtbus0 intc0: mem 0xf200b200-0xf200b3ff on simplebus0 systimer0: mem 0xf2003000-0xf2003fff irq 8,9,10,11 on simplebus0 Event timer "BCM2835 Event Timer 3" frequency 1000000 Hz quality 1000 Timecounter "BCM2835 Timecounter" frequency 1000000 Hz quality 1000 sdhci_bcm0: mem 0xf2300000-0xf23000ff irq 70 on simplebus0 bcm_sdhci_attach(): SDHCI frequency: 50MHz mmc0: on sdhci_bcm0 mbox0: mem 0xf200b880-0xf200b8bf irq 1 on simplebus0 mbox0: [GIANT-LOCKED] bcmwd0: mem 0xf210001c-0xf2100027 on simplebus0 gpio0: mem 0xf2200000-0xf22000af irq 57,59,58,60 on simplebus0 gpio0: read-only pins: 46,47,48,49,50,51,52,53. gpio0: reserved pins: 48,49,50,51,52,53. gpioc0: on gpio0 gpiobus0: on gpio0 uart0: mem 0xf2201000-0xf2201fff irq 65 on simplebus0 uart0: console (115200,n,8,1) dwcotg0: mem 0xf2980000-0xf299ffff irq 17 on simplebus0 usbus0 on dwcotg0 Timecounters tick every 10.000 msec usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered mmcsd0: 1886MB at mmc0 25.0MHz/4bit/65535-block bootpc_init: wired to interface 'ue0' ugen0.2: at usbus0 uhub1: on usbus0 uhub1: MTT enabled uhub1: 3 ports with 2 removable, self powered ugen0.3: at usbus0 smsc0: on usbus0 getting fdt mac addr, err=0 smsc0: got mac address 00:00:00:00:00:00 smsc0: setting mac address to 06:f3:7e:bb:29:fc smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: 06:f3:7e:bb:29:fc smsc0: setting mac address to 06:f3:7e:bb:29:fc smsc0: chip 0xec00, rev. 0002 ue0: link state changed to DOWN Sending DHCP Discover packet from interface ue0 (06:f3:7e:bb:29:fc) ue0: link state changed to UP ugen0.4: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4101 umass0:0:0:-1: Attached to scbus0 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 122104MB (250069680 512 byte sectors: 255H 63S/T 15566C) Received DHCP Offer packet on ue0 from 0.0.0.0 (accepted) (no root path) Sending DHCP Request packet from interface ue0 (06:f3:7e:bb:29:fc) Received DHCP Ack packet on ue0 from 0.0.0.0 (accepted) (no root path) Received DHCP Ack packet on ue0 from 0.0.0.0 (accepted) (no root path) -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 23:20:22 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2260EEA for ; Tue, 25 Dec 2012 23:20:22 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id E85C58FC0C for ; Tue, 25 Dec 2012 23:20:21 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id qBPNKEsm070969; Tue, 25 Dec 2012 23:20:14 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id wgn4sb6fvjcr6pmuykezcddhv6; Tue, 25 Dec 2012 23:20:14 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Raspberry Pi EABI test image Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20121224183119.73868caa@ivory.wynn.com> Date: Tue, 25 Dec 2012 15:20:11 -0800 Content-Transfer-Encoding: 7bit Message-Id: <850B9B76-0FBC-4711-B354-FC2013E2912B@kientzle.com> References: <20121224103825.086cd584@fubar.geek.nz> <50D79C5C.1000704@m5p.com> <20121224135512.30c84b7c@fubar.geek.nz> <50D87B88.6080504@m5p.com> <1356371614.1129.114.camel@revolution.hippie.lan> <9727806D-8356-4A98-B609-9B86BC42795F@bsdimp.com> <20121224181829.7a743510@ivory.wynn.com> <20121224183119.73868caa@ivory.wynn.com> To: Brett Wynkoop X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 23:20:22 -0000 On Dec 24, 2012, at 3:31 PM, Brett Wynkoop wrote: > On Mon, 24 Dec 2012 18:18:29 -0500 > Brett Wynkoop wrote: > >> On Mon, 24 Dec 2012 12:13:42 -0700 >> Warner Losh wrote: >> >>> Or alternatively, you can look at the early startup state of the ue0 >>> device and look for subtle differences between it and other >>> interfaces. For a short period of time it may throw some weird >>> error that dhclient isn't coping with. >>> >> >> I am not sure but the above might be a red herring. My interface on my >> BEAGLEBONE is cpsw0 and has the exact same issue. >> >> -Brett > Greeting- > > Just changed my devd_enable to yes and all works as I expected with > DHCP. My rc.conf set up with Tim's script had it off, > but /etc/defaults/rc.conf had it on. > > Tim if you are on the list you might want to change that in the script. Done. I had turned it off in a frenzy of "turn off everything I possibly can" in order to get things to run better, but it sounds like devd is pretty essential. Tim From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 23:21:26 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1EBAC11B for ; Tue, 25 Dec 2012 23:21:26 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id A07018FC0C for ; Tue, 25 Dec 2012 23:21:25 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.1.67]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TndoI-0006cd-6S; Tue, 25 Dec 2012 15:21:24 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Raspberry Pi questions From: Oleksandr Tymoshenko In-Reply-To: <1356476778.1144.20.camel@revolution.hippie.lan> Date: Tue, 25 Dec 2012 15:21:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0F630E03-7A0C-4D56-A580-C7A9ABD2CB0C@bluezbox.com> References: <1356466883.1144.8.camel@revolution.hippie.lan> <08125E73-C46A-4DDF-BFD8-59D5B86136B8@bluezbox.com> <1356476778.1144.20.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1499) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2012-12-25, at 3:06 PM, Ian Lepore wrote: > On Tue, 2012-12-25 at 12:37 -0800, Oleksandr Tymoshenko wrote: >> On 2012-12-25, at 12:21 PM, Ian Lepore wrote: >> >>> I got my RPi running this morning, more or less. I used the boot >>> partition from the latest image at http://www.peach.ne.jp/archives/rpi/ >>> but I'm loading my own custom built kernel and world. I have a few >>> questions... >>> >>> Can I get ubldr to load a kernel using tftp, bootp, etc? >> >> Yes. ubldr checks U-Boot devices (SD and net), then tries to locate >> FFS partition on SD card and if fails - falls back to NFS/bootp. You can fetch >> my image, boot partition there contains ubldr, FDT blob, config.txt and boot scripts: >> >> http://people.freebsd.org/~gonzo/arm/rpi/freebsd-pi-r243778.img.gz > > This is so close to working. In u-boot I have an env var "usbethaddr" > which contains what seems to be the right address (it's an RPi > foundation oui). But still when booting via ubldr it generates a random > address every time, apparently because smsc_fdt_find_mac() always > returns zeroes (I added a printf to the smsc driver). If I hard-code > the right mac address in the smsc driver I get all the way to multiuser > mode. > > Also, when ubldr launches it immediately begins to load the kernel from > sdcard before I can stop it. I have to wait for that to finish and then > do "unload" then load the kernel from net0:. Can I create a file that > contains different defaults or something? > > The amount of ram reported by kernel startup is only 128mb. u-boot says > 384mb, that's not right either. > [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 23:21:26 -0000 On 2012-12-25, at 3:06 PM, Ian Lepore = wrote: > On Tue, 2012-12-25 at 12:37 -0800, Oleksandr Tymoshenko wrote: >> On 2012-12-25, at 12:21 PM, Ian Lepore = wrote: >>=20 >>> I got my RPi running this morning, more or less. I used the boot >>> partition from the latest image at = http://www.peach.ne.jp/archives/rpi/ >>> but I'm loading my own custom built kernel and world. I have a few >>> questions... >>>=20 >>> Can I get ubldr to load a kernel using tftp, bootp, etc? =20 >>=20 >> Yes. ubldr checks U-Boot devices (SD and net), then tries to = locate >> FFS partition on SD card and if fails - falls back to NFS/bootp. You = can fetch >> my image, boot partition there contains ubldr, FDT blob, config.txt = and boot scripts: >>=20 >> http://people.freebsd.org/~gonzo/arm/rpi/freebsd-pi-r243778.img.gz >=20 > This is so close to working. In u-boot I have an env var "usbethaddr" > which contains what seems to be the right address (it's an RPi > foundation oui). But still when booting via ubldr it generates a = random > address every time, apparently because smsc_fdt_find_mac() always > returns zeroes (I added a printf to the smsc driver). If I hard-code > the right mac address in the smsc driver I get all the way to = multiuser > mode. >=20 > Also, when ubldr launches it immediately begins to load the kernel = from > sdcard before I can stop it. I have to wait for that to finish and = then > do "unload" then load the kernel from net0:. Can I create a file that > contains different defaults or something? >=20 > The amount of ram reported by kernel startup is only 128mb. u-boot = says > 384mb, that's not right either. >=20 All this means that kernel uses built-int dtb (I think at some point we = should just remove built-in DTB), not the one provided by u-boot. In order to make = ubldr aware of external dub you need to pass "fdt addr 0x100" command to it.=20= Also I don't know about how to set priorities for kernels :( So what I = did was: - Delete /boot/loader.rc and /boot/kernel/kernel on SD card. It makes = ubldr=20 go to NFS server for these files. Or you can just nuke whole = partition - Add "fdt addr 0x100" to /boot/loader.rc in NFS root - Deploy my experimental kernel to /boot/kernel/kernel in NFS root=20 Also make sure that DTB is populated by firmware. Issue following = commands in U-Boot prompt: fdt addr 0x100 fdt print=20 As a result you should get proper DTS with memory regions, MAC address = and board serial.=20 From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 23:55:28 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC7F05E0 for ; Tue, 25 Dec 2012 23:55:28 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 93BF38FC0A for ; Tue, 25 Dec 2012 23:55:28 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBPNtRUa001062 for ; Tue, 25 Dec 2012 16:55:27 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBPNt5Tc072532; Tue, 25 Dec 2012 16:55:05 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Raspberry Pi questions From: Ian Lepore To: Oleksandr Tymoshenko In-Reply-To: <0F630E03-7A0C-4D56-A580-C7A9ABD2CB0C@bluezbox.com> References: <1356466883.1144.8.camel@revolution.hippie.lan> <08125E73-C46A-4DDF-BFD8-59D5B86136B8@bluezbox.com> <1356476778.1144.20.camel@revolution.hippie.lan> <0F630E03-7A0C-4D56-A580-C7A9ABD2CB0C@bluezbox.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Dec 2012 16:55:05 -0700 Message-ID: <1356479705.1144.23.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 23:55:29 -0000 On Tue, 2012-12-25 at 15:21 -0800, Oleksandr Tymoshenko wrote: > On 2012-12-25, at 3:06 PM, Ian Lepore wrote: > > > On Tue, 2012-12-25 at 12:37 -0800, Oleksandr Tymoshenko wrote: > >> On 2012-12-25, at 12:21 PM, Ian Lepore wrote: > >> > >>> I got my RPi running this morning, more or less. I used the boot > >>> partition from the latest image at http://www.peach.ne.jp/archives/rpi/ > >>> but I'm loading my own custom built kernel and world. I have a few > >>> questions... > >>> > >>> Can I get ubldr to load a kernel using tftp, bootp, etc? > >> > >> Yes. ubldr checks U-Boot devices (SD and net), then tries to locate > >> FFS partition on SD card and if fails - falls back to NFS/bootp. You can fetch > >> my image, boot partition there contains ubldr, FDT blob, config.txt and boot scripts: > >> > >> http://people.freebsd.org/~gonzo/arm/rpi/freebsd-pi-r243778.img.gz > > > > This is so close to working. In u-boot I have an env var "usbethaddr" > > which contains what seems to be the right address (it's an RPi > > foundation oui). But still when booting via ubldr it generates a random > > address every time, apparently because smsc_fdt_find_mac() always > > returns zeroes (I added a printf to the smsc driver). If I hard-code > > the right mac address in the smsc driver I get all the way to multiuser > > mode. > > > > Also, when ubldr launches it immediately begins to load the kernel from > > sdcard before I can stop it. I have to wait for that to finish and then > > do "unload" then load the kernel from net0:. Can I create a file that > > contains different defaults or something? > > > > The amount of ram reported by kernel startup is only 128mb. u-boot says > > 384mb, that's not right either. > > > > All this means that kernel uses built-int dtb (I think at some point we should just > remove built-in DTB), not the one provided by u-boot. That was it exactly. My kernel config is doing including the standard RPI-B and then adding a few options of my own, and I didn't notice it had static dtb stuff in it. It's all working now, thanks! -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Dec 26 05:58:16 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 851B781A for ; Wed, 26 Dec 2012 05:58:16 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 5708C8FC0C for ; Wed, 26 Dec 2012 05:58:15 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id qBQ5vf8b073039; Wed, 26 Dec 2012 05:57:41 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id uetj4cmsspnbkdxx6xh73epgga; Wed, 26 Dec 2012 05:57:41 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Raspberry Pi questions Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <1356479705.1144.23.camel@revolution.hippie.lan> Date: Tue, 25 Dec 2012 21:57:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1356466883.1144.8.camel@revolution.hippie.lan> <08125E73-C46A-4DDF-BFD8-59D5B86136B8@bluezbox.com> <1356476778.1144.20.camel@revolution.hippie.lan> <0F630E03-7A0C-4D56-A580-C7A9ABD2CB0C@bluezbox.com> <1356479705.1144.23.camel@revolution.hippie.lan> To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 05:58:16 -0000 On Dec 25, 2012, at 3:55 PM, Ian Lepore wrote: >>>=20 >>> This is so close to working. I know what you mean=85. I've almost got my scripts building bootable RPi images now using the new boot sequence that Oleksandr's been working on. There's clearly been a huge amount of progress: memory config now works, the HDMI video console works. But I am still having a few inexplicable issues: 1) Building U-Boot. I'm trying to build U-Boot from the sources at github.com/gonzoua/u-boot-pi.git They build but the result won't boot. Can anyone point me to the U-Boot sources that do work? For now, I'm using the binary blob that Oleksandr built. 2) Random failure to mount root. This is weird. If I insert the SD card into my Mac and open the MSDOS partition, then eject, the card will boot (sort of, see below). Otherwise, the kernel can't mount root. I'm entirely baffled. 3) Doesn't quite make it to multi-user. When root does mount, it goes through the init scripts (generates SSH keys, etc), then prints the date and time and stops. I know the kernel is running since I get insert/removal messages if I plug/unplug a keyboard, but getty never seems to launch on either HDMI or serial console. Tim From owner-freebsd-arm@FreeBSD.ORG Wed Dec 26 06:07:53 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC3308A9 for ; Wed, 26 Dec 2012 06:07:53 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 65ABA8FC13 for ; Wed, 26 Dec 2012 06:07:53 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.1.67]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Tnk9a-0006wv-JB; Tue, 25 Dec 2012 22:07:52 -0800 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Raspberry Pi questions From: Oleksandr Tymoshenko In-Reply-To: Date: Tue, 25 Dec 2012 22:07:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2E70584E-598E-4D3A-9B2B-6E5FB19A506C@bluezbox.com> References: <1356466883.1144.8.camel@revolution.hippie.lan> <08125E73-C46A-4DDF-BFD8-59D5B86136B8@bluezbox.com> <1356476778.1144.20.camel@revolution.hippie.lan> <0F630E03-7A0C-4D56-A580-C7A9ABD2CB0C@bluezbox.com> <1356479705.1144.23.camel@revolution.hippie.lan> To: Tim Kientzle X-Mailer: Apple Mail (2.1499) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2012-12-25, at 9:57 PM, Tim Kientzle wrote: > On Dec 25, 2012, at 3:55 PM, Ian Lepore wrote: >>>> >>>> This is so close to working. > > I know what you mean…. > > I've almost got my scripts building bootable RPi images now using > the new boot sequence that Oleksandr's been working on. > > There's clearly been a huge amount of progress: memory config > now works, the HDMI video console works. > > But I am still having a few inexplicable issues: > > 1) Building U-Boot. > > I'm trying to build U-Boot from the sources at > github.com/gonzoua/u-boot-pi.git > They build but the result won't boot. Can anyone > point me to the U-Boot sources that do work? For > now, I'm using the binary blob that Oleksandr built. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 06:07:53 -0000 On 2012-12-25, at 9:57 PM, Tim Kientzle wrote: > On Dec 25, 2012, at 3:55 PM, Ian Lepore wrote: >>>>=20 >>>> This is so close to working. >=20 > I know what you mean=85. >=20 > I've almost got my scripts building bootable RPi images now using > the new boot sequence that Oleksandr's been working on. >=20 > There's clearly been a huge amount of progress: memory config > now works, the HDMI video console works. >=20 > But I am still having a few inexplicable issues: >=20 > 1) Building U-Boot. >=20 > I'm trying to build U-Boot from the sources at > github.com/gonzoua/u-boot-pi.git > They build but the result won't boot. Can anyone > point me to the U-Boot sources that do work? For > now, I'm using the binary blob that Oleksandr built. u-boot.bin should be post-processed by this tool: https://github.com/raspberrypi/tools/tree/master/mkimage The rest file is proper binary to be booted by Raspberry Pi firmware. >=20 > 2) Random failure to mount root. >=20 > This is weird. If I insert the SD card into my Mac and open > the MSDOS partition, then eject, the card will boot (sort of, > see below). Otherwise, the kernel can't mount root. I'm > entirely baffled. Never heard of it before :( could you provide full dmesg for failed=20= mountroot? >=20 > 3) Doesn't quite make it to multi-user. >=20 > When root does mount, it goes through the init > scripts (generates SSH keys, etc), then prints the > date and time and stops. I know the kernel is running > since I get insert/removal messages if I plug/unplug a > keyboard, but getty never seems to launch on either > HDMI or serial console. Daisuke Aoyama posted patch that I believe should fix this problem. The = root cause for it is that timer setup is interrupted and as a result - timer = never gets fired. So system stuck waiting for interrupt. If you boot with serial = console - pressing any key will generate UART interrupt and system will go out of=20= freeze. I'm planning on merging this patch soon.=20= From owner-freebsd-arm@FreeBSD.ORG Wed Dec 26 09:34:43 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64A63564 for ; Wed, 26 Dec 2012 09:34:43 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) by mx1.freebsd.org (Postfix) with ESMTP id C3F1C8FC0A for ; Wed, 26 Dec 2012 09:34:42 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 800E539FA3; Wed, 26 Dec 2012 18:34:34 +0900 (JST) Received: from artemis (unknown [172.18.0.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id 6B42939D5E; Wed, 26 Dec 2012 18:34:34 +0900 (JST) Message-ID: <68E7D970E6D2475C8061DB45301103AF@ad.peach.ne.jp> From: "Daisuke Aoyama" To: "Oleksandr Tymoshenko" References: In-Reply-To: Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Date: Wed, 26 Dec 2012 18:34:30 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 09:34:43 -0000 >Thanks! I'll integrate timer-related bits later this week, good catch! >spinlock_enter and spinlock_exit are intended to be used only in >spinlock code and should be replaced by intr_disable/intr_restore there, >AFAIU, Yes, you are right. It should not divide/re-entry. It seems the kernel is very stable than any previous! >The other bit I'm considering for merge is armv6 instruction for managing >interrupts/status. Probably, it's unnecessary. It's my cut and try code. RPI is my first ARM architecture for kernel side. Of course, I didn't know about ARM assembler until I got RPI. >PTE sync - related part, Im not sure it's strictly required. We use WT >caches for page tables >so we should be OK without implicit sync operations for them. I hope >somebody >more clueful can confirm/disprove this. It seems CF_ICACHE_SYNC solve PTE problem. Please see arm/swtch.S in the patch. However, still USB LAN is unstable :( Here is current using patch: http://www.peach.ne.jp/archives/rpi/patch/src-244663-20121226.patch.gz If you already have clang world, you can use pre-build version: http://www.peach.ne.jp/archives/rpi/test/kernel-20121226.gz or apply patch and rebuild the kernel yourself. # fetch -o /usr http://www.peach.ne.jp/archives/rpi/patch/src-244663-20121226.patch.gz # cd /usr/src # gzcat /usr/src-244663-20121226.patch.gz | patch # make buildkernel KERNCONF=RPI-B-test9 WITH_FDT=yes Don't forget to add NO_WERROR= and WERROR= to /etc/make.conf if you use clang. If you already applied previous patch, you can remove it by: # cd /usr/src # gzcat /usr/src-244663-20121225.patch.gz | patch -R then, apply new patch. Thanks. -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Wed Dec 26 15:03:40 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD6B04D5 for ; Wed, 26 Dec 2012 15:03:40 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6A54B8FC0A for ; Wed, 26 Dec 2012 15:03:40 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBQF3d4S011431 for ; Wed, 26 Dec 2012 08:03:39 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBQF3HVt074171; Wed, 26 Dec 2012 08:03:17 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Raspberry Pi questions From: Ian Lepore To: Tim Kientzle In-Reply-To: References: <1356466883.1144.8.camel@revolution.hippie.lan> <08125E73-C46A-4DDF-BFD8-59D5B86136B8@bluezbox.com> <1356476778.1144.20.camel@revolution.hippie.lan> <0F630E03-7A0C-4D56-A580-C7A9ABD2CB0C@bluezbox.com> <1356479705.1144.23.camel@revolution.hippie.lan> Content-Type: text/plain; charset="windows-1251" Date: Wed, 26 Dec 2012 08:03:17 -0700 Message-ID: <1356534197.1144.38.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 15:03:40 -0000 On Tue, 2012-12-25 at 21:57 -0800, Tim Kientzle wrote: > On Dec 25, 2012, at 3:55 PM, Ian Lepore wrote: > >>> > >>> This is so close to working. > > I know what you mean…. > > I've almost got my scripts building bootable RPi images now using > the new boot sequence that Oleksandr's been working on. > > There's clearly been a huge amount of progress: memory config > now works, the HDMI video console works. > > But I am still having a few inexplicable issues: > > 1) Building U-Boot. > > I'm trying to build U-Boot from the sources at > github.com/gonzoua/u-boot-pi.git > They build but the result won't boot. Can anyone > point me to the U-Boot sources that do work? For > now, I'm using the binary blob that Oleksandr built. > I'm using his stuff too now. I had a look at u-boot and ubldr in -current and it seemed that they must not be the latest stuff. I'm guessing the latest is on a private branch somewhere. What I'm supposed to be doing this week is writing a new bootloader for a new board at work, not playing with my new RPi (but hey, I'm "working on bootloader stuff," right?). > 2) Random failure to mount root. > > This is weird. If I insert the SD card into my Mac and open > the MSDOS partition, then eject, the card will boot (sort of, > see below). Otherwise, the kernel can't mount root. I'm > entirely baffled. > I had something like this happen several times yesterday. Most of the time it boots fine, sometimes it fails to mount root from the sdcard, but then it works on a reboot. I also saw the mmcsd0 driver ident line say the bus was running at 50mhz several times, and I'm pretty sure I wasn't using any SDHC cards, but that also wasn't the problem I was pursuing so I didn't pay close attention. Of course, that doesn't seem to intersect with what you describe very much at all, unless touching the card on the Mac wasn't really a cure, it was just some misleading coincidence going on. > 3) Doesn't quite make it to multi-user. > > When root does mount, it goes through the init > scripts (generates SSH keys, etc), then prints the > date and time and stops. I know the kernel is running > since I get insert/removal messages if I plug/unplug a > keyboard, but getty never seems to launch on either > HDMI or serial console. Whenever I've seen these symptoms in the past few years it has come down to init getting hung due to trying to open serial tty devices mentioned in the ttys file for which there is no hardware. For example, just setting up a serial console with a getty on it on an x86 system, then disabling that uart in the bios, will cause this. I keep meaning to dig into init and find the root cause and make it more robust against this sort of failure. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Dec 26 15:17:28 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 216D4E94 for ; Wed, 26 Dec 2012 15:17:28 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 7B5C78FC14 for ; Wed, 26 Dec 2012 15:17:27 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBQFHQL1011545 for ; Wed, 26 Dec 2012 08:17:26 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBQFH4n2074205; Wed, 26 Dec 2012 08:17:04 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Raspberry Pi questions From: Ian Lepore To: Oleksandr Tymoshenko In-Reply-To: <2E70584E-598E-4D3A-9B2B-6E5FB19A506C@bluezbox.com> References: <1356466883.1144.8.camel@revolution.hippie.lan> <08125E73-C46A-4DDF-BFD8-59D5B86136B8@bluezbox.com> <1356476778.1144.20.camel@revolution.hippie.lan> <0F630E03-7A0C-4D56-A580-C7A9ABD2CB0C@bluezbox.com> <1356479705.1144.23.camel@revolution.hippie.lan> <2E70584E-598E-4D3A-9B2B-6E5FB19A506C@bluezbox.com> Content-Type: text/plain; charset="windows-1251" Date: Wed, 26 Dec 2012 08:17:04 -0700 Message-ID: <1356535024.1144.46.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: Tim Kientzle , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 15:17:28 -0000 On Tue, 2012-12-25 at 22:07 -0800, Oleksandr Tymoshenko wrote: > On 2012-12-25, at 9:57 PM, Tim Kientzle wrote: > > > On Dec 25, 2012, at 3:55 PM, Ian Lepore wrote: > >>>> > >>>> This is so close to working. > > > > I know what you mean…. > > > > I've almost got my scripts building bootable RPi images now using > > the new boot sequence that Oleksandr's been working on. > > > > There's clearly been a huge amount of progress: memory config > > now works, the HDMI video console works. > > > > But I am still having a few inexplicable issues: > > > > 1) Building U-Boot. > > > > I'm trying to build U-Boot from the sources at > > github.com/gonzoua/u-boot-pi.git > > They build but the result won't boot. Can anyone > > point me to the U-Boot sources that do work? For > > now, I'm using the binary blob that Oleksandr built. > > u-boot.bin should be post-processed by this tool: > https://github.com/raspberrypi/tools/tree/master/mkimage > > The rest file is proper binary to be booted by Raspberry Pi firmware. > > > > > 2) Random failure to mount root. > > > > This is weird. If I insert the SD card into my Mac and open > > the MSDOS partition, then eject, the card will boot (sort of, > > see below). Otherwise, the kernel can't mount root. I'm > > entirely baffled. > Never heard of it before :( could you provide full dmesg for failed > mountroot? > > > > > 3) Doesn't quite make it to multi-user. > > > > When root does mount, it goes through the init > > scripts (generates SSH keys, etc), then prints the > > date and time and stops. I know the kernel is running > > since I get insert/removal messages if I plug/unplug a > > keyboard, but getty never seems to launch on either > > HDMI or serial console. > > Daisuke Aoyama posted patch that I believe should fix this problem. The root > cause for it is that timer setup is interrupted and as a result - timer never gets > fired. So system stuck waiting for interrupt. If you boot with serial console - > pressing any key will generate UART interrupt and system will go out of > freeze. I'm planning on merging this patch soon. Oh that's interesting. I guess I haven't seen it because I only have a serial console, no keyboard and screen. I did notice however that timekeeping seems a bit marginal... I left a compile and portsnap fetch running overnight, and this morning my ssh sessions had closed on a broken pipe, but the RPi had not rebooted. I always use "ServerAliveInterval 60" in my ssh sessions, so they shouldn't normally timeout for inactivity. In syslog I found: Dec 26 04:55:29 rpi ntpd[9534]: ntpd 4.2.4p5-a (1) Dec 26 07:20:31 rpi sshd[689]: fatal: Write failed: Broken pipe Dec 26 07:20:31 rpi sshd[590]: fatal: Write failed: Broken pipe Dec 26 09:03:45 rpi ntpd[9535]: time reset +4294.767396 s The first ntpd line was when the machine last rebooted yesterday. In case you're wondering, the difference between the broken pipe messages and the clock step is 6194 seconds. It would be just too neat and tidy for it to be 4294. (On the other hand, the difference between 6194 and 4294 is exactly 31 minutes. I hate round-number coincidences.) -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Dec 26 15:17:37 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A756E98 for ; Wed, 26 Dec 2012 15:17:37 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from smtp.getmail.no (smtp.getmail.no [84.208.15.66]) by mx1.freebsd.org (Postfix) with ESMTP id 063798FC16 for ; Wed, 26 Dec 2012 15:17:36 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from get-mta-scan01.get.basefarm.net ([10.5.16.4]) by get-mta-out02.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0MFN00K75955QK70@get-mta-out02.get.basefarm.net> for freebsd-arm@FreeBSD.org; Wed, 26 Dec 2012 16:17:29 +0100 (MET) Received: from get-mta-scan01.get.basefarm.net (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id C0D0B179BC27_DB1509B for ; Wed, 26 Dec 2012 15:17:29 +0000 (GMT) Received: from kg-v2.kg4.no (cm-84.215.134.159.getinternet.no [84.215.134.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by get-mta-scan01.get.basefarm.net (Sophos Email Appliance) with ESMTPSA id A482017A09AC_DB1509F for ; Wed, 26 Dec 2012 15:17:29 +0000 (GMT) Date: Wed, 26 Dec 2012 16:17:29 +0100 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Subject: Re: Raspberry Pi EABI test image Message-id: <20121226161729.494633b8df6141c420fd868f@getmail.no> In-reply-to: <20121224103825.086cd584@fubar.geek.nz> References: <20121224103825.086cd584@fubar.geek.nz> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 15:17:37 -0000 I noticed another thing with the test image. If I run gpart, it reports like this: root@raspberry-pi# gpart show => 270582939648 33262150885572609 mmcsd0 MBR (12G) 270582939648 281401962266625 1 !12 [active] (0B) 281672545206273 4294967295 - free - (2T) 281676840173568 8725483759861761 2 freebsd (8.0G) 9007160600035329 24255260868476928 - free - () => 0 8725483759861761 mmcsd0s2 BSD (8.0G) 0 8725483759861761 1 freebsd-ufs (4.0G) The SD card I am using is 4 GB, so why does it report 8 and 12 gigs? -- Torfinn Ingolfsen From owner-freebsd-arm@FreeBSD.ORG Wed Dec 26 15:28:32 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4BE0837D for ; Wed, 26 Dec 2012 15:28:32 +0000 (UTC) (envelope-from dev@macdevshanghai.com) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by mx1.freebsd.org (Postfix) with ESMTP id E7FA48FC08 for ; Wed, 26 Dec 2012 15:28:31 +0000 (UTC) Received: by mail-vb0-f51.google.com with SMTP id fq11so9017903vbb.10 for ; Wed, 26 Dec 2012 07:28:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=LVa/JDJTostnpYZuzMQshLrAn9STX8tzC95C9hKOyB0=; b=bnPXqHOLXpE3csq5FJ3s5IdrvNsCJ+2NFIs9JSHL2m0AVz14Dp/gNFf4siu/MdsZFP 95S0YgSuG8S1dUv4XShJeWxucyntXybUEaSWFZ9paxccLwl0qv1ljmkCqxQTOnVSZOsu hJZ1iflBxcn2AVDFTCWL3bVLnJe7rm3lH7frliIAclr0ooDHpvDeTDUXgtH2eaaOwQeJ zPXfnjs9UbLvOfRYjg+sXFturGK1q4G/OyjmjFCrD46wATsj5LxL25kDQ2VWN0T3Ly7n 9TrmR4bKoxH+XoiWmqrLq2h+XEI+9B9LbLQIxNBgb47yGrOgrkC4AUZ45ukbu3vtZLwP cDXw== MIME-Version: 1.0 Received: by 10.52.27.244 with SMTP id w20mr37724602vdg.44.1356535704779; Wed, 26 Dec 2012 07:28:24 -0800 (PST) Received: by 10.58.161.167 with HTTP; Wed, 26 Dec 2012 07:28:24 -0800 (PST) X-Originating-IP: [101.228.106.104] In-Reply-To: <20121226161729.494633b8df6141c420fd868f@getmail.no> References: <20121224103825.086cd584@fubar.geek.nz> <20121226161729.494633b8df6141c420fd868f@getmail.no> Date: Wed, 26 Dec 2012 23:28:24 +0800 Message-ID: Subject: Re: Raspberry Pi EABI test image From: "dev, dev" To: Torfinn Ingolfsen X-Gm-Message-State: ALoCoQlbjtVrc0LVDopGpvWWMBaw0T53nYJVgVasYXO7JLaHvW6F71m8Cswvbs1vEpNNoQl2MSoK Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 15:28:32 -0000 you may need erase the SD card. this is my display use 16G SD card root@raspberry-pi:~ # gpart show => 63 31268801 mmcsd0 MBR (14G) 63 64197 1 !12 [active] (31M) 64260 7605486 2 freebsd (3.6G) 7669746 63 - free - (31k) 7669809 23598918 3 freebsd (11G) 31268727 137 - free - (68k) => 0 7605486 mmcsd0s2 BSD (3.6G) 0 252 - free - (126k) 252 6553600 1 freebsd-ufs (3.1G) 6553852 1048576 2 freebsd-swap (512M) 7602428 3058 - free - (1.5M) yarshure 2012/12/26 Torfinn Ingolfsen > gpart show From owner-freebsd-arm@FreeBSD.ORG Wed Dec 26 16:05:42 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A23098C for ; Wed, 26 Dec 2012 16:05:42 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by mx1.freebsd.org (Postfix) with ESMTP id A25508FC08 for ; Wed, 26 Dec 2012 16:05:41 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id l5so10781797lah.39 for ; Wed, 26 Dec 2012 08:05:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=w7Djledp5tbqzsZ5FkGEuQs1sfZ29LVsajmykca1ctg=; b=Ck6+uVnmBzQfXNK0sChjBtaj1JRStzw/rAXFYn+JqhpfOI4W/Uyqy/XAv3ECWt4JKE 51p+DtP+6GrEIBw+GO6djlaTOzieDzLwThKDOnPvI9nBdQVKk+bsOStyPlgvatEfrCzR lGEiRtBL7Q0Vi4kitCgirmivlaL7oshpp/w07qBgAkDtJ53gFumM+DJBuZFSKk08sqPR k/3E6zKgEyaCBqLJi6QOSbK3UF7XXsfb4nHL/ZSpivPkAXzkwoCUJk1+W2UgzS2MRFrz HL/vB4MYYyM2/swxQk/g/JehH3LNnQhQIyKXMhYBITtPLINYS1V1FOa3X7bVE8znEmLv 1vGQ== MIME-Version: 1.0 Received: by 10.152.111.166 with SMTP id ij6mr26112676lab.47.1356537935254; Wed, 26 Dec 2012 08:05:35 -0800 (PST) Received: by 10.152.144.69 with HTTP; Wed, 26 Dec 2012 08:05:35 -0800 (PST) Date: Thu, 27 Dec 2012 00:05:35 +0800 Message-ID: Subject: Allwinner A10 From: Ganbold Tsagaankhuu To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 16:05:42 -0000 Just some information, Still nothing useful yet, but with the help of andrew@, ray@, gonzo@ and other arm guys kernel boots: https://github.com/tsgan/allwinner_a10/blob/master/dmesg_ehci.txt Tried usb/ehci glue code, no success yet, so maybe I will leave it now and try next SD/MMC :) br, Ganbold From owner-freebsd-arm@FreeBSD.ORG Wed Dec 26 19:13:04 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB29E5D6 for ; Wed, 26 Dec 2012 19:13:04 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 491D98FC16 for ; Wed, 26 Dec 2012 19:13:03 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBQJCux0013917 for ; Wed, 26 Dec 2012 12:13:03 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBQJCYHP074341; Wed, 26 Dec 2012 12:12:34 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Raspberry Pi questions From: Ian Lepore To: Tim Kientzle In-Reply-To: References: <1356466883.1144.8.camel@revolution.hippie.lan> <08125E73-C46A-4DDF-BFD8-59D5B86136B8@bluezbox.com> <1356476778.1144.20.camel@revolution.hippie.lan> <0F630E03-7A0C-4D56-A580-C7A9ABD2CB0C@bluezbox.com> <1356479705.1144.23.camel@revolution.hippie.lan> Content-Type: text/plain; charset="windows-1251" Date: Wed, 26 Dec 2012 12:12:34 -0700 Message-ID: <1356549154.1144.57.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 19:13:04 -0000 On Tue, 2012-12-25 at 21:57 -0800, Tim Kientzle wrote: > On Dec 25, 2012, at 3:55 PM, Ian Lepore wrote: > >>> > >>> This is so close to working. > > I know what you mean…. > > I've almost got my scripts building bootable RPi images now using > the new boot sequence that Oleksandr's been working on. > > There's clearly been a huge amount of progress: memory config > now works, the HDMI video console works. > > But I am still having a few inexplicable issues: > > 1) Building U-Boot. > > I'm trying to build U-Boot from the sources at > github.com/gonzoua/u-boot-pi.git > They build but the result won't boot. Can anyone > point me to the U-Boot sources that do work? For > now, I'm using the binary blob that Oleksandr built. > > 2) Random failure to mount root. > > This is weird. If I insert the SD card into my Mac and open > the MSDOS partition, then eject, the card will boot (sort of, > see below). Otherwise, the kernel can't mount root. I'm > entirely baffled. > I did some debugging on this today. For me, the failure is always associated with trying to run the card at 50mhz. Look for this line when it fails to boot and see if that's also the case for you. mmcsd0: 477MB at mmc0 50.0MHz/4bit/65535-block I've tracked down the underlying cause to some data corruption. The mmc layer sends the inquiry command to ask the card if it can do high-speed mode, and sometimes there's bogus data in the response buffer. It should always be 64 bytes of zeroes, except that one bit would be set if the card is SDHC. I see lots of non-zero data in the first part of the response buffer in the failure cases: ugen0.1: at usbus0 uhub0: on usbus0 00648001800180018001800180030000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 mmc0: switch_res[13] 0x03 The proper response would either be all zeroes or the 0x03 byte would be 0x02 for an SDHC card. I wonder if that non-zero data is in any way related to a dma transfer related to initializing the usb root hub that's happening at about the same time? -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Dec 26 20:37:56 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA22C4CC; Wed, 26 Dec 2012 20:37:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 933858FC0A; Wed, 26 Dec 2012 20:37:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qBQKF5FE036024; Wed, 26 Dec 2012 15:15:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBQKF5dm036023; Wed, 26 Dec 2012 20:15:05 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 26 Dec 2012 20:15:05 GMT Message-Id: <201212262015.qBQKF5dm036023@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 20:37:56 -0000 TB --- 2012-12-26 19:00:14 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2012-12-26 19:00:14 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-26 19:00:14 - starting HEAD tinderbox run for arm/arm TB --- 2012-12-26 19:00:14 - cleaning the object tree TB --- 2012-12-26 19:00:14 - /usr/local/bin/svn stat /src TB --- 2012-12-26 19:00:18 - At svn revision 244709 TB --- 2012-12-26 19:00:19 - building world TB --- 2012-12-26 19:00:19 - CROSS_BUILD_TESTING=YES TB --- 2012-12-26 19:00:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-26 19:00:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-26 19:00:19 - SRCCONF=/dev/null TB --- 2012-12-26 19:00:19 - TARGET=arm TB --- 2012-12-26 19:00:19 - TARGET_ARCH=arm TB --- 2012-12-26 19:00:19 - TZ=UTC TB --- 2012-12-26 19:00:19 - __MAKE_CONF=/dev/null TB --- 2012-12-26 19:00:19 - cd /src TB --- 2012-12-26 19:00:19 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Dec 26 19:00:25 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Dec 26 20:01:46 UTC 2012 TB --- 2012-12-26 20:01:46 - generating LINT kernel config TB --- 2012-12-26 20:01:46 - cd /src/sys/arm/conf TB --- 2012-12-26 20:01:46 - /usr/bin/make -B LINT TB --- 2012-12-26 20:01:46 - cd /src/sys/arm/conf TB --- 2012-12-26 20:01:46 - /usr/sbin/config -m LINT TB --- 2012-12-26 20:01:46 - building LINT kernel TB --- 2012-12-26 20:01:46 - CROSS_BUILD_TESTING=YES TB --- 2012-12-26 20:01:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-26 20:01:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-26 20:01:46 - SRCCONF=/dev/null TB --- 2012-12-26 20:01:46 - TARGET=arm TB --- 2012-12-26 20:01:46 - TARGET_ARCH=arm TB --- 2012-12-26 20:01:46 - TZ=UTC TB --- 2012-12-26 20:01:46 - __MAKE_CONF=/dev/null TB --- 2012-12-26 20:01:46 - cd /src TB --- 2012-12-26 20:01:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Dec 26 20:01:46 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -ffreestanding -Werror /src/sys/arm/arm/swtch.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -ffreestanding -Werror /src/sys/arm/arm/sys_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -ffreestanding -Werror /src/sys/arm/arm/trap.c cc1: warnings being treated as errors In file included from /src/sys/arm/arm/trap.c:900: /src/sys/arm/arm/../../kern/subr_syscall.c: In function 'syscallenter': /src/sys/arm/arm/../../kern/subr_syscall.c:80: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] /src/sys/arm/arm/../../kern/subr_syscall.c:154: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] *** [trap.o] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-26 20:15:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-26 20:15:05 - ERROR: failed to build LINT kernel TB --- 2012-12-26 20:15:05 - 3198.83 user 659.80 system 4490.77 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Thu Dec 27 03:02:24 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F87A895 for ; Thu, 27 Dec 2012 03:02:24 +0000 (UTC) (envelope-from dev@macdevshanghai.com) Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by mx1.freebsd.org (Postfix) with ESMTP id B03838FC15 for ; Thu, 27 Dec 2012 03:02:23 +0000 (UTC) Received: by mail-vb0-f43.google.com with SMTP id fs19so9318187vbb.2 for ; Wed, 26 Dec 2012 19:02:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=EYuLo2f6wnmduGTpZb3Nz6yb3FJfDZ4v+i4ca7Q7uGw=; b=lCdRZqqbF/F4kl586JUg6Myr0SVjluyCDTsafBtcilc6Dr4ReGO+oXa7J15ROvPIpv 1LqN+pZondvfKpi0nw6i+X3oYRvuLdbkm/RSl64mPFTUfDj3I7JAOveLO4F9yzk3t8aH 9ZUkYcz8kx2GKKKud4rC2pojrA2xAxZsBVPIoDhWBblxZ9XM85e4Cy2BES7EZRy0jWzS x5ODHON3VF3QusFEXk35Ox0wT4SkODdDt5Y/TsKDQ2lLdLTu5uzVAMGU0aguJNbT/I7G 8S7x92WRw3NK6u1rJrsAo/vPd7ZWqUYCiSvq7bCmyO4KLV2YafKwgt/vanUTs3yJnMOo wcQw== MIME-Version: 1.0 Received: by 10.58.107.235 with SMTP id hf11mr46265731veb.16.1356577341937; Wed, 26 Dec 2012 19:02:21 -0800 (PST) Received: by 10.58.161.167 with HTTP; Wed, 26 Dec 2012 19:02:21 -0800 (PST) X-Originating-IP: [101.228.106.104] In-Reply-To: References: Date: Thu, 27 Dec 2012 11:02:21 +0800 Message-ID: Subject: Re: Allwinner A10 From: "dev, dev" To: Ganbold Tsagaankhuu X-Gm-Message-State: ALoCoQnnkOFSsPGJM4HWKB4XPi+p0p7cAjNgWRma8CL4JiwH1OEb7t7wn6SRXFjBFvhHhPPOuuBi Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 03:02:24 -0000 waiting success! I will try it. I order one from taobao (China ebay) $60 http://item.taobao.com/item.htm?id=19815480852&ali_trackid=2:mm_14507416_2297358_8935934:1356332362_310_1536768759 yarshure 2012/12/27 Ganbold Tsagaankhuu > Just some information, > > Still nothing useful yet, but with the help of andrew@, ray@, gonzo@ > and other arm guys kernel boots: > > https://github.com/tsgan/allwinner_a10/blob/master/dmesg_ehci.txt > > Tried usb/ehci glue code, no success yet, so maybe I will leave it now > and try next SD/MMC :) > > br, > > Ganbold > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Thu Dec 27 03:21:11 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1ACD5D6E for ; Thu, 27 Dec 2012 03:21:11 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id DF6378FC12 for ; Thu, 27 Dec 2012 03:21:10 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id qBR3L1Kr079733; Thu, 27 Dec 2012 03:21:01 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id u8mf6jxh7gihhpj4n2w7chjpda; Thu, 27 Dec 2012 03:21:01 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Raspberry Pi questions Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1251 From: Tim Kientzle In-Reply-To: <1356534197.1144.38.camel@revolution.hippie.lan> Date: Wed, 26 Dec 2012 19:21:00 -0800 Content-Transfer-Encoding: 7bit Message-Id: <42B1C86B-F998-48DF-AA85-BB5250172E95@kientzle.com> References: <1356466883.1144.8.camel@revolution.hippie.lan> <08125E73-C46A-4DDF-BFD8-59D5B86136B8@bluezbox.com> <1356476778.1144.20.camel@revolution.hippie.lan> <0F630E03-7A0C-4D56-A580-C7A9ABD2CB0C@bluezbox.com> <1356479705.1144.23.camel@revolution.hippie.lan> <1356534197.1144.38.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 03:21:11 -0000 On Dec 26, 2012, at 7:03 AM, Ian Lepore wrote: > >> 2) Random failure to mount root. >> >> This is weird. If I insert the SD card into my Mac and open >> the MSDOS partition, then eject, the card will boot (sort of, >> see below). Otherwise, the kernel can't mount root. I'm >> entirely baffled. >> > > I had something like this happen several times yesterday. Most of the > time it boots fine, sometimes it fails to mount root from the sdcard, > but then it works on a reboot. I also saw the mmcsd0 driver ident line > say the bus was running at 50mhz several times, and I'm pretty sure I > wasn't using any SDHC cards, but that also wasn't the problem I was > pursuing so I didn't pay close attention. > > Of course, that doesn't seem to intersect with what you describe very > much at all, unless touching the card on the Mac wasn't really a cure, > it was just some misleading coincidence going on. Apparently it was just coincidence (that happened two times in a row!). I just tested a few more times and it now mounts root or not randomly even without mounting elsewhere in the middle. But I do see the correlation with probing the card at 25MHz (works) or 50MHz (fails). Tim From owner-freebsd-arm@FreeBSD.ORG Thu Dec 27 03:52:44 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 52374192 for ; Thu, 27 Dec 2012 03:52:44 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) by mx1.freebsd.org (Postfix) with ESMTP id AF5278FC0C for ; Thu, 27 Dec 2012 03:52:43 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id BD34739FA3; Thu, 27 Dec 2012 12:52:41 +0900 (JST) Received: from artemis (unknown [172.18.0.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id A8CF039D5E; Thu, 27 Dec 2012 12:52:41 +0900 (JST) Message-ID: <2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp> From: "Daisuke Aoyama" To: "Oleksandr Tymoshenko" References: In-Reply-To: Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Date: Thu, 27 Dec 2012 12:52:35 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 03:52:44 -0000 >PTE sync - related part, Im not sure it's strictly required. We use WT >caches for page tables >so we should be OK without implicit sync operations for them. I hope >somebody >more clueful can confirm/disprove this. Some digging, I notice "Invalidate Entire Instruction Cache" works without segfault. So, Invalidate D-cache is no effect :) It seems following should work for this issue: mov r0, #0 mcr p15, 0, r0, c7, c5, 0 /* Invalidate Entire Instruction Cache */ mcr p15, 0, r0, c7, c10, 4 /* Data Synchronization Barrier */ Try this code instead of CF_ICACHE_SYNC. I don't know side effect of Invalidate I-cache, but it works. Also I don't know whether DSB is required or not. For test, using NFS or HDD/SDD is BAD idea for system stress. You must use SD(mmc) or USB memory. Serial console is recommended for interrupt test. Here is simple test from serial console: # rm -rf /var/db/portsnap /usr/ports # mkdir /var/db/portsnap # portsnap fetch # portsnap extract # cd /usr/ports/shells/bash # make BATCH=y If your kernel is really stable, it should finish without any problems with SD/mmc. ---------------------------------------------------------------------- --- sys/arm/arm/swtch.S (revision 244663) +++ sys/arm/arm/swtch.S (working copy) @@ -130,7 +130,11 @@ /* Switch to lwp0 context */ ldr r9, .Lcpufuncs -#if !defined(CPU_ARM11) && !defined(CPU_CORTEXA) && !defined(CPU_MV_PJ4B) +#if defined(CPU_ARM1176) + mov r0, #0 + mcr p15, 0, r0, c7, c5, 0 /* Invalidate Entire Instruction Cache */ + mcr p15, 0, r0, c7, c10, 4 /* Data Synchronization Barrier */ +#elif !defined(CPU_CORTEXA) && !defined(CPU_MV_PJ4B) mov lr, pc ldr pc, [r9, #CF_IDCACHE_WBINV_ALL] #endif @@ -352,7 +356,11 @@ cmpeq r0, r5 /* Same DACR? */ beq .Lcs_context_switched /* yes! */ -#if !defined(CPU_ARM11) && !defined(CPU_CORTEXA) && !defined(CPU_MV_PJ4B) +#if defined(CPU_ARM1176) + mov r0, #0 + mcr p15, 0, r0, c7, c5, 0 /* Invalidate Entire Instruction Cache */ + mcr p15, 0, r0, c7, c10, 4 /* Data Synchronization Barrier */ +#elif !defined(CPU_CORTEXA) && !defined(CPU_MV_PJ4B) /* * Definately need to flush the cache. */ ---------------------------------------------------------------------- Thanks. -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Thu Dec 27 04:16:22 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9580C4EA for ; Thu, 27 Dec 2012 04:16:22 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 2ABA08FC08 for ; Thu, 27 Dec 2012 04:16:21 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.1.67]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1To4tF-000JET-T0; Wed, 26 Dec 2012 20:16:20 -0800 Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Oleksandr Tymoshenko X-Priority: 3 In-Reply-To: <2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp> Date: Wed, 26 Dec 2012 20:16:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp> To: Daisuke Aoyama X-Mailer: Apple Mail (2.1499) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2012-12-26, at 7:52 PM, Daisuke Aoyama wrote: >> PTE sync - related part, Im not sure it's strictly required. We use WT caches for page tables >> so we should be OK without implicit sync operations for them. I hope somebody >> more clueful can confirm/disprove this. > > Some digging, I notice "Invalidate Entire Instruction Cache" works without segfault. > So, Invalidate D-cache is no effect :) > > It seems following should work for this issue: > > mov r0, #0 > mcr p15, 0, r0, c7, c5, 0 /* Invalidate Entire Instruction Cache */ > mcr p15, 0, r0, c7, c10, 4 /* Data Synchronization Barrier */ > > Try this code instead of CF_ICACHE_SYNC. > I don't know side effect of Invalidate I-cache, but it works. > Also I don't know whether DSB is required or not. > > For test, using NFS or HDD/SDD is BAD idea for system stress. > You must use SD(mmc) or USB memory. Serial console is recommended for interrupt test. > Here is simple test from serial console: > > # rm -rf /var/db/portsnap /usr/ports > # mkdir /var/db/portsnap > # portsnap fetch > # portsnap extract > # cd /usr/ports/shells/bash > # make BATCH=y > > If your kernel is really stable, it should finish without any problems with SD/mmc. > [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 04:16:22 -0000 On 2012-12-26, at 7:52 PM, Daisuke Aoyama wrote: >> PTE sync - related part, Im not sure it's strictly required. We use = WT caches for page tables >> so we should be OK without implicit sync operations for them. I hope = somebody >> more clueful can confirm/disprove this. >=20 > Some digging, I notice "Invalidate Entire Instruction Cache" works = without segfault. > So, Invalidate D-cache is no effect :) >=20 > It seems following should work for this issue: >=20 > mov r0, #0 > mcr p15, 0, r0, c7, c5, 0 /* Invalidate Entire = Instruction Cache */ > mcr p15, 0, r0, c7, c10, 4 /* Data Synchronization = Barrier */ >=20 > Try this code instead of CF_ICACHE_SYNC. > I don't know side effect of Invalidate I-cache, but it works. > Also I don't know whether DSB is required or not. >=20 > For test, using NFS or HDD/SDD is BAD idea for system stress. > You must use SD(mmc) or USB memory. Serial console is recommended for = interrupt test. > Here is simple test from serial console: >=20 > # rm -rf /var/db/portsnap /usr/ports > # mkdir /var/db/portsnap > # portsnap fetch > # portsnap extract > # cd /usr/ports/shells/bash > # make BATCH=3Dy >=20 > If your kernel is really stable, it should finish without any problems = with SD/mmc. >=20 Hmm, I saw problems with i-caches with kernel with WB cache enabled = instead of WT.=20 This patch fixed it for me: http://people.freebsd.org/~gonzo/arm/patches/pmapv6-icache.diff It invalidates i-caches only when new mapping is created, not on every = switch so=20 it should be less taxing on performance. Could you test it on your setup?=20= From owner-freebsd-arm@FreeBSD.ORG Thu Dec 27 06:11:14 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E7C6408; Thu, 27 Dec 2012 06:11:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D4B848FC0A; Thu, 27 Dec 2012 06:11:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qBR6BCpx040742; Thu, 27 Dec 2012 01:11:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBR6BC4Z040741; Thu, 27 Dec 2012 06:11:12 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 27 Dec 2012 06:11:12 GMT Message-Id: <201212270611.qBR6BC4Z040741@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 06:11:14 -0000 TB --- 2012-12-27 05:00:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2012-12-27 05:00:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-27 05:00:16 - starting HEAD tinderbox run for arm/arm TB --- 2012-12-27 05:00:16 - cleaning the object tree TB --- 2012-12-27 05:01:44 - /usr/local/bin/svn stat /src TB --- 2012-12-27 05:01:47 - At svn revision 244726 TB --- 2012-12-27 05:01:48 - building world TB --- 2012-12-27 05:01:48 - CROSS_BUILD_TESTING=YES TB --- 2012-12-27 05:01:48 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-27 05:01:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-27 05:01:48 - SRCCONF=/dev/null TB --- 2012-12-27 05:01:48 - TARGET=arm TB --- 2012-12-27 05:01:48 - TARGET_ARCH=arm TB --- 2012-12-27 05:01:48 - TZ=UTC TB --- 2012-12-27 05:01:48 - __MAKE_CONF=/dev/null TB --- 2012-12-27 05:01:48 - cd /src TB --- 2012-12-27 05:01:48 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Dec 27 05:01:52 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Dec 27 05:57:46 UTC 2012 TB --- 2012-12-27 05:57:46 - generating LINT kernel config TB --- 2012-12-27 05:57:46 - cd /src/sys/arm/conf TB --- 2012-12-27 05:57:46 - /usr/bin/make -B LINT TB --- 2012-12-27 05:57:46 - cd /src/sys/arm/conf TB --- 2012-12-27 05:57:46 - /usr/sbin/config -m LINT TB --- 2012-12-27 05:57:46 - building LINT kernel TB --- 2012-12-27 05:57:46 - CROSS_BUILD_TESTING=YES TB --- 2012-12-27 05:57:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-27 05:57:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-27 05:57:46 - SRCCONF=/dev/null TB --- 2012-12-27 05:57:46 - TARGET=arm TB --- 2012-12-27 05:57:46 - TARGET_ARCH=arm TB --- 2012-12-27 05:57:46 - TZ=UTC TB --- 2012-12-27 05:57:46 - __MAKE_CONF=/dev/null TB --- 2012-12-27 05:57:46 - cd /src TB --- 2012-12-27 05:57:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Dec 27 05:57:46 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -ffreestanding -Werror /src/sys/arm/arm/swtch.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -ffreestanding -Werror /src/sys/arm/arm/sys_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -ffreestanding -Werror /src/sys/arm/arm/trap.c cc1: warnings being treated as errors In file included from /src/sys/arm/arm/trap.c:900: /src/sys/arm/arm/../../kern/subr_syscall.c: In function 'syscallenter': /src/sys/arm/arm/../../kern/subr_syscall.c:80: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] /src/sys/arm/arm/../../kern/subr_syscall.c:154: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] *** [trap.o] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-27 06:11:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-27 06:11:11 - ERROR: failed to build LINT kernel TB --- 2012-12-27 06:11:11 - 3190.16 user 655.80 system 4255.38 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Thu Dec 27 09:02:35 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8207292C for ; Thu, 27 Dec 2012 09:02:35 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.c2i.net [212.247.154.130]) by mx1.freebsd.org (Postfix) with ESMTP id 083EB8FC0C for ; Thu, 27 Dec 2012 09:02:34 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 357980192; Thu, 27 Dec 2012 10:02:26 +0100 From: Hans Petter Selasky To: freebsd-arm@freebsd.org Subject: Re: Allwinner A10 Date: Thu, 27 Dec 2012 10:04:01 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201212271004.01598.hselasky@c2i.net> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 09:02:35 -0000 On Wednesday 26 December 2012 17:05:35 Ganbold Tsagaankhuu wrote: > Just some information, > > Still nothing useful yet, but with the help of andrew@, ray@, gonzo@ > and other arm guys kernel boots: > > https://github.com/tsgan/allwinner_a10/blob/master/dmesg_ehci.txt > > Tried usb/ehci glue code, no success yet, so maybe I will leave it now > and try next SD/MMC :) > Hi, It looks like number of ports is zero. Can you try this: Edit sys/dev/usb/controller/ehci.c Find this: sc->sc_noport = EHCI_HCS_N_PORTS(sparams); Add this: if (sc->sc_noport == 0) sc->sc_noport = 1; Does the EHCI work now? --HPS From owner-freebsd-arm@FreeBSD.ORG Thu Dec 27 09:16:02 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4198CB38 for ; Thu, 27 Dec 2012 09:16:02 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by mx1.freebsd.org (Postfix) with ESMTP id B70A48FC12 for ; Thu, 27 Dec 2012 09:16:01 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id l5so11765662lah.39 for ; Thu, 27 Dec 2012 01:16:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9R5BQMJ776iSJg3b3UQ+1UTWaskkFhDxI0k7Z2KNoxQ=; b=fRjNGp8KgcdYNOdJqCPjiYiaTGHyL+mN1/5cPo1UmgEbbhAYXsUAtACDh6NIAhq5Lj C/RuOGLpBwrNFXJMpmDWjGIaDu2D8HzBBfQ0gpDPi/mQlu9JNgxm0udBpalemkO87XcB fW5E88+cIi55E8KA6UTDTV7FUcTMZ7hlr9MPQRw51o7IWyu/fxd9OB1oN2q2inc27GV8 7R2ZMznxw8dviqx3KFbTJVVz3+eO4v14i+56DEL/CkMDdRss3CZXvPhAnUYuvpA4BdgP qqKiLxb8Bv5I0AXW4wOUvhaFrmYaVpVamCCshWKPu9itQOQtDQS77lTaK3ygX/HYMhtw w+3g== MIME-Version: 1.0 Received: by 10.152.108.37 with SMTP id hh5mr28058788lab.52.1356599760373; Thu, 27 Dec 2012 01:16:00 -0800 (PST) Received: by 10.152.144.69 with HTTP; Thu, 27 Dec 2012 01:16:00 -0800 (PST) In-Reply-To: <201212271004.01598.hselasky@c2i.net> References: <201212271004.01598.hselasky@c2i.net> Date: Thu, 27 Dec 2012 17:16:00 +0800 Message-ID: Subject: Re: Allwinner A10 From: Ganbold Tsagaankhuu To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 09:16:02 -0000 Hans, On Thu, Dec 27, 2012 at 5:04 PM, Hans Petter Selasky wrote: > On Wednesday 26 December 2012 17:05:35 Ganbold Tsagaankhuu wrote: >> Just some information, >> >> Still nothing useful yet, but with the help of andrew@, ray@, gonzo@ >> and other arm guys kernel boots: >> >> https://github.com/tsgan/allwinner_a10/blob/master/dmesg_ehci.txt >> >> Tried usb/ehci glue code, no success yet, so maybe I will leave it now >> and try next SD/MMC :) >> > > Hi, > > It looks like number of ports is zero. Can you try this: > > Edit sys/dev/usb/controller/ehci.c > > > Find this: > sc->sc_noport = EHCI_HCS_N_PORTS(sparams); > > Add this: > if (sc->sc_noport == 0) > sc->sc_noport = 1; > > Does the EHCI work now? > Please see msg: https://github.com/tsgan/allwinner_a10/blob/master/dmesg_ehci-patch.txt Seems it passes. So does this mean it works this way? Ganbold > --HPS From owner-freebsd-arm@FreeBSD.ORG Thu Dec 27 09:54:34 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18460355 for ; Thu, 27 Dec 2012 09:54:34 +0000 (UTC) (envelope-from freebsd-arm@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id B1F268FC15 for ; Thu, 27 Dec 2012 09:54:33 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id qBR9sW2k069469 for ; Thu, 27 Dec 2012 04:54:32 -0500 (EST) (envelope-from freebsd-arm@wynn.com) Date: Thu, 27 Dec 2012 04:54:31 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: beaglebone ethernet updated information Message-ID: <20121227045431.20318c34@ivory.wynn.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 09:54:34 -0000 Greeting- I previously reported that my beaglebone would not work on my 10M hub. I now have it working on the 10M hub. I had to set it for full duplex on interface cpsw0. I changed rc.conf as follows: ifconfig_cpsw0="DHCP media 10baseT/UTP mediaopt full-duplex" It would be nice if the driver defaulted to full duplex because then the rc.conf could be left at ifconfig_cpsw0="DHCP" which will allow auto adaption to 100M or 10M. Ok enough beaglebone play for tonight.....time for me to get some sleep. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6924 718-717-5435 From owner-freebsd-arm@FreeBSD.ORG Thu Dec 27 10:01:24 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD92B5B1 for ; Thu, 27 Dec 2012 10:01:24 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 947E88FC0C for ; Thu, 27 Dec 2012 10:01:23 +0000 (UTC) Received: from terran (unknown [192.168.10.90]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id E5CBDC493C; Thu, 27 Dec 2012 12:01:21 +0200 (EET) Date: Thu, 27 Dec 2012 12:01:41 +0200 From: Aleksandr Rybalko To: Hans Petter Selasky Subject: Re: Allwinner A10 Message-Id: <20121227120141.6cff665cd399e722967efbe5@ddteam.net> In-Reply-To: <201212271004.01598.hselasky@c2i.net> References: <201212271004.01598.hselasky@c2i.net> X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 10:01:24 -0000 On Thu, 27 Dec 2012 10:04:01 +0100 Hans Petter Selasky wrote: > On Wednesday 26 December 2012 17:05:35 Ganbold Tsagaankhuu wrote: > > Just some information, > > > > Still nothing useful yet, but with the help of andrew@, ray@, gonzo@ > > and other arm guys kernel boots: > > > > https://github.com/tsgan/allwinner_a10/blob/master/dmesg_ehci.txt > > > > Tried usb/ehci glue code, no success yet, so maybe I will leave it now > > and try next SD/MMC :) > > > > Hi, > > It looks like number of ports is zero. Can you try this: > > Edit sys/dev/usb/controller/ehci.c > > > Find this: > sc->sc_noport = EHCI_HCS_N_PORTS(sparams); > > Add this: > if (sc->sc_noport == 0) > sc->sc_noport = 1; > > Does the EHCI work now? > > --HPS > _______________________________________________ > 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" I've ask Ganbold to inspect EHCI registers and they all is 0, so I think it is not port count problem, but clock and/or power control. Thanks! WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Thu Dec 27 15:10:36 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B4C731A; Thu, 27 Dec 2012 15:10:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 38F638FC13; Thu, 27 Dec 2012 15:10:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qBRFAZbx056227; Thu, 27 Dec 2012 10:10:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBRFAZ3U056226; Thu, 27 Dec 2012 15:10:35 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 27 Dec 2012 15:10:35 GMT Message-Id: <201212271510.qBRFAZ3U056226@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 15:10:36 -0000 TB --- 2012-12-27 14:50:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2012-12-27 14:50:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-27 14:50:16 - starting HEAD tinderbox run for arm/arm TB --- 2012-12-27 14:50:16 - cleaning the object tree TB --- 2012-12-27 14:51:29 - /usr/local/bin/svn stat /src TB --- 2012-12-27 14:51:32 - At svn revision 244738 TB --- 2012-12-27 14:51:33 - building world TB --- 2012-12-27 14:51:33 - CROSS_BUILD_TESTING=YES TB --- 2012-12-27 14:51:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-27 14:51:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-27 14:51:33 - SRCCONF=/dev/null TB --- 2012-12-27 14:51:33 - TARGET=arm TB --- 2012-12-27 14:51:33 - TARGET_ARCH=arm TB --- 2012-12-27 14:51:33 - TZ=UTC TB --- 2012-12-27 14:51:33 - __MAKE_CONF=/dev/null TB --- 2012-12-27 14:51:33 - cd /src TB --- 2012-12-27 14:51:33 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Dec 27 14:51:38 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/auth.c -o auth.o cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/expand_number.c -o expand_number.o cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/flopen.c -o flopen.o cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/fparseln.c -o fparseln.o cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libutil/gr_util.c -o gr_util.o cc1: warnings being treated as errors /src/lib/libutil/gr_util.c: In function 'gr_add': /src/lib/libutil/gr_util.c:510: warning: cast discards qualifiers from pointer target type *** [gr_util.o] Error code 1 Stop in /src/lib/libutil. *** [lib/libutil__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-27 15:10:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-27 15:10:35 - ERROR: failed to build world TB --- 2012-12-27 15:10:35 - 862.34 user 195.46 system 1219.15 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Thu Dec 27 15:34:36 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 72AFD98C for ; Thu, 27 Dec 2012 15:34:36 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) by mx1.freebsd.org (Postfix) with ESMTP id E8AD68FC0A for ; Thu, 27 Dec 2012 15:34:35 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 0635E39FA3; Fri, 28 Dec 2012 00:34:29 +0900 (JST) Received: from artemis (unknown [172.18.0.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id E5E6439D5E; Fri, 28 Dec 2012 00:34:28 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: "Oleksandr Tymoshenko" References: <2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp> In-Reply-To: Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Date: Fri, 28 Dec 2012 00:34:23 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 15:34:36 -0000 >>> PTE sync - related part, Im not sure it's strictly required. We use WT >>> caches for page tables >>> so we should be OK without implicit sync operations for them. I hope >>> somebody >>> more clueful can confirm/disprove this. >> >> Some digging, I notice "Invalidate Entire Instruction Cache" works >> without segfault. >> So, Invalidate D-cache is no effect :) >> >> It seems following should work for this issue: >> >> mov r0, #0 >> mcr p15, 0, r0, c7, c5, 0 /* Invalidate Entire >> Instruction Cache */ >> mcr p15, 0, r0, c7, c10, 4 /* Data Synchronization >> Barrier */ (snip) > > Hmm, I saw problems with i-caches with kernel with WB cache enabled > instead of WT. > This patch fixed it for me: > > http://people.freebsd.org/~gonzo/arm/patches/pmapv6-icache.diff > It invalidates i-caches only when new mapping is created, not on every > switch so > it should be less taxing on performance. > > Could you test it on your setup? = It does not help. Also both your patch +PTE SYNC and call always WBINV in pmap +PTE SYNC don't help. The kernel applied your patch was failed at first "portsnap fetch" step. Probably change in pmap is no effect for this segfault. Currently, adding invalidate I-cache to swtch.S is only solution. My test is: 1) ping from other freebsd to RPI. 2) login to RPI, then run "top -PHs1" under pi user. 3) use simple test (portsnap fetch/extract/build bash) from console. Side effect of digging, I found a reason why timer is never fired. According to the source, et_min_period.frac set to 2. This means the start will be called with 1 (frac - 1). So the routine have only 1us(1MHz) to be finished for the request. Probably it's impossible even if modern CPU such as 3GHz CPU. If failed to setup, it will be fired after 0xffffffff(wrapped about 4294.9sec). So, "the interrupt is not fired" is wrong understanding. The timer will be fired later. Until this, the world seems to have stopped :) This is complete version of systimer patch. It should fix stopping interrupt and related things such as USB LAN is unstable, SSH is closed suddenly. (I've not yet finished all test at this time, but at least portsnap fetch is success. Now extracting the ports without any problems.) ---------------------------------------------------------------------- --- bcm2835_systimer.c (revision 244663) +++ bcm2835_systimer.c (working copy) @@ -55,6 +55,7 @@ #define DEFAULT_TIMER 3 #define DEFAULT_FREQUENCY 1000000 +#define MIN_PERIOD 1000LLU #define SYSTIMER_CS 0x00 #define SYSTIMER_CLO 0x04 @@ -123,17 +124,20 @@ struct systimer *st = et->et_priv; uint32_t clo; uint32_t count; + register_t s; if (first != NULL) { - st->enabled = 1; - count = (st->et.et_frequency * (first->frac >> 32)) >> 32; if (first->sec != 0) count += st->et.et_frequency * first->sec; + s = intr_disable(); clo = bcm_systimer_tc_read_4(SYSTIMER_CLO); clo += count; bcm_systimer_tc_write_4(SYSTIMER_C0 + st->index*4, clo); + st->enabled = 1; + bcm_systimer_tc_write_4(SYSTIMER_CS, (1 << st->index)); + intr_restore(s); return (0); } @@ -154,13 +158,18 @@ bcm_systimer_intr(void *arg) { struct systimer *st = (struct systimer *)arg; + uint32_t cs; + cs = bcm_systimer_tc_read_4(SYSTIMER_CS); + if ((cs & (1 << st->index)) == 0) + return (FILTER_STRAY); + bcm_systimer_tc_write_4(SYSTIMER_CS, (1 << st->index)); - if (st->enabled) { + //if (st->enabled) { if (st->et.et_active) { st->et.et_event_cb(&st->et, st->et.et_arg); } - } + //} return (FILTER_HANDLED); } @@ -226,7 +235,7 @@ sc->st[DEFAULT_TIMER].et.et_frequency = sc->sysclk_freq; sc->st[DEFAULT_TIMER].et.et_min_period.sec = 0; sc->st[DEFAULT_TIMER].et.et_min_period.frac = - ((0x00000002LLU << 32) / sc->st[DEFAULT_TIMER].et.et_frequency) << 32; + ((MIN_PERIOD << 32) / sc->st[DEFAULT_TIMER].et.et_frequency) << 32; sc->st[DEFAULT_TIMER].et.et_max_period.sec = 0xfffffff0U / sc->st[DEFAULT_TIMER].et.et_frequency; sc->st[DEFAULT_TIMER].et.et_max_period.frac = ((0xfffffffeLLU << 32) / sc->st[DEFAULT_TIMER].et.et_frequency) << 32; ---------------------------------------------------------------------- Thanks. -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Thu Dec 27 16:11:56 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8022B473 for ; Thu, 27 Dec 2012 16:11:56 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6D6C68FC08 for ; Thu, 27 Dec 2012 16:11:55 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBRGBlk3027829 for ; Thu, 27 Dec 2012 09:11:48 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBRGBYdd075314; Thu, 27 Dec 2012 09:11:34 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) From: Ian Lepore To: Daisuke Aoyama In-Reply-To: References: <2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp> Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Dec 2012 09:11:34 -0700 Message-ID: <1356624694.1144.67.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 16:11:56 -0000 On Fri, 2012-12-28 at 00:34 +0900, Daisuke Aoyama wrote: > >>> PTE sync - related part, Im not sure it's strictly required. We use WT > >>> caches for page tables > >>> so we should be OK without implicit sync operations for them. I hope > >>> somebody > >>> more clueful can confirm/disprove this. > >> > >> Some digging, I notice "Invalidate Entire Instruction Cache" works > >> without segfault. > >> So, Invalidate D-cache is no effect :) > >> > >> It seems following should work for this issue: > >> > >> mov r0, #0 > >> mcr p15, 0, r0, c7, c5, 0 /* Invalidate Entire > >> Instruction Cache */ > >> mcr p15, 0, r0, c7, c10, 4 /* Data Synchronization > >> Barrier */ > (snip) > > > > Hmm, I saw problems with i-caches with kernel with WB cache enabled > > instead of WT. > > This patch fixed it for me: > > > > http://people.freebsd.org/~gonzo/arm/patches/pmapv6-icache.diff > > It invalidates i-caches only when new mapping is created, not on every > > switch so > > it should be less taxing on performance. > > > > Could you test it on your setup? = > > It does not help. Also both your patch +PTE SYNC and call always WBINV in > pmap +PTE SYNC don't help. > The kernel applied your patch was failed at first "portsnap fetch" step. > Probably change in pmap is no effect for this segfault. > > Currently, adding invalidate I-cache to swtch.S is only solution. > My test is: > > 1) ping from other freebsd to RPI. > 2) login to RPI, then run "top -PHs1" under pi user. > 3) use simple test (portsnap fetch/extract/build bash) from console. > > Side effect of digging, I found a reason why timer is never fired. > > According to the source, et_min_period.frac set to 2. > This means the start will be called with 1 (frac - 1). > So the routine have only 1us(1MHz) to be finished for the request. > Probably it's impossible even if modern CPU such as 3GHz CPU. > > If failed to setup, it will be fired after 0xffffffff(wrapped about > 4294.9sec). > So, "the interrupt is not fired" is wrong understanding. > The timer will be fired later. Until this, the world seems to have stopped > :) > > This is complete version of systimer patch. > It should fix stopping interrupt and related things such as USB LAN is > unstable, > SSH is closed suddenly. > (I've not yet finished all test at this time, but at least portsnap fetch is > success. > Now extracting the ports without any problems.) > > ---------------------------------------------------------------------- > --- bcm2835_systimer.c (revision 244663) > +++ bcm2835_systimer.c (working copy) > @@ -55,6 +55,7 @@ > > #define DEFAULT_TIMER 3 > #define DEFAULT_FREQUENCY 1000000 > +#define MIN_PERIOD 1000LLU > > #define SYSTIMER_CS 0x00 > #define SYSTIMER_CLO 0x04 > @@ -123,17 +124,20 @@ > struct systimer *st = et->et_priv; > uint32_t clo; > uint32_t count; > + register_t s; > > if (first != NULL) { > - st->enabled = 1; > - > count = (st->et.et_frequency * (first->frac >> 32)) >> 32; > if (first->sec != 0) > count += st->et.et_frequency * first->sec; > > + s = intr_disable(); > clo = bcm_systimer_tc_read_4(SYSTIMER_CLO); > clo += count; > bcm_systimer_tc_write_4(SYSTIMER_C0 + st->index*4, clo); > + st->enabled = 1; > + bcm_systimer_tc_write_4(SYSTIMER_CS, (1 << st->index)); > + intr_restore(s); > > return (0); > } > @@ -154,13 +158,18 @@ > bcm_systimer_intr(void *arg) > { > struct systimer *st = (struct systimer *)arg; > + uint32_t cs; > > + cs = bcm_systimer_tc_read_4(SYSTIMER_CS); > + if ((cs & (1 << st->index)) == 0) > + return (FILTER_STRAY); > + > bcm_systimer_tc_write_4(SYSTIMER_CS, (1 << st->index)); > - if (st->enabled) { > + //if (st->enabled) { > if (st->et.et_active) { > st->et.et_event_cb(&st->et, st->et.et_arg); > } > - } > + //} > > return (FILTER_HANDLED); > } > @@ -226,7 +235,7 @@ > sc->st[DEFAULT_TIMER].et.et_frequency = sc->sysclk_freq; > sc->st[DEFAULT_TIMER].et.et_min_period.sec = 0; > sc->st[DEFAULT_TIMER].et.et_min_period.frac = > - ((0x00000002LLU << 32) / sc->st[DEFAULT_TIMER].et.et_frequency) > << 32; > + ((MIN_PERIOD << 32) / sc->st[DEFAULT_TIMER].et.et_frequency) << > 32; > sc->st[DEFAULT_TIMER].et.et_max_period.sec = 0xfffffff0U / > sc->st[DEFAULT_TIMER].et.et_frequency; > sc->st[DEFAULT_TIMER].et.et_max_period.frac = > ((0xfffffffeLLU << 32) / sc->st[DEFAULT_TIMER].et.et_frequency) > << 32; > ---------------------------------------------------------------------- > Thanks. The thing I don't understand about all this is that I'm not seeing any of the problems you describe, and I can run this sequence you showed: > # rm -rf /var/db/portsnap /usr/ports > # mkdir /var/db/portsnap > # portsnap fetch > # portsnap extract > # cd /usr/ports/shells/bash > # make BATCH=y It works on an SSD drive connected via USB without any errors. I noticed your message said to try it with an sdcard, so I'm preparing an 8gb card now to try that with. But if it fails with sd after working fine with a USB drive, that would make me suspect the sd-related drivers. I don't have any of your patches, I'm just using plain -current @ r244691. I'm using gcc, not clang. I probably do need your timer patch, because I have seen ssh sessions close unexpectedly when the system is idle. But I don't seem to be having any problems involving cache maintence. I even tested that sequence above a second time while running lots of other processes -- a make -j3 kernel-toolchain with other windows running top and vmstat -- just trying to make more process context switches, trying to provoke problems. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Dec 27 16:43:54 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6965FFE5 for ; Thu, 27 Dec 2012 16:43:54 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) by mx1.freebsd.org (Postfix) with ESMTP id D2A178FC16 for ; Thu, 27 Dec 2012 16:43:53 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id ED56B39FA3; Fri, 28 Dec 2012 01:43:51 +0900 (JST) Received: from artemis (unknown [172.18.0.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id D83B939D5E; Fri, 28 Dec 2012 01:43:51 +0900 (JST) Message-ID: <234E1E18AC1C4A3985D6C570F78698E6@ad.peach.ne.jp> From: "Daisuke Aoyama" To: "Ian Lepore" References: <2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp> <1356624694.1144.67.camel@revolution.hippie.lan> In-Reply-To: <1356624694.1144.67.camel@revolution.hippie.lan> Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Date: Fri, 28 Dec 2012 01:43:47 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 16:43:54 -0000 >> >>> PTE sync - related part, Im not sure it's strictly required. We use >> >>> WT >> >>> caches for page tables >> >>> so we should be OK without implicit sync operations for them. I hope >> >>> somebody >> >>> more clueful can confirm/disprove this. >> >> >> >> Some digging, I notice "Invalidate Entire Instruction Cache" works >> >> without segfault. >> >> So, Invalidate D-cache is no effect :) >> >> >> >> It seems following should work for this issue: >> >> >> >> mov r0, #0 >> >> mcr p15, 0, r0, c7, c5, 0 /* Invalidate Entire >> >> Instruction Cache */ >> >> mcr p15, 0, r0, c7, c10, 4 /* Data Synchronization >> >> Barrier */ >> (snip) >> > >> > Hmm, I saw problems with i-caches with kernel with WB cache enabled >> > instead of WT. >> > This patch fixed it for me: >> > >> > http://people.freebsd.org/~gonzo/arm/patches/pmapv6-icache.diff >> > It invalidates i-caches only when new mapping is created, not on every >> > switch so >> > it should be less taxing on performance. >> > >> > Could you test it on your setup? = >> >> It does not help. Also both your patch +PTE SYNC and call always WBINV in >> pmap +PTE SYNC don't help. >> The kernel applied your patch was failed at first "portsnap fetch" step. >> Probably change in pmap is no effect for this segfault. >> >> Currently, adding invalidate I-cache to swtch.S is only solution. >> My test is: >> >> 1) ping from other freebsd to RPI. >> 2) login to RPI, then run "top -PHs1" under pi user. >> 3) use simple test (portsnap fetch/extract/build bash) from console. >> >> Side effect of digging, I found a reason why timer is never fired. >> >> According to the source, et_min_period.frac set to 2. >> This means the start will be called with 1 (frac - 1). >> So the routine have only 1us(1MHz) to be finished for the request. >> Probably it's impossible even if modern CPU such as 3GHz CPU. >> >> If failed to setup, it will be fired after 0xffffffff(wrapped about >> 4294.9sec). >> So, "the interrupt is not fired" is wrong understanding. >> The timer will be fired later. Until this, the world seems to have >> stopped >> :) >> >> This is complete version of systimer patch. >> It should fix stopping interrupt and related things such as USB LAN is >> unstable, >> SSH is closed suddenly. >> (I've not yet finished all test at this time, but at least portsnap fetch >> is >> success. >> Now extracting the ports without any problems.) >> >> ---------------------------------------------------------------------- >> --- bcm2835_systimer.c (revision 244663) >> +++ bcm2835_systimer.c (working copy) >> @@ -55,6 +55,7 @@ >> >> #define DEFAULT_TIMER 3 >> #define DEFAULT_FREQUENCY 1000000 >> +#define MIN_PERIOD 1000LLU >> >> #define SYSTIMER_CS 0x00 >> #define SYSTIMER_CLO 0x04 >> @@ -123,17 +124,20 @@ >> struct systimer *st = et->et_priv; >> uint32_t clo; >> uint32_t count; >> + register_t s; >> >> if (first != NULL) { >> - st->enabled = 1; >> - >> count = (st->et.et_frequency * (first->frac >> 32)) >> >> 32; >> if (first->sec != 0) >> count += st->et.et_frequency * first->sec; >> >> + s = intr_disable(); >> clo = bcm_systimer_tc_read_4(SYSTIMER_CLO); >> clo += count; >> bcm_systimer_tc_write_4(SYSTIMER_C0 + st->index*4, clo); >> + st->enabled = 1; >> + bcm_systimer_tc_write_4(SYSTIMER_CS, (1 << st->index)); >> + intr_restore(s); >> >> return (0); >> } >> @@ -154,13 +158,18 @@ >> bcm_systimer_intr(void *arg) >> { >> struct systimer *st = (struct systimer *)arg; >> + uint32_t cs; >> >> + cs = bcm_systimer_tc_read_4(SYSTIMER_CS); >> + if ((cs & (1 << st->index)) == 0) >> + return (FILTER_STRAY); >> + >> bcm_systimer_tc_write_4(SYSTIMER_CS, (1 << st->index)); >> - if (st->enabled) { >> + //if (st->enabled) { >> if (st->et.et_active) { >> st->et.et_event_cb(&st->et, st->et.et_arg); >> } >> - } >> + //} >> >> return (FILTER_HANDLED); >> } >> @@ -226,7 +235,7 @@ >> sc->st[DEFAULT_TIMER].et.et_frequency = sc->sysclk_freq; >> sc->st[DEFAULT_TIMER].et.et_min_period.sec = 0; >> sc->st[DEFAULT_TIMER].et.et_min_period.frac = >> - ((0x00000002LLU << 32) / >> sc->st[DEFAULT_TIMER].et.et_frequency) >> << 32; >> + ((MIN_PERIOD << 32) / sc->st[DEFAULT_TIMER].et.et_frequency) >> << >> 32; >> sc->st[DEFAULT_TIMER].et.et_max_period.sec = 0xfffffff0U / >> sc->st[DEFAULT_TIMER].et.et_frequency; >> sc->st[DEFAULT_TIMER].et.et_max_period.frac = >> ((0xfffffffeLLU << 32) / >> sc->st[DEFAULT_TIMER].et.et_frequency) >> << 32; >> ---------------------------------------------------------------------- >> Thanks. > > The thing I don't understand about all this is that I'm not seeing any > of the problems you describe, and I can run this sequence you showed: > >> # rm -rf /var/db/portsnap /usr/ports >> # mkdir /var/db/portsnap >> # portsnap fetch >> # portsnap extract >> # cd /usr/ports/shells/bash >> # make BATCH=y > > It works on an SSD drive connected via USB without any errors. I > noticed your message said to try it with an sdcard, so I'm preparing an > 8gb card now to try that with. But if it fails with sd after working > fine with a USB drive, that would make me suspect the sd-related > drivers. Thank you for a comment. Probably it may be clang issue. I didn't check with gcc. > I don't have any of your patches, I'm just using plain -current @ > r244691. I'm using gcc, not clang. I probably do need your timer > patch, because I have seen ssh sessions close unexpectedly when the > system is idle. Now I have uploaded the patch contains the systimer patch. Please take the part of this patch if you are interested in. http://www.peach.ne.jp/archives/rpi/patch/src-244663-20121228.patch.gz For clang user, this pre-build version can be used: http://www.peach.ne.jp/archives/rpi/test/kernel-20121228.gz Thanks. -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Thu Dec 27 22:42:26 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D8FF48EC; Thu, 27 Dec 2012 22:42:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A610F8FC0A; Thu, 27 Dec 2012 22:42:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qBRMgJwl023862; Thu, 27 Dec 2012 17:42:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBRMgJgk023832; Thu, 27 Dec 2012 22:42:19 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 27 Dec 2012 22:42:19 GMT Message-Id: <201212272242.qBRMgJgk023832@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 22:42:26 -0000 TB --- 2012-12-27 21:30:31 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2012-12-27 21:30:31 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-27 21:30:31 - starting HEAD tinderbox run for arm/arm TB --- 2012-12-27 21:30:31 - cleaning the object tree TB --- 2012-12-27 21:31:40 - /usr/local/bin/svn stat /src TB --- 2012-12-27 21:31:43 - At svn revision 244753 TB --- 2012-12-27 21:31:44 - building world TB --- 2012-12-27 21:31:44 - CROSS_BUILD_TESTING=YES TB --- 2012-12-27 21:31:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-27 21:31:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-27 21:31:44 - SRCCONF=/dev/null TB --- 2012-12-27 21:31:44 - TARGET=arm TB --- 2012-12-27 21:31:44 - TARGET_ARCH=arm TB --- 2012-12-27 21:31:44 - TZ=UTC TB --- 2012-12-27 21:31:44 - __MAKE_CONF=/dev/null TB --- 2012-12-27 21:31:44 - cd /src TB --- 2012-12-27 21:31:44 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Dec 27 21:31:48 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Dec 27 22:29:17 UTC 2012 TB --- 2012-12-27 22:29:17 - generating LINT kernel config TB --- 2012-12-27 22:29:17 - cd /src/sys/arm/conf TB --- 2012-12-27 22:29:17 - /usr/bin/make -B LINT TB --- 2012-12-27 22:29:17 - cd /src/sys/arm/conf TB --- 2012-12-27 22:29:17 - /usr/sbin/config -m LINT TB --- 2012-12-27 22:29:17 - building LINT kernel TB --- 2012-12-27 22:29:17 - CROSS_BUILD_TESTING=YES TB --- 2012-12-27 22:29:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-27 22:29:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-27 22:29:17 - SRCCONF=/dev/null TB --- 2012-12-27 22:29:17 - TARGET=arm TB --- 2012-12-27 22:29:17 - TARGET_ARCH=arm TB --- 2012-12-27 22:29:17 - TZ=UTC TB --- 2012-12-27 22:29:17 - __MAKE_CONF=/dev/null TB --- 2012-12-27 22:29:17 - cd /src TB --- 2012-12-27 22:29:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Dec 27 22:29:17 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -ffreestanding -Werror /src/sys/arm/arm/swtch.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -ffreestanding -Werror /src/sys/arm/arm/sys_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -ffreestanding -Werror /src/sys/arm/arm/trap.c cc1: warnings being treated as errors In file included from /src/sys/arm/arm/trap.c:900: /src/sys/arm/arm/../../kern/subr_syscall.c: In function 'syscallenter': /src/sys/arm/arm/../../kern/subr_syscall.c:80: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] /src/sys/arm/arm/../../kern/subr_syscall.c:154: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] *** [trap.o] Error code 1 Stop in /obj/arm.arm/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-27 22:42:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-27 22:42:19 - ERROR: failed to build LINT kernel TB --- 2012-12-27 22:42:19 - 3193.02 user 665.77 system 4308.15 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Fri Dec 28 15:33:32 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4EB7438F; Fri, 28 Dec 2012 15:33:32 +0000 (UTC) (envelope-from shurd@sasktel.net) Received: from mail111c7.megamailservers.com (mail111c7.megamailservers.com [69.49.98.211]) by mx1.freebsd.org (Postfix) with ESMTP id BDB2A8FC14; Fri, 28 Dec 2012 15:33:31 +0000 (UTC) X-Authenticated-User: hurds.sasktel.net Received: from stephen.hurd.local (ip70-187-145-241.oc.oc.cox.net [70.187.145.241]) (authenticated bits=0) by mail111c7.megamailservers.com (8.13.6/8.13.1) with ESMTP id qBSFXLY5013938; Fri, 28 Dec 2012 10:33:22 -0500 Message-ID: <50DDBBC0.7070306@sasktel.net> Date: Fri, 28 Dec 2012 07:33:20 -0800 From: Stephen Hurd User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121022 Firefox/16.0 SeaMonkey/2.13.1 MIME-Version: 1.0 To: Oleksandr Tymoshenko Subject: Re: svn commit: r244758 - head/sys/arm/broadcom/bcm2835 References: <201212280138.qBS1chFm022181@svn.freebsd.org> In-Reply-To: <201212280138.qBS1chFm022181@svn.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CSC: 0 X-CHA: v=1.1 cv=2sEl+nYIWn3GVGOYG7vvzr4q0iGv5BXujfxzLqGOH1s= c=1 sm=1 a=sd1-78TbSwQA:10 a=h_uZHXPN_y0A:10 a=YxfxW3ofkq8A:10 a=8nJEP1OIZ-IA:10 a=qWhSLQ/2FgUpSQgLv9E1tw==:17 a=6I5d2MoRAAAA:8 a=GVGP_v-ml0a0xz5ZjDAA:9 a=wPNLvfGTeEIA:10 a=qWhSLQ/2FgUpSQgLv9E1tw==:117 X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A020201.50DDBBC3.0028, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 15:33:32 -0000 Oleksandr Tymoshenko wrote: > Author: gonzo > Date: Fri Dec 28 01:38:43 2012 > New Revision: 244758 > URL: http://svnweb.freebsd.org/changeset/base/244758 > > Log: > Fix event timer on Raspberry Pi > > - Disable interrupt when updating compare value in order to > make this operation atomical > > - Increase minimum period for event timer. Systimer on BCM2835 > is compare timer, so if minimum period is too small it might > be less then fraction of time between "read current value" and > "set compare timer" operations. It means that when timer is armed > actual counter value is more then compare value and it will take > whole cycle (~32sec for 1MHz timer) to fire interrupt. > > Submitted by: Daisuke Aoyama This seems to have fixed the long hang issue I was having... package building ran overnight without the clock losing time or any hangs occuring. Thanks! From owner-freebsd-arm@FreeBSD.ORG Fri Dec 28 16:42:07 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89708F7C for ; Fri, 28 Dec 2012 16:42:07 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0B07A8FC0A for ; Fri, 28 Dec 2012 16:42:05 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 649A539FA3; Sat, 29 Dec 2012 01:41:58 +0900 (JST) Received: from artemis (unknown [172.18.0.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id 4F0C839D5E; Sat, 29 Dec 2012 01:41:58 +0900 (JST) Message-ID: <9ED42265200A41B1BD637682720E0E9D@ad.peach.ne.jp> From: "Daisuke Aoyama" To: "Daisuke Aoyama" References: <2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp> <1356624694.1144.67.camel@revolution.hippie.lan> <234E1E18AC1C4A3985D6C570F78698E6@ad.peach.ne.jp> In-Reply-To: <234E1E18AC1C4A3985D6C570F78698E6@ad.peach.ne.jp> Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Date: Sat, 29 Dec 2012 01:41:53 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 16:42:07 -0000 >>> This is complete version of systimer patch. >>> It should fix stopping interrupt and related things such as USB LAN is >>> unstable, >>> SSH is closed suddenly. >>> (I've not yet finished all test at this time, but at least portsnap >>> fetch is >>> success. >>> Now extracting the ports without any problems.) Finished without any problems. I'm checking the alignment of clang now. It seems no difference of location of data structure. However, access method is different. I learned clang will combine two loads into one op. This is a reason why the alignment seems difference between clang and gcc. Also, a reason why clang binary is smaller than gcc code. According to ARM manual, strd alignment is: "The address must be a multiple of eight for doubleword transfers." uboot/lib/api_public.h: ---------------------------------------------------------------------- struct sys_info { unsigned long clk_bus; unsigned long clk_cpu; unsigned long bar; struct mem_region *mr; /* << mr offset is 12!! (not DW aligned) */ int mr_no; /* number of memory regions */ }; uboot/lib/glue.c: ---------------------------------------------------------------------- struct sys_info * ub_get_sys_info(void) { int err = 0; memset(&si, 0, sizeof(struct sys_info)); si.mr = mr; si.mr_no = UB_MAX_MR; memset(&mr, 0, sizeof(mr)); if (!syscall(API_GET_SYS_INFO, &err, (u_int32_t)&si)) return (NULL); return ((err) ? NULL : &si); } ---------------------------------------------------------------------- clang -O2 output (7 steps): bl memset ; ATPCS uses r0-r3 as parameters ldr r0, .LCPI6_1 ; mr mov r1, #5 ; UB_MAX_MR mov r2, #60 ; sizeof(mr) strd r0, r1, [r5, #12] ; r5 aligned but strd requires DW(8byte) alignment (faulted here) mov r1, #0 bl memset ; memset(&mr, 0, sizeof(mr)); clang final binary size(2.8% smaller): -rwxr-xr-x 1 root wheel 235984 Dec 28 23:49 ubldr ---------------------------------------------------------------------- gcc 4.2 -O2 output (9 steps): bl memset ; ATPCS uses r0-r3 as parameters ldr ip, .L162+4 ; mr mov r3, #5 ; UB_MAX_MR mov r1, r4 ; r4 is zero mov r0, ip ; << what?? mov r2, #60 ; sizeof(mr) str r3, [r6, #16] ; r6 aligned same as clang str ip, [r6, #12] ; r6 aligned same as clang bl memset ; memset(&mr, 0, sizeof(mr)); gcc final binary size: -rwxr-xr-x 1 root wheel 242810 Dec 28 18:22 ubldr ---------------------------------------------------------------------- I don't know gcc 4.3 or newer, but probably output is more smart. It seems that there is no reason to use ip in this case. Does any one know how to prevent above clang output? (or how to solve this issue for all codes.) Thanks -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Fri Dec 28 16:47:52 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7BBC11000; Fri, 28 Dec 2012 16:47:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) by mx1.freebsd.org (Postfix) with ESMTP id CC1088FC08; Fri, 28 Dec 2012 16:47:51 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id t49so5113575wey.0 for ; Fri, 28 Dec 2012 08:47:44 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YAzhJDFjsSEWLWiT0/4oZO+/AFDTKZwD7FsCEQQ29eU=; b=asBiUtFZQuHIuI/qjAi7eCEgjWgOCZK9BxIJ1XVPulUUZI6p/M26N1cQdru7NXZ2FQ 1b5C6xDOsA12cifVQZ/l/CkC4TGmfxlEB+DHIMGa1CEnT1d7Ss8kVkCFihq/VEXa1fS8 BRLU4thVX+HqBsIplUEdz9Ci1EtGL2scge/Y3xSGbDjR0uhYrWHydi/WdG5dQrYanEbG AvwqsTP087K/kUA5zM7yZak5jzPNktlSDgGr9lgoz2xRrS+UH96oHYtKlSt1yHdDyrTZ My5XXwDFpV6ICQtmEddvPw3Y6uCNoodWn8FCk9H90xJGqUCzNsswKp77azrWajJVbwMq aU9Q== MIME-Version: 1.0 Received: by 10.180.8.130 with SMTP id r2mr46389623wia.28.1356713264727; Fri, 28 Dec 2012 08:47:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Fri, 28 Dec 2012 08:47:44 -0800 (PST) In-Reply-To: <9ED42265200A41B1BD637682720E0E9D@ad.peach.ne.jp> References: <2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp> <1356624694.1144.67.camel@revolution.hippie.lan> <234E1E18AC1C4A3985D6C570F78698E6@ad.peach.ne.jp> <9ED42265200A41B1BD637682720E0E9D@ad.peach.ne.jp> Date: Fri, 28 Dec 2012 08:47:44 -0800 X-Google-Sender-Auth: FLDfvQk_u6ajYAK9qKAWe8iesDI Message-ID: Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) From: Adrian Chadd To: Daisuke Aoyama , David Chisnall Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 16:47:52 -0000 .. the compiler should know the alignment for each of those types and pad the structure appropriately, right? david - what's the "right" behaviour here? Surely clang should be inserting 4 bytes of padding before that pointer? Adrian On 28 December 2012 08:41, Daisuke Aoyama wrote: >>>> This is complete version of systimer patch. >>>> It should fix stopping interrupt and related things such as USB LAN is >>>> unstable, >>>> SSH is closed suddenly. >>>> (I've not yet finished all test at this time, but at least portsnap >>>> fetch is >>>> success. >>>> Now extracting the ports without any problems.) > > > Finished without any problems. > > > I'm checking the alignment of clang now. It seems no difference of location > of data structure. > However, access method is different. > > I learned clang will combine two loads into one op. > This is a reason why the alignment seems difference between clang and gcc. > Also, a reason why clang binary is smaller than gcc code. > > According to ARM manual, strd alignment is: > "The address must be a multiple of eight for doubleword transfers." > > uboot/lib/api_public.h: > ---------------------------------------------------------------------- > struct sys_info { > unsigned long clk_bus; > unsigned long clk_cpu; > unsigned long bar; > struct mem_region *mr; /* << mr offset is 12!! (not DW > aligned) */ > int mr_no; /* number of memory regions */ > }; > > uboot/lib/glue.c: > ---------------------------------------------------------------------- > struct sys_info * > ub_get_sys_info(void) > { > int err = 0; > > memset(&si, 0, sizeof(struct sys_info)); > si.mr = mr; > si.mr_no = UB_MAX_MR; > memset(&mr, 0, sizeof(mr)); > > if (!syscall(API_GET_SYS_INFO, &err, (u_int32_t)&si)) > return (NULL); > > return ((err) ? NULL : &si); > } > > ---------------------------------------------------------------------- > clang -O2 output (7 steps): > bl memset ; ATPCS uses r0-r3 as parameters > ldr r0, .LCPI6_1 ; mr > mov r1, #5 ; UB_MAX_MR > mov r2, #60 ; sizeof(mr) > strd r0, r1, [r5, #12] ; r5 aligned but strd requires DW(8byte) > alignment (faulted here) > mov r1, #0 > bl memset ; memset(&mr, 0, sizeof(mr)); > > clang final binary size(2.8% smaller): > -rwxr-xr-x 1 root wheel 235984 Dec 28 23:49 ubldr > ---------------------------------------------------------------------- > gcc 4.2 -O2 output (9 steps): > bl memset ; ATPCS uses r0-r3 as parameters > ldr ip, .L162+4 ; mr > mov r3, #5 ; UB_MAX_MR > mov r1, r4 ; r4 is zero > mov r0, ip ; << what?? > mov r2, #60 ; sizeof(mr) > str r3, [r6, #16] ; r6 aligned same as clang > str ip, [r6, #12] ; r6 aligned same as clang > bl memset ; memset(&mr, 0, sizeof(mr)); > > gcc final binary size: > -rwxr-xr-x 1 root wheel 242810 Dec 28 18:22 ubldr > ---------------------------------------------------------------------- > I don't know gcc 4.3 or newer, but probably output is more smart. > It seems that there is no reason to use ip in this case. > > Does any one know how to prevent above clang output? > (or how to solve this issue for all codes.) > > Thanks > > -- > Daisuke Aoyama > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Fri Dec 28 16:55:32 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4DB37229 for ; Fri, 28 Dec 2012 16:55:32 +0000 (UTC) (envelope-from tadashi.takahashi@nifty.com) Received: from condef005-v.nifty.com (condef005-v.nifty.com [210.131.4.242]) by mx1.freebsd.org (Postfix) with ESMTP id E8BD08FC08 for ; Fri, 28 Dec 2012 16:55:31 +0000 (UTC) Received: from userg506.nifty.com ([10.22.128.86])by condef005-v.nifty.com with ESMTP id qBSGnXeF021934 for ; Sat, 29 Dec 2012 01:49:33 +0900 Received: from simba (nttkyo031194.tkyo.nt.ngn.ppp.infoweb.ne.jp [115.176.188.194])by userg506.nifty.com with ESMTP id qBSGnGxn012199 for ; Sat, 29 Dec 2012 01:49:16 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=mar2011msa; t=1356713356; bh=QC+oHYQuAlffyTsrFWmxv2NOSAjJRVKAAgJ2dokPY/E=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=r7nS5RrEEslMiAMH07X6fpVdxZhycDbOKRqaP+7jWk1swBQD/x82ls738vFb2CLdE DtciAVbkPF/SXVXOBJagJfq+rzWlvfKoilxh8xIhxbHO8lpOMafGX7aAcOWgGmYLp8 p/H1DMKdds6w0sHttVQ1zub7Z8eUhbWSjFiRFCB8= X-Nifty-SrcIP: [115.176.188.194] From: "Tadashi Takahashi" To: References: <201212280138.qBS1chFm022181@svn.freebsd.org> <50DDBBC0.7070306@sasktel.net> In-Reply-To: <50DDBBC0.7070306@sasktel.net> Subject: RE: svn commit: r244758 - head/sys/arm/broadcom/bcm2835 Date: Sat, 29 Dec 2012 01:49:09 +0900 Message-ID: <000101cde51b$42546fc0$c6fd4f40$@nifty.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEqXsdPIXsDFQE6EDvLL+llNZO/kgMmhmR4mVxEZrA= Content-Language: en-us X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 16:55:32 -0000 Hi developers, I also believe the stability is much better than before. I did below operations on both RPI-B 256MB and RPI-B 512MB systems. There is no core dump nor freeze. - check out src and ports tree by using cvs over network. - self buildworld is still running. - port build without trouble - perl, apache, mysql, bash ... Thank you for excellent job, Tadashi Takahashi -----Original Message----- From: owner-freebsd-arm@freebsd.org [mailto:owner-freebsd-arm@freebsd.org] On Behalf Of Stephen Hurd Sent: Saturday, December 29, 2012 12:33 AM To: Oleksandr Tymoshenko Cc: freebsd-arm@freebsd.org Subject: Re: svn commit: r244758 - head/sys/arm/broadcom/bcm2835 Oleksandr Tymoshenko wrote: > Author: gonzo > Date: Fri Dec 28 01:38:43 2012 > New Revision: 244758 > URL: http://svnweb.freebsd.org/changeset/base/244758 > > Log: > Fix event timer on Raspberry Pi > > - Disable interrupt when updating compare value in order to > make this operation atomical > > - Increase minimum period for event timer. Systimer on BCM2835 > is compare timer, so if minimum period is too small it might > be less then fraction of time between "read current value" and > "set compare timer" operations. It means that when timer is armed > actual counter value is more then compare value and it will take > whole cycle (~32sec for 1MHz timer) to fire interrupt. > > Submitted by: Daisuke Aoyama This seems to have fixed the long hang issue I was having... package building ran overnight without the clock losing time or any hangs occuring. Thanks! _______________________________________________ freebsd-arm@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Fri Dec 28 17:13:44 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B45F418; Fri, 28 Dec 2012 17:13:44 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id D2CEA8FC16; Fri, 28 Dec 2012 17:13:43 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBSHDafK044048; Fri, 28 Dec 2012 10:13:36 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBSHDXh3076321; Fri, 28 Dec 2012 10:13:33 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp> <1356624694.1144.67.camel@revolution.hippie.lan> <234E1E18AC1C4A3985D6C570F78698E6@ad.peach.ne.jp> <9ED42265200A41B1BD637682720E0E9D@ad.peach.ne.jp> Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Dec 2012 10:13:33 -0700 Message-ID: <1356714813.1144.92.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: David Chisnall , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 17:13:44 -0000 It shouldn't be padding, the pointer is aligned correctly. The problem is that it's optimizing a pair of word stores into a single doubleword store when the alignment of the pair doesn't allow that optimization. Some arm hardware allows unaligned access, other hardware doesn't, so maybe we should be setting some clang optimization flag to let it know what's legal for the target platform? -- Ian On Fri, 2012-12-28 at 08:47 -0800, Adrian Chadd wrote: > .. the compiler should know the alignment for each of those types and > pad the structure appropriately, right? > > david - what's the "right" behaviour here? Surely clang should be > inserting 4 bytes of padding before that pointer? > > > > Adrian > > > On 28 December 2012 08:41, Daisuke Aoyama wrote: > >>>> This is complete version of systimer patch. > >>>> It should fix stopping interrupt and related things such as USB LAN is > >>>> unstable, > >>>> SSH is closed suddenly. > >>>> (I've not yet finished all test at this time, but at least portsnap > >>>> fetch is > >>>> success. > >>>> Now extracting the ports without any problems.) > > > > > > Finished without any problems. > > > > > > I'm checking the alignment of clang now. It seems no difference of location > > of data structure. > > However, access method is different. > > > > I learned clang will combine two loads into one op. > > This is a reason why the alignment seems difference between clang and gcc. > > Also, a reason why clang binary is smaller than gcc code. > > > > According to ARM manual, strd alignment is: > > "The address must be a multiple of eight for doubleword transfers." > > > > uboot/lib/api_public.h: > > ---------------------------------------------------------------------- > > struct sys_info { > > unsigned long clk_bus; > > unsigned long clk_cpu; > > unsigned long bar; > > struct mem_region *mr; /* << mr offset is 12!! (not DW > > aligned) */ > > int mr_no; /* number of memory regions */ > > }; > > > > uboot/lib/glue.c: > > ---------------------------------------------------------------------- > > struct sys_info * > > ub_get_sys_info(void) > > { > > int err = 0; > > > > memset(&si, 0, sizeof(struct sys_info)); > > si.mr = mr; > > si.mr_no = UB_MAX_MR; > > memset(&mr, 0, sizeof(mr)); > > > > if (!syscall(API_GET_SYS_INFO, &err, (u_int32_t)&si)) > > return (NULL); > > > > return ((err) ? NULL : &si); > > } > > > > ---------------------------------------------------------------------- > > clang -O2 output (7 steps): > > bl memset ; ATPCS uses r0-r3 as parameters > > ldr r0, .LCPI6_1 ; mr > > mov r1, #5 ; UB_MAX_MR > > mov r2, #60 ; sizeof(mr) > > strd r0, r1, [r5, #12] ; r5 aligned but strd requires DW(8byte) > > alignment (faulted here) > > mov r1, #0 > > bl memset ; memset(&mr, 0, sizeof(mr)); > > > > clang final binary size(2.8% smaller): > > -rwxr-xr-x 1 root wheel 235984 Dec 28 23:49 ubldr > > ---------------------------------------------------------------------- > > gcc 4.2 -O2 output (9 steps): > > bl memset ; ATPCS uses r0-r3 as parameters > > ldr ip, .L162+4 ; mr > > mov r3, #5 ; UB_MAX_MR > > mov r1, r4 ; r4 is zero > > mov r0, ip ; << what?? > > mov r2, #60 ; sizeof(mr) > > str r3, [r6, #16] ; r6 aligned same as clang > > str ip, [r6, #12] ; r6 aligned same as clang > > bl memset ; memset(&mr, 0, sizeof(mr)); > > > > gcc final binary size: > > -rwxr-xr-x 1 root wheel 242810 Dec 28 18:22 ubldr > > ---------------------------------------------------------------------- > > I don't know gcc 4.3 or newer, but probably output is more smart. > > It seems that there is no reason to use ip in this case. > > > > Does any one know how to prevent above clang output? > > (or how to solve this issue for all codes.) > > > > Thanks > > > > -- > > Daisuke Aoyama > > > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Fri Dec 28 21:09:16 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 057EE262 for ; Fri, 28 Dec 2012 21:09:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by mx1.freebsd.org (Postfix) with ESMTP id A812D8FC12 for ; Fri, 28 Dec 2012 21:09:15 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id c12so13511684ieb.9 for ; Fri, 28 Dec 2012 13:09:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=RUBDMaOp6vcMhszYBTknYGJ+0o88fXIA2dKflLgRxMI=; b=kcVTR/l38QcNM3tp/rUj2mSpAU/DtVCjDCFTy/oiCnIPEOiEqJU8CbY+04++L0tJ6w 4Z83pVfCBFOx9aKw/E3deCiNiN34Pg50xejCdWlEfQlpttDz7655sgWx64NTFoELiQaH GinSYwddD0tyV/F93o42aOxh50zokk/8KVOOC3s7K20jNP+0mSJ0YDHAGFyVH8lFW45t bUbk7Ow+DOCGAAOcS4M19MSj9G+jd6fxhx9zsNMKhzY5yk6dwc03hflVaAYQRtLECPy5 QB6yeviExgyDA62NXLvq8XRQIOnxe5pDxLFqXx8pUfIr5gkST0dA797bHLsC9kxg4hre QlUQ== X-Received: by 10.50.153.200 with SMTP id vi8mr25518606igb.79.1356728948782; Fri, 28 Dec 2012 13:09:08 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id lu10sm21531664igc.15.2012.12.28.13.09.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 28 Dec 2012 13:09:07 -0800 (PST) Sender: Warner Losh Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Fri, 28 Dec 2012 14:09:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp> <1356624694.1144.67.camel@revolution.hippie.lan> <234E1E18AC1C4A3985D6C570F78698E6@ad.peach.ne.jp> <9ED42265200A41B1BD637682720E0E9D@ad.peach.ne.jp> To: Adrian Chadd X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmGHJzB1Q3WHaaR3DH8sqK/QtQPHHf0T+szvjARUEVKkT64tYA+YJxv96gu7JYYrWkuFi6v Cc: David Chisnall , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 21:09:16 -0000 On Dec 28, 2012, at 9:47 AM, Adrian Chadd wrote: > .. the compiler should know the alignment for each of those types and > pad the structure appropriately, right? No, it doesn't. At least traditionally gcc and other compilers will = assume you know what you are doing and use the natural accessors. > david - what's the "right" behaviour here? Surely clang should be > inserting 4 bytes of padding before that pointer? For OABI, no padding is the correct answer. For EABI padding is, I = believe, the right answer. If it matters, and if you are matching an = external standard, be explicit in some way with packed attributes and/or = explicit dummy padding members. Warner >=20 > Adrian >=20 >=20 > On 28 December 2012 08:41, Daisuke Aoyama wrote: >>>>> This is complete version of systimer patch. >>>>> It should fix stopping interrupt and related things such as USB = LAN is >>>>> unstable, >>>>> SSH is closed suddenly. >>>>> (I've not yet finished all test at this time, but at least = portsnap >>>>> fetch is >>>>> success. >>>>> Now extracting the ports without any problems.) >>=20 >>=20 >> Finished without any problems. >>=20 >>=20 >> I'm checking the alignment of clang now. It seems no difference of = location >> of data structure. >> However, access method is different. >>=20 >> I learned clang will combine two loads into one op. >> This is a reason why the alignment seems difference between clang and = gcc. >> Also, a reason why clang binary is smaller than gcc code. >>=20 >> According to ARM manual, strd alignment is: >> "The address must be a multiple of eight for doubleword transfers." >>=20 >> uboot/lib/api_public.h: >> = ---------------------------------------------------------------------- >> struct sys_info { >> unsigned long clk_bus; >> unsigned long clk_cpu; >> unsigned long bar; >> struct mem_region *mr; /* << mr offset is 12!! (not DW >> aligned) */ >> int mr_no; /* number of memory regions */ >> }; >>=20 >> uboot/lib/glue.c: >> = ---------------------------------------------------------------------- >> struct sys_info * >> ub_get_sys_info(void) >> { >> int err =3D 0; >>=20 >> memset(&si, 0, sizeof(struct sys_info)); >> si.mr =3D mr; >> si.mr_no =3D UB_MAX_MR; >> memset(&mr, 0, sizeof(mr)); >>=20 >> if (!syscall(API_GET_SYS_INFO, &err, (u_int32_t)&si)) >> return (NULL); >>=20 >> return ((err) ? NULL : &si); >> } >>=20 >> = ---------------------------------------------------------------------- >> clang -O2 output (7 steps): >> bl memset ; ATPCS uses r0-r3 as parameters >> ldr r0, .LCPI6_1 ; mr >> mov r1, #5 ; UB_MAX_MR >> mov r2, #60 ; sizeof(mr) >> strd r0, r1, [r5, #12] ; r5 aligned but strd requires = DW(8byte) >> alignment (faulted here) >> mov r1, #0 >> bl memset ; memset(&mr, 0, sizeof(mr)); >>=20 >> clang final binary size(2.8% smaller): >> -rwxr-xr-x 1 root wheel 235984 Dec 28 23:49 ubldr >> = ---------------------------------------------------------------------- >> gcc 4.2 -O2 output (9 steps): >> bl memset ; ATPCS uses r0-r3 as parameters >> ldr ip, .L162+4 ; mr >> mov r3, #5 ; UB_MAX_MR >> mov r1, r4 ; r4 is zero >> mov r0, ip ; << what?? >> mov r2, #60 ; sizeof(mr) >> str r3, [r6, #16] ; r6 aligned same as clang >> str ip, [r6, #12] ; r6 aligned same as clang >> bl memset ; memset(&mr, 0, sizeof(mr)); >>=20 >> gcc final binary size: >> -rwxr-xr-x 1 root wheel 242810 Dec 28 18:22 ubldr >> = ---------------------------------------------------------------------- >> I don't know gcc 4.3 or newer, but probably output is more smart. >> It seems that there is no reason to use ip in this case. >>=20 >> Does any one know how to prevent above clang output? >> (or how to solve this issue for all codes.) >>=20 >> Thanks >>=20 >> -- >> Daisuke Aoyama >>=20 >>=20 >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sat Dec 29 20:43:49 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89BD8164 for ; Sat, 29 Dec 2012 20:43:49 +0000 (UTC) (envelope-from ThomasSkibo@sbcglobal.net) Received: from nm12.access.bullet.mail.sp2.yahoo.com (nm12.access.bullet.mail.sp2.yahoo.com [98.139.44.139]) by mx1.freebsd.org (Postfix) with ESMTP id 540E98FC12 for ; Sat, 29 Dec 2012 20:43:49 +0000 (UTC) Received: from [98.139.44.102] by nm12.access.bullet.mail.sp2.yahoo.com with NNFMP; 29 Dec 2012 20:41:03 -0000 Received: from [67.195.22.113] by tm7.access.bullet.mail.sp2.yahoo.com with NNFMP; 29 Dec 2012 20:41:02 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.gq1.yahoo.com with NNFMP; 29 Dec 2012 20:41:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1356813662; bh=KBaLtoNWTPHMu7GTiK1os1BAHrrN8cR0n+PWicKV+oc=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type; b=MT2vJDln8ktp58WQ57n30w2XgyhVaPvkrWLX8anR5TNM+r7ZtvGUCeFVlxj5Rf6JnC3ksaJpDCXZJ/ruxSDT1JYNM2U/YwaG278aYKuX/mXD1zHQtyrYJWNqvPI5zz/Kia47cpn5iwjwuPnrK6W5atJrabRqZ6+Gbxc7vTXYZUU= X-Yahoo-Newman-Id: 697409.47763.bm@smtp115.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: lObExzoVM1lZinTCDrf.O9dJSMaJ71TVGTmsbSIiQvBJRJu NmDFjv7DqxURFtoltl8L3j7c1SRxOE5WHplv0JosVhoBSt2Yld2SVTU3R0mp b5cs5S6xfuf7EjUnlleFDNT6lJzx0gYCEncD0gs6QUjU_Riq5zvfPHwhBwNl 49JyVdp1i3FcXlp_1.K.8Rx8_7N1_C9Egav8OEvFHWLQlKPfqoh.1axSjGpx YbUq5xAQRehbIX51zuR5WFkjXAb24VRDliqaiTee1XNfQAgOX3bhzCnl9UEE OsNbV0wBQuj9EkHNEzhOaTg93BN73FrIEbtQpqW85cun8nO8OWdnoH5yeGTj 6E9QvJQfG1oEkpQOTEtDJDbT1eSgjqW3Yn4NnVyx1v9zkEo05uCj.iGQKN4N XmksII0T7aOmx1OF05SgFTCe8axbn8ai3_xoYWkcFkpVN5zKFu4xEvgRDomw 5a4cCTWUG79KGIB32i7Wl1_uFdVZLfZw5WFeyX5gAMSh2uIcfy6mA8oUcog- - X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- Received: from [192.168.1.9] (ThomasSkibo@71.139.179.229 with plain) by smtp115.sbc.mail.gq1.yahoo.com with SMTP; 29 Dec 2012 12:41:02 -0800 PST Message-ID: <50DF555B.9060601@sbcglobal.net> Date: Sat, 29 Dec 2012 12:40:59 -0800 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: FreeBSD on Zedboard (Xilinx Zynq-7000) References: <50DF4BD9.8080601@sbcglobal.net> In-Reply-To: <50DF4BD9.8080601@sbcglobal.net> Content-Type: multipart/mixed; boundary="------------070705020506020703020902" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 20:43:49 -0000 This is a multi-part message in MIME format. --------------070705020506020703020902 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello. I have been tinkering with this for several weeks: I booted FreeBSD on a Zedboard (a low-cost evaluation board for the Xilinx Zynq-7000 SoC). It was just a matter of coming up with a device tree file, implementing a UART driver, attaching the generic sdhci driver to the Zynq's SD hardware, and adding a new CPU id. I don't have an ethernet driver yet but I've started on it. I created an sdhci_fdt driver based on sdhci_pci.c. It should be useful for other platforms. I won't be surprised if somebody points out there is one already. One thing that stumped me for a while is that the interrupt controller driver, gic.c, does not initialize the priority mask register (GICC_PMR). The boot-loader left it at zero which masked all interrupts. For now, I plug 0xff into it in my initarm_late_init() function in zynq7_machdep.c. I'll provide my source soon. I want to do a few clean-ups of course and I'll take any feed-back on my naming conventions and how I organized the files. Thanks, -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net --------------070705020506020703020902 Content-Type: text/plain; charset=UTF-8; name="boot2.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="boot2.txt" CnplZC1ib290PiB0ZnRwIDB4MTAwMDAwIGtlcm5lbC5iaW4KVXNpbmcgenlucV9nZW0gZGV2 aWNlClRGVFAgZnJvbSBzZXJ2ZXIgMTkyLjE2OC4yLjEwOyBvdXIgSVAgYWRkcmVzcyBpcyAx OTIuMTY4LjIuMTEKRmlsZW5hbWUgJ2tlcm5lbC5iaW4nLgpMb2FkIGFkZHJlc3M6IDB4MTAw MDAwCkxvYWRpbmc6ICoIIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKCSAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwoJICMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj CgkgIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMKCSAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwoJICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCgkgIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMKCSAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIwoJICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwpk b25lCkJ5dGVzIHRyYW5zZmVycmVkID0gMjgyOTc1MiAoMmIyZGI4IGhleCkKemVkLWJvb3Q+ IGdvIDB4MTAwMDAwCiMjIFN0YXJ0aW5nIGFwcGxpY2F0aW9uIGF0IDB4MDAxMDAwMDAgLi4u CktEQjogZGVidWdnZXIgYmFja2VuZHM6IGRkYgpLREI6IGN1cnJlbnQgYmFja2VuZDogZGRi CkNvcHlyaWdodCAoYykgMTk5Mi0yMDEyIFRoZSBGcmVlQlNEIFByb2plY3QuCkNvcHlyaWdo dCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5Miwg MTk5MywgMTk5NAoJVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5p YS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVt YXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24uCkZyZWVCU0QgMTAuMC1DVVJSRU5UICMx NDYgcjI0NDc2OE06IFNhdCBEZWMgMjkgMTA6MTQ6NDMgUFNUIDIwMTIKICAgIHJvb3RAZnJl ZWJzZDovdXNyL29iai9hcm0uYXJtL3Vzci9ob21lL3NraWJvL3NyYy9zeXMvWkVEQk9BUkQg YXJtClByZWxvYWRlZCBlbGYga2VybmVsICJrZXJuZWwiIGF0IDB4YzAzY2RmZDAuCkNQVTog Q29ydGV4IEE5LXIzIHJldiAwIChDb3J0ZXgtQSBjb3JlKQogU3VwcG9ydGVkIGZlYXR1cmVz OiBBUk1fSVNBIFRIVU1CMiBKQVpFTExFIFRIVU1CRUUgQVJNdjQgU2VjdXJpdHlfRXh0CiBX QiBkaXNhYmxlZCBFQUJUIGJyYW5jaCBwcmVkaWN0aW9uIGVuYWJsZWQKTG9VVToyIExvQzox IExvVUlTOjIgCkNhY2hlIGxldmVsIDE6IAogMzJLQi8zMkIgNC13YXkgZGF0YSBjYWNoZSBX QiBSZWFkLUFsbG9jIFdyaXRlLUFsbG9jCiAzMktCLzMyQiA0LXdheSBpbnN0cnVjdGlvbiBj YWNoZSBSZWFkLUFsbG9jCnJlYWwgbWVtb3J5ICA9IDUzNjg3MDkxMiAoNTEyIE1CKQpQaHlz aWNhbCBtZW1vcnkgY2h1bmsocyk6CjB4MDAxMDAwIC0gMHgwZmZmZmYsIDEwNDQ0ODAgYnl0 ZXMgKDI1NSBwYWdlcykKMHg0ODgwMDAgLSAweDFmNWJiZmZmLCA1MjEzNTUyNjQgYnl0ZXMg KDEyNzI4NCBwYWdlcykKYXZhaWwgbWVtb3J5ID0gNTE5NzA4NjcyICg0OTUgTUIpCnJhbmRv bSBkZXZpY2Ugbm90IGxvYWRlZDsgdXNpbmcgaW5zZWN1cmUgZW50cm9weQpudWxsOiA8bnVs bCBkZXZpY2UsIHplcm8gZGV2aWNlPgpvcGVuZmlybTogPE9wZW4gRmlybXdhcmUgY29udHJv bCBkZXZpY2U+CnJhbmRvbTogPGVudHJvcHkgc291cmNlLCBTb2Z0d2FyZSwgWWFycm93Pgpt ZW06IDxtZW1vcnk+CmZkdGJ1czA6IDxGRFQgbWFpbiBidXM+CnNpbXBsZWJ1czA6IDxGbGF0 dGVuZWQgZGV2aWNlIHRyZWUgc2ltcGxlIGJ1cz4gb24gZmR0YnVzMApnaWMwOiA8QVJNIEdl bmVyaWMgSW50ZXJydXB0IENvbnRyb2xsZXI+IG1lbSAweGY4ZjAxMDAwLTB4ZjhmMDFmZmYs MHhmOGYwMDEwMC0weGY4ZjAwMWZmIG9uIHNpbXBsZWJ1czAKZ2ljMDogcG4gMHgzOTAsIGFy Y2ggMHgxLCByZXYgMHgyLCBpbXBsZW1lbnRlciAweDQzYiBuaXJxcyA5NgptcF90bXIwOiA8 QVJNIEdlbmVyaWMgTVBDb3JlIFRpbWVycz4gbWVtIDB4ZjhmMDAyMDAtMHhmOGYwMDJmZiww eGY4ZjAwNjAwLTB4ZjhmMDA2MWYgaXJxIDI3LDI5IG9uIHNpbXBsZWJ1czAKVGltZWNvdW50 ZXIgIkFSTSBNUENvcmUgVGltZWNvdW50ZXIiIGZyZXF1ZW5jeSA1MDAwMDAwMCBIeiBxdWFs aXR5IDEwMDAKRXZlbnQgdGltZXIgIkFSTSBNUENvcmUgRXZlbnR0aW1lciIgZnJlcXVlbmN5 IDUwMDAwMDAwIEh6IHF1YWxpdHkgMTAwMApsMmNhY2hlMDogPFBMMzEwIEwyIGNhY2hlIGNv bnRyb2xsZXI+IG1lbSAweGY4ZjAyMDAwLTB4ZjhmMDJmZmYgb24gc2ltcGxlYnVzMAogIEwy IENhY2hlOiA1MTJLQi8zMkIgOCB3YXlzCnNpbXBsZWJ1czE6IDxGbGF0dGVuZWQgZGV2aWNl IHRyZWUgc2ltcGxlIGJ1cz4gb24gZmR0YnVzMAp1YXJ0MDogPHp5bnE3X3VhcnQ+IG1lbSAw eGUwMDAxMDAwLTB4ZTAwMDFmZmYgaXJxIDgyIG9uIHNpbXBsZWJ1czEKdWFydDA6IGZhc3Qg aW50ZXJydXB0CnVhcnQwOiBjb25zb2xlICgxMTUyMDAsbiw4LDEpCnNkaGNpX2ZkdDA6IDxa eW5xLTcwMDAgZ2VuZXJpYyBmZHQgU0RIQ0kgY29udHJvbGxlcj4gbWVtIDB4ZTAxMDAwMDAt MHhlMDEwMGZmZiBpcnEgNTYgb24gc2ltcGxlYnVzMQpzZGhjaV9mZHQwLXNsb3QwOiA0OE1I eiBIUyA0Yml0cyAzLjNWIERNQQpzZGhjaV9mZHQwLXNsb3QwOiA9PT09PT09PT09PT09PSBS RUdJU1RFUiBEVU1QID09PT09PT09PT09PT09CnNkaGNpX2ZkdDAtc2xvdDA6IFN5cyBhZGRy OiAweDAwMDAwMDAwIHwgVmVyc2lvbjogIDB4MDAwMDg5MDEKc2RoY2lfZmR0MC1zbG90MDog QmxrIHNpemU6IDB4MDAwMDAwMDAgfCBCbGsgY250OiAgMHgwMDAwMDAwMApzZGhjaV9mZHQw LXNsb3QwOiBBcmd1bWVudDogMHgwMDAwMDAwMCB8IFRybiBtb2RlOiAweDAwMDAwMDAwCnNk aGNpX2ZkdDAtc2xvdDA6IFByZXNlbnQ6ICAweDAxZmYwMDAwIHwgSG9zdCBjdGw6IDB4MDAw MDAwMDAKc2RoY2lfZmR0MC1zbG90MDogUG93ZXI6ICAgIDB4MDAwMDAwMDAgfCBCbGsgZ2Fw OiAgMHgwMDAwMDAwMApzZGhjaV9mZHQwLXNsb3QwOiBXYWtlLXVwOiAgMHgwMDAwMDAwMCB8 IENsb2NrOiAgICAweDAwMDAwMDAwCnNkaGNpX2ZkdDAtc2xvdDA6IFRpbWVvdXQ6ICAweDAw MDAwMDAwIHwgSW50IHN0YXQ6IDB4MDAwMDAwMDAKc2RoY2lfZmR0MC1zbG90MDogSW50IGVu YWI6IDB4MDFmZjAwZmIgfCBTaWcgZW5hYjogMHgwMWZmMDBmYgpzZGhjaV9mZHQwLXNsb3Qw OiBBQzEyIGVycjogMHgwMDAwMDAwMCB8IFNsb3QgaW50OiAweDAwMDAwMDAwCnNkaGNpX2Zk dDAtc2xvdDA6IENhcHM6ICAgICAweDY5ZWYzMGIwIHwgTWF4IGN1cnI6IDB4MDAwMDAwMDEK c2RoY2lfZmR0MC1zbG90MDogPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQpzZGhjaV9mZHQwOiAxIHNsb3QocykgYWxsb2NhdGVkCm1tYzA6IDxNTUMvU0Qg YnVzPiBvbiBzZGhjaV9mZHQwClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEwLjAwMCBtc2Vj CnRjcF9pbml0OiBuZXQuaW5ldC50Y3AudGNiaGFzaHNpemUgYXV0byB0dW5lZCB0byA4MTky CmxvMDogYnBmIGF0dGFjaGVkCnNkaGNpX2ZkdDAtc2xvdDA6IERpdmlkZXIgMTI4IGZvciBm cmVxIDE4NzUwMCAobWF4IDQ4MDAwMDAwKQptbWMwOiBQcm9iaW5nIGJ1cwptbWMwOiBTRCAy LjAgaW50ZXJmYWNlIGNvbmRpdGlvbnM6IE9LCm1tYzA6IFNEIHByb2JlOiBPSyAoT0NSOiAw eDAwZmY4MDAwKQptbWMwOiBDdXJyZW50IE9DUjogMHgwMGZmODAwMAptbWMwOiBQcm9iaW5n IGNhcmRzCm1tYzA6IE5ldyBjYXJkIGRldGVjdGVkIChDSUQgMDI1NDRkNTM0MTMwMzQ0NzA2 MjFkNTNmY2IwMGFiMDApCm1tYzA6IE5ldyBjYXJkIGRldGVjdGVkIChDU0QgNDAwZTAwMzI1 YjU5MDAwMDFkNmY3ZjgwMGE0MDAwMDApCm1tYzA6IENhcmQgYXQgcmVsYXRpdmUgYWRkcmVz cyA0NjYwIGFkZGVkOgptbWMwOiAgY2FyZDogU0RIQyBTQTA0RyAwLjYgU04gNTY3NjIzNjI3 IE1GRyAxMS8yMDEwIGJ5IDIgVE0KbW1jMDogIGJ1czogNGJpdCwgNTBNSHosIGhpZ2ggc3Bl ZWQgdGltaW5nCm1tYzA6ICBtZW1vcnk6IDc3MTY4NjQgYmxvY2tzLCBlcmFzZSBzZWN0b3Ig ODE5MiBibG9ja3MKbW1jMDogc2V0dGluZyB0cmFuc2ZlciByYXRlIHRvIDQ4LjAwME1IeiAo aGlnaCBzcGVlZCB0aW1pbmcpCnNkaGNpX2ZkdDAtc2xvdDA6IERpdmlkZXIgMCBmb3IgZnJl cSA0ODAwMDAwMCAobWF4IDQ4MDAwMDAwKQptbWNzZDA6IDM3NjhNQiA8U0RIQyBTQTA0RyAw LjYgU04gNTY3NjIzNjI3IE1GRyAxMS8yMDEwIGJ5IDIgVE0+IGF0IG1tYzAgNDguME1Iei80 Yml0LzY1NTM1LWJsb2NrCkdFT006IG5ldyBkaXNrIG1tY3NkMAptbWMwOiBzZXR0aW5nIGJ1 cyB3aWR0aCB0byA0IGJpdHMKR0VPTV9QQVJUOiBwYXJ0aXRpb24gMSBpcyBub3QgYWxpZ25l ZCBvbiA0MTk0MzA0IGJ5dGVzCkdFT01fUEFSVDogcGFydGl0aW9uIDIgaXMgbm90IGFsaWdu ZWQgb24gNDE5NDMwNCBieXRlcwpHRU9NX1BBUlQ6IHBhcnRpdGlvbiAzIGlzIG5vdCBhbGln bmVkIG9uIDQxOTQzMDQgYnl0ZXMKVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6bW1j c2QwczIgW10uLi4Kd2FybmluZzogbm8gdGltZS1vZi1kYXkgY2xvY2sgcmVnaXN0ZXJlZCwg c3lzdGVtIHRpbWUgd2lsbCBub3QgYmUgc2V0IGFjY3VyYXRlbHkKc3RhcnRfaW5pdDogdHJ5 aW5nIC9zYmluL2luaXQKU2V0dGluZyBob3N0dXVpZDogOTA2N2M5NGMtNTE0ZC0xMWUyLTg1 OGYtYjc3OWU3OWQxZWE3LgpTZXR0aW5nIGhvc3RpZDogMHg3YmI1MmViYy4KTm8gc3VpdGFi bGUgZHVtcCBkZXZpY2Ugd2FzIGZvdW5kLgpFbnRyb3B5IGhhcnZlc3Rpbmc6IGludGVycnVw dHMgZXRoZXJuZXQgcG9pbnRfdG9fcG9pbnRzaGEyNTY6IC9rZXJuZWw6IE5vIHN1Y2ggZmls ZSBvciBkaXJlY3RvcnkKIGtpY2tzdGFydC4KU3RhcnRpbmcgZmlsZSBzeXN0ZW0gY2hlY2tz OgovZGV2L21tY3NkMHMyOiBGSUxFIFNZU1RFTSBDTEVBTjsgU0tJUFBJTkcgQ0hFQ0tTCi9k ZXYvbW1jc2QwczI6IGNsZWFuLCA2OTAxMiBmcmVlICgyOCBmcmFncywgODYyMyBibG9ja3Ms IDAuMCUgZnJhZ21lbnRhdGlvbikKTW91bnRpbmcgbG9jYWwgZmlsZSBzeXN0ZW1zOi4KV3Jp dGluZyBlbnRyb3B5IGZpbGU6LgpTZXR0aW5nIGhvc3RuYW1lOiB6ZWRib2FyZC4KU3RhcnRp bmcgTmV0d29yazogbG8wLgpsbzA6IGZsYWdzPTgwNDk8VVAsTE9PUEJBQ0ssUlVOTklORyxN VUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAxNjM4NAlvcHRpb25zPTYwMDAwMzxSWENTVU0sVFhD U1VNLFJYQ1NVTV9JUFY2LFRYQ1NVTV9JUFY2PgoJaW5ldCAxMjcuMC4wLjEgbmV0bWFzayAw eGZmMDAwMDAwIApTdGFydGluZyBkZXZkLgpDcmVhdGluZyBhbmQvb3IgdHJpbW1pbmcgbG9n IGZpbGVzLgpTdGFydGluZyBzeXNsb2dkLgpzeXNsb2dkOiB0aW1lZCBvdXQgd2FpdGluZyBm b3IgY2hpbGQKL2V0Yy9yYzogV0FSTklORzogZmFpbGVkIHRvIHN0YXJ0IHN5c2xvZ2QKcmVh bHBhdGg6IC9kZXYvZHVtcGRldjogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQovZXRjL3Jj OiBXQVJOSU5HOiBEdW1wIGRldmljZSBkb2VzIG5vdCBleGlzdC4gIFNhdmVjb3JlIG5vdCBy dW4uCkVMRiBsZGNvbmZpZyBwYXRoOiAvbGliIC91c3IvbGliIC91c3IvbGliL2NvbXBhdApD bGVhcmluZyAvdG1wIChYIHJlbGF0ZWQpLgpVcGRhdGluZyBtb3RkOi4KU3RhcnRpbmcgY3Jv bi4KU3RhcnRpbmcgYmFja2dyb3VuZCBmaWxlIHN5c3RlbSBjaGVja3MgaW4gNjAgc2Vjb25k cy4KClNhdCBEZWMgMjkgMDM6NTE6NDkgVVRDIDIwMTIKCkZyZWVCU0QvYXJtICh6ZWRib2Fy ZCkgKHR0eXUwKQoKbG9naW46IHJvb3QKRGVjIDI5IDAzOjUzOjAzIHplZGJvYXJkIGxvZ2lu OiBST09UIExPR0lOIChyb290KSBPTiB0dHl1MApMYXN0IGxvZ2luOiBTYXQgRGVjIDI5IDAz OjEzOjEyIG9uIHR0eXUwCkZyZWVCU0QgMTAuMC1DVVJSRU5UIChaRURCT0FSRCkgIzE0NiBy MjQ0NzY4TTogU2F0IERlYyAyOSAxMDoxNDo0MyBQU1QgMjAxMgoKV2VsY29tZSB0byBGcmVl QlNEIQoKLi4uW2VkaXRlZF0uLi4KCnJvb3RAemVkYm9hcmQ6LyAjIHVuYW1lIC1hCkZyZWVC U0QgemVkYm9hcmQgMTAuMC1DVVJSRU5UIEZyZWVCU0QgMTAuMC1DVVJSRU5UICMxNDYgcjI0 NDc2OE06IFNhdCBEZWMgMjkgMTA6MTQ6NDMgUFNUIDIwMTIgICAgIHJvb3RAZnJlZWJzZDov dXNyL29iai9hcm0uYXJtL3Vzci9ob21lL3NraWJvL3NyYy9zeXMvWkVEQk9BUkQgIGFybQpy b290QHplZGJvYXJkOi8gIyBoYWx0CkRlYyAyOSAwNDowNzozNiB6ZWRib2FyZCBoYWx0OiBo YWx0ZWQgYnkgcm9vdApEZWMgMjkgMDQ6MDc6MzkgemVkYm9hcmQgc3lzbG9nZDogZXhpdGlu ZyBvbiBzaWduYWwgMTUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJv Y2VzcyBgdm5scnUnIHRvIHN0b3AuLi5kb25lCldhaXRpbmcgKG1heCA2MCBzZWNvbmRzKSBm b3Igc3lzdGVtIHByb2Nlc3MgYGJ1ZmRhZW1vbicgdG8gc3RvcC4uLmRvbmUKV2FpdGluZyAo bWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgc3luY2VyJyB0byBzdG9wLi4u ClN5bmNpbmcgZGlza3MsIHZub2RlcyByZW1haW5pbmcuLi4yIDEgMCBkb25lClN5bmNpbmcg ZGlza3MsIGJ1ZmZlcnMgcmVtYWluaW5nLi4uIDYgNiA2IDYgNiA2IDYgNiA2IDYgNSA1IDUg NSA1IDUgNSA1IDUgNSA1IDUgNCA0IDQgNCA0IDQgNCA0IDQgNCA0IDQgMyAzIDMgMyAzIDMg MyAzIDMgMyAzIDMgCkZpbmFsIHN5bmMgY29tcGxldGUKVXB0aW1lOiA1Mm01MXMKClRoZSBv cGVyYXRpbmcgc3lzdGVtIGhhcyBoYWx0ZWQuClBsZWFzZSBwcmVzcyBhbnkga2V5IHRvIHJl Ym9vdC4KCgo= --------------070705020506020703020902-- From owner-freebsd-arm@FreeBSD.ORG Sat Dec 29 20:49:35 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F8DC1E1 for ; Sat, 29 Dec 2012 20:49:35 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-f173.google.com (mail-ia0-f173.google.com [209.85.210.173]) by mx1.freebsd.org (Postfix) with ESMTP id CD56E8FC0C for ; Sat, 29 Dec 2012 20:49:34 +0000 (UTC) Received: by mail-ia0-f173.google.com with SMTP id w21so9697809iac.32 for ; Sat, 29 Dec 2012 12:49:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=Q1bQRjMeHnVQ9pLbwUZtul3gThRBi3y+ojzlzlTsCxQ=; b=P4CFbFqZgxF+KA1KQTkyZsvINHayABPz+rU4kEHpde35YazntXsDSEu6MooxlJLpB3 y1z9pk/SF713P5fZ3diwo8VtWdzvcQbP0yPnTQ1wKnDrH1R2TpN+CeRmMU2hh6Tp1Ib7 cNmJIpKaVsBESiMK/hkcTxVul6fRDlkUopnauDh3bTlmBeOjQ9CCz+LBaW5WizxIs+de czLrt+J4rQBHakFWIDLZkseMSI8jnO9vW3iJrKlS1XFZHE4JlaQhjzu9vqQlnLX8rn6M FT3yRGHqqBTfJXnHpQpGg8t4r7Gxi/0nky4cxWBwcEVFgqmRIFEPZQV5bvoOFaGbY8yu iEow== X-Received: by 10.43.125.133 with SMTP id gs5mr28681077icc.54.1356814168456; Sat, 29 Dec 2012 12:49:28 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ex10sm29620710igc.15.2012.12.29.12.49.26 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 29 Dec 2012 12:49:27 -0800 (PST) Sender: Warner Losh Subject: Re: FreeBSD on Zedboard (Xilinx Zynq-7000) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <50DF555B.9060601@sbcglobal.net> Date: Sat, 29 Dec 2012 13:49:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6285A410-0470-4A75-9067-7C524831A8DA@bsdimp.com> References: <50DF4BD9.8080601@sbcglobal.net> <50DF555B.9060601@sbcglobal.net> To: Thomas Skibo X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQl/zrnt97VXNXOYuia/oyS+AlDqgYdcynZT192x/yBO4TdbEMkC03GID9dwstbgIk6Beyso Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 20:49:35 -0000 Cool! But don't be a tease! Share the code :) Bringing up new platforms is getting easier and easier now that we've = put all the weight behind FDT, eh? Warner On Dec 29, 2012, at 1:40 PM, Thomas Skibo wrote: >=20 > Hello. >=20 > I have been tinkering with this for several weeks: I booted FreeBSD > on a Zedboard (a low-cost evaluation board for the Xilinx Zynq-7000 = SoC). >=20 > It was just a matter of coming up with a device tree file, = implementing > a UART driver, attaching the generic sdhci driver to the Zynq's SD > hardware, and adding a new CPU id. I don't have an ethernet driver = yet > but I've started on it. >=20 > I created an sdhci_fdt driver based on sdhci_pci.c. It should be > useful for other platforms. I won't be surprised if somebody points > out there is one already. >=20 > One thing that stumped me for a while is that the interrupt controller > driver, gic.c, does not initialize the priority mask register > (GICC_PMR). The boot-loader left it at zero which masked all > interrupts. For now, I plug 0xff into it in my initarm_late_init() > function in zynq7_machdep.c. >=20 > I'll provide my source soon. I want to do a few clean-ups of course > and I'll take any feed-back on my naming conventions and how I = organized the files. >=20 > Thanks, >=20 > --=20 > -------- > Thomas Skibo > ThomasSkibo@sbcglobal.net >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sat Dec 29 21:37:41 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9EBA1F63 for ; Sat, 29 Dec 2012 21:37:41 +0000 (UTC) (envelope-from ThomasSkibo@sbcglobal.net) Received: from nm30.access.bullet.mail.mud.yahoo.com (nm30.access.bullet.mail.mud.yahoo.com [66.94.237.95]) by mx1.freebsd.org (Postfix) with ESMTP id 4A2C68FC08 for ; Sat, 29 Dec 2012 21:37:41 +0000 (UTC) Received: from [66.94.237.199] by nm30.access.bullet.mail.mud.yahoo.com with NNFMP; 29 Dec 2012 21:34:57 -0000 Received: from [68.142.198.205] by tm10.access.bullet.mail.mud.yahoo.com with NNFMP; 29 Dec 2012 21:34:57 -0000 Received: from [127.0.0.1] by smtp109.sbc.mail.mud.yahoo.com with NNFMP; 29 Dec 2012 21:34:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1356816897; bh=wEgH7WzQPsmbem3STjeFk3UNsJX3cQYGumaqExLVxm0=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=S84jxLXOAFkjZlm7aGhIsYfzduOk/J1zRkuwEyP15fa/doaF/NKg/x3IL/ntkHKGLCjsRkp5WeLFtl4gkTLnCCWZGfAYggMoVhLDvuKqeXVcckrk2TyNPpeWRdQvJiCl3hPsrC0Ck+GjIvKHoCO4XDGeruful7YYXV5Wyifc6UQ= X-Yahoo-Newman-Id: 353521.30666.bm@smtp109.sbc.mail.mud.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: lkO_ZJgVM1mBVs2m3ndtSeJ_1XF_brEwTo4QYvoQpvbdyVD QuzGRqllzASO5Yah.Gtm8ikjoDpQcRYDtQukukSHh40pb8jrbzJHYw85F9XK Jtc_KZqiA53ZIpoqkiO6jwTrtqsPRdBwsd_QPjRpZPMnSfDTHsZnz7n5mt7Z cNFGpTBhFIbippBshwtCnUCtewxNsxgWUxQW1gKNSaj9Klx05sHFHNRIs6Q3 rVJ1MZxM2i6oRVAJwoIzZoCWOrDf_Sw56Dd0ouUIjXAwNDV.LUNA5anC.2DB GMxu1GwmtCBhUxas386xSVXNqzOFf1wJy3stVU6evvKNZ1v8TAal.tMhpUgZ 9gHPd9aBco7zMZw5zKYlX.BrliFL6BflwL7S2r.DorXuIo6nYSaXw2d2nzwF gLHPNJ3oVnY0Oyt2NhsBD8IPYufhCy1NrkX2._HJBycta_4rV_QDLPg0spB6 xrjjWZKDtFg..wfWZhrdmP3W87fqPmDrNkZpnHYou X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- Received: from [192.168.1.9] (ThomasSkibo@71.139.179.229 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 29 Dec 2012 13:34:57 -0800 PST Message-ID: <50DF61FE.2030609@sbcglobal.net> Date: Sat, 29 Dec 2012 13:34:54 -0800 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Warner Losh Subject: Re: FreeBSD on Zedboard (Xilinx Zynq-7000) References: <50DF4BD9.8080601@sbcglobal.net> <50DF555B.9060601@sbcglobal.net> <6285A410-0470-4A75-9067-7C524831A8DA@bsdimp.com> In-Reply-To: <6285A410-0470-4A75-9067-7C524831A8DA@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 21:37:41 -0000 On 12/29/12 12:49 PM, Warner Losh wrote: > Cool! > > But don't be a tease! Share the code :) I'll try to put it up somewhere tonight or tomorrow. It's a little rough right now. > Bringing up new platforms is getting easier and easier now that we've put all the weight behind FDT, eh? Yes! Very cool. -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Sat Dec 29 22:38:49 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1864C0C for ; Sat, 29 Dec 2012 22:38:49 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id B24AF8FC12 for ; Sat, 29 Dec 2012 22:38:49 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id qBTMc7gb000709; Sat, 29 Dec 2012 22:38:07 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id pdjtrfqcx5hm37kidhnwqzn722; Sat, 29 Dec 2012 22:38:07 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: FreeBSD on Raspberry Pi 512MB (with U-Boot + ubldr) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle X-Priority: 3 In-Reply-To: <046DA83A0A7B4B489B3FD4471A3ACD98@ad.peach.ne.jp> Date: Sat, 29 Dec 2012 14:38:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3988C1622A974F19A9D3888F0334FF10@ad.peach.ne.jp> <046DA83A0A7B4B489B3FD4471A3ACD98@ad.peach.ne.jp> To: Daisuke Aoyama X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 22:38:49 -0000 On Dec 1, 2012, at 3:26 AM, Daisuke Aoyama wrote: >> You can try my test version from: >> http://www.peach.ne.jp/archives/rpi/freebsd-pi-20121201.img.gz >>=20 >> SHA256 (freebsd-pi-20121130.img.gz) =3D = a4159301e2d7564ef065aa4c3d6afaef3284cc3ace1ae7c146aaea9e18ec0457 >> SHA256 (freebsd-pi-20121201.img.gz) =3D = 7a0b8bcda7f70c39b259811c12854fcf856af7e18436e9beb0c2fa25a7fdb0e0 >>=20 >> Using config is here: >> http://www.peach.ne.jp/archives/rpi/config/RPI-B-test3 >=20 > If you have a problem such as "Unrecognized filesystem type", please = try this version: >=20 > http://www.peach.ne.jp/archives/rpi/test/uboot-20121201.img > SHA256 (uboot-20121201.img) =3D = 9218f3ce3a09b012eb250c044df9ed835929c207f3c3f89b21bfe249ef639a0f >=20 > Rename it to uboot.img, then copy it to the SD you created. Could you please send me the patches you used for this? Cheers, Tim From owner-freebsd-arm@FreeBSD.ORG Sat Dec 29 23:19:19 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 51043A59 for ; Sat, 29 Dec 2012 23:19:19 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id DD7898FC0C for ; Sat, 29 Dec 2012 23:19:18 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Tp5gG-000IBQ-0r; Sat, 29 Dec 2012 15:19:08 -0800 Message-ID: <50DF7A65.7090604@bluezbox.com> Date: Sat, 29 Dec 2012 15:19:01 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Tim Kientzle Subject: Re: FreeBSD on Raspberry Pi 512MB (with U-Boot + ubldr) References: <3988C1622A974F19A9D3888F0334FF10@ad.peach.ne.jp> <046DA83A0A7B4B489B3FD4471A3ACD98@ad.peach.ne.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 12/29/2012 2:38 PM, Tim Kientzle wrote: > On Dec 1, 2012, at 3:26 AM, Daisuke Aoyama wrote: > >>> You can try my test version from: >>> http://www.peach.ne.jp/archives/rpi/freebsd-pi-20121201.img.gz >>> >>> SHA256 (freebsd-pi-20121130.img.gz) = a4159301e2d7564ef065aa4c3d6afaef3284cc3ace1ae7c146aaea9e18ec0457 >>> SHA256 (freebsd-pi-20121201.img.gz) = 7a0b8bcda7f70c39b259811c12854fcf856af7e18436e9beb0c2fa25a7fdb0e0 >>> >>> Using config is here: >>> http://www.peach.ne.jp/archives/rpi/config/RPI-B-test3 >> If you have a problem such as "Unrecognized filesystem type", please try this version: >> >> http://www.peach.ne.jp/archives/rpi/test/uboot-20121201.img >> SHA256 (uboot-20121201.img) = 9218f3ce3a09b012eb250c044df9ed835929c207f3c3f89b21bfe249ef639a0f >> >> Rename it to uboot.img, then copy it to the SD you created. > Could you please send me the patches you used for this [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 23:19:19 -0000 On 12/29/2012 2:38 PM, Tim Kientzle wrote: > On Dec 1, 2012, at 3:26 AM, Daisuke Aoyama wrote: > >>> You can try my test version from: >>> http://www.peach.ne.jp/archives/rpi/freebsd-pi-20121201.img.gz >>> >>> SHA256 (freebsd-pi-20121130.img.gz) = a4159301e2d7564ef065aa4c3d6afaef3284cc3ace1ae7c146aaea9e18ec0457 >>> SHA256 (freebsd-pi-20121201.img.gz) = 7a0b8bcda7f70c39b259811c12854fcf856af7e18436e9beb0c2fa25a7fdb0e0 >>> >>> Using config is here: >>> http://www.peach.ne.jp/archives/rpi/config/RPI-B-test3 >> If you have a problem such as "Unrecognized filesystem type", please try this version: >> >> http://www.peach.ne.jp/archives/rpi/test/uboot-20121201.img >> SHA256 (uboot-20121201.img) = 9218f3ce3a09b012eb250c044df9ed835929c207f3c3f89b21bfe249ef639a0f >> >> Rename it to uboot.img, then copy it to the SD you created. > Could you please send me the patches you used for this I might be wrong but I think it just disables HS mode for SDHCI. Something like this: http://people.freebsd.org/~gonzo/patches/u-boot-pi-nohs.diff Daisuke will correct me if I'm wrong.