From owner-freebsd-arm@FreeBSD.ORG Sun Oct 16 07:41:08 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41FA4106564A for ; Sun, 16 Oct 2011 07:41:08 +0000 (UTC) (envelope-from mrossi@swin.edu.au) Received: from outbound.icp-qv1-irony-out2.iinet.net.au (outbound.icp-qv1-irony-out2.iinet.net.au [203.59.1.107]) by mx1.freebsd.org (Postfix) with ESMTP id B0A5F8FC14 for ; Sun, 16 Oct 2011 07:41:07 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcBAB6Dmk7L1iRx/2dsb2JhbAAMNqZqgQiDZwEBAQQ4QAEQCw0LCRYPCQMCAQIBRRMBBwEBtACJAoJPhTkEk3qFSIwi X-IronPort-AV: E=Sophos;i="4.69,353,1315152000"; d="scan'208";a="771899642" Received: from unknown (HELO [192.168.15.65]) ([203.214.36.113]) by outbound.icp-qv1-irony-out2.iinet.net.au with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 16 Oct 2011 15:13:09 +0800 Message-ID: <4E9A7602.6070806@swin.edu.au> Date: Sun, 16 Oct 2011 17:13:22 +1100 From: Mattia Rossi Organization: Swinburne University of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 CC: freebsd-arm@freebsd.org References: <4E782686.6070500@smartfruit.com> <4E98E1CF.2090507@smartfruit.com> <201110150739.35707.freebsd-arm@dino.sk> In-Reply-To: <201110150739.35707.freebsd-arm@dino.sk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Q about Ethernet - GlobalScale DreamPlug + FreeBSD 8.2 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mrossi@swin.edu.au List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 07:41:08 -0000 On 15/10/11 16:39, Milan Obuch wrote: > On Saturday 15 October 2011 03:28:47 Naoyuki Tai wrote: >> Hi, >> >> I just realized that I get only mge0, one of two ethernet >> ports. >> >> With the linux that came with DreamPlug, both ethernet >> ports show up as eth0 and eth1. >> >> Is there any way to get the mge1 get going? >> > > Hi, > > it looks like you are trying to solve similar issue as I did some time ago... > look in this list archives for message from me sent 2010-10-27 22:59 with > subject 'Re: Guruplug Server Plus working to some extent... [mge1 problem > SOLVED]' with some patches attached. I think at least guruplugplus.dts could > be useful. Basically, SoC used in Guruplug Server Plus and, I think, DreamPlug > uses the same or at least similar, multiplexes some functions on IO pins and > so some initialisation is important. > > Regards, > Milan > I've had the smae problem, and it's not just a multiplexing problem, but also in the dreamplug.dts file send by Matthieu, he uses the wrong address for mdio1 and enet1: 74000 instead of 76000 (although the comments suggest he suspected the problem already :-) ) The two necessary bits in corected version make mge1 work: mdio1: mdio@76000 { /* 76000? */ device_type = "mdio"; compatible = "mrvl,mdio"; reg = <76000 20>; #address-cells = <1>; #size-cells = <0>; phy1: ethernet-phy@0 { reg = <1>; device_type = "ethernet-phy"; }; }; enet1: ethernet@76000 { /* 76000? */ #address-cells = <1>; #size-cells = <1>; model = "V2"; compatible = "mrvl,ge"; reg = <0x76000 0x2000>; ranges = <0x0 0x74000 0x2000>; local-mac-address = [ 00 00 00 00 00 00 ]; interrupts = <16 17 18 15 47>; interrupt-parent = <&PIC>; phy-handle = <&phy1>; }; Additionally, if you need the pins multiplexed differently, there is an openrd-cl.dts found in this thread, (included in sdio_patch.txt), which also adds sdio support to HEAD. I've applied the patch without problems to 9-BETA3. There are two issues though: the included openrd-cl.dts adds pci support which causes a kernel panic, and the sdio driver actually doesn't seem to work. Didn't have enough time to investigate that yet. Mat From owner-freebsd-arm@FreeBSD.ORG Sun Oct 16 17:03:17 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6020F1065670 for ; Sun, 16 Oct 2011 17:03:15 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id 439D48FC14 for ; Sun, 16 Oct 2011 17:03:14 +0000 (UTC) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta02.emeryville.ca.mail.comcast.net with comcast id lUpt1h00217UAYkA2UpytB; Sun, 16 Oct 2011 16:49:58 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta13.emeryville.ca.mail.comcast.net with comcast id lUpG1h00a4NgCEG8ZUpHWe; Sun, 16 Oct 2011 16:49:18 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id p9GGo2nA021163; Sun, 16 Oct 2011 10:50:02 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: mrossi@swin.edu.au In-Reply-To: <4E9669CB.2060707@swin.edu.au> References: <4E9290FF.7090306@swin.edu.au> <4E92D2D8.8070500@swin.edu.au> <4E9535D0.2030706@swin.edu.au> <4E9669CB.2060707@swin.edu.au> Content-Type: text/plain Date: Sun, 16 Oct 2011 10:50:02 -0600 Message-Id: <1318783802.2245.8.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Create FAT partition/filesystem on the internal microSD flash of the Dreamplug X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 17:03:17 -0000 On Thu, 2011-10-13 at 15:32 +1100, Mattia Rossi wrote: > On 13/10/11 02:06, Warner Losh wrote: > > > > On Oct 12, 2011, at 12:38 AM, Mattia Rossi wrote: > > > >> -snip- > >>>>> I've tried to recreate it using gpart and newfs_msdos, but can't > >>>>> create any new FAT partition that mount_msdosfs would mount. > >>>>> [snip] This turned out to be a difference in structure packing (it's something that happens a lot with ARM). The patch below should get it working for you. Funny aside: I opened newfs_msdos.c and within 90 seconds knew what was wrong and how to fix it. It then took me over an hour to prove to myself that my fix was right -- the mount was failing because I forgot to put "option MSDOSFS" in my kernel config (and we always build our systems with no .ko modules at all). -- Ian diff -r 0e647646c002 sbin/newfs_msdos/newfs_msdos.c --- sbin/newfs_msdos/newfs_msdos.c.orig Thu Sep 29 08:39:38 2011 -0600 +++ sbin/newfs_msdos/newfs_msdos.c Sun Oct 16 10:40:07 2011 -0600 @@ -98,7 +98,7 @@ static const char rcsid[] = struct bs { u_int8_t bsJump[3]; /* bootstrap entry point */ u_int8_t bsOemName[8]; /* OEM name and version */ -}; +} __packed; struct bsbpb { u_int8_t bpbBytesPerSec[2]; /* bytes per sector */ @@ -113,7 +113,7 @@ struct bsbpb { u_int8_t bpbHeads[2]; /* drive heads */ u_int8_t bpbHiddenSecs[4]; /* hidden sectors */ u_int8_t bpbHugeSectors[4]; /* big total sectors */ -}; +} __packed; struct bsxbpb { u_int8_t bpbBigFATsecs[4]; /* big sectors per FAT */ @@ -123,7 +123,7 @@ struct bsxbpb { u_int8_t bpbFSInfo[2]; /* file system info sector */ u_int8_t bpbBackup[2]; /* backup boot sector */ u_int8_t bpbReserved[12]; /* reserved */ -}; +} __packed; struct bsx { u_int8_t exDriveNumber; /* drive number */ @@ -132,7 +132,7 @@ struct bsx { u_int8_t exVolumeID[4]; /* volume ID number */ u_int8_t exVolumeLabel[11]; /* volume label */ u_int8_t exFileSysType[8]; /* file system type */ -}; +} __packed; struct de { u_int8_t deName[11]; /* name and extension */ @@ -142,7 +142,7 @@ struct de { u_int8_t deMDate[2]; /* creation date */ u_int8_t deStartCluster[2]; /* starting cluster */ u_int8_t deFileSize[4]; /* size */ -}; +} __packed; struct bpb { u_int bpbBytesPerSec; /* bytes per sector */ From owner-freebsd-arm@FreeBSD.ORG Sun Oct 16 17:40:14 2011 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9E54106564A for ; Sun, 16 Oct 2011 17:40:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A9F998FC0C for ; Sun, 16 Oct 2011 17:40:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9GHeE15077622 for ; Sun, 16 Oct 2011 17:40:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9GHeE6k077621; Sun, 16 Oct 2011 17:40:14 GMT (envelope-from gnats) Date: Sun, 16 Oct 2011 17:40:14 GMT Message-Id: <201110161740.p9GHeE6k077621@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: arm/161492: commit references a PR X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 17:40:14 -0000 The following reply was made to PR arm/161492; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: arm/161492: commit references a PR Date: Sun, 16 Oct 2011 17:38:08 +0000 (UTC) Author: cognet Date: Sun Oct 16 17:37:54 2011 New Revision: 226441 URL: http://svn.freebsd.org/changeset/base/226441 Log: Explicitely set ARM_RAS_START and ARM_RAS_END once the cacheline or the page has been allocated, or we could end up using random values, and bad things could happen. PR: arm/161492 Submitted by: Ian Lepore MFC after: 1 week Modified: head/sys/arm/arm/machdep.c Modified: head/sys/arm/arm/machdep.c ============================================================================== --- head/sys/arm/arm/machdep.c Sun Oct 16 16:58:28 2011 (r226440) +++ head/sys/arm/arm/machdep.c Sun Oct 16 17:37:54 2011 (r226441) @@ -312,6 +312,8 @@ cpu_startup(void *dummy) m = vm_page_alloc(NULL, 0, VM_ALLOC_NOOBJ | VM_ALLOC_ZERO); pmap_kenter_user(ARM_TP_ADDRESS, VM_PAGE_TO_PHYS(m)); #endif + *(uint32_t *)ARM_RAS_START = 0; + *(uint32_t *)ARM_RAS_END = 0xffffffff; } SYSINIT(cpu, SI_SUB_CPU, SI_ORDER_FIRST, cpu_startup, NULL); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sun Oct 16 18:00:28 2011 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFE57106566B for ; Sun, 16 Oct 2011 18:00:28 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 941548FC08 for ; Sun, 16 Oct 2011 18:00:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9GI0SgC094566 for ; Sun, 16 Oct 2011 18:00:28 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9GI0SWr094564; Sun, 16 Oct 2011 18:00:28 GMT (envelope-from gnats) Date: Sun, 16 Oct 2011 18:00:28 GMT Message-Id: <201110161800.p9GI0SWr094564@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: arm/161498: commit references a PR X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 18:00:28 -0000 The following reply was made to PR arm/161498; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: arm/161498: commit references a PR Date: Sun, 16 Oct 2011 17:59:42 +0000 (UTC) Author: cognet Date: Sun Oct 16 17:59:28 2011 New Revision: 226443 URL: http://svn.freebsd.org/changeset/base/226443 Log: Fix 2 bugs : - A race condition could happen if two threads were using RAS at the same time as the code didn't reset RAS_END, the RAS code could believe we were not in a RAS, when we were in fact. - Using signed value logic to compare addresses wasn't such a good idea. Many thanks to Ian to investigate on these issues. Pointy hat to: cognet PR: arm/161498 Submitted by: Ian Lepore Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB2CA1065673 for ; Sun, 16 Oct 2011 20:30:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DA3788FC14 for ; Sun, 16 Oct 2011 20:30:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9GKUFIX031419 for ; Sun, 16 Oct 2011 20:30:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9GKUFdZ031416; Sun, 16 Oct 2011 20:30:15 GMT (envelope-from gnats) Date: Sun, 16 Oct 2011 20:30:15 GMT Message-Id: <201110162030.p9GKUFdZ031416@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org From: Mark Tinguely Cc: Subject: Re: arm/160431: [patch] Disable interrupts during busdma cache sync operations. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Tinguely List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 20:30:16 -0000 The following reply was made to PR arm/160431; it has been noted by GNATS. From: Mark Tinguely To: bug-followup@FreeBSD.org, freebsd@damnhippie.dyndns.org Cc: Subject: Re: arm/160431: [patch] Disable interrupts during busdma cache sync operations. Date: Sun, 16 Oct 2011 14:57:50 -0500 This is a multi-part message in MIME format. --------------090706000403080305010106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ian and I have been sending emails this week about this problem. He and I have examples where turning off interrupts will not be enough, but I think this is a good start. If we cache align the allocation sizes that are less than a PAGE_SIZE in bus_dmamem_alloc(), then it may help avoid this routine. Attached is a crude alignment concept code. --Mark. --------------090706000403080305010106 Content-Type: text/plain; name="arm_busdma_machdep_c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arm_busdma_machdep_c.diff" --- sys/arm/arm/busdma_machdep.c.orig 2011-10-16 13:09:49.000000000 -0500 +++ sys/arm/arm/busdma_machdep.c 2011-10-16 14:20:27.000000000 -0500 @@ -579,6 +579,7 @@ bus_dmamem_alloc(bus_dma_tag_t dmat, voi { bus_dmamap_t newmap = NULL; + bus_size_t len; int mflags; if (flags & BUS_DMA_NOWAIT) @@ -598,17 +599,23 @@ bus_dmamem_alloc(bus_dma_tag_t dmat, voi *mapp = newmap; newmap->dmat = dmat; - if (dmat->maxsize <= PAGE_SIZE && - (dmat->alignment < dmat->maxsize) && + if (dmat->maxsize < PAGE_SIZE) + /* round up to nearest cache line size */ + len = (dmat->maxsize + arm_dcache_align_mask) & + ~arm_dcache_align_mask; + else + len = dmat->maxsize; + if (len <= PAGE_SIZE && + (dmat->alignment < len) && !_bus_dma_can_bounce(dmat->lowaddr, dmat->highaddr)) { - *vaddr = malloc(dmat->maxsize, M_DEVBUF, mflags); + *vaddr = malloc(len, M_DEVBUF, mflags); } else { /* * XXX Use Contigmalloc until it is merged into this facility * and handles multi-seg allocations. Nobody is doing * multi-seg allocations yet though. */ - *vaddr = contigmalloc(dmat->maxsize, M_DEVBUF, mflags, + *vaddr = contigmalloc(len, M_DEVBUF, mflags, 0ul, dmat->lowaddr, dmat->alignment? dmat->alignment : 1ul, dmat->boundary); } @@ -623,7 +630,7 @@ bus_dmamem_alloc(bus_dma_tag_t dmat, voi if (flags & BUS_DMA_COHERENT) { void *tmpaddr = arm_remap_nocache( (void *)((vm_offset_t)*vaddr &~ PAGE_MASK), - dmat->maxsize + ((vm_offset_t)*vaddr & PAGE_MASK)); + len + ((vm_offset_t)*vaddr & PAGE_MASK)); if (tmpaddr) { tmpaddr = (void *)((vm_offset_t)(tmpaddr) + @@ -645,19 +652,28 @@ bus_dmamem_alloc(bus_dma_tag_t dmat, voi void bus_dmamem_free(bus_dma_tag_t dmat, void *vaddr, bus_dmamap_t map) { + bus_size_t len; + + if (dmat->maxsize < PAGE_SIZE) + /* round up to nearest cache line size */ + len = (dmat->maxsize + arm_dcache_align_mask) & + ~arm_dcache_align_mask; + else + len = dmat->maxsize; + if (map->allocbuffer) { KASSERT(map->allocbuffer == vaddr, ("Trying to freeing the wrong DMA buffer")); vaddr = map->origbuffer; arm_unmap_nocache(map->allocbuffer, - dmat->maxsize + ((vm_offset_t)vaddr & PAGE_MASK)); + len + ((vm_offset_t)vaddr & PAGE_MASK)); } - if (dmat->maxsize <= PAGE_SIZE && - dmat->alignment < dmat->maxsize && + if (len <= PAGE_SIZE && + dmat->alignment < len && !_bus_dma_can_bounce(dmat->lowaddr, dmat->highaddr)) free(vaddr, M_DEVBUF); else { - contigfree(vaddr, dmat->maxsize, M_DEVBUF); + contigfree(vaddr, len, M_DEVBUF); } dmat->map_count--; _busdma_free_dmamap(map); --------------090706000403080305010106-- From owner-freebsd-arm@FreeBSD.ORG Mon Oct 17 11:06:58 2011 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D24471065670 for ; Mon, 17 Oct 2011 11:06:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BF9528FC22 for ; Mon, 17 Oct 2011 11:06:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9HB6w2Y099164 for ; Mon, 17 Oct 2011 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9HB6wbM099162 for freebsd-arm@FreeBSD.org; Mon, 17 Oct 2011 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Oct 2011 11:06:58 GMT Message-Id: <201110171106.p9HB6wbM099162@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 11:06:58 -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/161498 arm [patch] ARM RAS code can fail to restart an atomic seq o arm/161492 arm [patch] ARM thread-data/RAS page is not properly initi o arm/161128 arm gcc 4.2.1 ARM produces bad code with -fstack-protector 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/160431 arm [patch] Disable interrupts during busdma cache sync op o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/156814 arm OpenRD Ultimate does not boot on DB-88F6XXX or SHEEVAP o arm/156496 arm [patch] Minor bugfixes and enhancements to mmc and mmc o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) o 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/154189 arm lang/perl5.12 doesn't build 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 18 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Oct 17 14:22:22 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC886106566B; Mon, 17 Oct 2011 14:22:22 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 091A38FC13; Mon, 17 Oct 2011 14:22:21 +0000 (UTC) Received: by wwi18 with SMTP id 18so3158292wwi.31 for ; Mon, 17 Oct 2011 07:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=oBTOZi9ypJVnTnvgxiknMq6J+iMS1Ikm2Ix+I5b6PBw=; b=bUefdqpFcxAmAVlofwId/1r5CaJUfWDZFxrdKHsMYc7xKMrqTtdzaqGcAzyDKvOYWf /INAo6pg8WKZ7gh6R1nQpNj4L19sRyFMu3Whwfh3MlR2LTGF7YgOg3c6fHZjlFH8PFL9 vbMt33oQszokIIuBK5J4wS/mUT1/X2Qxi1ZP8= MIME-Version: 1.0 Received: by 10.216.198.224 with SMTP id v74mr3162973wen.41.1318859476912; Mon, 17 Oct 2011 06:51:16 -0700 (PDT) Sender: c.jayachandran@gmail.com Received: by 10.216.188.3 with HTTP; Mon, 17 Oct 2011 06:51:16 -0700 (PDT) Date: Mon, 17 Oct 2011 19:21:16 +0530 X-Google-Sender-Auth: a3ghgUd5ioAW4ZIwHsc8zhq5n6E Message-ID: From: "Jayachandran C." To: freebsd-arm@freebsd.org, freebsd-ppc@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: HEADSUP: FDT phandle change. [svn commit: r226466] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 14:22:22 -0000 I have committed this revision that changes the way phandle is represented for FDT. The old representation was a pointer, which would not work on 64bit - and the new representation is as an offset. This should not affect the FDT users, but if there is any breakage on ARM or PPC due to this please let me know. Thanks, JC. ---------- Forwarded message ---------- From: Jayachandran C. Date: Mon, Oct 17, 2011 at 7:14 PM Subject: svn commit: r226466 - head/sys/dev/ofw To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Author: jchandra Date: Mon Oct 17 13:44:33 2011 New Revision: 226466 URL: http://svn.freebsd.org/changeset/base/226466 Log: =A0FDT changes for 64 bit kernel =A0Use the offset into the device tree from fdtp as the phandle instead =A0of using pointer into the device tree. =A0This will make sure that the =A0phandle fits into a uint32_t type, even when compiled for 64bit. =A0Reviewed by: =A0raj, nathanw, marcel Modified: =A0head/sys/dev/ofw/ofw_fdt.c Modified: head/sys/dev/ofw/ofw_fdt.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/ofw/ofw_fdt.c =A0Mon Oct 17 13:12:47 2011 =A0 =A0 =A0 =A0(= r226465) +++ head/sys/dev/ofw/ofw_fdt.c =A0Mon Oct 17 13:44:33 2011 =A0 =A0 =A0 =A0(= r226466) @@ -109,22 +109,48 @@ ofw_fdt_init(ofw_t ofw, void *data) =A0} =A0/* - * Device tree functions + * Device tree functions. + * + * We use the offset from fdtp to the node as the 'phandle' in OF interfac= e. + * + * phandle is a u32 value, therefore we cannot use the pointer to node as + * phandle in 64 bit. We also do not use the usual fdt offset as phandle, + * as it can be 0, and the OF interface has special meaning for phandle 0. =A0*/ +static phandle_t +fdt_offset_phandle(int offset) +{ + =A0 =A0 =A0 if (offset < 0) + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (0); + =A0 =A0 =A0 return ((phandle_t)offset + fdt_off_dt_struct(fdtp)); +} + =A0static int =A0fdt_phandle_offset(phandle_t p) =A0{ - =A0 =A0 =A0 const char *dt_struct; + =A0 =A0 =A0 int pint =3D (int)p; + =A0 =A0 =A0 int dtoff =3D fdt_off_dt_struct(fdtp); + + =A0 =A0 =A0 if (pint < dtoff) + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (-1); + =A0 =A0 =A0 return (pint - dtoff); +} + +static int +fdt_pointer_offset(const void *ptr) +{ + =A0 =A0 =A0 uintptr_t dt_struct, p; =A0 =A0 =A0 =A0int offset; - =A0 =A0 =A0 dt_struct =3D (const char *)fdtp + fdt_off_dt_struct(fdtp); + =A0 =A0 =A0 p =3D (uintptr_t)ptr; + =A0 =A0 =A0 dt_struct =3D (uintptr_t)fdtp + fdt_off_dt_struct(fdtp); - =A0 =A0 =A0 if (((const char *)p < dt_struct) || - =A0 =A0 =A0 =A0 =A0 (const char *)p > (dt_struct + fdt_size_dt_struct(fdt= p))) + =A0 =A0 =A0 if ((p < dt_struct) || + =A0 =A0 =A0 =A0 =A0 p > (dt_struct + fdt_size_dt_struct(fdtp))) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (-1); - =A0 =A0 =A0 offset =3D (const char *)p - dt_struct; + =A0 =A0 =A0 offset =3D p - dt_struct; =A0 =A0 =A0 =A0if (offset < 0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (-1); @@ -135,15 +161,13 @@ fdt_phandle_offset(phandle_t p) =A0static phandle_t =A0ofw_fdt_peer(ofw_t ofw, phandle_t node) =A0{ - =A0 =A0 =A0 phandle_t p; =A0 =A0 =A0 =A0int depth, offset; =A0 =A0 =A0 =A0if (node =3D=3D 0) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Find root node */ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0offset =3D fdt_path_offset(fdtp, "/"); - =A0 =A0 =A0 =A0 =A0 =A0 =A0 p =3D (phandle_t)fdt_offset_ptr(fdtp, offset,= sizeof(p)); - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (p); + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (fdt_offset_phandle(offset)); =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0offset =3D fdt_phandle_offset(node); @@ -155,10 +179,8 @@ ofw_fdt_peer(ofw_t ofw, phandle_t node) =A0 =A0 =A0 =A0 =A0 =A0offset =3D fdt_next_node(fdtp, offset, &depth)) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (depth < 0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (depth =3D=3D 1) { - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 p =3D (phandle_t)fdt_offset_p= tr(fdtp, offset, sizeof(p)); - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (p); - =A0 =A0 =A0 =A0 =A0 =A0 =A0 } + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (depth =3D=3D 1) + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (fdt_offset_phandle(of= fset)); =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0return (0); @@ -168,7 +190,6 @@ ofw_fdt_peer(ofw_t ofw, phandle_t node) =A0static phandle_t =A0ofw_fdt_child(ofw_t ofw, phandle_t node) =A0{ - =A0 =A0 =A0 phandle_t p; =A0 =A0 =A0 =A0int depth, offset; =A0 =A0 =A0 =A0offset =3D fdt_phandle_offset(node); @@ -180,10 +201,8 @@ ofw_fdt_child(ofw_t ofw, phandle_t node) =A0 =A0 =A0 =A0 =A0 =A0offset =3D fdt_next_node(fdtp, offset, &depth)) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (depth < 0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (depth =3D=3D 1) { - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 p =3D (phandle_t)fdt_offset_p= tr(fdtp, offset, sizeof(p)); - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (p); - =A0 =A0 =A0 =A0 =A0 =A0 =A0 } + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (depth =3D=3D 1) + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (fdt_offset_phandle(of= fset)); =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0return (0); @@ -193,7 +212,6 @@ ofw_fdt_child(ofw_t ofw, phandle_t node) =A0static phandle_t =A0ofw_fdt_parent(ofw_t ofw, phandle_t node) =A0{ - =A0 =A0 =A0 phandle_t p; =A0 =A0 =A0 =A0int offset, paroffset; =A0 =A0 =A0 =A0offset =3D fdt_phandle_offset(node); @@ -201,15 +219,13 @@ ofw_fdt_parent(ofw_t ofw, phandle_t node =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); =A0 =A0 =A0 =A0paroffset =3D fdt_parent_offset(fdtp, offset); - =A0 =A0 =A0 p =3D (phandle_t)fdt_offset_ptr(fdtp, paroffset, sizeof(phand= le_t)); - =A0 =A0 =A0 return (p); + =A0 =A0 =A0 return (fdt_offset_phandle(paroffset)); =A0} =A0/* Return the package handle that corresponds to an instance handle. */ =A0static phandle_t =A0ofw_fdt_instance_to_package(ofw_t ofw, ihandle_t instance) =A0{ - =A0 =A0 =A0 phandle_t p; =A0 =A0 =A0 =A0int offset; =A0 =A0 =A0 =A0/* @@ -223,8 +239,7 @@ ofw_fdt_instance_to_package(ofw_t ofw, i =A0 =A0 =A0 =A0if (offset < 0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (-1); - =A0 =A0 =A0 p =3D (phandle_t)fdt_offset_ptr(fdtp, offset, sizeof(phandle_= t)); - =A0 =A0 =A0 return (p); + =A0 =A0 =A0 return (fdt_offset_phandle(offset)); =A0} =A0/* Get the length of a property of a package. */ @@ -343,7 +358,7 @@ ofw_fdt_nextprop(ofw_t ofw, phandle_t pa =A0 =A0 =A0 =A0if (prop =3D=3D NULL) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (-1); - =A0 =A0 =A0 offset =3D fdt_phandle_offset((phandle_t)prop); + =A0 =A0 =A0 offset =3D fdt_pointer_offset(prop); =A0 =A0 =A0 =A0rv =3D fdt_nextprop(offset, buf, size); =A0 =A0 =A0 =A0return (rv); =A0} @@ -374,14 +389,10 @@ ofw_fdt_canon(ofw_t ofw, const char *dev =A0static phandle_t =A0ofw_fdt_finddevice(ofw_t ofw, const char *device) =A0{ - =A0 =A0 =A0 phandle_t p; =A0 =A0 =A0 =A0int offset; =A0 =A0 =A0 =A0offset =3D fdt_path_offset(fdtp, device); - - =A0 =A0 =A0 p =3D (phandle_t)fdt_offset_ptr(fdtp, offset, sizeof(p)); - - =A0 =A0 =A0 return (p); + =A0 =A0 =A0 return (fdt_offset_phandle(offset)); =A0} =A0/* Return the fully qualified pathname corresponding to an instance. */ From owner-freebsd-arm@FreeBSD.ORG Tue Oct 18 02:04:13 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EA801065672; Tue, 18 Oct 2011 02:04:13 +0000 (UTC) (envelope-from richo@psych0tik.net) Received: from bedford.accountservergroup.com (bedford.accountservergroup.com [50.22.11.19]) by mx1.freebsd.org (Postfix) with ESMTP id E90A68FC16; Tue, 18 Oct 2011 02:04:12 +0000 (UTC) Received: from boxand.lnk.telstra.net ([203.45.130.125] helo=richh-imac.office.boxdice.com.au) by bedford.accountservergroup.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RFy1d-0007Q1-AE; Mon, 17 Oct 2011 19:59:25 -0500 Date: Tue, 18 Oct 2011 11:59:39 +1100 From: richo To: "Jayachandran C." Message-ID: <20111018005939.GA27991@richh-imac.office.boxdice.com.au> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://natalya.psych0tik.net/~richo/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bedford.accountservergroup.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - psych0tik.net X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-arm@freebsd.org, freebsd-ppc@freebsd.org Subject: Re: HEADSUP: FDT phandle change. [svn commit: r226466] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 02:04:13 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 17/10/11 19:21 +0530, Jayachandran C. wrote: >I have committed this revision that changes the way phandle is >represented for FDT. The old representation was a pointer, which >would not work on 64bit - and the new representation is as an offset. > >This should not affect the FDT users, but if there is any breakage on >ARM or PPC due to this please let me know. > >Thanks, >JC. > I can test on ppc tonight, is there anything specific I need to test, or ju= st build world+kernel and confirm that it boots? --=20 richo || Today's excuse:=20 Someone set us up the bomb. --0F1p//8PRICkK4MW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJOnM97AAoJEIKiWz6J5yQVJnMIALA9mOdzOwUmAgqr3TqtUF+e ylFN5taxLneAEOj0HcKeXKcC3l26LurTb1sF41QiuPP+dN4HbMFMW4WCuP6AwTkM fOcnTxD/WGzopHvgteg/6U6y/ddH497mntoQYSdqsNjFk2Ggb8DLV684V9iigqeL Hof5HVvcQBNLje0gx+uAJ9sUANXchYfEjIu4kyU00scP50GgNcZYVP9LdIh+ZnSy LoZ+F9wr3pescbjqJk14zin8EKj/NUqeDVxz3KYVbGWWZSib8bxGJqwoOt6gp4Pv 7lqB0mrf5RRWJyAx2eiXB/kkm/WxzI5z/pShE0a0A4yVV6YkMNC1qYhzmUPS9ZI= =/AUy -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW-- From owner-freebsd-arm@FreeBSD.ORG Tue Oct 18 05:58:11 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EACD81065670; Tue, 18 Oct 2011 05:58:11 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 55C568FC18; Tue, 18 Oct 2011 05:58:10 +0000 (UTC) Received: by wyi40 with SMTP id 40so256907wyi.13 for ; Mon, 17 Oct 2011 22:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PLTbaFbcRP6rYPIKeD1GQnMYafBYBtE4tf9hePvU2VU=; b=GqfIjrGEu+luC0seHeCgW0IogPGz8iLqrWpUfuQO8qDU3DSupVqS/eZswROQPnBlWx /0Z9UhSTnV7Cic3EeEn0Gls37hBWmI+KQFl2/UjoCyKpr2Y1gsnr0CGLPtWjuc53SHmY g8exDJdmZZrq+qL/qa3l7JOdoDjAM/C794gZw= MIME-Version: 1.0 Received: by 10.216.137.36 with SMTP id x36mr373662wei.41.1318917490119; Mon, 17 Oct 2011 22:58:10 -0700 (PDT) Sender: c.jayachandran@gmail.com Received: by 10.216.188.3 with HTTP; Mon, 17 Oct 2011 22:58:10 -0700 (PDT) In-Reply-To: <20111018005939.GA27991@richh-imac.office.boxdice.com.au> References: <20111018005939.GA27991@richh-imac.office.boxdice.com.au> Date: Tue, 18 Oct 2011 11:28:10 +0530 X-Google-Sender-Auth: _PKor83zBhFwx4IZNlPQKgG3sho Message-ID: From: "Jayachandran C." To: richo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@freebsd.org, freebsd-ppc@freebsd.org Subject: Re: HEADSUP: FDT phandle change. [svn commit: r226466] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 05:58:12 -0000 On Tue, Oct 18, 2011 at 6:29 AM, richo wrote: > On 17/10/11 19:21 +0530, Jayachandran C. wrote: >> >> I have committed this revision that changes the way phandle is >> represented for FDT. =A0The old representation was a pointer, =A0which >> would not work on 64bit - and the new representation is as an offset. >> >> This should not affect the FDT users, but if there is any breakage on >> ARM or PPC due to this please let me know. >> >> Thanks, >> JC. >> > > I can test on ppc tonight, is there anything specific I need to test, or > just > build world+kernel and confirm that it boots? buildkernel would be sufficient since this does have changes that affect the userspace. Let me know if you see any new crash, change in device behavior or missing devices after these changes. Thanks, JC. From owner-freebsd-arm@FreeBSD.ORG Wed Oct 19 00:00:29 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 963C310656D8 for ; Wed, 19 Oct 2011 00:00:26 +0000 (UTC) (envelope-from root@ns6.wowcardeals.com) Received: from ns6.wowcardeals.com (ns6.wowcardeals.com [217.23.9.146]) by mx1.freebsd.org (Postfix) with ESMTP id CD7C48FC15 for ; Wed, 19 Oct 2011 00:00:14 +0000 (UTC) Received: by ns6.wowcardeals.com (Postfix, from userid 0) id B916A90A135; Wed, 19 Oct 2011 03:26:19 +0400 (MSD) To: freebsd-arm@freebsd.org From: 'Drive a New BMW for R4999 P/M' Content-Disposition: inline Message-Id: <20111018232619.B916A90A135@ns6.wowcardeals.com> Date: Wed, 19 Oct 2011 03:26:19 +0400 (MSD) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Drive A New BMW for R4999 P/M X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 00:00:29 -0000 wowbmw.com Drive a new BMW from R4999 per month! Can't see the pictures? [1]Click here to view this email online. Save up to R1 411.54 per month [2]BMW E90 320i BMW E90 320i Petrol (Manual) * From R4 999.00 per month. * Manual * 2.0L Petrol * Radio/CD * Aircon Climate Control * Central Locking * ABS/ASC + T&CBC * Fog Lamps * Cruise Control * Alloy Wheels * Isofix * Multifunction Steering Wheel * Cruise Control * Run Flat Tyres * 5 Year / 100 000km Motorplan Are you Interested? [3]YES / [4]NO Save up to R1 463.76 per month [5]BMW E90 Auto BMW E90 320i Petrol (Automatic) * From R5 299.00 per month. * Automatic * 2.0L Petrol * Radio/CD * Aircon Climate Control * Central Locking * ABS/ASC + T&CBC * Fog Lamps * Cruise Control * Alloy Wheels * Isofix * Multifunction Steering Wheel * Cruise Control * Run Flat Tyres * 5 Year / 100 000km Motorplan Are you Interested? [6]YES / [7]NO Subject to availability of stock. Extra's not factory fitted will be charged Terms and conditions and cost of credit General terms and conditions and cost of credit Duration of contract 72 months. Once off initiation fee of R1140.00 VAT inclusive, already included in contract. Monthly service fee of R57.00 VAT inclusive. Rate at prime +2% variable. All delivery, lic, registration and number plates included in cost of credit. No residual value or deposit. Cost of credit and repayments may vary due to your credit risk profile. Application subject (at all times) to approval from our credit providers partners. Pre quote and pre contract available at all times. Terms and conditions and cost of credit available or request of contract in all official languages To qualify, the applicant must comply with the following basic conditions: * Earn a minimum salary of R5 500.00 nett (take home); * Not listed on the ITC; * Have a SA Driver's license and ID; * The rest of our terms and conditions are set out in the example [8]Advertising Contract. Advertising initiative cost of credit: * BMW E90 320i Petrol (Manual) = R359 928.00 * BMW E90 320i Petrol (Automatic) = R381 528.00 Please note that your repayment and cost of credit may vary as per terms and conditions of the advertising agreement. Advertised payment reduction is governed by a advertising program. Re-payments exclude monthly services charged and include initiation fee as allowed by the NCR. To view an example of an advertising contract please [9]click here. Example adverts on the back of the vehicles: Branding Branding Cost of credit and repayment if you opt not to enter into the advertising initiative: * BMW E90 320i Petrol (Manual) = R465 662.88 Repayment = R6 467.54 per month * BMW E90 320i Petrol (Automatic) = R491 022.72 Repayment = R6 819.76 per month Repayments and cost of credit includes initiation and monthly service fees as prescribed by the [10]NCR. To stop receiving emails, please [11]UNSUBSCRIBE here References 1. http://www.wowbmw.com/mailer/002/agent.php?page=online&agent=002&campaign=bmw&vehicle=1 2. http://www.wowbmw.com/mailer/002/agent.php?page=apply&agent=002&campaign=bmw&vehicle=25 3. http://www.wowbmw.com/mailer/002/agent.php?page=apply&agent=002&campaign=bmw&vehicle=25 4. http://www.wowbmw.com/mailer/002/agent.php?page=decline&agent=002&campaign=bmw&vehicle=25 5. http://www.wowbmw.com/mailer/002/agent.php?page=apply&agent=002&campaign=bmw&vehicle=26 6. http://www.wowbmw.com/mailer/002/agent.php?page=apply&agent=002&campaign=bmw&vehicle=26 7. http://www.wowbmw.com/mailer/002/agent.php?page=decline&agent=002&campaign=bmw&vehicle=26 8. http://www.wowbmw.com/contract.pdf 9. http://www.wowbmw.com/contract.pdf 10. http://www.ncr.org.za/ 11. http://www.wowbmw.com/site/decline.php From owner-freebsd-arm@FreeBSD.ORG Wed Oct 19 15:38:39 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19DA9106564A; Wed, 19 Oct 2011 15:38:39 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1D6A98FC19; Wed, 19 Oct 2011 15:38:37 +0000 (UTC) Received: by wyi40 with SMTP id 40so2392191wyi.13 for ; Wed, 19 Oct 2011 08:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=Lll5IMW4teql2DW1qOv+Kj3PtIoA9WrGth3LJu5MIMA=; b=fvLjMen4AW2TQdGGk1bFEA03198b9Q1MO008PrpgqRk5EUrYrRrispOL6dgPsSQf4O yoPY/HbDAEh5u+p9sr3MxmGQ9+CIXTogWw/FQSB9UKtsNq/7jGmvk6Xw3BVKkNWxpCBj upBONGiShZAPhB3+efe4g8wpJdkFzDG5oMNqw= MIME-Version: 1.0 Received: by 10.216.139.224 with SMTP id c74mr2728022wej.11.1319038671103; Wed, 19 Oct 2011 08:37:51 -0700 (PDT) Sender: c.jayachandran@gmail.com Received: by 10.216.188.3 with HTTP; Wed, 19 Oct 2011 08:37:50 -0700 (PDT) Date: Wed, 19 Oct 2011 21:07:50 +0530 X-Google-Sender-Auth: JuUm13nXD6l6jf4yZCy9jAQkdqE Message-ID: From: "Jayachandran C." To: Rafal Jaworowski , Nathan Whitehorn , freebsd-arm@freebsd.org, freebsd-ppc@freebsd.org Content-Type: multipart/mixed; boundary=0016e6d508eb6fa82104afa89f6b Cc: Marcel Moolenaar Subject: [RFC] Fix OF_finddevice return code for FDT X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 15:38:39 -0000 --0016e6d508eb6fa82104afa89f6b Content-Type: text/plain; charset=ISO-8859-1 While reviewing the previous FDT patch, nwhithorn@ noted that the return code of OF_finddevice was not correct in case of FDT. According to the 1275 standard, we should return a phandle value of -1 in case of error, but the ofw_fdt_finddevice implementation now returns 0. The attached patches fixes this in the FDT code, and makes changes in the callers to check the return code correctly. Since most of the callers are in ARM, any testing on ARM would be really appreciated Thanks, JC. --0016e6d508eb6fa82104afa89f6b Content-Type: application/octet-stream; name="fdt-finddevice-fix.patch" Content-Disposition: attachment; filename="fdt-finddevice-fix.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gtygvap00 Y29tbWl0IDgxMDc2ZThhYTRjYmYyM2M4YWQ4OTBlYzg1MTVmNzkxN2JhZTJhYjgKQXV0aG9yOiBK YXlhY2hhbmRyYW4gQyA8amF5YWNoYW5kcmFuY0BuZXRsb2dpY21pY3JvLmNvbT4KRGF0ZTogICBU dWUgT2N0IDE4IDAwOjU3OjQ2IDIwMTEgKzA1MzAKCiAgICBPRl9maW5kZGV2aWNlIHNob3VsZCBy ZXR1cm4gLTEgb24gZXJyb3IKICAgIAogICAgRml4IHRoZSBpbXBsZW1lbnRhdGlvbiwgYW5kIGZp eHVwIHRoZSBjYWxsZXJzLgoKZGlmZiAtLWdpdCBhL3N5cy9kZXYvZmR0L2ZkdF9jb21tb24uYyBi L3N5cy9kZXYvZmR0L2ZkdF9jb21tb24uYwppbmRleCBkMjU3MTViLi44NzAyZGYyIDEwMDY0NAot LS0gYS9zeXMvZGV2L2ZkdC9mZHRfY29tbW9uLmMKKysrIGIvc3lzL2Rldi9mZHQvZmR0X2NvbW1v bi5jCkBAIC03NCwxMyArNzQsMTMgQEAgZmR0X2ltbXJfYWRkcih2bV9vZmZzZXRfdCBpbW1yX3Zh KQogCS8qCiAJICogVHJ5IHRvIGFjY2VzcyB0aGUgU09DIG5vZGUgZGlyZWN0bHkgaS5lLiB0aHJv dWdoIC9hbGlhc2VzLy4KIAkgKi8KLQlpZiAoKG5vZGUgPSBPRl9maW5kZGV2aWNlKCJzb2MiKSkg IT0gMCkKKwlpZiAoKG5vZGUgPSBPRl9maW5kZGV2aWNlKCJzb2MiKSkgIT0gLTEpCiAJCWlmIChm ZHRfaXNfY29tcGF0aWJsZV9zdHJpY3Qobm9kZSwgInNpbXBsZS1idXMiKSkKIAkJCWdvdG8gbW92 ZW9uOwogCS8qCiAJICogRmluZCB0aGUgbm9kZSB0aGUgbG9uZyB3YXkuCiAJICovCi0JaWYgKChu b2RlID0gT0ZfZmluZGRldmljZSgiLyIpKSA9PSAwKQorCWlmICgobm9kZSA9IE9GX2ZpbmRkZXZp Y2UoIi8iKSkgPT0gLTEpCiAJCXJldHVybiAoRU5YSU8pOwogCiAJaWYgKChub2RlID0gZmR0X2Zp bmRfY29tcGF0aWJsZShub2RlLCAic2ltcGxlLWJ1cyIsIDEpKSA9PSAwKQpAQCAtNTc2LDcgKzU3 Niw3IEBAIGZkdF9nZXRfbWVtX3JlZ2lvbnMoc3RydWN0IG1lbV9yZWdpb24gKm1yLCBpbnQgKm1y Y250LCB1aW50MzJfdCAqbWVtc2l6ZSkKIAogCW1heF9zaXplID0gc2l6ZW9mKHJlZyk7CiAJbWVt b3J5ID0gT0ZfZmluZGRldmljZSgiL21lbW9yeSIpOwotCWlmIChtZW1vcnkgPD0gMCkgeworCWlm IChtZW1vcnkgPT0gLTEpIHsKIAkJcnYgPSBFTlhJTzsKIAkJZ290byBvdXQ7CiAJfQpkaWZmIC0t Z2l0IGEvc3lzL2Rldi9mZHQvZmR0YnVzLmMgYi9zeXMvZGV2L2ZkdC9mZHRidXMuYwppbmRleCBl MjgwOGQxLi5kNTI5NmE5IDEwMDY0NAotLS0gYS9zeXMvZGV2L2ZkdC9mZHRidXMuYworKysgYi9z eXMvZGV2L2ZkdC9mZHRidXMuYwpAQCAtMTc3LDcgKzE3Nyw3IEBAIGZkdGJ1c19hdHRhY2goZGV2 aWNlX3QgZGV2KQogCXVfbG9uZyBzdGFydCwgZW5kOwogCWludCBlcnJvcjsKIAotCWlmICgocm9v dCA9IE9GX3BlZXIoMCkpID09IDApCisJaWYgKChyb290ID0gT0ZfZmluZGRldmljZSgiLyIpKSA9 PSAtMSkKIAkJcGFuaWMoImZkdGJ1c19hdHRhY2g6IG5vIHJvb3Qgbm9kZS4iKTsKIAogCXNjID0g ZGV2aWNlX2dldF9zb2Z0YyhkZXYpOwpkaWZmIC0tZ2l0IGEvc3lzL2Rldi9vZncvb2Z3X2ZkdC5j IGIvc3lzL2Rldi9vZncvb2Z3X2ZkdC5jCmluZGV4IDgwNmYxN2MuLjdiM2IwZTkgMTAwNjQ0Ci0t LSBhL3N5cy9kZXYvb2Z3L29md19mZHQuYworKysgYi9zeXMvZGV2L29mdy9vZndfZmR0LmMKQEAg LTM5Miw2ICszOTIsOCBAQCBvZndfZmR0X2ZpbmRkZXZpY2Uob2Z3X3Qgb2Z3LCBjb25zdCBjaGFy ICpkZXZpY2UpCiAJaW50IG9mZnNldDsKIAogCW9mZnNldCA9IGZkdF9wYXRoX29mZnNldChmZHRw LCBkZXZpY2UpOworCWlmIChvZmZzZXQgPCAwKQorCQlyZXR1cm4gKC0xKTsKIAlyZXR1cm4gKGZk dF9vZmZzZXRfcGhhbmRsZShvZmZzZXQpKTsKIH0KIApAQCAtNDIwLDcgKzQyMiw3IEBAIG9md19m ZHRfZml4dXAob2Z3X3Qgb2Z3KQogCXNzaXplX3QgbGVuOwogCWludCBpOwogCi0JaWYgKChyb290 ID0gb2Z3X2ZkdF9maW5kZGV2aWNlKG9mdywgIi8iKSkgPT0gMCkKKwlpZiAoKHJvb3QgPSBvZndf ZmR0X2ZpbmRkZXZpY2Uob2Z3LCAiLyIpKSA9PSAtMSkKIAkJcmV0dXJuIChFTk9ERVYpOwogCiAJ aWYgKChsZW4gPSBvZndfZmR0X2dldHByb3BsZW4ob2Z3LCByb290LCAibW9kZWwiKSkgPD0gMCkK ZGlmZiAtLWdpdCBhL3N5cy9kZXYvb2Z3L29wZW5maXJtLmMgYi9zeXMvZGV2L29mdy9vcGVuZmly bS5jCmluZGV4IGE4Y2I4ZjcuLmY1NDNkY2UgMTAwNjQ0Ci0tLSBhL3N5cy9kZXYvb2Z3L29wZW5m aXJtLmMKKysrIGIvc3lzL2Rldi9vZncvb3BlbmZpcm0uYwpAQCAtMTMxLDcgKzEzMSw3IEBAIE9G X2luaXQodm9pZCAqY29va2llKQogCiAJcnYgPSBPRldfSU5JVChvZndfb2JqLCBjb29raWUpOwog Ci0JaWYgKChjaG9zZW4gPSBPRl9maW5kZGV2aWNlKCIvY2hvc2VuIikpID4gMCkKKwlpZiAoKGNo b3NlbiA9IE9GX2ZpbmRkZXZpY2UoIi9jaG9zZW4iKSkgIT0gLTEpCiAJCWlmIChPRl9nZXRwcm9w KGNob3NlbiwgInN0ZG91dCIsICZzdGRvdXQsIHNpemVvZihzdGRvdXQpKSA9PSAtMSkKIAkJCXN0 ZG91dCA9IC0xOwogCmRpZmYgLS1naXQgYS9zeXMvZGV2L3VhcnQvdWFydF9idXNfZmR0LmMgYi9z eXMvZGV2L3VhcnQvdWFydF9idXNfZmR0LmMKaW5kZXggNDIwOTg2Ni4uOGJiNjJlYSAxMDA2NDQK LS0tIGEvc3lzL2Rldi91YXJ0L3VhcnRfYnVzX2ZkdC5jCisrKyBiL3N5cy9kZXYvdWFydC91YXJ0 X2J1c19mZHQuYwpAQCAtMTU1LDExICsxNTUsMTEgQEAgdWFydF9jcHVfZ2V0ZGV2KGludCBkZXZ0 eXBlLCBzdHJ1Y3QgdWFydF9kZXZpbmZvICpkaSkKIAkvKgogCSAqIFJldHJpZXZlIC9jaG9zZW4v c3Rke2luLG91dH0uCiAJICovCi0JaWYgKChjaG9zZW4gPSBPRl9maW5kZGV2aWNlKCIvY2hvc2Vu IikpID09IDApCisJaWYgKChjaG9zZW4gPSBPRl9maW5kZGV2aWNlKCIvY2hvc2VuIikpID09IC0x KQogCQlyZXR1cm4gKEVOWElPKTsKIAlpZiAoT0ZfZ2V0cHJvcChjaG9zZW4sICJzdGRpbiIsIGJ1 Ziwgc2l6ZW9mKGJ1ZikpIDw9IDApCiAJCXJldHVybiAoRU5YSU8pOwotCWlmICgobm9kZSA9IE9G X2ZpbmRkZXZpY2UoYnVmKSkgPT0gMCkKKwlpZiAoKG5vZGUgPSBPRl9maW5kZGV2aWNlKGJ1Zikp ID09IC0xKQogCQlyZXR1cm4gKEVOWElPKTsKIAlpZiAoT0ZfZ2V0cHJvcChjaG9zZW4sICJzdGRv dXQiLCBidWYsIHNpemVvZihidWYpKSA8PSAwKQogCQlyZXR1cm4gKEVOWElPKTsK --0016e6d508eb6fa82104afa89f6b Content-Type: application/octet-stream; name="arm-fixes.patch" Content-Disposition: attachment; filename="arm-fixes.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gtygvc7g1 ZGlmZiAtLWdpdCBhL3N5cy9hcm0vbXYvY29tbW9uLmMgYi9zeXMvYXJtL212L2NvbW1vbi5jCmlu ZGV4IDQ1OTZhMjAuLmM3YmVhZTggMTAwNjQ0Ci0tLSBhL3N5cy9hcm0vbXYvY29tbW9uLmMKKysr IGIvc3lzL2FybS9tdi9jb21tb24uYwpAQCAtMTY5Myw3ICsxNjkzLDcgQEAgZmR0X2dldF9yYW5n ZXMoY29uc3QgY2hhciAqbm9kZW5hbWUsIHZvaWQgKmJ1ZiwgaW50IHNpemUsIGludCAqdHVwbGVz LAogCWludCBsZW4sIHR1cGxlX3NpemUsIHR1cGxlc19jb3VudDsKIAogCW5vZGUgPSBPRl9maW5k ZGV2aWNlKG5vZGVuYW1lKTsKLQlpZiAobm9kZSA8PSAwKQorCWlmIChub2RlID09IC0xKQogCQly ZXR1cm4gKEVJTlZBTCk7CiAKIAlpZiAoKGZkdF9hZGRyc2l6ZV9jZWxscyhub2RlLCAmYWRkcl9j ZWxscywgJnNpemVfY2VsbHMpKSAhPSAwKQpAQCAtMTc2MiwxMSArMTc2MiwxMSBAQCB3aW5fY3B1 X2Zyb21fZHQodm9pZCkKIAkvKgogCSAqIFJldHJpZXZlIENFU0EgU1JBTSBkYXRhLgogCSAqLwot CWlmICgobm9kZSA9IE9GX2ZpbmRkZXZpY2UoInNyYW0iKSkgIT0gMCkKKwlpZiAoKG5vZGUgPSBP Rl9maW5kZGV2aWNlKCJzcmFtIikpICE9IC0xKQogCQlpZiAoZmR0X2lzX2NvbXBhdGlibGUobm9k ZSwgIm1ydmwsY2VzYS1zcmFtIikpCiAJCQlnb3RvIG1vdmVvbjsKIAotCWlmICgobm9kZSA9IE9G X2ZpbmRkZXZpY2UoIi8iKSkgPT0gMCkKKwlpZiAoKG5vZGUgPSBPRl9maW5kZGV2aWNlKCIvIikp ICE9IC0xKQogCQlyZXR1cm4gKEVOWElPKTsKIAogCWlmICgobm9kZSA9IGZkdF9maW5kX2NvbXBh dGlibGUobm9kZSwgIm1ydmwsY2VzYS1zcmFtIiwgMCkpID09IDApCkBAIC0xNzk2LDcgKzE3OTYs NyBAQCBmZHRfd2luX3NldHVwKHZvaWQpCiAJaW50IGVyciwgaTsKIAogCW5vZGUgPSBPRl9maW5k ZGV2aWNlKCIvIik7Ci0JaWYgKG5vZGUgPT0gMCkKKwlpZiAobm9kZSA9PSAtMSkKIAkJcGFuaWMo ImZkdF93aW5fc2V0dXA6IG5vIHJvb3Qgbm9kZSIpOwogCiAJbm9kZSA9IGZkdF9maW5kX2NvbXBh dGlibGUobm9kZSwgInNpbXBsZS1idXMiLCAxKTsKZGlmZiAtLWdpdCBhL3N5cy9hcm0vbXYvbXZf bWFjaGRlcC5jIGIvc3lzL2FybS9tdi9tdl9tYWNoZGVwLmMKaW5kZXggZmQxNzY5Mi4uODgzOTc0 MCAxMDA2NDQKLS0tIGEvc3lzL2FybS9tdi9tdl9tYWNoZGVwLmMKKysrIGIvc3lzL2FybS9tdi9t dl9tYWNoZGVwLmMKQEAgLTYxNywxMyArNjE3LDEzIEBAIHBsYXRmb3JtX21wcF9pbml0KHZvaWQp CiAJLyoKIAkgKiBUcnkgdG8gYWNjZXNzIHRoZSBNUFAgbm9kZSBkaXJlY3RseSBpLmUuIHRocm91 Z2ggL2FsaWFzZXMvbXBwLgogCSAqLwotCWlmICgobm9kZSA9IE9GX2ZpbmRkZXZpY2UoIm1wcCIp KSAhPSAwKQorCWlmICgobm9kZSA9IE9GX2ZpbmRkZXZpY2UoIm1wcCIpKSAhPSAtMSkKIAkJaWYg KGZkdF9pc19jb21wYXRpYmxlKG5vZGUsICJtcnZsLG1wcCIpKQogCQkJZ290byBtb3Zlb247CiAJ LyoKIAkgKiBGaW5kIHRoZSBub2RlIHRoZSBsb25nIHdheS4KIAkgKi8KLQlpZiAoKG5vZGUgPSBP Rl9maW5kZGV2aWNlKCIvIikpID09IDApCisJaWYgKChub2RlID0gT0ZfZmluZGRldmljZSgiLyIp KSA9PSAtMSkKIAkJcmV0dXJuIChFTlhJTyk7CiAKIAlpZiAoKG5vZGUgPSBmZHRfZmluZF9jb21w YXRpYmxlKG5vZGUsICJzaW1wbGUtYnVzIiwgMCkpID09IDApCkBAIC03NTIsNyArNzUyLDcgQEAg cGxhdGZvcm1fZGV2bWFwX2luaXQodm9pZCkKIAkvKgogCSAqIFBDSSByYW5nZShzKS4KIAkgKi8K LQlpZiAoKHJvb3QgPSBPRl9maW5kZGV2aWNlKCIvIikpID09IDApCisJaWYgKChyb290ID0gT0Zf ZmluZGRldmljZSgiLyIpKSA9PSAtMSkKIAkJcmV0dXJuIChFTlhJTyk7CiAKIAlmb3IgKGNoaWxk ID0gT0ZfY2hpbGQocm9vdCk7IGNoaWxkICE9IDA7IGNoaWxkID0gT0ZfcGVlcihjaGlsZCkpCkBA IC03NzksNyArNzc5LDcgQEAgcGxhdGZvcm1fZGV2bWFwX2luaXQodm9pZCkKIAkvKgogCSAqIENF U0EgU1JBTSByYW5nZS4KIAkgKi8KLQlpZiAoKGNoaWxkID0gT0ZfZmluZGRldmljZSgic3JhbSIp KSAhPSAwKQorCWlmICgoY2hpbGQgPSBPRl9maW5kZGV2aWNlKCJzcmFtIikpICE9IC0xKQogCQlp ZiAoZmR0X2lzX2NvbXBhdGlibGUoY2hpbGQsICJtcnZsLGNlc2Etc3JhbSIpKQogCQkJZ290byBt b3Zlb247CiAK --0016e6d508eb6fa82104afa89f6b Content-Type: application/octet-stream; name="ppc-fixes.patch" Content-Disposition: attachment; filename="ppc-fixes.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gtygvczc2 ZGlmZiAtLWdpdCBhL3N5cy9kZXYvZmR0L2ZkdF9wb3dlcnBjLmMgYi9zeXMvZGV2L2ZkdC9mZHRf cG93ZXJwYy5jCmluZGV4IGVhNjE0ZGIuLmFjODFjMDggMTAwNjQ0Ci0tLSBhL3N5cy9kZXYvZmR0 L2ZkdF9wb3dlcnBjLmMKKysrIGIvc3lzL2Rldi9mZHQvZmR0X3Bvd2VycGMuYwpAQCAtNjIsNyAr NjIsNyBAQCBmZHRfZml4dXBfYnVzZnJlcShwaGFuZGxlX3Qgcm9vdCkKIAkgKiBUaGlzIGZpeHVw IHVzZXMgL2NwdXMvIGJ1cy1mcmVxdWVuY3kgcHJvcCB2YWx1ZSB0byBzZXQgc2ltcGxlLWJ1cwog CSAqIGJ1cy1mcmVxdWVuY3kgcHJvcGVydHkuCiAJICovCi0JaWYgKChjcHVzID0gT0ZfZmluZGRl dmljZSgiL2NwdXMiKSkgPT0gMCkKKwlpZiAoKGNwdXMgPSBPRl9maW5kZGV2aWNlKCIvY3B1cyIp KSA9PSAtMSkKIAkJcmV0dXJuOwogCiAJaWYgKChjaGlsZCA9IE9GX2NoaWxkKGNwdXMpKSA9PSAw KQpkaWZmIC0tZ2l0IGEvc3lzL3Bvd2VycGMvYm9va2UvcGxhdGZvcm1fYmFyZS5jIGIvc3lzL3Bv d2VycGMvYm9va2UvcGxhdGZvcm1fYmFyZS5jCmluZGV4IGNhM2NmYTIuLmYwNGJmOTYgMTAwNjQ0 Ci0tLSBhL3N5cy9wb3dlcnBjL2Jvb2tlL3BsYXRmb3JtX2JhcmUuYworKysgYi9zeXMvcG93ZXJw Yy9ib29rZS9wbGF0Zm9ybV9iYXJlLmMKQEAgLTE4OSw3ICsxODksNyBAQCBiYXJlX3RpbWViYXNl X2ZyZXEocGxhdGZvcm1fdCBwbGF0LCBzdHJ1Y3QgY3B1cmVmICpjcHVyZWYpCiAJfSBlbHNlCiAJ CXRpY2tzID0gMDsKIAotCWlmICgoY3B1cyA9IE9GX2ZpbmRkZXZpY2UoIi9jcHVzIikpID09IDAp CisJaWYgKChjcHVzID0gT0ZfZmluZGRldmljZSgiL2NwdXMiKSkgPT0gLTEpCiAJCWdvdG8gb3V0 OwogCiAJaWYgKChjaGlsZCA9IE9GX2NoaWxkKGNwdXMpKSA9PSAwKQo= --0016e6d508eb6fa82104afa89f6b-- From owner-freebsd-arm@FreeBSD.ORG Thu Oct 20 22:56:23 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CE26106567A; Thu, 20 Oct 2011 22:56:23 +0000 (UTC) (envelope-from richo@psych0tik.net) Received: from bedford.accountservergroup.com (bedford.accountservergroup.com [50.22.11.19]) by mx1.freebsd.org (Postfix) with ESMTP id 00FD08FC20; Thu, 20 Oct 2011 22:56:22 +0000 (UTC) Received: from boxand.lnk.telstra.net ([203.45.130.125] helo=richh-imac.office.boxdice.com.au) by bedford.accountservergroup.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RH1XB-0001el-AV; Thu, 20 Oct 2011 17:56:21 -0500 Date: Fri, 21 Oct 2011 09:56:39 +1100 From: richo To: "Jayachandran C." Message-ID: <20111020225639.GB15019@richh-imac.office.boxdice.com.au> References: <20111018005939.GA27991@richh-imac.office.boxdice.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tqI+Z3u+9OQ7kwn0" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://natalya.psych0tik.net/~richo/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bedford.accountservergroup.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - psych0tik.net X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-arm@freebsd.org, freebsd-ppc@freebsd.org Subject: Re: HEADSUP: FDT phandle change. [svn commit: r226466] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 22:56:23 -0000 --tqI+Z3u+9OQ7kwn0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 18/10/11 11:28 +0530, Jayachandran C. wrote: >On Tue, Oct 18, 2011 at 6:29 AM, richo wrote: >> On 17/10/11 19:21 +0530, Jayachandran C. wrote: >>> >>> I have committed this revision that changes the way phandle is >>> represented for FDT. =A0The old representation was a pointer, =A0which >>> would not work on 64bit - and the new representation is as an offset. >>> >>> This should not affect the FDT users, but if there is any breakage on >>> ARM or PPC due to this please let me know. >>> >>> Thanks, >>> JC. >>> >> >> I can test on ppc tonight, is there anything specific I need to test, or >> just >> build world+kernel and confirm that it boots? > >buildkernel would be sufficient since this does have changes that >affect the userspace. Let me know if you see any new crash, change in >device behavior or missing devices after these changes. > >Thanks, >JC. Kernel built and booted fine for me on ppc64, on an iMac G5 --=20 richo || Today's excuse:=20 Sticky bits on disk. --tqI+Z3u+9OQ7kwn0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJOoKcnAAoJEIKiWz6J5yQVOL8IAMl6+grXhOMFzV6DRmsbrsAB 6QW0VR79XRTJfUpIpQMrCNKBV87o3y+OdkuHofjahzYF6p+lGoSPGy7xVL071qkh 57nWSEB9EGU+Qqc12c08y7y9IMkljfICTRbGYoQMj8sBS+IouwQi+GDJFZIkp/V9 yKSyFKHXOPvm3yWpHUjgNjdARtfdORE/THNpLxMoJ0IKPU467e0lHPa7QoXJIvCa ZSpr4H5RtCP0FaGHhYSdoNHVqYgFbQ3BYJGAMUUhzz0mb0gv2Qn+PmolV0Ms+aKn jwn4DIj+rzYwOhAmAmNARE0bPGbfAS+x1YlWJ1St9H7f7gnXQ/pY1kMyGAnxuJo= =FhuB -----END PGP SIGNATURE----- --tqI+Z3u+9OQ7kwn0--