From owner-freebsd-arm@FreeBSD.ORG Sun Dec 23 05:07:11 2012
Return-Path: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <hselasky@c2i.net>
To: Ralf Wenk <iz-rpi03@hs-karlsruhe.de>
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>
<E1TmY92-0066I4-A8@smtp.hs-karlsruhe.de>
In-Reply-To: <E1TmY92-0066I4-A8@smtp.hs-karlsruhe.de>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <hselasky@c2i.net>
> > > > To: Warner Losh <imp@bsdimp.com>
> > > > CC: Andrew Turner <andrew@fubar.geek.nz>, Oleksandr Tymoshenko
> > > > <gonzo@freebsd.org>, 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: <Kingston> at usbus0
> umass0: <Kingston DataTraveler G2, class 0/0, rev 2.00/2.00, addr 4> 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: <Kingston> at usbus0 (disconnected)
> umass0: at uhub1, port 3, addr 4 (disconnected)
>
> When things go well they are:
>
> root@raspberry-pi:~ # ugen0.4: <Kingston> at usbus0
> umass0: <Kingston DataTraveler G2, class 0/0, rev 2.00/2.00, addr 4> 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: <Kingston DataTraveler G2 1.00> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <hselasky@c2i.net>
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>
<E1TmY92-0066I4-A8@smtp.hs-karlsruhe.de>
<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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <hselasky@c2i.net>
> > > > > To: Warner Losh <imp@bsdimp.com>
> > > > > CC: Andrew Turner <andrew@fubar.geek.nz>, Oleksandr Tymoshenko
> > > > > <gonzo@freebsd.org>, 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: <Kingston> at usbus0
> > umass0: <Kingston DataTraveler G2, class 0/0, rev 2.00/2.00, addr 4> 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: <Kingston> at usbus0 (disconnected)
> > umass0: at uhub1, port 3, addr 4 (disconnected)
> >
> > When things go well they are:
> >
> > root@raspberry-pi:~ # ugen0.4: <Kingston> at usbus0
> > umass0: <Kingston DataTraveler G2, class 0/0, rev 2.00/2.00, addr 4> 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: <Kingston DataTraveler G2 1.00> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <hselasky@c2i.net>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <hselasky@c2i.net>
> > > > > > To: Warner Losh <imp@bsdimp.com>
> > > > > > CC: Andrew Turner <andrew@fubar.geek.nz>, Oleksandr Tymoshenko
> > > > > > <gonzo@freebsd.org>, 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: <Kingston> at usbus0
> > > umass0: <Kingston DataTraveler G2, class 0/0, rev 2.00/2.00, addr 4> 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: <Kingston> at usbus0 (disconnected)
> > > umass0: at uhub1, port 3, addr 4 (disconnected)
> > >
> > > When things go well they are:
> > >
> > > root@raspberry-pi:~ # ugen0.4: <Kingston> at usbus0
> > > umass0: <Kingston DataTraveler G2, class 0/0, rev 2.00/2.00, addr 4> 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: <Kingston DataTraveler G2 1.00> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <iz-rpi03@hs-karlsruhe.de>)
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 <iz-rpi03@hs-karlsruhe.de>
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: <E1TmoVu-006dJs-2Y@smtp.hs-karlsruhe.de>
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to the StrongARM Processor <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <hselasky@c2i.net>
> > > > > > > To: Warner Losh <imp@bsdimp.com>
> > > > > > > CC: Andrew Turner <andrew@fubar.geek.nz>, Oleksandr Tymoshenko
> > > > > > > <gonzo@freebsd.org>, 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: <Kingston> at usbus0
> > > > umass0: <Kingston DataTraveler G2, class 0/0, rev 2.00/2.00, addr 4> 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: <Kingston> at usbus0 (disconnected)
> > > > umass0: at uhub1, port 3, addr 4 (disconnected)
> > > >
> > > > When things go well they are:
> > > >
> > > > root@raspberry-pi:~ # ugen0.4: <Kingston> at usbus0
> > > > umass0: <Kingston DataTraveler G2, class 0/0, rev 2.00/2.00, addr 4> 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: <Kingston DataTraveler G2 1.00> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <andrew@fubar.geek.nz>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <andrew@fubar.geek.nz>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <andrew@FreeBSD.org> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <george+freebsd@m5p.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <arm@freebsd.org>; 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 <arm@freebsd.org>; Mon, 24 Dec 2012 00:22:56 +0000 (UTC)
Received: by mail-pa0-f41.google.com with SMTP id bj3so3816788pad.28
for <arm@freebsd.org>; 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 <jroberson@jroberson.net>
X-X-Sender: jroberson@desktop
To: Ian Lepore <freebsd@damnhippie.dyndns.org>
Subject: Re: Call for testing and review, busdma changes
In-Reply-To: <1355085250.87661.345.camel@revolution.hippie.lan>
Message-ID: <alpine.BSF.2.00.1212231418120.2005@desktop>
References: <alpine.BSF.2.00.1212080841370.4081@desktop>
<1355077061.87661.320.camel@revolution.hippie.lan>
<alpine.BSF.2.00.1212090840080.4081@desktop>
<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 <jhb@freebsd.org>, 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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <andrew@fubar.geek.nz>
Subject: Re: Raspberry Pi EABI test image
In-reply-to: <50D79C5C.1000704@m5p.com>
To: George Mitchell <george+freebsd@m5p.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Dec 2012 00:55:34 -0000
On Sun, 23 Dec 2012 19:05:48 -0500
George Mitchell <george+freebsd@m5p.com> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <gonzo@id.bluezbox.com>)
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 <gonzo@bluezbox.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@wynn.com>
To: Oleksandr Tymoshenko <gonzo@bluezbox.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Dec 2012 01:36:31 -0000
On Sun, 23 Dec 2012 16:42:44 -0800
Oleksandr Tymoshenko <gonzo@bluezbox.com> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@wynn.com>
To: George Mitchell <george+freebsd@m5p.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Dec 2012 01:41:02 -0000
On Sun, 23 Dec 2012 19:05:48 -0500
George Mitchell <george+freebsd@m5p.com> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; Mon, 24 Dec 2012 01:52:07 +0000 (UTC)
Received: by mail-ia0-f176.google.com with SMTP id y26so5522078iab.7
for <freebsd-arm@freebsd.org>; 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: <CAGW5k5b54N8yD+oRPmaenm87Wz0qjQQzWR9=+JMSjnL7ML8p+A@mail.gmail.com>
Subject: Re: Raspberry Pi EABI test image
From: Johny Mattsson <johny.mattsson+fbsd@gmail.com>
To: George Mitchell <george+freebsd@m5p.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Dec 2012 01:52:08 -0000
On 24 December 2012 11:05, George Mitchell <george+freebsd@m5p.com> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd@damnhippie.dyndns.org>
To: Brett Wynkoop <freebsd-arm@wynn.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <george+freebsd@m5p.com> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <shurd@sasktel.net>
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 <freebsd-arm@wynn.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <george+freebsd@m5p.com> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; Mon, 24 Dec 2012 02:01:45 +0000 (UTC)
Received: by mail-pb0-f45.google.com with SMTP id mc8so3714242pbc.32
for <freebsd-arm@freebsd.org>; 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: <CANuCnH9+UFPcaazhpZL97MYnK5h5+oNis2Lky5g7dGc99Kquww@mail.gmail.com>
<6FC3E540-DEBD-4763-BB46-13F3422508E9@kientzle.com>
Date: Sun, 23 Dec 2012 18:01:39 -0800
Message-ID: <CANuCnH_=SnmnrF9ZR7wCPfZQP-mmVyJkxmzQdUtJEz25ZTKiqg@mail.gmail.com>
Subject: Re: FreeBSD10-CURRENT r244480 hang while compiling lighttpd or any
port
From: Alie Tan <alie@affle.com>
To: Tim Kientzle <tim@kientzle.com>
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" <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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Dec 2012 02:01:46 -0000
On Sat, Dec 22, 2012 at 12:23 AM, Tim Kientzle <tim@kientzle.com> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <shurd@sasktel.net>
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 <alie@affle.com>
Subject: Re: FreeBSD10-CURRENT r244480 hang while compiling lighttpd or any
port
References: <CANuCnH9+UFPcaazhpZL97MYnK5h5+oNis2Lky5g7dGc99Kquww@mail.gmail.com>
<6FC3E540-DEBD-4763-BB46-13F3422508E9@kientzle.com>
<CANuCnH_=SnmnrF9ZR7wCPfZQP-mmVyJkxmzQdUtJEz25ZTKiqg@mail.gmail.com>
In-Reply-To: <CANuCnH_=SnmnrF9ZR7wCPfZQP-mmVyJkxmzQdUtJEz25ZTKiqg@mail.gmail.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=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 <tim@kientzle.com>,
"freebsd-arm@freebsd.org" <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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <shurd@sasktel.net>
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 <alie@affle.com>
Subject: Re: FreeBSD10-CURRENT r244480 hang while compiling lighttpd or any
port
References: <CANuCnH9+UFPcaazhpZL97MYnK5h5+oNis2Lky5g7dGc99Kquww@mail.gmail.com>
<6FC3E540-DEBD-4763-BB46-13F3422508E9@kientzle.com>
<CANuCnH_=SnmnrF9ZR7wCPfZQP-mmVyJkxmzQdUtJEz25ZTKiqg@mail.gmail.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 <tim@kientzle.com>,
"freebsd-arm@freebsd.org" <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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <gonzo@id.bluezbox.com>)
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 <gonzo@bluezbox.com>
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 <alie@affle.com>
Subject: Re: FreeBSD10-CURRENT r244480 hang while compiling lighttpd or any
port
References: <CANuCnH9+UFPcaazhpZL97MYnK5h5+oNis2Lky5g7dGc99Kquww@mail.gmail.com>
In-Reply-To: <CANuCnH9+UFPcaazhpZL97MYnK5h5+oNis2Lky5g7dGc99Kquww@mail.gmail.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/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" <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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; Mon, 24 Dec 2012 02:21:54 +0000 (UTC)
Received: by mail-pa0-f54.google.com with SMTP id bi5so3825675pad.27
for <freebsd-arm@freebsd.org>; 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: <CANuCnH9+UFPcaazhpZL97MYnK5h5+oNis2Lky5g7dGc99Kquww@mail.gmail.com>
<6FC3E540-DEBD-4763-BB46-13F3422508E9@kientzle.com>
<CANuCnH_=SnmnrF9ZR7wCPfZQP-mmVyJkxmzQdUtJEz25ZTKiqg@mail.gmail.com>
<50D7B80B.2030106@sasktel.net> <50D7B945.3050400@sasktel.net>
Date: Sun, 23 Dec 2012 18:21:53 -0800
Message-ID: <CANuCnH9JncuGs97AigGLZZkmy2d9w00UJpN2Uk2HOnY40k5p2g@mail.gmail.com>
Subject: Re: FreeBSD10-CURRENT r244480 hang while compiling lighttpd or any
port
From: Alie Tan <alie@affle.com>
To: Stephen Hurd <shurd@sasktel.net>
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 <tim@kientzle.com>,
"freebsd-arm@freebsd.org" <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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <shurd@sasktel.net> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@wynn.com>
To: Ian Lepore <freebsd@damnhippie.dyndns.org>, 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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Dec 2012 02:49:18 -0000
On Sun, 23 Dec 2012 18:59:28 -0700
Ian Lepore <freebsd@damnhippie.dyndns.org> wrote:
> On Sun, 2012-12-23 at 20:41 -0500, Brett Wynkoop wrote:
> > On Sun, 23 Dec 2012 19:05:48 -0500
> > George Mitchell <george+freebsd@m5p.com> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <gonzo@id.bluezbox.com>)
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 <gonzo@bluezbox.com>
In-Reply-To: <201212211520.46822.hselasky@c2i.net>
Date: Sun, 23 Dec 2012 19:31:05 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <FADAC7E9-5164-4D20-96D8-4D4959003205@bluezbox.com>
References: <201212201956.47884.hselasky@c2i.net>
<50D3AAF1.80609@bluezbox.com> <201212211520.46822.hselasky@c2i.net>
To: Hans Petter Selasky <hselasky@c2i.net>
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 <hselasky@c2i.net>
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 <hselasky@c2i.net> >>> To: Warner Losh <imp@bsdimp.com> >>> CC: Andrew
Turner <andrew@fubar.geek.nz>, Oleksandr Tymoshenko >>> <gonzo@freebsd.org>,
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Dec 2012 03:31:26 -0000
On 2012-12-21, at 6:20 AM, Hans Petter Selasky <hselasky@c2i.net> 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 <hselasky@c2i.net>
>>> To: Warner Losh <imp@bsdimp.com>
>>> CC: Andrew Turner <andrew@fubar.geek.nz>, Oleksandr Tymoshenko
>>> <gonzo@freebsd.org>, 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <hselasky@c2i.net>
To: Ralf Wenk <iz-rpi03@hs-karlsruhe.de>
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>
<E1TmoVu-006dJs-2Y@smtp.hs-karlsruhe.de>
In-Reply-To: <E1TmoVu-006dJs-2Y@smtp.hs-karlsruhe.de>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@FreeBSD.org>; 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 <freebsd-arm@FreeBSD.org>; 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 <freebsd-arm@FreeBSD.org>; 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 <bugmaster@FreeBSD.org>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <iz-rpi03@hs-karlsruhe.de>)
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 <iz-rpi03@hs-karlsruhe.de>
To: Hans Petter Selasky <hselasky@c2i.net>
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>
<E1TmoVu-006dJs-2Y@smtp.hs-karlsruhe.de>
<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: <E1Tn8NQ-0023vC-98@smtp.hs-karlsruhe.de>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <george+freebsd@m5p.com>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
rv:15.0) Gecko/20121125 Thunderbird/15.0.1
MIME-Version: 1.0
To: Andrew Turner <andrew@fubar.geek.nz>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <george+freebsd@m5p.com> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <george+freebsd@m5p.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <george+freebsd@m5p.com> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd@damnhippie.dyndns.org>
To: George Mitchell <george+freebsd@m5p.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <george+freebsd@m5p.com> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; Mon, 24 Dec 2012 19:13:51 +0000 (UTC)
Received: by mail-ie0-f172.google.com with SMTP id c13so9148315ieb.17
for <freebsd-arm@freebsd.org>; 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 <wlosh@bsdimp.com>
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 <imp@bsdimp.com>
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 <freebsd@damnhippie.dyndns.org>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <george+freebsd@m5p.com> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <george@m5p.com>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
rv:15.0) Gecko/20121125 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Lepore <freebsd@damnhippie.dyndns.org>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <george+freebsd@m5p.com> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd@damnhippie.dyndns.org>
To: Jeff Roberson <jroberson@jroberson.net>
In-Reply-To: <alpine.BSF.2.00.1212231418120.2005@desktop>
References: <alpine.BSF.2.00.1212080841370.4081@desktop>
<1355077061.87661.320.camel@revolution.hippie.lan>
<alpine.BSF.2.00.1212090840080.4081@desktop>
<1355085250.87661.345.camel@revolution.hippie.lan>
<alpine.BSF.2.00.1212231418120.2005@desktop>
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 <jhb@freebsd.org>, 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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@wynn.com>
To: Warner Losh <imp@bsdimp.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Dec 2012 23:18:50 -0000
On Mon, 24 Dec 2012 12:13:42 -0700
Warner Losh <imp@bsdimp.com> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <wynkoop@wynn.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Dec 2012 23:31:22 -0000
On Mon, 24 Dec 2012 18:18:29 -0500
Brett Wynkoop <freebsd-arm@wynn.com> wrote:
> On Mon, 24 Dec 2012 12:13:42 -0700
> Warner Losh <imp@bsdimp.com> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <shurd@sasktel.net>
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 <wynkoop@wynn.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <freebsd-arm@wynn.com> wrote:
>
>> On Mon, 24 Dec 2012 12:13:42 -0700
>> Warner Losh <imp@bsdimp.com> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; Mon, 24 Dec 2012 23:47:15 +0000 (UTC)
Received: by mail-ia0-f176.google.com with SMTP id y26so6161374iab.21
for <freebsd-arm@freebsd.org>; 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 <wlosh@bsdimp.com>
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 <imp@bsdimp.com>
In-Reply-To: <50D8E820.3050400@sasktel.net>
Date: Mon, 24 Dec 2012 16:47:12 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <C7E2F525-A413-428D-B5D7-C56B218028B6@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>
<20121224181829.7a743510@ivory.wynn.com>
<20121224183119.73868caa@ivory.wynn.com> <50D8E820.3050400@sasktel.net>
To: Stephen Hurd <shurd@sasktel.net>
X-Mailer: Apple Mail (2.1085)
X-Gm-Message-State: ALoCoQnRVjasWRAYn2Lk0b6hrv1awScV/mB0F0H/0L75oGRwX5tFLaOO7+mx3f6fSCgYi+7nZoY5
Cc: freebsd-arm@freebsd.org, Brett Wynkoop <wynkoop@wynn.com>
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to the StrongARM Processor <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <freebsd-arm@wynn.com> wrote:
>>=20
>>> On Mon, 24 Dec 2012 12:13:42 -0700
>>> Warner Losh <imp@bsdimp.com> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <shurd@sasktel.net>
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 <imp@bsdimp.com>
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>
<C7E2F525-A413-428D-B5D7-C56B218028B6@bsdimp.com>
In-Reply-To: <C7E2F525-A413-428D-B5D7-C56B218028B6@bsdimp.com>
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 <wynkoop@wynn.com>
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to the StrongARM Processor <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; Tue, 25 Dec 2012 09:35:07 +0900 (JST)
Message-ID: <B508111FCE534B2CBA61F4D1EC1078D3@ad.peach.ne.jp>
From: "Daisuke Aoyama" <aoyama@peach.ne.jp>
To: <freebsd-arm@freebsd.org>
References: <B5F827FF91C94FF2AFEE00194A2BB2C5@ad.peach.ne.jp>
In-Reply-To: <B5F827FF91C94FF2AFEE00194A2BB2C5@ad.peach.ne.jp>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <arm@freebsd.org>; 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 <arm@freebsd.org>; Tue, 25 Dec 2012 00:02:28 +0000 (UTC)
Received: by mail-da0-f48.google.com with SMTP id k18so3351016dae.7
for <arm@freebsd.org>; 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 <jroberson@jroberson.net>
X-X-Sender: jroberson@desktop
To: Ian Lepore <freebsd@damnhippie.dyndns.org>
Subject: Re: Call for testing and review, busdma changes
In-Reply-To: <1356390225.1129.217.camel@revolution.hippie.lan>
Message-ID: <alpine.BSF.2.00.1212241357420.2005@desktop>
References: <alpine.BSF.2.00.1212080841370.4081@desktop>
<1355077061.87661.320.camel@revolution.hippie.lan>
<alpine.BSF.2.00.1212090840080.4081@desktop>
<1355085250.87661.345.camel@revolution.hippie.lan>
<alpine.BSF.2.00.1212231418120.2005@desktop>
<1356381775.1129.181.camel@revolution.hippie.lan>
<alpine.BSF.2.00.1212241104040.2005@desktop>
<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 <jhb@freebsd.org>, 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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <arm@freebsd.org>; 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 <arm@freebsd.org>; 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 <scott4long@yahoo.com>
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: <alpine.BSF.2.00.1212080841370.4081@desktop>
<1355077061.87661.320.camel@revolution.hippie.lan>
<alpine.BSF.2.00.1212090840080.4081@desktop>
<1355085250.87661.345.camel@revolution.hippie.lan>
<alpine.BSF.2.00.1212231418120.2005@desktop>
<1356381775.1129.181.camel@revolution.hippie.lan>
<alpine.BSF.2.00.1212241104040.2005@desktop>
<1356390225.1129.217.camel@revolution.hippie.lan>
To: Ian Lepore <freebsd@damnhippie.dyndns.org>
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 <jhb@freebsd.org>, "mav@freebsd.org Motin" <mav@freebsd.org>,
"attilio@FreeBSD.org Rao" <attilio@freebsd.org>,
Jeff Roberson <jroberson@jroberson.net>, 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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Dec 2012 03:13:18 -0000
On Dec 24, 2012, at 6:03 PM, Ian Lepore <freebsd@damnhippie.dyndns.org> =
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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <andrew@fubar.geek.nz>
Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr)
In-reply-to: <B508111FCE534B2CBA61F4D1EC1078D3@ad.peach.ne.jp>
To: Daisuke Aoyama <aoyama@peach.ne.jp>
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: <B5F827FF91C94FF2AFEE00194A2BB2C5@ad.peach.ne.jp>
<B508111FCE534B2CBA61F4D1EC1078D3@ad.peach.ne.jp>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Dec 2012 07:23:47 -0000
On Tue, 25 Dec 2012 09:34:51 +0900
"Daisuke Aoyama" <aoyama@peach.ne.jp> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <ray@freebsd.org>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <ray@freebsd.org>
From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 11:57:26 2012
Return-Path: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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: <CF39233ED91241919AA069FC56CBC110@ad.peach.ne.jp>
From: "Daisuke Aoyama" <aoyama@peach.ne.jp>
To: "Andrew Turner" <andrew@fubar.geek.nz>
References: <B5F827FF91C94FF2AFEE00194A2BB2C5@ad.peach.ne.jp>
<B508111FCE534B2CBA61F4D1EC1078D3@ad.peach.ne.jp>
<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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <jakub.klama@uj.edu.pl>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <ray@ddteam.net>
To: Jakub Klama <jakub.klama@uj.edu.pl>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Dec 2012 13:49:18 -0000
On Tue, 25 Dec 2012 14:30:47 +0100
Jakub Klama <jakub.klama@uj.edu.pl> 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 <ray@ddteam.net>
From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 15:51:59 2012
Return-Path: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@FreeBSD.org>; 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 <freebsd-arm@FreeBSD.org>; 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 <freebsd-arm@FreeBSD.org>; 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
<freebsd-arm@FreeBSD.org>; Tue, 25 Dec 2012 14:51:50 +0000 (GMT)
Date: Tue, 25 Dec 2012 15:51:46 +0100
From: Torfinn Ingolfsen <torfinn.ingolfsen@getmail.no>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Dec 2012 15:51:59 -0000
On Mon, 24 Dec 2012 10:38:25 +1300
Andrew Turner <andrew@fubar.geek.nz> 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 <torfinn.ingolfsen@getmail.no>
From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 17:22:09 2012
Return-Path: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <george+freebsd@m5p.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; Tue, 25 Dec 2012 13:21:23 -0700 (MST)
(envelope-from freebsd@damnhippie.dyndns.org)
Subject: Raspberry Pi questions
From: Ian Lepore <freebsd@damnhippie.dyndns.org>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <gonzo@id.bluezbox.com>)
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 <gonzo@bluezbox.com>
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 <freebsd@damnhippie.dyndns.org>
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 <freebsd@damnhippie.dyndns.org>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Dec 2012 20:37:36 -0000
On 2012-12-25, at 12:21 PM, Ian Lepore <freebsd@damnhippie.dyndns.org> =
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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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" <aoyama@peach.ne.jp>
To: "Ian Lepore" <freebsd@damnhippie.dyndns.org>,
<freebsd-arm@freebsd.org>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <gonzo@id.bluezbox.com>)
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 <gonzo@bluezbox.com>
X-Priority: 3
In-Reply-To: <B508111FCE534B2CBA61F4D1EC1078D3@ad.peach.ne.jp>
Date: Tue, 25 Dec 2012 12:51:03 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <E42823D3-D405-40E7-B4CF-75DC947AC119@bluezbox.com>
References: <B5F827FF91C94FF2AFEE00194A2BB2C5@ad.peach.ne.jp>
<B508111FCE534B2CBA61F4D1EC1078D3@ad.peach.ne.jp>
To: Daisuke Aoyama <aoyama@peach.ne.jp>
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 <aoyama@peach.ne.jp>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Dec 2012 20:51:26 -0000
On 2012-12-24, at 4:34 PM, Daisuke Aoyama <aoyama@peach.ne.jp> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd@damnhippie.dyndns.org>
To: Oleksandr Tymoshenko <gonzo@bluezbox.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <freebsd@damnhippie.dyndns.org> 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: <Flattened device tree simple bus> mem 0xf2000000-0xf2ffffff on fdtbus0
intc0: <BCM2835 Interrupt Controller> mem 0xf200b200-0xf200b3ff on simplebus0
systimer0: <BCM2835 System Timer> 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: <Broadcom 2708 SDHCI controller> mem 0xf2300000-0xf23000ff irq 70 on simplebus0
bcm_sdhci_attach(): SDHCI frequency: 50MHz
mmc0: <MMC/SD bus> on sdhci_bcm0
mbox0: <BCM2835 VideoCore Mailbox> mem 0xf200b880-0xf200b8bf irq 1 on simplebus0
mbox0: [GIANT-LOCKED]
bcmwd0: <BCM2708/2835 Watchdog> mem 0xf210001c-0xf2100027 on simplebus0
gpio0: <BCM2708/2835 GPIO controller> 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: <GPIO controller> on gpio0
gpiobus0: <GPIO bus> on gpio0
uart0: <PrimeCell UART (PL011)> mem 0xf2201000-0xf2201fff irq 65 on simplebus0
uart0: console (115200,n,8,1)
dwcotg0: <DWC OTG 2.0 integrated USB controller> 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: <DWCOTG> at usbus0
uhub0: <DWCOTG OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
uhub0: 1 port with 1 removable, self powered
mmcsd0: 1886MB <SD SD02G 8.0 SN 32334986 MFG 05/2010 by 3 SD> at mmc0 25.0MHz/4bit/65535-block
bootpc_init: wired to interface 'ue0'
ugen0.2: <vendor 0x0424> at usbus0
uhub1: <vendor 0x0424 product 0x9512, class 9/0, rev 2.00/2.00, addr 2> on usbus0
uhub1: MTT enabled
uhub1: 3 ports with 2 removable, self powered
ugen0.3: <vendor 0x0424> at usbus0
smsc0: <vendor 0x0424 product 0xec00, rev 2.00/2.00, addr 3> 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: <MII bus> on smsc0
ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0
ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ue0: <USB Ethernet> 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: <SSI Computer corp> at usbus0
umass0: <MSC Bulk-Only Transfer> 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: <M4-CT128 M4SSD2 > 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <tim@kientzle.com>
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 <wynkoop@wynn.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <freebsd-arm@wynn.com> wrote:
>
>> On Mon, 24 Dec 2012 12:13:42 -0700
>> Warner Losh <imp@bsdimp.com> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <gonzo@id.bluezbox.com>)
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 <gonzo@bluezbox.com>
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 <freebsd@damnhippie.dyndns.org>
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 <freebsd@damnhippie.dyndns.org>
wrote: > On Tue, 2012-12-25 at 12:37 -0800, Oleksandr Tymoshenko wrote: >>
On 2012-12-25, at 12:21 PM, Ian Lepore <freebsd@damnhippie.dyndns.org> 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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Dec 2012 23:21:26 -0000
On 2012-12-25, at 3:06 PM, Ian Lepore <freebsd@damnhippie.dyndns.org> =
wrote:
> On Tue, 2012-12-25 at 12:37 -0800, Oleksandr Tymoshenko wrote:
>> On 2012-12-25, at 12:21 PM, Ian Lepore =
<freebsd@damnhippie.dyndns.org> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd@damnhippie.dyndns.org>
To: Oleksandr Tymoshenko <gonzo@bluezbox.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <freebsd@damnhippie.dyndns.org> wrote:
>
> > On Tue, 2012-12-25 at 12:37 -0800, Oleksandr Tymoshenko wrote:
> >> On 2012-12-25, at 12:21 PM, Ian Lepore <freebsd@damnhippie.dyndns.org> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <tim@kientzle.com>
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: <B46B53E3-F555-4AE9-A5B4-FE2C33756C62@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>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <gonzo@id.bluezbox.com>)
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 <gonzo@bluezbox.com>
In-Reply-To: <B46B53E3-F555-4AE9-A5B4-FE2C33756C62@kientzle.com>
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>
<B46B53E3-F555-4AE9-A5B4-FE2C33756C62@kientzle.com>
To: Tim Kientzle <tim@kientzle.com>
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 <tim@kientzle.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Dec 2012 06:07:53 -0000
On 2012-12-25, at 9:57 PM, Tim Kientzle <tim@kientzle.com> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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" <aoyama@peach.ne.jp>
To: "Oleksandr Tymoshenko" <gonzo@bluezbox.com>
References: <B5F827FF91C94FF2AFEE00194A2BB2C5@ad.peach.ne.jp>
<B508111FCE534B2CBA61F4D1EC1078D3@ad.peach.ne.jp>
<E42823D3-D405-40E7-B4CF-75DC947AC119@bluezbox.com>
In-Reply-To: <E42823D3-D405-40E7-B4CF-75DC947AC119@bluezbox.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd@damnhippie.dyndns.org>
To: Tim Kientzle <tim@kientzle.com>
In-Reply-To: <B46B53E3-F555-4AE9-A5B4-FE2C33756C62@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>
<B46B53E3-F555-4AE9-A5B4-FE2C33756C62@kientzle.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd@damnhippie.dyndns.org>
To: Oleksandr Tymoshenko <gonzo@bluezbox.com>
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>
<B46B53E3-F555-4AE9-A5B4-FE2C33756C62@kientzle.com>
<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 <tim@kientzle.com>, freebsd-arm@freebsd.org
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting FreeBSD to the StrongARM Processor <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <tim@kientzle.com> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@FreeBSD.org>; 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 <freebsd-arm@FreeBSD.org>; 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 <freebsd-arm@FreeBSD.org>; 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
<freebsd-arm@FreeBSD.org>; Wed, 26 Dec 2012 15:17:29 +0000 (GMT)
Date: Wed, 26 Dec 2012 16:17:29 +0100
From: Torfinn Ingolfsen <torfinn.ingolfsen@getmail.no>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <torfinn.ingolfsen@getmail.no>
From owner-freebsd-arm@FreeBSD.ORG Wed Dec 26 15:28:32 2012
Return-Path: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; Wed, 26 Dec 2012 15:28:31 +0000 (UTC)
Received: by mail-vb0-f51.google.com with SMTP id fq11so9017903vbb.10
for <freebsd-arm@freebsd.org>; 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: <CANEJTgDQr4nixV422jaLoBR2eqGVTwFhHmzow7Nz=etZg3NePA@mail.gmail.com>
Subject: Re: Raspberry Pi EABI test image
From: "dev, dev" <dev@macdevshanghai.com>
To: Torfinn Ingolfsen <torfinn.ingolfsen@getmail.no>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <torfinn.ingolfsen@getmail.no>
> gpart show
From owner-freebsd-arm@FreeBSD.ORG Wed Dec 26 16:05:42 2012
Return-Path: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; Wed, 26 Dec 2012 16:05:41 +0000 (UTC)
Received: by mail-la0-f52.google.com with SMTP id l5so10781797lah.39
for <freebsd-arm@freebsd.org>; 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: <CAGtf9xOquNGakvSmRfmN31zqqQ49MMLmGscH5XvpwRoVJ6e3FQ@mail.gmail.com>
Subject: Allwinner A10
From: Ganbold Tsagaankhuu <ganbold@gmail.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd@damnhippie.dyndns.org>
To: Tim Kientzle <tim@kientzle.com>
In-Reply-To: <B46B53E3-F555-4AE9-A5B4-FE2C33756C62@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>
<B46B53E3-F555-4AE9-A5B4-FE2C33756C62@kientzle.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <SD 5 1.0 SN 7842 MFG 09/2007 by 111 0x0000> 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: <DWCOTG> at usbus0
uhub0: <DWCOTG OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <tinderbox@freebsd.org> using -f
Sender: FreeBSD Tinderbox <tinderbox@freebsd.org>
From: FreeBSD Tinderbox <tinderbox@freebsd.org>
To: FreeBSD Tinderbox <tinderbox@freebsd.org>, <current@freebsd.org>,
<arm@freebsd.org>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; Thu, 27 Dec 2012 03:02:23 +0000 (UTC)
Received: by mail-vb0-f43.google.com with SMTP id fs19so9318187vbb.2
for <freebsd-arm@freebsd.org>; 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: <CAGtf9xOquNGakvSmRfmN31zqqQ49MMLmGscH5XvpwRoVJ6e3FQ@mail.gmail.com>
References: <CAGtf9xOquNGakvSmRfmN31zqqQ49MMLmGscH5XvpwRoVJ6e3FQ@mail.gmail.com>
Date: Thu, 27 Dec 2012 11:02:21 +0800
Message-ID: <CANEJTgCJHQJpzLTLFN5ixot4RfYozr1z_iwrja4CU0WYJJMcGg@mail.gmail.com>
Subject: Re: Allwinner A10
From: "dev, dev" <dev@macdevshanghai.com>
To: Ganbold Tsagaankhuu <ganbold@gmail.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <ganbold@gmail.com>
> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <tim@kientzle.com>
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>
<B46B53E3-F555-4AE9-A5B4-FE2C33756C62@kientzle.com>
<1356534197.1144.38.camel@revolution.hippie.lan>
To: Ian Lepore <freebsd@damnhippie.dyndns.org>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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" <aoyama@peach.ne.jp>
To: "Oleksandr Tymoshenko" <gonzo@bluezbox.com>
References: <B5F827FF91C94FF2AFEE00194A2BB2C5@ad.peach.ne.jp>
<B508111FCE534B2CBA61F4D1EC1078D3@ad.peach.ne.jp>
<E42823D3-D405-40E7-B4CF-75DC947AC119@bluezbox.com>
In-Reply-To: <E42823D3-D405-40E7-B4CF-75DC947AC119@bluezbox.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <gonzo@id.bluezbox.com>)
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 <gonzo@bluezbox.com>
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: <BE93F553-E060-45E5-90FE-39AAD1325BAB@bluezbox.com>
References: <B5F827FF91C94FF2AFEE00194A2BB2C5@ad.peach.ne.jp>
<B508111FCE534B2CBA61F4D1EC1078D3@ad.peach.ne.jp>
<E42823D3-D405-40E7-B4CF-75DC947AC119@bluezbox.com>
<2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp>
To: Daisuke Aoyama <aoyama@peach.ne.jp>
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 <aoyama@peach.ne.jp>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Dec 2012 04:16:22 -0000
On 2012-12-26, at 7:52 PM, Daisuke Aoyama <aoyama@peach.ne.jp> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <tinderbox@freebsd.org> using -f
Sender: FreeBSD Tinderbox <tinderbox@freebsd.org>
From: FreeBSD Tinderbox <tinderbox@freebsd.org>
To: FreeBSD Tinderbox <tinderbox@freebsd.org>, <current@freebsd.org>,
<arm@freebsd.org>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <hselasky@c2i.net>
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: <CAGtf9xOquNGakvSmRfmN31zqqQ49MMLmGscH5XvpwRoVJ6e3FQ@mail.gmail.com>
In-Reply-To: <CAGtf9xOquNGakvSmRfmN31zqqQ49MMLmGscH5XvpwRoVJ6e3FQ@mail.gmail.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; Thu, 27 Dec 2012 09:16:01 +0000 (UTC)
Received: by mail-la0-f52.google.com with SMTP id l5so11765662lah.39
for <freebsd-arm@freebsd.org>; 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: <CAGtf9xOquNGakvSmRfmN31zqqQ49MMLmGscH5XvpwRoVJ6e3FQ@mail.gmail.com>
<201212271004.01598.hselasky@c2i.net>
Date: Thu, 27 Dec 2012 17:16:00 +0800
Message-ID: <CAGtf9xOwjC6Kq0SemG9a+Z8M_-GATT9Tm82xKSQXbuvJzqH=TA@mail.gmail.com>
Subject: Re: Allwinner A10
From: Ganbold Tsagaankhuu <ganbold@gmail.com>
To: Hans Petter Selasky <hselasky@c2i.net>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <hselasky@c2i.net> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@wynn.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <ray@ddteam.net>
To: Hans Petter Selasky <hselasky@c2i.net>
Subject: Re: Allwinner A10
Message-Id: <20121227120141.6cff665cd399e722967efbe5@ddteam.net>
In-Reply-To: <201212271004.01598.hselasky@c2i.net>
References: <CAGtf9xOquNGakvSmRfmN31zqqQ49MMLmGscH5XvpwRoVJ6e3FQ@mail.gmail.com>
<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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <hselasky@c2i.net> 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 <ray@ddteam.net>
From owner-freebsd-arm@FreeBSD.ORG Thu Dec 27 15:10:36 2012
Return-Path: <owner-freebsd-arm@FreeBSD.ORG>
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 <tinderbox@freebsd.org> using -f
Sender: FreeBSD Tinderbox <tinderbox@freebsd.org>
From: FreeBSD Tinderbox <tinderbox@freebsd.org>
To: FreeBSD Tinderbox <tinderbox@freebsd.org>, <current@freebsd.org>,
<arm@freebsd.org>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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: <F384770FEB784C67BC89AFF7CF57E96C@ad.peach.ne.jp>
From: "Daisuke Aoyama" <aoyama@peach.ne.jp>
To: "Oleksandr Tymoshenko" <gonzo@bluezbox.com>
References: <B5F827FF91C94FF2AFEE00194A2BB2C5@ad.peach.ne.jp>
<B508111FCE534B2CBA61F4D1EC1078D3@ad.peach.ne.jp>
<E42823D3-D405-40E7-B4CF-75DC947AC119@bluezbox.com>
<2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp>
<BE93F553-E060-45E5-90FE-39AAD1325BAB@bluezbox.com>
In-Reply-To: <BE93F553-E060-45E5-90FE-39AAD1325BAB@bluezbox.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd@damnhippie.dyndns.org>
To: Daisuke Aoyama <aoyama@peach.ne.jp>
In-Reply-To: <F384770FEB784C67BC89AFF7CF57E96C@ad.peach.ne.jp>
References: <B5F827FF91C94FF2AFEE00194A2BB2C5@ad.peach.ne.jp>
<B508111FCE534B2CBA61F4D1EC1078D3@ad.peach.ne.jp>
<E42823D3-D405-40E7-B4CF-75DC947AC119@bluezbox.com>
<2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp>
<BE93F553-E060-45E5-90FE-39AAD1325BAB@bluezbox.com>
<F384770FEB784C67BC89AFF7CF57E96C@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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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" <aoyama@peach.ne.jp>
To: "Ian Lepore" <freebsd@damnhippie.dyndns.org>
References: <B5F827FF91C94FF2AFEE00194A2BB2C5@ad.peach.ne.jp>
<B508111FCE534B2CBA61F4D1EC1078D3@ad.peach.ne.jp>
<E42823D3-D405-40E7-B4CF-75DC947AC119@bluezbox.com>
<2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp>
<BE93F553-E060-45E5-90FE-39AAD1325BAB@bluezbox.com>
<F384770FEB784C67BC89AFF7CF57E96C@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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <tinderbox@freebsd.org> using -f
Sender: FreeBSD Tinderbox <tinderbox@freebsd.org>
From: FreeBSD Tinderbox <tinderbox@freebsd.org>
To: FreeBSD Tinderbox <tinderbox@freebsd.org>, <current@freebsd.org>,
<arm@freebsd.org>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <shurd@sasktel.net>
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 <gonzo@freebsd.org>
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" <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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <aoyama at peach.ne.jp>
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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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" <aoyama@peach.ne.jp>
To: "Daisuke Aoyama" <aoyama@peach.ne.jp>
References: <B5F827FF91C94FF2AFEE00194A2BB2C5@ad.peach.ne.jp>
<B508111FCE534B2CBA61F4D1EC1078D3@ad.peach.ne.jp>
<E42823D3-D405-40E7-B4CF-75DC947AC119@bluezbox.com>
<2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp>
<BE93F553-E060-45E5-90FE-39AAD1325BAB@bluezbox.com>
<F384770FEB784C67BC89AFF7CF57E96C@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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <multiple recipients>; 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: <B5F827FF91C94FF2AFEE00194A2BB2C5@ad.peach.ne.jp>
<B508111FCE534B2CBA61F4D1EC1078D3@ad.peach.ne.jp>
<E42823D3-D405-40E7-B4CF-75DC947AC119@bluezbox.com>
<2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp>
<BE93F553-E060-45E5-90FE-39AAD1325BAB@bluezbox.com>
<F384770FEB784C67BC89AFF7CF57E96C@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: <CAJ-VmokH8=CHnPGHtjZTrpuWe1HAjR+YRp+zGROtS8GcJrCiZA@mail.gmail.com>
Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr)
From: Adrian Chadd <adrian@freebsd.org>
To: Daisuke Aoyama <aoyama@peach.ne.jp>, David Chisnall <theraven@freebsd.org>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <aoyama@peach.ne.jp> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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" <tadashi.takahashi@nifty.com>
To: <freebsd-arm@freebsd.org>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <aoyama at peach.ne.jp>
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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd@damnhippie.dyndns.org>
To: Adrian Chadd <adrian@freebsd.org>
In-Reply-To: <CAJ-VmokH8=CHnPGHtjZTrpuWe1HAjR+YRp+zGROtS8GcJrCiZA@mail.gmail.com>
References: <B5F827FF91C94FF2AFEE00194A2BB2C5@ad.peach.ne.jp>
<B508111FCE534B2CBA61F4D1EC1078D3@ad.peach.ne.jp>
<E42823D3-D405-40E7-B4CF-75DC947AC119@bluezbox.com>
<2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp>
<BE93F553-E060-45E5-90FE-39AAD1325BAB@bluezbox.com>
<F384770FEB784C67BC89AFF7CF57E96C@ad.peach.ne.jp>
<1356624694.1144.67.camel@revolution.hippie.lan>
<234E1E18AC1C4A3985D6C570F78698E6@ad.peach.ne.jp>
<9ED42265200A41B1BD637682720E0E9D@ad.peach.ne.jp>
<CAJ-VmokH8=CHnPGHtjZTrpuWe1HAjR+YRp+zGROtS8GcJrCiZA@mail.gmail.com>
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 <theraven@freebsd.org>, 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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <aoyama@peach.ne.jp> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; Fri, 28 Dec 2012 21:09:15 +0000 (UTC)
Received: by mail-ie0-f178.google.com with SMTP id c12so13511684ieb.9
for <freebsd-arm@freebsd.org>; 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 <wlosh@bsdimp.com>
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 <imp@bsdimp.com>
In-Reply-To: <CAJ-VmokH8=CHnPGHtjZTrpuWe1HAjR+YRp+zGROtS8GcJrCiZA@mail.gmail.com>
Date: Fri, 28 Dec 2012 14:09:04 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <F28AB348-B188-4734-80AF-D2DD27DB3073@bsdimp.com>
References: <B5F827FF91C94FF2AFEE00194A2BB2C5@ad.peach.ne.jp>
<B508111FCE534B2CBA61F4D1EC1078D3@ad.peach.ne.jp>
<E42823D3-D405-40E7-B4CF-75DC947AC119@bluezbox.com>
<2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp>
<BE93F553-E060-45E5-90FE-39AAD1325BAB@bluezbox.com>
<F384770FEB784C67BC89AFF7CF57E96C@ad.peach.ne.jp>
<1356624694.1144.67.camel@revolution.hippie.lan>
<234E1E18AC1C4A3985D6C570F78698E6@ad.peach.ne.jp>
<9ED42265200A41B1BD637682720E0E9D@ad.peach.ne.jp>
<CAJ-VmokH8=CHnPGHtjZTrpuWe1HAjR+YRp+zGROtS8GcJrCiZA@mail.gmail.com>
To: Adrian Chadd <adrian@freebsd.org>
X-Mailer: Apple Mail (2.1085)
X-Gm-Message-State: ALoCoQmGHJzB1Q3WHaaR3DH8sqK/QtQPHHf0T+szvjARUEVKkT64tYA+YJxv96gu7JYYrWkuFi6v
Cc: David Chisnall <theraven@freebsd.org>, 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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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 <aoyama@peach.ne.jp> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <ThomasSkibo@sbcglobal.net>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; Sat, 29 Dec 2012 20:49:34 +0000 (UTC)
Received: by mail-ia0-f173.google.com with SMTP id w21so9697809iac.32
for <freebsd-arm@freebsd.org>; 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 <wlosh@bsdimp.com>
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 <imp@bsdimp.com>
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 <ThomasSkibo@sbcglobal.net>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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
> <boot2.txt>_______________________________________________
> 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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <ThomasSkibo@sbcglobal.net>
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 <imp@bsdimp.com>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <tim@kientzle.com>
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: <A717EA1B-5FAA-4E38-A0F0-3FEDB3CABCA3@kientzle.com>
References: <3988C1622A974F19A9D3888F0334FF10@ad.peach.ne.jp>
<EDA5788A-A74B-47A5-88C7-4CAD9B572EE2@exmandato.se>
<D0C85770-572C-492D-82A4-7CB19F114F01@bluezbox.com>
<C956325DD85D4E1E9739709F94FEEA76@ad.peach.ne.jp>
<046DA83A0A7B4B489B3FD4471A3ACD98@ad.peach.ne.jp>
To: Daisuke Aoyama <aoyama@peach.ne.jp>
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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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: <owner-freebsd-arm@FreeBSD.ORG>
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 <freebsd-arm@freebsd.org>; 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 <freebsd-arm@freebsd.org>; 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 <gonzo@id.bluezbox.com>)
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 <gonzo@bluezbox.com>
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 <tim@kientzle.com>
Subject: Re: FreeBSD on Raspberry Pi 512MB (with U-Boot + ubldr)
References: <3988C1622A974F19A9D3888F0334FF10@ad.peach.ne.jp>
<EDA5788A-A74B-47A5-88C7-4CAD9B572EE2@exmandato.se>
<D0C85770-572C-492D-82A4-7CB19F114F01@bluezbox.com>
<C956325DD85D4E1E9739709F94FEEA76@ad.peach.ne.jp>
<046DA83A0A7B4B489B3FD4471A3ACD98@ad.peach.ne.jp>
<A717EA1B-5FAA-4E38-A0F0-3FEDB3CABCA3@kientzle.com>
In-Reply-To: <A717EA1B-5FAA-4E38-A0F0-3FEDB3CABCA3@kientzle.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/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 <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
<mailto:freebsd-arm-request@freebsd.org?subject=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.