From owner-freebsd-arm@FreeBSD.ORG Sun Mar 3 00:02:51 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ECA39763 for ; Sun, 3 Mar 2013 00:02:51 +0000 (UTC) (envelope-from ThomasSkibo@sbcglobal.net) Received: from nm11-vm1.access.bullet.mail.mud.yahoo.com (nm11-vm1.access.bullet.mail.mud.yahoo.com [66.94.237.184]) by mx1.freebsd.org (Postfix) with ESMTP id A2BF3A27 for ; Sun, 3 Mar 2013 00:02:51 +0000 (UTC) Received: from [66.94.237.192] by nm11.access.bullet.mail.mud.yahoo.com with NNFMP; 03 Mar 2013 00:02:45 -0000 Received: from [68.142.198.106] by tm3.access.bullet.mail.mud.yahoo.com with NNFMP; 03 Mar 2013 00:02:45 -0000 Received: from [127.0.0.1] by smtp108.sbc.mail.mud.yahoo.com with NNFMP; 03 Mar 2013 00:02:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1362268965; bh=7zUJUFN4qUczp5DujaE6tSgyP7wkv8HvAaQ6XqJYooQ=; 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:Content-Type:Content-Transfer-Encoding; b=eCUCYW9KH1mtN6w99wtsgxLPbj6TaXEEvrfbUfMXqvwC00tSKB9BBgln3F6db1R+bRdr141oa9HQGElnBCPbmlDtVChBdEZB33avHp+P9C1A5AXMVH5dE68CwhIUNrN8X9aPp3Z8RabiZAobQ9XekTlQ4OZPTQHgnPZOizVMa3M= X-Yahoo-Newman-Id: 680006.84655.bm@smtp108.sbc.mail.mud.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: xhb2PLcVM1nh5FUN3ZG4yQCovzOo7k75FchI2adqpz8SXAw NGWNaTZAbGBTZ1Rl2ApC_BvpxuhsY31VwgqvW5HQoLN9_yedR2XW7Rzgh8yf UTeF3nx3uQHxCb7Ncs.BLIZn4oizvUZNym8Vshn5zPpRw_tND71HSRCEGEBT aw7JyCVPOIcYBU3jvDkAiBix6yOIxuk9Gyo7BKpx0Wg2YDSNsQCEZWxNWvwB Bcp8WXG1hDe6a2ZaH3iBvCKPoGRTvLO7iCuLC8W7jw9k7uK8kii0TbhLRs0m 9WUUygoT24G0uNKR7rxFqNdek6KKpHIVLtK..5BVqgwX6RqDLMP5l9P.mktk eQGPptC1SlsZ.eysXvZ.Oa8hBR.wnMm.5tlcwXNceOOfUugBwo05uK4srlqE a_pfNJ4K6osAcJcdaebys4SUq_odqKgmfUaxLnvuDg.NU304pz7RQGKVhCXC NjWUxJ5B_9sFdhSYFIwCyGvQC0NupUY.3GikQ5xF.o5Tk7VsqmW61Vjzf3yg - X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- Received: from [192.168.1.9] (ThomasSkibo@71.139.174.219 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 02 Mar 2013 16:02:45 -0800 PST Message-ID: <51329325.7070301@sbcglobal.net> Date: Sat, 02 Mar 2013 16:02:45 -0800 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: A bug in busdma_machdep-v6.c? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 00:02:52 -0000 Hello. I've been trying to solve a tcp checksum bug and I think I see a problem in _bus_dmamap_load_buffer(): In the following code bit, a segment is tacked onto the previous segment's slist[] entry if it is adjacent to the previous segment in virtual memory. That's okay if all cache operations use virtual addresses but if the level 2 cache operations need physical addresses (ARM_L2_PIPT), the physical address of the second segment is lost. I don't think bus_dmamap_sync() is properly wb/invalidating the second segment from the level 2 cache. 1008 sl = &map->slist[map->sync_count - 1]; 1009 if (map->sync_count == 0 || 1010 vaddr != sl->vaddr + sl->datacount) { 1011 if (++map->sync_count > dmat->nsegments) 1012 goto cleanup; 1013 sl++; 1014 sl->vaddr = vaddr; 1015 sl->datacount = sgsize; 1016 sl->busaddr = curaddr; 1017 } else 1018 sl->datacount += sgsize; 1019 } I was seeing bad checksums on large packets. While examining the dma descriptors of the offending packets, I noticed that the second of three segments always ended on a page boundary so I just guessed the second and third were one buffer straddling a page boundary. So far, this patch is fixing the problem for me: *************** *** 1007,1012 **** --- 1007,1015 ---- } else { sl = &map->slist[map->sync_count - 1]; if (map->sync_count == 0 || + #ifdef ARM_L2_PIPT + curaddr != sl->busaddr + sl->datacount || + #endif vaddr != sl->vaddr + sl->datacount) { if (++map->sync_count > dmat->nsegments) goto cleanup; -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Sun Mar 3 00:15:29 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 897CE8E6 for ; Sun, 3 Mar 2013 00:15:29 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:150:ca0a:a9ff:fef1:a4c9]) by mx1.freebsd.org (Postfix) with ESMTP id 2F762A69 for ; Sun, 3 Mar 2013 00:15:28 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.5/8.14.5) with ESMTP id r230F4cr055043; Sun, 3 Mar 2013 01:15:04 +0100 (CET) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.5/8.14.5/Submit) id r230F4HH055042; Sun, 3 Mar 2013 01:15:04 +0100 (CET) (envelope-from mlfbsd) Date: Sun, 3 Mar 2013 01:15:04 +0100 From: Olivier Houchard To: Thomas Skibo Subject: Re: A bug in busdma_machdep-v6.c? Message-ID: <20130303001504.GA55003@ci0.org> References: <51329325.7070301@sbcglobal.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51329325.7070301@sbcglobal.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 00:15:29 -0000 On Sat, Mar 02, 2013 at 04:02:45PM -0800, Thomas Skibo wrote: > > Hello. > > I've been trying to solve a tcp checksum bug and I think I see a problem > in _bus_dmamap_load_buffer(): > > In the following code bit, a segment is tacked onto the previous > segment's slist[] entry if it is adjacent to the previous segment in > virtual memory. That's okay if all cache operations use virtual > addresses but if the level 2 cache operations need physical addresses > (ARM_L2_PIPT), the physical address of the second segment is lost. I > don't think bus_dmamap_sync() is properly wb/invalidating the second > segment from the level 2 cache. > Hi Thomas, That makes sense. I'll commit your patch tomorrow if nobody else does it before. Thanks ! Olivier From owner-freebsd-arm@FreeBSD.ORG Sun Mar 3 01:18:58 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 70B8A766 for ; Sun, 3 Mar 2013 01:18:58 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 25773C2C for ; Sun, 3 Mar 2013 01:18:57 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UBxZp-0008X0-3M; Sun, 03 Mar 2013 01:18:57 +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 r231IrTs089121; Sat, 2 Mar 2013 18:18:54 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18T+qFpcDGVXtGgmyab6WxI Subject: Re: PHYSADDR From: Ian Lepore To: Tim Kientzle In-Reply-To: References: <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> <8FEA3237-8ABF-4564-B672-4B4C0C6EF291@kientzle.com> <1362155632.1195.120.camel@revolution.hippie.lan> <5B622D1B-4EAE-4184-A194-DD14083A48B6@kientzle.com> <1362246634.1195.178.camel@revolution.hippie.lan> Content-Type: multipart/mixed; boundary="=-YTotqcJXRcyvz05kVYP6" Date: Sat, 02 Mar 2013 18:18:53 -0700 Message-ID: <1362273533.1195.199.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 01:18:58 -0000 --=-YTotqcJXRcyvz05kVYP6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sat, 2013-03-02 at 10:10 -0800, Tim Kientzle wrote: > On Mar 2, 2013, at 9:50 AM, Ian Lepore wrote: > > >[...] > > > I'm not sure its safe to assume that (entry-pc & 0xfffff000) is the > > beginning of the kernel; it's true now but need not be so. But that's > > no big deal, we can tweak the linker script to give us the offset of the > > _start symbol so it'll work no matter what. > > Patches? ;-) This turned out to be a bit trickier than I first thought it would be, but it worked out. This gets rids of any reference to PHYSADDR and similar constants in the main path through the code. I didn't address the "running from flash" case or anything under #ifdef SMP, yet. The only constant left is KERNBASE which is 0xC0000000 for all arm systems. For now I've got #undef PHYSADDR at the top of the code; this is just for testing without having to remove it yet from anywhere else. There are two ldscript changes: define a new ENTRY_OFFSET symbol which is the offset between the start of the load image and the _start symbol, and also it puts the physical addresses in the headers, by calculating a physical value for ENTRY(), and using an AT(expr) for the text segment, which very conviently just flows to the following segments without needing to re-specify it on every new segment. This isn't ready to commit, but it's ready to play with, and to get comments from folks who know some of the history of this code (Olivier has been helping me on irc all day answering such questions). -- Ian --=-YTotqcJXRcyvz05kVYP6 Content-Description: Content-Disposition: inline; filename="locore_physaddr.diff" Content-Type: text/x-patch; name="locore_physaddr.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/arm/arm/locore.S =================================================================== --- sys/arm/arm/locore.S (revision 247421) +++ sys/arm/arm/locore.S (working copy) @@ -41,6 +41,8 @@ __FBSDID("$FreeBSD$"); +#undef PHYSADDR + /* What size should this really be ? It is only used by initarm() */ #define INIT_ARM_STACK_SIZE (2048 * 4) @@ -52,16 +54,8 @@ __FBSDID("$FreeBSD$"); mov tmp, tmp /* wait for it to complete */ ;\ CPWAIT_BRANCH /* branch to next insn */ -/* - * This is for kvm_mkdb, and should be the address of the beginning - * of the kernel text segment (not necessarily the same as kernbase). - */ .text .align 0 -.globl kernbase -.set kernbase,KERNBASE -.globl physaddr -.set physaddr,PHYSADDR /* * On entry for FreeBSD boot ABI: @@ -87,7 +81,7 @@ ASENTRY_NP(_start) orr r7, r7, #(I32_bit|F32_bit) msr cpsr_c, r7 -#if defined (FLASHADDR) && defined(LOADERRAMADDR) +#if defined(PHYSADDR) && defined(FLASHADDR) && defined(LOADERRAMADDR) /* Check if we're running from flash. */ ldr r7, =FLASHADDR /* @@ -123,11 +117,23 @@ Lram_offset: .word from_ram-_C_LABEL(_start) from_ram: nop #endif + + /* + * The MMU could be disabled (we're on physical addressing), + * or it could be enabled with VA=PA, or it could be enabled + * with some mystery mapping. In the latter case, there's no + * easy way to recover the current physical address from the PC. + * We could maybe do a manual tlb walk, but for now we'll just + * require that the physical address be provided at compile time. + * This is all legacy stuff to support redboot long ago. + */ + adr r7, Lunmapped +#ifdef PHYSADDR bic r7, r7, #0xf0000000 orr r7, r7, #PHYSADDR +#endif - disable_mmu: /* Disable MMU for a while */ mrc p15, 0, r2, c1, c0, 0 @@ -142,12 +148,39 @@ disable_mmu: nop mov pc, r7 Lunmapped: + +#ifdef PHYSADDR + ldr r6, =PHYSADDR /* If PHYSADDR is provided, use it. */ +#else + adr r0, entry_offset /* Load the linker-provided offset */ + ldr r0, [r0] /* between _start and the start of */ + adr r6, _start /* the image. Subtract the offset */ + sub r6, r6, r0 /* to get the physical load addr. */ +#endif + adr r0, kern_physaddr /* Save it (for debugging mostly). */ + str r6, [r0] /* We'll use the addr to build L1 */ + mov r0, #0xff000000 /* section PDEs that map 1MB each; */ + orr r0, #0x00f00000 /* mask the load address to round */ + and r6, r6, r0 /* to previous 1MB boundary. */ + #ifdef STARTUP_PAGETABLE_ADDR + /* build page table from scratch */ - ldr r0, Lstartup_pagetable adr r4, mmu_init_table - b 3f +#define fix_mmu_init(offset) \ + ldr r0, [r4, offset] ; \ + orr r0, r0, r6 ; \ + str r0, [r4, offset] + + fix_mmu_init(#4) /* Adjust the va and pa values in */ + fix_mmu_init(#8) /* the first two mmu init table */ + fix_mmu_init(#16) /* entries to the actual physical */ + fix_mmu_init(#20) /* load address calculated above. */ + + ldr r0, Lstartup_pagetable + b 3f /* Go start building the table. */ + 2: str r3, [r0, r2] add r2, r2, #4 @@ -156,11 +189,9 @@ Lunmapped: bhi 2b 3: ldmia r4!, {r1,r2,r3} /* # of sections, VA, PA|attr */ + mov r2, r2, LSR #(L1_S_SHIFT-2) cmp r1, #0 - adrne r5, 2b - bicne r5, r5, #0xf0000000 - orrne r5, r5, #PHYSADDR - movne pc, r5 + bne 2b #if defined(SMP) orr r0, r0, #2 /* Set TTB shared memory flag */ @@ -222,15 +253,7 @@ virt_done: b _C_LABEL(panic) /* NOTREACHED */ #ifdef STARTUP_PAGETABLE_ADDR -#define MMU_INIT(va,pa,n_sec,attr) \ - .word n_sec ; \ - .word 4*((va)>>L1_S_SHIFT) ; \ - .word (pa)|(attr) ; -Lvirtaddr: - .word KERNVIRTADDR -Lphysaddr: - .word KERNPHYSADDR Lreal_start: .word _start Lend: @@ -241,21 +264,47 @@ Lstartup_pagetable: Lstartup_pagetable_secondary: .word temp_pagetable #endif -mmu_init_table: - /* fill all table VA==PA */ - /* map SDRAM VA==PA, WT cacheable */ + +/* + * mmu_init_table: data used to construct the initial page tables. + * + * Note that the first two table entries are magical. They establish va=pa and + * kernva=pa mappings for the first 64 mb starting at the kernel's physical load + * address. The virtual and physical addresses of just the first two entries + * are re-written by the code that builds the L1 table, to add in the offset at + * which the kernel is physically loaded/running. Any entries after the first + * two are mapped without modification. This is especially useful for things + * like temporarily adding mappings for serial console hardware for debugging. + */ #if !defined(SMP) - MMU_INIT(PHYSADDR, PHYSADDR , 64, L1_TYPE_S|L1_S_C|L1_S_AP(AP_KRW)) - /* map VA 0xc0000000..0xc3ffffff to PA */ - MMU_INIT(KERNBASE, PHYSADDR, 64, L1_TYPE_S|L1_S_C|L1_S_AP(AP_KRW)) +#define VM_ATTR_DEV (L1_TYPE_S|L1_S_AP(AP_KRW)) +#define VM_ATTR_RAM (L1_TYPE_S|L1_S_AP(AP_KRW)|L1_S_C) #else - MMU_INIT(PHYSADDR, PHYSADDR , 64, L1_TYPE_S|L1_SHARED|L1_S_C|L1_S_AP(AP_KRW)) - /* map VA 0xc0000000..0xc3ffffff to PA */ - MMU_INIT(KERNBASE, PHYSADDR, 64, L1_TYPE_S|L1_SHARED|L1_S_C|L1_S_AP(AP_KRW)) - MMU_INIT(0x48000000, 0x48000000, 1, L1_TYPE_S|L1_SHARED|L1_S_C|L1_S_AP(AP_KRW)) +#define VM_ATTR_DEV (L1_TYPE_S|L1_S_AP(AP_KRW)|L1_SHARED) +#define VM_ATTR_RAM (L1_TYPE_S|L1_S_AP(AP_KRW)|L1_SHARED|L1_S_C) #endif + +#define MMU_INIT(va,pa,n_sec,attr) \ + .word (n_sec) ; \ + .word (va) ; \ + .word (pa)|(attr) ; + +mmu_init_table: + MMU_INIT(0, 0, 256, VM_ATTR_RAM) + MMU_INIT(KERNBASE, 0, 256, VM_ATTR_RAM) +/* MMU_INIT(0xFFF00000, 0xFFF00000, 1, VM_ATTR_DEV) example hw entry */ .word 0 /* end of table */ -#endif + +#endif /* STARTUP_PAGETABLE_ADDR */ + + .extern ENTRY_OFFSET /* Import this symbol generated by */ +entry_offset: /* ldscript.arm. It is the offset */ + .word ENTRY_OFFSET /* of _start in the loaded image. */ + + .globl kern_physaddr /* Export calculated addr, mostly */ +kern_physaddr: /* for debugging. There may be */ + .word 0 /* no reason to keep this. */ + .Lstart: .word _edata .word _end Index: sys/conf/ldscript.arm =================================================================== --- sys/conf/ldscript.arm (revision 247421) +++ sys/conf/ldscript.arm (working copy) @@ -1,13 +1,17 @@ /* $FreeBSD$ */ OUTPUT_ARCH(arm) -ENTRY(_start) -SEARCH_DIR(/usr/lib); +PHYSOFFS = KERNVIRTADDR - KERNPHYSADDR; +PHYSENTRY = _start - PHYSOFFS; + +ENTRY(PHYSENTRY) + SECTIONS { /* Read-only sections, merged into text segment: */ . = KERNVIRTADDR + SIZEOF_HEADERS; - .text : + ENTRY_OFFSET = _start - KERNVIRTADDR; + .text : AT(ADDR(.text) - PHYSOFFS) { *(.text) *(.stub) --=-YTotqcJXRcyvz05kVYP6-- From owner-freebsd-arm@FreeBSD.ORG Sun Mar 3 02:22:04 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C9B43787; Sun, 3 Mar 2013 02:22:04 +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 9A94CE54; Sun, 3 Mar 2013 02:22:04 +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 <0MJ20029WBWQ7150@smtp3.clear.net.nz>; Sun, 03 Mar 2013 15:22:02 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO bender) ([202.0.48.19]) by smtpin32.paradise.net.nz with ESMTP; Sun, 03 Mar 2013 15:22:02 +1300 Date: Sun, 03 Mar 2013 15:22:01 +1300 From: Andrew Turner Subject: Re: ARM EABI test image In-reply-to: To: Warner Losh Message-id: <20130303152201.15d0e209@bender> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit References: <20130302172556.5b59e122@bender> <1362246830.1195.181.camel@revolution.hippie.lan> Cc: freebsd-arm@FreeBSD.org, Ian Lepore , Ronald Klop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 02:22:04 -0000 On Sat, 2 Mar 2013 16:16:22 -0700 Warner Losh wrote: > > On Mar 2, 2013, at 10:53 AM, Ian Lepore wrote: > > > On Sat, 2013-03-02 at 18:21 +0100, Ronald Klop wrote: > >> On Sat, 02 Mar 2013 05:25:56 +0100, Andrew Turner > >> wrote: > >> > >>> Hello, > >>> > >>> I have built an updated ARM EABI test image for Raspberry Pi [1]. > >>> > >>> The only known issue is c++ exception handling is broken when > >>> using in a dynamically linked executable. Static executables > >>> should work with c++ exceptions. > >>> > >>> To test it you will have to extract it using unxz and dd it to an > >>> sd card, for example, with a USB to SD adapter on /dev/da0: > >>> $ unxz bsd-pi-eabi-r247609.img.xz > >>> $ dd if=bsd-pi-eabi-r247609.img of=/dev/da0 > >>> > >>> If you don't have a Raspberry Pi but would like to try it on your > >>> board you can add -DWITH_ARM_EABI to the make commands you use to > >>> build and install world and the kernel. > >> > >> Is this also interesing on the older SHEEVAPLUG? > >> If yes, I can test it somewhere next week. > >> > >> Ronald. > > > > As I understand it, the plan is that eventually everything is EABI, > > including the older armv4/5 stuff, so that needs testing too. > > > > You know what I haven't stumbled across yet is a simple explanation > > of why EABI is better then OABI. I tried to search for some info > > the other day, but there are so many noise hits on the search I > > didn't find a simple synopsis of differences or advantages. > > Alignment of structures is more like x86. This makes all the weird > hacks we have in the tree to support the old ABI obsolete, and makes > all the broken ones that we don't know about fixed. > > I'm sure there's a bunch more, but that's the main reason I want it :) This, along with better toolchain and floating point support along with better arm/thumb interoperability. I'm starting to look into using the hard-float version of the ABI on armv6 and I would like to support thumb mode in the future. There are a number of third-party projects that only support EABI, including Qt and maybe node.js. Andrew From owner-freebsd-arm@FreeBSD.ORG Sun Mar 3 03:31:50 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7149B1B0; Sun, 3 Mar 2013 03:31:50 +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 26D7D152; Sun, 3 Mar 2013 03:31:49 +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 <0MJ200MKYF4SGQ00@smtp4.clear.net.nz>; Sun, 03 Mar 2013 16:31:41 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO bender) ([202.0.48.19]) by smtpin1.paradise.net.nz with ESMTP; Sun, 03 Mar 2013 16:31:40 +1300 Date: Sun, 03 Mar 2013 16:31:39 +1300 From: Andrew Turner Subject: Re: About board-specific files.* In-reply-to: <58FF3A9F-2782-429F-BE82-27728E8D209D@bsdimp.com> To: Warner Losh Message-id: <20130303163139.3af41ae5@bender> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 8BIT References: <58FF3A9F-2782-429F-BE82-27728E8D209D@bsdimp.com> Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 03:31:50 -0000 On Sat, 2 Mar 2013 16:20:54 -0700 Warner Losh wrote: > > On Mar 2, 2013, at 2:05 PM, Tim Kientzle wrote: > > > Now that I think I understand some of the issues in building > > a GENERIC arm kernel, I'm starting to piece together > > a kernel that has both RPi and BBone bits that I can > > use as a testbed. > > > > Next Problem: A lot of the boards are using > > board-specific files.* to control what files get > > linked into the kernel. > > > > This seems like a real problem for a GENERIC kernel, > > so I propose merging them into sys/conf/files.arm. > > > > Here's how I'm doing it right now for my current > > experiments. If anyone has a better idea, I'm > > definitely interested. > > > > Basically, I'm using "device bcm2835" to represent > > all of the basic support for that particular SoC. > > (An SoC is, after all, just another piece of hardware.) > > > > Then the files marked "standard" in > > arm/bcm2835/files.bcm2835 move to > > files.arm as "optional bcm2835". > > > > With this approach, the GENERIC arm kernel will > > list the SoCs as devices: > > > > device bcm2835 > > device am335x > > device omap4 > > … etc … > > > > That will bring in the basic support for those SoCs > > (e.g., interrupt handler, gpio, clock management, etc). > > Additional drivers (SDHCI, UART, USB, etc) will > > be separate devices. > > > > I think this makes sense, but I'm open to other ideas. > > I think this is perfect. It is what atmel uses to bring in different > atmel things. I don't think there are any atmel files specified as > std any more, and if there are they could transition to this. I know > this isn't an issue for a GENERIC for armv6, since there is not way > an armv4 and an armv6 kernel could be built today... I don't think that is a problem. We can have two GENERIC kernels, i.e. an arm and an armv6 kernel. Having two GENERIC like kernels doesn't preclude having a single GENERIC in the future, quite the opposite. We are unlikely to have a GENERIC kernel for any hardware that doesn't have fdt, or some other way to detect which SoC & board we are running on. Andrew From owner-freebsd-arm@FreeBSD.ORG Sun Mar 3 04:18:37 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4C4A189A for ; Sun, 3 Mar 2013 04:18:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id C7DC927A for ; Sun, 3 Mar 2013 04:18:36 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id c13so5101479ieb.9 for ; Sat, 02 Mar 2013 20:18:36 -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=isPngWJxVTFi9P8xG2YKlHjhrQOP7zlBK7F9X3PPbmA=; b=MZcKvM6G1SlSwopdLXfnQ4Hdwt0nbXjRCfcm8eCYVXkQdrhWpM8uuQKJnpHpGow9ku bIIeV6wrAfEfU6jKi9Ein3qQ1phNli5XjN5J4R0WHa9mYTCxEeN6TlteouNPoRkcRhY8 i8/ll6oE5LV4EBNayJZ8ks5UpnmOag7qYm6EU4YBd2BiKguFq+OLAByzvfBov0/lEOVZ wCKpRZLpmVQ5hHoRfWcSsSqY57p3ydM+up3WavZyBx8yj5dL93RSqqz2P5nnLZUIDdPl tZRtq83aSf7VAin4w2thnPUDONqK2DY/TApzg/y0ovkMFGqiHT9tCXUkHcwNUuOM5eyD IkLg== X-Received: by 10.43.111.201 with SMTP id ep9mr19050405icc.43.1362284316237; Sat, 02 Mar 2013 20:18:36 -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 gy3sm5410637igc.10.2013.03.02.20.18.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Mar 2013 20:18:35 -0800 (PST) Sender: Warner Losh Subject: Re: PHYSADDR Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1362273533.1195.199.camel@revolution.hippie.lan> Date: Sat, 2 Mar 2013 21:18:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <042A3136-C7E6-4824-B153-8C8778376106@bsdimp.com> References: <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> <8FEA3237-8ABF-4564-B672-4B4C0C6EF291@kientzle.com> <1362155632.1195.120.camel@revolution.hippie.lan> <5B622D1B-4EAE-4184-A194-DD14083A48B6@kientzle.com> <1362246634.1195.178.camel@revolution.hippie.lan> <1362273533.1195.199.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnrxMOcOM5l7OVav4mtcd5xIo8rJaef80DEB9e96KH5uFLM/dDb9HHBr7aZlBCJmE8ytvmh Cc: Tim Kientzle , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 04:18:37 -0000 I didn't review this in great detail, but I agree: this isn't quite = ready to commit. Just had one comment inline... On Mar 2, 2013, at 6:18 PM, Ian Lepore wrote: > On Sat, 2013-03-02 at 10:10 -0800, Tim Kientzle wrote: >> On Mar 2, 2013, at 9:50 AM, Ian Lepore wrote: >>=20 >>> [...] >>=20 >>> I'm not sure its safe to assume that (entry-pc & 0xfffff000) is the >>> beginning of the kernel; it's true now but need not be so. But = that's >>> no big deal, we can tweak the linker script to give us the offset of = the >>> _start symbol so it'll work no matter what. >>=20 >> Patches? ;-) >=20 > This turned out to be a bit trickier than I first thought it would be, > but it worked out. >=20 > This gets rids of any reference to PHYSADDR and similar constants in = the > main path through the code. I didn't address the "running from flash" > case or anything under #ifdef SMP, yet. The only constant left is > KERNBASE which is 0xC0000000 for all arm systems. >=20 > For now I've got #undef PHYSADDR at the top of the code; this is just > for testing without having to remove it yet from anywhere else. >=20 > There are two ldscript changes: define a new ENTRY_OFFSET symbol which > is the offset between the start of the load image and the _start = symbol, > and also it puts the physical addresses in the headers, by calculating = a > physical value for ENTRY(), and using an AT(expr) for the text = segment, > which very conviently just flows to the following segments without > needing to re-specify it on every new segment. >=20 > This isn't ready to commit, but it's ready to play with, and to get > comments from folks who know some of the history of this code (Olivier > has been helping me on irc all day answering such questions). >=20 > -- Ian >=20 > Index: sys/arm/arm/locore.S > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/arm/arm/locore.S (revision 247421) > +++ sys/arm/arm/locore.S (working copy) > @@ -41,6 +41,8 @@ >=20 > __FBSDID("$FreeBSD$"); >=20 > +#undef PHYSADDR > + > /* What size should this really be ? It is only used by initarm() */ > #define INIT_ARM_STACK_SIZE (2048 * 4) >=20 > @@ -52,16 +54,8 @@ __FBSDID("$FreeBSD$"); > mov tmp, tmp /* wait for it to complete */ = ;\ > CPWAIT_BRANCH /* branch to next insn */ >=20 > -/* > - * This is for kvm_mkdb, and should be the address of the beginning > - * of the kernel text segment (not necessarily the same as kernbase). > - */ > .text > .align 0 > -.globl kernbase > -.set kernbase,KERNBASE > -.globl physaddr > -.set physaddr,PHYSADDR >=20 > /* > * On entry for FreeBSD boot ABI: > @@ -87,7 +81,7 @@ ASENTRY_NP(_start) > orr r7, r7, #(I32_bit|F32_bit) > msr cpsr_c, r7 >=20 > -#if defined (FLASHADDR) && defined(LOADERRAMADDR) > +#if defined(PHYSADDR) && defined(FLASHADDR) && defined(LOADERRAMADDR) > /* Check if we're running from flash. */ > ldr r7, =3DFLASHADDR > /* > @@ -123,11 +117,23 @@ Lram_offset: .word from_ram-_C_LABEL(_start) > from_ram: > nop > #endif > + > + /* > + * The MMU could be disabled (we're on physical addressing), > + * or it could be enabled with VA=3DPA, or it could be enabled > + * with some mystery mapping. In the latter case, there's no > + * easy way to recover the current physical address from the PC. > + * We could maybe do a manual tlb walk, but for now we'll just > + * require that the physical address be provided at compile = time. > + * This is all legacy stuff to support redboot long ago. > + */ Linux requires that the kernel be booted without the MMU enabled to = simplify this case. Is there any reason we can't do the same? > adr r7, Lunmapped > +#ifdef PHYSADDR > bic r7, r7, #0xf0000000 > orr r7, r7, #PHYSADDR > +#endif >=20 > - > disable_mmu: > /* Disable MMU for a while */ > mrc p15, 0, r2, c1, c0, 0 > @@ -142,12 +148,39 @@ disable_mmu: > nop > mov pc, r7 > Lunmapped: > + > +#ifdef PHYSADDR > + ldr r6, =3DPHYSADDR /* If PHYSADDR is provided, use = it. */ > +#else > + adr r0, entry_offset /* Load the linker-provided = offset */ > + ldr r0, [r0] /* between _start and the start = of */ > + adr r6, _start /* the image. Subtract the = offset */ > + sub r6, r6, r0 /* to get the physical load = addr. */ > +#endif > + adr r0, kern_physaddr /* Save it (for debugging = mostly). */ > + str r6, [r0] /* We'll use the addr to build = L1 */ > + mov r0, #0xff000000 /* section PDEs that map 1MB = each; */ > + orr r0, #0x00f00000 /* mask the load address to = round */ > + and r6, r6, r0 /* to previous 1MB boundary. */ > + > #ifdef STARTUP_PAGETABLE_ADDR > + > /* build page table from scratch */ > - ldr r0, Lstartup_pagetable > adr r4, mmu_init_table > - b 3f >=20 > +#define fix_mmu_init(offset) \ > + ldr r0, [r4, offset] ; \ > + orr r0, r0, r6 ; \ > + str r0, [r4, offset] > + > + fix_mmu_init(#4) /* Adjust the va and pa values = in */ > + fix_mmu_init(#8) /* the first two mmu init table = */ > + fix_mmu_init(#16) /* entries to the actual = physical */ > + fix_mmu_init(#20) /* load address calculated = above. */ > + > + ldr r0, Lstartup_pagetable > + b 3f /* Go start building the table. = */ > + > 2: > str r3, [r0, r2] > add r2, r2, #4 > @@ -156,11 +189,9 @@ Lunmapped: > bhi 2b > 3: > ldmia r4!, {r1,r2,r3} /* # of sections, VA, PA|attr */ > + mov r2, r2, LSR #(L1_S_SHIFT-2) > cmp r1, #0 > - adrne r5, 2b > - bicne r5, r5, #0xf0000000 > - orrne r5, r5, #PHYSADDR > - movne pc, r5 > + bne 2b >=20 > #if defined(SMP) > orr r0, r0, #2 /* Set TTB shared memory flag */ > @@ -222,15 +253,7 @@ virt_done: > b _C_LABEL(panic) > /* NOTREACHED */ > #ifdef STARTUP_PAGETABLE_ADDR > -#define MMU_INIT(va,pa,n_sec,attr) \ > - .word n_sec ; \ > - .word 4*((va)>>L1_S_SHIFT) ; \ > - .word (pa)|(attr) ; >=20 > -Lvirtaddr: > - .word KERNVIRTADDR > -Lphysaddr: > - .word KERNPHYSADDR > Lreal_start: > .word _start > Lend:=09 > @@ -241,21 +264,47 @@ Lstartup_pagetable: > Lstartup_pagetable_secondary: > .word temp_pagetable > #endif > -mmu_init_table: > - /* fill all table VA=3D=3DPA */ > - /* map SDRAM VA=3D=3DPA, WT cacheable */ > + > +/*=20 > + * mmu_init_table: data used to construct the initial page tables. > + *=20 > + * Note that the first two table entries are magical. They establish = va=3Dpa and > + * kernva=3Dpa mappings for the first 64 mb starting at the kernel's = physical load > + * address. The virtual and physical addresses of just the first two = entries > + * are re-written by the code that builds the L1 table, to add in the = offset at > + * which the kernel is physically loaded/running. Any entries after = the first > + * two are mapped without modification. This is especially useful = for things > + * like temporarily adding mappings for serial console hardware for = debugging. > + */ > #if !defined(SMP) > - MMU_INIT(PHYSADDR, PHYSADDR , 64, = L1_TYPE_S|L1_S_C|L1_S_AP(AP_KRW)) > - /* map VA 0xc0000000..0xc3ffffff to PA */ > - MMU_INIT(KERNBASE, PHYSADDR, 64, = L1_TYPE_S|L1_S_C|L1_S_AP(AP_KRW)) > +#define VM_ATTR_DEV (L1_TYPE_S|L1_S_AP(AP_KRW)) > +#define VM_ATTR_RAM (L1_TYPE_S|L1_S_AP(AP_KRW)|L1_S_C) > #else > - MMU_INIT(PHYSADDR, PHYSADDR , 64, = L1_TYPE_S|L1_SHARED|L1_S_C|L1_S_AP(AP_KRW)) > - /* map VA 0xc0000000..0xc3ffffff to PA */ > - MMU_INIT(KERNBASE, PHYSADDR, 64, = L1_TYPE_S|L1_SHARED|L1_S_C|L1_S_AP(AP_KRW)) > - MMU_INIT(0x48000000, 0x48000000, 1, = L1_TYPE_S|L1_SHARED|L1_S_C|L1_S_AP(AP_KRW)) > +#define VM_ATTR_DEV (L1_TYPE_S|L1_S_AP(AP_KRW)|L1_SHARED) > +#define VM_ATTR_RAM (L1_TYPE_S|L1_S_AP(AP_KRW)|L1_SHARED|L1_S_C) > #endif > + > +#define MMU_INIT(va,pa,n_sec,attr) \ > + .word (n_sec) ; \ > + .word (va) ; \ > + .word (pa)|(attr) ; > + > +mmu_init_table: > + MMU_INIT(0, 0, 256, VM_ATTR_RAM) > + MMU_INIT(KERNBASE, 0, 256, VM_ATTR_RAM) > +/* MMU_INIT(0xFFF00000, 0xFFF00000, 1, VM_ATTR_DEV) example hw = entry */ > .word 0 /* end of table */ > -#endif > + > +#endif /* STARTUP_PAGETABLE_ADDR */ > + > + .extern ENTRY_OFFSET /* Import this symbol generated = by */ > +entry_offset: /* ldscript.arm. It is = the offset */ > + .word ENTRY_OFFSET /* of _start in the loaded = image. */ > + > + .globl kern_physaddr /* Export calculated addr, = mostly */ > +kern_physaddr: /* for debugging. There = may be */ > + .word 0 /* no reason to keep this. */ > + > .Lstart: > .word _edata > .word _end > Index: sys/conf/ldscript.arm > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/conf/ldscript.arm (revision 247421) > +++ sys/conf/ldscript.arm (working copy) > @@ -1,13 +1,17 @@ > /* $FreeBSD$ */ > OUTPUT_ARCH(arm) > -ENTRY(_start) >=20 > -SEARCH_DIR(/usr/lib); > +PHYSOFFS =3D KERNVIRTADDR - KERNPHYSADDR; > +PHYSENTRY =3D _start - PHYSOFFS; > + > +ENTRY(PHYSENTRY) > + > SECTIONS > { > /* Read-only sections, merged into text segment: */ > . =3D KERNVIRTADDR + SIZEOF_HEADERS; > - .text : > + ENTRY_OFFSET =3D _start - KERNVIRTADDR; > + .text : AT(ADDR(.text) - PHYSOFFS) =20 > { > *(.text) > *(.stub) > _______________________________________________ > 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 Sun Mar 3 04:21:06 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B0C709D5 for ; Sun, 3 Mar 2013 04:21:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 720EA28C for ; Sun, 3 Mar 2013 04:21:06 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id bn7so5089512ieb.11 for ; Sat, 02 Mar 2013 20:21:06 -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=2dGcD423IgQYr0sWwQxAokqItfcbHkmP/YOVmMsry50=; b=aVo67bT3TzFSlAb9FSPQOnWEXaf2mVuFRewg3YgRHhPkG0BYxq5Sq6I+p8DM/zVzUF TjGM0VP9hzDJhvDH+UuvMD5os6TLoerdPNR8SkLv1s1DBiGrrLjFesZCpjEx5gkl3A57 QeJCUJeT5KwW1Nm9QI540dLsppj86ypVrtRsnymU9ODkhyp7w4mAhgZv2AtOVM085KVE 2mXOd5CBc/6G29iHzlx7YYAqp5Z9stfkLWYHSqCltq5pqL6SqEjikgfJjUu3DsELrhAW LkGORefLhPPnGAM834w1hd/C0zp74x47wYnwTWiRr8193Y51XpqCV/fVG/m7IsOaTOX+ krLw== X-Received: by 10.42.247.8 with SMTP id ma8mr19000182icb.1.1362284465882; Sat, 02 Mar 2013 20:21:05 -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 xe9sm4782124igb.7.2013.03.02.20.21.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Mar 2013 20:21:05 -0800 (PST) Sender: Warner Losh Subject: Re: About board-specific files.* Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: <20130303163139.3af41ae5@bender> Date: Sat, 2 Mar 2013 21:21:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <83771FC1-9729-4DFF-A336-B61F4FD32368@bsdimp.com> References: <58FF3A9F-2782-429F-BE82-27728E8D209D@bsdimp.com> <20130303163139.3af41ae5@bender> To: Andrew Turner X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkdpUdoZzqDDJh2Q1pwQaQ7M/y7WwSg8uyywHfEzbSn4zZxuIy8ha8WAjQ+Qd6lyx5Dbygn Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 04:21:06 -0000 On Mar 2, 2013, at 8:31 PM, Andrew Turner wrote: > On Sat, 2 Mar 2013 16:20:54 -0700 > Warner Losh wrote: >=20 >>=20 >> On Mar 2, 2013, at 2:05 PM, Tim Kientzle wrote: >>=20 >>> Now that I think I understand some of the issues in building >>> a GENERIC arm kernel, I'm starting to piece together >>> a kernel that has both RPi and BBone bits that I can >>> use as a testbed. >>>=20 >>> Next Problem: A lot of the boards are using >>> board-specific files.* to control what files get >>> linked into the kernel. >>>=20 >>> This seems like a real problem for a GENERIC kernel, >>> so I propose merging them into sys/conf/files.arm. >>>=20 >>> Here's how I'm doing it right now for my current >>> experiments. If anyone has a better idea, I'm >>> definitely interested. >>>=20 >>> Basically, I'm using "device bcm2835" to represent >>> all of the basic support for that particular SoC. >>> (An SoC is, after all, just another piece of hardware.) >>>=20 >>> Then the files marked "standard" in >>> arm/bcm2835/files.bcm2835 move to >>> files.arm as "optional bcm2835". >>>=20 >>> With this approach, the GENERIC arm kernel will >>> list the SoCs as devices: >>>=20 >>> device bcm2835 >>> device am335x >>> device omap4 >>> =85 etc =85 >>>=20 >>> That will bring in the basic support for those SoCs >>> (e.g., interrupt handler, gpio, clock management, etc). >>> Additional drivers (SDHCI, UART, USB, etc) will >>> be separate devices. >>>=20 >>> I think this makes sense, but I'm open to other ideas. >>=20 >> I think this is perfect. It is what atmel uses to bring in different >> atmel things. I don't think there are any atmel files specified as >> std any more, and if there are they could transition to this. I know >> this isn't an issue for a GENERIC for armv6, since there is not way >> an armv4 and an armv6 kernel could be built today... >=20 > I don't think that is a problem. We can have two GENERIC kernels, i.e. > an arm and an armv6 kernel. Having two GENERIC like kernels doesn't > preclude having a single GENERIC in the future, quite the opposite. We > are unlikely to have a GENERIC kernel for any hardware that doesn't > have fdt, or some other way to detect which SoC & board we are running > on. Yes. I'd love to see Atmel move to FDT, but my time for hacking that = lately has meant almost no progress. For other, older armv4/5 parts, = those could be part of LINT, but not GENERIC, or we can drop support for = them... Warner Warner= From owner-freebsd-arm@FreeBSD.ORG Sun Mar 3 06:22:14 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D808DC97; Sun, 3 Mar 2013 06:22:14 +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 A61DA783; Sun, 3 Mar 2013 06:22:14 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r236MDrG063117; Sun, 3 Mar 2013 06:22:13 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 4q7vnckhpcir8hhut48jeedu8a; Sun, 03 Mar 2013 06:22:13 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: PHYSADDR Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <1362273533.1195.199.camel@revolution.hippie.lan> Date: Sat, 2 Mar 2013 22:22:10 -0800 Content-Transfer-Encoding: 7bit Message-Id: <1F9BEBCF-AB1C-4918-917A-921B5CC606FC@kientzle.com> References: <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> <8FEA3237-8ABF-4564-B672-4B4C0C6EF291@kientzle.com> <1362155632.1195.120.camel@revolution.hippie.lan> <5B622D1B-4EAE-4184-A194-DD14083A48B6@kientzle.com> <1362246634.1195.178.camel@revolution.hippie.lan> <1362273533.1195.199.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 06:22:14 -0000 On Mar 2, 2013, at 5:18 PM, Ian Lepore wrote: > On Sat, 2013-03-02 at 10:10 -0800, Tim Kientzle wrote: >> On Mar 2, 2013, at 9:50 AM, Ian Lepore wrote: >> >>> [...] >> >>> I'm not sure its safe to assume that (entry-pc & 0xfffff000) is the >>> beginning of the kernel; it's true now but need not be so. But that's >>> no big deal, we can tweak the linker script to give us the offset of the >>> _start symbol so it'll work no matter what. >> >> Patches? ;-) > > This turned out to be a bit trickier than I first thought it would be, > but it worked out. > > This gets rids of any reference to PHYSADDR and similar constants in the > main path through the code. I didn't address the "running from flash" > case or anything under #ifdef SMP, yet. The only constant left is > KERNBASE which is 0xC0000000 for all arm systems. > > For now I've got #undef PHYSADDR at the top of the code; this is just > for testing without having to remove it yet from anywhere else. I see you computing kern_physaddr here. I presume we should be using that in machdep.c to initialize the page tables instead of KERNPHYSADDR? Tim From owner-freebsd-arm@FreeBSD.ORG Sun Mar 3 13:10:01 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B6B79B57 for ; Sun, 3 Mar 2013 13:10:01 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id 8AFC76E0 for ; Sun, 3 Mar 2013 13:10:01 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UC8fv-000Klh-JH; Sun, 03 Mar 2013 13:09:59 +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 r23D9ufE089805; Sun, 3 Mar 2013 06:09:56 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18dsddSRvgF2d3cRAKhTUt3 Subject: Re: PHYSADDR From: Ian Lepore To: Tim Kientzle In-Reply-To: <1F9BEBCF-AB1C-4918-917A-921B5CC606FC@kientzle.com> References: <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> <8FEA3237-8ABF-4564-B672-4B4C0C6EF291@kientzle.com> <1362155632.1195.120.camel@revolution.hippie.lan> <5B622D1B-4EAE-4184-A194-DD14083A48B6@kientzle.com> <1362246634.1195.178.camel@revolution.hippie.lan> <1362273533.1195.199.camel@revolution.hippie.lan> <1F9BEBCF-AB1C-4918-917A-921B5CC606FC@kientzle.com> Content-Type: text/plain; charset="us-ascii" Date: Sun, 03 Mar 2013 06:09:55 -0700 Message-ID: <1362316195.1195.206.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 13:10:01 -0000 On Sat, 2013-03-02 at 22:22 -0800, Tim Kientzle wrote: > On Mar 2, 2013, at 5:18 PM, Ian Lepore wrote: > > > On Sat, 2013-03-02 at 10:10 -0800, Tim Kientzle wrote: > >> On Mar 2, 2013, at 9:50 AM, Ian Lepore wrote: > >> > >>> [...] > >> > >>> I'm not sure its safe to assume that (entry-pc & 0xfffff000) is the > >>> beginning of the kernel; it's true now but need not be so. But that's > >>> no big deal, we can tweak the linker script to give us the offset of the > >>> _start symbol so it'll work no matter what. > >> > >> Patches? ;-) > > > > This turned out to be a bit trickier than I first thought it would be, > > but it worked out. > > > > This gets rids of any reference to PHYSADDR and similar constants in the > > main path through the code. I didn't address the "running from flash" > > case or anything under #ifdef SMP, yet. The only constant left is > > KERNBASE which is 0xC0000000 for all arm systems. > > > > For now I've got #undef PHYSADDR at the top of the code; this is just > > for testing without having to remove it yet from anywhere else. > > I see you computing kern_physaddr here. I presume > we should be using that in machdep.c to initialize the > page tables instead of KERNPHYSADDR? > > Tim Yeah, I suspect so. I didn't look outside of locore to see what other changes could flow from computing physaddr. On a semi-related note, it occurs to me that we should choose a standard kernel load offset that's a multiple of 1MB, so that the code that builds the real page tables will be able to use section mappings for all but the last section of the loaded kernel. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Mar 3 13:35:26 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 81FD8EFC; Sun, 3 Mar 2013 13:35: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 42F78780; Sun, 3 Mar 2013 13:35:25 +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 r23DZJ4l051690; Sun, 3 Mar 2013 08:35: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 r23DZIuA051689; Sun, 3 Mar 2013 13:35:18 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Mar 2013 13:35:18 GMT Message-Id: <201303031335.r23DZIuA051689@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 13:35:26 -0000 TB --- 2013-03-03 12:00:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-03 12:00:18 - 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 --- 2013-03-03 12:00:18 - starting HEAD tinderbox run for arm/arm TB --- 2013-03-03 12:00:18 - cleaning the object tree TB --- 2013-03-03 12:00:18 - /usr/local/bin/svn stat /src TB --- 2013-03-03 12:00:22 - At svn revision 247709 TB --- 2013-03-03 12:00:23 - building world TB --- 2013-03-03 12:00:23 - CROSS_BUILD_TESTING=YES TB --- 2013-03-03 12:00:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-03 12:00:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-03 12:00:23 - SRCCONF=/dev/null TB --- 2013-03-03 12:00:23 - TARGET=arm TB --- 2013-03-03 12:00:23 - TARGET_ARCH=arm TB --- 2013-03-03 12:00:23 - TZ=UTC TB --- 2013-03-03 12:00:23 - __MAKE_CONF=/dev/null TB --- 2013-03-03 12:00:23 - cd /src TB --- 2013-03-03 12:00:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Mar 3 12:00:27 UTC 2013 >>> 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 [...] cc -O -pipe -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -c kdigest-commands.c cc -O -pipe -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kdigest/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kdigest/../../include -std=gnu99 -o kdigest kdigest.o kdigest-commands.o -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/arm.arm/src/kerberos5/libexec/kdigest/../../lib/libsl/libsl.a /obj/arm.arm/src/kerberos5/libexec/kdigest/../../lib/libvers/libvers.a -ledit /obj/arm.arm/src/tmp/usr/lib/libedit.so: undefined reference to `tgetflag' /obj/arm.arm/src/tmp/usr/lib/libedit.so: undefined reference to `tgetent' /obj/arm.arm/src/tmp/usr/lib/libedit.so: undefined reference to `tputs' /obj/arm.arm/src/tmp/usr/lib/libedit.so: undefined reference to `tgoto' /obj/arm.arm/src/tmp/usr/lib/libedit.so: undefined reference to `tgetnum' /obj/arm.arm/src/tmp/usr/lib/libedit.so: undefined reference to `tgetstr' *** [kdigest] Error code 1 Stop in /src/kerberos5/libexec/kdigest. *** [all] Error code 1 Stop in /src/kerberos5/libexec. *** [all] Error code 1 Stop in /src/kerberos5. *** [kerberos5.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-03 13:35:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-03 13:35:18 - ERROR: failed to build world TB --- 2013-03-03 13:35:18 - 4647.85 user 820.34 system 5700.31 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Mar 3 16:11:18 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1F322B6C for ; Sun, 3 Mar 2013 16:11:18 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from smtprelay-h22.telenor.se (smtprelay-h22.telenor.se [195.54.99.197]) by mx1.freebsd.org (Postfix) with ESMTP id 9EF53E27 for ; Sun, 3 Mar 2013 16:11:17 +0000 (UTC) Received: from ipb3.telenor.se (ipb3.telenor.se [195.54.127.166]) by smtprelay-h22.telenor.se (Postfix) with ESMTP id D55A0E9C81 for ; Sun, 3 Mar 2013 16:40:12 +0100 (CET) X-SENDER-IP: [85.229.94.62] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtpBAJJuM1FV5V4+PGdsb2JhbABEiwe0Y4JgexcDAQEBATg0gh8BAQQBMgEjMwtGLQwKFIgmCscLjyQWgyoDjhqXTIRV X-IronPort-AV: E=Sophos;i="4.84,775,1355094000"; d="scan'208";a="289500163" Received: from c-3e5ee555.06-11-73746f31.cust.bredbandsbolaget.se (HELO sigyn.alvermark.net) ([85.229.94.62]) by ipb3.telenor.se with ESMTP; 03 Mar 2013 16:40:12 +0100 Received: from localhost ([127.0.0.1] helo=alvermark.net) by sigyn.alvermark.net with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UCB1H-0004WR-St for freebsd-arm@freebsd.org; Sun, 03 Mar 2013 16:40:12 +0100 Received: from 85.229.95.148 (SquirrelMail authenticated user alvis) by alvermark.net with HTTP; Sun, 3 Mar 2013 16:40:11 +0100 (CET) Message-ID: <54059.85.229.95.148.1362325211.squirrel@alvermark.net> In-Reply-To: References: <20130302172556.5b59e122@bender> Date: Sun, 3 Mar 2013 16:40:11 +0100 (CET) Subject: Re: ARM EABI test image From: "Jakob Alvermark" To: freebsd-arm@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 16:11:18 -0000 On Sat, March 2, 2013 18:17, Ganbold Tsagaankhuu wrote: >> Can people try this as I would like to know if anything else is broken >> as this will become the default ABI for 10. >> > > Just tried the image. Seems work but observed for instance gpart shows > big numbers for 2GB SD: > > root@raspberry-pi:/home/pi # uname -an > FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r247609: Sat > Mar 2 16:43:25 NZDT 2013 > andrew@bender:/usr/obj/arm.armv6/usr/home/andrew/freebsd/anon/head/sys/RPI > -B > arm root@raspberry-pi:/home/pi # gpart show > => 4294967296 16800529082482689 mmcsd0 MBR (20G) > 4294967296 266287972352 - free - (124T) > 270582939648 281401962266625 1 !12 [active] (0B) > 281672545206273 4294967295 - free - (2T) > 281676840173568 8725483759861761 2 freebsd (8.0G) > 9007160600035329 4294967295 - free - (2T) > 9007164895002624 7793325532774401 3 freebsd (4.0G) > 16800490427777025 42949672960 - free - (20T) > > > => 0 8725483759861761 mmcsd0s2 BSD (8.0G) > 0 8725483759861761 1 freebsd-ufs (4.0G) Hi, I just tried compiling with 'WITH_ARM_EABI=yes' in src.conf (it should do the same, doesn't it) I get similar results as Ganbold (I use an 8 GB SD card, but the actual image is kept to 256 MB): root@raspberry-pi:~ # gpart show => 4294967296 67685927215955969 mmcsd0 MBR (12G) 4294967296 34359738368 - free - (16T) 38654705664 281440616972289 1 !12 [active] (0B) 281479271677953 4294967295 - free - (2T) 281483566645248 1970303362138113 2 freebsd (8.0G) 2251786928783361 65434144582139904 - free - (-3E) => 0 1970303362138113 mmcsd0s2 BSD (8.0G) 0 1970303362138113 1 freebsd-ufs (4.0G) root@raspberry-pi:~ # df -h Filesystem Size Used Avail Capacity Mounted on /dev/mmcsd0s2a 216M 164M 35M 82% / devfs 1.0k 1.0k 0B 100% /dev root@raspberry-pi:~ # uname -a FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #29 r247713: Sun Mar 3 15:52:45 CET 2013 root@test10:/src/FreeBSD/obj/arm.armv6/src/FreeBSD/head/sys/RPI-B arm Jakob From owner-freebsd-arm@FreeBSD.ORG Sun Mar 3 17:24:31 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9FE47BBC; Sun, 3 Mar 2013 17:24:31 +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 587DDFEA; Sun, 3 Mar 2013 17:24:30 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r23HOUvG066012; Sun, 3 Mar 2013 17:24:30 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id vsv47b2wvyxydr5kk2du64pim6; Sun, 03 Mar 2013 17:24:30 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: PHYSADDR Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <1362316195.1195.206.camel@revolution.hippie.lan> Date: Sun, 3 Mar 2013 09:24:27 -0800 Content-Transfer-Encoding: 7bit Message-Id: <51CC15E5-891D-4BF2-906A-4CE15F790E93@kientzle.com> References: <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> <8FEA3237-8ABF-4564-B672-4B4C0C6EF291@kientzle.com> <1362155632.1195.120.camel@revolution.hippie.lan> <5B622D1B-4EAE-4184-A194-DD14083A48B6@kientzle.com> <1362246634.1195.178.camel@revolution.hippie.lan> <1362273533.1195.199.camel@revolution.hippie.lan> <1F9BEBCF-AB1C-4918-917A-921B5CC606FC@kientzle.com> <1362316195.1195.206.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 17:24:31 -0000 On Mar 3, 2013, at 5:09 AM, Ian Lepore wrote: > > On a semi-related note, it occurs to me that we should choose a standard > kernel load offset that's a multiple of 1MB, so that the code that > builds the real page tables will be able to use section mappings for all > but the last section of the loaded kernel. I'm using 1MB as the standard offset for my experiments right now. I could be talked into using 2MB. Tim From owner-freebsd-arm@FreeBSD.ORG Sun Mar 3 19:43:31 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9D3A6916 for ; Sun, 3 Mar 2013 19:43:31 +0000 (UTC) (envelope-from kientzle@freebsd.org) 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 64C2D657 for ; Sun, 3 Mar 2013 19:43:30 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r23JhON3066497 for freebsd-arm@freebsd.org; Sun, 3 Mar 2013 19:43:24 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id cyx5aui9ib5guycd2brwgnzdbs; for freebsd-arm@freebsd.org; Sun, 03 Mar 2013 19:43:24 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: multipart/signed; boundary="Apple-Mail=_F90B5CAF-B0AA-4609-AF80-4A91CA3659E3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: GENERIC kernel issues Date: Sun, 3 Mar 2013 11:43:21 -0800 Message-Id: To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 19:43:31 -0000 --Apple-Mail=_F90B5CAF-B0AA-4609-AF80-4A91CA3659E3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii I spent some time yesterday putting together a kernel configuration for a GENERIC ARM kernel that would support both RaspberryPi and BeagleBone. Just to see how far I could get. Here's a list of the problems I've found so far: ** Multiple MMU support. If you put these two lines into an ARM kernel config, the build will fail in the MMU code: cpu CPU_ARM1176 cpu CPU_CORTEXA Basically, this turns on the support for multiple MMUs but the ARMv6/ARMv7 MMU definitions don't play nicely with run-time MMU selection. ** PHYSADDR/KERNPHYSADDR hardwiring. Ian has made a lot of progress and I'm working on some related changes to address this. I think we understand how to eliminate these constants and replace them with run-time detection of the load address. I'm still not sure what changes might be needed to the loader to make this work. ** PIPT vs. VIVT cache management. This is currently set at compile time; we'll need to have a way to set this at run time based on the CPU. (I have some skeletal code to select CPU at the top of initarm by inspecting the FDT. I presume this switch will be routine once a robust version of that is in place.) ** TI processor detection. This is currently hardwired at build time, so we cannot currently build a kernel that supports both AM335x and OMAP4, for example. Question: should we create a /projects/arm-generic/ branch to hold this work while it's in flux? Tim --Apple-Mail=_F90B5CAF-B0AA-4609-AF80-4A91CA3659E3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQEcBAEBAgAGBQJRM6faAAoJEGMNyGo0rfFBdfAH/R7xOKp9xQ2zz8FSKT7M6lan VOf6ArQqMpfNkaUyr4lmAN5NNAkXWLmc4H78RrL6aWQHTEqH+xAFaQTnthZzCTOF bRC3olzQGCbhP7IBn51Z9waYa8Q/PRKdBbApEPaL2mOzX0XHvipIXn3GAZgxVCv7 YZnuiPfCAkWOiZMWBpLdKK2Jo9DZBPKSfKzxHqYLUbG0H2FyJmgUsHi35MQJiDKq VWe8KQ9jEneu+HO5V3xEsS1Yd1m873w7e0TjhIteWH1MqnDQd1MGcF1oO+u+naAa WjvBcEcuuTQaAi07Ii8H4iJn3pATg+Q6q5RX8MOSsj7Ih3mjBwRnE37GV26X8Us= =zsr9 -----END PGP SIGNATURE----- --Apple-Mail=_F90B5CAF-B0AA-4609-AF80-4A91CA3659E3-- From owner-freebsd-arm@FreeBSD.ORG Sun Mar 3 19:59:44 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 826EACE9 for ; Sun, 3 Mar 2013 19:59:44 +0000 (UTC) (envelope-from kientzle@freebsd.org) 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 62DFE6E3 for ; Sun, 3 Mar 2013 19:59:43 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r23JxhNZ066563 for freebsd-arm@freebsd.org; Sun, 3 Mar 2013 19:59:43 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id qestbrwbh2f9dz5dnx33ij2san; for freebsd-arm@freebsd.org; Sun, 03 Mar 2013 19:59:43 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: multipart/signed; boundary="Apple-Mail=_1EDADA6A-44AF-4CB2-83B0-085AAFA7776B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Discount on RaspberryPi Date: Sun, 3 Mar 2013 11:59:40 -0800 Message-Id: To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 19:59:44 -0000 --Apple-Mail=_1EDADA6A-44AF-4CB2-83B0-085AAFA7776B Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii If you don't already have enough RaspberryPi's sitting around your desk, Newark Element 14 is offering Free Shipping this month. I don't know if this is limited to RaspberryPi stuff or not. "Celebrate Raspberry Pi's first birthday all month long with Free Shipping exclusive to you! Use voucher code 314BDAY on shopping cart page. *Web only. $100 Minimum purchase. Offer expires 3/31/2013." --Apple-Mail=_1EDADA6A-44AF-4CB2-83B0-085AAFA7776B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQEcBAEBAgAGBQJRM6utAAoJEGMNyGo0rfFBK5cH/19xlWInevSa0HNYaB2IY2fo 4CAZUjWkZnl3PA30+SXEXUgr+gBBpXuoOxrWWobErSNdzgXr0tpweADlT6S8OvVN a1jQlalNajSDbEei7tvLCecKutXMBu0Aha/dzVtjZ2UVPod68qLSfyC5ogIsEAD5 F06qpjqLIxJFiZx5RTInUkQ/hNV3Eau1DSjvtDsmz3S4sx8uLujNIAdeRJ8HI86t Hp2oLbw+Ublb9Ke4VdLf9FuNohA5IkY8yGVUnVDIBYKm8UXtIsVyBwMdIqk2XMLo n38ucLhxWPRSKfDf0a9+hDcLM1rX1OXxMMeV0yrlvH69edVdvH/pralQSVQbTB4= =lhoT -----END PGP SIGNATURE----- --Apple-Mail=_1EDADA6A-44AF-4CB2-83B0-085AAFA7776B-- From owner-freebsd-arm@FreeBSD.ORG Sun Mar 3 23:19:35 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 24050C9E for ; Sun, 3 Mar 2013 23:19:35 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 8BCEDE5C for ; Sun, 3 Mar 2013 23:19:34 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 55300358C5B for ; Mon, 4 Mar 2013 00:19:32 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 30B062848C; Mon, 4 Mar 2013 00:19:32 +0100 (CET) Date: Mon, 4 Mar 2013 00:19:32 +0100 From: Jilles Tjoelker To: freebsd-arm@freebsd.org Subject: cross-compilation of sh(1) from x86 to arm Message-ID: <20130303231931.GD21318@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 23:19:35 -0000 There has long been a bug in sh(1) where it assumes (in mksyntax.c) that the properties of char are the same between build and run environments. This assumption does not hold if a cross build is done for arm on an x86 machine. The main effect is that such a miscompiled sh incorrectly handles characters with bit 7 set. Various tests in tools/regression/bin/sh start failing, possibly in ways that eat huge amounts of CPU time and memory. Christoph Mallon has submitted a fix for this and I have committed it to head and stable/9. It has, however, only been tested on x86 using the -funsigned-char compiler option to create the discrepancy. Below is a backport of the fix to stable/8. It needs r247733 or at least the bin/sh/mksyntax.c of that revision. Because I had to fix some conflicts and stable/8's sh differs quite a bit from head's, I would like to have some testing first before committing this. I again tested only on amd64 with and without the -funsigned-char compiler option and tools/regression/bin/sh. If the cross-compilation need not be supported on stable/8, I am fine with leaving it unfixed in stable/8. Index: bin/sh =================================================================== --- bin/sh (revision 247733) +++ bin/sh (working copy) Property changes on: bin/sh ___________________________________________________________________ Modified: svn:mergeinfo Merged /head/bin/sh:r246522 Index: bin/sh/mksyntax.c =================================================================== --- bin/sh/mksyntax.c (revision 247733) +++ bin/sh/mksyntax.c (working copy) @@ -101,23 +101,16 @@ static FILE *cfile; static FILE *hfile; -static const char *syntax[513]; -static int base; -static int size; /* number of values which a char variable can have */ -static int nbits; /* number of bits in a character */ -static void filltable(const char *); -static void init(void); +static void add_default(void); +static void finish(void); +static void init(const char *); static void add(const char *, const char *); -static void print(const char *); static void output_type_macros(void); int main(int argc __unused, char **argv __unused) { - char c; - char d; - int sign; int i; char buf[80]; int pos; @@ -134,28 +127,9 @@ fputs(writer, hfile); fputs(writer, cfile); - /* Determine the characteristics of chars. */ - c = -1; - sign = (c > 0) ? 0 : 1; - for (nbits = 1 ; ; nbits++) { - d = (1 << nbits) - 1; - if (d == c) - break; - } -#if 0 - printf("%s %d bit chars\n", sign? "signed" : "unsigned", nbits); -#endif - if (nbits > 9) { - fputs("Characters can't have more than 9 bits\n", stderr); - exit(2); - } - size = (1 << nbits) + 1; - base = 1; - if (sign) - base += 1 << (nbits - 1); - fputs("#include \n", hfile); fputs("#include \n", hfile); + fputs("#include \n\n", hfile); /* Generate the #define statements in the header file */ fputs("/* Syntax classes */\n", hfile); @@ -176,8 +150,8 @@ fprintf(hfile, "/* %s */\n", is_entry[i].comment); } putc('\n', hfile); - fprintf(hfile, "#define SYNBASE %d\n", base); - fprintf(hfile, "#define PEOF %d\n\n", -base); + fputs("#define SYNBASE (1 - CHAR_MIN)\n", hfile); + fputs("#define PEOF -SYNBASE\n\n", hfile); putc('\n', hfile); fputs("#define BASESYNTAX (basesyntax + SYNBASE)\n", hfile); fputs("#define DQSYNTAX (dqsyntax + SYNBASE)\n", hfile); @@ -188,10 +162,13 @@ putc('\n', hfile); /* Generate the syntax tables. */ + fputs("#include \"parser.h\"\n", cfile); fputs("#include \"shell.h\"\n", cfile); fputs("#include \"syntax.h\"\n\n", cfile); - init(); + fputs("/* syntax table used when not in quotes */\n", cfile); + init("basesyntax"); + add_default(); add("\n", "CNL"); add("\\", "CBACK"); add("'", "CSQUOTE"); @@ -200,9 +177,11 @@ add("$", "CVAR"); add("}", "CENDVAR"); add("<>();&| \t", "CSPCL"); - print("basesyntax"); - init(); + finish(); + fputs("\n/* syntax table used when in double quotes */\n", cfile); + init("dqsyntax"); + add_default(); add("\n", "CNL"); add("\\", "CBACK"); add("\"", "CENDQUOTE"); @@ -211,16 +190,20 @@ add("}", "CENDVAR"); /* ':/' for tilde expansion, '-' for [a\-x] pattern ranges */ add("!*?[=~:/-", "CCTL"); - print("dqsyntax"); - init(); + finish(); + fputs("\n/* syntax table used when in single quotes */\n", cfile); + init("sqsyntax"); + add_default(); add("\n", "CNL"); add("'", "CENDQUOTE"); /* ':/' for tilde expansion, '-' for [a\-x] pattern ranges */ add("!*?[=~:/-", "CCTL"); - print("sqsyntax"); - init(); + finish(); + fputs("\n/* syntax table used when in arithmetic */\n", cfile); + init("arisyntax"); + add_default(); add("\n", "CNL"); add("\\", "CBACK"); add("`", "CBQUOTE"); @@ -230,99 +213,94 @@ add("}", "CENDVAR"); add("(", "CLP"); add(")", "CRP"); - print("arisyntax"); - filltable("0"); + finish(); + fputs("\n/* character classification table */\n", cfile); + init("is_type"); add("0123456789", "ISDIGIT"); add("abcdefghijklmnopqrstucvwxyz", "ISLOWER"); add("ABCDEFGHIJKLMNOPQRSTUCVWXYZ", "ISUPPER"); add("_", "ISUNDER"); add("#?$!-*@", "ISSPECL"); - print("is_type"); + finish(); + exit(0); } - /* - * Clear the syntax table. + * Output the header and declaration of a syntax table. */ static void -filltable(const char *dftval) +init(const char *name) { - int i; + fprintf(hfile, "extern const char %s[];\n", name); + fprintf(cfile, "const char %s[SYNBASE + CHAR_MAX + 1] = {\n", name); +} - for (i = 0 ; i < size ; i++) - syntax[i] = dftval; + +static void +add_one(const char *key, const char *type) +{ + fprintf(cfile, "\t[SYNBASE + %s] = %s,\n", key, type); } /* - * Initialize the syntax table with default values. + * Add default values to the syntax table. */ static void -init(void) +add_default(void) { - filltable("CWORD"); - syntax[0] = "CEOF"; - syntax[base + CTLESC] = "CCTL"; - syntax[base + CTLVAR] = "CCTL"; - syntax[base + CTLENDVAR] = "CCTL"; - syntax[base + CTLBACKQ] = "CCTL"; - syntax[base + CTLBACKQ + CTLQUOTE] = "CCTL"; - syntax[base + CTLARI] = "CCTL"; - syntax[base + CTLENDARI] = "CCTL"; - syntax[base + CTLQUOTEMARK] = "CCTL"; + add_one("PEOF", "CEOF"); + add_one("CTLESC", "CCTL"); + add_one("CTLVAR", "CCTL"); + add_one("CTLENDVAR", "CCTL"); + add_one("CTLBACKQ", "CCTL"); + add_one("CTLBACKQ + CTLQUOTE", "CCTL"); + add_one("CTLARI", "CCTL"); + add_one("CTLENDARI", "CCTL"); + add_one("CTLQUOTEMARK", "CCTL"); } /* - * Add entries to the syntax table. + * Output the footer of a syntax table. */ static void -add(const char *p, const char *type) +finish(void) { - while (*p) - syntax[*p++ + base] = type; + fputs("};\n", cfile); } - /* - * Output the syntax table. + * Add entries to the syntax table. */ static void -print(const char *name) +add(const char *p, const char *type) { - int i; - int col; + for (; *p; ++p) { + char c = *p; + switch (c) { + case '\t': c = 't'; break; + case '\n': c = 'n'; break; + case '\'': c = '\''; break; + case '\\': c = '\\'; break; - fprintf(hfile, "extern const char %s[];\n", name); - fprintf(cfile, "const char %s[%d] = {\n", name, size); - col = 0; - for (i = 0 ; i < size ; i++) { - if (i == 0) { - fputs(" ", cfile); - } else if ((i & 03) == 0) { - fputs(",\n ", cfile); - col = 0; - } else { - putc(',', cfile); - while (++col < 9 * (i & 03)) - putc(' ', cfile); + default: + fprintf(cfile, "\t[SYNBASE + '%c'] = %s,\n", c, type); + continue; } - fputs(syntax[i], cfile); - col += strlen(syntax[i]); + fprintf(cfile, "\t[SYNBASE + '\\%c'] = %s,\n", c, type); } - fputs("\n};\n", cfile); } - /* * Output character classification macros (e.g. is_digit). If digits are * contiguous, we can test for them quickly. -- Jilles Tjoelker From owner-freebsd-arm@FreeBSD.ORG Mon Mar 4 01:02:21 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2049249D for ; Mon, 4 Mar 2013 01:02:21 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id BFCA917A for ; Mon, 4 Mar 2013 01:02:20 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id c12so5431855ieb.6 for ; Sun, 03 Mar 2013 17:02:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-rim-org-msg-ref-id:message-id :content-transfer-encoding:reply-to:x-priority:references :in-reply-to:sensitivity:importance:subject:to:from:date :content-type:mime-version:x-gm-message-state; bh=3HYcU2yr3d3rSVPtP+ANG7piYNav3o/jG8z9g1zCZts=; b=GqxjuIbqtGx1fHqirufpFi9mCijvIvAyfoXFNvdlcGCMdm0Xx5XTajcOh2voMRpa9h VSbuFA585poM1gFmJIexWL81E/Ru4Ejby4CnPEJ11RVqBU5kkJbSpBK9px3SBQxa5p0u RazrfT1cw651fEXTB7CjhAbssNrnRST7ircNvtyAb5dJv01VDKvBIvf74G8HVv3D0JcB 5rK4pW5MgO0LGlC7ORIjsc57h9vLXMMTBXIqkOryJopV1uX1kCvqcu8kRqL7hHdQ58yO oFCUtVqZBcrIWjqulHGYuLeCNilLokOfcqeDnu6UYoa0YfmeWaM0jV3zMZi6sNI6NhDn q3YA== X-Received: by 10.42.179.73 with SMTP id bp9mr22309932icb.51.1362358940374; Sun, 03 Mar 2013 17:02:20 -0800 (PST) Received: from 172.22.81.187 (bda-216-9-250-74.bis3.ap.blackberry.com. [216.9.250.74]) by mx.google.com with ESMTPS id xd4sm8760544igb.3.2013.03.03.17.02.19 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 03 Mar 2013 17:02:19 -0800 (PST) X-rim-org-msg-ref-id: 803775396 Message-ID: <803775396-1362358938-cardhu_decombobulator_blackberry.rim.net-1860878237-@b17.c6.bise3.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: In-Reply-To: Sensitivity: Normal Importance: Normal Subject: Re: Discount on RaspberryPi To: "Tim Kientzle" , owner-freebsd-arm@freebsd.org, freebsd-arm@freebsd.org From: "Alie Tan" Date: Mon, 4 Mar 2013 01:02:17 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Gm-Message-State: ALoCoQmiqT4s25XOKDns/mtjCtM2OT8jCHpczxt6KnqUJ58VYeDh48gkAEX0CHlNC08HfXenejkh X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: alie@affle.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 01:02:21 -0000 VGhhbmtzLA0KDQpXZSBnb3QgZnJlZSBzaGlwcGluZyBpbiBTaW5nYXBvcmUgaWYgb3VyIG1pbmlt dW0gb3JkZXIgaXMgUyQ3NSBzaW5jZSBiZWdpbm5pbmcuDQoNClNlbnQgdmlhIEJsYWNrQmVycnkg ZnJvbSBTaW5nVGVsIQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVGltIEtp ZW50emxlIDxraWVudHpsZUBmcmVlYnNkLm9yZz4NClNlbmRlcjogb3duZXItZnJlZWJzZC1hcm1A ZnJlZWJzZC5vcmdEYXRlOiBTdW4sIDMgTWFyIDIwMTMgMTE6NTk6NDAgDQpUbzogPGZyZWVic2Qt YXJtQGZyZWVic2Qub3JnPg0KU3ViamVjdDogRGlzY291bnQgb24gUmFzcGJlcnJ5UGkNCg0KSWYg eW91IGRvbid0IGFscmVhZHkgaGF2ZSBlbm91Z2ggUmFzcGJlcnJ5UGkncyBzaXR0aW5nDQphcm91 bmQgeW91ciBkZXNrLCBOZXdhcmsgRWxlbWVudCAxNCBpcyBvZmZlcmluZyBGcmVlDQpTaGlwcGlu ZyB0aGlzIG1vbnRoLg0KDQpJIGRvbid0IGtub3cgaWYgdGhpcyBpcyBsaW1pdGVkIHRvIFJhc3Bi ZXJyeVBpIHN0dWZmIG9yIG5vdC4NCg0KIkNlbGVicmF0ZSBSYXNwYmVycnkgUGkncyBmaXJzdCBi aXJ0aGRheSBhbGwgbW9udGggbG9uZyB3aXRoDQpGcmVlIFNoaXBwaW5nIGV4Y2x1c2l2ZSB0byB5 b3UhIFVzZSB2b3VjaGVyIGNvZGUgMzE0QkRBWQ0Kb24gc2hvcHBpbmcgY2FydCBwYWdlLg0KKldl YiBvbmx5LiAkMTAwIE1pbmltdW0gcHVyY2hhc2UuIE9mZmVyIGV4cGlyZXMgMy8zMS8yMDEzLiIN Cg0KDQo= From owner-freebsd-arm@FreeBSD.ORG Mon Mar 4 02:39:44 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9CCEAF90 for ; Mon, 4 Mar 2013 02:39:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x231.google.com (mail-ia0-x231.google.com [IPv6:2607:f8b0:4001:c02::231]) by mx1.freebsd.org (Postfix) with ESMTP id 701EB6D9 for ; Mon, 4 Mar 2013 02:39:44 +0000 (UTC) Received: by mail-ia0-f177.google.com with SMTP id o25so4384125iad.36 for ; Sun, 03 Mar 2013 18:39:44 -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=rzxzXTv+aYX8lqF3zckR3ohY3ve8DXxlgEfglgDZ2as=; b=QJSbxLRD7rFk4B+XzZcoBcY5tV8QMbAcUlOwT4YmXAkw3GLS2+1bt4E5/uzmki4JEg RKPSuy4Qdow3mxTfFAPilTJ6snCRlHdrN+B8Y/ubUB0sjJ01d8KDeh5ENhamuvVf1ZSv ufbVSe2A63IemYK/yjpoQWwwHcK3UaSLsaRY2jFetgbhJMys+nHSQW7ookgn4E28Qe8a dn/zuWfjfP8W6E/wmTarmtbryYIrWnT/V7vO+GJnHPHmovCKTjhB4dFQJX3+39Y+6WZD gnp+obEWCr88uLD08efw518qCcXeDXETaWws1D1/gLie3bstMYDBTwi4U0+TfrGVaGmB s7Fw== X-Received: by 10.50.173.73 with SMTP id bi9mr1260705igc.64.1362364783678; Sun, 03 Mar 2013 18:39:43 -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 a3sm9083316igq.5.2013.03.03.18.39.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Mar 2013 18:39:42 -0800 (PST) Sender: Warner Losh Subject: Re: GENERIC kernel issues Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 3 Mar 2013 19:39:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <549B1B40-99E7-47D4-BA13-1F08507B7B58@bsdimp.com> References: To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQn+5mwQRZwcVKst3fxkdV1NquUE9blYdtkmXJFvl/bB3pl/pBpymMCS8vHCVVooUr96oHpe Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 02:39:44 -0000 On Mar 3, 2013, at 12:43 PM, Tim Kientzle wrote: > I spent some time yesterday putting together a kernel > configuration for a GENERIC ARM kernel that would > support both RaspberryPi and BeagleBone. >=20 > Just to see how far I could get. >=20 > Here's a list of the problems I've found so far: >=20 > ** Multiple MMU support. If you put these two lines into an > ARM kernel config, the build will fail in the MMU code: >=20 > cpu CPU_ARM1176 > cpu CPU_CORTEXA >=20 > Basically, this turns on the support for multiple MMUs but the > ARMv6/ARMv7 MMU definitions don't play nicely with run-time > MMU selection. Having looked at the defines, it could be done with variables, but I = fear that will slow things down to do a simple #define -> variable. We = may need two sets of code for performance... > ** PHYSADDR/KERNPHYSADDR hardwiring. Ian has made a > lot of progress and I'm working on some related changes to > address this. I think we understand how to eliminate these > constants and replace them with run-time detection of the > load address. I'm still not sure what changes might be needed > to the loader to make this work. >=20 > ** PIPT vs. VIVT cache management. This is currently set at compile > time; we'll need to have a way to set this at run time based on the > CPU. (I have some skeletal code to select CPU at the top of > initarm by inspecting the FDT. I presume this switch will be routine > once a robust version of that is in place.) Generally we should be doing this, both for the Core and the SoC. I = don't think we do this generally, and we should. It is one of the big = advantages of FDT: It tells you what's going on so you don't have to = guess.... > ** TI processor detection. This is currently hardwired at build = time, > so we cannot currently build a kernel that supports both AM335x > and OMAP4, for example. Can't we do this with compat field in the FDT? > Question: should we create a /projects/arm-generic/ branch > to hold this work while it's in flux? Works for me. Warner From owner-freebsd-arm@FreeBSD.ORG Mon Mar 4 05:15:33 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 696EA73D for ; Mon, 4 Mar 2013 05:15:33 +0000 (UTC) (envelope-from juan.rosero@oksigeno.com) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx1.freebsd.org (Postfix) with ESMTP id 075A4C2F for ; Mon, 4 Mar 2013 05:15:32 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hi8so1508401wib.13 for ; Sun, 03 Mar 2013 21:15:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oksigeno.com; s=mail; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type; bh=HIeCicMtgMjN18YCKsQ9wPVB2o8oz02OxHpGGuZ1AEY=; b=VMQNBdgHr4yW89wIqaO5q7nOdxQ9mNnNfvoGBgv/qCQRWuE3qyIzFV0ZxFMBNvUugq Bf7p8INd1/SvZZ/5VYJHkVRb1rkTHZ1Pun4A2Enr7rR40x6AiTsY6BhzKwovfME4q2nW Z0GsMhRvHVcWuSFsol4qgCiv7SoF5zGvRcXZw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=HIeCicMtgMjN18YCKsQ9wPVB2o8oz02OxHpGGuZ1AEY=; b=Lba0enBLv6JmYWEGAnybI72RMXTvEFzRSWpnfOhc3Yqv0zBzrvsoYy5h9kv3WG7YYK A+LtJsThDW7LZ6udqF35CfSEM0jkDZnKNvRAtBShlRfPdUVtX3zwWLE43WtB+miqk45M zTOvumB6ycSApXjB8gmoBH+fO8ekt2KZ4D3e+kVzNr9VyZoLwsHU90CKKH8cJSi3S9Iw QG6tTbNu6cYKKkXJGVAZ/P9jlKH96RTe9Z/K/tLViqzdsPtmsOTLOl5FsA5/5sUFw6NN DK15KdPuurttf6HWf42/lVAoGnJEpWolYKO6BDZz4aRXB1rsMd98mUEYhcXIArqoisiv tdOw== MIME-Version: 1.0 X-Received: by 10.194.158.161 with SMTP id wv1mr29294422wjb.38.1362374126247; Sun, 03 Mar 2013 21:15:26 -0800 (PST) Received: by 10.194.15.170 with HTTP; Sun, 3 Mar 2013 21:15:26 -0800 (PST) X-Originating-IP: [186.101.157.163] Date: Mon, 4 Mar 2013 00:15:26 -0500 Message-ID: Subject: FreeBSD cross-compilation for ARM architecture From: =?ISO-8859-1?Q?Modus_Latinoam=E9rica_=2D_Juan_Manuel_Rosero_Puente?= To: freebsd-arm@freebsd.org X-Gm-Message-State: ALoCoQmBPZZrhaS1XtdpocsYf8ibLu2qSgQJvGL6k9hxRFwoIf5hxywudWYthNUC5uvekQbKvxFR Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 05:15:33 -0000 To the people who want to join us, we pretend to build a FreeBSD basic cross-compilation for ARM embedded systems with few .img files for the popular main chipsets. - Rockchip - I will work on it! - Raspberry pi - ... any ideas? Everyone is welcome. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 4 09:12:17 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7F47A1C4 for ; Mon, 4 Mar 2013 09:12:17 +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 48E5C7F4 for ; Mon, 4 Mar 2013 09:12:16 +0000 (UTC) Received: from mxin2-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp5.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MJ400BUTPK6WU20@smtp5.clear.net.nz> for freebsd-arm@freebsd.org; Mon, 04 Mar 2013 22:12:10 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO bender) ([202.0.48.19]) by smtpin2.paradise.net.nz with ESMTP; Mon, 04 Mar 2013 22:12:09 +1300 Date: Mon, 04 Mar 2013 22:12:05 +1300 From: Andrew Turner Subject: Re: ARM EABI test image In-reply-to: To: Ganbold Tsagaankhuu Message-id: <20130304221205.7d427b38@bender> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit References: <20130302172556.5b59e122@bender> Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 09:12:17 -0000 On Sun, 3 Mar 2013 01:17:01 +0800 Ganbold Tsagaankhuu wrote: > Andrew, > > On Sat, Mar 2, 2013 at 12:25 PM, Andrew Turner > wrote: > > Hello, > > > > I have built an updated ARM EABI test image for Raspberry Pi [1]. > > > > The only known issue is c++ exception handling is broken when > > using in a dynamically linked executable. Static executables should > > work with c++ exceptions. > > > > To test it you will have to extract it using unxz and dd it to an sd > > card, for example, with a USB to SD adapter on /dev/da0: > > $ unxz bsd-pi-eabi-r247609.img.xz > > $ dd if=bsd-pi-eabi-r247609.img of=/dev/da0 > > > > If you don't have a Raspberry Pi but would like to try it on your > > board you can add -DWITH_ARM_EABI to the make commands you use to > > build and install world and the kernel. > > > > Can people try this as I would like to know if anything else is > > broken as this will become the default ABI for 10. > > > > Just tried the image. Seems work but observed for instance gpart shows > big numbers for 2GB SD: I've confirmed this is a bug where the stack is incorrectly aligned. I have a fix for this and will post a patch for review when I've cleaned it up. Andrew From owner-freebsd-arm@FreeBSD.ORG Mon Mar 4 11:06:39 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 69388E8C for ; Mon, 4 Mar 2013 11:06:39 +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 5B274E39 for ; Mon, 4 Mar 2013 11:06:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r24B6dte038678 for ; Mon, 4 Mar 2013 11:06:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r24B6cOw038676 for freebsd-arm@FreeBSD.org; Mon, 4 Mar 2013 11:06:38 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Mar 2013 11:06:38 GMT Message-Id: <201303041106.r24B6cOw038676@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 11:06:39 -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/176424 arm Compiler warning, TARGET_ARCH=armv6, make MALLOC_PRODU o arm/175803 arm building xdev for arm failing o arm/175605 arm please fix build binutils-2.23.1 in raspberry pi 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 [new driver] [patch] nslu2_led driver for the LEDs on p arm/134338 arm [patch] Lock GPIO accesses on ixp425 19 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Mar 4 12:06:12 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E65AA7D5 for ; Mon, 4 Mar 2013 12:06:12 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by mx1.freebsd.org (Postfix) with ESMTP id B00731506 for ; Mon, 4 Mar 2013 12:06:12 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id cr7so1079148qab.8 for ; Mon, 04 Mar 2013 04:06:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=jYUS39DH3MAhexm03zRIHYkscgGQJZFz8BWspaDaz2o=; b=Xee8mG35z/3Wr+q8bi9rcN8nQwXfwqzgYkYTSVPTojh9HcPZ9P578IRKetXVXeVH8a qOgQJPP/qnB1sQZZ1IFCwW1xsYKEosOBB6CkJ2di3LkfZg2/ExXbGBNkQ1y8Mztm7uKn zULnA812lSTmIyzEFDmzMDmKOZFV+M+WupYillPB5PbdthL4CNsch/Hr6QNsMkdGHF+I g3DUdi3BcnnxB3IXM7CGxe6K5qEJDGS7HVcqrk6Xnhng72BRYnN4j2DfKelWwZ3l3zQY ojIoVa8y0RdJBBYRGLK8CS51SoiNJleHhFHi4TTMapDnZv5P/o2q5ivh2PNgYeLl/QEb ElJw== MIME-Version: 1.0 X-Received: by 10.49.84.104 with SMTP id x8mr34636505qey.5.1362398765663; Mon, 04 Mar 2013 04:06:05 -0800 (PST) Received: by 10.49.87.193 with HTTP; Mon, 4 Mar 2013 04:06:05 -0800 (PST) Date: Mon, 4 Mar 2013 20:06:05 +0800 Message-ID: Subject: RasPi Panic: Address offset 0xC1526FF0 bigger than size 0x08000000 From: Alie Tan To: "freebsd-arm@freebsd.org" X-Gm-Message-State: ALoCoQm57/1WaKL/osJAEyfXOAN8AQlbeKdKyUSeqHTifzzsHJx56oEe0Kf/YY2qq7SaTJNlrE1p Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 12:06:13 -0000 Hi, I got this panic below with RasPi 256MB: panic: Address offset 0xC1526FF0 bigger than size 0x08000000 Any idea why? Regards, Alie T From owner-freebsd-arm@FreeBSD.ORG Mon Mar 4 15:03:12 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E5534396 for ; Mon, 4 Mar 2013 15:03:12 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id C22F81ED7 for ; Mon, 4 Mar 2013 15:03:12 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UCWuv-0003GS-Mp; Mon, 04 Mar 2013 15:03:05 +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 r24F32Ke091531; Mon, 4 Mar 2013 08:03:02 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+Kvzr9tZI9MoNhpD11NmNf Subject: Re: RasPi Panic: Address offset 0xC1526FF0 bigger than size 0x08000000 From: Ian Lepore To: Alie Tan In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Mon, 04 Mar 2013 08:03:02 -0700 Message-ID: <1362409382.1195.227.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 15:03:13 -0000 On Mon, 2013-03-04 at 20:06 +0800, Alie Tan wrote: > Hi, > > I got this panic below with RasPi 256MB: > panic: Address offset 0xC1526FF0 bigger than size 0x08000000 > > Any idea why? > > Regards, > Alie T If you're using a recently-compiled kernel but the ubldr on the msdos partition of your sdcard hasn't been updated recently, that would explain it. If so, just copy the latest ubldr onto the msdos partition. If you're using a build script that always rebuilds the whole sdcard image every time, this may be a different problem. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Mar 4 15:18:49 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2799A9CF; Mon, 4 Mar 2013 15:18:49 +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 F40E41FC6; Mon, 4 Mar 2013 15:18:48 +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 r24FImGs050516; Mon, 4 Mar 2013 10:18:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r24FIm0b050515; Mon, 4 Mar 2013 15:18:48 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Mar 2013 15:18:48 GMT Message-Id: <201303041518.r24FIm0b050515@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 15:18:49 -0000 TB --- 2013-03-04 13:20:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-04 13:20:20 - 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 --- 2013-03-04 13:20:20 - starting HEAD tinderbox run for arm/arm TB --- 2013-03-04 13:20:20 - cleaning the object tree TB --- 2013-03-04 13:20:20 - /usr/local/bin/svn stat /src TB --- 2013-03-04 13:20:24 - At svn revision 247790 TB --- 2013-03-04 13:20:25 - building world TB --- 2013-03-04 13:20:25 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 13:20:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 13:20:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 13:20:25 - SRCCONF=/dev/null TB --- 2013-03-04 13:20:25 - TARGET=arm TB --- 2013-03-04 13:20:25 - TARGET_ARCH=arm TB --- 2013-03-04 13:20:25 - TZ=UTC TB --- 2013-03-04 13:20:25 - __MAKE_CONF=/dev/null TB --- 2013-03-04 13:20:25 - cd /src TB --- 2013-03-04 13:20:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 4 13:20:30 UTC 2013 >>> 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 Mon Mar 4 15:09:36 UTC 2013 TB --- 2013-03-04 15:09:36 - generating LINT kernel config TB --- 2013-03-04 15:09:36 - cd /src/sys/arm/conf TB --- 2013-03-04 15:09:36 - /usr/bin/make -B LINT TB --- 2013-03-04 15:09:37 - cd /src/sys/arm/conf TB --- 2013-03-04 15:09:37 - /usr/sbin/config -m LINT TB --- 2013-03-04 15:09:37 - building LINT kernel TB --- 2013-03-04 15:09:37 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 15:09:37 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 15:09:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 15:09:37 - SRCCONF=/dev/null TB --- 2013-03-04 15:09:37 - TARGET=arm TB --- 2013-03-04 15:09:37 - TARGET_ARCH=arm TB --- 2013-03-04 15:09:37 - TZ=UTC TB --- 2013-03-04 15:09:37 - __MAKE_CONF=/dev/null TB --- 2013-03-04 15:09:37 - cd /src TB --- 2013-03-04 15:09:37 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 4 15:09:37 UTC 2013 >>> 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 -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 -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/kern_thr.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 -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/kern_thread.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 -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/kern_time.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 -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/kern_timeout.c /src/sys/kern/kern_timeout.c: In function 'softclock_call_cc': /src/sys/kern/kern_timeout.c:659: error: 'sbt1' undeclared (first use in this function) /src/sys/kern/kern_timeout.c:659: error: (Each undeclared identifier is reported only once /src/sys/kern/kern_timeout.c:659: error: for each function it appears in.) *** [kern_timeout.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 --- 2013-03-04 15:18:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-04 15:18:48 - ERROR: failed to build LINT kernel TB --- 2013-03-04 15:18:48 - 5776.47 user 998.45 system 7107.85 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Mon Mar 4 16:26:31 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 05CDAC18 for ; Mon, 4 Mar 2013 16:26:31 +0000 (UTC) (envelope-from kientzle@freebsd.org) 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 BEC546D5 for ; Mon, 4 Mar 2013 16:26:30 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r24GQTc2073124; Mon, 4 Mar 2013 16:26:29 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id r988mbfjwq72puy4aetmt9d9cs; Mon, 04 Mar 2013 16:26:29 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: FreeBSD cross-compilation for ARM architecture Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Tim Kientzle In-Reply-To: Date: Mon, 4 Mar 2013 08:26:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?iso-8859-1?Q?Modus_Latinoam=E9rica_-_Juan_Manuel_Rosero_Puente?= X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 16:26:31 -0000 On Mar 3, 2013, at 9:15 PM, Modus Latinoam=E9rica - Juan Manuel Rosero = Puente wrote: > To the people who want to join us, we pretend to build a FreeBSD basic > cross-compilation for ARM embedded systems with few .img files for the > popular main chipsets. >=20 >=20 > - Rockchip - I will work on it! > - Raspberry pi > - ... any ideas? You should take a look at github.com/kientzle/freebsd-beaglebone This started as a tool for building images for BeagleBone, but now supports several different ARM embedded systems, including: * RaspberryPi * BeagleBone * Pandaboard * VersatilePB It should be easy to use this for other platforms as well. If you have any questions, please let me know. Cheers, Tim From owner-freebsd-arm@FreeBSD.ORG Mon Mar 4 16:31:43 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 05145CA4 for ; Mon, 4 Mar 2013 16:31:43 +0000 (UTC) (envelope-from kientzle@freebsd.org) 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 C2C616FC for ; Mon, 4 Mar 2013 16:31:42 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r24GVeT3073171; Mon, 4 Mar 2013 16:31:40 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id znqtej69gvyumqdwyx9hqdcaxa; Mon, 04 Mar 2013 16:31:40 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: GENERIC kernel issues Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <549B1B40-99E7-47D4-BA13-1F08507B7B58@bsdimp.com> Date: Mon, 4 Mar 2013 08:31:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9C4AD429-7134-4433-A713-5DFA12628AE9@freebsd.org> References: <549B1B40-99E7-47D4-BA13-1F08507B7B58@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 16:31:43 -0000 On Mar 3, 2013, at 6:39 PM, Warner Losh wrote: >=20 > On Mar 3, 2013, at 12:43 PM, Tim Kientzle wrote: >=20 >> I spent some time yesterday putting together a kernel >> configuration for a GENERIC ARM kernel that would >> support both RaspberryPi and BeagleBone. >>=20 >> Just to see how far I could get. >>=20 >> Here's a list of the problems I've found so far: >>=20 >> ** Multiple MMU support. If you put these two lines into an >> ARM kernel config, the build will fail in the MMU code: >>=20 >> cpu CPU_ARM1176 >> cpu CPU_CORTEXA >>=20 >> Basically, this turns on the support for multiple MMUs but the >> ARMv6/ARMv7 MMU definitions don't play nicely with run-time >> MMU selection. >=20 > Having looked at the defines, it could be done with variables, but I = fear that will slow things down to do a simple #define -> variable. We = may need two sets of code for performance=85 The MMU management I really know nothing about. If you do =85 ;-) >> ** PHYSADDR/KERNPHYSADDR hardwiring. Ian has made a >> lot of progress and I'm working on some related changes to >> address this. I think we understand how to eliminate these >> constants and replace them with run-time detection of the >> load address. I'm still not sure what changes might be needed >> to the loader to make this work. >>=20 >> ** PIPT vs. VIVT cache management. This is currently set at compile >> time; we'll need to have a way to set this at run time based on the >> CPU. (I have some skeletal code to select CPU at the top of >> initarm by inspecting the FDT. I presume this switch will be routine >> once a robust version of that is in place.) >=20 > Generally we should be doing this, both for the Core and the SoC. I = don't think we do this generally, and we should. It is one of the big = advantages of FDT: It tells you what's going on so you don't have to = guess.... >=20 >> ** TI processor detection. This is currently hardwired at build = time, >> so we cannot currently build a kernel that supports both AM335x >> and OMAP4, for example. >=20 > Can't we do this with compat field in the FDT? I have prototype code that does exactly this, but it needs a lot of cleanup before it can be committed. Tim From owner-freebsd-arm@FreeBSD.ORG Mon Mar 4 17:35:15 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6D0B974A for ; Mon, 4 Mar 2013 17:35:15 +0000 (UTC) (envelope-from jadcooper@yahoo.com) Received: from nm30-vm4.bullet.mail.ne1.yahoo.com (nm30-vm4.bullet.mail.ne1.yahoo.com [98.138.91.190]) by mx1.freebsd.org (Postfix) with ESMTP id 218A7A1D for ; Mon, 4 Mar 2013 17:35:15 +0000 (UTC) Received: from [98.138.226.176] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 04 Mar 2013 17:32:27 -0000 Received: from [98.138.88.247] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 04 Mar 2013 17:32:27 -0000 Received: from [127.0.0.1] by smtp110-mob.biz.mail.ne1.yahoo.com with NNFMP; 04 Mar 2013 17:32:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362418347; bh=fij8aQvzQaf+YpiyB7Hvvvlue5gGZw0aBA+4bhjbAWQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Subject:From:Content-Type:X-Mailer:Message-Id:Date:To:Content-Transfer-Encoding:Mime-Version; b=UxdCp/LDDHOdxtsBTCLto6S7Sv7EQFyt6XtDSaLfjSkrAwQsrAug6WQp9GNwBjYfrvb50rskmTyffGo+gMCXnTvKVcsiAvC+n/uPXLSXg2o91e6VrT84KNKmXYPcu5xXRzjvxHopBqdJI/r0EuZSQ5dhRn61rokCtBDMWNAt8JI= X-Yahoo-Newman-Id: 202226.81286.bm@smtp110-mob.biz.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: e10jZmEVM1nBe0O4UF3044eMUFN62.dnqnAzVmSsunKxIIV P7pyqsDnalnRngd5X5IcynC3fxqndAKiDtX3XxOuy4bTv_IjPKq9dHlzMRUJ 0LfVIqNm3wy_QxKdwD0bt32hd6mq7n0hbTjYKV4Mod0vWkAPXwBhLbGSoB2J N_6JHG0RzGKYJqPJJYQOm1AZIdE0VJNMbEbPwZX3eJBEgy_uxFkhY6glN3N4 qq.2Zq0fROapCNf2mrlr0KDeXp34Z7Se4XJGcDK.8R5OI_uiQu97oiSDR.iC fHBEr35bVZ9RswcCGc1U5Xrxc_rRxxNi4Z26tx7V1W3Mpqyuo3PpeFmbwgX8 ESSN_iBz7MP._6dbxJod..rZ8fGcPa_V0.FEHbblkJDALLTp9FGhsL102UzX MklOqsYWIhzFNI0lyDb0ziojhPdN9EzkEmWFVpi_ZGlUhBfYhQtOpTZ6tp.k YfqCBaH3c5Q-- X-Yahoo-SMTP: 1NwK1FqswBBIXmrGMynm9AQsKvKa_A-- Received: from [192.168.1.103] (jadcooper@68.161.233.84 with xymcookie) by smtp110-mob.biz.mail.ne1.yahoo.com with SMTP; 04 Mar 2013 09:32:27 -0800 PST Subject: Raspberry Pi image and pkg_add, pkg etc From: Jad Cooper Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (9B206) Message-Id: <642BFD16-A5E3-447F-9C52-6855AB1E5CC4@yahoo.com> Date: Mon, 4 Mar 2013 12:20:13 -0500 To: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 17:35:15 -0000 Hi, I'd like to get involved in cleaning up/helping mature the Freebsd Raspe= rry Pi image.=20 It's a fantastic platform but some things are broken especially the package m= anager as it seems to not correctly resolve the FTP repository, or incorrect= ly looks for tzb files or looks for a directory called ARMv6 when in fact th= e txz files are in the ARM folder.=20 Please not this is my first such post so if the formatting or post is in the= wrong list, I do apologize in advance. Jad= From owner-freebsd-arm@FreeBSD.ORG Mon Mar 4 22:16:34 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 35F57592 for ; Mon, 4 Mar 2013 22:16:34 +0000 (UTC) (envelope-from mcgovern@spoon.beta.com) Received: from spoon.beta.com (spoon.beta.com [199.165.180.2]) by mx1.freebsd.org (Postfix) with ESMTP id D35931849 for ; Mon, 4 Mar 2013 22:16:33 +0000 (UTC) Received: from spoon.beta.com (localhost [127.0.0.1]) by spoon.beta.com (8.14.5/8.14.5) with ESMTP id r24LtVki017001 for ; Mon, 4 Mar 2013 16:55:31 -0500 (EST) (envelope-from mcgovern@spoon.beta.com) Received: (from mcgovern@localhost) by spoon.beta.com (8.14.5/8.14.5/Submit) id r24LtN7a016998 for freebsd-arm@freebsd.org; Mon, 4 Mar 2013 16:55:23 -0500 (EST) (envelope-from mcgovern) Date: Mon, 4 Mar 2013 16:55:23 -0500 (EST) From: "Brian J. McGovern" Message-Id: <201303042155.r24LtN7a016998@spoon.beta.com> To: freebsd-arm@freebsd.org Subject: arm/173617 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on spoon.beta.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 22:16:34 -0000 I have been chasing down a disk write problem my OpenRD. In my research, I ran across arm/173617, which discusses file corruption while downloading ports via fetch, which is how I first noticed the issue. However, contrary to the PR, the issues does not appear to be in the network interface, but rather on the writing of the file to disk. The problem appears global - I've tested SATA, USB (umass), and SD/MMC interfaces. I've also had problems with NFS mounts in the past, but have not verified that the issues are the same. I have not chased down a particular size, but "small" writes (e.g. a config file, .c file, etc.) appear to work correctly at all times. "Large" writes (I usually see it on files a MB or larger, but this may be a function of opportunity) will typically see some number of bytes set to zero. To reproduce the problem, I wrote a short application that writes sequentially incrementing 64-bit integers out to disk. (e.g. 0, 1, 2, 3...), and one that reads them back. The result matrix clearly showed the problem is on the write side - writing files on other systems and reading them back on the OpenRD works fine. Writing them on the OpenRD causes read back failures, both on the OpenRD _and_ other hosts. I have also found that setting the file handle O_SYNC (or mounting the filesystem in sync mode) eliminates the problem. Has anyone seen/fixed this problem? I'd hate to waste much more time with it if its a known problem, or there is a closed PR I haven't found yet. -Brian From owner-freebsd-arm@FreeBSD.ORG Mon Mar 4 22:52:10 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 879D0F95 for ; Mon, 4 Mar 2013 22:52:10 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 5C49C137 for ; Mon, 4 Mar 2013 22:52:10 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UCeEr-000HiV-FO; Mon, 04 Mar 2013 22:52:09 +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 r24Mq7FB092142; Mon, 4 Mar 2013 15:52:07 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19g/MHT0HaB0QxHDa0ujd8s Subject: Re: arm/173617 From: Ian Lepore To: "Brian J. McGovern" In-Reply-To: <201303042155.r24LtN7a016998@spoon.beta.com> References: <201303042155.r24LtN7a016998@spoon.beta.com> Content-Type: text/plain; charset="us-ascii" Date: Mon, 04 Mar 2013 15:52:06 -0700 Message-ID: <1362437526.1195.293.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 22:52:10 -0000 On Mon, 2013-03-04 at 16:55 -0500, Brian J. McGovern wrote: > I have been chasing down a disk write problem my OpenRD. In my research, I > ran across arm/173617, which discusses file corruption while downloading ports > via fetch, which is how I first noticed the issue. However, contrary to the PR, > the issues does not appear to be in the network interface, but rather on the > writing of the file to disk. The problem appears global - I've tested SATA, > USB (umass), and SD/MMC interfaces. I've also had problems with NFS mounts in > the past, but have not verified that the issues are the same. > > I have not chased down a particular size, but "small" writes (e.g. a config > file, .c file, etc.) appear to work correctly at all times. "Large" writes > (I usually see it on files a MB or larger, but this may be a function of > opportunity) will typically see some number of bytes set to zero. To reproduce > the problem, I wrote a short application that writes sequentially incrementing > 64-bit integers out to disk. (e.g. 0, 1, 2, 3...), and one that reads them > back. > > The result matrix clearly showed the problem is on the write side - writing > files on other systems and reading them back on the OpenRD works fine. Writing > them on the OpenRD causes read back failures, both on the OpenRD _and_ other > hosts. I have also found that setting the file handle O_SYNC (or mounting > the filesystem in sync mode) eliminates the problem. > > Has anyone seen/fixed this problem? I'd hate to waste much more time with it > if its a known problem, or there is a closed PR I haven't found yet. > You didn't say what version of freebsd you're working with. I saw a problem like that a while back on my similar DreamPlug; the symptom was random chunks of corruption that were always 32 bytes of wrong data each. I think the fix for that was to disable cache write-allocate on sheeva chipsets; that fix came into -current along with all the armv6 changes, but I have it as a separate patch too. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Mar 5 00:49:40 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6E3D22B1 for ; Tue, 5 Mar 2013 00:49:40 +0000 (UTC) (envelope-from ThomasSkibo@sbcglobal.net) Received: from nm25-vm0.access.bullet.mail.mud.yahoo.com (nm25-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.191]) by mx1.freebsd.org (Postfix) with ESMTP id F2AFB69D for ; Tue, 5 Mar 2013 00:49:39 +0000 (UTC) Received: from [66.94.237.192] by nm25.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Mar 2013 00:49:33 -0000 Received: from [98.138.84.173] by tm3.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Mar 2013 00:49:32 -0000 Received: from [127.0.0.1] by smtp107.sbc.mail.ne1.yahoo.com with NNFMP; 05 Mar 2013 00:49:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1362444572; bh=uZEchNFS+Ea2xPRxVscgUZoRCFuBa3eazrWDiA8LlUo=; 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:Content-Type:Content-Transfer-Encoding; b=HSW32VRMDpOta+ARW1aqnvcx9OQuWMroPeuRX/OBkaARjq0cHuzwEI8vrCL9sCFJF9aTs12CnD4xPSFlS0yNadqkOfFuDaMI5VhJ4pbOM2++tn9aMEN8/BrZynF5xdzkgRzWKYHTGLSvcuiZNHcRSfngOWkdCppOxc2LzocmEgk= X-Yahoo-Newman-Id: 807676.71577.bm@smtp107.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: a1mazYYVM1nmGBI61hi4LukMfqVTaGJRmgA6OHb.WPRHf9b 395hHPPB5Nmk4aqugGfPiu7XdaEUpyOL.9dP._kR.DPo6M_R9vp97ejkiYGI pp0_Nr0w.uBKuJQxn1fYQbKMehGIoSVmU9BLaz9wFbZODkGEQVQVOFbVmGl4 9cBV0izZBr5EtglC9Oa6GJjLmvjuZ.udDjrB9FLBXFvQ9ibg0EvzL9mxp3Os HLxkqdS1yybo9yzQsVwQvBi.K5QFu_bF7TXSA2xmlh2uaMRN3PjgVo8F1kcn wU2RkEJTI6lbbpsTBiz6gbwZ7wXbOgiZosyQVCdQE536.dF78xH7XuGW2JQG Ju_19HO6Jsm99ruqHJmYGbuMwXHV1D0ZZGmzLw6DofY0H.oYBclj90KnhMEl r86vMvSrS9evaJ1Q1jSYsPoihrxG6CI2_5fMm6Ih6G.7EgSze9VtAyMbx3.m hvYods_PF33nzR6Sat84ma3h_auJv.iy80G55JQQ- X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- Received: from [192.168.1.9] (ThomasSkibo@71.139.174.219 with plain) by smtp107.sbc.mail.ne1.yahoo.com with SMTP; 04 Mar 2013 16:49:32 -0800 PST Message-ID: <51354125.4060500@sbcglobal.net> Date: Mon, 04 Mar 2013 16:49:41 -0800 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Weird kernel mode data abort panic on Zedboard. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 00:49:40 -0000 Hello, again. I thought I'd describe this kernel panic and see if anyone has seen anything similar. This is on the Zedboard (ARM Cortex-A9 armv6). I can consistently panic the kernel by ftp'ing files to a local filesystem. It crashes every fourth time or so in the same manner. The specific fault is a 'Permission Fault (P)' on the first page of data in a file buf. The fault occurs in ffs_write() when it attempts to uiomove/copyin data from user space to the file buf. The first write faults but copyin() catches the fault and then calls vfs_bio_clrbuf() which tries to zero out the buf data. It's the second fault that causes the panic. Using Xilinx's XMD tool, I can walk the page table in physical memory and find the PTE. It is always okay and has priviledged read and write permissions. Curiously, sometimes I get another permission fault if I try to read from the fault address in the debugger. That tells me there is a stale TLB entry without read permissions either. The other buf pages seem okay. Any ideas? I can duplicate this with l2 cache turned off. I can also duplicate it using a USB-ethernet interface instead of the Zynq cgem ethernet interface so it's not that driver. Thanks, --Thomas ============================================================ (ftp data from a remote system to Zedboard...) 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd tftpboot 250 Directory successfully changed. ftp> get kernel.bin local: kernel.bin remote: kernel.bin 229 Entering Extended Passive Mode (|||30574|). 150 Opening BINARY mode data connection for kernel.bin (4176120 bytes). 0% | | 0 0.00 KiB/s --:-- ETA100% |***********************************| 4078 KiB 27.55 MiB/s 00:00 ETA 226 Transfer complete. 4176120 bytes received in 00:00 (27.45 MiB/s) ftp> get kernel.bin local: kernel.bin remote: kernel.bin 229 Entering Extended Passive Mode (|||32024|). 150 Opening BINARY mode data connection for kernel.bin (4176120 bytes). 0% | | 0 0.00 KiB/s --:-- ETA100% |***********************************| 4078 KiB 27.79 MiB/s 00:00 ETA 226 Transfer complete. 4176120 bytes received in 00:00 (27.71 MiB/s) ftp> get kernel.bin local: kernel.bin remote: kernel.bin 229 Entering Extended Passive Mode (|||59472|). 150 Opening BINARY mode data connection for kernel.bin (4176120 bytes). 0% | | 0 0.00 KiB/s --:-- ETA100% |***********************************| 4078 KiB 27.81 MiB/s 00:00 ETA 226 Transfer complete. 4176120 bytes received in 00:00 (27.73 MiB/s) ftp> get kernel.bin local: kernel.bin remote: kernel.bin 229 Entering Extended Passive Mode (|||18618|). 150 Opening BINARY mode data connection for kernel.bin (4176120 bytes). 0% | | 0 0.00 KiB/s --:-- ETA100% |***********************************| 4078 KiB 27.90 MiB/s 00:00 ETA 226 Transfer complete. 4176120 bytes received in 00:00 (27.81 MiB/s) ftp> get kernel.bin local: kernel.bin remote: kernel.bin 229 Entering Extended Passive Mode (|||8385|). 150 Opening BINARY mode data connection for kernel.bin (4176120 bytes). 0% | | 0 0.00 KiB/s --:-- ETA100% |***********************************| 4078 KiB 27.83 MiB/s 00:00 ETA 226 Transfer complete. 4176120 bytes received in 00:00 (27.75 MiB/s) ftp> get kernel.bin local: kernel.bin remote: kernel.bin 229 Entering Extended Passive Mode (|||45403|). 150 Opening BINARY mode data connection for kernel.bin (4176120 bytes). 0% | | 0 0.00 KiB/s --:-- ETA100% |***********************************| 4078 KiB 27.92 MiB/s 00:00 ETA 226 Transfer complete. 4176120 bytes received in 00:00 (27.83 MiB/s) ftp> get kernel.bin local: kernel.bin remote: kernel.bin 229 Entering Extended Passive Mode (|||34019|). 150 Opening BINARY mode data connection for kernel.bin (4176120 bytes). 0% | | 0 0.00 KiB/s --:-- ETA vm_fault(0xc0610000, cdf2c000, 2, 0) -> 2 Fatal kernel mode data abort: 'Permission Fault (P)' trapframe: 0xd67eda68 FSR=0000080f, FAR=cdf2c000, spsr=20000013 r0 =cdf2c000, r1 =00000f80, r2 =00000000, r3 =00000000 r4 =cdf2c000, r5 =00000000, r6 =00000000, r7 =cdf2d000 r8 =000000ff, r9 =00000000, r10=cd385660, r11=d67edae0 r12=cdf2c000, ssp=d67edab4, slr=c02d27a8, pc =c043039c [ thread pid 619 tid 100040 ] Stopped at memset+0x48: undge 0xa0cc20f8 db> show buffer $r10 ===== faulty address is always first page of buf ===== buf at 0xcd385660 b_flags = 0x20000000, b_xflags=0x2, b_vflags=0x0 b_error = 0, b_bufsize = 32768, b_bcount = 32768, b_resid = 0 b_bufobj = (0xc3028954), b_data = 0xcdf2c000, b_blkno = 2432, b_lblkno = 24, b_dep = 0 b_npages = 8, pages(OBJ, IDX, PA): (0xc301dc24, 0xc0, 0x402a000),(0xc301dc24, 0xc1, 0x402b000),(0xc301dc24, 0xc2, 0x4250000),(0xc301dc24, 0xc3, 0x4251000),(0xc301dc24, 0xc4, 0x4252000),(0xc301dc24, 0xc5, 0x4253000),(0xc301dc24, 0xc6, 0x4274000),(0xc301dc24, 0xc7, 0x4275000) lock type bufwait: EXCL by thread 0xc2ef7000 (pid 619, ftp, tid 100040) db> bt Tracing pid 619 tid 100040 td 0xc2ef7000 db_trace_self() at db_trace_self+0xc scp=0xc04236fc rlv=0xc0423748 (db_trace_thread+0x38) rsp=0xd67ed77c rfp=0xd67ed788 db_trace_thread() at db_trace_thread+0xc scp=0xc042371c rlv=0xc012b708 (db_command_init+0x354) rsp=0xd67ed78c rfp=0xd67ed7a8 db_command_init() at db_command_init+0x27c scp=0xc012b630 rlv=0xc012b10c (db_skip_to_eol+0x4a0) rsp=0xd67ed7ac rfp=0xd67ed850 r5=0x00000000 r4=0xc04d382c db_skip_to_eol() at db_skip_to_eol+0x1d4 scp=0xc012ae40 rlv=0xc012b278 (db_command_loop+0x60) rsp=0xd67ed854 rfp=0xd67ed860 r10=0x60000093 r8=0x0000080f r7=0x00000000 r6=0xcdf2c000 r5=0xc04d3af4 r4=0xd67ed86c db_command_loop() at db_command_loop+0xc scp=0xc012b224 rlv=0xc012d758 (X_db_sym_numargs+0xf4) rsp=0xd67ed864 rfp=0xd67ed980 X_db_sym_numargs() at X_db_sym_numargs+0x14 --More-- scp=0xc012d678 rlv=0xc02897a4 (kdb_trap+0xa4) rsp=0xd67ed984 rfp=0xd67ed9a8 r4=0xd67eda68 kdb_trap() at kdb_trap+0xc scp=0xc028970c rlv=0xc04329b4 (badaddr_read+0x284) rsp=0xd67ed9ac rfp=0xd67ed9c8 r10=0x00000000 r8=0xd67eda68 r7=0xc2ef7000 r6=0xcdf2c000 r5=0x0000080f r4=0xd67eda68 badaddr_read() at badaddr_read+0xfc scp=0xc043282c rlv=0xc0432ef0 (data_abort_handler+0x4e4) rsp=0xd67ed9cc rfp=0xd67eda64 r6=0xd67edef8 r5=0xc2eec8ac r4=0xcdf2c000 data_abort_handler() at data_abort_handler+0xc scp=0xc0432a18 rlv=0xc0424f00 (address_exception_entry+0x50) rsp=0xd67eda68 rfp=0xd67edae0 r10=0xcd385660 r9=0x00000000 r8=0x000000ff r7=0xcdf2d000 r6=0x00000000 r5=0x00000000 r4=0xcdf2c000 vfs_bio_clrbuf() at vfs_bio_clrbuf+0xc --More-- scp=0xc02d2594 rlv=0xc03d7970 (ffs_syncvnode+0xb4c) rsp=0xd67edae4 rfp=0xd67edb5c r10=0x00008000 r9=0x00000000 r8=0x00008000 r7=0x0000000f r6=0x00000000 r5=0x00008000 r4=0xc2f61000 ffs_syncvnode() at ffs_syncvnode+0x6bc scp=0xc03d74e0 rlv=0xc04448c8 (VOP_WRITE_APV+0x104) rsp=0xd67edb60 rfp=0xd67edc08 r10=0x00000000 r9=0x000c0000 r8=0x00000000 r7=0x00000000 r6=0x00000000 r5=0xd67edc24 r4=0xc04f5f00 VOP_WRITE_APV() at VOP_WRITE_APV+0xc scp=0xc04447d0 rlv=0xc02ff4b8 (vn_extattr_get+0x2e0) rsp=0xd67edc0c rfp=0xd67edc6c r8=0xc2f25ce8 r7=0xc30288e0 r6=0x00000000 r5=0xd67edc24 r4=0x00000000 vn_extattr_get() at vn_extattr_get+0x158 scp=0xc02ff330 rlv=0xc02fd9a0 (foffset_lock_uio+0x1f8) rsp=0xd67edc70 rfp=0xd67edd40 r10=0xc30288e0 r9=0x00010000 --More-- r8=0x00000000 r7=0x00000000 r6=0xc2f25ce8 r5=0xd67eddb4 r4=0x7fffffff foffset_lock_uio() at foffset_lock_uio+0x38 scp=0xc02fd7e0 rlv=0xc029ce48 (sys_ioctl+0x210) rsp=0xd67edd44 rfp=0xd67edd70 r10=0x00010000 r9=0x00000005 r8=0x00000000 r7=0xc2f25ce8 r6=0xc2ef7000 r5=0xd67eddb4 r4=0xffffffff sys_ioctl() at sys_ioctl+0x174 scp=0xc029cdac rlv=0xc029d190 (kern_writev+0x60) rsp=0xd67edd74 rfp=0xd67edda8 r10=0x00000000 r9=0x00000000 r8=0xc2ef7000 r7=0xd67eddb4 r6=0x00000005 r5=0x00000000 r4=0x00000000 kern_writev() at kern_writev+0xc scp=0xc029d13c rlv=0xc029d230 (sys_write+0x58) rsp=0xd67eddac rfp=0xd67edde0 r8=0x00000000 r7=0x00000000 r6=0x00000000 r5=0xc2ef7000 r4=0xc2eec8ac sys_write() at sys_write+0xc --More-- scp=0xc029d1e4 rlv=0xc0433570 (swi_handler+0x49c) rsp=0xd67edde4 rfp=0xd67edea4 swi_handler() at swi_handler+0xc scp=0xc04330e0 rlv=0xc0424d34 (swi_entry+0x30) rsp=0xd67edea8 rfp=0xbfffe2e0 r7=0x00000000 r6=0xd67edeac r5=0x00010000 r4=0x2089d000 fiqvector() at 0x170f8 scp=0x000170f8 rlv=0x00019f94 (0x19f94) rsp=0xbfffe2e4 rfp=0xbfffe3d8 r10=0x20803130 r9=0x00036614 r8=0x00024058 r7=0x00000000 r6=0x00000001 r5=0x00000000 r4=0x00000004 fiqvector() at 0x19824 scp=0x00019824 rlv=0x00010424 (0x10424) rsp=0xbfffe3dc rfp=0xbfffe884 r7=0x20803130 r6=0x00000001 r5=0x00000000 r4=0xbfffe8a0 fiqvector() at 0x101b4 scp=0x000101b4 rlv=0x00010634 (0x10634) --More-- rsp=0xbfffe888 rfp=0xbfffe894 r10=0x00000000 r9=0x00000000 r8=0x00000000 r7=0xbfffee64 r6=0x20808400 r5=0x00030048 r4=0xbfffe8a0 fiqvector() at 0x10614 scp=0x00010614 rlv=0x0001c82c (0x1c82c) rsp=0xbfffe898 rfp=0xbfffe8c8 fiqvector() at 0x1c4a0 scp=0x0001c4a0 rlv=0x0001d72c (0x1d72c) rsp=0xbfffe8cc rfp=0xbfffed10 r6=0x00000001 r5=0x00037354 r4=0x00034bfc fiqvector() at 0x1c94c scp=0x0001c94c rlv=0x0000aa58 (0xaa58) rsp=0xbfffed14 rfp=0xbfffed34 r10=0x2004eb90 r8=0x00000000 r7=0x00000000 r6=0xbfffed54 r5=0xbfffed48 r4=0x00000002 fiqvector() at 0xa928 scp=0x0000a928 rlv=0x20038144 (0x20038144) rsp=0xbfffed38 rfp=0x00000000 --More-- r8=0x00000000 r7=0x00000000 r6=0xbfffed44 r5=0x20037db8 r4=0x20053000 ====== (now debugger faults trying to read the same address) ====== db> x 0xcdf2c000 0xcdf2c000: vm_fault(0xc0610000, cdf2c000, 2, 0) -> 2 Fatal kernel mode data abort: 'Permission Fault (P)' trapframe: 0xd67ed6f0 FSR=0000000f, FAR=cdf2c000, spsr=60000093 r0 =00000000, r1 =c2ef7000, r2 =00000004, r3 =c051bac8 r4 =00000004, r5 =cdf2c000, r6 =00000000, r7 =d67ed760 r8 =cdf2c000, r9 =00000002, r10=00000010, r11=d67ed75c r12=00000001, ssp=d67ed73c, slr=c0429c04, pc =c0423174 panic: Fatal abort Uptime: 49s Automatic reboot in 15 seconds - press a key on the console to abort -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Tue Mar 5 01:09:47 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A4723674; Tue, 5 Mar 2013 01:09:47 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 791E370C; Tue, 5 Mar 2013 01:09:47 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UCgNx-000B7U-5k; Tue, 05 Mar 2013 01:09:41 +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 r2519bnD092298; Mon, 4 Mar 2013 18:09:37 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/94X/mmuXPv8yApyQWgqGL Subject: Re: GENERIC kernel issues From: Ian Lepore To: Tim Kientzle In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Mon, 04 Mar 2013 18:09:37 -0700 Message-ID: <1362445777.1195.299.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 01:09:47 -0000 On Sun, 2013-03-03 at 11:43 -0800, Tim Kientzle wrote: > > ** PHYSADDR/KERNPHYSADDR hardwiring. Ian has made a > lot of progress and I'm working on some related changes to > address this. I think we understand how to eliminate these > constants and replace them with run-time detection of the > load address. I'm still not sure what changes might be needed > to the loader to make this work. I don't think anything more needs to be done to the loader to be able to load a kernel built with the ldscript changes, beyond the change I did a week or two ago to make it work right with elf headers that contain physical addresses. On the other hand, I haven't got anything to offer on the problem of the loader needing to be linked differently for each board or SoC, since they all have physical memory in differing address ranges. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Mar 5 01:19:14 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4DB63723; Tue, 5 Mar 2013 01:19:14 +0000 (UTC) (envelope-from mcgovern@beta.com) Received: from spoon.beta.com (spoon.beta.com [199.165.180.2]) by mx1.freebsd.org (Postfix) with ESMTP id D3E0A742; Tue, 5 Mar 2013 01:19:13 +0000 (UTC) Received: from [199.165.180.44] ([199.165.180.44]) by spoon.beta.com (8.14.5/8.14.5) with ESMTP id r251J74w017956; Mon, 4 Mar 2013 20:19:08 -0500 (EST) (envelope-from mcgovern@beta.com) Subject: Re: arm/173617 From: "Brian J. McGovern" To: Ian Lepore In-Reply-To: <1362437526.1195.293.camel@revolution.hippie.lan> References: <201303042155.r24LtN7a016998@spoon.beta.com> <1362437526.1195.293.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Organization: B.E.T.A. Date: Tue, 05 Mar 2013 01:19:07 +0000 Message-ID: <1362446347.1382.4.camel@fbsd-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=1.5 required=5.0 tests=HELO_MISC_IP,RDNS_NONE autolearn=no version=3.3.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on spoon.beta.com Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mcgovern@beta.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 01:19:14 -0000 On Mon, 2013-03-04 at 15:52 -0700, Ian Lepore wrote: > On Mon, 2013-03-04 at 16:55 -0500, Brian J. McGovern wrote: > > I have been chasing down a disk write problem my OpenRD. In my research, I > > ran across arm/173617, which discusses file corruption while downloading ports > > via fetch, which is how I first noticed the issue. However, contrary to the PR, > > the issues does not appear to be in the network interface, but rather on the > > writing of the file to disk. The problem appears global - I've tested SATA, > > USB (umass), and SD/MMC interfaces. I've also had problems with NFS mounts in > > the past, but have not verified that the issues are the same. > > > > I have not chased down a particular size, but "small" writes (e.g. a config > > file, .c file, etc.) appear to work correctly at all times. "Large" writes > > (I usually see it on files a MB or larger, but this may be a function of > > opportunity) will typically see some number of bytes set to zero. To reproduce > > the problem, I wrote a short application that writes sequentially incrementing > > 64-bit integers out to disk. (e.g. 0, 1, 2, 3...), and one that reads them > > back. > > > > The result matrix clearly showed the problem is on the write side - writing > > files on other systems and reading them back on the OpenRD works fine. Writing > > them on the OpenRD causes read back failures, both on the OpenRD _and_ other > > hosts. I have also found that setting the file handle O_SYNC (or mounting > > the filesystem in sync mode) eliminates the problem. > > > > Has anyone seen/fixed this problem? I'd hate to waste much more time with it > > if its a known problem, or there is a closed PR I haven't found yet. > > > > You didn't say what version of freebsd you're working with. I saw a > problem like that a while back on my similar DreamPlug; the symptom was > random chunks of corruption that were always 32 bytes of wrong data > each. I think the fix for that was to disable cache write-allocate on > sheeva chipsets; that fix came into -current along with all the armv6 > changes, but I have it as a separate patch too. > > -- Ian > > > Sorry. The tests were specifically with 9.1-RELEASE. Most of the time, I've seen 64 bits of corruption, and all zeros, rather than "wrong data", although early on I did see some other values occur, although I thought it may have been a 32 vs. 64 bit issues with ints until I went to uint64_t. Is -current working well enough to build a stable platform? Can you email me the patch privately, and I'll see if I can get it working on 9? -Brian From owner-freebsd-arm@FreeBSD.ORG Tue Mar 5 01:21:12 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2B3A5779 for ; Tue, 5 Mar 2013 01:21:12 +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 C01FF757 for ; Tue, 5 Mar 2013 01:21:11 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UCgYw-000Njs-1O for freebsd-arm@freebsd.org; Mon, 04 Mar 2013 17:21:04 -0800 Message-ID: <5135487C.80107@bluezbox.com> Date: Mon, 04 Mar 2013 17:21:00 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Weird kernel mode data abort panic on Zedboard. References: <51354125.4060500@sbcglobal.net> In-Reply-To: <51354125.4060500@sbcglobal.net> 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 3/4/2013 4:49 PM, Thomas Skibo wrote: > > Hello, again. > > I thought I'd describe this kernel panic and see if anyone has seen > anything similar. This is on the Zedboard (ARM Cortex-A9 armv6). > > I can consistently panic the kernel by ftp'ing files to a local > filesystem. It crashes every fourth time or so in the same manner. > The specific fault is a 'Permission Fault (P)' on the first page of > data in a file buf. > > The fault occurs in ffs_write() when it attempts to uiomove/copyin > data from user space to the file buf. The first write faults but > copyin() catches the fault and then calls vfs_bio_clrbuf() which tries > to zero out the buf data. It's the second fault that causes the panic. > > Using Xilinx's XMD tool, I can walk the page table in physical memory > and find the PTE. It is always okay and has priviledged read and > write permissions. Curiously, sometimes I get another permission > fault if I try to read from the fault address in the debugger. That > tells me there is a stale TLB entry without read permissions either. > The other buf pages seem okay. > > Any ideas? I can duplicate this with l2 cache turned off. I can also > duplicate it using a USB-ethernet interface instead of the Zynq cgem > ethernet interface so it's not that driver. [...] 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] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 01:21:12 -0000 On 3/4/2013 4:49 PM, Thomas Skibo wrote: > > Hello, again. > > I thought I'd describe this kernel panic and see if anyone has seen > anything similar. This is on the Zedboard (ARM Cortex-A9 armv6). > > I can consistently panic the kernel by ftp'ing files to a local > filesystem. It crashes every fourth time or so in the same manner. > The specific fault is a 'Permission Fault (P)' on the first page of > data in a file buf. > > The fault occurs in ffs_write() when it attempts to uiomove/copyin > data from user space to the file buf. The first write faults but > copyin() catches the fault and then calls vfs_bio_clrbuf() which tries > to zero out the buf data. It's the second fault that causes the panic. > > Using Xilinx's XMD tool, I can walk the page table in physical memory > and find the PTE. It is always okay and has priviledged read and > write permissions. Curiously, sometimes I get another permission > fault if I try to read from the fault address in the debugger. That > tells me there is a stale TLB entry without read permissions either. > The other buf pages seem okay. > > Any ideas? I can duplicate this with l2 cache turned off. I can also > duplicate it using a USB-ethernet interface instead of the Zynq cgem > ethernet interface so it's not that driver. Just a hunch here - looks like TLB entry is not update properly. Might be missing PTE_SYNC in pmap-v6.c. Or current PTE_SYNC implementation does not cover all requirements for your platform. I'd say latter - but without proper debugging it's just guesswork. From owner-freebsd-arm@FreeBSD.ORG Tue Mar 5 01:47:37 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CEEF7A80 for ; Tue, 5 Mar 2013 01:47:37 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 9657680D for ; Tue, 5 Mar 2013 01:47:37 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UCgye-0002he-F8; Tue, 05 Mar 2013 01:47:36 +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 r251lXHf092327; Mon, 4 Mar 2013 18:47:33 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/bmvpP6kMRHiPLSJyeOSTU Subject: Re: arm/173617 From: Ian Lepore To: mcgovern@beta.com In-Reply-To: <1362446347.1382.4.camel@fbsd-laptop> References: <201303042155.r24LtN7a016998@spoon.beta.com> <1362437526.1195.293.camel@revolution.hippie.lan> <1362446347.1382.4.camel@fbsd-laptop> Content-Type: multipart/mixed; boundary="=-2B+lSvL55LM46qugFifW" Date: Mon, 04 Mar 2013 18:47:33 -0700 Message-ID: <1362448053.1195.304.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 01:47:37 -0000 --=-2B+lSvL55LM46qugFifW Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tue, 2013-03-05 at 01:19 +0000, Brian J. McGovern wrote: > On Mon, 2013-03-04 at 15:52 -0700, Ian Lepore wrote: > > On Mon, 2013-03-04 at 16:55 -0500, Brian J. McGovern wrote: > > > I have been chasing down a disk write problem my OpenRD. In my research, I > > > ran across arm/173617, which discusses file corruption while downloading ports > > > via fetch, which is how I first noticed the issue. However, contrary to the PR, > > > the issues does not appear to be in the network interface, but rather on the > > > writing of the file to disk. The problem appears global - I've tested SATA, > > > USB (umass), and SD/MMC interfaces. I've also had problems with NFS mounts in > > > the past, but have not verified that the issues are the same. > > > > > > I have not chased down a particular size, but "small" writes (e.g. a config > > > file, .c file, etc.) appear to work correctly at all times. "Large" writes > > > (I usually see it on files a MB or larger, but this may be a function of > > > opportunity) will typically see some number of bytes set to zero. To reproduce > > > the problem, I wrote a short application that writes sequentially incrementing > > > 64-bit integers out to disk. (e.g. 0, 1, 2, 3...), and one that reads them > > > back. > > > > > > The result matrix clearly showed the problem is on the write side - writing > > > files on other systems and reading them back on the OpenRD works fine. Writing > > > them on the OpenRD causes read back failures, both on the OpenRD _and_ other > > > hosts. I have also found that setting the file handle O_SYNC (or mounting > > > the filesystem in sync mode) eliminates the problem. > > > > > > Has anyone seen/fixed this problem? I'd hate to waste much more time with it > > > if its a known problem, or there is a closed PR I haven't found yet. > > > > > > > You didn't say what version of freebsd you're working with. I saw a > > problem like that a while back on my similar DreamPlug; the symptom was > > random chunks of corruption that were always 32 bytes of wrong data > > each. I think the fix for that was to disable cache write-allocate on > > sheeva chipsets; that fix came into -current along with all the armv6 > > changes, but I have it as a separate patch too. > > > > -- Ian > > > > > > > Sorry. The tests were specifically with 9.1-RELEASE. > > Most of the time, I've seen 64 bits of corruption, and all zeros, rather > than "wrong data", although early on I did see some other values occur, > although I thought it may have been a 32 vs. 64 bit issues with ints > until I went to uint64_t. > > Is -current working well enough to build a stable platform? Can you > email me the patch privately, and I'll see if I can get it working on 9? > > -Brian Here's the patch I prepared for 8.2 at work, it applies cleanly to 9-stable (it's even simpler than I remembered). The state of -current is good for DreamPlug. I'd actually appreciate folks testing other sheeva-based platforms and let me know about any kernel config or dts file changes you need to do. I'd like to get support for all the GlobalScale computers solidified in 9-stable sometime soon. -- Ian --=-2B+lSvL55LM46qugFifW Content-Disposition: inline; filename="dp_cache_wralloc.diff" Content-Type: text/x-patch; name="dp_cache_wralloc.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Do not enable allocating a cache line on write access. Instead, leave that feature in whatever state the bootloader set it to, on the theory that the firmware that comes with the unit knows best. diff -r df572d6d53cd -r a142512ee876 sys/arm/arm/cpufunc.c --- sys/arm/arm/cpufunc.c Thu Nov 22 16:46:06 2012 -0700 +++ sys/arm/arm/cpufunc.c Sat Dec 01 15:38:59 2012 -0700 @@ -1067,13 +1067,13 @@ set_cpufuncs() */ if (cputype == CPU_ID_MV88FR571_VD || cputype == CPU_ID_MV88FR571_41) { - sheeva_control_ext(0xffffffff, - FC_DCACHE_STREAM_EN | FC_WR_ALLOC_EN | + sheeva_control_ext(0xffffffff & ~FC_WR_ALLOC_EN, + FC_DCACHE_STREAM_EN | FC_BRANCH_TARG_BUF_DIS | FC_L2CACHE_EN | FC_L2_PREF_DIS); } else { - sheeva_control_ext(0xffffffff, - FC_DCACHE_STREAM_EN | FC_WR_ALLOC_EN | + sheeva_control_ext(0xffffffff & ~FC_WR_ALLOC_EN, + FC_DCACHE_STREAM_EN | FC_BRANCH_TARG_BUF_DIS | FC_L2CACHE_EN); } --=-2B+lSvL55LM46qugFifW-- From owner-freebsd-arm@FreeBSD.ORG Tue Mar 5 04:30:06 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3522D9EC for ; Tue, 5 Mar 2013 04:30:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 0666EE78 for ; Tue, 5 Mar 2013 04:30:05 +0000 (UTC) Received: by mail-ia0-f171.google.com with SMTP id z13so5607776iaz.2 for ; Mon, 04 Mar 2013 20:30:05 -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=ms8njQ0tXSJaScQGfLsvd98utjLMc6PQ0M07TWIpUx0=; b=jpkuT+GLl/dIHiqHJfAyKW5bhHJh0ghRvFF/HonBO0QKqPdKWPilF6Ewgxz9H+aiYl Xw6H5d9OeZk1neepT1T+3dOWOcOsyTm191k+4hsBb5EM+TaoXMHCMJ2bb3at8rvCAbQL C34kMBMzhXCVfhdewe/8Pz0IqgyWh8fAEJSbamzboubiNfP2jkK3wg3sI2EpeC13kpng iDeQx+sjvXfe2jEB2HzuGxxZ/jPoiVC9N0A/74bu8P0LEwWclrjkYKkCR4CuJW22icwb 6hAQYPtb35CB+rt2hDmFHc404c9o3tov0M06GaKALRMpdQiySEtjkgDOQQToMU+Z+kt/ YeAg== X-Received: by 10.50.185.234 with SMTP id ff10mr4890948igc.25.1362457805324; Mon, 04 Mar 2013 20:30:05 -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 ur12sm14991790igb.8.2013.03.04.20.30.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Mar 2013 20:30:03 -0800 (PST) Sender: Warner Losh Subject: Re: GENERIC kernel issues Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1362445777.1195.299.camel@revolution.hippie.lan> Date: Mon, 4 Mar 2013 21:30:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> References: <1362445777.1195.299.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkGJUkJqzo+O0NOdasAopOiSA6W1Fns09+znvOVbuORuwJ4Gdmq8W+X6X9o92qV9nQtcFef Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 04:30:06 -0000 On Mar 4, 2013, at 6:09 PM, Ian Lepore wrote: > On Sun, 2013-03-03 at 11:43 -0800, Tim Kientzle wrote: >>=20 >> ** PHYSADDR/KERNPHYSADDR hardwiring. Ian has made a >> lot of progress and I'm working on some related changes to >> address this. I think we understand how to eliminate these >> constants and replace them with run-time detection of the >> load address. I'm still not sure what changes might be needed >> to the loader to make this work.=20 >=20 > I don't think anything more needs to be done to the loader to be able = to > load a kernel built with the ldscript changes, beyond the change I did = a > week or two ago to make it work right with elf headers that contain > physical addresses. >=20 > On the other hand, I haven't got anything to offer on the problem of = the > loader needing to be linked differently for each board or SoC, since > they all have physical memory in differing address ranges. Well, the Phyiscal memory load address is just a hint after all. Any way = to leave it blank and have ubldr cope by putting it in the first = available phyiscal memory slot from the FDT? Warner From owner-freebsd-arm@FreeBSD.ORG Tue Mar 5 06:08:44 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 06CC4FB8 for ; Tue, 5 Mar 2013 06:08:44 +0000 (UTC) (envelope-from ThomasSkibo@sbcglobal.net) Received: from nm17.access.bullet.mail.sp2.yahoo.com (nm17.access.bullet.mail.sp2.yahoo.com [98.139.44.144]) by mx1.freebsd.org (Postfix) with ESMTP id ACB1923E for ; Tue, 5 Mar 2013 06:08:43 +0000 (UTC) Received: from [98.139.44.106] by nm17.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Mar 2013 06:08:43 -0000 Received: from [67.195.14.108] by tm11.access.bullet.mail.sp2.yahoo.com with NNFMP; 05 Mar 2013 06:08:43 -0000 Received: from [127.0.0.1] by smtp105.sbc.mail.gq1.yahoo.com with NNFMP; 05 Mar 2013 06:08:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1362463723; bh=dzvrUKCqLGtZa2LvP2GP+puoc18g8WrdwI6eAVH0jt4=; 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:Content-Transfer-Encoding; b=GKPpe3Acy4HiBhe/D7FYI0EsXEmhJrwW4RAnsvh4+uDUjZWOM+xWcJmLauGOVJSiH7opa2ZvNEvbt3RGu171Dqbev4ZFyP4ADmbd4M3C929yBF5PraZz578yC3jVXBrs0ors6LJ4EWAwXRI70iPhn7agT14JhW6ZGlOOh7yaxXQ= X-Yahoo-Newman-Id: 38756.74236.bm@smtp105.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: fZHsrjMVM1meGC6_i9KXh0sIBZAD_vjpX4.i0kFLP8r1e5o fkkcY7OfLTlP58dVTzMSqpRKeobkagNRNMlba5CKl_vUFMuQiOANi7H5nr0W nvwbIuIbNtGLCp4bdKPZoHsIoItrep.iHslIet2.iEt.MqurEHJUadcIAXWh wPK1Y9hV.l7uxWKah7MqUo738vhCKoYFr6cCckySw8qS8bqzrxlGw9OrX6zn 07cQf80qBVPOPoLUYcdVAqYk09__UOZhs5U8RbZ97Sw_kWmQKzn2tMnlLchl JdxpXR99FdZ8_odFFdtIonjPS8pQUOc.b8GEaCFRvjrObMuxz1D0MaU2SkwW ptfU4X7D.KaBzcySzspKkaYDL.cH7eb220umSMGOP4BhiUMAOjMTOifeW3sp fx5t_qHLRXcJcsPeNDr1HYsA9V6x_vD0hH7eDlgWwR.9w.yB2lI8EILm.fYg a5eTPVj0gbc7Oz0sdJm.88sOscIl.fB0VQdKb5bFwpxABbpbGsCIuNMVV.A- - X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- Received: from [192.168.1.9] (ThomasSkibo@71.139.174.219 with plain) by smtp105.sbc.mail.gq1.yahoo.com with SMTP; 04 Mar 2013 22:08:42 -0800 PST Message-ID: <51358BEB.50603@sbcglobal.net> Date: Mon, 04 Mar 2013 22:08:43 -0800 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Weird kernel mode data abort panic on Zedboard. References: <51354125.4060500@sbcglobal.net> In-Reply-To: <51354125.4060500@sbcglobal.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 06:08:44 -0000 Oleksandr Tymoshenko : > > Just a hunch here - looks like TLB entry is not update properly. Might > be missing > PTE_SYNC in pmap-v6.c. Or current PTE_SYNC implementation does not cover > all requirements for your platform. I'd say latter - but without proper > debugging > it's just guesswork. > Thanks. On my platform, PMAP_NEEDS_PTE_SYNC was 0 and I convinced myself earlier that the page tables were properly configured with write-through caching and didn't need PTE_SYNC() anyway. But, I just forced it use the run-time configurable pmap_needs_pte_sync variable which is set to 1 upon initialization and the problem went away. Setting pmap_needs_pte_sync to 0 subsequently didn't make the problem reappear so maybe it has something to do with early initialization of the page tables. I'll get more time to look at it later in the week. By the way, PTE_SYNC() doesn't properly write-back the level 2 cache on my platform because it needs physical addresses. But, it looks like that doesn't matter. --Thomas -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Tue Mar 5 07:33:28 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1EF74712 for ; Tue, 5 Mar 2013 07:33:28 +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 C2CFF702 for ; Tue, 5 Mar 2013 07:33:27 +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 <0MJ600F6FFNP1T10@smtp3.clear.net.nz> for freebsd-arm@freebsd.org; Tue, 05 Mar 2013 20:33:25 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO bender) ([202.0.48.19]) by smtpin32.paradise.net.nz with ESMTP; Tue, 05 Mar 2013 20:33:25 +1300 Date: Tue, 05 Mar 2013 20:33:18 +1300 From: Andrew Turner Subject: Re: ARM EABI test image In-reply-to: <20130304221205.7d427b38@bender> To: Ganbold Tsagaankhuu Message-id: <20130305203318.24f244c9@bender> MIME-version: 1.0 Content-type: multipart/mixed; boundary="MP_/KpoxgBcMnzg5T6o_qvFqvMh" References: <20130302172556.5b59e122@bender> <20130304221205.7d427b38@bender> Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 07:33:28 -0000 --MP_/KpoxgBcMnzg5T6o_qvFqvMh Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, 04 Mar 2013 22:12:05 +1300 Andrew Turner wrote: > On Sun, 3 Mar 2013 01:17:01 +0800 > Ganbold Tsagaankhuu wrote: > > > Andrew, > > > > On Sat, Mar 2, 2013 at 12:25 PM, Andrew Turner > > wrote: > > > Hello, > > > > > > I have built an updated ARM EABI test image for Raspberry Pi [1]. > > > > > > The only known issue is c++ exception handling is broken when > > > using in a dynamically linked executable. Static executables > > > should work with c++ exceptions. > > > > > > To test it you will have to extract it using unxz and dd it to an > > > sd card, for example, with a USB to SD adapter on /dev/da0: > > > $ unxz bsd-pi-eabi-r247609.img.xz > > > $ dd if=bsd-pi-eabi-r247609.img of=/dev/da0 > > > > > > If you don't have a Raspberry Pi but would like to try it on your > > > board you can add -DWITH_ARM_EABI to the make commands you use to > > > build and install world and the kernel. > > > > > > Can people try this as I would like to know if anything else is > > > broken as this will become the default ABI for 10. > > > > > > > Just tried the image. Seems work but observed for instance gpart > > shows big numbers for 2GB SD: > > I've confirmed this is a bug where the stack is incorrectly aligned. I > have a fix for this and will post a patch for review when I've cleaned > it up. Can you try this patch. It fixes the alignment of the stack in the kernel to be on an 8 byte boundary. Andrew --MP_/KpoxgBcMnzg5T6o_qvFqvMh Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=stack_align.diff Index: arm/vm_machdep.c =================================================================== --- arm/vm_machdep.c (revision 247608) +++ arm/vm_machdep.c (working copy) @@ -73,6 +73,12 @@ #include +/* + * struct switchframe must be a multiple of 8 for correct stack alignment + */ +CTASSERT(sizeof(struct switchframe) == 24); +CTASSERT(sizeof(struct trapframe) == 76); + #ifndef NSFBUFS #define NSFBUFS (512 + maxusers * 16) #endif @@ -131,8 +137,8 @@ pcb2->un_32.pcb32_sp = td2->td_kstack + USPACE_SVC_STACK_TOP - sizeof(*pcb2); pmap_activate(td2); - td2->td_frame = tf = - (struct trapframe *)pcb2->un_32.pcb32_sp - 1; + td2->td_frame = tf = (struct trapframe *)STACKALIGN( + pcb2->un_32.pcb32_sp - sizeof(struct trapframe)); *tf = *td1->td_frame; sf = (struct switchframe *)tf - 1; sf->sf_r4 = (u_int)fork_return; @@ -142,6 +148,8 @@ tf->tf_r0 = 0; tf->tf_r1 = 0; pcb2->un_32.pcb32_sp = (u_int)sf; + KASSERT((pcb2->un_32.pcb32_sp & 7) == 0, + ("cpu_fork: Incorrect stack alignment")); /* Setup to release spin count in fork_exit(). */ td2->td_md.md_spinlock_count = 1; @@ -345,6 +353,8 @@ tf->tf_r0 = 0; td->td_pcb->un_32.pcb32_sp = (u_int)sf; td->td_pcb->un_32.pcb32_und_sp = td->td_kstack + USPACE_UNDEF_STACK_TOP; + KASSERT((td->td_pcb->un_32.pcb32_sp & 7) == 0, + ("cpu_set_upcall: Incorrect stack alignment")); /* Setup to release spin count in fork_exit(). */ td->td_md.md_spinlock_count = 1; @@ -438,6 +448,8 @@ sf->sf_r4 = (u_int)func; sf->sf_r5 = (u_int)arg; td->td_pcb->un_32.pcb32_sp = (u_int)sf; + KASSERT((td->td_pcb->un_32.pcb32_sp & 7) == 0, + ("cpu_set_fork_handler: Incorrect stack alignment")); } /* Index: arm/swtch.S =================================================================== --- arm/swtch.S (revision 247608) +++ arm/swtch.S (working copy) @@ -211,10 +211,12 @@ GET_PCPU(r6) str r7, [r6, #PC_CURPCB] + add sp, sp, #4; ldmfd sp!, {r4-r7, pc} ENTRY(cpu_switch) stmfd sp!, {r4-r7, lr} + sub sp, sp, #4; mov r6, r2 /* Save the mutex */ .Lswitch_resume: @@ -488,6 +490,7 @@ * Pull the registers that got pushed when either savectx() or * cpu_switch() was called and return. */ + add sp, sp, #4; ldmfd sp!, {r4-r7, pc} #ifdef DIAGNOSTIC .Lswitch_bogons: @@ -501,6 +504,7 @@ #endif ENTRY(savectx) stmfd sp!, {r4-r7, lr} + sub sp, sp, #4 /* * r0 = pcb */ @@ -528,6 +532,7 @@ bl _C_LABEL(vfp_store) 1: #endif /* ARM_VFP_SUPPORT */ + add sp, sp, #4; ldmfd sp!, {r4-r7, pc} ENTRY(fork_trampoline) Index: include/frame.h =================================================================== --- include/frame.h (revision 247608) +++ include/frame.h (working copy) @@ -138,10 +138,14 @@ } irqframe_t; /* - * Switch frame + * Switch frame. + * + * It is important this is a multiple of 8 bytes so the stack is correctly + * aligned when we create new threads. */ struct switchframe { + u_int pad; /* Used to pad the struct to a multiple of 8-bytes */ u_int sf_r4; u_int sf_r5; u_int sf_r6; --MP_/KpoxgBcMnzg5T6o_qvFqvMh-- From owner-freebsd-arm@FreeBSD.ORG Tue Mar 5 10:02:27 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C2C98F1C for ; Tue, 5 Mar 2013 10:02:27 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from smtprelay-h31.telenor.se (smtprelay-h31.telenor.se [213.150.131.4]) by mx1.freebsd.org (Postfix) with ESMTP id 55D481B1 for ; Tue, 5 Mar 2013 10:02:26 +0000 (UTC) Received: from ipb5.telenor.se (ipb5.telenor.se [195.54.127.168]) by smtprelay-h31.telenor.se (Postfix) with ESMTP id 9A849E99F1 for ; Tue, 5 Mar 2013 10:29:54 +0100 (CET) X-SENDER-IP: [85.229.94.62] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap9JAOa5NVFV5V4+PGdsb2JhbABEiwe3TYEBFwMBAQEBODSCHwEBBAE6HCMFCwsYLiEMDAoUBhOIAQMJCq40hlINiVqMRIIVMweCX2EDlGqNNogh X-IronPort-AV: E=Sophos;i="4.84,786,1355094000"; d="scan'208";a="286537283" Received: from c-3e5ee555.06-11-73746f31.cust.bredbandsbolaget.se (HELO sigyn.alvermark.net) ([85.229.94.62]) by ipb5.telenor.se with ESMTP; 05 Mar 2013 10:29:54 +0100 Received: from gw.inter-sonic.com ([212.247.8.97] helo=[192.168.1.191]) by sigyn.alvermark.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UCoC2-0007aM-0O; Tue, 05 Mar 2013 10:29:54 +0100 Subject: Re: ARM EABI test image Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jakob Alvermark In-Reply-To: <20130305203318.24f244c9@bender> Date: Tue, 5 Mar 2013 10:29:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <15D3CC57-B665-45FB-A4D3-27058BC5689E@alvermark.net> References: <20130302172556.5b59e122@bender> <20130304221205.7d427b38@bender> <20130305203318.24f244c9@bender> To: Andrew Turner X-Mailer: Apple Mail (2.1085) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 10:02:27 -0000 On 5 mar 2013, at 08:33, Andrew Turner wrote: > On Mon, 04 Mar 2013 22:12:05 +1300 > Andrew Turner wrote: >=20 >> On Sun, 3 Mar 2013 01:17:01 +0800 >> Ganbold Tsagaankhuu wrote: >>=20 >>> Andrew, >>>=20 >>> On Sat, Mar 2, 2013 at 12:25 PM, Andrew Turner >>> wrote: >>>> Hello, >>>>=20 >>>> I have built an updated ARM EABI test image for Raspberry Pi [1]. >>>>=20 >>>> The only known issue is c++ exception handling is broken when >>>> using in a dynamically linked executable. Static executables >>>> should work with c++ exceptions. >>>>=20 >>>> To test it you will have to extract it using unxz and dd it to an >>>> sd card, for example, with a USB to SD adapter on /dev/da0: >>>> $ unxz bsd-pi-eabi-r247609.img.xz >>>> $ dd if=3Dbsd-pi-eabi-r247609.img of=3D/dev/da0 >>>>=20 >>>> If you don't have a Raspberry Pi but would like to try it on your >>>> board you can add -DWITH_ARM_EABI to the make commands you use to >>>> build and install world and the kernel. >>>>=20 >>>> Can people try this as I would like to know if anything else is >>>> broken as this will become the default ABI for 10. >>>>=20 >>>=20 >>> Just tried the image. Seems work but observed for instance gpart >>> shows big numbers for 2GB SD: >>=20 >> I've confirmed this is a bug where the stack is incorrectly aligned. = I >> have a fix for this and will post a patch for review when I've = cleaned >> it up. >=20 > Can you try this patch. It fixes the alignment of the stack in the > kernel to be on an 8 byte boundary. Hi Andrew, I just tried rebuilding the kernel with the patch applied and it seems = to have cured the gpart problem at least, haven't tested anything else = yet: % uname -a FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #33 r247831M: Tue = Mar 5 09:38:05 CET 2013 = root@test10:/src/FreeBSD/obj/arm.armv6/src/FreeBSD/head/sys/RPI-B arm % gpart show =3D> 1 15759359 mmcsd0 MBR (7.5G) 1 8 - free - (4.0k) 9 65529 1 !12 [active] (32M) 65538 458748 2 freebsd (224M) 524286 15235074 - free - (7.3G) =3D> 0 458748 mmcsd0s2 BSD (224M) 0 458748 1 freebsd-ufs (224M) %=20 Jakob= From owner-freebsd-arm@FreeBSD.ORG Tue Mar 5 20:01:44 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6A58589B for ; Tue, 5 Mar 2013 20:01:44 +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 0C62EA53 for ; Tue, 5 Mar 2013 20:01:43 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UCy3P-000HVY-HJ; Tue, 05 Mar 2013 12:01:41 -0800 Message-ID: <51364F20.500@bluezbox.com> Date: Tue, 05 Mar 2013 12:01:36 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Daisuke Aoyama Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <512FD3E8.4000307@bluezbox.com> <2D2EAE5B346840A49A5D99A9BFD1DA1D@ad.peach.ne.jp> In-Reply-To: <2D2EAE5B346840A49A5D99A9BFD1DA1D@ad.peach.ne.jp> 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 3/1/2013 12:57 AM, Daisuke Aoyama wrote: >> I'd like to thank you again for your outstanding work. >> I've just committed three patches based on your code: >> >> - Platform DMA support for SDHCI >> - DMA engine driver >> - DMA support for BCM2835 SDHCI driver > > Thank you. I checked the code and found some bug. > I don't check why bus_dma and bus_space is slow. > But using generic code is good. > > > o INFO_WAIT_RESP is cleared when reset. > o dreq is overwritten by next call. > o should reset DMA when error. > > quick fix is like this: > > > --- bcm2835_dma.c (revision 247518) > +++ bcm2835_dma.c (working copy) > @@ -199,6 +199,7 @@ > /* Reset control block */ > cb = sc->sc_dma_ch[ch].cb; > bzero(cb, sizeof(cb)); > + cb->info = INFO_WAIT_RESP; /* XXX */ > } [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 20:01:44 -0000 On 3/1/2013 12:57 AM, Daisuke Aoyama wrote: >> I'd like to thank you again for your outstanding work. >> I've just committed three patches based on your code: >> >> - Platform DMA support for SDHCI >> - DMA engine driver >> - DMA support for BCM2835 SDHCI driver > > Thank you. I checked the code and found some bug. > I don't check why bus_dma and bus_space is slow. > But using generic code is good. > > ---------------------------------------------------------------------- > o INFO_WAIT_RESP is cleared when reset. > o dreq is overwritten by next call. > o should reset DMA when error. > > quick fix is like this: > > > --- bcm2835_dma.c (revision 247518) > +++ bcm2835_dma.c (working copy) > @@ -199,6 +199,7 @@ > /* Reset control block */ > cb = sc->sc_dma_ch[ch].cb; > bzero(cb, sizeof(cb)); > + cb->info = INFO_WAIT_RESP; /* XXX */ > } Fixed > > static int > @@ -409,8 +410,10 @@ > return (-1); > > info = sc->sc_dma_ch[ch].cb->info; > - info &= ~INFO_PERMAP_MASK; > - info |= (dreq << INFO_PERMAP_SHIFT) & INFO_PERMAP_MASK; > + if (dreq) { > + info &= ~INFO_PERMAP_MASK; > + info |= (dreq << INFO_PERMAP_SHIFT) & INFO_PERMAP_MASK; > + } > > if (dreq) > info |= INFO_S_DREQ; > @@ -459,8 +462,10 @@ > return (-1); > > info = sc->sc_dma_ch[ch].cb->info; > - info &= ~INFO_PERMAP_MASK; > - info |= (dreq << INFO_PERMAP_SHIFT) & INFO_PERMAP_MASK; > + if (dreq) { > + info &= ~INFO_PERMAP_MASK; > + info |= (dreq << INFO_PERMAP_SHIFT) & INFO_PERMAP_MASK; > + } These are not really required. With current code if dreq is zero it will overwrite info bits properly while when patched - bits will be left untouched from previous setup call. > > if (dreq) > info |= INFO_D_DREQ; > @@ -615,6 +693,7 @@ > debug & DEBUG_ERROR_MASK, ch->ch); > bus_write_4(sc->sc_mem, BCM_DMA_DEBUG(ch->ch), > debug & DEBUG_ERROR_MASK); > + bcm_dma_reset(sc->sc_dev, ch->ch); > } > Fixed > if (cs & CS_INT) { > ---------------------------------------------------------------------- From owner-freebsd-arm@FreeBSD.ORG Tue Mar 5 22:59:28 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 52AC4D35; Tue, 5 Mar 2013 22:59:28 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id 8F44C213; Tue, 5 Mar 2013 22:59:27 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UD0pR-0002nr-WA; Tue, 05 Mar 2013 22:59:26 +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 r25MxNBJ002106; Tue, 5 Mar 2013 15:59:23 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+emoUwurEjYukmeT9848N5 Subject: Re: Raspberry Pi image and pkg_add, pkg etc From: Ian Lepore To: Jad Cooper In-Reply-To: <642BFD16-A5E3-447F-9C52-6855AB1E5CC4@yahoo.com> References: <642BFD16-A5E3-447F-9C52-6855AB1E5CC4@yahoo.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Mar 2013 15:59:23 -0700 Message-ID: <1362524363.1291.51.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" , Baptiste Daroussin X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 22:59:28 -0000 On Mon, 2013-03-04 at 12:20 -0500, Jad Cooper wrote: > Hi, I'd like to get involved in cleaning up/helping mature the Freebsd Rasperry Pi image. > It's a fantastic platform but some things are broken especially the package manager as it seems to not correctly resolve the FTP repository, or incorrectly looks for tzb files or looks for a directory called ARMv6 when in fact the txz files are in the ARM folder. > > Please not this is my first such post so if the formatting or post is in the wrong list, I do apologize in advance. > > Jad I don't think I quite understand your question, which is not too surprising since I know almost nothing about ports and packages. I do want to make sure you get a response from someone who knows about these things; I've added one such person to the CC list. One thing that confuses me about your question is the reference to the ftp repository... I don' think there are any arm packages being built and distributed by the FreeBSD project right now. Are you trying to set up your own local repository, or connect to a private one somewhere? -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Mar 5 23:05:37 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 78A4AEAF for ; Tue, 5 Mar 2013 23:05:37 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews04.kpnxchange.com (cpsmtpb-ews04.kpnxchange.com [213.75.39.7]) by mx1.freebsd.org (Postfix) with ESMTP id CCB6124E for ; Tue, 5 Mar 2013 23:05:36 +0000 (UTC) Received: from cpsps-ews05.kpnxchange.com ([10.94.84.172]) by cpsmtpb-ews04.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 6 Mar 2013 00:03:03 +0100 Received: from CPSMTPM-TLF101.kpnxchange.com ([195.121.3.4]) by cpsps-ews05.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 6 Mar 2013 00:03:03 +0100 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF101.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 6 Mar 2013 00:04:28 +0100 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id A6ACC61A5 for ; Wed, 6 Mar 2013 00:04:23 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: ARM EABI test image References: <20130302172556.5b59e122@bender> Date: Wed, 06 Mar 2013 00:04:22 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.14 (FreeBSD) X-OriginalArrivalTime: 05 Mar 2013 23:04:28.0750 (UTC) FILETIME=[CA0796E0:01CE19F5] X-RcptDomain: freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 23:05:37 -0000 On Sat, 02 Mar 2013 18:21:28 +0100, Ronald Klop wrote: > On Sat, 02 Mar 2013 05:25:56 +0100, Andrew Turner > wrote: > >> Hello, >> >> I have built an updated ARM EABI test image for Raspberry Pi [1]. >> >> The only known issue is c++ exception handling is broken when >> using in a dynamically linked executable. Static executables should >> work with c++ exceptions. >> >> To test it you will have to extract it using unxz and dd it to an sd >> card, for example, with a USB to SD adapter on /dev/da0: >> $ unxz bsd-pi-eabi-r247609.img.xz >> $ dd if=bsd-pi-eabi-r247609.img of=/dev/da0 >> >> If you don't have a Raspberry Pi but would like to try it on your board >> you can add -DWITH_ARM_EABI to the make commands you use to build and >> install world and the kernel. > > Is this also interesing on the older SHEEVAPLUG? > If yes, I can test it somewhere next week. > > Ronald. > >> >> Can people try this as I would like to know if anything else is broken >> as this will become the default ABI for 10. >> >> Andrew >> >> [1] http://people.freebsd.org/~andrew/rpi/bsd-pi-eabi-r247609.img.xz I get this error. I cross-compile 10-CURRENT/arm for SHEEVAPLUG on 9-STABLE/amd64. 10-CURRENT is just svn up'ed. I don't have special vars set for clang, so it compiles with gcc AFAIK. No src.conf. Using these env vars for buildworld: export TARGET_ARCH=arm export KERNCONF=SHEEVAPLUG export WITH_NAND=yes export WITH_ARM_EABI=yes ... cc -O -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_NANDFS_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -I/usr/src/sys/boot/arm/uboot/../../fdt -I/usr/obj/arm.arm/usr/src/sys/boot/arm/uboot/../../fdt -DLOADER_FDT_SUPPORT -DBOOT_FORTH -I/usr/src/sys/boot/arm/uboot/../../ficl -I/usr/src/sys/boot/arm/uboot/../../ficl/arm -DLOADER_DISK_SUPPORT -DLOADER_GPT_SUPPORT -DLOADER_MBR_SUPPORT -I/usr/src/sys/boot/arm/uboot/../../common -I. -ffreestanding -I/usr/src/sys/boot/arm/uboot/../../uboot/common -I/usr/src/sys/boot/arm/uboot/../../uboot/lib -I/usr/obj/arm.arm/usr/src/sys/boot/arm/uboot/../../uboot/lib -I/usr/src/sys/boot/arm/uboot/../../../../lib/libstand/ -std=gnu99 -Wsystem-headers -Werror -Wno-pointer-sign -nostdlib -static -T ldscript.generated -T /usr/src/sys/boot/arm/uboot/ldscript.arm -o ubldr start.o conf.o vers.o boot.o commands.o console.o devopen.o interp.o interp_backslash.o interp_parse.o ls.o misc.o module.o panic.o load_elf32.o reloc_elf32.o dev_net.o disk.o part.o crc32.o interp_forth.o main.o metadata.o /usr/obj/arm.arm/usr/src/sys/boot/arm/uboot/../../ficl/libficl.a /usr/obj/arm.arm/usr/src/sys/boot/arm/uboot/../../uboot/lib/libuboot.a /usr/obj/arm.arm/usr/src/sys/boot/arm/uboot/../../fdt/libfdt.a -lstand /usr/obj/arm.arm/usr/src/tmp/usr/lib/libstand.a(udivmoddi4.o): In function `__udivmoddi4': udivmoddi4.c:(.text+0x154): undefined reference to `__ctzsi2' udivmoddi4.c:(.text+0x16c): undefined reference to `__clzsi2' udivmoddi4.c:(.text+0x178): undefined reference to `__clzsi2' udivmoddi4.c:(.text+0x214): undefined reference to `__ctzsi2' udivmoddi4.c:(.text+0x240): undefined reference to `__clzsi2' udivmoddi4.c:(.text+0x24c): undefined reference to `__clzsi2' udivmoddi4.c:(.text+0x2c0): undefined reference to `__clzsi2' udivmoddi4.c:(.text+0x2cc): undefined reference to `__clzsi2' /usr/obj/arm.arm/usr/src/tmp/usr/lib/libstand.a(udivsi3.o): In function `__aeabi_uidiv': udivsi3.c:(.text+0x1c): undefined reference to `__clzsi2' /usr/obj/arm.arm/usr/src/tmp/usr/lib/libstand.a(udivsi3.o):udivsi3.c:(.text+0x28): more undefined references to `__clzsi2' follow *** [ubldr] Error code 1 1 error *** [all] Error code 2 1 error *** [all] Error code 2 1 error *** [all] Error code 2 1 error *** [sys.all__D] Error code 2 1 error *** [everything] Error code 2 1 error *** [buildworld] Error code 2 1 error If you need more info please tell. Ronald. From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 03:08:33 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5BAF09B4 for ; Wed, 6 Mar 2013 03:08:33 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 214FADAB for ; Wed, 6 Mar 2013 03:08:32 +0000 (UTC) Received: from pool-96-250-5-62.nycmny.fios.verizon.net ([96.250.5.62]:54993 helo=new-host-4.home) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UD4iQ-0005be-46 for arm@freebsd.org; Tue, 05 Mar 2013 22:08:26 -0500 From: George Neville-Neil Content-Type: multipart/signed; boundary="Apple-Mail=_A823AEAA-FEFF-4025-BC87-17E1CCAD7929"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Building gettext on ARM? Message-Id: <46D6567D-D7AC-4BFB-94FE-B54E87224C20@neville-neil.com> Date: Tue, 5 Mar 2013 22:08:25 -0500 To: "arm@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 03:08:33 -0000 --Apple-Mail=_A823AEAA-FEFF-4025-BC87-17E1CCAD7929 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Howdy, I believe this is an issue that may run deeper than just gettext: =3D=3D=3D> Building for gettext-0.18.1.1 Making all in gnulib-local Making all in gettext-runtime make all-recursive Making all in doc Making all in intl /bin/sh /usr/local/bin/libtool --tag=3DCC --mode=3Dcompile cc -c = -DLOCALEDIR=3D\"/usr/local/share/locale\" = -DLOCALE_ALIAS_PATH=3D\"/usr/local/share/locale\" = -DLIBDIR=3D\"/usr/local/lib\" -DBUILDING_LIBINTL -DBUILDING_DLL = -DIN_LIBINTL -DENABLE_RELOCATABLE=3D1 -DIN_LIBRARY = -DINSTALLDIR=3D\"/usr/local/lib\" -DNO_XMALLOC = -Dset_relocation_prefix=3Dlibintl_set_relocation_prefix = -Drelocate=3Dlibintl_relocate -DDEPENDS_ON_LIBICONV=3D1 -DHAVE_CONFIG_H = -I. -I. -I.. -I/usr/local/include -O -pipe -fvisibility=3Dhidden = ./bindtextdom.c libtool: compile: cc -c -DLOCALEDIR=3D\"/usr/local/share/locale\" = -DLOCALE_ALIAS_PATH=3D\"/usr/local/share/locale\" = -DLIBDIR=3D\"/usr/local/lib\" -DBUILDING_LIBINTL -DBUILDING_DLL = -DIN_LIBINTL -DENABLE_RELOCATABLE=3D1 -DIN_LIBRARY = -DINSTALLDIR=3D\"/usr/local/lib\" -DNO_XMALLOC = -Dset_relocation_prefix=3Dlibintl_set_relocation_prefix = -Drelocate=3Dlibintl_relocate -DDEPENDS_ON_LIBICONV=3D1 -DHAVE_CONFIG_H = -I. -I. -I.. -I/usr/local/include -O -pipe -fvisibility=3Dhidden = ./bindtextdom.c -fPIC -DPIC -o .libs/bindtextdom.o In file included from ./bindtextdom.c:24: /usr/include/stddef.h:41: error: two or more data types in declaration = specifiers *** [bindtextdom.lo] Signal 11 The offending line is: #include #include #include typedef __ptrdiff_t ptrdiff_t; <--- Line 41 Thoughts? Best, George --Apple-Mail=_A823AEAA-FEFF-4025-BC87-17E1CCAD7929 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iEYEARECAAYFAlE2sykACgkQYdh2wUQKM9KD0gCguKo9dYSEVuDs+ahx/Y6i4Qhu BeEAnR92iKJtfpJu+IZM2LmF8mZ5+J4j =ys9w -----END PGP SIGNATURE----- --Apple-Mail=_A823AEAA-FEFF-4025-BC87-17E1CCAD7929-- From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 03:24:25 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3A4A5D5B; Wed, 6 Mar 2013 03:24:25 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) by mx1.freebsd.org (Postfix) with ESMTP id 7F4DCE57; Wed, 6 Mar 2013 03:24:24 +0000 (UTC) Received: from [192.168.1.104] (pool-173-77-68-234.nycmny.east.verizon.net [173.77.68.234]) (authenticated bits=0) by feynman.konjz.org (8.14.6/8.14.4) with ESMTP id r2636L3Z062286 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 5 Mar 2013 22:06:30 -0500 (EST) (envelope-from george@ceetonetechnology.com) Message-ID: <5136B2A3.4010701@ceetonetechnology.com> Date: Tue, 05 Mar 2013 22:06:11 -0500 From: George Rosamond User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130222 Thunderbird/17.0.3 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Raspberry Pi image and pkg_add, pkg etc References: <642BFD16-A5E3-447F-9C52-6855AB1E5CC4@yahoo.com> <1362524363.1291.51.camel@revolution.hippie.lan> In-Reply-To: <1362524363.1291.51.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 5.32 (*****) FH_HOST_EQ_VERIZON_P,RDNS_DYNAMIC X-Spam-Hits: 5320 X-Spam-Names: FH_HOST_EQ_VERIZON_P,RDNS_DYNAMIC X-Spam-Flag: YES X-Mail-Provider: KonjZ X-Scanned-By: MIMEDefang 2.73 on 64.147.119.39 Cc: "freebsd-arm@freebsd.org" , Baptiste Daroussin X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: george@ceetonetechnology.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 03:24:25 -0000 On 03/05/13 17:59, Ian Lepore wrote: > On Mon, 2013-03-04 at 12:20 -0500, Jad Cooper wrote: >> Hi, I'd like to get involved in cleaning up/helping mature the >> Freebsd Rasperry Pi image. It's a fantastic platform but some >> things are broken especially the package manager as it seems to not >> correctly resolve the FTP repository, or incorrectly looks for tzb >> files or looks for a directory called ARMv6 when in fact the txz >> files are in the ARM folder. >> >> Please not this is my first such post so if the formatting or post >> is in the wrong list, I do apologize in advance. >> >> Jad > > I don't think I quite understand your question, which is not too > surprising since I know almost nothing about ports and packages. I > do want to make sure you get a response from someone who knows about > these things; I've added one such person to the CC list. > > One thing that confuses me about your question is the reference to > the ftp repository... I don' think there are any arm packages being > built and distributed by the FreeBSD project right now. Are you > trying to set up your own local repository, or connect to a private > one somewhere? I think my read on this is: there is no default PACKAGESITE set for pkgng in /usr/local/etc/pkg.conf for the builds, which means pkgng doesn't work as it should, so Jad is offering to assist in resolving this. Cool, Jad. And you're on the right list, and my MUA sees your email fine! So there is no official package or port repository yet for FreeBSD arm architecture. A number of people are maintaining public yet individual sites, but nothing official yet. Whether or not you're a developer, jump aboard and look at Tim's and Gonzo's scripts for start. But start building images and customizing them. Play. Enjoy. And feel free to jump in and ask questions. g From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 03:58:11 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 27CAC105; Wed, 6 Mar 2013 03:58:11 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id E3AEDF04; Wed, 6 Mar 2013 03:58:10 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UD5UX-000N2y-Gg; Wed, 06 Mar 2013 03:58:09 +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 r263w6Wd002353; Tue, 5 Mar 2013 20:58:06 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19cU8FSrSRU6NtJR+4f1ot/ Subject: Re: GENERIC kernel issues From: Ian Lepore To: Warner Losh In-Reply-To: <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> References: <1362445777.1195.299.camel@revolution.hippie.lan> <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Mar 2013 20:58:06 -0700 Message-ID: <1362542286.1291.94.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 03:58:11 -0000 On Mon, 2013-03-04 at 21:30 -0700, Warner Losh wrote: > On Mar 4, 2013, at 6:09 PM, Ian Lepore wrote: > > On Sun, 2013-03-03 at 11:43 -0800, Tim Kientzle wrote: > >> > >> ** PHYSADDR/KERNPHYSADDR hardwiring. Ian has made a > >> lot of progress and I'm working on some related changes to > >> address this. I think we understand how to eliminate these > >> constants and replace them with run-time detection of the > >> load address. I'm still not sure what changes might be needed > >> to the loader to make this work. > > > > I don't think anything more needs to be done to the loader to be able to > > load a kernel built with the ldscript changes, beyond the change I did a > > week or two ago to make it work right with elf headers that contain > > physical addresses. > > > > On the other hand, I haven't got anything to offer on the problem of the > > loader needing to be linked differently for each board or SoC, since > > they all have physical memory in differing address ranges. > > Well, the Phyiscal memory load address is just a hint after all. Any way to leave it blank and have ubldr cope by putting it in the first available phyiscal memory slot from the FDT? > > Warner > It's not just a hint, the executable is linked to run at that address and no other. There is no relocation info in the file at all. That's true of both the kernel and ubldr. It's also true of any old static-linked executable, but in that case the object is just mapped at the virtual address it's linked for by the kern/imgact_elf.c code. We essentially pull off the same mapping trick with the kernel, except that very early in locore.s the code is carefully crafted to work right whether on physical or virtual addressing, just long enough to get the MMU turned off. Then it sets up page tables to map the physical pages the kernel has been loaded into to match the virtual addresses it was linked for. All of that only works if the low-order bits of the virtual address it was linked for match the physical address it was loaded at. That is, if linked for 0xC0001000 it must be loaded at 0xNNNN1000 physical, where the N bits can be anything. Unfortunately, I don't think we can pull the same kind of trick with ubldr. In locore.s for the kernel we build simple page tables which are just enough to get us to the code in initarm() that builds them for real. No SoC-specific stuff has to happen along the way (or if it does, SoC-specific code is invoked via various hooks to board support routines). In ubldr we mess with the hardware (via the u-boot drivers), so if we turn on the MMU to map the memory ubldr is running from, we also have to map the hardware va=pa for those drivers to work. I don't know that there's any way to get the needed info for that from u-boot. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 10:06:00 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 602BFF50 for ; Wed, 6 Mar 2013 10:06:00 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 37BC5EB4 for ; Wed, 6 Mar 2013 10:06:00 +0000 (UTC) Received: by mail-ia0-f171.google.com with SMTP id z13so7298047iaz.30 for ; Wed, 06 Mar 2013 02:05:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=PNYaaPtZhWGsCgfuuNb9hm1yoDPvnzAJUD43T50N6PQ=; b=pL/ZB1GzvlUsprx6DTCDbaLva4eOsKzidH/cHX/VD8YuTDxxQi4SO5MSMAZstttF4f AUdWdV6NaGkCmdnRENp1ItAJhW2GBeAOEc8IrmQpARcNA3Dk1TKzi+tba38X+NCAODAp Qg6pkZvUL51vTUd99rkpqi8Bdrs6NEI2MLKadng/9PaYrBMPJqFwGJOlRoeV5+SY+06z W4STN/inI6NA4tegead2NRsF79ArHpZdTg40b1JJlvOZzpeW7LcF9007ekLksT5Zx03p QC9bokryyHI4/6X1bUtDXYTXUEMz1uZA+ub1tjuXJJKuxokfKSBd42sW0oKWguK+2/yO wYoQ== MIME-Version: 1.0 X-Received: by 10.50.170.102 with SMTP id al6mr10237566igc.20.1362564359811; Wed, 06 Mar 2013 02:05:59 -0800 (PST) Received: by 10.64.140.36 with HTTP; Wed, 6 Mar 2013 02:05:59 -0800 (PST) Date: Wed, 6 Mar 2013 18:05:59 +0800 Message-ID: Subject: Cubieboard like board - MarsBoard A10 From: Alie Tan To: "freebsd-arm@freebsd.org" X-Gm-Message-State: ALoCoQlRgvrSoG4fcaImm/ZbYypQXvi0mV9t13ah5g3G+dKWk2WvKbmeUKHX7890jjpJ87p9Mgg1 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 10:06:00 -0000 http://www.hotmcu.com/marsboard-a10-dev-board-p-59.html?cPath=33 Looks nice and seems supported by FreeBSD already since we already have CUBIEBOARD support From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 10:09:18 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EC356FBF for ; Wed, 6 Mar 2013 10:09:18 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by mx1.freebsd.org (Postfix) with ESMTP id BF01EED4 for ; Wed, 6 Mar 2013 10:09:18 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id k13so9020519iea.7 for ; Wed, 06 Mar 2013 02:09:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=96n8hknlcDpKdxh4rUPHBcov8Ej/hzBp0X4ZFr967a8=; b=Fif2JE8RgquCzdnzlFca5PtubiI1CIH9HRbA3Zfzoam0Byr9CbrHHHjJnt2T6vuwJu N4zLvS5RVvkUAZe4WXDcn1Ho8ITqQ/3V9mJLHZmZgKChohztt2APaXV+/wMyc4soRcU6 tVBTjyHUc4WXFy0y2zjS7jvsIuZNhEQGgDuoX2JHyqtR3aepLK8GTv92ydZJvsmVa6SC D6jQiPJ31YPWMBhC9TV0+Gu3e9C1ULQLZzBgP6HnIugrQeanGHUtTnY1B4BkPNmlH8Fs u6WpPiexAVR00yXKqBQpUFsfK2w4C90jixTE4NwWnM958gqr4Y5D+5JLF9XSBnpQ3gKF SUCg== MIME-Version: 1.0 X-Received: by 10.50.7.211 with SMTP id l19mr10171881iga.53.1362564558430; Wed, 06 Mar 2013 02:09:18 -0800 (PST) Received: by 10.64.140.36 with HTTP; Wed, 6 Mar 2013 02:09:18 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Mar 2013 18:09:18 +0800 Message-ID: Subject: Re: Cubieboard like board - MarsBoard A10 From: Alie Tan To: "freebsd-arm@freebsd.org" X-Gm-Message-State: ALoCoQnQpxcDtyhK1cgriD9Fl9NUX1RZALfsKJEfJ5joSA7vRJ8wAK59LN+QHERfWGEE5KCG5wSa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 10:09:19 -0000 Here is the website http://www.marsboard.com/ Seems still under construction On Wed, Mar 6, 2013 at 6:05 PM, Alie Tan wrote: > http://www.hotmcu.com/marsboard-a10-dev-board-p-59.html?cPath=33 > > Looks nice and seems supported by FreeBSD already since we already have > CUBIEBOARD support > From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 10:39:46 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 00111737; Wed, 6 Mar 2013 10:39:45 +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 69CA66B; Wed, 6 Mar 2013 10:39:45 +0000 (UTC) Received: from terran (unknown [192.168.99.1]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id A26E5C4946; Wed, 6 Mar 2013 12:39:43 +0200 (EET) Date: Wed, 6 Mar 2013 12:39:45 +0200 From: Aleksandr Rybalko To: george@ceetonetechnology.com Subject: Re: Raspberry Pi image and pkg_add, pkg etc Message-Id: <20130306123945.60aff30773fdd0fb2707a635@ddteam.net> In-Reply-To: <5136B2A3.4010701@ceetonetechnology.com> References: <642BFD16-A5E3-447F-9C52-6855AB1E5CC4@yahoo.com> <1362524363.1291.51.camel@revolution.hippie.lan> <5136B2A3.4010701@ceetonetechnology.com> 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" , Baptiste Daroussin , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 10:39:46 -0000 On Tue, 05 Mar 2013 22:06:11 -0500 George Rosamond wrote: > On 03/05/13 17:59, Ian Lepore wrote: > > On Mon, 2013-03-04 at 12:20 -0500, Jad Cooper wrote: > >> Hi, I'd like to get involved in cleaning up/helping mature the > >> Freebsd Rasperry Pi image. It's a fantastic platform but some > >> things are broken especially the package manager as it seems to not > >> correctly resolve the FTP repository, or incorrectly looks for tzb > >> files or looks for a directory called ARMv6 when in fact the txz > >> files are in the ARM folder. > >> > >> Please not this is my first such post so if the formatting or post > >> is in the wrong list, I do apologize in advance. > >> > >> Jad > > > > I don't think I quite understand your question, which is not too > > surprising since I know almost nothing about ports and packages. I > > do want to make sure you get a response from someone who knows about > > these things; I've added one such person to the CC list. > > > > One thing that confuses me about your question is the reference to > > the ftp repository... I don' think there are any arm packages being > > built and distributed by the FreeBSD project right now. Are you > > trying to set up your own local repository, or connect to a private > > one somewhere? > > I think my read on this is: there is no default PACKAGESITE set for > pkgng in /usr/local/etc/pkg.conf for the builds, which means pkgng > doesn't work as it should, so Jad is offering to assist in resolving this. > > Cool, Jad. And you're on the right list, and my MUA sees your email fine! > > So there is no official package or port repository yet for FreeBSD arm Small correction: we have port repository for all platforms, only some ports can't be built for ARM. Some ports are binary and can't be installed due to lack of FreeBSD ARM distro. > architecture. A number of people are maintaining public yet individual > sites, but nothing official yet. > > Whether or not you're a developer, jump aboard and look at Tim's and > Gonzo's scripts for start. > > But start building images and customizing them. Play. Enjoy. And feel > free to jump in and ask questions. > > g > _______________________________________________ > 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" -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 11:55:56 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 62F9F63B for ; Wed, 6 Mar 2013 11:55:56 +0000 (UTC) (envelope-from millenia2000@hotmail.com) Received: from bay0-omc3-s4.bay0.hotmail.com (bay0-omc3-s4.bay0.hotmail.com [65.54.190.142]) by mx1.freebsd.org (Postfix) with ESMTP id 516625F6 for ; Wed, 6 Mar 2013 11:55:56 +0000 (UTC) Received: from BAY165-W42 ([65.54.190.189]) by bay0-omc3-s4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Mar 2013 03:54:50 -0800 X-EIP: [4vQ9XPw/rSnJu+rz3tOBbzvT5+dimklb] X-Originating-Email: [millenia2000@hotmail.com] Message-ID: From: Sean Cavanaugh To: , , , , , Subject: Re: Date: Wed, 6 Mar 2013 06:54:50 -0500 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 06 Mar 2013 11:54:50.0468 (UTC) FILETIME=[68520A40:01CE1A61] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 11:55:56 -0000 http://tokoibunda.com/ajax/opensearch.php?jltzovn=3D555720&yipdk=3D5014 = From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 12:43:35 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A52CE1A8 for ; Wed, 6 Mar 2013 12:43:35 +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 61A4588F for ; Wed, 6 Mar 2013 12:43:35 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 9FC1639E09; Wed, 6 Mar 2013 21:43:27 +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 893B039D62; Wed, 6 Mar 2013 21:43:27 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: "Oleksandr Tymoshenko" References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <512FD3E8.4000307@bluezbox.com> <2D2EAE5B346840A49A5D99A9BFD1DA1D@ad.peach.ne.jp> <51364F20.500@bluezbox.com> In-Reply-To: <51364F20.500@bluezbox.com> Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Date: Wed, 6 Mar 2013 21:43:28 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 12:43:35 -0000 > These are not really required. With current code if dreq is zero it will > overwrite info bits properly while when patched - bits will be left untouched > from previous setup call. No, you need it. Current code cannot handle PERMAP (not INFO_S_DREQ and INFO_D_DREQ) if calling it with: setup_src(IO/DREQ_XXXX) *1 setup_dst(mem/DREQ_NONE) or setup_dst(IO/DREQ_XXXX) *2 setup_src(mem/DREQ_NONE) Note: Peripheral Mapping(20:16, see p.51) is shared by both src and dst. At least, you cannot use like: > info &= ~INFO_PERMAP_MASK; Because, previous call (*1 and *2) may put a value to it. -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 15:03:10 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A6492754 for ; Wed, 6 Mar 2013 15:03:10 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id 601D4F7D for ; Wed, 6 Mar 2013 15:03:09 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UDFs5-00017R-E4; Wed, 06 Mar 2013 15:03:09 +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 r26F35RN003126; Wed, 6 Mar 2013 08:03:05 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18Derx9KBqM92bk1B8iG1SO Subject: Re: cross-compilation of sh(1) from x86 to arm From: Ian Lepore To: Jilles Tjoelker In-Reply-To: <20130303231931.GD21318@stack.nl> References: <20130303231931.GD21318@stack.nl> Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Mar 2013 08:03:05 -0700 Message-ID: <1362582185.1291.106.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 15:03:10 -0000 On Mon, 2013-03-04 at 00:19 +0100, Jilles Tjoelker wrote: > There has long been a bug in sh(1) where it assumes (in mksyntax.c) that > the properties of char are the same between build and run environments. > This assumption does not hold if a cross build is done for arm on an x86 > machine. The main effect is that such a miscompiled sh incorrectly > handles characters with bit 7 set. Various tests in > tools/regression/bin/sh start failing, possibly in ways that eat huge > amounts of CPU time and memory. > > Christoph Mallon has submitted a fix for this and I have committed it to > head and stable/9. It has, however, only been tested on x86 using the > -funsigned-char compiler option to create the discrepancy. > > Below is a backport of the fix to stable/8. It needs r247733 or at least > the bin/sh/mksyntax.c of that revision. > > Because I had to fix some conflicts and stable/8's sh differs quite a > bit from head's, I would like to have some testing first before > committing this. I again tested only on amd64 with and without the > -funsigned-char compiler option and tools/regression/bin/sh. If the > cross-compilation need not be supported on stable/8, I am fine with > leaving it unfixed in stable/8. It took me a while to get an arm 8-stable environment running to test this. I'm cross-building arm from an i386 build machine running 8.3. Testing with 8-stable @ r247889 before applying your patch, I get two failures: not ok 12 - ./builtins/cd1.0 # wrong exit status not ok 98 - ./expansion/ifs3.0 # wrong exit status After applying your patch, only test 12 fails (still wrong exit status). The failure of test 12 looks like this in both cases: root@dpcur:/tmp/regression/bin/sh # sh -x builtins/cd1.0 + set -e + P=/tmp + cd /tmp + mktemp -d sh-test.XXXXXX + T=sh-test.TkJqGN + chmod 0 sh-test.TkJqGN + cd -L sh-test.TkJqGN + exit 1 If I launch sh and enter that series of commands interactively, the cd -L command returns a status of 0. Now that I've remembered the incantations for getting 8.x to run on my dreamplug I can test things pretty easily if you've got other changes. I also tested -current cross-built on the same machine (using gcc and oabi), and there are no failures there. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 15:57:02 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 674A28B5 for ; Wed, 6 Mar 2013 15:57:02 +0000 (UTC) (envelope-from jadcooper@yahoo.com) Received: from nm29-vm0.bullet.mail.bf1.yahoo.com (nm29-vm0.bullet.mail.bf1.yahoo.com [98.139.213.166]) by mx1.freebsd.org (Postfix) with ESMTP id 249272E3 for ; Wed, 6 Mar 2013 15:57:01 +0000 (UTC) Received: from [98.139.215.141] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 06 Mar 2013 15:56:54 -0000 Received: from [98.139.173.161] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 06 Mar 2013 15:56:54 -0000 Received: from [127.0.0.1] by smtp104-mob.biz.mail.bf1.yahoo.com with NNFMP; 06 Mar 2013 15:56:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362585414; bh=pX7OjN1yPIgTJRf96+rpFUIiVLCyOjlbf3FcaHNhju0=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=2q+NDeUYVaPOfbc6Z/kRAq9P1KZm+UZSmA6KIhppw1kftCo9ylCF+x1PfVVeHVsgDSkJOQ0BNWcdKjxFS7EStKuk5pNQ2rZD0QROZTOASTHE9x5m3rRR+nWDhLHwj8pBVaGOZS6F10OZBW9lMoxE3el0i+Dc2kMGNNvS3R4UKys= X-Yahoo-Newman-Id: 666001.27810.bm@smtp104-mob.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: By2D5OEVM1lbrwqun4sCyyLRZ7b84IaVch.DLOXTzUU9CjN JF2aH39D_dSOlIwS2yiV7BD1Wade6V7fp2QWHqMxBCwHJu.r72Q9oCUcdMVi lJC_RGEiAhbvLkzZeIl4GWhWxDwbh.meqLT6u5XtBwphiT4rrv7fD8QbrsJm B4fqNfdayslsDxI.JzkF43oYdK5YWs6HAlFFXLWU7uWtiQD.SYqSwzQdzro7 rLrWOv_REmFkG5UPJAYMlsHGsRVwI8b9y1U12iFV7q1mjMubwvJOs4fbEPi2 KKKFZKxufBVAOoVi8_CiIyzudQTB0JPQyX__xeyZcq9pB.chVOBAWqbpO0iX ALe.POahz.35UdqhhkD3REtA.BQAPDfUo8JmBaRIh8NxtoV7trqmbuqgYkn8 iL4hBBmEPW0R8DI.WC09194bfRn88aJCSRO1QV1D8SWglA6HyWFr1iO7bqGI mbc758vXlqVqxOQ-- X-Yahoo-SMTP: 1NwK1FqswBBIXmrGMynm9AQsKvKa_A-- Received: from [10.53.157.149] (jadcooper@198.228.194.248 with xymcookie) by smtp104-mob.biz.mail.bf1.yahoo.com with SMTP; 06 Mar 2013 07:56:54 -0800 PST References: <642BFD16-A5E3-447F-9C52-6855AB1E5CC4@yahoo.com> <1362524363.1291.51.camel@revolution.hippie.lan> <5136B2A3.4010701@ceetonetechnology.com> <20130306123945.60aff30773fdd0fb2707a635@ddteam.net> In-Reply-To: <20130306123945.60aff30773fdd0fb2707a635@ddteam.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <7198D3D7-AEFA-4054-8769-4B5E64C015D3@yahoo.com> X-Mailer: iPhone Mail (9B206) From: Jad Cooper Subject: Re: Raspberry Pi image and pkg_add, pkg etc Date: Wed, 6 Mar 2013 10:56:47 -0500 To: Aleksandr Rybalko Cc: "george@ceetonetechnology.com" , "freebsd-arm@freebsd.org" , Baptiste Daroussin , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 15:57:02 -0000 Hi all thanks for taking the time to reply. Indeed the packages are all available for ARM. When I delved into installing packages initially there were issues. These are specific to the rpi image. 1. The pkg_add works but wants to download packages from an armv6 dir that's= not in the public repo. 2. Since pkgng is the new manager , trying to get it bootstrapped fails, so a= manual build is necessary - downloading the txz and extracting it leaves i= t missing several libraries. 3. Once pkgng is setup and working the location of the repo has to be set ma= nually using the setenv packagesite 4. using pkgng I have to force install the packages. Most of us are technical but to a hobbyist this is a bit complex, these are t= he tools, files/condos I'd like to repair so that the image is immediately u= seful for RPI.=20 It's a great image already but I want to make it as simple as possible for s= tudents to get started with it.=20 Do I need to download the image source as tweak the c and header files?? Jad On Mar 6, 2013, at 5:39 AM, Aleksandr Rybalko wrote: On Tue, 05 Mar 2013 22:06:11 -0500 George Rosamond wrote: > On 03/05/13 17:59, Ian Lepore wrote: >> On Mon, 2013-03-04 at 12:20 -0500, Jad Cooper wrote: >>> Hi, I'd like to get involved in cleaning up/helping mature the >>> Freebsd Rasperry Pi image. It's a fantastic platform but some >>> things are broken especially the package manager as it seems to not >>> correctly resolve the FTP repository, or incorrectly looks for tzb >>> files or looks for a directory called ARMv6 when in fact the txz >>> files are in the ARM folder. >>>=20 >>> Please not this is my first such post so if the formatting or post >>> is in the wrong list, I do apologize in advance. >>>=20 >>> Jad >>=20 >> I don't think I quite understand your question, which is not too=20 >> surprising since I know almost nothing about ports and packages. I >> do want to make sure you get a response from someone who knows about >> these things; I've added one such person to the CC list. >>=20 >> One thing that confuses me about your question is the reference to >> the ftp repository... I don' think there are any arm packages being >> built and distributed by the FreeBSD project right now. Are you >> trying to set up your own local repository, or connect to a private >> one somewhere? >=20 > I think my read on this is: there is no default PACKAGESITE set for > pkgng in /usr/local/etc/pkg.conf for the builds, which means pkgng > doesn't work as it should, so Jad is offering to assist in resolving this.= >=20 > Cool, Jad. And you're on the right list, and my MUA sees your email fine!= >=20 > So there is no official package or port repository yet for FreeBSD arm Small correction: we have port repository for all platforms, only some ports can't be built for ARM. Some ports are binary and can't be installed due to lack of FreeBSD ARM distro. > architecture. A number of people are maintaining public yet individual > sites, but nothing official yet. >=20 > Whether or not you're a developer, jump aboard and look at Tim's and > Gonzo's scripts for start. >=20 > But start building images and customizing them. Play. Enjoy. And feel > free to jump in and ask questions. >=20 > g > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --=20 Aleksandr Rybalko _______________________________________________ freebsd-arm@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 16:31:40 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 86026215; Wed, 6 Mar 2013 16:31:40 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id E52296BB; Wed, 6 Mar 2013 16:31:39 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id z53so8266238wey.15 for ; Wed, 06 Mar 2013 08:31:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=ooRZNgVvIoG5adZW6Kk81hg21jf26h64IIvA4++hbv0=; b=eYRnLWV9wq9udj8lSOWzdbs/E+QXtDrbv65LuygXm5Tjvz5AfKSDtCsZ8+xjMLqROH 30QWyV9t2zl7yyDvOVDEQHq7KRpCJRK8BgM3gCwpiBznnq5Cny08UJ3Tdrw0V9cIgDfm eadpFS1PG1o+EXFo6rn8KWe0ZcEmkt5pldMaIWqewCO3688Kez6Eq7ZKEV6Opd48wYfR 2lE2b9mEHK2+bh9JNsFww7tfxuzw7mUbP07cQEa/QLfjMhS2Fkg77R3ZDMQ8oM5vI5/J zITIO/riDeu17copninM1xgrOAK1qQSSkKPjjj4mouKF1NUf+0FY35TtFknobgtOcZ9R m8TQ== X-Received: by 10.180.94.135 with SMTP id dc7mr27433001wib.11.1362587498485; Wed, 06 Mar 2013 08:31:38 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPS id bj9sm27856209wib.4.2013.03.06.08.31.36 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 06 Mar 2013 08:31:37 -0800 (PST) Sender: Baptiste Daroussin Date: Wed, 6 Mar 2013 17:31:35 +0100 From: Baptiste Daroussin To: Jad Cooper Subject: Re: Raspberry Pi image and pkg_add, pkg etc Message-ID: <20130306163135.GA45920@ithaqua.etoilebsd.net> References: <642BFD16-A5E3-447F-9C52-6855AB1E5CC4@yahoo.com> <1362524363.1291.51.camel@revolution.hippie.lan> <5136B2A3.4010701@ceetonetechnology.com> <20130306123945.60aff30773fdd0fb2707a635@ddteam.net> <7198D3D7-AEFA-4054-8769-4B5E64C015D3@yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <7198D3D7-AEFA-4054-8769-4B5E64C015D3@yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "george@ceetonetechnology.com" , Aleksandr Rybalko , "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 16:31:40 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 06, 2013 at 10:56:47AM -0500, Jad Cooper wrote: > Hi all thanks for taking the time to reply. >=20 > Indeed the packages are all available for ARM. Not on the FreeBSD side, we do not provide any packages for arm, may that be pkgng or the old pkg_install, where did you find any packages? > When I delved into installing packages initially there were issues. > These are specific to the rpi image. >=20 > 1. The pkg_add works but wants to download packages from an armv6 dir tha= t's not in the public repo. > 2. Since pkgng is the new manager , trying to get it bootstrapped fails, = so a manual build is necessary - downloading the txz and extracting it lea= ves it missing several libraries. To manually build pkgng the best is to use the ports tree which does everyt= hing needed for you. How does it leaves missing libraries and what libraries, I do myself usr pk= gng on a pandoboard with no problem you mean you have done the whole thing by h= and (picking the sources and building?). > 3. Once pkgng is setup and working the location of the repo has to be set= manually using the setenv packagesite It can also be specified via pkg.conf but this is only useful if you have a= ny repository available somewhere to make binary only installation > 4. using pkgng I have to force install the packages. I don't get this one? can you give more details? >=20 > Most of us are technical but to a hobbyist this is a bit complex, these a= re the tools, files/condos I'd like to repair so that the image is immediat= ely useful for RPI.=20 >=20 > It's a great image already but I want to make it as simple as possible fo= r students to get started with it.=20 >=20 > Do I need to download the image source as tweak the c and header files?? Use the ports tree until we are able to create an arm build cluster, or use= some of the third party package repositories available out there (sorry I have no link for arm, just know that it does exists :) Bapt --AhhlLboLdkugWU4S Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlE3b2cACgkQ8kTtMUmk6EzUAgCgs4T+sOojuT6UpWxpgAnEfL9X E+8AoI+0VSHazHTaezkWG5040rSx2QJh =6D96 -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 17:03:32 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A3C2F7F6 for ; Wed, 6 Mar 2013 17:03:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by mx1.freebsd.org (Postfix) with ESMTP id 63373813 for ; Wed, 6 Mar 2013 17:03:32 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id k1so12854043oag.19 for ; Wed, 06 Mar 2013 09:03:31 -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=snkWLHm0PmZJLcZVGIAAt+GypHn392iPX/MTB8NIbu0=; b=GuhrmLMVPpzQKoW9cSRPpqwHAff8/bbH+ar/3nmSkATFFYNRwktkCGpjhYjfztzEhR NRO4Gm3lbyqx8KJY7n69RwMMVHQuO8taoDwxFfJk97SZ7AbmKVN/HVqb1kZFEDUCldl9 m5MSvh7Gvw75UdouWzi6Ut3zyl7JJ2cDsi2fXqQmNJchgv/chb1iosNfRO1Ul+wdRr1u aEj2jkfg2j72mGtneAY2FNIAXVOvrUDvc8Mf4mBkTvqkf1IZTk6EsXNR5Bj5cPn8nnW/ OWEGCkJ06dwgbRUWTztITUrI5TYlFZin3eVGVNOdIG/tWW9HDuhmr5o0xIVUN4RZ/HCv B8cA== X-Received: by 10.60.3.10 with SMTP id 10mr24049156oey.61.1362589411761; Wed, 06 Mar 2013 09:03:31 -0800 (PST) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id ad19sm39507352oec.0.2013.03.06.09.03.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 09:03:30 -0800 (PST) Sender: Warner Losh Subject: Re: GENERIC kernel issues Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1362542286.1291.94.camel@revolution.hippie.lan> Date: Wed, 6 Mar 2013 10:03:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> References: <1362445777.1195.299.camel@revolution.hippie.lan> <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> <1362542286.1291.94.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlUhemW/lklDlfeJjhEaNnNzE1pYQJSOPDOkhLYxJOFVtchfbwDHg+i+PD7kMAzJD4pjwHL Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:03:32 -0000 On Mar 5, 2013, at 8:58 PM, Ian Lepore wrote: > On Mon, 2013-03-04 at 21:30 -0700, Warner Losh wrote:=20 >> On Mar 4, 2013, at 6:09 PM, Ian Lepore wrote: >>> On Sun, 2013-03-03 at 11:43 -0800, Tim Kientzle wrote: >>>>=20 >>>> ** PHYSADDR/KERNPHYSADDR hardwiring. Ian has made a >>>> lot of progress and I'm working on some related changes to >>>> address this. I think we understand how to eliminate these >>>> constants and replace them with run-time detection of the >>>> load address. I'm still not sure what changes might be needed >>>> to the loader to make this work.=20 >>>=20 >>> I don't think anything more needs to be done to the loader to be = able to >>> load a kernel built with the ldscript changes, beyond the change I = did a >>> week or two ago to make it work right with elf headers that contain >>> physical addresses. >>>=20 >>> On the other hand, I haven't got anything to offer on the problem of = the >>> loader needing to be linked differently for each board or SoC, since >>> they all have physical memory in differing address ranges. >>=20 >> Well, the Phyiscal memory load address is just a hint after all. Any = way to leave it blank and have ubldr cope by putting it in the first = available phyiscal memory slot from the FDT? >>=20 >> Warner >>=20 >=20 > It's not just a hint, the executable is linked to run at that address > and no other. There is no relocation info in the file at all. That's > true of both the kernel and ubldr. It's also true of any old > static-linked executable, but in that case the object is just mapped = at > the virtual address it's linked for by the kern/imgact_elf.c code. It is just a hint, since we can load it at any physical address. Well, = almost any. But we can get the almost from the virtual part. > We essentially pull off the same mapping trick with the kernel, except > that very early in locore.s the code is carefully crafted to work = right > whether on physical or virtual addressing, just long enough to get the > MMU turned off. Then it sets up page tables to map the physical pages > the kernel has been loaded into to match the virtual addresses it was > linked for. All of that only works if the low-order bits of the = virtual > address it was linked for match the physical address it was loaded at. > That is, if linked for 0xC0001000 it must be loaded at 0xNNNN1000 > physical, where the N bits can be anything. Right, but can't we get that from the virtual address. > Unfortunately, I don't think we can pull the same kind of trick with > ubldr. In locore.s for the kernel we build simple page tables which = are > just enough to get us to the code in initarm() that builds them for > real. No SoC-specific stuff has to happen along the way (or if it = does, > SoC-specific code is invoked via various hooks to board support > routines). In ubldr we mess with the hardware (via the u-boot = drivers), > so if we turn on the MMU to map the memory ubldr is running from, we > also have to map the hardware va=3Dpa for those drivers to work. I = don't > know that there's any way to get the needed info for that from u-boot. So long as the code is PIC up until the time we turn on the MMU, then = we're fine. We can and should still do this in locore.S. I guess I'm being dense this morning.. I'm not sure I understand what = the big deal is... Warner From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 17:08:04 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3752A90F for ; Wed, 6 Mar 2013 17:08:04 +0000 (UTC) (envelope-from ThomasSkibo@sbcglobal.net) Received: from nm10.access.bullet.mail.sp2.yahoo.com (nm10.access.bullet.mail.sp2.yahoo.com [98.139.44.137]) by mx1.freebsd.org (Postfix) with ESMTP id DD3F0838 for ; Wed, 6 Mar 2013 17:08:03 +0000 (UTC) Received: from [98.139.44.102] by nm10.access.bullet.mail.sp2.yahoo.com with NNFMP; 06 Mar 2013 17:08:03 -0000 Received: from [67.195.14.95] by tm7.access.bullet.mail.sp2.yahoo.com with NNFMP; 06 Mar 2013 17:08:03 -0000 Received: from [127.0.0.1] by smtp110.sbc.mail.gq1.yahoo.com with NNFMP; 06 Mar 2013 17:08:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1362589683; bh=d4eY1qJruM0QO5w53HO4WXklaAYQS8kWwlDx3ZmrMoc=; 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:Content-Transfer-Encoding; b=R5NwxLQmPxiZZE1n+zI2El4DuY8tf+C9zpwsM94dHbHslYl4NwQSIgmS55ADcXhZp7y17HRhIuaPdU8Yul8G+NgM9LGZmWDmySsytMggtkslNbD1Ojqep39JuFx9mTysm0Uy2hXJ33Ivup0M8FC8INaAf6V/r+2lYGf0yumGDj4= X-Yahoo-Newman-Id: 280673.56747.bm@smtp110.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 0FuQ80cVM1neGgOuWfmFqUCB5bQ3R1MIizyd0Rf2ERtGXcx sWx4bYmfckjVAV1pHG5Di2hupFaMH0GrtoHuagyQk5WRYFjJvk5_rsfqjz6i DbQsOypHOvFGv0GL4ZFFJ7wqJc_pFxM6DjU8xaOQ.EcwTv4Qj5Zun3LupYlI lI7nItLjfwCuvyEUyiflpqwZryTKBxVFyC2IXJEL.vdR.Usjz2IAzQhurJIs 4paQBIJZz5pkLN3f1RXX0bjhP2C09bgwnnNUZfTLqkE5gjah.kXN1PneZjBN 20e_0CaRh49UY.56.EKDk2mthYm6UWhODGEc.gCFnvuHJinxo_K0FbM7RL03 q3C3Uz_pyxlfvo4PyD9qJUTHJOm2CRN58I_.SJzlN8SOHXedD6tDPdFos1vk WBraIz_1j.2SmHsqjv6mumpIotax3fMCUa9Oq60orhznaYvJD3y8LC3UKzKK qP0CYAjr2zGp2zI7ws2ZDqfqaGlWKx2kI5iYMgUX65P28mAIf1_lWFyt8TA- - X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- Received: from [192.168.1.9] (ThomasSkibo@71.139.174.219 with plain) by smtp110.sbc.mail.gq1.yahoo.com with SMTP; 06 Mar 2013 09:08:03 -0800 PST Message-ID: <513777F4.60302@sbcglobal.net> Date: Wed, 06 Mar 2013 09:08:04 -0800 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Weird kernel mode data abort panic on Zedboard. References: <51354125.4060500@sbcglobal.net> <51358BEB.50603@sbcglobal.net> In-Reply-To: <51358BEB.50603@sbcglobal.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:08:04 -0000 On 3/4/13 10:08 PM, Thomas Skibo wrote: > > Oleksandr Tymoshenko : >> >> Just a hunch here - looks like TLB entry is not update properly. Might >> be missing >> PTE_SYNC in pmap-v6.c. Or current PTE_SYNC implementation does not cover >> all requirements for your platform. I'd say latter - but without proper >> debugging >> it's just guesswork. >> > > Thanks. On my platform, PMAP_NEEDS_PTE_SYNC was 0 and I convinced > myself earlier that the page tables were properly configured with > write-through caching and didn't need PTE_SYNC() anyway. I've had a chance to look at this some more. According to the Cortex-A9 manual, when the MMU is configured for write-through cacheing, it goes directly to external memory to read the page-table. So, PMAP_NEEDS_PTE_SYNC=0 is correct for my platform but I need PTE_SYNC() for the call to cpu_drain_writebuf(). I looked around again for missing PTE_SYNC()s and the only thing suspicious to me is that vector_page_setprot() doesn't have one. I think when I forced PMAP_NEEDS_PTE_SYNC to 1, the (unnecessary) cache ops just changed the timing of some kind of race condition somewhere else. I'll try to see what the other threads are doing when it crashes. THanks, -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 17:36:31 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2CE24442; Wed, 6 Mar 2013 17:36:31 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) 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 11E5F9F0; Wed, 6 Mar 2013 17:36:30 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r26HaMqc087977; Wed, 6 Mar 2013 17:36:22 GMT (envelope-from kientzle@FreeBSD.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id xfachhn3is8qhitkuyuutk7b72; Wed, 06 Mar 2013 17:36:22 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Subject: Re: GENERIC kernel issues Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> Date: Wed, 6 Mar 2013 09:36:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1362445777.1195.299.camel@revolution.hippie.lan> <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> <1362542286.1291.94.camel@revolution.hippie.lan> <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:36:31 -0000 >>>>=20 >>>> On the other hand, I haven't got anything to offer on the PROBLEM = OF >>>> THE LOADER needing to be linked differently for each board or SoC, = since >>>> they all have physical memory in differing address ranges. >>>=20 >>> Well, the Phyiscal memory load address is just a hint after all. Any = way to leave it blank and have ubldr cope by putting it in the first = available phyiscal memory slot from the FDT? >>>=20 >>> Warner >>>=20 >>=20 >> It's not just a hint, the executable is linked to run at that address >> and no other. There is no relocation info in the file at all. = That's >> true of both the kernel and ubldr. It's also true of any old >> static-linked executable, but in that case the object is just mapped = at >> the virtual address it's linked for by the kern/imgact_elf.c code. >=20 > It is just a hint, since we can load it at any physical address. = Well, almost any. But we can get the almost from the virtual part. >=20 >> We essentially pull off the same mapping trick with the kernel, = except >> that very early in locore.s the code is carefully crafted to work = right >> whether on physical or virtual addressing, just long enough to get = the >> MMU turned off. Then it sets up page tables to map the physical = pages >> the kernel has been loaded into to match the virtual addresses it was >> linked for. All of that only works if the low-order bits of the = virtual >> address it was linked for match the physical address it was loaded = at. >> That is, if linked for 0xC0001000 it must be loaded at 0xNNNN1000 >> physical, where the N bits can be anything. >=20 > Right, but can't we get that from the virtual address. >=20 >> Unfortunately, I don't think we can pull the same kind of trick with >> UBLDR. In locore.s for the kernel we build simple page tables which = are >> just enough to get us to the code in initarm() that builds them for >> real. No SoC-specific stuff has to happen along the way (or if it = does, >> SoC-specific code is invoked via various hooks to board support >> routines). In UBLDR we mess with the hardware (via the u-boot = drivers), >> so if we turn on the MMU to map the memory UBLDR is running from, we >> also have to map the hardware va=3Dpa for those drivers to work. I = don't >> know that there's any way to get the needed info for that from = u-boot. >=20 > So long as the code is PIC up until the time we turn on the MMU, then = we're fine. We can and should still do this in locore.S. >=20 > I guess I'm being dense this morning.. I'm not sure I understand what = the big deal is=85 Ian is NOT talking about the kernel here. He's talking about UBLDR, which is an ELF image loaded by U-Boot. The techniques used for the kernel (which we all agree on and which Ian has partly implemented already) don't seem to be applicable here. (I don't want to change U-Boot's ELF loader, nor should UBLDR be messing with the MMU.) So we're stuck for now with linking UBLDR separately for each memory address at which UBLDR gets run. The obvious answer is to have UBLDR be a static PIC binary and not ELF. If you see another approach, I'm interested. Tim From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 17:40:38 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C11BF555 for ; Wed, 6 Mar 2013 17:40:38 +0000 (UTC) (envelope-from jadcooper@yahoo.com) Received: from nm15-vm0.bullet.mail.bf1.yahoo.com (nm15-vm0.bullet.mail.bf1.yahoo.com [98.139.212.254]) by mx1.freebsd.org (Postfix) with SMTP id 6DF6CA4B for ; Wed, 6 Mar 2013 17:40:38 +0000 (UTC) Received: from [98.139.212.146] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 06 Mar 2013 17:40:37 -0000 Received: from [98.139.173.184] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 06 Mar 2013 17:40:37 -0000 Received: from [127.0.0.1] by smtp111-mob.biz.mail.bf1.yahoo.com with NNFMP; 06 Mar 2013 17:40:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362591637; bh=Cr8/7S4zV7YqBxl5QBZNkwfyoq/WP4t8sDk4DGxGJq4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=fccbbJjNX/oZXrPu5hF1TfhawbYevLibdS2HeMD5csHCQeqHbkT8J8/t6VMZqDEvDBTW+qOeekB/y72v2ob0vAuPFOEM8kf55cqVDCoWFMUI72Bguj2tenNFen/0d6iv10n521KJXxMnC4X/gN521bjn1rye1MoJ+C8mD5wOocc= X-Yahoo-Newman-Id: 72860.5962.bm@smtp111-mob.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: FvVb6x8VM1mj0n8sxTIIIq2_oOTz9Iymq3a_Va4dx7WrMAl 1XFsSDdf34kHEElXsOMmDMdfMOwJqD_A3_5hIbqiVMnUoeycUSYieAhSfIgc twTGCReuwZS7LtS3ss9.EbA7BQGUxBpRby26FeqpyAsmxa1PXsU_bOqZKHkZ ODZoTtzIv0YfZJodcJqYSi6IDuTHoDU_iMVcS9fI.IcvmorIY9INKRzAuHRD F9e_kz4MAMLxBLIXYWV_uBB4oqvLO4fUhlGHrlpIK1a43Ua6XrXpPS5bE0jM 5vlfTHbOeme7lt4om8euZZzYD7e3sjW9PyFZ7loRYkb1j4CpHcpjtVrf9fMx 1KDzZiRBBedEztjpt8W.MH2W3Zo61H7RsypT8IPAJ1LIgu4N.cHQ_If3DDTG aUliAaoQoDQJm6MYfNOn0_bboXGNQ9p0So4KKFLfl9rOrZg47pFSLiLrdKhO abds5.REoABM- X-Yahoo-SMTP: 1NwK1FqswBBIXmrGMynm9AQsKvKa_A-- Received: from [192.168.1.103] (jadcooper@68.161.233.84 with xymcookie) by smtp111-mob.biz.mail.bf1.yahoo.com with SMTP; 06 Mar 2013 09:40:36 -0800 PST References: <642BFD16-A5E3-447F-9C52-6855AB1E5CC4@yahoo.com> <1362524363.1291.51.camel@revolution.hippie.lan> <5136B2A3.4010701@ceetonetechnology.com> <20130306123945.60aff30773fdd0fb2707a635@ddteam.net> <7198D3D7-AEFA-4054-8769-4B5E64C015D3@yahoo.com> <20130306163135.GA45920@ithaqua.etoilebsd.net> In-Reply-To: <20130306163135.GA45920@ithaqua.etoilebsd.net> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (9B206) From: Jad Cooper Subject: Re: Raspberry Pi image and pkg_add, pkg etc Date: Wed, 6 Mar 2013 12:40:34 -0500 To: Baptiste Daroussin Cc: "george@ceetonetechnology.com" , Aleksandr Rybalko , "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:40:38 -0000 On Mar 6, 2013, at 11:31 AM, Baptiste Daroussin wrote: > On Wed, Mar 06, 2013 at 10:56:47AM -0500, Jad Cooper wrote: >> Hi all thanks for taking the time to reply. >>=20 >> Indeed the packages are all available for ARM. >=20 > Not on the FreeBSD side, we do not provide any packages for arm, may that b= e > pkgng or the old pkg_install, where did you find any packages? I found the .txz files ftp://ftp.freebsd.org/pub/FreeBSD/ports/arm/packages=20 The file I use with pkgng is the repo.txz file in that directory -=20 >=20 >> When I delved into installing packages initially there were issues. >> These are specific to the rpi image. >>=20 >> 1. The pkg_add works but wants to download packages from an armv6 dir tha= t's not in the public repo. >> 2. Since pkgng is the new manager , trying to get it bootstrapped fails, s= o a manual build is necessary - downloading the txz and extracting it leave= s it missing several libraries. > To manually build pkgng the best is to use the ports tree which does every= thing > needed for you. >=20 > How does it leaves missing libraries and what libraries, I do myself usr p= kgng > on a pandoboard with no problem you mean you have done the whole thing by h= and > (picking the sources and building?). >=20 Yes I downloaded the source from github and built it using make etc >> 3. Once pkgng is setup and working the location of the repo has to be set= manually using the setenv packagesite > It can also be specified via pkg.conf but this is only useful if you have a= ny > repository available somewhere to make binary only installation >=20 I have the repo as above - the problem is that the pkg.conf file isn't in th= e image... >> 4. using pkgng I have to force install the packages. >=20 > I don't get this one? can you give more details? When I do "pkg install curl" for example=20 It resolves the package but when it tries to install it complains that the v= ersion is not correct, saying that the version is incorrect built for 9 but n= ot 10the exact output I don't have - but=20 "pkg install -f curl" works it just forces it to install - and curl then wor= ks=20 >>=20 >> Most of us are technical but to a hobbyist this is a bit complex, these a= re the tools, files/condos I'd like to repair so that the image is immediate= ly useful for RPI.=20 >>=20 >> It's a great image already but I want to make it as simple as possible fo= r students to get started with it.=20 >>=20 >> Do I need to download the image source as tweak the c and header files?? >=20 > Use the ports tree until we are able to create an arm build cluster, or us= e some > of the third party package repositories available out there (sorry I have n= o > link for arm, just know that it does exists :) >=20 Isn't that FTP directory the ARM repo?? Maybe I'm missing some very fundamental FreeBSD insight but the FTP folders a= bove contain the compressed binary packages for almost everything - even wit= hout pkgng or pkg_add I could install most using=20 tar - zxvPf package.txz , granted I had a lot of missing dependencies but ye= ah the ARM bins are all there I thought... From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 17:51:50 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B9347AA9 for ; Wed, 6 Mar 2013 17:51:50 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 832B0AED for ; Wed, 6 Mar 2013 17:51:50 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id x4so3739583obh.16 for ; Wed, 06 Mar 2013 09:51:50 -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=i1Zh0/QzyOGcCH/D2DK5PaxHaHzS9qtGG/nslgg5rjQ=; b=bfqxAQpbnr0bJxBXaJMsYJOrWC+5rBMjGgC8kkOlncNzq3nipBLtTE16lqFVRGrEX2 vd2NFnD4+zAlWQP2pmQfU0JOpxkci+O0o5pSj5COKyXnRnrHqhIO1ZgTVqy5nWWP2YGE QzmAAOM6DbR5mDWsrhY40eptisjSC94kp1b+jS3CXapd1ia+4vSwnwe9ZaQ8Q3/3hluo O4OJdwdbkA0UVtmRDdY6eEezkgOmlTkQ0MSR2WIZChKv9ifJSezFOQi5jchihFwGdLIy Ii79EwrYFuHG7KDiEA3+AkoK34FJFmWjfvrx+xgXAil2JUYVpAEspnLawO6T+qIJ6/Wr Outw== X-Received: by 10.60.10.102 with SMTP id h6mr23276818oeb.14.1362592310078; Wed, 06 Mar 2013 09:51:50 -0800 (PST) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id ri1sm38496653obc.12.2013.03.06.09.51.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 09:51:48 -0800 (PST) Sender: Warner Losh Subject: Re: GENERIC kernel issues Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: Date: Wed, 6 Mar 2013 10:51:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1362445777.1195.299.camel@revolution.hippie.lan> <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> <1362542286.1291.94.camel@revolution.hippie.lan> <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlEO4o6mm/Rhzq5Fd0Js3bqC9ewT2D3FMH/smXLSR8kN+r2tSlTq4qk/wm8a76unwzVaW4N Cc: freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:51:50 -0000 On Mar 6, 2013, at 10:36 AM, Tim Kientzle wrote: >>>>>=20 >>>>> On the other hand, I haven't got anything to offer on the PROBLEM = OF >>>>> THE LOADER needing to be linked differently for each board or SoC, = since >>>>> they all have physical memory in differing address ranges. >>>>=20 >>>> Well, the Phyiscal memory load address is just a hint after all. = Any way to leave it blank and have ubldr cope by putting it in the first = available phyiscal memory slot from the FDT? >>>>=20 >>>> Warner >>>>=20 >>>=20 >>> It's not just a hint, the executable is linked to run at that = address >>> and no other. There is no relocation info in the file at all. = That's >>> true of both the kernel and ubldr. It's also true of any old >>> static-linked executable, but in that case the object is just mapped = at >>> the virtual address it's linked for by the kern/imgact_elf.c code. >>=20 >> It is just a hint, since we can load it at any physical address. = Well, almost any. But we can get the almost from the virtual part. >>=20 >>> We essentially pull off the same mapping trick with the kernel, = except >>> that very early in locore.s the code is carefully crafted to work = right >>> whether on physical or virtual addressing, just long enough to get = the >>> MMU turned off. Then it sets up page tables to map the physical = pages >>> the kernel has been loaded into to match the virtual addresses it = was >>> linked for. All of that only works if the low-order bits of the = virtual >>> address it was linked for match the physical address it was loaded = at. >>> That is, if linked for 0xC0001000 it must be loaded at 0xNNNN1000 >>> physical, where the N bits can be anything. >>=20 >> Right, but can't we get that from the virtual address. >>=20 >>> Unfortunately, I don't think we can pull the same kind of trick with >>> UBLDR. In locore.s for the kernel we build simple page tables which = are >>> just enough to get us to the code in initarm() that builds them for >>> real. No SoC-specific stuff has to happen along the way (or if it = does, >>> SoC-specific code is invoked via various hooks to board support >>> routines). In UBLDR we mess with the hardware (via the u-boot = drivers), >>> so if we turn on the MMU to map the memory UBLDR is running from, we >>> also have to map the hardware va=3Dpa for those drivers to work. I = don't >>> know that there's any way to get the needed info for that from = u-boot. >>=20 >> So long as the code is PIC up until the time we turn on the MMU, then = we're fine. We can and should still do this in locore.S. >>=20 >> I guess I'm being dense this morning.. I'm not sure I understand what = the big deal is=85 >=20 > Ian is NOT talking about the kernel here. >=20 > He's talking about UBLDR, which is an ELF image > loaded by U-Boot. >=20 > The techniques used for the kernel (which we > all agree on and which Ian has partly implemented > already) don't seem to be applicable here. (I don't want > to change U-Boot's ELF loader, nor should UBLDR > be messing with the MMU.) >=20 > So we're stuck for now with linking UBLDR separately > for each memory address at which UBLDR gets run. > The obvious answer is to have UBLDR be a static PIC > binary and not ELF. If you see another approach, I'm > interested. OK. I'm back with you now, and I agree. ubldr does run in PA, and what = I've said don't apply... Unless we make ubldr PIC, so I think we're on = the same page here... We could create our own mapping, but we'd have to totally trash that = just before jumping to the kernel, which I'm at best luke warm to since = that kind of code has to be in assembler... I think that static PIC = binary would be easier... Warner= From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 18:06:01 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F2C6CEF2; Wed, 6 Mar 2013 18:06:00 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id 4DEA6C2B; Wed, 6 Mar 2013 18:06:00 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id t44so8498899wey.40 for ; Wed, 06 Mar 2013 10:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=EyzcNWzuF7LGKmg4vdeDcFUdvS8ZctY+Aq+/bzvDZ6k=; b=tfA/BmemXaFKHidZyb+aOmtdhBcvA6UqAzYmxXl3ts4keiGTO5Oxe7qHlVk3BCzzrw im2rWT6f97ZAUQTcQ0EyEHpFDmjhMM17pBtUSZ7pjfM9RZalL/VVNrCDZkplffSUBZwj uqZ+3AmZoNapODWyEw0jS1aXeFPxniJenGNOqGFVTt9f1QEEOuks2+8bQ9jPSsK0wlKd uufUUs4ay3aM3zDqRELkMgAL/iGvDKFbQcFoTPDSNYlnE7dSxgATIjJf+4kkmBF4mjko lVfo1CcYGghQmuit46uW00a3ZnWTQUYnICqpclKGkQyhPG0xeb+m2bpz59ouB8Sds6SU SZ1A== X-Received: by 10.180.8.4 with SMTP id n4mr27982111wia.13.1362593158173; Wed, 06 Mar 2013 10:05:58 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPS id bs6sm31138197wib.4.2013.03.06.10.05.56 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 06 Mar 2013 10:05:57 -0800 (PST) Sender: Baptiste Daroussin Date: Wed, 6 Mar 2013 19:05:55 +0100 From: Baptiste Daroussin To: Jad Cooper Subject: Re: Raspberry Pi image and pkg_add, pkg etc Message-ID: <20130306180555.GI18971@ithaqua.etoilebsd.net> References: <642BFD16-A5E3-447F-9C52-6855AB1E5CC4@yahoo.com> <1362524363.1291.51.camel@revolution.hippie.lan> <5136B2A3.4010701@ceetonetechnology.com> <20130306123945.60aff30773fdd0fb2707a635@ddteam.net> <7198D3D7-AEFA-4054-8769-4B5E64C015D3@yahoo.com> <20130306163135.GA45920@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2xeD/fx0+7k8I/QN" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "george@ceetonetechnology.com" , Aleksandr Rybalko , "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 18:06:01 -0000 --2xeD/fx0+7k8I/QN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 06, 2013 at 12:40:34PM -0500, Jad Cooper wrote: >=20 > On Mar 6, 2013, at 11:31 AM, Baptiste Daroussin wrote: >=20 > > On Wed, Mar 06, 2013 at 10:56:47AM -0500, Jad Cooper wrote: > >> Hi all thanks for taking the time to reply. > >>=20 > >> Indeed the packages are all available for ARM. > >=20 > > Not on the FreeBSD side, we do not provide any packages for arm, may th= at be > > pkgng or the old pkg_install, where did you find any packages? > I found the .txz files > ftp://ftp.freebsd.org/pub/FreeBSD/ports/arm/packages=20 > The file I use with pkgng is the repo.txz file in that directory -=20 Oh I forgot about those one, but they are very old and build on a 9.x box. > >=20 > >> When I delved into installing packages initially there were issues. > >> These are specific to the rpi image. > >>=20 > >> 1. The pkg_add works but wants to download packages from an armv6 dir = that's not in the public repo. > >> 2. Since pkgng is the new manager , trying to get it bootstrapped fail= s, so a manual build is necessary - downloading the txz and extracting it = leaves it missing several libraries. > > To manually build pkgng the best is to use the ports tree which does ev= erything > > needed for you. > >=20 > > How does it leaves missing libraries and what libraries, I do myself us= r pkgng > > on a pandoboard with no problem you mean you have done the whole thing = by hand > > (picking the sources and building?). > >=20 >=20 > Yes I downloaded the source from github and built it using make etc Meaning you are now running on the master code which can easily be broken (branch release-1.0 for stable things) >=20 >=20 > >> 3. Once pkgng is setup and working the location of the repo has to be = set manually using the setenv packagesite > > It can also be specified via pkg.conf but this is only useful if you ha= ve any > > repository available somewhere to make binary only installation > >=20 >=20 > I have the repo as above - the problem is that the pkg.conf file isn't in= the image... Nope because 1.0b16 is really old and buggy for pkgng >=20 >=20 > >> 4. using pkgng I have to force install the packages. > >=20 > > I don't get this one? can you give more details? >=20 > When I do "pkg install curl" for example=20 >=20 > It resolves the package but when it tries to install it complains that th= e version is not correct, saying that the version is incorrect built for 9 = but not 10the exact output I don't have - but=20 >=20 > "pkg install -f curl" works it just forces it to install - and curl then = works=20 Sure you are trying to install package build on a FreeBSD 9 into a FreeBSD = 10. curl works just because you got some compatibility bit able to use FreeBSD 9 binaries but if one of the base library ABI has changed since 9 it would ha= ve been broken >=20 > >>=20 > >> Most of us are technical but to a hobbyist this is a bit complex, thes= e are the tools, files/condos I'd like to repair so that the image is immed= iately useful for RPI.=20 > >>=20 > >> It's a great image already but I want to make it as simple as possible= for students to get started with it.=20 > >>=20 > >> Do I need to download the image source as tweak the c and header files= ?? > >=20 > > Use the ports tree until we are able to create an arm build cluster, or= use some > > of the third party package repositories available out there (sorry I ha= ve no > > link for arm, just know that it does exists :) > >=20 > Isn't that FTP directory the ARM repo?? Somehow :), but I do not recommand to use it :) >=20 > Maybe I'm missing some very fundamental FreeBSD insight but the FTP folde= rs above contain the compressed binary packages for almost everything - eve= n without pkgng or pkg_add I could install most using=20 > tar - zxvPf package.txz , granted I had a lot of missing dependencies but= yeah the ARM bins are all there I thought... Yes the pkgng format has been made that way, so if pkgng itself break a sim= ple tar xvpf can save you :) regards, Bapt --2xeD/fx0+7k8I/QN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlE3hYMACgkQ8kTtMUmk6Ew73ACdFtnCV3b4tVcQ1751m3wllBDG sR8An0Cr5Vf3pCTpCBmc59aSC8gaEVpJ =f/Mt -----END PGP SIGNATURE----- --2xeD/fx0+7k8I/QN-- From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 19:33:18 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B63AEE59 for ; Wed, 6 Mar 2013 19:33:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by mx1.freebsd.org (Postfix) with ESMTP id 6A4BF179 for ; Wed, 6 Mar 2013 19:33:17 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id j6so13306239oag.36 for ; Wed, 06 Mar 2013 11:33:17 -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=6rCackKKNBCzrY8GXZuP5LlcA8l9Rr01aHQ3X9CR2/w=; b=L6LRLY9y1AI71i7qL6cK7M7iE7ZPSUy997Rf3x8OiVQbVip9IaB00mgvLDdKHbC2pe lZKV8iPO2stZAnQKe7qVmEzxBK8g/zCRVgjVOL4g2Q8jMlv64uV+ANy9OafEvwyH/Jpr QMxDDowg9kjapUZXAudr0grKVKBo8P8gBoTWYGaJSYJ5A3J2FOi1wCrUrw6/irIq/KR3 MAk67CH64NslNqkCQVHMUq8HrpOcMyEGFAQB2bQYzVg2W4t1h6UVzgSgVwAV2h+6Ph2y NF2Rzn4O4oL9xtkPqENgAn2dG3axLdZVj9/6WWWmE5U+cyLKdzyi9DL04TkrQvBvnWD7 /r0g== X-Received: by 10.60.25.35 with SMTP id z3mr23339942oef.98.1362598396725; Wed, 06 Mar 2013 11:33:16 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id ri1sm38827181obc.12.2013.03.06.11.33.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 11:33:15 -0800 (PST) Sender: Warner Losh Subject: Re: GENERIC kernel issues Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1362594744.1291.132.camel@revolution.hippie.lan> Date: Wed, 6 Mar 2013 12:33:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1362445777.1195.299.camel@revolution.hippie.lan> <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> <1362542286.1291.94.camel@revolution.hippie.lan> <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> <1362594744.1291.132.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnxAJC8oHxW1WfkeNoq4e6Ydfc/y2oPYLbq8Y7ZO/BxzconriaKKSHPvQcFJz/aDQuaUyg4 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 19:33:18 -0000 On Mar 6, 2013, at 11:32 AM, Ian Lepore wrote: > On Wed, 2013-03-06 at 10:03 -0700, Warner Losh wrote: >> On Mar 5, 2013, at 8:58 PM, Ian Lepore wrote: > [...] >>> We essentially pull off the same mapping trick with the kernel, = except >>> that very early in locore.s the code is carefully crafted to work = right >>> whether on physical or virtual addressing, just long enough to get = the >>> MMU turned off. Then it sets up page tables to map the physical = pages >>> the kernel has been loaded into to match the virtual addresses it = was >>> linked for. All of that only works if the low-order bits of the = virtual >>> address it was linked for match the physical address it was loaded = at. >>> That is, if linked for 0xC0001000 it must be loaded at 0xNNNN1000 >>> physical, where the N bits can be anything. >>=20 >> Right, but can't we get that from the virtual address. >=20 > Not always. You can always figure out the right virtual address if = you > have the physical (you just OR-in 0xC0000000), but you can't always go > the other way. If all you know is 0xC0010000 you have no idea whether > the underlying physical address might be 0x00010000 or 0x80010000. = Our > current code that assumes you can do phys=3Dpc&0xf0000000 is wrong for = the > same reason (but has been working okay by accident). The phys segment is pc & 0xf0000000 before you turn on the MMU (assuming = 256MB chip select offsets, adding another F would get that down to 16MB = chip selects, which is definitely good enough). After we MMU start, it = isn't, and our code shouldn't do that, unless it is followed by oring in = the physical segment... > That's part of why I've been working towards getting our arm ldscript = to > put proper physical addresses in the elf headers instead of virtual, = in > the fields that are supposed to have phsyical addresses in them (entry > and program-header paddr fields). But that doesn't matter for the kernel so much... > With this scheme SoC-specific kernels will be linked with PHYSADDR=3D = the > real physical address and can be loaded by any standard elf loader > because the headers are correct. A generic kernel will be linked with > PHYSADDR=3Doffset where offset is just the low-order part of the = address > and ubldr can load the kernel into whatever physical memory is = available > as long as the offset part stays the same. OK. That part makes perfect sense now. Warner= From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 20:16:20 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BA820AD5 for ; Wed, 6 Mar 2013 20:16:20 +0000 (UTC) (envelope-from jadcooper@yahoo.com) Received: from nm37-vm5.bullet.mail.bf1.yahoo.com (nm37-vm5.bullet.mail.bf1.yahoo.com [72.30.238.205]) by mx1.freebsd.org (Postfix) with ESMTP id 5F5F939C for ; Wed, 6 Mar 2013 20:16:20 +0000 (UTC) Received: from [98.139.212.145] by nm37.bullet.mail.bf1.yahoo.com with NNFMP; 06 Mar 2013 20:09:47 -0000 Received: from [98.139.173.172] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 06 Mar 2013 20:09:47 -0000 Received: from [127.0.0.1] by smtp101-mob.biz.mail.bf1.yahoo.com with NNFMP; 06 Mar 2013 20:09:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362600587; bh=nYQX+F395R4XItOQlMmjwT7eequVuY8ceojWbW9X3aw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=bLoC+H370C5q+Mbtk5Dqs8ZVkGYsHENhRtW80J7ertxnarTYkrfy4RR06hjEMHH4DrdRFrAks+H+bPXcPLd518uKOUtUUS4YBZFn7H5G984ZVc6Z2LzLgEcfW8+eJJYUEouhaAKwjytS/y/k8SeJ3Zuz3sx1tf1Oht6FRd+YMjg= X-Yahoo-Newman-Id: 780331.48397.bm@smtp101-mob.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: xuqZ1FsVM1kPW1k5D1vrFN_JySKcRbpoXH7JS8.6jfYSiP. iwTQcYXb0J3a74W95yMgAE9lOWMqRNuvHVDMRRAVpkQmlqR7k5_ngytxANgH 7XJxVcBkmqVCIl9nv48uW7yppGlVdMy.ZzLqeb1hM8JoxkiQGdUOmbkygQ8Z o8I5VOVEcr6.FpADeCpUnCgcAY7.GH6lLUK5QfUznrglIN3rxzeAwwZ0Am2x c22w6isiqO9soq3gDVVndFI1T.IUf2NGJhjDAqg.v1ws09XWn7y5ywjqmCwc pXXZEJTNz_bSb27oZiWW2j5n1Xg9IbHDtnqnydykgKvQEVap95PYes9lsIY_ OaKiMIqB.GERvo.Cq1Y6IQiKAV2ZbjTci8ZFZ7iK2QfzyyXB_Dfkn3otMxDj NAu4i.vLhto9cD4ri6HEDMmbYuRU86G_v7YZCL8F4SX8HhWNk5eBzHt2dfC. pHH93i.K_gGZoACodhbE.w6Ue4BukcPJCvxamflaumxJq3ryISgT8m6Ok3gN 3nQAugXidYjzeEMx_zE04CNYoTtW_exsn X-Yahoo-SMTP: 1NwK1FqswBBIXmrGMynm9AQsKvKa_A-- Received: from [192.168.1.103] (jadcooper@68.161.233.84 with xymcookie) by smtp101-mob.biz.mail.bf1.yahoo.com with SMTP; 06 Mar 2013 12:09:47 -0800 PST References: <642BFD16-A5E3-447F-9C52-6855AB1E5CC4@yahoo.com> <1362524363.1291.51.camel@revolution.hippie.lan> <5136B2A3.4010701@ceetonetechnology.com> <20130306123945.60aff30773fdd0fb2707a635@ddteam.net> <7198D3D7-AEFA-4054-8769-4B5E64C015D3@yahoo.com> <20130306163135.GA45920@ithaqua.etoilebsd.net> <20130306180555.GI18971@ithaqua.etoilebsd.net> In-Reply-To: <20130306180555.GI18971@ithaqua.etoilebsd.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <9479EAE2-E2E8-4528-A13B-ADD256B86212@yahoo.com> X-Mailer: iPhone Mail (9B206) From: Jad Cooper Subject: Re: Raspberry Pi image and pkg_add, pkg etc Date: Wed, 6 Mar 2013 15:09:44 -0500 To: Baptiste Daroussin Cc: "george@ceetonetechnology.com" , Aleksandr Rybalko , "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 20:16:20 -0000 Excellent - thanks for your responses -=20 how then should one proceed after downloading and installing the RPI=20 Image - freebsd-pi-r245446.img.gz? This is sort of my original point, how do I get involved in creating the rep= o/building packaged for FreeBSD10-Current and/or tweaking the image- the goa= l being that a hobbyist or high school student can download the image, copy t= o the disk, boot and start downloading packages? Perhaps I'm behind in versions ? Did I download a very early version of the b= uild for RPI ? I'm just looking for direction or to join an effort to make i= t more streamlined right from the outset. Cheers, J On Mar 6, 2013, at 1:05 PM, Baptiste Daroussin wrote: > On Wed, Mar 06, 2013 at 12:40:34PM -0500, Jad Cooper wrote: >>=20 >> On Mar 6, 2013, at 11:31 AM, Baptiste Daroussin wrote:= >>=20 >>> On Wed, Mar 06, 2013 at 10:56:47AM -0500, Jad Cooper wrote: >>>> Hi all thanks for taking the time to reply. >>>>=20 >>>> Indeed the packages are all available for ARM. >>>=20 >>> Not on the FreeBSD side, we do not provide any packages for arm, may tha= t be >>> pkgng or the old pkg_install, where did you find any packages? >> I found the .txz files >> ftp://ftp.freebsd.org/pub/FreeBSD/ports/arm/packages=20 >> The file I use with pkgng is the repo.txz file in that directory -=20 >=20 > Oh I forgot about those one, but they are very old and build on a 9.x box.= >>>=20 >>>> When I delved into installing packages initially there were issues. >>>> These are specific to the rpi image. >>>>=20 >>>> 1. The pkg_add works but wants to download packages from an armv6 dir t= hat's not in the public repo. >>>> 2. Since pkgng is the new manager , trying to get it bootstrapped fails= , so a manual build is necessary - downloading the txz and extracting it le= aves it missing several libraries. >>> To manually build pkgng the best is to use the ports tree which does eve= rything >>> needed for you. >>>=20 >>> How does it leaves missing libraries and what libraries, I do myself usr= pkgng >>> on a pandoboard with no problem you mean you have done the whole thing b= y hand >>> (picking the sources and building?). >>>=20 >>=20 >> Yes I downloaded the source from github and built it using make etc >=20 > Meaning you are now running on the master code which can easily be broken > (branch release-1.0 for stable things) >>=20 >>=20 >>>> 3. Once pkgng is setup and working the location of the repo has to be s= et manually using the setenv packagesite >>> It can also be specified via pkg.conf but this is only useful if you hav= e any >>> repository available somewhere to make binary only installation >>>=20 >>=20 >> I have the repo as above - the problem is that the pkg.conf file isn't in= the image... >=20 > Nope because 1.0b16 is really old and buggy for pkgng >>=20 >>=20 >>>> 4. using pkgng I have to force install the packages. >>>=20 >>> I don't get this one? can you give more details? >>=20 >> When I do "pkg install curl" for example=20 >>=20 >> It resolves the package but when it tries to install it complains that th= e version is not correct, saying that the version is incorrect built for 9 b= ut not 10the exact output I don't have - but=20 >>=20 >> "pkg install -f curl" works it just forces it to install - and curl then w= orks=20 >=20 > Sure you are trying to install package build on a FreeBSD 9 into a FreeBSD= 10. > curl works just because you got some compatibility bit able to use FreeBSD= 9 > binaries but if one of the base library ABI has changed since 9 it would h= ave > been broken >=20 >>=20 >>>>=20 >>>> Most of us are technical but to a hobbyist this is a bit complex, these= are the tools, files/condos I'd like to repair so that the image is immedia= tely useful for RPI.=20 >>>>=20 >>>> It's a great image already but I want to make it as simple as possible f= or students to get started with it.=20 >>>>=20 >>>> Do I need to download the image source as tweak the c and header files?= ? >>>=20 >>> Use the ports tree until we are able to create an arm build cluster, or u= se some >>> of the third party package repositories available out there (sorry I hav= e no >>> link for arm, just know that it does exists :) >>>=20 >> Isn't that FTP directory the ARM repo?? >=20 > Somehow :), but I do not recommand to use it :) >=20 >>=20 >> Maybe I'm missing some very fundamental FreeBSD insight but the FTP folde= rs above contain the compressed binary packages for almost everything - even= without pkgng or pkg_add I could install most using=20 >> tar - zxvPf package.txz , granted I had a lot of missing dependencies but= yeah the ARM bins are all there I thought... >=20 > Yes the pkgng format has been made that way, so if pkgng itself break a si= mple > tar xvpf can save you :) >=20 > regards, > Bapt >=20 From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 21:40:25 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4547962E; Wed, 6 Mar 2013 21:40:25 +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 BA733A1C; Wed, 6 Mar 2013 21:40:24 +0000 (UTC) Received: from rnote.ddteam.net (229-39-135-95.pool.ukrtel.net [95.135.39.229]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id CB4B9C4947; Wed, 6 Mar 2013 23:40:21 +0200 (EET) Date: Wed, 6 Mar 2013 23:40:04 +0200 From: Aleksandr Rybalko To: Warner Losh Subject: Re: GENERIC kernel issues Message-Id: <20130306234004.bf113967.ray@freebsd.org> In-Reply-To: References: <1362445777.1195.299.camel@revolution.hippie.lan> <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> <1362542286.1291.94.camel@revolution.hippie.lan> <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> <1362594744.1291.132.camel@revolution.hippie.lan> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 21:40:25 -0000 On Wed, 6 Mar 2013 12:33:11 -0700 Warner Losh wrote: > > On Mar 6, 2013, at 11:32 AM, Ian Lepore wrote: > > > On Wed, 2013-03-06 at 10:03 -0700, Warner Losh wrote: > >> On Mar 5, 2013, at 8:58 PM, Ian Lepore wrote: > > [...] > >>> We essentially pull off the same mapping trick with the kernel, > >>> except that very early in locore.s the code is carefully crafted > >>> to work right whether on physical or virtual addressing, just > >>> long enough to get the MMU turned off. Then it sets up page > >>> tables to map the physical pages the kernel has been loaded into > >>> to match the virtual addresses it was linked for. All of that > >>> only works if the low-order bits of the virtual address it was > >>> linked for match the physical address it was loaded at. That is, > >>> if linked for 0xC0001000 it must be loaded at 0xNNNN1000 > >>> physical, where the N bits can be anything. > >> > >> Right, but can't we get that from the virtual address. > > > > Not always. You can always figure out the right virtual address if > > you have the physical (you just OR-in 0xC0000000), but you can't > > always go the other way. If all you know is 0xC0010000 you have no > > idea whether the underlying physical address might be 0x00010000 or > > 0x80010000. Our current code that assumes you can do > > phys=pc&0xf0000000 is wrong for the same reason (but has been > > working okay by accident). > > The phys segment is pc & 0xf0000000 before you turn on the MMU > (assuming 256MB chip select offsets, adding another F would get that > down to 16MB chip selects, which is definitely good enough). After we > MMU start, it isn't, and our code shouldn't do that, unless it is > followed by oring in the physical segment... > > > That's part of why I've been working towards getting our arm > > ldscript to put proper physical addresses in the elf headers > > instead of virtual, in the fields that are supposed to have > > phsyical addresses in them (entry and program-header paddr fields). > > But that doesn't matter for the kernel so much... > > > With this scheme SoC-specific kernels will be linked with PHYSADDR= > > the real physical address and can be loaded by any standard elf > > loader because the headers are correct. A generic kernel will be > > linked with PHYSADDR=offset where offset is just the low-order part > > of the address and ubldr can load the kernel into whatever physical > > memory is available as long as the offset part stays the same. > > OK. That part makes perfect sense now. > > Warner > _______________________________________________ > 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" Maybe we should just let ubldr to enable MMU for us? Like we do for i386, IIRC. WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 21:56:23 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5309C995; Wed, 6 Mar 2013 21:56:23 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id 0370CABF; Wed, 6 Mar 2013 21:56:23 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 8712012013F; Wed, 6 Mar 2013 22:56:08 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 19BCE2848C; Wed, 6 Mar 2013 22:56:08 +0100 (CET) Date: Wed, 6 Mar 2013 22:56:08 +0100 From: Jilles Tjoelker To: Ian Lepore Subject: Re: cross-compilation of sh(1) from x86 to arm Message-ID: <20130306215607.GB15814@stack.nl> References: <20130303231931.GD21318@stack.nl> <1362582185.1291.106.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1362582185.1291.106.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 21:56:23 -0000 On Wed, Mar 06, 2013 at 08:03:05AM -0700, Ian Lepore wrote: > On Mon, 2013-03-04 at 00:19 +0100, Jilles Tjoelker wrote: > > There has long been a bug in sh(1) where it assumes (in mksyntax.c) that > > the properties of char are the same between build and run environments. > > This assumption does not hold if a cross build is done for arm on an x86 > > machine. The main effect is that such a miscompiled sh incorrectly > > handles characters with bit 7 set. Various tests in > > tools/regression/bin/sh start failing, possibly in ways that eat huge > > amounts of CPU time and memory. > > Christoph Mallon has submitted a fix for this and I have committed it to > > head and stable/9. It has, however, only been tested on x86 using the > > -funsigned-char compiler option to create the discrepancy. > > Below is a backport of the fix to stable/8. It needs r247733 or at least > > the bin/sh/mksyntax.c of that revision. > > Because I had to fix some conflicts and stable/8's sh differs quite a > > bit from head's, I would like to have some testing first before > > committing this. I again tested only on amd64 with and without the > > -funsigned-char compiler option and tools/regression/bin/sh. If the > > cross-compilation need not be supported on stable/8, I am fine with > > leaving it unfixed in stable/8. > It took me a while to get an arm 8-stable environment running to test > this. I'm cross-building arm from an i386 build machine running 8.3. > Testing with 8-stable @ r247889 before applying your patch, I get two > failures: > not ok 12 - ./builtins/cd1.0 # wrong exit status > not ok 98 - ./expansion/ifs3.0 # wrong exit status > After applying your patch, only test 12 fails (still wrong exit status). Thanks for testing. I will commit the MFC. > The failure of test 12 looks like this in both cases: > root@dpcur:/tmp/regression/bin/sh # sh -x builtins/cd1.0 > + set -e > + P=/tmp > + cd /tmp > + mktemp -d sh-test.XXXXXX > + T=sh-test.TkJqGN > + chmod 0 sh-test.TkJqGN > + cd -L sh-test.TkJqGN > + exit 1 > If I launch sh and enter that series of commands interactively, the cd > -L command returns a status of 0. That part of the test does not work as root. The cd command is supposed to fail and not change internal state. In 9.x that part of the test is skipped when running as root; I have just MFC'ed that change. I never noticed this issue because I always run the tests as a normal user. > Now that I've remembered the incantations for getting 8.x to run on my > dreamplug I can test things pretty easily if you've got other changes. Thanks, but I'm not planning to MFC anything more to stable/8/bin/sh right now. (Unless you'd like to have some (compatible) change from 9.x or 10.x.) > I also tested -current cross-built on the same machine (using gcc and > oabi), and there are no failures there. Cool. -- Jilles Tjoelker From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 21:56:54 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 465A29D8 for ; Wed, 6 Mar 2013 21:56:54 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 1D5E6AC7 for ; Wed, 6 Mar 2013 21:56:53 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UDJ8d-0008rh-7h; Wed, 06 Mar 2013 18:32:27 +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 r26IWOvZ003334; Wed, 6 Mar 2013 11:32:24 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18VrC1G1My8FKfSBUJeLec6 Subject: Re: GENERIC kernel issues From: Ian Lepore To: Warner Losh In-Reply-To: <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> References: <1362445777.1195.299.camel@revolution.hippie.lan> <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> <1362542286.1291.94.camel@revolution.hippie.lan> <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Mar 2013 11:32:24 -0700 Message-ID: <1362594744.1291.132.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 21:56:54 -0000 On Wed, 2013-03-06 at 10:03 -0700, Warner Losh wrote: > On Mar 5, 2013, at 8:58 PM, Ian Lepore wrote: [...] > > We essentially pull off the same mapping trick with the kernel, except > > that very early in locore.s the code is carefully crafted to work right > > whether on physical or virtual addressing, just long enough to get the > > MMU turned off. Then it sets up page tables to map the physical pages > > the kernel has been loaded into to match the virtual addresses it was > > linked for. All of that only works if the low-order bits of the virtual > > address it was linked for match the physical address it was loaded at. > > That is, if linked for 0xC0001000 it must be loaded at 0xNNNN1000 > > physical, where the N bits can be anything. > > Right, but can't we get that from the virtual address. Not always. You can always figure out the right virtual address if you have the physical (you just OR-in 0xC0000000), but you can't always go the other way. If all you know is 0xC0010000 you have no idea whether the underlying physical address might be 0x00010000 or 0x80010000. Our current code that assumes you can do phys=pc&0xf0000000 is wrong for the same reason (but has been working okay by accident). That's part of why I've been working towards getting our arm ldscript to put proper physical addresses in the elf headers instead of virtual, in the fields that are supposed to have phsyical addresses in them (entry and program-header paddr fields). With this scheme SoC-specific kernels will be linked with PHYSADDR= the real physical address and can be loaded by any standard elf loader because the headers are correct. A generic kernel will be linked with PHYSADDR=offset where offset is just the low-order part of the address and ubldr can load the kernel into whatever physical memory is available as long as the offset part stays the same. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 21:58:00 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CDEE2A1F for ; Wed, 6 Mar 2013 21:58:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 821CFAD5 for ; Wed, 6 Mar 2013 21:58:00 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id 16so3915194obc.19 for ; Wed, 06 Mar 2013 13:58:00 -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=gEO4QFfVL/ahUqNJp9PJ7PIX+ZWHdj1yzISEjYrl6pw=; b=IqbHNAH+w+rIdeEAOwJxIIVxUDOgRgGL+PLKf4WRHRG5N0K2oH/iCuwnC/MSbPlD2j 33yTQT5GVFYsIOYHhpzwfUUUQrIZ0H2UvRRzUKH1fJ6ltglOiPzVq1p5pyKI2RXTx7FU rKgwVg8prunyR3V6/fzWJ+3a3cCnsvAEZcK1aEn7/AQLRY22rJN6BP73/KyCLnW5p126 Jblmg3dPFGLuPOgAftVIFJ4J9sQgLammCEmpSU7VFTwoCLDQQ4tOiMWuCCKyLwqP+3St H3WgrMPNk1L9+N2B5QLYIk0Xq+hHIm6hl3YnuY1+SlWYtAaDBkz7TYtAkC2ZDEShZQig Mqzg== X-Received: by 10.60.32.113 with SMTP id h17mr24006326oei.54.1362607080152; Wed, 06 Mar 2013 13:58:00 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id t9sm39325331obk.13.2013.03.06.13.57.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 13:57:59 -0800 (PST) Sender: Warner Losh Subject: Re: GENERIC kernel issues Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130306234004.bf113967.ray@freebsd.org> Date: Wed, 6 Mar 2013 14:57:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4C0099FA-BBBE-4F93-8C97-CE5B79465829@bsdimp.com> References: <1362445777.1195.299.camel@revolution.hippie.lan> <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> <1362542286.1291.94.camel@revolution.hippie.lan> <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> <1362594744.1291.132.camel@revolution.hippie.lan> <20130306234004.bf113967.ray@freebsd.org> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkcargwfFQuMh0imeffpj6xXbRECFP1YBq/bLBzJZaLujwi8S8osqCiYbuOqYi4UPOlz/Do Cc: freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 21:58:00 -0000 On Mar 6, 2013, at 2:40 PM, Aleksandr Rybalko wrote: > On Wed, 6 Mar 2013 12:33:11 -0700 > Warner Losh wrote: >=20 >>=20 >> On Mar 6, 2013, at 11:32 AM, Ian Lepore wrote: >>=20 >>> On Wed, 2013-03-06 at 10:03 -0700, Warner Losh wrote: >>>> On Mar 5, 2013, at 8:58 PM, Ian Lepore wrote: >>> [...] >>>>> We essentially pull off the same mapping trick with the kernel, >>>>> except that very early in locore.s the code is carefully crafted >>>>> to work right whether on physical or virtual addressing, just >>>>> long enough to get the MMU turned off. Then it sets up page >>>>> tables to map the physical pages the kernel has been loaded into >>>>> to match the virtual addresses it was linked for. All of that >>>>> only works if the low-order bits of the virtual address it was >>>>> linked for match the physical address it was loaded at. That is, >>>>> if linked for 0xC0001000 it must be loaded at 0xNNNN1000 >>>>> physical, where the N bits can be anything. >>>>=20 >>>> Right, but can't we get that from the virtual address. >>>=20 >>> Not always. You can always figure out the right virtual address if >>> you have the physical (you just OR-in 0xC0000000), but you can't >>> always go the other way. If all you know is 0xC0010000 you have no >>> idea whether the underlying physical address might be 0x00010000 or >>> 0x80010000. Our current code that assumes you can do >>> phys=3Dpc&0xf0000000 is wrong for the same reason (but has been >>> working okay by accident). >>=20 >> The phys segment is pc & 0xf0000000 before you turn on the MMU >> (assuming 256MB chip select offsets, adding another F would get that >> down to 16MB chip selects, which is definitely good enough). After we >> MMU start, it isn't, and our code shouldn't do that, unless it is >> followed by oring in the physical segment... >>=20 >>> That's part of why I've been working towards getting our arm >>> ldscript to put proper physical addresses in the elf headers >>> instead of virtual, in the fields that are supposed to have >>> phsyical addresses in them (entry and program-header paddr fields). >>=20 >> But that doesn't matter for the kernel so much... >>=20 >>> With this scheme SoC-specific kernels will be linked with PHYSADDR=3D >>> the real physical address and can be loaded by any standard elf >>> loader because the headers are correct. A generic kernel will be >>> linked with PHYSADDR=3Doffset where offset is just the low-order = part >>> of the address and ubldr can load the kernel into whatever physical >>> memory is available as long as the offset part stays the same. >>=20 >> OK. That part makes perfect sense now. >>=20 >> Warner >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >=20 > Maybe we should just let ubldr to enable MMU for us? Like we do for > i386, IIRC. One weak reason is that uboot and other loaders that are used to loading = Linux are forbidden from having the MMU enabled when they transfer = control to the kernel they boot. We'd want to still work there, and = would need extra/different code to cope with the booted with the MMU = enabled and booted without the MMU enabled. Warner From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 22:57:09 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 075E54A3; Wed, 6 Mar 2013 22:57:09 +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 4B0A2E6A; Wed, 6 Mar 2013 22:57:08 +0000 (UTC) Received: from rnote.ddteam.net (229-39-135-95.pool.ukrtel.net [95.135.39.229]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id BDF2FC493C; Thu, 7 Mar 2013 00:57:06 +0200 (EET) Date: Thu, 7 Mar 2013 00:56:49 +0200 From: Aleksandr Rybalko To: Warner Losh Subject: Re: GENERIC kernel issues Message-Id: <20130307005649.35a6b9ae.ray@freebsd.org> In-Reply-To: <4C0099FA-BBBE-4F93-8C97-CE5B79465829@bsdimp.com> References: <1362445777.1195.299.camel@revolution.hippie.lan> <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> <1362542286.1291.94.camel@revolution.hippie.lan> <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> <1362594744.1291.132.camel@revolution.hippie.lan> <20130306234004.bf113967.ray@freebsd.org> <4C0099FA-BBBE-4F93-8C97-CE5B79465829@bsdimp.com> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 22:57:09 -0000 On Wed, 6 Mar 2013 14:57:56 -0700 Warner Losh wrote: > > On Mar 6, 2013, at 2:40 PM, Aleksandr Rybalko wrote: > > > On Wed, 6 Mar 2013 12:33:11 -0700 > > Warner Losh wrote: > > > >> > >> On Mar 6, 2013, at 11:32 AM, Ian Lepore wrote: > >> > >>> On Wed, 2013-03-06 at 10:03 -0700, Warner Losh wrote: > >>>> On Mar 5, 2013, at 8:58 PM, Ian Lepore wrote: > >>> [...] > >>>>> We essentially pull off the same mapping trick with the kernel, > >>>>> except that very early in locore.s the code is carefully crafted > >>>>> to work right whether on physical or virtual addressing, just > >>>>> long enough to get the MMU turned off. Then it sets up page > >>>>> tables to map the physical pages the kernel has been loaded into > >>>>> to match the virtual addresses it was linked for. All of that > >>>>> only works if the low-order bits of the virtual address it was > >>>>> linked for match the physical address it was loaded at. That is, > >>>>> if linked for 0xC0001000 it must be loaded at 0xNNNN1000 > >>>>> physical, where the N bits can be anything. > >>>> > >>>> Right, but can't we get that from the virtual address. > >>> > >>> Not always. You can always figure out the right virtual address > >>> if you have the physical (you just OR-in 0xC0000000), but you > >>> can't always go the other way. If all you know is 0xC0010000 you > >>> have no idea whether the underlying physical address might be > >>> 0x00010000 or 0x80010000. Our current code that assumes you can > >>> do phys=pc&0xf0000000 is wrong for the same reason (but has been > >>> working okay by accident). > >> > >> The phys segment is pc & 0xf0000000 before you turn on the MMU > >> (assuming 256MB chip select offsets, adding another F would get > >> that down to 16MB chip selects, which is definitely good enough). > >> After we MMU start, it isn't, and our code shouldn't do that, > >> unless it is followed by oring in the physical segment... > >> > >>> That's part of why I've been working towards getting our arm > >>> ldscript to put proper physical addresses in the elf headers > >>> instead of virtual, in the fields that are supposed to have > >>> phsyical addresses in them (entry and program-header paddr > >>> fields). > >> > >> But that doesn't matter for the kernel so much... > >> > >>> With this scheme SoC-specific kernels will be linked with > >>> PHYSADDR= the real physical address and can be loaded by any > >>> standard elf loader because the headers are correct. A generic > >>> kernel will be linked with PHYSADDR=offset where offset is just > >>> the low-order part of the address and ubldr can load the kernel > >>> into whatever physical memory is available as long as the offset > >>> part stays the same. > >> > >> OK. That part makes perfect sense now. > >> > >> Warner > >> _______________________________________________ > >> 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" > > > > Maybe we should just let ubldr to enable MMU for us? Like we do for > > i386, IIRC. > > One weak reason is that uboot and other loaders that are used to > loading Linux are forbidden from having the MMU enabled when they > transfer control to the kernel they boot. We'd want to still work > there, and would need extra/different code to cope with the booted > with the MMU enabled and booted without the MMU enabled. > > Warner > IIRC, there was already decided point, to have one kernel per incompatible device and single kernel for all systems that we can make generic. Right? ubldr depend on U-Boot, and U-Boot must be recompilled with CONFIG_API thing, which is not enabled in all uboots I ever seen. So in that case we can even make ubldr compiled into uboot as uboot-app :) So we need to decide where we will do ugly things: 1. in U-Boot (or other loader) 2. in ubldr 3. in kernel in some case we can't replace original loader and/or add second loader (second uboot), and we prefer to have most of thing to looks identical in kernel. So my finger points on ubldr. And it will be nice to teach ubldr to work with other loaders and somehow not to depend on CONFIG_API of uboot. Thanks! WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 23:16:04 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 25E268BF; Wed, 6 Mar 2013 23:16:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 5AEA6F52; Wed, 6 Mar 2013 23:16:03 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id z53so9277303wey.1 for ; Wed, 06 Mar 2013 15:16:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=GOeCgG+53M8WFFYqBXym8FpLVZ+z0dR5ntZKOaIykBg=; b=QwWmXvmc8kDGnpvvnkvg8AFwIyopwoPmSfwjjGjNo2c+vEaHwXZIk9coun75SHIko6 P3YhtJ/zy3Pz14C0QR3lWE7fjTnSUEaHBe/JlItLlQ8iumrG0KqU8nutf3CmiECl2krp /KcKjhOtd4L01qvfwW4nd12GmXuHZhDrgoayrr4jObU6cmq8yP2x8591rQJ4ByBki8qq 1kghzmMAVQLFtuFuuuh0qPfpRrIbut4lhrmc9QDfa6j5bl1vFGs3L/nScj9HOlb92Ac9 LBF04QgCaTUqHhF+l1NJfwHqsBDXxjUYH8BAuBv7msk3/+0pR+YO29kc4ACUChuVhCCL 06zg== MIME-Version: 1.0 X-Received: by 10.194.178.9 with SMTP id cu9mr30070117wjc.39.1362611762320; Wed, 06 Mar 2013 15:16:02 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.51.2 with HTTP; Wed, 6 Mar 2013 15:16:02 -0800 (PST) In-Reply-To: <20130307005649.35a6b9ae.ray@freebsd.org> References: <1362445777.1195.299.camel@revolution.hippie.lan> <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> <1362542286.1291.94.camel@revolution.hippie.lan> <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> <1362594744.1291.132.camel@revolution.hippie.lan> <20130306234004.bf113967.ray@freebsd.org> <4C0099FA-BBBE-4F93-8C97-CE5B79465829@bsdimp.com> <20130307005649.35a6b9ae.ray@freebsd.org> Date: Wed, 6 Mar 2013 15:16:02 -0800 X-Google-Sender-Auth: 71r40uXR8EircUIhjPKnTuNCGZs Message-ID: Subject: Re: GENERIC kernel issues From: Adrian Chadd To: Aleksandr Rybalko Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 23:16:04 -0000 Peeps, If you make the boot process too complicated and it stops being "load kernel via flash/NFS, boot" then people may just not bother. :-) I know you're going for correctness and we're hampered by how "linux does things', but I really do suggest that you first get working, packaged, easily installed and updated systems using what we currently heave before you try to make a 'much nicer but noone ever uses it' solution. Please don't fall down the trap of "over-engineering correctness that noone will ever use." that software people do when they don't have deliverables. 2c, Adrian From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 23:40:46 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3A33162F; Wed, 6 Mar 2013 23:40:46 +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 C1D141F6; Wed, 6 Mar 2013 23:40:45 +0000 (UTC) Received: from rnote.ddteam.net (229-39-135-95.pool.ukrtel.net [95.135.39.229]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id C2AF3C4946; Thu, 7 Mar 2013 01:40:38 +0200 (EET) Date: Thu, 7 Mar 2013 01:40:21 +0200 From: Aleksandr Rybalko To: Adrian Chadd Subject: Re: GENERIC kernel issues Message-Id: <20130307014021.3c02fdb4.ray@freebsd.org> In-Reply-To: References: <1362445777.1195.299.camel@revolution.hippie.lan> <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> <1362542286.1291.94.camel@revolution.hippie.lan> <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> <1362594744.1291.132.camel@revolution.hippie.lan> <20130306234004.bf113967.ray@freebsd.org> <4C0099FA-BBBE-4F93-8C97-CE5B79465829@bsdimp.com> <20130307005649.35a6b9ae.ray@freebsd.org> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 23:40:46 -0000 On Wed, 6 Mar 2013 15:16:02 -0800 Adrian Chadd wrote: > Peeps, > > If you make the boot process too complicated and it stops being "load > kernel via flash/NFS, boot" then people may just not bother. :-) > > I know you're going for correctness and we're hampered by how "linux > does things', but I really do suggest that you first get working, > packaged, easily installed and updated systems using what we currently > heave before you try to make a 'much nicer but noone ever uses it' > solution. > > Please don't fall down the trap of "over-engineering correctness that > noone will ever use." that software people do when they don't have > deliverables. > > 2c, > > > > Adrian Adrian, I hope you don't compile special kernel before first boot on every new laptop/desktop/server? :))) We want also find such drugs for so mach fancy ARM world, so anybody will have a way to boot board with one of few install images, but not one per board. Thanks! WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Thu Mar 7 00:09:09 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8E880173 for ; Thu, 7 Mar 2013 00:09:09 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5736A344 for ; Thu, 7 Mar 2013 00:09:09 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id l20so13608209oag.9 for ; Wed, 06 Mar 2013 16:09:08 -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=sOTeOHCnU3OkyCVf8iAaBDdQ/3gsHVTDhLPlEqMb1Bk=; b=bjo9MW1UGEu8Sq3agqSMFm8dFfCqT5Mgpo6Cas4HwFtW5GUGGH4eL0oCNwlLeBD9Q6 BBW7DgSq836QIECMXNoYKUeCILx84/IX0Fob5ytWyic09z0zjOSVHcdcxv4OM/eWOq9Y mpNV+Do9FonypEutT6PNwcqw+vztKIWQUHAAn0xqvrdIAfzNTcOc/vOwu0tksTGNhNVU EgyZ9im4Adt9T7K90MivL9SjON3N5xRs2S3XQEaD9DJotVxRkjUdPru9QIO39hWykEo7 5FzTARUPk9Jl3Zl2bK2md509ulgy0wgo1cp0i+a/2dNyA8MvPYShVz5ph6PrDfRdMR3O OFkA== X-Received: by 10.60.22.34 with SMTP id a2mr24268908oef.97.1362614948539; Wed, 06 Mar 2013 16:09:08 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id ad19sm41003796oec.0.2013.03.06.16.09.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 16:09:07 -0800 (PST) Sender: Warner Losh Subject: Re: GENERIC kernel issues Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130307014021.3c02fdb4.ray@freebsd.org> Date: Wed, 6 Mar 2013 17:09:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1362445777.1195.299.camel@revolution.hippie.lan> <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> <1362542286.1291.94.camel@revolution.hippie.lan> <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> <1362594744.1291.132.camel@revolution.hippie.lan> <20130306234004.bf113967.ray@freebsd.org> <4C0099FA-BBBE-4F93-8C97-CE5B79465829@bsdimp.com> <20130307005649.35a6b9ae.ray@freebsd.org> <20130307014021.3c02fdb4.ray@freebsd.org> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmz12nAOMpE63Cp7kt6S5U4BKhssSu4dcl7LbpUd+pcThRBS35YlKo4UhorGiU3Jo8FB3nP Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 00:09:09 -0000 On Mar 6, 2013, at 4:40 PM, Aleksandr Rybalko wrote: > On Wed, 6 Mar 2013 15:16:02 -0800 > Adrian Chadd wrote: >=20 >> Peeps, >>=20 >> If you make the boot process too complicated and it stops being "load >> kernel via flash/NFS, boot" then people may just not bother. :-) >>=20 >> I know you're going for correctness and we're hampered by how "linux >> does things', but I really do suggest that you first get working, >> packaged, easily installed and updated systems using what we = currently >> heave before you try to make a 'much nicer but noone ever uses it' >> solution. >>=20 >> Please don't fall down the trap of "over-engineering correctness that >> noone will ever use." that software people do when they don't have >> deliverables. >>=20 >> 2c, >>=20 >>=20 >>=20 >> Adrian >=20 > Adrian,=20 >=20 > I hope you don't compile special kernel before first boot on > every new laptop/desktop/server? :))) >=20 > We want also find such drugs for so mach fancy ARM world, so anybody > will have a way to boot board with one of few install images, but not > one per board. We're also not talking about making it too complicated, but rather the = reverse: how can we create fewer binary images. Since Linux is king in = the embedded world, it seems self obvious that having our kernels be = compatible with that will give us the least head wind. Having attempted = to do something "right" without considering the prevailing environment = before, I'd say that we will be miles ahead doing this in a sane way = first, rather than kludging something together that kinda works on two = boards. Today a single linux arm kernel will boot on hundreds if not = thousands of different boards. We should learn from that experience = rather than coming up with something that's NIH, but gets "something" = done fast. So far we haven't been hampered by taking this route, apart from some = churn in email and the odd issue here and there. Ian has been hitting it = out of the park, and none of the issues we've seen so far are show = stoppers, especially if we go to a static PIC ubldr to increase the = number of systems we can load on... Then what we do with the elf = headers suddenly doesn't matter at all. Or at least not as much... Warner= From owner-freebsd-arm@FreeBSD.ORG Thu Mar 7 00:10:59 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 048451B9 for ; Thu, 7 Mar 2013 00:10:59 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id D45A9351 for ; Thu, 7 Mar 2013 00:10:58 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UDOQD-000HKa-Oi; Thu, 07 Mar 2013 00:10:58 +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 r270As7O003627; Wed, 6 Mar 2013 17:10:54 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX194A3rWm5F8khUpGKcu4VX5 Subject: Re: cross-compilation of sh(1) from x86 to arm From: Ian Lepore To: Jilles Tjoelker In-Reply-To: <20130306215607.GB15814@stack.nl> References: <20130303231931.GD21318@stack.nl> <1362582185.1291.106.camel@revolution.hippie.lan> <20130306215607.GB15814@stack.nl> Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Mar 2013 17:10:54 -0700 Message-ID: <1362615054.1291.159.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 00:10:59 -0000 On Wed, 2013-03-06 at 22:56 +0100, Jilles Tjoelker wrote: > Thanks, but I'm not planning to MFC anything more to stable/8/bin/sh > right now. (Unless you'd like to have some (compatible) change from 9.x > or 10.x.) > Did the vfork() changes ever make it to 8? That'd be nice to have if it's easy, don't worry about it if it's a lot of work. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Mar 7 00:15:55 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 843E3236 for ; Thu, 7 Mar 2013 00:15:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA48378 for ; Thu, 7 Mar 2013 00:15:55 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id k14so13231363oag.39 for ; Wed, 06 Mar 2013 16:15:54 -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=oZaaaRfsZmyAIu64mjfNbKUgGREeGIltPp6sY+7Ynak=; b=QE1m8Wf/rtfZcyYhZimHptRmJhrrX8yrNxybf2Ip5KPCjXeMi4LuSrABBLTDR3ttyR U/6uLeyjUnc/Z+N2IXaQvG0+KMcP2Z+V0kCwHswqhev63tQ/PRHX58B1h9E3cY4MDOqc kT5kn0FtNtdUxhOmp1IqGv8bZ99LXS5nsBYB45UFU0K6kkH/MKJzy0zQGempqIIKIBw7 cLwgfZryhjn4NCQ4HSnrR0fyoEBCZlXbNKxcWIR4sdKH1Q4ryyPL/Usvi7vowyc3n5EI nGbuFBiyUtrRjud748Dlmiqx+Q/UXyC/AlpeIhTwrAeJ+590+AxRTc7+LV/HbWhp5ZPg 9rrA== X-Received: by 10.182.43.103 with SMTP id v7mr24396219obl.17.1362615354719; Wed, 06 Mar 2013 16:15:54 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id z5sm41024645oeh.1.2013.03.06.16.15.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 16:15:53 -0800 (PST) Sender: Warner Losh Subject: Re: GENERIC kernel issues Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130307014021.3c02fdb4.ray@freebsd.org> Date: Wed, 6 Mar 2013 17:15:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5EF158CC-645A-466C-BDF7-7CA04B1CEA10@bsdimp.com> References: <1362445777.1195.299.camel@revolution.hippie.lan> <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> <1362542286.1291.94.camel@revolution.hippie.lan> <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> <1362594744.1291.132.camel@revolution.hippie.lan> <20130306234004.bf113967.ray@freebsd.org> <4C0099FA-BBBE-4F93-8C97-CE5B79465829@bsdimp.com> <20130307005649.35a6b9ae.ray@freebsd.org> <20130307014021.3c02fdb4.ray@freebsd.org> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlADPMKmw8d9+T0r4uxjC0RdasmCre4A9UQp2SIM3PiuCHoyzYHXLLllAUneZAmN/Rh6Wqe Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 00:15:55 -0000 On Mar 6, 2013, at 4:40 PM, Aleksandr Rybalko wrote: > On Wed, 6 Mar 2013 15:16:02 -0800 > Adrian Chadd wrote: >=20 >> Peeps, >>=20 >> If you make the boot process too complicated and it stops being "load >> kernel via flash/NFS, boot" then people may just not bother. :-) >>=20 >> I know you're going for correctness and we're hampered by how "linux >> does things', but I really do suggest that you first get working, >> packaged, easily installed and updated systems using what we = currently >> heave before you try to make a 'much nicer but noone ever uses it' >> solution. >>=20 >> Please don't fall down the trap of "over-engineering correctness that >> noone will ever use." that software people do when they don't have >> deliverables. >>=20 >> 2c, >>=20 >>=20 >>=20 >> Adrian >=20 > Adrian,=20 >=20 > I hope you don't compile special kernel before first boot on > every new laptop/desktop/server? :))) >=20 > We want also find such drugs for so mach fancy ARM world, so anybody > will have a way to boot board with one of few install images, but not > one per board. another way of saying this is that the commercial folks that have been = using ARM boards have discovered that a diversity of kernels is bad, and = the more boards one kernel can support the better for their support = load. Also, we've been down the compile it per board route, and it is = showing signs of strain. Linux also went down this route years ago and = found the strain too much so has been evolving into a single kernel = image that supports any FDT platform. We're a ways away from *THAT*, but = one of the issues that needs to be solved is loading stuff in the right = place, and Ian is well down that path and should have a solution to = that. Then all we have to worry about are things like DELAY, cpu_*, = platform_*, cache coherence differences (currently ifdefs in pmap v6 = code), switching between v4/5 and v6/7 pmap, and likley a few others = that I've forgotten. All these things today make a single image = impossible. But it is a solveable, whack-a-mole problem rather than an = infinite set of things we have to struggle with. So while we're not trying to stop someone from having a custom kernel, = we're trying to have a viable GENERIC that actually works like x86 and = ppc do today, hopefully without a big performance hit.... Should we = succeed, then you can still build a specific thing, should we fail, you = can still build a specific thing... But if we succeed you won't be = forced to do so... Warner= From owner-freebsd-arm@FreeBSD.ORG Thu Mar 7 10:29:15 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2313C917 for ; Thu, 7 Mar 2013 10:29:15 +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 E99F5FC9 for ; Thu, 7 Mar 2013 10:29:14 +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 <0MJA005M4D4DAM30@smtp5.clear.net.nz> for arm@freebsd.org; Thu, 07 Mar 2013 23:29:06 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO bender) ([202.0.48.19]) by smtpin1.paradise.net.nz with ESMTP; Thu, 07 Mar 2013 23:29:07 +1300 Date: Thu, 07 Mar 2013 23:28:53 +1300 From: Andrew Turner Subject: Re: Building gettext on ARM? In-reply-to: <46D6567D-D7AC-4BFB-94FE-B54E87224C20@neville-neil.com> To: George Neville-Neil Message-id: <20130307232853.2d33667b@bender> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit References: <46D6567D-D7AC-4BFB-94FE-B54E87224C20@neville-neil.com> Cc: "arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 10:29:15 -0000 On Tue, 5 Mar 2013 22:08:25 -0500 George Neville-Neil wrote: > Howdy, > > I believe this is an issue that may run deeper than just gettext: > > ===> Building for gettext-0.18.1.1 > Making all in gnulib-local > Making all in gettext-runtime > make all-recursive > Making all in doc > Making all in intl > /bin/sh /usr/local/bin/libtool --tag=CC --mode=compile cc -c > -DLOCALEDIR=\"/usr/local/share/locale\" > -DLOCALE_ALIAS_PATH=\"/usr/local/share/locale\" > -DLIBDIR=\"/usr/local/lib\" -DBUILDING_LIBINTL -DBUILDING_DLL > -DIN_LIBINTL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY > -DINSTALLDIR=\"/usr/local/lib\" -DNO_XMALLOC > -Dset_relocation_prefix=libintl_set_relocation_prefix > -Drelocate=libintl_relocate -DDEPENDS_ON_LIBICONV=1 -DHAVE_CONFIG_H > -I. -I. -I.. -I/usr/local/include -O -pipe > -fvisibility=hidden ./bindtextdom.c libtool: compile: cc -c > -DLOCALEDIR=\"/usr/local/share/locale\" > -DLOCALE_ALIAS_PATH=\"/usr/local/share/locale\" > -DLIBDIR=\"/usr/local/lib\" -DBUILDING_LIBINTL -DBUILDING_DLL > -DIN_LIBINTL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY > -DINSTALLDIR=\"/usr/local/lib\" -DNO_XMALLOC > -Dset_relocation_prefix=libintl_set_relocation_prefix > -Drelocate=libintl_relocate -DDEPENDS_ON_LIBICONV=1 -DHAVE_CONFIG_H > -I. -I. -I.. -I/usr/local/include -O -pipe > -fvisibility=hidden ./bindtextdom.c -fPIC -DPIC > -o .libs/bindtextdom.o In file included > from ./bindtextdom.c:24: /usr/include/stddef.h:41: error: two or more > data types in declaration specifiers *** [bindtextdom.lo] Signal 11 > > > The offending line is: > > #include > #include > #include > > typedef __ptrdiff_t ptrdiff_t; <--- Line 41 > > Thoughts? > Best, > George I'm unable to reproduce this build failure. I am, however, running an EABI system so that may be enough of a difference. Can you send me gettext-runtime/config.h and gettext-runtime/config.log. I suspect the check for ptrdiff_t is failing and the preprocessor is defining it as something else. Andrew From owner-freebsd-arm@FreeBSD.ORG Thu Mar 7 12:32:25 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8E2BBEFC for ; Thu, 7 Mar 2013 12:32:25 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 25F1376C for ; Thu, 7 Mar 2013 12:32:25 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UDZzb-0001z6-M5 for freebsd-arm@freebsd.org; Thu, 07 Mar 2013 13:32:18 +0100 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UDZza-00044i-QX for freebsd-arm@freebsd.org; Thu, 07 Mar 2013 13:32:14 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: ARM EABI test image References: <20130302172556.5b59e122@bender> Date: Thu, 07 Mar 2013 13:32:15 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.14 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.0 X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=disabled version=3.3.1 X-Scan-Signature: 2d0a7f6a049cc125cd28f2ceffdc0173 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 12:32:25 -0000 On Wed, 06 Mar 2013 00:04:22 +0100, Ronald Klop wrote: > On Sat, 02 Mar 2013 18:21:28 +0100, Ronald Klop > wrote: > >> On Sat, 02 Mar 2013 05:25:56 +0100, Andrew Turner >> wrote: >> >>> Hello, >>> >>> I have built an updated ARM EABI test image for Raspberry Pi [1]. >>> >>> The only known issue is c++ exception handling is broken when >>> using in a dynamically linked executable. Static executables should >>> work with c++ exceptions. >>> >>> To test it you will have to extract it using unxz and dd it to an sd >>> card, for example, with a USB to SD adapter on /dev/da0: >>> $ unxz bsd-pi-eabi-r247609.img.xz >>> $ dd if=bsd-pi-eabi-r247609.img of=/dev/da0 >>> >>> If you don't have a Raspberry Pi but would like to try it on your board >>> you can add -DWITH_ARM_EABI to the make commands you use to build and >>> install world and the kernel. >> >> Is this also interesing on the older SHEEVAPLUG? >> If yes, I can test it somewhere next week. >> >> Ronald. >> >>> >>> Can people try this as I would like to know if anything else is broken >>> as this will become the default ABI for 10. >>> >>> Andrew >>> >>> [1] http://people.freebsd.org/~andrew/rpi/bsd-pi-eabi-r247609.img.xz > > I get this error. I cross-compile 10-CURRENT/arm for SHEEVAPLUG on > 9-STABLE/amd64. > 10-CURRENT is just svn up'ed. I don't have special vars set for clang, > so it compiles with gcc AFAIK. > No src.conf. Using these env vars for buildworld: > export TARGET_ARCH=arm > export KERNCONF=SHEEVAPLUG > export WITH_NAND=yes > export WITH_ARM_EABI=yes > > ... > cc -O -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT > -DLOADER_NANDFS_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT > -I/usr/src/sys/boot/arm/uboot/../../fdt > -I/usr/obj/arm.arm/usr/src/sys/boot/arm/uboot/../../fdt > -DLOADER_FDT_SUPPORT -DBOOT_FORTH > -I/usr/src/sys/boot/arm/uboot/../../ficl > -I/usr/src/sys/boot/arm/uboot/../../ficl/arm -DLOADER_DISK_SUPPORT > -DLOADER_GPT_SUPPORT -DLOADER_MBR_SUPPORT > -I/usr/src/sys/boot/arm/uboot/../../common -I. -ffreestanding > -I/usr/src/sys/boot/arm/uboot/../../uboot/common > -I/usr/src/sys/boot/arm/uboot/../../uboot/lib > -I/usr/obj/arm.arm/usr/src/sys/boot/arm/uboot/../../uboot/lib > -I/usr/src/sys/boot/arm/uboot/../../../../lib/libstand/ -std=gnu99 > -Wsystem-headers -Werror -Wno-pointer-sign -nostdlib -static -T > ldscript.generated -T /usr/src/sys/boot/arm/uboot/ldscript.arm -o ubldr > start.o conf.o vers.o boot.o commands.o console.o devopen.o interp.o > interp_backslash.o interp_parse.o ls.o misc.o module.o panic.o > load_elf32.o reloc_elf32.o dev_net.o disk.o part.o crc32.o > interp_forth.o main.o metadata.o > /usr/obj/arm.arm/usr/src/sys/boot/arm/uboot/../../ficl/libficl.a > /usr/obj/arm.arm/usr/src/sys/boot/arm/uboot/../../uboot/lib/libuboot.a > /usr/obj/arm.arm/usr/src/sys/boot/arm/uboot/../../fdt/libfdt.a -lstand > /usr/obj/arm.arm/usr/src/tmp/usr/lib/libstand.a(udivmoddi4.o): In > function `__udivmoddi4': > udivmoddi4.c:(.text+0x154): undefined reference to `__ctzsi2' > udivmoddi4.c:(.text+0x16c): undefined reference to `__clzsi2' > udivmoddi4.c:(.text+0x178): undefined reference to `__clzsi2' > udivmoddi4.c:(.text+0x214): undefined reference to `__ctzsi2' > udivmoddi4.c:(.text+0x240): undefined reference to `__clzsi2' > udivmoddi4.c:(.text+0x24c): undefined reference to `__clzsi2' > udivmoddi4.c:(.text+0x2c0): undefined reference to `__clzsi2' > udivmoddi4.c:(.text+0x2cc): undefined reference to `__clzsi2' > /usr/obj/arm.arm/usr/src/tmp/usr/lib/libstand.a(udivsi3.o): In function > `__aeabi_uidiv': > udivsi3.c:(.text+0x1c): undefined reference to `__clzsi2' > /usr/obj/arm.arm/usr/src/tmp/usr/lib/libstand.a(udivsi3.o):udivsi3.c:(.text+0x28): > more undefined references to `__clzsi2' follow > *** [ubldr] Error code 1 > 1 error > *** [all] Error code 2 > 1 error > *** [all] Error code 2 > 1 error > *** [all] Error code 2 > 1 error > *** [sys.all__D] Error code 2 > 1 error > *** [everything] Error code 2 > 1 error > *** [buildworld] Error code 2 > 1 error > > If you need more info please tell. > > Ronald. I saw the commit to libstand. http://svnweb.freebsd.org/base?view=revision&revision=247912 Buildworld and buildkernel complete correctly now. I can test an install at the end of next week. Ronald. From owner-freebsd-arm@FreeBSD.ORG Thu Mar 7 15:36:40 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C009B7A for ; Thu, 7 Mar 2013 15:36:40 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 4D4F8172 for ; Thu, 7 Mar 2013 15:36:40 +0000 (UTC) Received: from [209.249.190.124] (port=58577 helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UDcs3-0006Gw-AV; Thu, 07 Mar 2013 10:36:39 -0500 Content-Type: multipart/mixed; boundary="Apple-Mail=_8B60640B-88EE-4ED8-8857-C77C3B94C5C5" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Building gettext on ARM? From: George Neville-Neil In-Reply-To: <20130307232853.2d33667b@bender> Date: Thu, 7 Mar 2013 10:36:43 -0500 Message-Id: References: <46D6567D-D7AC-4BFB-94FE-B54E87224C20@neville-neil.com> <20130307232853.2d33667b@bender> To: Andrew Turner X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com Cc: "arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 15:36:40 -0000 --Apple-Mail=_8B60640B-88EE-4ED8-8857-C77C3B94C5C5 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Mar 7, 2013, at 05:28 , Andrew Turner wrote: > On Tue, 5 Mar 2013 22:08:25 -0500 > George Neville-Neil wrote: > >> Howdy, >> >> I believe this is an issue that may run deeper than just gettext: >> >> ===> Building for gettext-0.18.1.1 >> Making all in gnulib-local >> Making all in gettext-runtime >> make all-recursive >> Making all in doc >> Making all in intl >> /bin/sh /usr/local/bin/libtool --tag=CC --mode=compile cc -c >> -DLOCALEDIR=\"/usr/local/share/locale\" >> -DLOCALE_ALIAS_PATH=\"/usr/local/share/locale\" >> -DLIBDIR=\"/usr/local/lib\" -DBUILDING_LIBINTL -DBUILDING_DLL >> -DIN_LIBINTL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY >> -DINSTALLDIR=\"/usr/local/lib\" -DNO_XMALLOC >> -Dset_relocation_prefix=libintl_set_relocation_prefix >> -Drelocate=libintl_relocate -DDEPENDS_ON_LIBICONV=1 -DHAVE_CONFIG_H >> -I. -I. -I.. -I/usr/local/include -O -pipe >> -fvisibility=hidden ./bindtextdom.c libtool: compile: cc -c >> -DLOCALEDIR=\"/usr/local/share/locale\" >> -DLOCALE_ALIAS_PATH=\"/usr/local/share/locale\" >> -DLIBDIR=\"/usr/local/lib\" -DBUILDING_LIBINTL -DBUILDING_DLL >> -DIN_LIBINTL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY >> -DINSTALLDIR=\"/usr/local/lib\" -DNO_XMALLOC >> -Dset_relocation_prefix=libintl_set_relocation_prefix >> -Drelocate=libintl_relocate -DDEPENDS_ON_LIBICONV=1 -DHAVE_CONFIG_H >> -I. -I. -I.. -I/usr/local/include -O -pipe >> -fvisibility=hidden ./bindtextdom.c -fPIC -DPIC >> -o .libs/bindtextdom.o In file included >> from ./bindtextdom.c:24: /usr/include/stddef.h:41: error: two or more >> data types in declaration specifiers *** [bindtextdom.lo] Signal 11 >> >> >> The offending line is: >> >> #include >> #include >> #include >> >> typedef __ptrdiff_t ptrdiff_t; <--- Line 41 >> >> Thoughts? >> Best, >> George > > I'm unable to reproduce this build failure. I am, however, running an > EABI system so that may be enough of a difference. > > Can you send me gettext-runtime/config.h and > gettext-runtime/config.log. I suspect the check for ptrdiff_t is > failing and the preprocessor is defining it as something else. > Here it is. BTW I note that it defines DITSIZEOF_PTDRIFF_T to 0. Best, George --Apple-Mail=_8B60640B-88EE-4ED8-8857-C77C3B94C5C5 Content-Disposition: attachment; filename=config.h Content-Type: application/octet-stream; x-unix-mode=0644; name="config.h" Content-Transfer-Encoding: 7bit /* config.h. Generated from config.h.in by configure. */ /* config.h.in. Generated from configure.ac by autoheader. */ /* Define if the compiler is building for multiple architectures of Apple platforms at once. */ /* #undef AA_APPLE_UNIVERSAL_BUILD */ /* Define to the number of bits in type 'ptrdiff_t'. */ #define BITSIZEOF_PTRDIFF_T 0 /* Define to the number of bits in type 'sig_atomic_t'. */ #define BITSIZEOF_SIG_ATOMIC_T 0 /* Define to the number of bits in type 'size_t'. */ #define BITSIZEOF_SIZE_T 0 /* Define to the number of bits in type 'wchar_t'. */ #define BITSIZEOF_WCHAR_T 0 /* Define to the number of bits in type 'wint_t'. */ #define BITSIZEOF_WINT_T 0 /* Define to one of `_getb67', `GETB67', `getb67' for Cray-2 and Cray-YMP systems. This function is required for `alloca.c' support on those systems. */ /* #undef CRAY_STACKSEG_END */ /* Define if mono is the preferred C# implementation. */ /* #undef CSHARP_CHOICE_MONO */ /* Define if pnet is the preferred C# implementation. */ /* #undef CSHARP_CHOICE_PNET */ /* Define to 1 if using `alloca.c'. */ /* #undef C_ALLOCA */ /* Define to 1 if // is a file system root distinct from /. */ /* #undef DOUBLE_SLASH_IS_DISTINCT_ROOT */ /* Define to 1 if translation of program messages to the user's native language is requested. */ #define ENABLE_NLS 1 /* Define to 1 if the package shall run at any location in the file system. */ /* #undef ENABLE_RELOCATABLE */ /* Define on systems for which file names may have a so-called `drive letter' prefix, define this to compute the length of that prefix, including the colon. */ #define FILE_SYSTEM_ACCEPTS_DRIVE_LETTER_PREFIX 0 /* Define if the backslash character may also serve as a file name component separator. */ #define FILE_SYSTEM_BACKSLASH_IS_FILE_NAME_SEPARATOR 0 /* Define if a drive letter prefix denotes a relative path if it is not followed by a file name component separator. */ #define FILE_SYSTEM_DRIVE_PREFIX_CAN_BE_RELATIVE 0 /* Define to 1 if realpath() can malloc memory, always gives an absolute path, and handles trailing slash correctly. */ #define FUNC_REALPATH_WORKS 1 /* Define to a C preprocessor expression that evaluates to 1 or 0, depending whether the gnulib module canonicalize-lgpl shall be considered present. */ #define GNULIB_CANONICALIZE_LGPL 1 /* Define to a C preprocessor expression that evaluates to 1 or 0, depending whether the gnulib module fwriteerror shall be considered present. */ #define GNULIB_FWRITEERROR 1 /* Define to a C preprocessor expression that evaluates to 1 or 0, depending whether the gnulib module sigpipe shall be considered present. */ #define GNULIB_SIGPIPE 1 /* Define to 1 when the gnulib module canonicalize_file_name should be tested. */ #define GNULIB_TEST_CANONICALIZE_FILE_NAME 1 /* Define to 1 when the gnulib module environ should be tested. */ #define GNULIB_TEST_ENVIRON 1 /* Define to 1 when the gnulib module getopt-gnu should be tested. */ #define GNULIB_TEST_GETOPT_GNU 1 /* Define to 1 when the gnulib module lstat should be tested. */ #define GNULIB_TEST_LSTAT 1 /* Define to 1 when the gnulib module malloc-posix should be tested. */ #define GNULIB_TEST_MALLOC_POSIX 1 /* Define to 1 when the gnulib module mbrtowc should be tested. */ #define GNULIB_TEST_MBRTOWC 1 /* Define to 1 when the gnulib module mbsinit should be tested. */ #define GNULIB_TEST_MBSINIT 1 /* Define to 1 when the gnulib module mbslen should be tested. */ #define GNULIB_TEST_MBSLEN 1 /* Define to 1 when the gnulib module mbsstr should be tested. */ #define GNULIB_TEST_MBSSTR 1 /* Define to 1 when the gnulib module memchr should be tested. */ #define GNULIB_TEST_MEMCHR 1 /* Define to 1 when the gnulib module readlink should be tested. */ #define GNULIB_TEST_READLINK 1 /* Define to 1 when the gnulib module realpath should be tested. */ #define GNULIB_TEST_REALPATH 1 /* Define to 1 when the gnulib module sigprocmask should be tested. */ #define GNULIB_TEST_SIGPROCMASK 1 /* Define to 1 when the gnulib module stat should be tested. */ #define GNULIB_TEST_STAT 1 /* Define to 1 when the gnulib module strerror should be tested. */ #define GNULIB_TEST_STRERROR 1 /* Define to 1 when the gnulib module strnlen should be tested. */ #define GNULIB_TEST_STRNLEN 1 /* Define to 1 when the gnulib module wcwidth should be tested. */ #define GNULIB_TEST_WCWIDTH 1 /* Define to 1 if you have `alloca', as a function or macro. */ #define HAVE_ALLOCA 1 /* Define to 1 if you have and it should be used (not on Ultrix). */ /* #undef HAVE_ALLOCA_H */ /* Define to 1 if you have the `argz_count' function. */ /* #undef HAVE_ARGZ_COUNT */ /* Define to 1 if you have the header file. */ /* #undef HAVE_ARGZ_H */ /* Define to 1 if you have the `argz_next' function. */ /* #undef HAVE_ARGZ_NEXT */ /* Define to 1 if you have the `argz_stringify' function. */ /* #undef HAVE_ARGZ_STRINGIFY */ /* Define to 1 if you have the `asprintf' function. */ #define HAVE_ASPRINTF 1 /* Define to 1 if you have the `atexit' function. */ #define HAVE_ATEXIT 1 /* Define to 1 if you have the header file. */ /* #undef HAVE_BP_SYM_H */ /* Define to 1 if the compiler understands __builtin_expect. */ #define HAVE_BUILTIN_EXPECT 1 /* Define to 1 if you have the `canonicalize_file_name' function. */ /* #undef HAVE_CANONICALIZE_FILE_NAME */ /* Define to 1 if you have the MacOS X function CFLocaleCopyCurrent in the CoreFoundation framework. */ /* #undef HAVE_CFLOCALECOPYCURRENT */ /* Define to 1 if you have the MacOS X function CFPreferencesCopyAppValue in the CoreFoundation framework. */ /* #undef HAVE_CFPREFERENCESCOPYAPPVALUE */ /* Define if the GNU dcgettext() function is already present or preinstalled. */ /* #undef HAVE_DCGETTEXT */ /* Define to 1 if you have the declaration of `clearerr_unlocked', and to 0 if you don't. */ #define HAVE_DECL_CLEARERR_UNLOCKED 1 /* Define to 1 if you have the declaration of `feof_unlocked', and to 0 if you don't. */ #define HAVE_DECL_FEOF_UNLOCKED 1 /* Define to 1 if you have the declaration of `ferror_unlocked', and to 0 if you don't. */ #define HAVE_DECL_FERROR_UNLOCKED 1 /* Define to 1 if you have the declaration of `fflush_unlocked', and to 0 if you don't. */ #define HAVE_DECL_FFLUSH_UNLOCKED 0 /* Define to 1 if you have the declaration of `fgets_unlocked', and to 0 if you don't. */ #define HAVE_DECL_FGETS_UNLOCKED 0 /* Define to 1 if you have the declaration of `fputc_unlocked', and to 0 if you don't. */ #define HAVE_DECL_FPUTC_UNLOCKED 0 /* Define to 1 if you have the declaration of `fputs_unlocked', and to 0 if you don't. */ #define HAVE_DECL_FPUTS_UNLOCKED 0 /* Define to 1 if you have the declaration of `fread_unlocked', and to 0 if you don't. */ #define HAVE_DECL_FREAD_UNLOCKED 0 /* Define to 1 if you have the declaration of `fwrite_unlocked', and to 0 if you don't. */ #define HAVE_DECL_FWRITE_UNLOCKED 0 /* Define to 1 if you have the declaration of `getchar_unlocked', and to 0 if you don't. */ #define HAVE_DECL_GETCHAR_UNLOCKED 1 /* Define to 1 if you have the declaration of `getc_unlocked', and to 0 if you don't. */ #define HAVE_DECL_GETC_UNLOCKED 1 /* Define to 1 if you have the declaration of `getenv', and to 0 if you don't. */ #define HAVE_DECL_GETENV 1 /* Define to 1 if you have the declaration of `getopt_clip', and to 0 if you don't. */ /* #undef HAVE_DECL_GETOPT_CLIP */ /* Define to 1 if you have the declaration of `optreset', and to 0 if you don't. */ #define HAVE_DECL_OPTRESET 1 /* Define to 1 if you have the declaration of `program_invocation_name', and to 0 if you don't. */ #define HAVE_DECL_PROGRAM_INVOCATION_NAME 0 /* Define to 1 if you have the declaration of `program_invocation_short_name', and to 0 if you don't. */ #define HAVE_DECL_PROGRAM_INVOCATION_SHORT_NAME 0 /* Define to 1 if you have the declaration of `putchar_unlocked', and to 0 if you don't. */ #define HAVE_DECL_PUTCHAR_UNLOCKED 1 /* Define to 1 if you have the declaration of `putc_unlocked', and to 0 if you don't. */ #define HAVE_DECL_PUTC_UNLOCKED 1 /* Define to 1 if you have the declaration of `strerror', and to 0 if you don't. */ /* #undef HAVE_DECL_STRERROR */ /* Define to 1 if you have the declaration of `strerror_r', and to 0 if you don't. */ #define HAVE_DECL_STRERROR_R 1 /* Define to 1 if you have the declaration of `strnlen', and to 0 if you don't. */ #define HAVE_DECL_STRNLEN 1 /* Define to 1 if you have the declaration of `wcwidth', and to 0 if you don't. */ #define HAVE_DECL_WCWIDTH 0 /* Define to 1 if you have the declaration of `_snprintf', and to 0 if you don't. */ #define HAVE_DECL__SNPRINTF 0 /* Define to 1 if you have the declaration of `_snwprintf', and to 0 if you don't. */ #define HAVE_DECL__SNWPRINTF 0 /* Define to 1 if you have the header file. */ #define HAVE_DLFCN_H 1 /* Define if you have the declaration of environ. */ /* #undef HAVE_ENVIRON_DECL */ /* Define to 1 if you have the header file. */ #define HAVE_ERRNO_H 1 /* Define to 1 if you have the `fwprintf' function. */ #define HAVE_FWPRINTF 1 /* Define to 1 if you have the `getcwd' function. */ #define HAVE_GETCWD 1 /* Define to 1 if you have the `getegid' function. */ #define HAVE_GETEGID 1 /* Define to 1 if you have the `geteuid' function. */ #define HAVE_GETEUID 1 /* Define to 1 if you have the `getgid' function. */ #define HAVE_GETGID 1 /* Define to 1 if you have the header file. */ #define HAVE_GETOPT_H 1 /* Define to 1 if you have the `getopt_long_only' function. */ #define HAVE_GETOPT_LONG_ONLY 1 /* Define to 1 if you have the `getpagesize' function. */ #define HAVE_GETPAGESIZE 1 /* Define if the GNU gettext() function is already present or preinstalled. */ /* #undef HAVE_GETTEXT */ /* Define to 1 if you have the `getuid' function. */ #define HAVE_GETUID 1 /* Define if you have the iconv() function and it works. */ #define HAVE_ICONV 1 /* Define to 1 if you have the header file. */ #define HAVE_ICONV_H 1 /* Define if you have the 'intmax_t' type in or . */ #define HAVE_INTMAX_T 1 /* Define to 1 if you have the header file. */ #define HAVE_INTTYPES_H 1 /* Define if exists, doesn't clash with , and declares uintmax_t. */ #define HAVE_INTTYPES_H_WITH_UINTMAX 1 /* Define to 1 if you have the `iswblank' function. */ #define HAVE_ISWBLANK 1 /* Define to 1 if you have the `iswcntrl' function. */ #define HAVE_ISWCNTRL 1 /* Define if you have and nl_langinfo(CODESET). */ #define HAVE_LANGINFO_CODESET 1 /* Define if your file defines LC_MESSAGES. */ #define HAVE_LC_MESSAGES 1 /* Define to 1 if you have the header file. */ #define HAVE_LIMITS_H 1 /* Define to 1 if the system has the type `long long int'. */ #define HAVE_LONG_LONG_INT 1 /* Define to 1 if you have the `lstat' function. */ #define HAVE_LSTAT 1 /* Define to 1 if you have the header file. */ /* #undef HAVE_MACH_O_DYLD_H */ /* Define if the 'malloc' function is POSIX compliant. */ #define HAVE_MALLOC_POSIX 1 /* Define to 1 if mmap()'s MAP_ANONYMOUS flag is available after including config.h and . */ #define HAVE_MAP_ANONYMOUS 1 /* Define to 1 if you have the `mbrtowc' function. */ #define HAVE_MBRTOWC 1 /* Define to 1 if you have the `mbsinit' function. */ #define HAVE_MBSINIT 1 /* Define to 1 if you have the `mbslen' function. */ /* #undef HAVE_MBSLEN */ /* Define to 1 if declares mbstate_t. */ #define HAVE_MBSTATE_T 1 /* Define to 1 if you have the `memchr' function. */ #define HAVE_MEMCHR 1 /* Define to 1 if you have the `memmove' function. */ #define HAVE_MEMMOVE 1 /* Define to 1 if you have the header file. */ #define HAVE_MEMORY_H 1 /* Define to 1 if you have the `mempcpy' function. */ /* #undef HAVE_MEMPCPY */ /* Define to 1 if you have a working `mmap' system call. */ #define HAVE_MMAP 1 /* Define to 1 if you have the `mprotect' function. */ #define HAVE_MPROTECT 1 /* Define to 1 if you have the `munmap' function. */ #define HAVE_MUNMAP 1 /* Define to 1 if you have the `newlocale' function. */ #define HAVE_NEWLOCALE 1 /* Define to 1 if you have the `pathconf' function. */ #define HAVE_PATHCONF 1 /* Define if your printf() function supports format strings with positions. */ #define HAVE_POSIX_PRINTF 1 /* Define if the defines PTHREAD_MUTEX_RECURSIVE. */ /* #undef HAVE_PTHREAD_MUTEX_RECURSIVE */ /* Define if the POSIX multithreading library has read/write locks. */ /* #undef HAVE_PTHREAD_RWLOCK */ /* Define to 1 if you have the `putenv' function. */ #define HAVE_PUTENV 1 /* Define to 1 if you have the header file. */ /* #undef HAVE_RANDOM_H */ /* Define to 1 if atoll is declared even after undefining macros. */ #define HAVE_RAW_DECL_ATOLL 1 /* Define to 1 if btowc is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_BTOWC */ /* Define to 1 if canonicalize_file_name is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_CANONICALIZE_FILE_NAME */ /* Define to 1 if chown is declared even after undefining macros. */ #define HAVE_RAW_DECL_CHOWN 1 /* Define to 1 if dprintf is declared even after undefining macros. */ #define HAVE_RAW_DECL_DPRINTF 1 /* Define to 1 if dup2 is declared even after undefining macros. */ #define HAVE_RAW_DECL_DUP2 1 /* Define to 1 if dup3 is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_DUP3 */ /* Define to 1 if endusershell is declared even after undefining macros. */ #define HAVE_RAW_DECL_ENDUSERSHELL 1 /* Define to 1 if environ is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_ENVIRON */ /* Define to 1 if euidaccess is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_EUIDACCESS */ /* Define to 1 if faccessat is declared even after undefining macros. */ #define HAVE_RAW_DECL_FACCESSAT 1 /* Define to 1 if fchdir is declared even after undefining macros. */ #define HAVE_RAW_DECL_FCHDIR 1 /* Define to 1 if fchmodat is declared even after undefining macros. */ #define HAVE_RAW_DECL_FCHMODAT 1 /* Define to 1 if fchownat is declared even after undefining macros. */ #define HAVE_RAW_DECL_FCHOWNAT 1 /* Define to 1 if fpurge is declared even after undefining macros. */ #define HAVE_RAW_DECL_FPURGE 1 /* Define to 1 if fseeko is declared even after undefining macros. */ #define HAVE_RAW_DECL_FSEEKO 1 /* Define to 1 if fstatat is declared even after undefining macros. */ #define HAVE_RAW_DECL_FSTATAT 1 /* Define to 1 if fsync is declared even after undefining macros. */ #define HAVE_RAW_DECL_FSYNC 1 /* Define to 1 if ftello is declared even after undefining macros. */ #define HAVE_RAW_DECL_FTELLO 1 /* Define to 1 if ftruncate is declared even after undefining macros. */ #define HAVE_RAW_DECL_FTRUNCATE 1 /* Define to 1 if futimens is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_FUTIMENS */ /* Define to 1 if getcwd is declared even after undefining macros. */ #define HAVE_RAW_DECL_GETCWD 1 /* Define to 1 if getdelim is declared even after undefining macros. */ #define HAVE_RAW_DECL_GETDELIM 1 /* Define to 1 if getdomainname is declared even after undefining macros. */ #define HAVE_RAW_DECL_GETDOMAINNAME 1 /* Define to 1 if getdtablesize is declared even after undefining macros. */ #define HAVE_RAW_DECL_GETDTABLESIZE 1 /* Define to 1 if getgroups is declared even after undefining macros. */ #define HAVE_RAW_DECL_GETGROUPS 1 /* Define to 1 if gethostname is declared even after undefining macros. */ #define HAVE_RAW_DECL_GETHOSTNAME 1 /* Define to 1 if getline is declared even after undefining macros. */ #define HAVE_RAW_DECL_GETLINE 1 /* Define to 1 if getloadavg is declared even after undefining macros. */ #define HAVE_RAW_DECL_GETLOADAVG 1 /* Define to 1 if getlogin is declared even after undefining macros. */ #define HAVE_RAW_DECL_GETLOGIN 1 /* Define to 1 if getlogin_r is declared even after undefining macros. */ #define HAVE_RAW_DECL_GETLOGIN_R 1 /* Define to 1 if getpagesize is declared even after undefining macros. */ #define HAVE_RAW_DECL_GETPAGESIZE 1 /* Define to 1 if getsubopt is declared even after undefining macros. */ #define HAVE_RAW_DECL_GETSUBOPT 1 /* Define to 1 if getusershell is declared even after undefining macros. */ #define HAVE_RAW_DECL_GETUSERSHELL 1 /* Define to 1 if grantpt is declared even after undefining macros. */ #define HAVE_RAW_DECL_GRANTPT 1 /* Define to 1 if initstat_r is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_INITSTAT_R */ /* Define to 1 if lchmod is declared even after undefining macros. */ #define HAVE_RAW_DECL_LCHMOD 1 /* Define to 1 if lchown is declared even after undefining macros. */ #define HAVE_RAW_DECL_LCHOWN 1 /* Define to 1 if link is declared even after undefining macros. */ #define HAVE_RAW_DECL_LINK 1 /* Define to 1 if linkat is declared even after undefining macros. */ #define HAVE_RAW_DECL_LINKAT 1 /* Define to 1 if lseek is declared even after undefining macros. */ #define HAVE_RAW_DECL_LSEEK 1 /* Define to 1 if lstat is declared even after undefining macros. */ #define HAVE_RAW_DECL_LSTAT 1 /* Define to 1 if mbrlen is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_MBRLEN */ /* Define to 1 if mbrtowc is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_MBRTOWC */ /* Define to 1 if mbsinit is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_MBSINIT */ /* Define to 1 if mbsnrtowcs is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_MBSNRTOWCS */ /* Define to 1 if mbsrtowcs is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_MBSRTOWCS */ /* Define to 1 if memmem is declared even after undefining macros. */ #define HAVE_RAW_DECL_MEMMEM 1 /* Define to 1 if mempcpy is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_MEMPCPY */ /* Define to 1 if memrchr is declared even after undefining macros. */ #define HAVE_RAW_DECL_MEMRCHR 1 /* Define to 1 if mkdirat is declared even after undefining macros. */ #define HAVE_RAW_DECL_MKDIRAT 1 /* Define to 1 if mkdtemp is declared even after undefining macros. */ #define HAVE_RAW_DECL_MKDTEMP 1 /* Define to 1 if mkfifo is declared even after undefining macros. */ #define HAVE_RAW_DECL_MKFIFO 1 /* Define to 1 if mkfifoat is declared even after undefining macros. */ #define HAVE_RAW_DECL_MKFIFOAT 1 /* Define to 1 if mknod is declared even after undefining macros. */ #define HAVE_RAW_DECL_MKNOD 1 /* Define to 1 if mknodat is declared even after undefining macros. */ #define HAVE_RAW_DECL_MKNODAT 1 /* Define to 1 if mkostemp is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_MKOSTEMP */ /* Define to 1 if mkostemps is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_MKOSTEMPS */ /* Define to 1 if mkstemp is declared even after undefining macros. */ #define HAVE_RAW_DECL_MKSTEMP 1 /* Define to 1 if mkstemps is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_MKSTEMPS */ /* Define to 1 if pipe2 is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_PIPE2 */ /* Define to 1 if popen is declared even after undefining macros. */ #define HAVE_RAW_DECL_POPEN 1 /* Define to 1 if pread is declared even after undefining macros. */ #define HAVE_RAW_DECL_PREAD 1 /* Define to 1 if ptsname is declared even after undefining macros. */ #define HAVE_RAW_DECL_PTSNAME 1 /* Define to 1 if pwrite is declared even after undefining macros. */ #define HAVE_RAW_DECL_PWRITE 1 /* Define to 1 if random_r is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_RANDOM_R */ /* Define to 1 if rawmemchr is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_RAWMEMCHR */ /* Define to 1 if readlink is declared even after undefining macros. */ #define HAVE_RAW_DECL_READLINK 1 /* Define to 1 if readlinkat is declared even after undefining macros. */ #define HAVE_RAW_DECL_READLINKAT 1 /* Define to 1 if realpath is declared even after undefining macros. */ #define HAVE_RAW_DECL_REALPATH 1 /* Define to 1 if renameat is declared even after undefining macros. */ #define HAVE_RAW_DECL_RENAMEAT 1 /* Define to 1 if rmdir is declared even after undefining macros. */ #define HAVE_RAW_DECL_RMDIR 1 /* Define to 1 if rpmatch is declared even after undefining macros. */ #define HAVE_RAW_DECL_RPMATCH 1 /* Define to 1 if setenv is declared even after undefining macros. */ #define HAVE_RAW_DECL_SETENV 1 /* Define to 1 if setstate_r is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_SETSTATE_R */ /* Define to 1 if setusershell is declared even after undefining macros. */ #define HAVE_RAW_DECL_SETUSERSHELL 1 /* Define to 1 if sigaction is declared even after undefining macros. */ #define HAVE_RAW_DECL_SIGACTION 1 /* Define to 1 if sigaddset is declared even after undefining macros. */ #define HAVE_RAW_DECL_SIGADDSET 1 /* Define to 1 if sigdelset is declared even after undefining macros. */ #define HAVE_RAW_DECL_SIGDELSET 1 /* Define to 1 if sigemptyset is declared even after undefining macros. */ #define HAVE_RAW_DECL_SIGEMPTYSET 1 /* Define to 1 if sigfillset is declared even after undefining macros. */ #define HAVE_RAW_DECL_SIGFILLSET 1 /* Define to 1 if sigismember is declared even after undefining macros. */ #define HAVE_RAW_DECL_SIGISMEMBER 1 /* Define to 1 if sigpending is declared even after undefining macros. */ #define HAVE_RAW_DECL_SIGPENDING 1 /* Define to 1 if sigprocmask is declared even after undefining macros. */ #define HAVE_RAW_DECL_SIGPROCMASK 1 /* Define to 1 if sleep is declared even after undefining macros. */ #define HAVE_RAW_DECL_SLEEP 1 /* Define to 1 if snprintf is declared even after undefining macros. */ #define HAVE_RAW_DECL_SNPRINTF 1 /* Define to 1 if srandom_r is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_SRANDOM_R */ /* Define to 1 if stat is declared even after undefining macros. */ #define HAVE_RAW_DECL_STAT 1 /* Define to 1 if stpcpy is declared even after undefining macros. */ #define HAVE_RAW_DECL_STPCPY 1 /* Define to 1 if stpncpy is declared even after undefining macros. */ #define HAVE_RAW_DECL_STPNCPY 1 /* Define to 1 if strcasestr is declared even after undefining macros. */ #define HAVE_RAW_DECL_STRCASESTR 1 /* Define to 1 if strchrnul is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_STRCHRNUL */ /* Define to 1 if strdup is declared even after undefining macros. */ #define HAVE_RAW_DECL_STRDUP 1 /* Define to 1 if strncat is declared even after undefining macros. */ #define HAVE_RAW_DECL_STRNCAT 1 /* Define to 1 if strndup is declared even after undefining macros. */ #define HAVE_RAW_DECL_STRNDUP 1 /* Define to 1 if strnlen is declared even after undefining macros. */ #define HAVE_RAW_DECL_STRNLEN 1 /* Define to 1 if strpbrk is declared even after undefining macros. */ #define HAVE_RAW_DECL_STRPBRK 1 /* Define to 1 if strsep is declared even after undefining macros. */ #define HAVE_RAW_DECL_STRSEP 1 /* Define to 1 if strsignal is declared even after undefining macros. */ #define HAVE_RAW_DECL_STRSIGNAL 1 /* Define to 1 if strtod is declared even after undefining macros. */ #define HAVE_RAW_DECL_STRTOD 1 /* Define to 1 if strtok_r is declared even after undefining macros. */ #define HAVE_RAW_DECL_STRTOK_R 1 /* Define to 1 if strtoll is declared even after undefining macros. */ #define HAVE_RAW_DECL_STRTOLL 1 /* Define to 1 if strtoull is declared even after undefining macros. */ #define HAVE_RAW_DECL_STRTOULL 1 /* Define to 1 if strverscmp is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_STRVERSCMP */ /* Define to 1 if symlink is declared even after undefining macros. */ #define HAVE_RAW_DECL_SYMLINK 1 /* Define to 1 if symlinkat is declared even after undefining macros. */ #define HAVE_RAW_DECL_SYMLINKAT 1 /* Define to 1 if tmpfile is declared even after undefining macros. */ #define HAVE_RAW_DECL_TMPFILE 1 /* Define to 1 if ttyname_r is declared even after undefining macros. */ #define HAVE_RAW_DECL_TTYNAME_R 1 /* Define to 1 if unlink is declared even after undefining macros. */ #define HAVE_RAW_DECL_UNLINK 1 /* Define to 1 if unlinkat is declared even after undefining macros. */ #define HAVE_RAW_DECL_UNLINKAT 1 /* Define to 1 if unlockpt is declared even after undefining macros. */ #define HAVE_RAW_DECL_UNLOCKPT 1 /* Define to 1 if unsetenv is declared even after undefining macros. */ #define HAVE_RAW_DECL_UNSETENV 1 /* Define to 1 if usleep is declared even after undefining macros. */ #define HAVE_RAW_DECL_USLEEP 1 /* Define to 1 if utimensat is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_UTIMENSAT */ /* Define to 1 if vdprintf is declared even after undefining macros. */ #define HAVE_RAW_DECL_VDPRINTF 1 /* Define to 1 if vsnprintf is declared even after undefining macros. */ #define HAVE_RAW_DECL_VSNPRINTF 1 /* Define to 1 if wcrtomb is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_WCRTOMB */ /* Define to 1 if wcsnrtombs is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_WCSNRTOMBS */ /* Define to 1 if wcsrtombs is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_WCSRTOMBS */ /* Define to 1 if wctob is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_WCTOB */ /* Define to 1 if wcwidth is declared even after undefining macros. */ /* #undef HAVE_RAW_DECL_WCWIDTH */ /* Define to 1 if you have the `readlink' function. */ #define HAVE_READLINK 1 /* Define to 1 if you have the `realpath' function. */ #define HAVE_REALPATH 1 /* Define to 1 if you have the header file. */ #define HAVE_SEARCH_H 1 /* Define to 1 if you have the `setenv' function. */ #define HAVE_SETENV 1 /* Define to 1 if you have the `setlocale' function. */ #define HAVE_SETLOCALE 1 /* Define to 1 if you have the header file. */ #define HAVE_SIGNAL_H 1 /* Define to 1 if 'sig_atomic_t' is a signed integer type. */ /* #undef HAVE_SIGNED_SIG_ATOMIC_T */ /* Define to 1 if 'wchar_t' is a signed integer type. */ /* #undef HAVE_SIGNED_WCHAR_T */ /* Define to 1 if 'wint_t' is a signed integer type. */ /* #undef HAVE_SIGNED_WINT_T */ /* Define to 1 if the system has the type `sigset_t'. */ /* #undef HAVE_SIGSET_T */ /* Define to 1 if you have the `snprintf' function. */ #define HAVE_SNPRINTF 1 /* Define to 1 if stdbool.h conforms to C99. */ #define HAVE_STDBOOL_H 1 /* Define to 1 if you have the header file. */ #define HAVE_STDDEF_H 1 /* Define to 1 if you have the header file. */ #define HAVE_STDINT_H 1 /* Define if exists, doesn't clash with , and declares uintmax_t. */ #define HAVE_STDINT_H_WITH_UINTMAX 1 /* Define to 1 if you have the header file. */ #define HAVE_STDIO_H 1 /* Define to 1 if you have the header file. */ #define HAVE_STDLIB_H 1 /* Define to 1 if you have the `stpcpy' function. */ #define HAVE_STPCPY 1 /* Define to 1 if you have the `strcasecmp' function. */ #define HAVE_STRCASECMP 1 /* Define to 1 if you have the `strdup' function. */ #define HAVE_STRDUP 1 /* Define to 1 if you have the `strerror_r' function. */ #define HAVE_STRERROR_R 1 /* Define to 1 if you have the header file. */ #define HAVE_STRINGS_H 1 /* Define to 1 if you have the header file. */ #define HAVE_STRING_H 1 /* Define to 1 if you have the `strnlen' function. */ #define HAVE_STRNLEN 1 /* Define to 1 if you have the `strtol' function. */ #define HAVE_STRTOL 1 /* Define to 1 if you have the `strtoul' function. */ #define HAVE_STRTOUL 1 /* Define to 1 if the system has the type `struct random_data'. */ /* #undef HAVE_STRUCT_RANDOM_DATA */ /* Define to 1 if you have the header file. */ /* #undef HAVE_SYS_BITYPES_H */ /* Define to 1 if you have the header file. */ /* #undef HAVE_SYS_INTTYPES_H */ /* Define to 1 if you have the header file. */ #define HAVE_SYS_MMAN_H 1 /* Define to 1 if you have the header file. */ #define HAVE_SYS_PARAM_H 1 /* Define to 1 if you have the header file. */ #define HAVE_SYS_SOCKET_H 1 /* Define to 1 if you have the header file. */ #define HAVE_SYS_STAT_H 1 /* Define to 1 if you have the header file. */ #define HAVE_SYS_TIME_H 1 /* Define to 1 if you have the header file. */ #define HAVE_SYS_TYPES_H 1 /* Define to 1 if you have the header file. */ #define HAVE_TIME_H 1 /* Define to 1 if you have the `tsearch' function. */ #define HAVE_TSEARCH 1 /* Define if you have the 'uintmax_t' type in or . */ #define HAVE_UINTMAX_T 1 /* Define to 1 if you have the header file. */ #define HAVE_UNISTD_H 1 /* Define to 1 if the system has the type `unsigned long long int'. */ #define HAVE_UNSIGNED_LONG_LONG_INT 1 /* Define to 1 if you have the `uselocale' function. */ #define HAVE_USELOCALE 1 /* Define to 1 or 0, depending whether the compiler supports simple visibility declarations. */ #define HAVE_VISIBILITY 1 /* Define to 1 if you have the header file. */ #define HAVE_WCHAR_H 1 /* Define if you have the 'wchar_t' type. */ #define HAVE_WCHAR_T 1 /* Define to 1 if you have the `wcrtomb' function. */ #define HAVE_WCRTOMB 1 /* Define to 1 if you have the `wcslen' function. */ #define HAVE_WCSLEN 1 /* Define to 1 if you have the `wcsnlen' function. */ #define HAVE_WCSNLEN 1 /* Define to 1 if you have the header file. */ #define HAVE_WCTYPE_H 1 /* Define to 1 if you have the `wcwidth' function. */ #define HAVE_WCWIDTH 1 /* Define to 1 if you have the header file. */ /* #undef HAVE_WINSOCK2_H */ /* Define if you have the 'wint_t' type. */ #define HAVE_WINT_T 1 /* Define to 1 if O_NOATIME works. */ #define HAVE_WORKING_O_NOATIME 0 /* Define to 1 if O_NOFOLLOW works. */ #define HAVE_WORKING_O_NOFOLLOW 1 /* Define to 1 if the system has the type `_Bool'. */ #define HAVE__BOOL 1 /* Define to 1 if you have the `_NSGetExecutablePath' function. */ /* #undef HAVE__NSGETEXECUTABLEPATH */ /* Define to 1 if you have the `__fsetlocking' function. */ /* #undef HAVE___FSETLOCKING */ /* Define as const if the declaration of iconv() needs const. */ #define ICONV_CONST const /* Define to a symbolic name denoting the flavor of iconv_open() implementation. */ /* #undef ICONV_FLAVOR */ /* Define to the value of ${prefix}, as a string. */ #define INSTALLPREFIX "/usr/local" /* Define if integer division by zero raises signal SIGFPE. */ #define INTDIV0_RAISES_SIGFPE 1 #if FILE_SYSTEM_BACKSLASH_IS_FILE_NAME_SEPARATOR # define ISSLASH(C) ((C) == '/' || (C) == '\\') #else # define ISSLASH(C) ((C) == '/') #endif /* Define to 1 if `lstat' dereferences a symlink specified with a trailing slash. */ #define LSTAT_FOLLOWS_SLASHED_SYMLINK 1 /* Define to the sub-directory in which libtool stores uninstalled libraries. */ #define LT_OBJDIR ".libs/" /* If malloc(0) is != NULL, define this to 1. Otherwise define this to 0. */ #define MALLOC_0_IS_NONNULL 1 /* Define to a substitute value for mmap()'s MAP_ANONYMOUS flag. */ /* #undef MAP_ANONYMOUS */ /* Define if the mbrtowc function has the NULL string argument bug. */ /* #undef MBRTOWC_NULL_ARG_BUG */ /* Define if the mbrtowc function does not return 0 for a NUL character. */ /* #undef MBRTOWC_NUL_RETVAL_BUG */ /* Define if the mbrtowc function returns a wrong return value. */ /* #undef MBRTOWC_RETVAL_BUG */ /* Define to 1 if your C compiler doesn't accept -c and -o together. */ /* #undef NO_MINUS_C_MINUS_O */ /* Name of package */ #define PACKAGE "gettext-runtime" /* Define to the address where bug reports for this package should be sent. */ #define PACKAGE_BUGREPORT "" /* Define to the full name of this package. */ #define PACKAGE_NAME "" /* Define to the full name and version of this package. */ #define PACKAGE_STRING "" /* Define to the one symbol short name of this package. */ #define PACKAGE_TARNAME "" /* Define to the home page for this package. */ #define PACKAGE_URL "" /* Define to the version of this package. */ #define PACKAGE_VERSION "" /* Define if exists and defines unusable PRI* macros. */ /* #undef PRI_MACROS_BROKEN */ /* Define if the pthread_in_use() detection is hard. */ /* #undef PTHREAD_IN_USE_DETECTION_HARD */ /* Define to l, ll, u, ul, ull, etc., as suitable for constants of type 'ptrdiff_t'. */ #define PTRDIFF_T_SUFFIX /* Define to 1 if readlink fails to recognize a trailing slash. */ /* #undef READLINK_TRAILING_SLASH_BUG */ /* Define to 1 if stat needs help when passed a directory name with a trailing slash */ /* #undef REPLACE_FUNC_STAT_DIR */ /* Define to 1 if stat needs help when passed a file name with a trailing slash */ /* #undef REPLACE_FUNC_STAT_FILE */ /* Define this to 1 if strerror is broken. */ /* #undef REPLACE_STRERROR */ /* Define to l, ll, u, ul, ull, etc., as suitable for constants of type 'sig_atomic_t'. */ #define SIG_ATOMIC_T_SUFFIX /* Define as the maximum value of type 'size_t', if the system doesn't define it. */ #ifndef SIZE_MAX /* # undef SIZE_MAX */ #endif /* Define to l, ll, u, ul, ull, etc., as suitable for constants of type 'size_t'. */ #define SIZE_T_SUFFIX /* If using the C implementation of alloca, define if you know the direction of stack growth for your system; otherwise it will be automatically deduced at runtime. STACK_DIRECTION > 0 => grows toward higher addresses STACK_DIRECTION < 0 => grows toward lower addresses STACK_DIRECTION = 0 => direction of growth unknown */ /* #undef STACK_DIRECTION */ /* Define to 1 if the `S_IS*' macros in do not work properly. */ /* #undef STAT_MACROS_BROKEN */ /* Define to 1 if you have the ANSI C header files. */ /* #undef STDC_HEADERS */ /* Define to 1 if strerror_r returns char *. */ /* #undef STRERROR_R_CHAR_P */ /* Define to the prefix of C symbols at the assembler and linker level, either an underscore or empty. */ #define USER_LABEL_PREFIX /* Define if the POSIX multithreading library can be used. */ /* #undef USE_POSIX_THREADS */ /* Define if references to the POSIX multithreading library should be made weak. */ /* #undef USE_POSIX_THREADS_WEAK */ /* Define if the GNU Pth multithreading library can be used. */ /* #undef USE_PTH_THREADS */ /* Define if references to the GNU Pth multithreading library should be made weak. */ /* #undef USE_PTH_THREADS_WEAK */ /* Define if the old Solaris multithreading library can be used. */ /* #undef USE_SOLARIS_THREADS */ /* Define if references to the old Solaris multithreading library should be made weak. */ /* #undef USE_SOLARIS_THREADS_WEAK */ /* Define to 1 if you want getc etc. to use unlocked I/O if available. Unlocked I/O can improve performance in unithreaded apps, but it is not safe for multithreaded apps. */ #define USE_UNLOCKED_IO 1 /* Define if the Win32 multithreading API can be used. */ /* #undef USE_WIN32_THREADS */ /* Version number of package */ #define VERSION "0.18.1" /* Define to l, ll, u, ul, ull, etc., as suitable for constants of type 'wchar_t'. */ #define WCHAR_T_SUFFIX /* Define to l, ll, u, ul, ull, etc., as suitable for constants of type 'wint_t'. */ #define WINT_T_SUFFIX /* Define to 1 if on MINIX. */ /* #undef _MINIX */ /* Define to 2 if the system does not provide POSIX.1 features except with this defined. */ /* #undef _POSIX_1_SOURCE */ /* Define to 1 if you need to in order for `stat' and other things to work. */ /* #undef _POSIX_SOURCE */ /* Define to 500 only on HP-UX. */ /* #undef _XOPEN_SOURCE */ /* Enable extensions on AIX 3, Interix. */ #ifndef _ALL_SOURCE # define _ALL_SOURCE 1 #endif /* Enable GNU extensions on systems that have them. */ #ifndef _GNU_SOURCE # define _GNU_SOURCE 1 #endif /* Enable threading extensions on Solaris. */ #ifndef _POSIX_PTHREAD_SEMANTICS # define _POSIX_PTHREAD_SEMANTICS 1 #endif /* Enable extensions on HP NonStop. */ #ifndef _TANDEM_SOURCE # define _TANDEM_SOURCE 1 #endif /* Enable general extensions on Solaris. */ #ifndef __EXTENSIONS__ # define __EXTENSIONS__ 1 #endif /* Define to rpl_ if the getopt replacement functions and variables should be used. */ #define __GETOPT_PREFIX rpl_ /* Define to `int' if doesn't define. */ /* #undef gid_t */ /* Define to `__inline__' or `__inline' if that's what the C compiler calls it, or to nothing if 'inline' is not supported under any name. */ #ifndef __cplusplus /* #undef inline */ #endif /* Work around a bug in Apple GCC 4.0.1 build 5465: In C99 mode, it supports the ISO C 99 semantics of 'extern inline' (unlike the GNU C semantics of earlier versions), but does not display it by setting __GNUC_STDC_INLINE__. __APPLE__ && __MACH__ test for MacOS X. __APPLE_CC__ tests for the Apple compiler and its version. __STDC_VERSION__ tests for the C99 mode. */ #if defined __APPLE__ && defined __MACH__ && __APPLE_CC__ >= 5465 && !defined __cplusplus && __STDC_VERSION__ >= 199901L && !defined __GNUC_STDC_INLINE__ # define __GNUC_STDC_INLINE__ 1 #endif /* Define to a type if does not define. */ /* #undef mbstate_t */ /* Define to the type of st_nlink in struct stat, or a supertype. */ /* #undef nlink_t */ /* Define as the type of the result of subtracting two pointers, if the system doesn't define it. */ #define ptrdiff_t long /* Define to the equivalent of the C99 'restrict' keyword, or to nothing if this is not supported. Do not define if restrict is supported directly. */ #define restrict __restrict /* Work around a bug in Sun C++: it does not support _Restrict or __restrict__, even though the corresponding Sun C compiler ends up with "#define restrict _Restrict" or "#define restrict __restrict__" in the previous line. Perhaps some future version of Sun C++ will work with restrict; if so, hopefully it defines __RESTRICT like Sun C does. */ #if defined __SUNPRO_CC && !defined __RESTRICT # define _Restrict # define __restrict__ #endif /* Define to `unsigned int' if does not define. */ /* #undef size_t */ /* Define as a signed type of the same size as size_t. */ /* #undef ssize_t */ /* Define to `int' if doesn't define. */ /* #undef uid_t */ /* Define to unsigned long or unsigned long long if and don't define. */ /* #undef uintmax_t */ /* Define as a marker that can be attached to declarations that might not be used. This helps to reduce warnings, such as from GCC -Wunused-parameter. */ #if __GNUC__ >= 3 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 7) # define _GL_UNUSED __attribute__ ((__unused__)) #else # define _GL_UNUSED #endif /* The name _UNUSED_PARAMETER_ is an earlier spelling, although the name is a misnomer outside of parameter lists. */ #define _UNUSED_PARAMETER_ _GL_UNUSED #define __libc_lock_t gl_lock_t #define __libc_lock_define gl_lock_define #define __libc_lock_define_initialized gl_lock_define_initialized #define __libc_lock_init gl_lock_init #define __libc_lock_lock gl_lock_lock #define __libc_lock_unlock gl_lock_unlock #define __libc_lock_recursive_t gl_recursive_lock_t #define __libc_lock_define_recursive gl_recursive_lock_define #define __libc_lock_define_initialized_recursive gl_recursive_lock_define_initialized #define __libc_lock_init_recursive gl_recursive_lock_init #define __libc_lock_lock_recursive gl_recursive_lock_lock #define __libc_lock_unlock_recursive gl_recursive_lock_unlock #define glthread_in_use libintl_thread_in_use #define glthread_lock_init_func libintl_lock_init_func #define glthread_lock_lock_func libintl_lock_lock_func #define glthread_lock_unlock_func libintl_lock_unlock_func #define glthread_lock_destroy_func libintl_lock_destroy_func #define glthread_rwlock_init_multithreaded libintl_rwlock_init_multithreaded #define glthread_rwlock_init_func libintl_rwlock_init_func #define glthread_rwlock_rdlock_multithreaded libintl_rwlock_rdlock_multithreaded #define glthread_rwlock_rdlock_func libintl_rwlock_rdlock_func #define glthread_rwlock_wrlock_multithreaded libintl_rwlock_wrlock_multithreaded #define glthread_rwlock_wrlock_func libintl_rwlock_wrlock_func #define glthread_rwlock_unlock_multithreaded libintl_rwlock_unlock_multithreaded #define glthread_rwlock_unlock_func libintl_rwlock_unlock_func #define glthread_rwlock_destroy_multithreaded libintl_rwlock_destroy_multithreaded #define glthread_rwlock_destroy_func libintl_rwlock_destroy_func #define glthread_recursive_lock_init_multithreaded libintl_recursive_lock_init_multithreaded #define glthread_recursive_lock_init_func libintl_recursive_lock_init_func #define glthread_recursive_lock_lock_multithreaded libintl_recursive_lock_lock_multithreaded #define glthread_recursive_lock_lock_func libintl_recursive_lock_lock_func #define glthread_recursive_lock_unlock_multithreaded libintl_recursive_lock_unlock_multithreaded #define glthread_recursive_lock_unlock_func libintl_recursive_lock_unlock_func #define glthread_recursive_lock_destroy_multithreaded libintl_recursive_lock_destroy_multithreaded #define glthread_recursive_lock_destroy_func libintl_recursive_lock_destroy_func #define glthread_once_func libintl_once_func #define glthread_once_singlethreaded libintl_once_singlethreaded #define glthread_once_multithreaded libintl_once_multithreaded /* On Windows, variables that may be in a DLL must be marked specially. */ #if (defined _MSC_VER && defined _DLL) && !defined IN_RELOCWRAPPER # define DLL_VARIABLE __declspec (dllimport) #else # define DLL_VARIABLE #endif /* Extra OS/2 (emx+gcc) defines. */ #ifdef __EMX__ # include "intl/os2compat.h" #endif --Apple-Mail=_8B60640B-88EE-4ED8-8857-C77C3B94C5C5 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_8B60640B-88EE-4ED8-8857-C77C3B94C5C5-- From owner-freebsd-arm@FreeBSD.ORG Thu Mar 7 20:29:39 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 95ED9989 for ; Thu, 7 Mar 2013 20:29:39 +0000 (UTC) (envelope-from jkwilborn@gmail.com) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by mx1.freebsd.org (Postfix) with ESMTP id 492C214C for ; Thu, 7 Mar 2013 20:29:39 +0000 (UTC) Received: by mail-oa0-f53.google.com with SMTP id m1so1146005oag.12 for ; Thu, 07 Mar 2013 12:29:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=xq9NyK5GHL0MUnlO0WJe2RAWoZRxFSfV3TOqlS7CYh8=; b=hSfq9mWjBuXKmX6oV8RrBQUfJOSq2+YWu9Qy5fwDpPp4T514H0TAgdfF2f5FrIoNJK qhblo/MZUBuaZkgJhZgJ1w7M+T+dB19duYshLjQRau0Wyatdwdtv45ACyE1+BtKMt7Ab 8DHc5KlMllxN3tvH1YQC2fvwQANLbLUsPMdfAIcE1ulm4kUaF3h2IvMhvksxMENZYE7T Gm1R7PVkYMEvcI9qrlYyqXkk4GGxdJmmxKW5OZleQ9AuZNZNqnFGpd0xxJsePTT2mJrI zqtdRFj868x0jttxE7Hk1WLQpOHfOlBH0oIzrZqN2MBpVajamHdYAJleLUHaaLs5+lvC s/gg== MIME-Version: 1.0 X-Received: by 10.182.144.6 with SMTP id si6mr26976784obb.38.1362688172881; Thu, 07 Mar 2013 12:29:32 -0800 (PST) Received: by 10.60.78.202 with HTTP; Thu, 7 Mar 2013 12:29:32 -0800 (PST) Date: Thu, 7 Mar 2013 13:29:32 -0700 Message-ID: Subject: Monitor Rom commands From: Jack Wilborn To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 20:29:39 -0000 Hello, I have a Global Scale Technologies Dreamplug which has a Marvell 88F6281 CPU. This computer comes up with a low level prompt of Marvell> I can get a quick synopsis of the command with the keyword 'help' or '?' but I would really like to have some real documentation on the commands. Some of the commands can be accessed by 'help command', but the help is pretty limited. I've asked the companies, but no reply. I guess it's once you buy it you're on your own? You would think they would publish this in many places, but no such luck! If anyone has or knows where these documents are, please send me a link or something so I can do more than guess at the parameter list! Thanks Jack From owner-freebsd-arm@FreeBSD.ORG Thu Mar 7 20:41:28 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 07950349 for ; Thu, 7 Mar 2013 20:41:28 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id BDA331CC for ; Thu, 7 Mar 2013 20:41:27 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UDhcv-000Iz1-Bz; Thu, 07 Mar 2013 20:41:21 +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 r27KfJfk004984; Thu, 7 Mar 2013 13:41:19 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/yPpNbZNsJrcTHg6Z5z7qK Subject: Re: Monitor Rom commands From: Ian Lepore To: Jack Wilborn In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Thu, 07 Mar 2013 13:41:18 -0700 Message-ID: <1362688878.1291.174.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 20:41:28 -0000 On Thu, 2013-03-07 at 13:29 -0700, Jack Wilborn wrote: > Hello, I have a Global Scale Technologies Dreamplug which has a > Marvell 88F6281 CPU. This computer comes up with a low level prompt > of > > Marvell> > > I can get a quick synopsis of the command with the keyword 'help' or > '?' but I would really like to have some real documentation on the > commands. Some of the commands can be accessed by 'help command', but > the help is pretty limited. I've asked the companies, but no reply. > I guess it's once you buy it you're on your own? > > You would think they would publish this in many places, but no such luck! > > If anyone has or knows where these documents are, please send me a > link or something so I can do more than guess at the parameter list! > > Thanks > That prompt is coming from the u-boot software that's in flash. General documentation on u-boot is at http://www.denx.de/wiki/DULG/Manual but be aware that u-boot is vastly configurable, and so not everything in the docs will be available on the DreamPlug. We have a freebsd wiki page with some info (which is seriously out of date) at https://wiki.freebsd.org/FreeBSDMarvell I have a couple DreamPlug units here and can answer questions about using freebsd on them. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Mar 8 02:35:49 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 61D53E3E for ; Fri, 8 Mar 2013 02:35:49 +0000 (UTC) (envelope-from kientzle@freebsd.org) 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 0C1341DE for ; Fri, 8 Mar 2013 02:35:48 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r282Zehq098333 for freebsd-arm@freebsd.org; Fri, 8 Mar 2013 02:35:40 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id sixtms58a8dfzm5aqbu54gtbps; for freebsd-arm@freebsd.org; Fri, 08 Mar 2013 02:35:40 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: multipart/signed; boundary="Apple-Mail=_BE493368-E27C-4161-B82D-9882D690463A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: profclock overrides? Date: Thu, 7 Mar 2013 18:35:40 -0800 Message-Id: <63983A6C-0D9F-46D1-BC4E-F7EE717EC676@freebsd.org> To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 02:35:49 -0000 --Apple-Mail=_BE493368-E27C-4161-B82D-9882D690463A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As part of my poking and prodding towards a GENERIC kernel, I'm trying to see what happens when I actually combine the sources for different ARM systems together. Here's one problem that seems to appear with a lot of the ARM systems: ixp425_timer.o: In function `cpu_startprofclock': = /usr/home/tim/projects/FreeBSD/svn/head/sys/arm/xscale/ixp425/ixp425_timer= .c:263: multiple definition of `cpu_startprofclock' = kern_clocksource.o:/usr/home/tim/projects/FreeBSD/svn/head/sys/kern/kern_c= locksource.c:734: first defined here ixp425_timer.o: In function `cpu_stopprofclock': = /usr/home/tim/projects/FreeBSD/svn/head/sys/arm/xscale/ixp425/ixp425_timer= .c:268: multiple definition of `cpu_stopprofclock' = kern_clocksource.o:/usr/home/tim/projects/FreeBSD/svn/head/sys/kern/kern_c= locksource.c:754: first defined here It looks like a bunch of systems have overridden these two functions in order to disable the profclock. Is this an intrinsic board difference (that should be included in board/SoC-specific startup vectors), or is there a better way to do this? Tim --Apple-Mail=_BE493368-E27C-4161-B82D-9882D690463A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQEcBAEBAgAGBQJROU59AAoJEGMNyGo0rfFBlo4H/R5hNAI/eApEeEff6lkAIkMS PJ9cEbsQxSscyitZl4IOmYvUHHryMUSMQ8j7N/vZbvd8RgIx3tj33kO5QyEJxN8h ViHxmNG3hBMaLfH+9SXPLzbH74JsuIBBeBVdoleZ0OfwX8HYKLVwENiUbuJPSRm7 YpeEHAzlIXByVPa0ICfBzvii0YpaLIk6lKjlGyLJAYswM+YturbCSIAafOqo2uq/ GjpL9CQL44LF9OL8Nut9FQsEfa1nHoI57YSFe39UyD3CGDDcoT8VaQ32cifE3jU9 5Jzk00XPpsK36fVrhc/2K2X5UJW5QzmBCoNrsLfbFBCiDZkXlC4OmhljkXk0de8= =B2sC -----END PGP SIGNATURE----- --Apple-Mail=_BE493368-E27C-4161-B82D-9882D690463A-- From owner-freebsd-arm@FreeBSD.ORG Fri Mar 8 07:12:47 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2A32493A for ; Fri, 8 Mar 2013 07:12:47 +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 C4CE3D03 for ; Fri, 8 Mar 2013 07:12:45 +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 r2874GIP022070 for ; Fri, 8 Mar 2013 02:04:16 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Fri, 8 Mar 2013 02:04:16 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: binutils build on arm failure Message-ID: <20130308020416.070905d3@ivory.wynn.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.15; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 07:12:47 -0000 Greeting- Has anyone gotten binutils to compile on armv6? So far I have no joy. After adding armv6-*-freebsd* to config.bfd my next error was: checking for cos in -lm... yes *** Configuration armv6-portbld-freebsd10.0 is obsolete. *** Support has been REMOVED. gmake[1]: *** [configure-bfd] Error 1 gmake[1]: Leaving directory `/export/ports/devel/binutils/work/binutils-2.23.1' gmake: *** [all] Error 2 Ideas? -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 Gun Control: The theory that a woman found dead in an alley, raped and strangled with her own pantyhose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound From owner-freebsd-arm@FreeBSD.ORG Fri Mar 8 07:24:23 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D6373A20 for ; Fri, 8 Mar 2013 07:24:23 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by mx1.freebsd.org (Postfix) with ESMTP id AF0FFD71 for ; Fri, 8 Mar 2013 07:24:23 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id k13so1646048iea.35 for ; Thu, 07 Mar 2013 23:24:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=GK+7L6xO6SnBBNd57A9Zj8UOiVIyt+9bSqxIxb1s+y4=; b=Zzh+U9eDdWzWaMXbEteGMFwuhNJrtaid5yBWh3mvu1U2OoYx70kwxxyNWPRyHhWO8w Dd7Q9DhAAs9PVmYmlnS7icGp5nOGwq3KVeMufcsEN5u5kl5/A2ZTNCze35IX3Ri0AWYp OVG0kTwJ1qkPApGy+CAhcPGSBVnwMCYuEFI19dsAGi2hSAVq2KbjvLegTqk07iXlz/XL Pr9KagFYxPvAqDKsgWrrj8Nks92rOkbCrL2fWcqItiZP7cc9+fY21wq8gQKmtuJApZbm /1H8wWLunPp2lBdvRJjPRIhwzcnUdH/hxFGTDSqCVMXk5JpbYsYwYpj1inl7sgHYDhiu AXzg== X-Received: by 10.50.207.39 with SMTP id lt7mr860118igc.110.1362727463359; Thu, 07 Mar 2013 23:24:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.43.58.133 with HTTP; Thu, 7 Mar 2013 23:23:43 -0800 (PST) From: "Lundberg, Johannes" Date: Fri, 8 Mar 2013 16:23:43 +0900 Message-ID: Subject: Freescale i.MX6 To: freebsd-arm@freebsd.org X-Gm-Message-State: ALoCoQmgRAc8D7yM9VMNh9t5JQlW7rZw/v2ZW1+8R7wWKjusPu9YErgqmQZqWfBW/K6GuxkQL429 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 07:24:23 -0000 Hi all! Can anyone tell me if the Freescale i.MX6 is supported or if work is in progress to support it? Thanks! Johannes Lundberg BRILLIANTSERVICE CO., LTD. From owner-freebsd-arm@FreeBSD.ORG Fri Mar 8 12:58:02 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F3379DEC for ; Fri, 8 Mar 2013 12:58:01 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by mx1.freebsd.org (Postfix) with ESMTP id B5B32F3C for ; Fri, 8 Mar 2013 12:58:01 +0000 (UTC) Received: by mail-qe0-f54.google.com with SMTP id i11so935801qej.41 for ; Fri, 08 Mar 2013 04:57:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=XUxQ/NdldGx55onYbHn7pFUjEsgab1bRHPieJAbWbrc=; b=Rapp71sD/ng4GBkikXunpOekop+joGtQBGL0cuh7relq5JTVcFGa0mIdt7dMbytj0f jn9/3CLLkYgBC6NzZLgh195mKCBr1/+fpx+z19LBFcIVvUISJrsvhVsqWDZrE2ywKpaE lGQm3sD6gE2+qp/9U998sE4t1avAPUPjDocNQmnAy+HRIT4F64vQIW0PEYDOo/k13LZo W/HM+2lq1h85PnzVXKhccb6c88Bvj9PdbI3ZLTPWFeBD59SROsBaI9O1KHOh8t7Fmfs4 wZ+kha10aQapr35lbNVl6TJAMHwxwo6NmFWWuC3pMVwCP0dm5p7WK86YmnJVbYoNdHPN yivQ== MIME-Version: 1.0 X-Received: by 10.49.95.138 with SMTP id dk10mr3258457qeb.43.1362747474960; Fri, 08 Mar 2013 04:57:54 -0800 (PST) Received: by 10.49.87.193 with HTTP; Fri, 8 Mar 2013 04:57:54 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Mar 2013 20:57:54 +0800 Message-ID: Subject: Re: Freescale i.MX6 From: Alie Tan To: "Lundberg, Johannes" X-Gm-Message-State: ALoCoQnM8HxmaQkzSpGGM+uGaYEaX6ImFj6YPpqNMrpuYbJTHzPNLGQEnyGmG3Nl37F22s0jko1z Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 12:58:02 -0000 No we don't have it but we do have i.MX515 support for Efika MX and Smartbook: http://svnweb.freebsd.org/base/projects/efika_mx/ http://raybsd.blogspot.sg/ On Fri, Mar 8, 2013 at 3:23 PM, Lundberg, Johannes < johannes@brilliantservice.co.jp> wrote: > Hi all! > > Can anyone tell me if the Freescale i.MX6 is supported or if work is in > progress to support it? > > Thanks! > > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. > _______________________________________________ > 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 Mar 8 13:31:12 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E556A124 for ; Fri, 8 Mar 2013 13:31:12 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id BA18115C for ; Fri, 8 Mar 2013 13:31:12 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id 17so1943691iea.40 for ; Fri, 08 Mar 2013 05:31:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=5+k1yjxEWZ/Kz5CbEpPxj+UzojinvrKRYnL0YFizdmQ=; b=f2aKQnyKR62qL7RuFIOJBaJ/dG+/11XbHdYGYICrtbH1gwDNVw9+uyv8I0hBhWgiZ4 nAcQDqsH38Ftz7DVkvycN7w1zj0GFuYBxHD77leJjAL7RFJfLZsXQrSX/9ODdzmb/8pr 4cA4zhfkhhmC0IrCkpipihZNHq7+QPK4KnAypZ5HXADf+HHy/yuQenRthU1KfYrZdYQc a+FGyzisrYuIUcsblJVP3Xv9b9rgop+DyIR9Zd37w+yfkYB11OHPh6c/5DcDjx7ZwQ4f 2+JsRUNCuW4aWWb+1DVVQy5pz2YJ9WNMPYjtFtIvjhNvhV3gLfnokAvnyLSN/PW3kvTT uLXw== MIME-Version: 1.0 X-Received: by 10.42.215.196 with SMTP id hf4mr1135219icb.23.1362749472343; Fri, 08 Mar 2013 05:31:12 -0800 (PST) Received: by 10.43.58.133 with HTTP; Fri, 8 Mar 2013 05:31:12 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Mar 2013 22:31:12 +0900 Message-ID: Subject: Re: Freescale i.MX6 From: "Lundberg, Johannes" To: Alie Tan X-Gm-Message-State: ALoCoQnfFli7WnJRf8qla44E9dhW8VUZ74e5JKAr3yfhKmhWF48LrG972D25Bcny+8BcBsf/y7J2 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 13:31:13 -0000 Thank you. Do anyone know how much it would take to get running on iMX6 quad core? On Friday, March 8, 2013, Alie Tan wrote: > No we don't have it but we do have i.MX515 support for Efika MX and > Smartbook: > http://svnweb.freebsd.org/base/projects/efika_mx/ > http://raybsd.blogspot.sg/ > > > On Fri, Mar 8, 2013 at 3:23 PM, Lundberg, Johannes < > johannes@brilliantservice.co.jp 'johannes@brilliantservice.co.jp');>> wrote: > >> Hi all! >> >> Can anyone tell me if the Freescale i.MX6 is supported or if work is in >> progress to support it? >> >> Thanks! >> >> Johannes Lundberg >> BRILLIANTSERVICE CO., LTD. >> _______________________________________________ >> freebsd-arm@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 >> " >> > > -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. From owner-freebsd-arm@FreeBSD.ORG Fri Mar 8 17:22:17 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1DAE335A for ; Fri, 8 Mar 2013 17:22:17 +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 F41226FD for ; Fri, 8 Mar 2013 17:22:16 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r28HMCmK002681; Fri, 8 Mar 2013 17:22:12 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 94ahuq9rdi7yqbjydcnvxphv8w; Fri, 08 Mar 2013 17:22:12 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: binutils build on arm failure Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20130308020416.070905d3@ivory.wynn.com> Date: Fri, 8 Mar 2013 09:22:10 -0800 Content-Transfer-Encoding: 7bit Message-Id: <164FD950-FA52-483F-B240-ACB057010CA8@kientzle.com> References: <20130308020416.070905d3@ivory.wynn.com> To: Brett Wynkoop X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 17:22:17 -0000 On Mar 7, 2013, at 11:04 PM, Brett Wynkoop wrote: > Greeting- > > Has anyone gotten binutils to compile on armv6? So far I have no joy. > > After adding armv6-*-freebsd* to config.bfd my next error was: > > checking for cos in -lm... yes > *** Configuration armv6-portbld-freebsd10.0 is obsolete. > *** Support has been REMOVED. > gmake[1]: *** [configure-bfd] Error 1 > gmake[1]: Leaving directory > `/export/ports/devel/binutils/work/binutils-2.23.1' gmake: *** [all] > Error 2 Sounds like the "freebsd1" problem that ports folks were struggling with a little while ago. (A lot of autotools-based programs were reading "freebsd10" as "freebsd1" when they tried to configure.) I would ask the binutils maintainer about this. Tim From owner-freebsd-arm@FreeBSD.ORG Fri Mar 8 17:37:49 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C233F965 for ; Fri, 8 Mar 2013 17:37:49 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by mx1.freebsd.org (Postfix) with ESMTP id 906EB852 for ; Fri, 8 Mar 2013 17:37:49 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id l10so2293284oag.2 for ; Fri, 08 Mar 2013 09:37:43 -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=iBzt70+LyvC95wWX7k2bUMc60BvO/0dQQqKmPnrTPo8=; b=Gm7cMDYbPwfEAv9o2vI5O/bUtapUjxEj0GserjujqjFQIv5i88eHmE0oMEajIuPTyg /6jqI9WzOhDQmmJt0Zavdq1r88mUdxLzwjvJ6kDFfW+ke2RKiSQi5iP3euG44sZ75Nd6 svnMNfHxfH2q8+hD8ZmPdeWNe8ti2oIhAxDu7ES0UpQEzbfh96XZ0amdAuvbcv7Fml3V Gh98H+Bz7kfn8A3z1aHyuJNyy51NlVtTpJz/jtOcou7120kYcBfLVBdbuRNAQq7m8s4y alMqPLZo70UDeONycTTQtkeX2YMvMwW+fq16DJJsWnQBZaWTqO4/myRW5jaU14kzRD81 on2g== X-Received: by 10.182.146.42 with SMTP id sz10mr2283583obb.83.1362764263167; Fri, 08 Mar 2013 09:37:43 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id qk4sm6363672obc.5.2013.03.08.09.37.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Mar 2013 09:37:41 -0800 (PST) Sender: Warner Losh Subject: Re: profclock overrides? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <63983A6C-0D9F-46D1-BC4E-F7EE717EC676@freebsd.org> Date: Fri, 8 Mar 2013 10:37:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8437A197-5345-458E-8132-78FF0A2CF210@bsdimp.com> References: <63983A6C-0D9F-46D1-BC4E-F7EE717EC676@freebsd.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnKQYDSNiYBagEMjQEhKFfaog4Cy6uXLBbniG/F7gBlwsniRqLjspPkBDUO2h4CK3eR26W/ Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 17:37:49 -0000 On Mar 7, 2013, at 7:35 PM, Tim Kientzle wrote: > As part of my poking and prodding towards a GENERIC kernel, I'm > trying to see what happens when I actually combine the sources for > different ARM systems together. >=20 > Here's one problem that seems to appear with a lot of the ARM systems: >=20 > ixp425_timer.o: In function `cpu_startprofclock': > = /usr/home/tim/projects/FreeBSD/svn/head/sys/arm/xscale/ixp425/ixp425_timer= .c:263: multiple definition of `cpu_startprofclock' > = kern_clocksource.o:/usr/home/tim/projects/FreeBSD/svn/head/sys/kern/kern_c= locksource.c:734: first defined here > ixp425_timer.o: In function `cpu_stopprofclock': > = /usr/home/tim/projects/FreeBSD/svn/head/sys/arm/xscale/ixp425/ixp425_timer= .c:268: multiple definition of `cpu_stopprofclock' > = kern_clocksource.o:/usr/home/tim/projects/FreeBSD/svn/head/sys/kern/kern_c= locksource.c:754: first defined here >=20 > It looks like a bunch of systems have overridden these two functions > in order to disable the profclock. >=20 > Is this an intrinsic board difference (that should be included in > board/SoC-specific startup vectors), or is there a better way to > do this? I think we should add this to a platform-sw function table that each = platform sets.... Warner From owner-freebsd-arm@FreeBSD.ORG Fri Mar 8 17:41:58 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 77089B12 for ; Fri, 8 Mar 2013 17:41:58 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 428A689F for ; Fri, 8 Mar 2013 17:41:58 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id eh20so1505911obb.36 for ; Fri, 08 Mar 2013 09:41:57 -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=MJ6PuxXqYFMq0oO4YZky8tXpaq2hIDBsM+x4D0ngbOI=; b=KJbIW1F+7d8r6lem/0t14klCR8TsFcNevfwsg90lYoVBKZSJslOGmweZfz8qk+bn4x ZaYaAEFC+9aI0tbAxH+FkyK1Us9jtthvtCHoBOL8m1TdAoLWoh4mrsbzpUzrBtU86+xK RhaQHKb+wBChIz4gXzDMPcU6MKuzAp6mtJegLkGc2Mqu9qSQTRG5UogH1ghYghjbpYpL a8NhYJs6woJsFlG/KcPPVc3RAEwb81NXMIENEQUhPHAv1XiHB9qd09nCMiX2VIONQ7j3 3uC0LNDGhxDjlT+kurszY232z6NCqQsHaXlYVg6RoQDyW4B2gnlmVMP/ZKDo2o1N56x3 2A4Q== X-Received: by 10.182.235.49 with SMTP id uj17mr2350278obc.18.1362764517844; Fri, 08 Mar 2013 09:41:57 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id ri1sm6356384obc.12.2013.03.08.09.41.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Mar 2013 09:41:56 -0800 (PST) Sender: Warner Losh Subject: Re: Freescale i.MX6 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Fri, 8 Mar 2013 10:41:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Lundberg, Johannes" X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlnugWxkLSDnBi/cWJOF+M5WGcafhO3D5sGFXwybjLldoKOBU/LWbPQcJyP/Fsvj14W+PAM Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 17:41:58 -0000 I've heard rumors of people working on at least the single core version = of this, but I don't think they are ready to commit to it publicly yet. Are you looking for something to put on the machine and run today? Or = are you looking to help with the bring-up efforts? Warner On Mar 8, 2013, at 6:31 AM, Lundberg, Johannes wrote: > Thank you. > Do anyone know how much it would take to get running on iMX6 quad = core? >=20 >=20 >=20 > On Friday, March 8, 2013, Alie Tan wrote: >=20 >> No we don't have it but we do have i.MX515 support for Efika MX and >> Smartbook: >> http://svnweb.freebsd.org/base/projects/efika_mx/ >> http://raybsd.blogspot.sg/ >>=20 >>=20 >> On Fri, Mar 8, 2013 at 3:23 PM, Lundberg, Johannes < >> johannes@brilliantservice.co.jp > 'johannes@brilliantservice.co.jp');>> wrote: >>=20 >>> Hi all! >>>=20 >>> Can anyone tell me if the Freescale i.MX6 is supported or if work is = in >>> progress to support it? >>>=20 >>> Thanks! >>>=20 >>> Johannes Lundberg >>> BRILLIANTSERVICE CO., LTD. >>> _______________________________________________ >>> freebsd-arm@freebsd.org >> 'freebsd-arm@freebsd.org');> mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org >>> " >>>=20 >>=20 >>=20 >=20 > --=20 > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. > _______________________________________________ > 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 Mar 8 17:52:29 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 299E3DA1 for ; Fri, 8 Mar 2013 17:52:29 +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 D7DD5948 for ; Fri, 8 Mar 2013 17:52:28 +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 r28HqQjN032155; Fri, 8 Mar 2013 12:52:26 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Fri, 8 Mar 2013 12:52:26 -0500 From: Brett Wynkoop To: Tim Kientzle Subject: Re: binutils build on arm failure Message-ID: <20130308125226.4f34f8b6@ivory.wynn.com> In-Reply-To: <164FD950-FA52-483F-B240-ACB057010CA8@kientzle.com> References: <20130308020416.070905d3@ivory.wynn.com> <164FD950-FA52-483F-B240-ACB057010CA8@kientzle.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.15; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 17:52:29 -0000 On Fri, 8 Mar 2013 09:22:10 -0800 Tim Kientzle wrote: > > On Mar 7, 2013, at 11:04 PM, Brett Wynkoop wrote: > > > Greeting- > > > > Has anyone gotten binutils to compile on armv6? So far I have no > > joy. > > > > After adding armv6-*-freebsd* to config.bfd my next error was: > > > > checking for cos in -lm... yes > > *** Configuration armv6-portbld-freebsd10.0 is obsolete. > > *** Support has been REMOVED. > > gmake[1]: *** [configure-bfd] Error 1 > > gmake[1]: Leaving directory > > `/export/ports/devel/binutils/work/binutils-2.23.1' gmake: *** [all] > > Error 2 > > Sounds like the "freebsd1" problem that ports folks were > struggling with a little while ago. (A lot of autotools-based > programs were reading "freebsd10" as "freebsd1" when > they tried to configure.) > > I would ask the binutils maintainer about this. > > Tim Yeah I will track down the binutils maintainer. I was hopeful to send the maintainer a fix, but it is beyond me at this point. I am trying to get zoneminder running and for some reason it wants binutils. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 Gun Control: The theory that a woman found dead in an alley, raped and strangled with her own pantyhose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound From owner-freebsd-arm@FreeBSD.ORG Fri Mar 8 18:18:46 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C1DCEF42 for ; Fri, 8 Mar 2013 18:18:46 +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 7018ECB2 for ; Fri, 8 Mar 2013 18:18:45 +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 r28IIj8A032507 for ; Fri, 8 Mar 2013 13:18:45 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Fri, 8 Mar 2013 13:18:45 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: RPi Networking Message-ID: <20130308131845.050c4734@ivory.wynn.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.15; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 18:18:46 -0000 Greeting- I built a new kernel with head from yesterday and the Pi seems to be doing a bit better on networking. It is now pinging it's neighbors in sub 10 ms times about 50% of the time and I have not lost the interface in 24 hours! Thanks kernel hackers! -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 Gun Control: The theory that a woman found dead in an alley, raped and strangled with her own pantyhose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound From owner-freebsd-arm@FreeBSD.ORG Fri Mar 8 21:47:09 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 95C3B7E0; Fri, 8 Mar 2013 21:47:09 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id 55FDCC1B; Fri, 8 Mar 2013 21:47:09 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 1C5DF1203C0; Fri, 8 Mar 2013 22:46:54 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 06E9A2848C; Fri, 8 Mar 2013 22:46:54 +0100 (CET) Date: Fri, 8 Mar 2013 22:46:53 +0100 From: Jilles Tjoelker To: Ian Lepore Subject: Re: cross-compilation of sh(1) from x86 to arm Message-ID: <20130308214653.GA50358@stack.nl> References: <20130303231931.GD21318@stack.nl> <1362582185.1291.106.camel@revolution.hippie.lan> <20130306215607.GB15814@stack.nl> <1362615054.1291.159.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1362615054.1291.159.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 21:47:09 -0000 On Wed, Mar 06, 2013 at 05:10:54PM -0700, Ian Lepore wrote: > On Wed, 2013-03-06 at 22:56 +0100, Jilles Tjoelker wrote: > > Thanks, but I'm not planning to MFC anything more to stable/8/bin/sh > > right now. (Unless you'd like to have some (compatible) change from 9.x > > or 10.x.) > Did the vfork() changes ever make it to 8? That'd be nice to have if > it's easy, don't worry about it if it's a lot of work. The vfork() change is only in head right now. I would have to MFC it to stable/9 first. Also, it depends on SHELLPROC removal (i.e. starting executable scripts without #! in a new instance of /bin/sh instead of a forked copy of the current shell) which is in stable/9 but not stable/8. I think it is not appropriate to MFC these changes right before the freeze. It may be interesting for stable/9 though. -- Jilles Tjoelker From owner-freebsd-arm@FreeBSD.ORG Sat Mar 9 00:11:17 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CC73F78D for ; Sat, 9 Mar 2013 00:11:17 +0000 (UTC) (envelope-from johannes@brilliantservice.co.jp) Received: from mail-ia0-x235.google.com (mail-ia0-x235.google.com [IPv6:2607:f8b0:4001:c02::235]) by mx1.freebsd.org (Postfix) with ESMTP id 7D99114E for ; Sat, 9 Mar 2013 00:11:17 +0000 (UTC) Received: by mail-ia0-f181.google.com with SMTP id w33so1958017iag.40 for ; Fri, 08 Mar 2013 16:11:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=whsyyaHGDLz7vowkJgAXWnE1mlNLl4L3j10VL0LORMI=; b=CTse0ggOeGzBXK4p/1ew/6qE3g93NqWT2RTqREaD4CG9zc53P6AoRO8pLX+YmkADKL d+sURB878zmz1IxH+g5TQQmnqPRTzkatGk8z04ZzXj3aAGVjyiGMYdXkR2WRGg2W+Kb0 8McYXP1/XT9Mv3nN3/SUCsODBns8FUN9+TeF1ZdwcjAfYKQ+IzYuppw7mNlwVO+uM+Og YWI+3xDqpO1Fd1qyVi7uhWtD+rcQxruglN1uu5pHtrcXvgNwzKs5J0ulFllmRjAZOKVF Qfluqks/upoIzlnBwBnm+8w7RnFZGQ0JALBlGMXiXz5aqVML7BZ34TU9fJ8ez08YgfRn UA1Q== MIME-Version: 1.0 X-Received: by 10.50.173.73 with SMTP id bi9mr863802igc.64.1362787876481; Fri, 08 Mar 2013 16:11:16 -0800 (PST) Received: by 10.43.58.133 with HTTP; Fri, 8 Mar 2013 16:11:16 -0800 (PST) Date: Sat, 9 Mar 2013 09:11:16 +0900 Message-ID: Subject: Re: Freescale i.MX6 or OMAP 5430 From: "Lundberg, Johannes" To: Warner Losh X-Gm-Message-State: ALoCoQno48MEQUCJjUTtSv8n71RKF2ULJ/0H6XVESRgpC/byqFWs1EVBXc/pMqFzD3LlLkXFz3uI Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 00:11:17 -0000 We will help with development in that case. However, using OMAP is still an option we are considering. For OMAP the 5430 seem most attractive but I'm uncertain if its supported today. On Saturday, March 9, 2013, Warner Losh wrote: > I've heard rumors of people working on at least the single core version of > this, but I don't think they are ready to commit to it publicly yet. > > Are you looking for something to put on the machine and run today? Or are > you looking to help with the bring-up efforts? > > Warner > > On Mar 8, 2013, at 6:31 AM, Lundberg, Johannes wrote: > > > Thank you. > > Do anyone know how much it would take to get running on iMX6 quad core? > > > > > > > > On Friday, March 8, 2013, Alie Tan wrote: > > > >> No we don't have it but we do have i.MX515 support for Efika MX and > >> Smartbook: > >> http://svnweb.freebsd.org/base/projects/efika_mx/ > >> http://raybsd.blogspot.sg/ > >> > >> > >> On Fri, Mar 8, 2013 at 3:23 PM, Lundberg, Johannes < > >> johannes@brilliantservice.co.jp 'cvml', > >> 'johannes@brilliantservice.co.jp ');>> wrote: > >> > >>> Hi all! > >>> > >>> Can anyone tell me if the Freescale i.MX6 is supported or if work is in > >>> progress to support it? > >>> > >>> Thanks! > >>> > >>> Johannes Lundberg > >>> BRILLIANTSERVICE CO., LTD. > >>> _______________________________________________ > >>> freebsd-arm@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 'cvml', 'freebsd-arm-unsubscribe@freebsd.org ');> > >>> " > >>> > >> > >> > > > > -- > > Johannes Lundberg > > BRILLIANTSERVICE CO., LTD. > > _______________________________________________ > > 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 > " > > -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. From owner-freebsd-arm@FreeBSD.ORG Sat Mar 9 00:15:04 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 489258F4 for ; Sat, 9 Mar 2013 00:15:04 +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 04198174 for ; Sat, 9 Mar 2013 00:15:03 +0000 (UTC) Received: from rnote.ddteam.net (248-73-135-95.pool.ukrtel.net [95.135.73.248]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 66ED5C4946; Sat, 9 Mar 2013 02:14:55 +0200 (EET) Date: Sat, 9 Mar 2013 02:14:37 +0200 From: Aleksandr Rybalko To: "Lundberg, Johannes" Subject: Re: Freescale i.MX6 Message-Id: <20130309021437.de0a9e0f.ray@freebsd.org> In-Reply-To: References: Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 00:15:04 -0000 On Fri, 8 Mar 2013 16:23:43 +0900 "Lundberg, Johannes" wrote: > Hi all! Hi Johannes! > > Can anyone tell me if the Freescale i.MX6 is supported or if work is > in progress to support it? I don't really see a big problems here. Just lack of time and HW. > > Thanks! > > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. > _______________________________________________ > 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" WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Sat Mar 9 00:44:52 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CF007D73 for ; Sat, 9 Mar 2013 00:44:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by mx1.freebsd.org (Postfix) with ESMTP id 990C6209 for ; Sat, 9 Mar 2013 00:44:52 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id h1so2770394oag.17 for ; Fri, 08 Mar 2013 16:44:46 -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=L91yKk7LVp0TWMcqWUzJhMYJZx5Z51hD9y2WD2bM7/U=; b=CSf7436orVHCdOTl6TGWbYAOZIfosgyxqcLTKIFcL6tEo9ihKrRncPD23r8Jh4JyAW ir4wMepOzeBl8oGrIhdiAGmQYJx5HTgQnOhgnXmoKLZu1hW7KFYqyCYBKLiTPjugSUeT eBiEG1ra0uW+mWJeztmAhfVaRYiHAHSEZ2ipoLMtEkSro9vMu4kYqBJJdxWhSjpjpS51 zuBG5ixYhHe2jZonw/dG3Tl4acQNqa5EdiG4zeT2AQIXBayRrsNj2KYLwHIImAURomQ6 LMHtBg/3cqjn5oJIuXzc11JF89CNj2+/BVocODWw1DV3KgJDLQ6SykWwTmN8AvT4bSOn OFRg== X-Received: by 10.60.0.194 with SMTP id 2mr3421726oeg.131.1362789886336; Fri, 08 Mar 2013 16:44:46 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id d10sm7957512obk.1.2013.03.08.16.44.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Mar 2013 16:44:45 -0800 (PST) Sender: Warner Losh Subject: Re: Freescale i.MX6 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130309021437.de0a9e0f.ray@freebsd.org> Date: Fri, 8 Mar 2013 17:44:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <73942C47-FFAA-4C97-AAC3-073DD86A9679@bsdimp.com> References: <20130309021437.de0a9e0f.ray@freebsd.org> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmMLugQgQq8uQLbsn/e7rbcEEEUiCTi62toJFOX6V2vKg9sKovpCQfk4QoiNsDGFC+TGjwW Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 00:44:52 -0000 On Mar 8, 2013, at 5:14 PM, Aleksandr Rybalko wrote: > On Fri, 8 Mar 2013 16:23:43 +0900 > "Lundberg, Johannes" wrote: >=20 >> Hi all! >=20 > Hi Johannes! >=20 >>=20 >> Can anyone tell me if the Freescale i.MX6 is supported or if work is >> in progress to support it? >=20 > I don't really see a big problems here. Just lack of time and HW. http://wandboard.org/ 512MB 1 core $79 (wanboard.org "price") 1G 2 core + wifi/bluetooth $99 (ditto) Just in case anybody wants to play around with it on the cheap. I = haven't shopped around much, but digikey seems to have them for about = 10% more ($88 in Q1) with 107 available for immediate shipping. Warner >=20 >>=20 >> Thanks! >>=20 >> Johannes Lundberg >> BRILLIANTSERVICE CO., LTD. >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >=20 > WBW > --=20 > Aleksandr Rybalko > _______________________________________________ > 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 Mar 9 00:58:11 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8C3D012D; Sat, 9 Mar 2013 00:58:11 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id 57A53260; Sat, 9 Mar 2013 00:58:11 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UE870-0007rw-GI; Sat, 09 Mar 2013 00:58:10 +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 r290w7sw006800; Fri, 8 Mar 2013 17:58:07 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18QPSInTyuqYZtdzHiEOvqg Subject: Re: Freescale i.MX6 From: Ian Lepore To: Warner Losh In-Reply-To: <73942C47-FFAA-4C97-AAC3-073DD86A9679@bsdimp.com> References: <20130309021437.de0a9e0f.ray@freebsd.org> <73942C47-FFAA-4C97-AAC3-073DD86A9679@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 08 Mar 2013 17:58:07 -0700 Message-ID: <1362790687.1291.215.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Aleksandr Rybalko , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 00:58:11 -0000 On Fri, 2013-03-08 at 17:44 -0700, Warner Losh wrote: > On Mar 8, 2013, at 5:14 PM, Aleksandr Rybalko wrote: > > > On Fri, 8 Mar 2013 16:23:43 +0900 > > "Lundberg, Johannes" wrote: > > > >> Hi all! > > > > Hi Johannes! > > > >> > >> Can anyone tell me if the Freescale i.MX6 is supported or if work is > >> in progress to support it? > > > > I don't really see a big problems here. Just lack of time and HW. > > http://wandboard.org/ > > 512MB 1 core $79 (wanboard.org "price") > 1G 2 core + wifi/bluetooth $99 (ditto) > > Just in case anybody wants to play around with it on the cheap. I haven't shopped around much, but digikey seems to have them for about 10% more ($88 in Q1) with 107 available for immediate shipping. > > Warner I ordered one of these (single core) yesterday, DigiKey shipped it today. The other place that has it for a few dollars less has them on backorder. Hopefully I'll be playing with one of these in a few days. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Mar 9 03:36:26 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2647EE60; Sat, 9 Mar 2013 03:36:26 +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 DA833925; Sat, 9 Mar 2013 03:36:25 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r293aHQ2006187; Sat, 9 Mar 2013 03:36:17 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 4jk7vnzujy3yq9ad5twz7jesin; Sat, 09 Mar 2013 03:36:17 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Freescale i.MX6 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <1362790687.1291.215.camel@revolution.hippie.lan> Date: Fri, 8 Mar 2013 19:36:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7BE5AB28-0D0E-487B-A200-83302FBE6A45@kientzle.com> References: <20130309021437.de0a9e0f.ray@freebsd.org> <73942C47-FFAA-4C97-AAC3-073DD86A9679@bsdimp.com> <1362790687.1291.215.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: Aleksandr Rybalko , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 03:36:26 -0000 On Mar 8, 2013, at 4:58 PM, Ian Lepore wrote: > On Fri, 2013-03-08 at 17:44 -0700, Warner Losh wrote: >> On Mar 8, 2013, at 5:14 PM, Aleksandr Rybalko wrote: >>=20 >>> On Fri, 8 Mar 2013 16:23:43 +0900 >>> "Lundberg, Johannes" wrote: >>>=20 >>>> Hi all! >>>=20 >>> Hi Johannes! >>>=20 >>>>=20 >>>> Can anyone tell me if the Freescale i.MX6 is supported or if work = is >>>> in progress to support it? >>>=20 >>> I don't really see a big problems here. Just lack of time and HW. >>=20 >> http://wandboard.org/ >>=20 >> 512MB 1 core $79 (wanboard.org "price") >> 1G 2 core + wifi/bluetooth $99 (ditto) >>=20 >> Just in case anybody wants to play around with it on the cheap. I = haven't shopped around much, but digikey seems to have them for about = 10% more ($88 in Q1) with 107 available for immediate shipping. >>=20 >> Warner >=20 > I ordered one of these (single core) yesterday, DigiKey shipped it > today. The other place that has it for a few dollars less has them on > backorder. >=20 > Hopefully I'll be playing with one of these in a few days. Interesting. I noted with some frustration that the Wandboard site suggests getting a power supply but doesn't say *what* power supply it uses. (What connector?) Tim From owner-freebsd-arm@FreeBSD.ORG Sat Mar 9 04:18:07 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 034F2270; Sat, 9 Mar 2013 04:18:07 +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 BB537A7D; Sat, 9 Mar 2013 04:18:06 +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 r294I5UI022707; Fri, 8 Mar 2013 23:18: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 r294I5Tj022703; Sat, 9 Mar 2013 04:18:05 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 9 Mar 2013 04:18:05 GMT Message-Id: <201303090418.r294I5Tj022703@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 04:18:07 -0000 TB --- 2013-03-09 01:30:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-09 01:30:17 - 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 --- 2013-03-09 01:30:17 - starting HEAD tinderbox run for arm/arm TB --- 2013-03-09 01:30:17 - cleaning the object tree TB --- 2013-03-09 01:30:17 - /usr/local/bin/svn stat /src TB --- 2013-03-09 01:30:21 - At svn revision 248079 TB --- 2013-03-09 01:30:22 - building world TB --- 2013-03-09 01:30:22 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 01:30:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 01:30:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 01:30:22 - SRCCONF=/dev/null TB --- 2013-03-09 01:30:22 - TARGET=arm TB --- 2013-03-09 01:30:22 - TARGET_ARCH=arm TB --- 2013-03-09 01:30:22 - TZ=UTC TB --- 2013-03-09 01:30:22 - __MAKE_CONF=/dev/null TB --- 2013-03-09 01:30:22 - cd /src TB --- 2013-03-09 01:30:22 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 9 01:30:26 UTC 2013 >>> 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 Sat Mar 9 03:19:43 UTC 2013 TB --- 2013-03-09 03:19:43 - generating LINT kernel config TB --- 2013-03-09 03:19:43 - cd /src/sys/arm/conf TB --- 2013-03-09 03:19:43 - /usr/bin/make -B LINT TB --- 2013-03-09 03:19:44 - cd /src/sys/arm/conf TB --- 2013-03-09 03:19:44 - /usr/sbin/config -m LINT TB --- 2013-03-09 03:19:44 - building LINT kernel TB --- 2013-03-09 03:19:44 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 03:19:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 03:19:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 03:19:44 - SRCCONF=/dev/null TB --- 2013-03-09 03:19:44 - TARGET=arm TB --- 2013-03-09 03:19:44 - TARGET_ARCH=arm TB --- 2013-03-09 03:19:44 - TZ=UTC TB --- 2013-03-09 03:19:44 - __MAKE_CONF=/dev/null TB --- 2013-03-09 03:19:44 - cd /src TB --- 2013-03-09 03:19:44 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 9 03:19:44 UTC 2013 >>> 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 >>> Kernel build for LINT completed on Sat Mar 9 03:39:30 UTC 2013 TB --- 2013-03-09 03:39:30 - cd /src/sys/arm/conf TB --- 2013-03-09 03:39:30 - /usr/sbin/config -m AC100 TB --- 2013-03-09 03:39:30 - skipping AC100 kernel TB --- 2013-03-09 03:39:30 - cd /src/sys/arm/conf TB --- 2013-03-09 03:39:30 - /usr/sbin/config -m ARMADAXP TB --- 2013-03-09 03:39:30 - skipping ARMADAXP kernel TB --- 2013-03-09 03:39:30 - cd /src/sys/arm/conf TB --- 2013-03-09 03:39:30 - /usr/sbin/config -m ATMEL TB --- 2013-03-09 03:39:30 - building ATMEL kernel TB --- 2013-03-09 03:39:30 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 03:39:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 03:39:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 03:39:30 - SRCCONF=/dev/null TB --- 2013-03-09 03:39:30 - TARGET=arm TB --- 2013-03-09 03:39:30 - TARGET_ARCH=arm TB --- 2013-03-09 03:39:30 - TZ=UTC TB --- 2013-03-09 03:39:30 - __MAKE_CONF=/dev/null TB --- 2013-03-09 03:39:30 - cd /src TB --- 2013-03-09 03:39:30 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Sat Mar 9 03:39:30 UTC 2013 >>> 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 >>> Kernel build for ATMEL completed on Sat Mar 9 03:43:34 UTC 2013 TB --- 2013-03-09 03:43:34 - cd /src/sys/arm/conf TB --- 2013-03-09 03:43:34 - /usr/sbin/config -m AVILA TB --- 2013-03-09 03:43:34 - skipping AVILA kernel TB --- 2013-03-09 03:43:34 - cd /src/sys/arm/conf TB --- 2013-03-09 03:43:34 - /usr/sbin/config -m BEAGLEBONE TB --- 2013-03-09 03:43:34 - skipping BEAGLEBONE kernel TB --- 2013-03-09 03:43:34 - cd /src/sys/arm/conf TB --- 2013-03-09 03:43:34 - /usr/sbin/config -m BWCT TB --- 2013-03-09 03:43:34 - building BWCT kernel TB --- 2013-03-09 03:43:34 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 03:43:34 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 03:43:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 03:43:34 - SRCCONF=/dev/null TB --- 2013-03-09 03:43:34 - TARGET=arm TB --- 2013-03-09 03:43:34 - TARGET_ARCH=arm TB --- 2013-03-09 03:43:34 - TZ=UTC TB --- 2013-03-09 03:43:34 - __MAKE_CONF=/dev/null TB --- 2013-03-09 03:43:34 - cd /src TB --- 2013-03-09 03:43:34 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Sat Mar 9 03:43:34 UTC 2013 >>> 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 >>> Kernel build for BWCT completed on Sat Mar 9 03:45:54 UTC 2013 TB --- 2013-03-09 03:45:54 - cd /src/sys/arm/conf TB --- 2013-03-09 03:45:54 - /usr/sbin/config -m CAMBRIA TB --- 2013-03-09 03:45:54 - skipping CAMBRIA kernel TB --- 2013-03-09 03:45:54 - cd /src/sys/arm/conf TB --- 2013-03-09 03:45:54 - /usr/sbin/config -m CNS11XXNAS TB --- 2013-03-09 03:45:54 - building CNS11XXNAS kernel TB --- 2013-03-09 03:45:54 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 03:45:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 03:45:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 03:45:54 - SRCCONF=/dev/null TB --- 2013-03-09 03:45:54 - TARGET=arm TB --- 2013-03-09 03:45:54 - TARGET_ARCH=arm TB --- 2013-03-09 03:45:54 - TZ=UTC TB --- 2013-03-09 03:45:54 - __MAKE_CONF=/dev/null TB --- 2013-03-09 03:45:54 - cd /src TB --- 2013-03-09 03:45:54 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Sat Mar 9 03:45:54 UTC 2013 >>> 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 >>> Kernel build for CNS11XXNAS completed on Sat Mar 9 03:48:31 UTC 2013 TB --- 2013-03-09 03:48:31 - cd /src/sys/arm/conf TB --- 2013-03-09 03:48:31 - /usr/sbin/config -m CRB TB --- 2013-03-09 03:48:31 - skipping CRB kernel TB --- 2013-03-09 03:48:31 - cd /src/sys/arm/conf TB --- 2013-03-09 03:48:31 - /usr/sbin/config -m CUBIEBOARD TB --- 2013-03-09 03:48:31 - skipping CUBIEBOARD kernel TB --- 2013-03-09 03:48:31 - cd /src/sys/arm/conf TB --- 2013-03-09 03:48:31 - /usr/sbin/config -m DB-78XXX TB --- 2013-03-09 03:48:31 - building DB-78XXX kernel TB --- 2013-03-09 03:48:31 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 03:48:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 03:48:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 03:48:31 - SRCCONF=/dev/null TB --- 2013-03-09 03:48:31 - TARGET=arm TB --- 2013-03-09 03:48:31 - TARGET_ARCH=arm TB --- 2013-03-09 03:48:31 - TZ=UTC TB --- 2013-03-09 03:48:31 - __MAKE_CONF=/dev/null TB --- 2013-03-09 03:48:31 - cd /src TB --- 2013-03-09 03:48:31 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Sat Mar 9 03:48:31 UTC 2013 >>> 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 >>> Kernel build for DB-78XXX completed on Sat Mar 9 03:51:23 UTC 2013 TB --- 2013-03-09 03:51:23 - cd /src/sys/arm/conf TB --- 2013-03-09 03:51:23 - /usr/sbin/config -m DB-88F5XXX TB --- 2013-03-09 03:51:23 - building DB-88F5XXX kernel TB --- 2013-03-09 03:51:23 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 03:51:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 03:51:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 03:51:23 - SRCCONF=/dev/null TB --- 2013-03-09 03:51:23 - TARGET=arm TB --- 2013-03-09 03:51:23 - TARGET_ARCH=arm TB --- 2013-03-09 03:51:23 - TZ=UTC TB --- 2013-03-09 03:51:23 - __MAKE_CONF=/dev/null TB --- 2013-03-09 03:51:23 - cd /src TB --- 2013-03-09 03:51:23 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Sat Mar 9 03:51:23 UTC 2013 >>> 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 >>> Kernel build for DB-88F5XXX completed on Sat Mar 9 03:54:06 UTC 2013 TB --- 2013-03-09 03:54:06 - cd /src/sys/arm/conf TB --- 2013-03-09 03:54:06 - /usr/sbin/config -m DB-88F6XXX TB --- 2013-03-09 03:54:06 - building DB-88F6XXX kernel TB --- 2013-03-09 03:54:06 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 03:54:06 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 03:54:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 03:54:06 - SRCCONF=/dev/null TB --- 2013-03-09 03:54:06 - TARGET=arm TB --- 2013-03-09 03:54:06 - TARGET_ARCH=arm TB --- 2013-03-09 03:54:06 - TZ=UTC TB --- 2013-03-09 03:54:06 - __MAKE_CONF=/dev/null TB --- 2013-03-09 03:54:06 - cd /src TB --- 2013-03-09 03:54:06 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Sat Mar 9 03:54:06 UTC 2013 >>> 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 >>> Kernel build for DB-88F6XXX completed on Sat Mar 9 03:57:03 UTC 2013 TB --- 2013-03-09 03:57:03 - cd /src/sys/arm/conf TB --- 2013-03-09 03:57:03 - /usr/sbin/config -m DOCKSTAR TB --- 2013-03-09 03:57:03 - building DOCKSTAR kernel TB --- 2013-03-09 03:57:03 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 03:57:03 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 03:57:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 03:57:03 - SRCCONF=/dev/null TB --- 2013-03-09 03:57:03 - TARGET=arm TB --- 2013-03-09 03:57:03 - TARGET_ARCH=arm TB --- 2013-03-09 03:57:03 - TZ=UTC TB --- 2013-03-09 03:57:03 - __MAKE_CONF=/dev/null TB --- 2013-03-09 03:57:03 - cd /src TB --- 2013-03-09 03:57:03 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Sat Mar 9 03:57:03 UTC 2013 >>> 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 >>> Kernel build for DOCKSTAR completed on Sat Mar 9 03:59:44 UTC 2013 TB --- 2013-03-09 03:59:44 - cd /src/sys/arm/conf TB --- 2013-03-09 03:59:44 - /usr/sbin/config -m DREAMPLUG-1001 TB --- 2013-03-09 03:59:44 - building DREAMPLUG-1001 kernel TB --- 2013-03-09 03:59:44 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 03:59:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 03:59:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 03:59:44 - SRCCONF=/dev/null TB --- 2013-03-09 03:59:44 - TARGET=arm TB --- 2013-03-09 03:59:44 - TARGET_ARCH=arm TB --- 2013-03-09 03:59:44 - TZ=UTC TB --- 2013-03-09 03:59:44 - __MAKE_CONF=/dev/null TB --- 2013-03-09 03:59:44 - cd /src TB --- 2013-03-09 03:59:44 - /usr/bin/make -B buildkernel KERNCONF=DREAMPLUG-1001 >>> Kernel build for DREAMPLUG-1001 started on Sat Mar 9 03:59:44 UTC 2013 >>> 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 >>> Kernel build for DREAMPLUG-1001 completed on Sat Mar 9 04:03:34 UTC 2013 TB --- 2013-03-09 04:03:34 - cd /src/sys/arm/conf TB --- 2013-03-09 04:03:34 - /usr/sbin/config -m EA3250 TB --- 2013-03-09 04:03:34 - building EA3250 kernel TB --- 2013-03-09 04:03:34 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 04:03:34 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 04:03:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 04:03:34 - SRCCONF=/dev/null TB --- 2013-03-09 04:03:34 - TARGET=arm TB --- 2013-03-09 04:03:34 - TARGET_ARCH=arm TB --- 2013-03-09 04:03:34 - TZ=UTC TB --- 2013-03-09 04:03:34 - __MAKE_CONF=/dev/null TB --- 2013-03-09 04:03:34 - cd /src TB --- 2013-03-09 04:03:34 - /usr/bin/make -B buildkernel KERNCONF=EA3250 >>> Kernel build for EA3250 started on Sat Mar 9 04:03:34 UTC 2013 >>> 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 >>> Kernel build for EA3250 completed on Sat Mar 9 04:06:20 UTC 2013 TB --- 2013-03-09 04:06:20 - cd /src/sys/arm/conf TB --- 2013-03-09 04:06:20 - /usr/sbin/config -m EB9200 TB --- 2013-03-09 04:06:20 - building EB9200 kernel TB --- 2013-03-09 04:06:20 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 04:06:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 04:06:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 04:06:20 - SRCCONF=/dev/null TB --- 2013-03-09 04:06:20 - TARGET=arm TB --- 2013-03-09 04:06:20 - TARGET_ARCH=arm TB --- 2013-03-09 04:06:20 - TZ=UTC TB --- 2013-03-09 04:06:20 - __MAKE_CONF=/dev/null TB --- 2013-03-09 04:06:20 - cd /src TB --- 2013-03-09 04:06:20 - /usr/bin/make -B buildkernel KERNCONF=EB9200 >>> Kernel build for EB9200 started on Sat Mar 9 04:06:20 UTC 2013 >>> 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 >>> Kernel build for EB9200 completed on Sat Mar 9 04:08:52 UTC 2013 TB --- 2013-03-09 04:08:52 - cd /src/sys/arm/conf TB --- 2013-03-09 04:08:52 - /usr/sbin/config -m EP80219 TB --- 2013-03-09 04:08:52 - skipping EP80219 kernel TB --- 2013-03-09 04:08:52 - cd /src/sys/arm/conf TB --- 2013-03-09 04:08:52 - /usr/sbin/config -m ETHERNUT5 TB --- 2013-03-09 04:08:52 - building ETHERNUT5 kernel TB --- 2013-03-09 04:08:52 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 04:08:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 04:08:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 04:08:52 - SRCCONF=/dev/null TB --- 2013-03-09 04:08:52 - TARGET=arm TB --- 2013-03-09 04:08:52 - TARGET_ARCH=arm TB --- 2013-03-09 04:08:52 - TZ=UTC TB --- 2013-03-09 04:08:52 - __MAKE_CONF=/dev/null TB --- 2013-03-09 04:08:52 - cd /src TB --- 2013-03-09 04:08:52 - /usr/bin/make -B buildkernel KERNCONF=ETHERNUT5 >>> Kernel build for ETHERNUT5 started on Sat Mar 9 04:08:52 UTC 2013 >>> 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 -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c cc1: warnings being treated as errors /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c: In function 'mesh_recv_indiv_data_to_fwrd': /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1480: warning: unused variable 'ic' [-Wunused-variable] /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c: In function 'mesh_recv_indiv_data_to_me': /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1539: warning: unused variable 'ic' [-Wunused-variable] /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c: In function 'mesh_recv_group_data': /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1606: warning: unused variable 'ic' [-Wunused-variable] *** [ieee80211_mesh.o] Error code 1 Stop in /src/sys/modules/wlan. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/arm.arm/src/sys/ETHERNUT5. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-09 04:18:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-09 04:18:05 - ERROR: failed to build ETHERNUT5 kernel TB --- 2013-03-09 04:18:05 - 8057.57 user 1463.77 system 10068.22 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 9 05:20:42 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A9DEA835; Sat, 9 Mar 2013 05:20:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id E8B93BE6; Sat, 9 Mar 2013 05:20:41 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id t57so1820493wey.13 for ; Fri, 08 Mar 2013 21:20:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0wlamhaPCHBS9s5gZptoYfVhUSkS8wpJq18CorU7jkQ=; b=scshIyB7k49iquvT04IHeNWUqFVTXY3BMhl4oEbV3hRTEzrkteHP1JqzxAL/pBky5p g/qsxo0JU3XL9E+kobPYQiRUUz+GWSI1t8NP/10+dIiGFPVsCN4PbYnOS36iy7XE9f6G D9R3KtRtHHfCIbCi545aSIjhD7PGMeOXr4+cvWs6TqJIl45FBNxL0IcNsEAktsQLCnvr JnDNhNGuBYt38+cJm0gk3Ti64iwiDFt27PJuLmP50XkqE8LpzwBGES8VMDradhGT/BgD 9pIwwS0zeNwR7RyaNfvIQtZgo88CItkaRI6R7AtwVPh2snuOND1/Un2ctkZMNYHxJZU4 CWtQ== MIME-Version: 1.0 X-Received: by 10.194.178.9 with SMTP id cu9mr8280151wjc.39.1362806439784; Fri, 08 Mar 2013 21:20:39 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.51.2 with HTTP; Fri, 8 Mar 2013 21:20:39 -0800 (PST) In-Reply-To: <201303090418.r294I5Tj022703@freebsd-current.sentex.ca> References: <201303090418.r294I5Tj022703@freebsd-current.sentex.ca> Date: Fri, 8 Mar 2013 21:20:39 -0800 X-Google-Sender-Auth: Q7vRNvpVcWq-Of_BJGjwD2ZGboc Message-ID: Subject: Re: [head tinderbox] failure on arm/arm From: Adrian Chadd To: FreeBSD Tinderbox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arm@freebsd.org, current@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 05:20:42 -0000 Fixed! Adrian On 8 March 2013 20:18, FreeBSD Tinderbox wrote: > TB --- 2013-03-09 01:30:17 - tinderbox 2.10 running on freebsd-current.se= ntex.ca > TB --- 2013-03-09 01:30:17 - FreeBSD freebsd-current.sentex.ca 8.3-PREREL= EASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebs= d-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 > TB --- 2013-03-09 01:30:17 - starting HEAD tinderbox run for arm/arm > TB --- 2013-03-09 01:30:17 - cleaning the object tree > TB --- 2013-03-09 01:30:17 - /usr/local/bin/svn stat /src > TB --- 2013-03-09 01:30:21 - At svn revision 248079 > TB --- 2013-03-09 01:30:22 - building world > TB --- 2013-03-09 01:30:22 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 01:30:22 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 01:30:22 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 01:30:22 - SRCCONF=3D/dev/null > TB --- 2013-03-09 01:30:22 - TARGET=3Darm > TB --- 2013-03-09 01:30:22 - TARGET_ARCH=3Darm > TB --- 2013-03-09 01:30:22 - TZ=3DUTC > TB --- 2013-03-09 01:30:22 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 01:30:22 - cd /src > TB --- 2013-03-09 01:30:22 - /usr/bin/make -B buildworld >>>> Building an up-to-date make(1) >>>> World build started on Sat Mar 9 01:30:26 UTC 2013 >>>> 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 Sat Mar 9 03:19:43 UTC 2013 > TB --- 2013-03-09 03:19:43 - generating LINT kernel config > TB --- 2013-03-09 03:19:43 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:19:43 - /usr/bin/make -B LINT > TB --- 2013-03-09 03:19:44 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:19:44 - /usr/sbin/config -m LINT > TB --- 2013-03-09 03:19:44 - building LINT kernel > TB --- 2013-03-09 03:19:44 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 03:19:44 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 03:19:44 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 03:19:44 - SRCCONF=3D/dev/null > TB --- 2013-03-09 03:19:44 - TARGET=3Darm > TB --- 2013-03-09 03:19:44 - TARGET_ARCH=3Darm > TB --- 2013-03-09 03:19:44 - TZ=3DUTC > TB --- 2013-03-09 03:19:44 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 03:19:44 - cd /src > TB --- 2013-03-09 03:19:44 - /usr/bin/make -B buildkernel KERNCONF=3DLINT >>>> Kernel build for LINT started on Sat Mar 9 03:19:44 UTC 2013 >>>> 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 >>>> Kernel build for LINT completed on Sat Mar 9 03:39:30 UTC 2013 > TB --- 2013-03-09 03:39:30 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:39:30 - /usr/sbin/config -m AC100 > TB --- 2013-03-09 03:39:30 - skipping AC100 kernel > TB --- 2013-03-09 03:39:30 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:39:30 - /usr/sbin/config -m ARMADAXP > TB --- 2013-03-09 03:39:30 - skipping ARMADAXP kernel > TB --- 2013-03-09 03:39:30 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:39:30 - /usr/sbin/config -m ATMEL > TB --- 2013-03-09 03:39:30 - building ATMEL kernel > TB --- 2013-03-09 03:39:30 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 03:39:30 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 03:39:30 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 03:39:30 - SRCCONF=3D/dev/null > TB --- 2013-03-09 03:39:30 - TARGET=3Darm > TB --- 2013-03-09 03:39:30 - TARGET_ARCH=3Darm > TB --- 2013-03-09 03:39:30 - TZ=3DUTC > TB --- 2013-03-09 03:39:30 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 03:39:30 - cd /src > TB --- 2013-03-09 03:39:30 - /usr/bin/make -B buildkernel KERNCONF=3DATME= L >>>> Kernel build for ATMEL started on Sat Mar 9 03:39:30 UTC 2013 >>>> 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 >>>> Kernel build for ATMEL completed on Sat Mar 9 03:43:34 UTC 2013 > TB --- 2013-03-09 03:43:34 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:43:34 - /usr/sbin/config -m AVILA > TB --- 2013-03-09 03:43:34 - skipping AVILA kernel > TB --- 2013-03-09 03:43:34 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:43:34 - /usr/sbin/config -m BEAGLEBONE > TB --- 2013-03-09 03:43:34 - skipping BEAGLEBONE kernel > TB --- 2013-03-09 03:43:34 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:43:34 - /usr/sbin/config -m BWCT > TB --- 2013-03-09 03:43:34 - building BWCT kernel > TB --- 2013-03-09 03:43:34 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 03:43:34 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 03:43:34 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 03:43:34 - SRCCONF=3D/dev/null > TB --- 2013-03-09 03:43:34 - TARGET=3Darm > TB --- 2013-03-09 03:43:34 - TARGET_ARCH=3Darm > TB --- 2013-03-09 03:43:34 - TZ=3DUTC > TB --- 2013-03-09 03:43:34 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 03:43:34 - cd /src > TB --- 2013-03-09 03:43:34 - /usr/bin/make -B buildkernel KERNCONF=3DBWCT >>>> Kernel build for BWCT started on Sat Mar 9 03:43:34 UTC 2013 >>>> 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 >>>> Kernel build for BWCT completed on Sat Mar 9 03:45:54 UTC 2013 > TB --- 2013-03-09 03:45:54 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:45:54 - /usr/sbin/config -m CAMBRIA > TB --- 2013-03-09 03:45:54 - skipping CAMBRIA kernel > TB --- 2013-03-09 03:45:54 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:45:54 - /usr/sbin/config -m CNS11XXNAS > TB --- 2013-03-09 03:45:54 - building CNS11XXNAS kernel > TB --- 2013-03-09 03:45:54 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 03:45:54 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 03:45:54 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 03:45:54 - SRCCONF=3D/dev/null > TB --- 2013-03-09 03:45:54 - TARGET=3Darm > TB --- 2013-03-09 03:45:54 - TARGET_ARCH=3Darm > TB --- 2013-03-09 03:45:54 - TZ=3DUTC > TB --- 2013-03-09 03:45:54 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 03:45:54 - cd /src > TB --- 2013-03-09 03:45:54 - /usr/bin/make -B buildkernel KERNCONF=3DCNS1= 1XXNAS >>>> Kernel build for CNS11XXNAS started on Sat Mar 9 03:45:54 UTC 2013 >>>> 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 >>>> Kernel build for CNS11XXNAS completed on Sat Mar 9 03:48:31 UTC 2013 > TB --- 2013-03-09 03:48:31 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:48:31 - /usr/sbin/config -m CRB > TB --- 2013-03-09 03:48:31 - skipping CRB kernel > TB --- 2013-03-09 03:48:31 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:48:31 - /usr/sbin/config -m CUBIEBOARD > TB --- 2013-03-09 03:48:31 - skipping CUBIEBOARD kernel > TB --- 2013-03-09 03:48:31 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:48:31 - /usr/sbin/config -m DB-78XXX > TB --- 2013-03-09 03:48:31 - building DB-78XXX kernel > TB --- 2013-03-09 03:48:31 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 03:48:31 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 03:48:31 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 03:48:31 - SRCCONF=3D/dev/null > TB --- 2013-03-09 03:48:31 - TARGET=3Darm > TB --- 2013-03-09 03:48:31 - TARGET_ARCH=3Darm > TB --- 2013-03-09 03:48:31 - TZ=3DUTC > TB --- 2013-03-09 03:48:31 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 03:48:31 - cd /src > TB --- 2013-03-09 03:48:31 - /usr/bin/make -B buildkernel KERNCONF=3DDB-7= 8XXX >>>> Kernel build for DB-78XXX started on Sat Mar 9 03:48:31 UTC 2013 >>>> 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 >>>> Kernel build for DB-78XXX completed on Sat Mar 9 03:51:23 UTC 2013 > TB --- 2013-03-09 03:51:23 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:51:23 - /usr/sbin/config -m DB-88F5XXX > TB --- 2013-03-09 03:51:23 - building DB-88F5XXX kernel > TB --- 2013-03-09 03:51:23 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 03:51:23 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 03:51:23 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 03:51:23 - SRCCONF=3D/dev/null > TB --- 2013-03-09 03:51:23 - TARGET=3Darm > TB --- 2013-03-09 03:51:23 - TARGET_ARCH=3Darm > TB --- 2013-03-09 03:51:23 - TZ=3DUTC > TB --- 2013-03-09 03:51:23 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 03:51:23 - cd /src > TB --- 2013-03-09 03:51:23 - /usr/bin/make -B buildkernel KERNCONF=3DDB-8= 8F5XXX >>>> Kernel build for DB-88F5XXX started on Sat Mar 9 03:51:23 UTC 2013 >>>> 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 >>>> Kernel build for DB-88F5XXX completed on Sat Mar 9 03:54:06 UTC 2013 > TB --- 2013-03-09 03:54:06 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:54:06 - /usr/sbin/config -m DB-88F6XXX > TB --- 2013-03-09 03:54:06 - building DB-88F6XXX kernel > TB --- 2013-03-09 03:54:06 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 03:54:06 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 03:54:06 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 03:54:06 - SRCCONF=3D/dev/null > TB --- 2013-03-09 03:54:06 - TARGET=3Darm > TB --- 2013-03-09 03:54:06 - TARGET_ARCH=3Darm > TB --- 2013-03-09 03:54:06 - TZ=3DUTC > TB --- 2013-03-09 03:54:06 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 03:54:06 - cd /src > TB --- 2013-03-09 03:54:06 - /usr/bin/make -B buildkernel KERNCONF=3DDB-8= 8F6XXX >>>> Kernel build for DB-88F6XXX started on Sat Mar 9 03:54:06 UTC 2013 >>>> 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 >>>> Kernel build for DB-88F6XXX completed on Sat Mar 9 03:57:03 UTC 2013 > TB --- 2013-03-09 03:57:03 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:57:03 - /usr/sbin/config -m DOCKSTAR > TB --- 2013-03-09 03:57:03 - building DOCKSTAR kernel > TB --- 2013-03-09 03:57:03 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 03:57:03 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 03:57:03 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 03:57:03 - SRCCONF=3D/dev/null > TB --- 2013-03-09 03:57:03 - TARGET=3Darm > TB --- 2013-03-09 03:57:03 - TARGET_ARCH=3Darm > TB --- 2013-03-09 03:57:03 - TZ=3DUTC > TB --- 2013-03-09 03:57:03 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 03:57:03 - cd /src > TB --- 2013-03-09 03:57:03 - /usr/bin/make -B buildkernel KERNCONF=3DDOCK= STAR >>>> Kernel build for DOCKSTAR started on Sat Mar 9 03:57:03 UTC 2013 >>>> 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 >>>> Kernel build for DOCKSTAR completed on Sat Mar 9 03:59:44 UTC 2013 > TB --- 2013-03-09 03:59:44 - cd /src/sys/arm/conf > TB --- 2013-03-09 03:59:44 - /usr/sbin/config -m DREAMPLUG-1001 > TB --- 2013-03-09 03:59:44 - building DREAMPLUG-1001 kernel > TB --- 2013-03-09 03:59:44 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 03:59:44 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 03:59:44 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 03:59:44 - SRCCONF=3D/dev/null > TB --- 2013-03-09 03:59:44 - TARGET=3Darm > TB --- 2013-03-09 03:59:44 - TARGET_ARCH=3Darm > TB --- 2013-03-09 03:59:44 - TZ=3DUTC > TB --- 2013-03-09 03:59:44 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 03:59:44 - cd /src > TB --- 2013-03-09 03:59:44 - /usr/bin/make -B buildkernel KERNCONF=3DDREA= MPLUG-1001 >>>> Kernel build for DREAMPLUG-1001 started on Sat Mar 9 03:59:44 UTC 201= 3 >>>> 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 >>>> Kernel build for DREAMPLUG-1001 completed on Sat Mar 9 04:03:34 UTC 2= 013 > TB --- 2013-03-09 04:03:34 - cd /src/sys/arm/conf > TB --- 2013-03-09 04:03:34 - /usr/sbin/config -m EA3250 > TB --- 2013-03-09 04:03:34 - building EA3250 kernel > TB --- 2013-03-09 04:03:34 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 04:03:34 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 04:03:34 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 04:03:34 - SRCCONF=3D/dev/null > TB --- 2013-03-09 04:03:34 - TARGET=3Darm > TB --- 2013-03-09 04:03:34 - TARGET_ARCH=3Darm > TB --- 2013-03-09 04:03:34 - TZ=3DUTC > TB --- 2013-03-09 04:03:34 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 04:03:34 - cd /src > TB --- 2013-03-09 04:03:34 - /usr/bin/make -B buildkernel KERNCONF=3DEA32= 50 >>>> Kernel build for EA3250 started on Sat Mar 9 04:03:34 UTC 2013 >>>> 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 >>>> Kernel build for EA3250 completed on Sat Mar 9 04:06:20 UTC 2013 > TB --- 2013-03-09 04:06:20 - cd /src/sys/arm/conf > TB --- 2013-03-09 04:06:20 - /usr/sbin/config -m EB9200 > TB --- 2013-03-09 04:06:20 - building EB9200 kernel > TB --- 2013-03-09 04:06:20 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 04:06:20 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 04:06:20 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 04:06:20 - SRCCONF=3D/dev/null > TB --- 2013-03-09 04:06:20 - TARGET=3Darm > TB --- 2013-03-09 04:06:20 - TARGET_ARCH=3Darm > TB --- 2013-03-09 04:06:20 - TZ=3DUTC > TB --- 2013-03-09 04:06:20 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 04:06:20 - cd /src > TB --- 2013-03-09 04:06:20 - /usr/bin/make -B buildkernel KERNCONF=3DEB92= 00 >>>> Kernel build for EB9200 started on Sat Mar 9 04:06:20 UTC 2013 >>>> 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 >>>> Kernel build for EB9200 completed on Sat Mar 9 04:08:52 UTC 2013 > TB --- 2013-03-09 04:08:52 - cd /src/sys/arm/conf > TB --- 2013-03-09 04:08:52 - /usr/sbin/config -m EP80219 > TB --- 2013-03-09 04:08:52 - skipping EP80219 kernel > TB --- 2013-03-09 04:08:52 - cd /src/sys/arm/conf > TB --- 2013-03-09 04:08:52 - /usr/sbin/config -m ETHERNUT5 > TB --- 2013-03-09 04:08:52 - building ETHERNUT5 kernel > TB --- 2013-03-09 04:08:52 - CROSS_BUILD_TESTING=3DYES > TB --- 2013-03-09 04:08:52 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2013-03-09 04:08:52 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-03-09 04:08:52 - SRCCONF=3D/dev/null > TB --- 2013-03-09 04:08:52 - TARGET=3Darm > TB --- 2013-03-09 04:08:52 - TARGET_ARCH=3Darm > TB --- 2013-03-09 04:08:52 - TZ=3DUTC > TB --- 2013-03-09 04:08:52 - __MAKE_CONF=3D/dev/null > TB --- 2013-03-09 04:08:52 - cd /src > TB --- 2013-03-09 04:08:52 - /usr/bin/make -B buildkernel KERNCONF=3DETHE= RNUT5 >>>> Kernel build for ETHERNUT5 started on Sat Mar 9 04:08:52 UTC 2013 >>>> 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 -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTI= ON_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@= /contrib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --para= m large-function-growth=3D1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT= 5 -mcpu=3Darm9 -ffreestanding -std=3Diso9899:1999 -Wall -Wredundant-decls -= Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -= Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissi= ng-include-dirs -fdiagnostics-show-option -c /src/sys/modules/wlan/../../= net80211/ieee80211_mesh.c > cc1: warnings being treated as errors > /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c: In function 'mesh_= recv_indiv_data_to_fwrd': > /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1480: warning: unus= ed variable 'ic' [-Wunused-variable] > /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c: In function 'mesh_= recv_indiv_data_to_me': > /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1539: warning: unus= ed variable 'ic' [-Wunused-variable] > /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c: In function 'mesh_= recv_group_data': > /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c:1606: warning: unus= ed variable 'ic' [-Wunused-variable] > *** [ieee80211_mesh.o] Error code 1 > > Stop in /src/sys/modules/wlan. > *** [all] Error code 1 > > Stop in /src/sys/modules. > *** [modules-all] Error code 1 > > Stop in /obj/arm.arm/src/sys/ETHERNUT5. > *** [buildkernel] Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2013-03-09 04:18:05 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2013-03-09 04:18:05 - ERROR: failed to build ETHERNUT5 kernel > TB --- 2013-03-09 04:18:05 - 8057.57 user 1463.77 system 10068.22 real > > > http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-arm@FreeBSD.ORG Sat Mar 9 14:21:05 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DAD35583; Sat, 9 Mar 2013 14:21:05 +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 74F0B383; Sat, 9 Mar 2013 14:21:05 +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 r29EL4Yd080302; Sat, 9 Mar 2013 09:21:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r29EL4Jc080297; Sat, 9 Mar 2013 14:21:04 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 9 Mar 2013 14:21:04 GMT Message-Id: <201303091421.r29EL4Jc080297@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 14:21:05 -0000 TB --- 2013-03-09 11:30:25 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-09 11:30:25 - 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 --- 2013-03-09 11:30:25 - starting HEAD tinderbox run for arm/arm TB --- 2013-03-09 11:30:25 - cleaning the object tree TB --- 2013-03-09 11:31:57 - /usr/local/bin/svn stat /src TB --- 2013-03-09 11:32:00 - At svn revision 248093 TB --- 2013-03-09 11:32:01 - building world TB --- 2013-03-09 11:32:01 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 11:32:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 11:32:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 11:32:01 - SRCCONF=/dev/null TB --- 2013-03-09 11:32:01 - TARGET=arm TB --- 2013-03-09 11:32:01 - TARGET_ARCH=arm TB --- 2013-03-09 11:32:01 - TZ=UTC TB --- 2013-03-09 11:32:01 - __MAKE_CONF=/dev/null TB --- 2013-03-09 11:32:01 - cd /src TB --- 2013-03-09 11:32:01 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Mar 9 11:32:05 UTC 2013 >>> 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 Sat Mar 9 13:22:18 UTC 2013 TB --- 2013-03-09 13:22:18 - generating LINT kernel config TB --- 2013-03-09 13:22:18 - cd /src/sys/arm/conf TB --- 2013-03-09 13:22:18 - /usr/bin/make -B LINT TB --- 2013-03-09 13:22:18 - cd /src/sys/arm/conf TB --- 2013-03-09 13:22:18 - /usr/sbin/config -m LINT TB --- 2013-03-09 13:22:18 - building LINT kernel TB --- 2013-03-09 13:22:18 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 13:22:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 13:22:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 13:22:18 - SRCCONF=/dev/null TB --- 2013-03-09 13:22:18 - TARGET=arm TB --- 2013-03-09 13:22:18 - TARGET_ARCH=arm TB --- 2013-03-09 13:22:18 - TZ=UTC TB --- 2013-03-09 13:22:18 - __MAKE_CONF=/dev/null TB --- 2013-03-09 13:22:18 - cd /src TB --- 2013-03-09 13:22:18 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 9 13:22:18 UTC 2013 >>> 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 >>> Kernel build for LINT completed on Sat Mar 9 13:42:15 UTC 2013 TB --- 2013-03-09 13:42:15 - cd /src/sys/arm/conf TB --- 2013-03-09 13:42:15 - /usr/sbin/config -m AC100 TB --- 2013-03-09 13:42:15 - skipping AC100 kernel TB --- 2013-03-09 13:42:15 - cd /src/sys/arm/conf TB --- 2013-03-09 13:42:15 - /usr/sbin/config -m ARMADAXP TB --- 2013-03-09 13:42:15 - skipping ARMADAXP kernel TB --- 2013-03-09 13:42:15 - cd /src/sys/arm/conf TB --- 2013-03-09 13:42:15 - /usr/sbin/config -m ATMEL TB --- 2013-03-09 13:42:15 - building ATMEL kernel TB --- 2013-03-09 13:42:15 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 13:42:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 13:42:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 13:42:15 - SRCCONF=/dev/null TB --- 2013-03-09 13:42:15 - TARGET=arm TB --- 2013-03-09 13:42:15 - TARGET_ARCH=arm TB --- 2013-03-09 13:42:15 - TZ=UTC TB --- 2013-03-09 13:42:15 - __MAKE_CONF=/dev/null TB --- 2013-03-09 13:42:15 - cd /src TB --- 2013-03-09 13:42:15 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Sat Mar 9 13:42:15 UTC 2013 >>> 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 >>> Kernel build for ATMEL completed on Sat Mar 9 13:46:18 UTC 2013 TB --- 2013-03-09 13:46:18 - cd /src/sys/arm/conf TB --- 2013-03-09 13:46:18 - /usr/sbin/config -m AVILA TB --- 2013-03-09 13:46:18 - skipping AVILA kernel TB --- 2013-03-09 13:46:18 - cd /src/sys/arm/conf TB --- 2013-03-09 13:46:18 - /usr/sbin/config -m BEAGLEBONE TB --- 2013-03-09 13:46:18 - skipping BEAGLEBONE kernel TB --- 2013-03-09 13:46:18 - cd /src/sys/arm/conf TB --- 2013-03-09 13:46:18 - /usr/sbin/config -m BWCT TB --- 2013-03-09 13:46:18 - building BWCT kernel TB --- 2013-03-09 13:46:18 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 13:46:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 13:46:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 13:46:18 - SRCCONF=/dev/null TB --- 2013-03-09 13:46:18 - TARGET=arm TB --- 2013-03-09 13:46:18 - TARGET_ARCH=arm TB --- 2013-03-09 13:46:18 - TZ=UTC TB --- 2013-03-09 13:46:18 - __MAKE_CONF=/dev/null TB --- 2013-03-09 13:46:18 - cd /src TB --- 2013-03-09 13:46:18 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Sat Mar 9 13:46:18 UTC 2013 >>> 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 >>> Kernel build for BWCT completed on Sat Mar 9 13:48:38 UTC 2013 TB --- 2013-03-09 13:48:38 - cd /src/sys/arm/conf TB --- 2013-03-09 13:48:38 - /usr/sbin/config -m CAMBRIA TB --- 2013-03-09 13:48:38 - skipping CAMBRIA kernel TB --- 2013-03-09 13:48:38 - cd /src/sys/arm/conf TB --- 2013-03-09 13:48:38 - /usr/sbin/config -m CNS11XXNAS TB --- 2013-03-09 13:48:38 - building CNS11XXNAS kernel TB --- 2013-03-09 13:48:38 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 13:48:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 13:48:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 13:48:38 - SRCCONF=/dev/null TB --- 2013-03-09 13:48:38 - TARGET=arm TB --- 2013-03-09 13:48:38 - TARGET_ARCH=arm TB --- 2013-03-09 13:48:38 - TZ=UTC TB --- 2013-03-09 13:48:38 - __MAKE_CONF=/dev/null TB --- 2013-03-09 13:48:38 - cd /src TB --- 2013-03-09 13:48:38 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Sat Mar 9 13:48:38 UTC 2013 >>> 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 >>> Kernel build for CNS11XXNAS completed on Sat Mar 9 13:51:13 UTC 2013 TB --- 2013-03-09 13:51:13 - cd /src/sys/arm/conf TB --- 2013-03-09 13:51:13 - /usr/sbin/config -m CRB TB --- 2013-03-09 13:51:13 - skipping CRB kernel TB --- 2013-03-09 13:51:13 - cd /src/sys/arm/conf TB --- 2013-03-09 13:51:13 - /usr/sbin/config -m CUBIEBOARD TB --- 2013-03-09 13:51:13 - skipping CUBIEBOARD kernel TB --- 2013-03-09 13:51:13 - cd /src/sys/arm/conf TB --- 2013-03-09 13:51:13 - /usr/sbin/config -m DB-78XXX TB --- 2013-03-09 13:51:13 - building DB-78XXX kernel TB --- 2013-03-09 13:51:13 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 13:51:13 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 13:51:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 13:51:13 - SRCCONF=/dev/null TB --- 2013-03-09 13:51:13 - TARGET=arm TB --- 2013-03-09 13:51:13 - TARGET_ARCH=arm TB --- 2013-03-09 13:51:13 - TZ=UTC TB --- 2013-03-09 13:51:13 - __MAKE_CONF=/dev/null TB --- 2013-03-09 13:51:13 - cd /src TB --- 2013-03-09 13:51:13 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Sat Mar 9 13:51:13 UTC 2013 >>> 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 >>> Kernel build for DB-78XXX completed on Sat Mar 9 13:54:02 UTC 2013 TB --- 2013-03-09 13:54:02 - cd /src/sys/arm/conf TB --- 2013-03-09 13:54:02 - /usr/sbin/config -m DB-88F5XXX TB --- 2013-03-09 13:54:02 - building DB-88F5XXX kernel TB --- 2013-03-09 13:54:02 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 13:54:02 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 13:54:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 13:54:02 - SRCCONF=/dev/null TB --- 2013-03-09 13:54:02 - TARGET=arm TB --- 2013-03-09 13:54:02 - TARGET_ARCH=arm TB --- 2013-03-09 13:54:02 - TZ=UTC TB --- 2013-03-09 13:54:02 - __MAKE_CONF=/dev/null TB --- 2013-03-09 13:54:02 - cd /src TB --- 2013-03-09 13:54:02 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Sat Mar 9 13:54:02 UTC 2013 >>> 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 >>> Kernel build for DB-88F5XXX completed on Sat Mar 9 13:56:44 UTC 2013 TB --- 2013-03-09 13:56:44 - cd /src/sys/arm/conf TB --- 2013-03-09 13:56:44 - /usr/sbin/config -m DB-88F6XXX TB --- 2013-03-09 13:56:44 - building DB-88F6XXX kernel TB --- 2013-03-09 13:56:44 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 13:56:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 13:56:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 13:56:44 - SRCCONF=/dev/null TB --- 2013-03-09 13:56:44 - TARGET=arm TB --- 2013-03-09 13:56:44 - TARGET_ARCH=arm TB --- 2013-03-09 13:56:44 - TZ=UTC TB --- 2013-03-09 13:56:44 - __MAKE_CONF=/dev/null TB --- 2013-03-09 13:56:44 - cd /src TB --- 2013-03-09 13:56:44 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Sat Mar 9 13:56:44 UTC 2013 >>> 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 >>> Kernel build for DB-88F6XXX completed on Sat Mar 9 13:59:43 UTC 2013 TB --- 2013-03-09 13:59:43 - cd /src/sys/arm/conf TB --- 2013-03-09 13:59:43 - /usr/sbin/config -m DOCKSTAR TB --- 2013-03-09 13:59:43 - building DOCKSTAR kernel TB --- 2013-03-09 13:59:43 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 13:59:43 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 13:59:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 13:59:43 - SRCCONF=/dev/null TB --- 2013-03-09 13:59:43 - TARGET=arm TB --- 2013-03-09 13:59:43 - TARGET_ARCH=arm TB --- 2013-03-09 13:59:43 - TZ=UTC TB --- 2013-03-09 13:59:43 - __MAKE_CONF=/dev/null TB --- 2013-03-09 13:59:43 - cd /src TB --- 2013-03-09 13:59:43 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Sat Mar 9 13:59:43 UTC 2013 >>> 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 >>> Kernel build for DOCKSTAR completed on Sat Mar 9 14:02:24 UTC 2013 TB --- 2013-03-09 14:02:24 - cd /src/sys/arm/conf TB --- 2013-03-09 14:02:24 - /usr/sbin/config -m DREAMPLUG-1001 TB --- 2013-03-09 14:02:24 - building DREAMPLUG-1001 kernel TB --- 2013-03-09 14:02:24 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 14:02:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 14:02:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 14:02:24 - SRCCONF=/dev/null TB --- 2013-03-09 14:02:24 - TARGET=arm TB --- 2013-03-09 14:02:24 - TARGET_ARCH=arm TB --- 2013-03-09 14:02:24 - TZ=UTC TB --- 2013-03-09 14:02:24 - __MAKE_CONF=/dev/null TB --- 2013-03-09 14:02:24 - cd /src TB --- 2013-03-09 14:02:24 - /usr/bin/make -B buildkernel KERNCONF=DREAMPLUG-1001 >>> Kernel build for DREAMPLUG-1001 started on Sat Mar 9 14:02:24 UTC 2013 >>> 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 >>> Kernel build for DREAMPLUG-1001 completed on Sat Mar 9 14:06:17 UTC 2013 TB --- 2013-03-09 14:06:17 - cd /src/sys/arm/conf TB --- 2013-03-09 14:06:17 - /usr/sbin/config -m EA3250 TB --- 2013-03-09 14:06:17 - building EA3250 kernel TB --- 2013-03-09 14:06:17 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 14:06:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 14:06:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 14:06:17 - SRCCONF=/dev/null TB --- 2013-03-09 14:06:17 - TARGET=arm TB --- 2013-03-09 14:06:17 - TARGET_ARCH=arm TB --- 2013-03-09 14:06:17 - TZ=UTC TB --- 2013-03-09 14:06:17 - __MAKE_CONF=/dev/null TB --- 2013-03-09 14:06:17 - cd /src TB --- 2013-03-09 14:06:17 - /usr/bin/make -B buildkernel KERNCONF=EA3250 >>> Kernel build for EA3250 started on Sat Mar 9 14:06:17 UTC 2013 >>> 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 >>> Kernel build for EA3250 completed on Sat Mar 9 14:09:05 UTC 2013 TB --- 2013-03-09 14:09:05 - cd /src/sys/arm/conf TB --- 2013-03-09 14:09:05 - /usr/sbin/config -m EB9200 TB --- 2013-03-09 14:09:05 - building EB9200 kernel TB --- 2013-03-09 14:09:05 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 14:09:05 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 14:09:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 14:09:05 - SRCCONF=/dev/null TB --- 2013-03-09 14:09:05 - TARGET=arm TB --- 2013-03-09 14:09:05 - TARGET_ARCH=arm TB --- 2013-03-09 14:09:05 - TZ=UTC TB --- 2013-03-09 14:09:05 - __MAKE_CONF=/dev/null TB --- 2013-03-09 14:09:05 - cd /src TB --- 2013-03-09 14:09:05 - /usr/bin/make -B buildkernel KERNCONF=EB9200 >>> Kernel build for EB9200 started on Sat Mar 9 14:09:05 UTC 2013 >>> 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 >>> Kernel build for EB9200 completed on Sat Mar 9 14:11:41 UTC 2013 TB --- 2013-03-09 14:11:41 - cd /src/sys/arm/conf TB --- 2013-03-09 14:11:41 - /usr/sbin/config -m EP80219 TB --- 2013-03-09 14:11:41 - skipping EP80219 kernel TB --- 2013-03-09 14:11:41 - cd /src/sys/arm/conf TB --- 2013-03-09 14:11:41 - /usr/sbin/config -m ETHERNUT5 TB --- 2013-03-09 14:11:41 - building ETHERNUT5 kernel TB --- 2013-03-09 14:11:41 - CROSS_BUILD_TESTING=YES TB --- 2013-03-09 14:11:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-09 14:11:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-09 14:11:41 - SRCCONF=/dev/null TB --- 2013-03-09 14:11:41 - TARGET=arm TB --- 2013-03-09 14:11:41 - TARGET_ARCH=arm TB --- 2013-03-09 14:11:41 - TZ=UTC TB --- 2013-03-09 14:11:41 - __MAKE_CONF=/dev/null TB --- 2013-03-09 14:11:41 - cd /src TB --- 2013-03-09 14:11:41 - /usr/bin/make -B buildkernel KERNCONF=ETHERNUT5 >>> Kernel build for ETHERNUT5 started on Sat Mar 9 14:11:41 UTC 2013 >>> 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 -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/wlan/../../net80211/ieee80211_input.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/wlan/../../net80211/ieee80211_ioctl.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/wlan/../../net80211/ieee80211_mesh.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/wlan/../../net80211/ieee80211_node.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -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 -c /src/sys/modules/wlan/../../net80211/ieee80211_output.c cc1: warnings being treated as errors /src/sys/modules/wlan/../../net80211/ieee80211_output.c: In function 'ieee80211_send_setup': /src/sys/modules/wlan/../../net80211/ieee80211_output.c:600: warning: unused variable 'ic' [-Wunused-variable] *** [ieee80211_output.o] Error code 1 Stop in /src/sys/modules/wlan. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/arm.arm/src/sys/ETHERNUT5. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-09 14:21:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-09 14:21:04 - ERROR: failed to build ETHERNUT5 kernel TB --- 2013-03-09 14:21:04 - 8060.01 user 1475.91 system 10238.58 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Mar 9 14:29:00 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 51F10A69 for ; Sat, 9 Mar 2013 14:29:00 +0000 (UTC) (envelope-from mats@exmandato.se) Received: from ext.mellstrand.net (ext.mellstrand.net [IPv6:2001:2040:4:2::51]) by mx1.freebsd.org (Postfix) with ESMTP id D4DEA3FA for ; Sat, 9 Mar 2013 14:28:59 +0000 (UTC) Received: by ext.mellstrand.net Sat, 9 Mar 2013 14:28:55 GMT From: Mats Mellstrand Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RPi booting problem Message-Id: Date: Sat, 9 Mar 2013 15:29:00 +0100 To: "freebsd-arm@freebsd.org" Mime-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 14:29:00 -0000 Hi I have checked out the latest from head and built world and kernel = (conf/RPI-B) and finally created and image that I written to a flash. I have used freebsd-uboot-20130201.tar.gz=20 When I try to boot, the uboot goes in to a cyclic restart... U-Boot 2013.01-rc1-g6709570-dirty (Nov 30 2012 - 19:09:28) DRAM: 448 MiB WARNING: Caches not enabled MMC: bcm2835_sdhci: 0 Using default environment In: serial Out: lcd Err: lcd bcm2835: USB power in ON Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0=20 reading uEnv.txt reading boot.scr 137 bytes read in 9023 ms (0 Bytes/s) Running bootscript from mmc0 ... ## Executing script at 00200000 reading ubldr 238023 bytes read in 60497 ms (2.9 KiB/s) ## Starting application at 0x02000054 ... U-Boot 2013.01-rc1-g6709570-dirty (Nov 30 2012 - 19:09:28) over and over .... Suggestions? /mm From owner-freebsd-arm@FreeBSD.ORG Sat Mar 9 15:16:17 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 51D2EF66 for ; Sat, 9 Mar 2013 15:16:17 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 24E4082B for ; Sat, 9 Mar 2013 15:16:17 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id c12so3146163ieb.20 for ; Sat, 09 Mar 2013 07:16:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-rim-org-msg-ref-id:message-id :content-transfer-encoding:reply-to:x-priority:sensitivity :importance:subject:to:from:date:content-type:mime-version :x-gm-message-state; bh=HLyiSlv68g6PbUqpHh/u3A0eLpopG2QMCcvFqsmcyrs=; b=Lvwu318WNKjA0gqMh8tqgY02GPOSwoPdaFxD3I3F8Zsyerz0vGo+ZbekmIDJymCCWd aHDJYNkmbAdKkr5WhD1Q8JO96+9dY/7iO4xFJdi/i9fbYpHvp2C3x+6OdAry9dCgTZ9x mVT9iUSGLzsqDBQ3ieIEfy0i7IvbiKk8GLCOqeSe0LdaWsKOjihIZGK96wj8yCy2F9yz 7IW4I6kUnD470VT+i6AGA7XM56A0QY6su9Zhpa+ceaAs3JFIuj6NfKvoO8yeCopoV+ab vEAWpYZCI2VMQRcGYT9uJQ1tnnaI0Ib0+FUK76E63TAy+0YlFbyZdviJmgQC2e4e6gsf kUFA== X-Received: by 10.50.189.170 with SMTP id gj10mr2710029igc.1.1362842176676; Sat, 09 Mar 2013 07:16:16 -0800 (PST) Received: from 172.19.199.187 (bda-216-9-250-65.bis3.ap.blackberry.com. [216.9.250.65]) by mx.google.com with ESMTPS id ur12sm4548693igb.8.2013.03.09.07.16.15 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 09 Mar 2013 07:16:16 -0800 (PST) X-rim-org-msg-ref-id: 906054203 Message-ID: <906054203-1362842174-cardhu_decombobulator_blackberry.rim.net-928644089-@b26.c6.bise3.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal Sensitivity: Normal Importance: Normal Subject: Re: RPi booting problem To: "Mats Mellstrand" , owner-freebsd-arm@freebsd.org, "freebsd-arm@freebsd.org" From: "Alie Tan" Date: Sat, 9 Mar 2013 15:16:07 +0000 Content-Type: text/plain; charset="big5-hkscs" MIME-Version: 1.0 X-Gm-Message-State: ALoCoQnFm0z4Xn1kza6mE45mnGi5mJSrPOoJgH5dmXxpyeNXwnHn8MoslWf9QWPcA0SrsLijsPaT X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: alie@affle.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 15:16:17 -0000 RG8geW91IGhhdmUgV0lUSF9BUk1fRUFCST0iWUVTIiBvbiB5b3VyIHNyYy5jb25mPw0KDQoNCi0t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLS0NCkZyb206IE1hdHMgTWVsbHN0cmFuZA0KU2VuZGVy OiBvd25lci1mcmVlYnNkLWFybUBmcmVlYnNkLm9yZw0KVG86IGZyZWVic2QtYXJtQGZyZWVic2Qu b3JnDQpTdWJqZWN0OiBSUGkgYm9vdGluZyBwcm9ibGVtDQpTZW50OiBNYXIgOSwgMjAxMyAxMDoy OSBQTQ0KDQpIaQ0KDQpJIGhhdmUgY2hlY2tlZCBvdXQgdGhlIGxhdGVzdCBmcm9tIGhlYWQgYW5k IGJ1aWx0IHdvcmxkIGFuZCBrZXJuZWwgKGNvbmYvUlBJLUIpIGFuZCBmaW5hbGx5IGNyZWF0ZWQg YW5kIGltYWdlIHRoYXQgSSB3cml0dGVuIHRvIGEgZmxhc2guDQpJIGhhdmUgdXNlZCBmcmVlYnNk LXVib290LTIwMTMwMjAxLnRhci5neiANCg0KV2hlbiBJIHRyeSB0byBib290LCAgdGhlIHVib290 IGdvZXMgaW4gdG8gYSBjeWNsaWMgcmVzdGFydC4uLg0KDQpVLUJvb3QgMjAxMy4wMS1yYzEtZzY3 MDk1NzAtZGlydHkgKE5vdiAzMCAyMDEyIC0gMTk6MDk6MjgpDQoNCkRSQU06ICA0NDggTWlCDQpX QVJOSU5HOiBDYWNoZXMgbm90IGVuYWJsZWQNCk1NQzogICBiY20yODM1X3NkaGNpOiAwDQpVc2lu ZyBkZWZhdWx0IGVudmlyb25tZW50DQoNCkluOiAgICBzZXJpYWwNCk91dDogICBsY2QNCkVycjog ICBsY2QNCmJjbTI4MzU6IFVTQiBwb3dlciBpbiBPTg0KTmV0OiAgIE5ldCBJbml0aWFsaXphdGlv biBTa2lwcGVkDQpObyBldGhlcm5ldCBmb3VuZC4NCkhpdCBhbnkga2V5IHRvIHN0b3AgYXV0b2Jv b3Q6ICAwIA0KcmVhZGluZyB1RW52LnR4dA0KcmVhZGluZyBib290LnNjcg0KMTM3IGJ5dGVzIHJl YWQgaW4gOTAyMyBtcyAoMCBCeXRlcy9zKQ0KUnVubmluZyBib290c2NyaXB0IGZyb20gbW1jMCAu Li4NCiMjIEV4ZWN1dGluZyBzY3JpcHQgYXQgMDAyMDAwMDANCnJlYWRpbmcgdWJsZHINCjIzODAy MyBieXRlcyByZWFkIGluIDYwNDk3IG1zICgyLjkgS2lCL3MpDQojIyBTdGFydGluZyBhcHBsaWNh dGlvbiBhdCAweDAyMDAwMDU0IC4uLg0KDQoNClUtQm9vdCAyMDEzLjAxLXJjMS1nNjcwOTU3MC1k aXJ0eSAoTm92IDMwIDIwMTIgLSAxOTowOToyOCkNCg0Kb3ZlciBhbmQgb3ZlciAuLi4uDQoNCg0K U3VnZ2VzdGlvbnM/DQoNCg0KDQovbW0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KZnJlZWJzZC1hcm1AZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0 DQpodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLWFybQ0K VG8gdW5zdWJzY3JpYmUsIHNlbmQgYW55IG1haWwgdG8gImZyZWVic2QtYXJtLXVuc3Vic2NyaWJl QGZyZWVic2Qub3JnIg0KDQpTZW50IHZpYSBCbGFja0JlcnJ5IGZyb20gU2luZ1RlbCE= From owner-freebsd-arm@FreeBSD.ORG Sat Mar 9 15:18:37 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 12AE92D5; Sat, 9 Mar 2013 15:18:37 +0000 (UTC) (envelope-from mats@exmandato.se) Received: from ext.mellstrand.net (ext.mellstrand.net [IPv6:2001:2040:4:2::51]) by mx1.freebsd.org (Postfix) with ESMTP id 8F41B85F; Sat, 9 Mar 2013 15:18:36 +0000 (UTC) Received: by ext.mellstrand.net Sat, 9 Mar 2013 15:18:33 GMT Subject: Re: RPi booting problem Mime-Version: 1.0 Content-Type: text/plain; charset=big5-hkscs From: Mats Mellstrand X-Priority: Normal In-Reply-To: <906054203-1362842174-cardhu_decombobulator_blackberry.rim.net-928644089-@b26.c6.bise3.blackberry> Date: Sat, 9 Mar 2013 16:18:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7EFEBF33-D975-4E4A-917C-85450DF23BA3@exmandato.se> References: <906054203-1362842174-cardhu_decombobulator_blackberry.rim.net-928644089-@b26.c6.bise3.blackberry> To: alie@affle.com Cc: owner-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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 15:18:37 -0000 On 9 mar 2013, at 16:16, Alie Tan wrote: > Do you have WITH_ARM_EABI=3D"YES" on your src.conf? No >=20 >=20 > ------Original Message------ > From: Mats Mellstrand > Sender: owner-freebsd-arm@freebsd.org > To: freebsd-arm@freebsd.org > Subject: RPi booting problem > Sent: Mar 9, 2013 10:29 PM >=20 > Hi >=20 > I have checked out the latest from head and built world and kernel = (conf/RPI-B) and finally created and image that I written to a flash. > I have used freebsd-uboot-20130201.tar.gz=20 >=20 > When I try to boot, the uboot goes in to a cyclic restart... >=20 > U-Boot 2013.01-rc1-g6709570-dirty (Nov 30 2012 - 19:09:28) >=20 > DRAM: 448 MiB > WARNING: Caches not enabled > MMC: bcm2835_sdhci: 0 > Using default environment >=20 > In: serial > Out: lcd > Err: lcd > bcm2835: USB power in ON > Net: Net Initialization Skipped > No ethernet found. > Hit any key to stop autoboot: 0=20 > reading uEnv.txt > reading boot.scr > 137 bytes read in 9023 ms (0 Bytes/s) > Running bootscript from mmc0 ... > ## Executing script at 00200000 > reading ubldr > 238023 bytes read in 60497 ms (2.9 KiB/s) > ## Starting application at 0x02000054 ... >=20 >=20 > U-Boot 2013.01-rc1-g6709570-dirty (Nov 30 2012 - 19:09:28) >=20 > over and over .... >=20 >=20 > Suggestions? >=20 >=20 >=20 > /mm >=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" >=20 > Sent via BlackBerry from SingTel! >=20