From owner-freebsd-arm@FreeBSD.ORG Sun Feb 16 08:37:34 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74C68D6A for ; Sun, 16 Feb 2014 08:37:34 +0000 (UTC) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 396EB19CC for ; Sun, 16 Feb 2014 08:37:33 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id uq10so3483707igb.0 for ; Sun, 16 Feb 2014 00:37:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+lG4stlgYOVGKQoSVOjvJ+h1dC8VPc1aPYOOXiQ4UFg=; b=CG0D14C5VOAibH/u05ULBH+RlrY/VJKhebGgAqyXSmFPCqXsaWu+7cApi6YrOC67s2 lUtymBNaXMGuKVs5h6Q6bxXweFTJyPqlNKZYXcNauHu0BeVdb4HMuLxPSb4PpUgpfj3n Ma5qesGl7zTcllB7iOxOePv77mrId8tq/SI2OiAajmV7BJNar/RSVJeWMAgEGXSxeT1t dr1dGJagTmEJD6sM7yaeCPcZkHmMY1Gi2pexPUegxMLnzUy+5pE1njUPIpyd4hv9wCYE mCKLR68x/j2ZoK+x6ulsMWXF7gce1qmCgCH4HlYm3m+tXsmWcrNxVfWsVZcYkCHSLhkR L7zA== X-Gm-Message-State: ALoCoQlhZv7rfd6XgATYoIqBXqSQm9Nhvp34tgvn2JU8529YbxkJJJjQAYI7nOVXDe1IIpYEag7vcZvnkPSQuRFaAOPbAO1sjqvyqsUfQmwApZf65vvQ4zg= X-Received: by 10.50.67.82 with SMTP id l18mr10788319igt.29.1392539847117; Sun, 16 Feb 2014 00:37:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.128.200 with HTTP; Sun, 16 Feb 2014 00:37:10 -0800 (PST) In-Reply-To: <20140213152802.GH1667@glenbarber.us> References: <20140129181803.GI1827@glenbarber.us> <6620C833-9D56-4367-AA4D-D78D4BCA2D40@neville-neil.com> <20140211161142.GA1665@glenbarber.us> <20140211211746.28beee52@cuisine.seix> <20140211203645.GB1650@glenbarber.us> <20140212010827.GA1671@glenbarber.us> <20140212012025.GB1671@glenbarber.us> <20140213152802.GH1667@glenbarber.us> From: "Lundberg, Johannes" Date: Sun, 16 Feb 2014 17:37:10 +0900 Message-ID: Subject: Re: Raspberry Pi and BeagleBone images available on FreeBSD FTP mirrors To: Glen Barber Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 08:37:34 -0000 Hi Glen This is what I get when booting your image (burnt to 4 GB ScanDisk Ultra HC card) loader> boot -v Using DTB compiled into kernel. Kernel entry at 0x80200100... Kernel args: -v KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r261642: Wed Feb 12 22:58:33 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/PANDABOARD arm FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 Preloaded elf kernel "/boot/kernel/kernel" at 0xc0757000. CPU: Cortex A9-r2 rev 10 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:1 LoUIS:2 Cache level 1: 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc 32KB/32B 4-way instruction cache Read-Alloc real memory = 1073741824 (1024 MB) Physical memory chunk(s): 0x80000000 - 0x801fffff, 2048 KBytes (512 pages) 0x80888000 - 0xbeb6afff, 1018764 KBytes (254691 pages) avail memory = 1041924096 (993 MB) Static device mappings: 0x48000000 - 0x48ffffff mapped at VA 0xfef00000 0x4a000000 - 0x4affffff mapped at VA 0xfdf00000 Texas Instruments OMAP4460 Processor, Revision ES1.1 random device not loaded; using insecure entropy null: openfirm: Falling back to random adaptor random: initialized mem: nfslock: pseudo-device ofwbus0: simplebus0: on ofwbus0 gic0: mem 0x48241000-0x48241fff,0x48240100-0x482401ff on simplebus0 gic0: pn 0x390, arch 0x1, rev 0x2, implementer 0x43b sc->nirqs 160 omap4_prcm0: mem 0x4a306000-0x4a307fff,0x4a004000-0x4a004fff,0x4a008000-0x4a00ffff on simplebus0 l2cache0: mem 0x48242000-0x48242fff irq 32 on simplebus0 l2cache0: Part number: 0x3, release: 0x7 l2cache0: L2 Cache: 1024KB/32B 16 ways l2cache0: Early BRESP response: disabled l2cache0: Instruction prefetch: disabled l2cache0: Data prefetch: enabled l2cache0: Non-secure interrupt control: enabled l2cache0: Non-secure lockdown: enabled l2cache0: Share override: disabled l2cache0: Double linefil: disabled l2cache0: Instruction prefetch: disabled l2cache0: Data prefetch: enabled l2cache0: Double linefill on WRAP request: disabled l2cache0: Prefetch drop: disabled l2cache0: Incr double Linefill: disabled l2cache0: Not same ID on exclusive sequence: disabled l2cache0: Prefetch offset: 5 mp_tmr0: mem 0x48240200-0x482402ff,0x48240600-0x482406ff irq 27,29 on simplebus0 Timecounter "ARM MPCore Timecounter" frequency 12607573 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 12607573 Hz quality 1000 ??uart0: mem 0x48020000-0x48020fff irq 106 on simplebus0 uart0: console (115384,n,8,1) uart0: fast interrupt ti_scm0: mem 0x4a100000-0x4a100fff on simplebus0 ti_scm0: setting internal 4 for usbb1_ulpiphy_stp ti_scm0: setting internal 10c for usbb1_ulpiphy_clk ti_scm0: setting internal 10c for usbb1_ulpiphy_dir ti_scm0: setting internal 10c for usbb1_ulpiphy_nxt ti_scm0: setting internal 10c for usbb1_ulpiphy_dat0 ti_scm0: setting internal 10c for usbb1_ulpiphy_dat1 ti_scm0: setting internal 10c for usbb1_ulpiphy_dat2 ti_scm0: setting internal 10c for usbb1_ulpiphy_dat3 ti_scm0: setting internal 10c for usbb1_ulpiphy_dat4 ti_scm0: setting internal 10c for usbb1_ulpiphy_dat5 ti_scm0: setting internal 10c for usbb1_ulpiphy_dat6 ti_scm0: setting internal 10c for usbb1_ulpiphy_dat7 gpio0: mem 0x4a310000-0x4a310fff,0x48055000-0x48055fff,0x48057000-0x48057fff,0x48059000-0x48059fff,0x4805b000-0x4805bfff,0x4805d000-0x4805dfff irq 61,62,63,64,65,66 on simplebus0 gpioc0: on gpio0 gpiobus0: on gpio0 ehci0: mem 0x4a064c00-0x4a064cff,0x4a064000-0x4a0646ff,0x4a062000-0x4a062fff irq 109 on simplebus0 ehci0: Starting TI EHCI USB Controller ehci0: UHH revision 0x50700100 ehci0: OMAP_UHH_SYSCONFIG: 0x00000014 ehci0: UHH setup done, uhh_hostconfig=0x8000001c usbus0: EHCI version 1.0 usbus0 on ehci0 ehci0: usbpf: Attached iichb0: mem 0x48070000-0x480700ff irq 88 on simplebus0 iichb0: I2C revision 4.0 iicbus0: on iichb0 iic0: on iicbus0 ti_sdma0: mem 0x4a056000-0x4a056fff irq 44,45,46,47 on simplebus0 ti_sdma0: sDMA revision 00010900 ti_mmchs0: mem 0x4809c000-0x4809cfff irq 115 on simplebus0 mmc0: on ti_mmchs0 Timecounters tick every 10.000 msec tcp_init: net.inet.tcp.tcbhashsize auto tuned to 16384 lo0: bpf attached usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 mmc0: Probing bus mmc0: SD 2.0 interface conditions: OK mmc0: SD probe: OK (OCR: 0x40ff8000) mmc0: Current OCR: 0x00ff8000 mmc0: Probing cards mmc0: New card detected (CID 0353445355303447801c3557c400c9f5) uhub0: 3 ports with 3 removable, self powered mmc0: New card detected (CSD 400e00325b5900001d8a7f800a4040b9) mmc0: Card at relative address 0xe624 added: mmc0: card: SDHC SU04G 8.0 SN 473257924 MFG 09/2012 by 3 SD mmc0: bus: 4bit, 50MHz, high speed timing mmc0: memory: 7744512 blocks, erase sector 8192 blocks mmc0: setting transfer rate to 25.000MHz mmcsd0: 4GB at mmc0 25.0MHz/4bit/1-block random: unblocking device. GEOM:ugen0.2: at usbus0 uhub1: on usbus0 uhub1: MTT enabled new disk mmcsd0 mmc0: setting bus width to 4 bits GEOM_PART: partition 1 is not aligned on 4194304 bytes GEOM_PART: partition 2 is not aligned on 4194304 bytes uhub1: 5 ports with 4 removable, self powered GEOM_PART: partition 1 is not aligned on 4194304 bytes Root mount waiting for: usbus0 ugen0.3: at usbus0 smsc0: on usbus0 Root mount waiting for: usbus0 Trying to mount root from ufs:/dev/mmcsd0s2 [rw,noatime]... smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: OUI 0x00800f, model 0x000c, rev. 3 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: bpf attached ue0: Ethernet address: d2:20:2a:b7:50:c7 warning: no time-of-day clock registered, system time will not be set accurately start_init: trying /sbin/init Spurious interrupt detected [0x000003ff] Spurious interrupt detected [0x000003ff] Spurious interrupt detected [0x000003ff] Spurious interrupt detected [0x000003ff] and so on... -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Fri, Feb 14, 2014 at 12:28 AM, Glen Barber wrote: > On Tue, Feb 11, 2014 at 08:20:25PM -0500, Glen Barber wrote: > > On Wed, Feb 12, 2014 at 10:10:04AM +0900, Lundberg, Johannes wrote: > > > Thanks! Will Pandaboard also show up here soon? > > > > > > > Yes. > > > > Can you test the image located here? If it works for you, PANDABOARD > will be included in the next set of snapshot builds. > > http://people.freebsd.org/~gjb/PANDABOARD/ > > Glen > > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. From owner-freebsd-arm@FreeBSD.ORG Sun Feb 16 08:47:36 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 002477A for ; Sun, 16 Feb 2014 08:47:35 +0000 (UTC) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B4CDB1A53 for ; Sun, 16 Feb 2014 08:47:35 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id c10so3420226igq.0 for ; Sun, 16 Feb 2014 00:47:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LcyC9k3IYaVKjGI/RvvUZU3TsDzmSAgkY0IEphKVfWo=; b=MOsVW3l75mlrXsKMLOzghlqP/cwmmEb9DqAjzIC0Ds6aEq7WhIV0mWtOHHmTsLh5V0 QX/ZdYSUOZzqhXXPRy4uSXDjJb6wid4Cp9wDXPD8tKxLMP/bhbBoAjO1ChB4TURxilD2 DCnHzjXbg+m8ocpj/jsiogUfGP8dQgig1iWwe3uun/SPkciGAfc45dL7BjIpunOsd95K y+v7LP/OSZ+9hMk4oGncYQgshYOKqjikcTekoYJuW9er+Y8xKGWF92stVJFGlltjyarY HOv/m41D0BxavEGx0V78WzeCYHnqE6vkhRZD2rgkW2KRSu2wq3iAp+W1ym120BpqUUIF cggg== X-Gm-Message-State: ALoCoQki/MCdkELaK5okAjurZnz7AqHNUkRhw8y78h9zHDroaMqUW7xp1S8g0iBiarUdE8uOW0UNCmSYkI4XGfqAgW4AEHMqrqaMl+hawBRyEWK/KGXFBok= X-Received: by 10.42.53.10 with SMTP id l10mr12981623icg.33.1392540001567; Sun, 16 Feb 2014 00:40:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.128.200 with HTTP; Sun, 16 Feb 2014 00:39:46 -0800 (PST) In-Reply-To: References: <20140129181803.GI1827@glenbarber.us> <6620C833-9D56-4367-AA4D-D78D4BCA2D40@neville-neil.com> <20140211161142.GA1665@glenbarber.us> <20140211211746.28beee52@cuisine.seix> <20140211203645.GB1650@glenbarber.us> <20140212010827.GA1671@glenbarber.us> <20140212012025.GB1671@glenbarber.us> <20140213152802.GH1667@glenbarber.us> From: "Lundberg, Johannes" Date: Sun, 16 Feb 2014 17:39:46 +0900 Message-ID: Subject: Re: Raspberry Pi and BeagleBone images available on FreeBSD FTP mirrors To: Glen Barber Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 08:47:36 -0000 Next time I booted it crash after a bunch of "Spurious interrupt detected" vm_fault(0xc089c4f0, 0, 1, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (P)' trapframe: 0xefa5bb78 FSR=00000017, FAR=00000078, spsr=60000113 r0 =c0783000, r1 =00000000, r2 =00000000, r3 =0000001f r4 =c056c9c8, r5 =c06893b0, r6 =c056c9c8, r7 =00000020 r8 =00000004, r9 =82371000, r10=c068d834, r11=efa5bbf8 r12=00000020, ssp=efa5bbc8, slr=c0573888, pc =c0573888 [ thread pid 17 tid 100044 ] Stopped at pmap_copy_page_generic+0x164: ldr r2, [r7, #0x058] db> bt Tracing pid 17 tid 100044 td 0xc3b81640 db_trace_self() at db_trace_self pc = 0xc056596c lr = 0xc02340d0 (db_stack_trace+0xf4) sp = 0xefa5b878 fp = 0xefa5b890 r10 = 0xc0641840 db_stack_trace() at db_stack_trace+0xf4 pc = 0xc02340d0 lr = 0xc0233a80 (db_command+0x264) sp = 0xefa5b898 fp = 0xefa5b938 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc05d907b db_command() at db_command+0x264 pc = 0xc0233a80 lr = 0xc02337f0 (db_command_loop+0x60) sp = 0xefa5b940 fp = 0xefa5b950 r4 = 0xc05ad7a8 r5 = 0xc05c21a3 r6 = 0xc068a2ec r7 = 0xefa5bb78 r8 = 0xc089c4f0 r9 = 0xc0680eb4 r10 = 0xc0641ab0 db_command_loop() at db_command_loop+0x60 pc = 0xc02337f0 lr = 0xc02362b0 (db_trap+0xdc) sp = 0xefa5b958 fp = 0xefa5ba78 r4 = 0x00000000 r5 = 0xefa5b960 r6 = 0xc0680ee0 db_trap() at db_trap+0xdc pc = 0xc02362b0 lr = 0xc03c4968 (kdb_trap+0xcc) sp = 0xefa5ba80 fp = 0xefa5baa0 r4 = 0x00000000 r5 = 0x00000017 r6 = 0xc0680ee0 r7 = 0xefa5bb78 kdb_trap() at kdb_trap+0xcc pc = 0xc03c4968 lr = 0xc057985c (dab_fatal+0x174) sp = 0xefa5baa8 fp = 0xefa5bac0 r4 = 0xefa5bb78 r5 = 0x600001d3 r6 = 0x00000078 r7 = 0x00000017 r8 = 0xc089c4f0 r9 = 0x00000001 r10 = 0xefa5bb78 dab_fatal() at dab_fatal+0x174 pc = 0xc057985c lr = 0xc057962c (data_abort_handler+0x5a0) sp = 0xefa5bac8 fp = 0xefa5bb70 r4 = 0x00000017 r5 = 0xc3b81640 r6 = 0xc3b7a6ec r7 = 0x00000004 data_abort_handler() at data_abort_handler+0x5a0 pc = 0xc057962c lr = 0xc0567774 (exception_exit) sp = 0xefa5bb78 fp = 0xefa5bbf8 r4 = 0xc056c9c8 r5 = 0xc06893b0 r6 = 0xc056c9c8 r7 = 0x00000020 r8 = 0x00000004 r9 = 0x82371000 r10 = 0xc068d834 exception_exit() at exception_exit pc = 0xc0567774 lr = 0xc0573888 (pmap_copy_page_generic+0x164) sp = 0xefa5bbc8 fp = 0xefa5bbf8 r0 = 0xc0783000 r1 = 0x00000000 r2 = 0x00000000 r3 = 0x0000001f r4 = 0xc056c9c8 r5 = 0xc06893b0 r6 = 0xc056c9c8 r7 = 0x00000020 r8 = 0x00000004 r9 = 0x82371000 r10 = 0xc068d834 r12 = 0x00000020 pmap_copy_page_generic() at pmap_copy_page_generic+0x164 pc = 0xc0573888 lr = 0xc0573c48 (pmap_copy_page+0x64) sp = 0xefa5bc00 fp = 0xefa5bc08 r4 = 0xc0993370 r5 = 0xc0972210 r6 = 0xc3bfcab0 r7 = 0x00000001 r8 = 0xbfffe000 r9 = 0x00000000 r10 = 0xefa5bd10 pmap_copy_page() at pmap_copy_page+0x64 pc = 0xc0573c48 lr = 0xc0533278 ($a+0x10) sp = 0xefa5bc10 fp = 0xefa5bd80 r4 = 0xc3bfcaa0 r5 = 0x00000000 $a() at $a+0x10 pc = 0xc0533278 lr = 0xc0531acc (vm_fault+0x84) sp = 0xefa5bd88 fp = 0xefa5bda8 r4 = 0xc089c4f0 r5 = 0x00000002 r6 = 0xc3b81640 r7 = 0xbfffe000 r8 = 0x00000000 r9 = 0x00000002 r10 = 0xc068cce8 vm_fault() at vm_fault+0x84 pc = 0xc0531acc lr = 0xc057948c (data_abort_handler+0x400) sp = 0xefa5bdb0 fp = 0xefa5be58 r4 = 0xc3b7a6ec r5 = 0xc3b81640 r6 = 0xc3b7a6ec r7 = 0x00000004 r8 = 0xc089c4f0 r9 = 0xbfffebf8 r10 = 0xefa5be60 data_abort_handler() at data_abort_handler+0x400 pc = 0xc057948c lr = 0xc0567774 (exception_exit) sp = 0xefa5be60 fp = 0xbfffedb8 r4 = 0x00030908 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x208052d0 r8 = 0x00000003 r9 = 0x2080d020 r10 = 0x00000000 exception_exit() at exception_exit pc = 0xc0567774 lr = 0x2014e308 (0x2014e308) sp = 0xefa5beb0 fp = 0xbfffedb8 r0 = 0x2080d020 r1 = 0xbfffec48 r2 = 0x00000000 r3 = 0x00000000 r4 = 0x00030908 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x208052d0 r8 = 0x00000003 r9 = 0x2080d020 r10 = 0x00000000 r12 = 0x208052d0 Unable to unwind into user mode -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Sun, Feb 16, 2014 at 5:37 PM, Lundberg, Johannes < johannes@brilliantservice.co.jp> wrote: > Hi Glen > > This is what I get when booting your image (burnt to 4 GB ScanDisk Ultra > HC card) > > loader> boot -v > Using DTB compiled into kernel. > Kernel entry at 0x80200100... > Kernel args: -v > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2014 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-CURRENT #0 r261642: Wed Feb 12 22:58:33 UTC 2014 > root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/PANDABOARD arm > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0757000. > CPU: Cortex A9-r2 rev 10 (Cortex-A core) > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > WB disabled EABT branch prediction enabled > LoUU:2 LoC:1 LoUIS:2 > Cache level 1: > 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc > 32KB/32B 4-way instruction cache Read-Alloc > real memory = 1073741824 (1024 MB) > Physical memory chunk(s): > 0x80000000 - 0x801fffff, 2048 KBytes (512 pages) > 0x80888000 - 0xbeb6afff, 1018764 KBytes (254691 pages) > avail memory = 1041924096 (993 MB) > Static device mappings: > 0x48000000 - 0x48ffffff mapped at VA 0xfef00000 > 0x4a000000 - 0x4affffff mapped at VA 0xfdf00000 > Texas Instruments OMAP4460 Processor, Revision ES1.1 > random device not loaded; using insecure entropy > null: > openfirm: > Falling back to random adaptor > random: initialized > mem: > nfslock: pseudo-device > ofwbus0: > simplebus0: on ofwbus0 > gic0: mem > 0x48241000-0x48241fff,0x48240100-0x482401ff on simplebus0 > gic0: pn 0x390, arch 0x1, rev 0x2, implementer 0x43b sc->nirqs 160 > omap4_prcm0: mem > 0x4a306000-0x4a307fff,0x4a004000-0x4a004fff,0x4a008000-0x4a00ffff on > simplebus0 > l2cache0: mem 0x48242000-0x48242fff irq 32 on > simplebus0 > l2cache0: Part number: 0x3, release: 0x7 > l2cache0: L2 Cache: 1024KB/32B 16 ways > l2cache0: Early BRESP response: disabled > l2cache0: Instruction prefetch: disabled > l2cache0: Data prefetch: enabled > l2cache0: Non-secure interrupt control: enabled > l2cache0: Non-secure lockdown: enabled > l2cache0: Share override: disabled > l2cache0: Double linefil: disabled > l2cache0: Instruction prefetch: disabled > l2cache0: Data prefetch: enabled > l2cache0: Double linefill on WRAP request: disabled > l2cache0: Prefetch drop: disabled > l2cache0: Incr double Linefill: disabled > l2cache0: Not same ID on exclusive sequence: disabled > l2cache0: Prefetch offset: 5 > mp_tmr0: mem > 0x48240200-0x482402ff,0x48240600-0x482406ff irq 27,29 on simplebus0 > Timecounter "ARM MPCore Timecounter" frequency 12607573 Hz quality 1000 > Event timer "ARM MPCore Eventtimer" frequency 12607573 Hz quality 1000 > ??uart0: mem > 0x48020000-0x48020fff irq 106 on simplebus0 > uart0: console (115384,n,8,1) > uart0: fast interrupt > ti_scm0: mem 0x4a100000-0x4a100fff on simplebus0 > ti_scm0: setting internal 4 for usbb1_ulpiphy_stp > ti_scm0: setting internal 10c for usbb1_ulpiphy_clk > ti_scm0: setting internal 10c for usbb1_ulpiphy_dir > ti_scm0: setting internal 10c for usbb1_ulpiphy_nxt > ti_scm0: setting internal 10c for usbb1_ulpiphy_dat0 > ti_scm0: setting internal 10c for usbb1_ulpiphy_dat1 > ti_scm0: setting internal 10c for usbb1_ulpiphy_dat2 > ti_scm0: setting internal 10c for usbb1_ulpiphy_dat3 > ti_scm0: setting internal 10c for usbb1_ulpiphy_dat4 > ti_scm0: setting internal 10c for usbb1_ulpiphy_dat5 > ti_scm0: setting internal 10c for usbb1_ulpiphy_dat6 > ti_scm0: setting internal 10c for usbb1_ulpiphy_dat7 > gpio0: mem > 0x4a310000-0x4a310fff,0x48055000-0x48055fff,0x48057000-0x48057fff,0x48059000-0x48059fff,0x4805b000-0x4805bfff,0x4805d000-0x4805dfff > irq 61,62,63,64,65,66 on simplebus0 > gpioc0: on gpio0 > gpiobus0: on gpio0 > ehci0: mem > 0x4a064c00-0x4a064cff,0x4a064000-0x4a0646ff,0x4a062000-0x4a062fff irq 109 > on simplebus0 > ehci0: Starting TI EHCI USB Controller > ehci0: UHH revision 0x50700100 > ehci0: OMAP_UHH_SYSCONFIG: 0x00000014 > ehci0: UHH setup done, uhh_hostconfig=0x8000001c > usbus0: EHCI version 1.0 > usbus0 on ehci0 > ehci0: usbpf: Attached > iichb0: mem 0x48070000-0x480700ff irq 88 on simplebus0 > iichb0: I2C revision 4.0 > iicbus0: on iichb0 > iic0: on iicbus0 > ti_sdma0: mem 0x4a056000-0x4a056fff irq 44,45,46,47 > on simplebus0 > ti_sdma0: sDMA revision 00010900 > ti_mmchs0: mem 0x4809c000-0x4809cfff > irq 115 on simplebus0 > mmc0: on ti_mmchs0 > Timecounters tick every 10.000 msec > tcp_init: net.inet.tcp.tcbhashsize auto tuned to 16384 > lo0: bpf attached > usbus0: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: > on usbus0 > mmc0: Probing bus > mmc0: SD 2.0 interface conditions: OK > mmc0: SD probe: OK (OCR: 0x40ff8000) > mmc0: Current OCR: 0x00ff8000 > mmc0: Probing cards > mmc0: New card detected (CID 0353445355303447801c3557c400c9f5) > uhub0: 3 ports with 3 removable, self powered > mmc0: New card detected (CSD 400e00325b5900001d8a7f800a4040b9) > mmc0: Card at relative address 0xe624 added: > mmc0: card: SDHC SU04G 8.0 SN 473257924 MFG 09/2012 by 3 SD > mmc0: bus: 4bit, 50MHz, high speed timing > mmc0: memory: 7744512 blocks, erase sector 8192 blocks > mmc0: setting transfer rate to 25.000MHz > mmcsd0: 4GB at mmc0 > 25.0MHz/4bit/1-block > random: unblocking device. > GEOM:ugen0.2: at usbus0 > uhub1: on > usbus0 > uhub1: MTT enabled > new disk mmcsd0 > > mmc0: setting bus width to 4 bits > GEOM_PART: partition 1 is not aligned on 4194304 bytes > GEOM_PART: partition 2 is not aligned on 4194304 bytes > uhub1: 5 ports with 4 removable, self powered > GEOM_PART: partition 1 is not aligned on 4194304 bytes > Root mount waiting for: usbus0 > ugen0.3: at usbus0 > smsc0: on usbus0 > Root mount waiting for: usbus0 > Trying to mount root from ufs:/dev/mmcsd0s2 [rw,noatime]... > smsc0: chip 0xec00, rev. 0002 > miibus0: on smsc0 > ukphy0: PHY 1 on miibus0 > ukphy0: OUI 0x00800f, model 0x000c, rev. 3 > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ue0: on smsc0 > ue0: bpf attached > ue0: Ethernet address: d2:20:2a:b7:50:c7 > warning: no time-of-day clock registered, system time will not be set > accurately > start_init: trying /sbin/init > Spurious interrupt detected [0x000003ff] > Spurious interrupt detected [0x000003ff] > Spurious interrupt detected [0x000003ff] > Spurious interrupt detected [0x000003ff] > and so on... > > > -- > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. > > > On Fri, Feb 14, 2014 at 12:28 AM, Glen Barber wrote: > >> On Tue, Feb 11, 2014 at 08:20:25PM -0500, Glen Barber wrote: >> > On Wed, Feb 12, 2014 at 10:10:04AM +0900, Lundberg, Johannes wrote: >> > > Thanks! Will Pandaboard also show up here soon? >> > > >> > >> > Yes. >> > >> >> Can you test the image located here? If it works for you, PANDABOARD >> will be included in the next set of snapshot builds. >> >> http://people.freebsd.org/~gjb/PANDABOARD/ >> >> Glen >> >> > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. From owner-freebsd-arm@FreeBSD.ORG Sun Feb 16 11:11:55 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 041224D4; Sun, 16 Feb 2014 11:11:55 +0000 (UTC) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id B710C148F; Sun, 16 Feb 2014 11:11:54 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com 6323E3F4AD DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1392549113; bh=1YEok5W3WRRe4z5jSbz55ecJDDiFetyEzUKLCgD+P4M=; h=Date:From:To:Cc:Subject; b=eRAL6XLE4J4EyND+WC4CFpuVhf/mcGYSvE0C/ZUMlzA7MqCdQ1InGBJl581JLeSHY r+fwhGYBaoyavMIV5Z093m52zImQ6WhEtZt4NWevCjkX8gPp93XDtFwqwlQfBfmY2S tfNm4Pluhq2fbGeRIV0hE+3WcksVqWG2nPCkXbZ4= Date: Sun, 16 Feb 2014 12:11:53 +0100 From: Ilya Bakulin To: Adrian Chadd , Alexander Motin , Warner Losh Subject: MMC/SDIO stack under CAM Message-ID: <20140216111153.GA74858@olymp.kibab.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline Cc: freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 11:11:55 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi list, so I still want to move SDIO stack integration forward. As was already discussed, the best thing to do would be to have MMC stack under CAM. I have tried to understand how the CAM works for the existing drivers. Below is the structure for USB sticks: +-----------------------+ |Kernel (disk interface)| +-----------------------+ | BIO | +-------------------+ |da (storage driver)| +-------------------+ | CCB | +------------------------+ |CAM Layer sys/cam/scsi/*| +------------------------+ | CCB | +------------------+ |umass (HBA == SIM)| +------------------+ | usbd_* | +--------------------------+ |USB stack (and controller)| +--------------------------+ So da(4) doesn't know anything about USB. At this point I thought, that in this case da(4) will happily communicate with MMC/SD cards, if we provide a SIM for MMC! So the structure for MMC would be like this: +-----------------------+ |Kernel (disk interface)| +-----------------------+ | BIO | +-------------------+ |da (storage driver)| +-------------------+ | CCB | +------------------------+ |CAM Layer (sys/cam/mmc/*| +------------------------+ | CCB | +-------------------+ |mmc_cam (HBA == SIM| +-------------------+ | SD/MMC protocol (struct mmc_request) | +-------------------------------------------+ | MMC ctrlr driver (sdhci_ti, ..., mmcnull) | +-------------------------------------------+ | | +------------------+ | MMC/SD/SDIO Card | +------------------+ (the mmcnull driver is the pseudo-driver that I'm writing to make it possible to develop and test the whole thing on the VM). So MMC SIM and MMC controller driver would exchange mmc_requests, as it was before, with the exception that command completion will be reported differently (to utilize async callbacks system of CAM). For SDIO card, the situation will be different. Essentially, we should allow a device driver to send arbitrary messages to the card. So the device driver will attach directly to the scbus. Please let me know your thoughts about it. I really want SDIO make its way into the kernel, because there is an increasing number of ARM boards on the market that have integrated SDIO WLAN on them and we cannot support them fully. -- Ilya --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iEYEARECAAYFAlMAnPcACgkQo9vlj1oadwhvqQCdHvVy3fWYl6m49MBpKpDfk2XG i/UAn1LsZym1H2QokRa3V9KowxHqgqrK =rC+Z -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-arm@FreeBSD.ORG Sun Feb 16 16:35:57 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32464AD4; Sun, 16 Feb 2014 16:35:57 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F214B1B1B; Sun, 16 Feb 2014 16:35:56 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 8BCA617CE4; Sun, 16 Feb 2014 16:35:48 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 8BCA617CE4 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 16 Feb 2014 11:35:47 -0500 From: Glen Barber To: "Lundberg, Johannes" Subject: Re: Raspberry Pi and BeagleBone images available on FreeBSD FTP mirrors Message-ID: <20140216163547.GB1667@glenbarber.us> References: <6620C833-9D56-4367-AA4D-D78D4BCA2D40@neville-neil.com> <20140211161142.GA1665@glenbarber.us> <20140211211746.28beee52@cuisine.seix> <20140211203645.GB1650@glenbarber.us> <20140212010827.GA1671@glenbarber.us> <20140212012025.GB1671@glenbarber.us> <20140213152802.GH1667@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="x68wm+TSW4ddya8z" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 16:35:57 -0000 --x68wm+TSW4ddya8z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 16, 2014 at 05:37:10PM +0900, Lundberg, Johannes wrote: > Hi Glen >=20 > This is what I get when booting your image (burnt to 4 GB ScanDisk Ultra = HC > card) >=20 Do you have a slower SD card you can try? I do not have one of these boards, so am limited to what help I can provide. Glen --x68wm+TSW4ddya8z Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTAOjjAAoJELls3eqvi17QkikP/0maqXy8xkhj8h6pDXzflWU7 iAzBJkc/YELNUfMZVXziPLKzYhiC5GxGg8EDThZf2ZUmrTNOLZm6x2JucMuPBXNn YT3wHD4ZJL7mLDHJdpJ9inI4/cQmyRiCmrrmU4NAqI/p4oQc+fo9kBRg2aN158qM HPaVHC/CYGk1dNE0qStXPpXRwdbGGAE5LKh7nhejXOMHJEY00GAaDzsWPQgO/H/g TeB8g7dbkAPzxYArGk1lVhszf8RSoKTJ2uZwcSoJPgbk0MQXFqJQ0M+luEe/UF+E DqWtYLDlGwTDklHHtK1nKjt/+ubmT+u/vBUB5iSIyBo7onNS13ziZ9wux8V6TOiY ltXJcQiUe4YXTjVZPdzBx0XZwJbXt6M95b2TCJpygicbh6VQyFzobpzBh9PCTcq5 DGQOAuK86BKI0vyH1wNu8bjp2sPsNtM3uWKkZobj3ely5JVpsAqceeXhF2j/47Ke VNYyBqMWruUpxhfbZHl/FEOn2XdmujI5t0Y6i8z8KCpTzLrcaw02c1JYW67R0qxy n3ZVWhXzmuoli2M9l8ZV6OYjdTTKWkKxoWUryt1quHJBnAzog+ES1inejdnTh6pi ZFDUqLM9h0PhGZz0ZP88RdOZ1zPwrn4CemSTP/m4qo06p8p41iZIGZ3EUlIRQFSw zOBnZXg460L/5T72SETI =ZbFZ -----END PGP SIGNATURE----- --x68wm+TSW4ddya8z-- From owner-freebsd-arm@FreeBSD.ORG Sun Feb 16 18:05:39 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59E77B02 for ; Sun, 16 Feb 2014 18:05:39 +0000 (UTC) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1BE2411D7 for ; Sun, 16 Feb 2014 18:05:38 +0000 (UTC) Received: by mail-oa0-f53.google.com with SMTP id m1so16867009oag.12 for ; Sun, 16 Feb 2014 10:05:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=QOZ2jb5M5CNdjVCDwj/oN5YST4Oq1B2qpZOi3TDSFHE=; b=XVb14ev4RK8HrZAmCIwxGm7vA7X4tvtczrkABcIAJfCJyruiKLNAAI8REub4R2ZGst sx6PmDtZLJuFISNxGtSaoOFEOuJvO7B2nxTP+GHOtsWQx2u3zFZ2Jj41h7MfDsQ/NTno fbeyLw3nuIubSGxDSZ4DXVtCI3TlhjdH0/1TdQtLKQyxBKeuXgTbkzYOxsU5FCyoUohg tAGvpINNKTx3qYFY35gFdDrVJEvXeQNX5TizRvLEkKtWw01qq834603adYolLiH5BAzR pXQSaKbZT8LG9Lbkp9u2pj0X3FjpUKioVkhhcgBm7WKfg0s+ASbmvHbU+6BSJEY/Zmay Ghlw== X-Gm-Message-State: ALoCoQkZthhN7m0FlbeQdjzrStprsE2KQ1YWiQyvI/QVG13f1LGvWif+XxvKmXZ42ESb1TDAXSWC X-Received: by 10.182.241.8 with SMTP id we8mr5116obc.62.1392573938012; Sun, 16 Feb 2014 10:05:38 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id o6sm87669176oel.4.2014.02.16.10.05.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Feb 2014 10:05:36 -0800 (PST) Sender: Warner Losh Subject: Re: MMC/SDIO stack under CAM Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20140216111153.GA74858@olymp.kibab.com> Date: Sun, 16 Feb 2014 11:05:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> References: <20140216111153.GA74858@olymp.kibab.com> To: Ilya Bakulin X-Mailer: Apple Mail (2.1085) Cc: Adrian Chadd , freebsd-hackers@freebsd.org, Alexander Motin , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 18:05:39 -0000 On Feb 16, 2014, at 4:11 AM, Ilya Bakulin wrote: > Hi list, > so I still want to move SDIO stack integration forward. > As was already discussed, the best thing to do would be to > have MMC stack under CAM. > I have tried to understand how the CAM works for the existing drivers. >=20 > Below is the structure for USB sticks: >=20 > +-----------------------+ > |Kernel (disk interface)| > +-----------------------+ > | > BIO > | > +-------------------+ > |da (storage driver)| > +-------------------+ > | > CCB > | > +------------------------+ > |CAM Layer sys/cam/scsi/*| > +------------------------+ > | > CCB > | > +------------------+ > |umass (HBA =3D=3D SIM)| > +------------------+ > | > usbd_* > | > +--------------------------+ > |USB stack (and controller)| > +--------------------------+ >=20 > So da(4) doesn't know anything about USB. > At this point I thought, that in this case da(4) > will happily communicate with MMC/SD cards, if we provide > a SIM for MMC! So the structure for MMC would be like this: >=20 > +-----------------------+ > |Kernel (disk interface)| > +-----------------------+ > | > BIO > | > +-------------------+ > |da (storage driver)| > +-------------------+ > | > CCB > | > +------------------------+ > |CAM Layer (sys/cam/mmc/*| > +------------------------+ > | > CCB > | > +-------------------+ > |mmc_cam (HBA =3D=3D SIM| > +-------------------+ > | > SD/MMC protocol (struct mmc_request) > | > +-------------------------------------------+ > | MMC ctrlr driver (sdhci_ti, ..., mmcnull) | > +-------------------------------------------+ > | > | > +------------------+ > | MMC/SD/SDIO Card | > +------------------+ >=20 > (the mmcnull driver is the pseudo-driver that I'm writing > to make it possible to develop and test the whole thing > on the VM). that's cool! I'd thought of writing a mmcsim that I could use to develop = the stack on x86, but time pressures of my job precluded that (though in = hind sight, it would have saved a lot of time). > So MMC SIM and MMC controller driver would exchange mmc_requests, > as it was before, with the exception that command completion will be > reported differently (to utilize async callbacks system of CAM). >=20 > For SDIO card, the situation will be different. Essentially, > we should allow a device driver to send arbitrary messages to the = card. > So the device driver will attach directly to the scbus. >=20 > Please let me know your thoughts about it. > I really want SDIO make its way into the kernel, because there > is an increasing number of ARM boards on the market that have = integrated > SDIO WLAN on them and we cannot support them fully. Generally, I like this idea... I'd be very interested in some of the = specifics to make the direct attachment work with SDIO. That's the one = area I either don't think I understand your proposal well enough, or I = do and I'm concerned about it. :) So maybe write a bit more about the = details of the SDIO cards and how they's interact with CAM in this = scenario... The notion of moving MMC/SD into the CAM stack has been around since I = started working on MMC. At the time, CAM was too SCSI centric to do it, = but Alexander Motin's work has generally improved that situation, so it = may be possible now to do it and shake out the few dark corners of CAM = where this isn't the case. I also think it should help performance a lot = since we're currently single threaded to the card (but that's also the = nature of the bus), which introduces some round-trip latencies between = too many threads that CAM may help us avoid. Warner= From owner-freebsd-arm@FreeBSD.ORG Sun Feb 16 19:20:00 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2FB5F6 for ; Sun, 16 Feb 2014 19:20:00 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AC0A216CD for ; Sun, 16 Feb 2014 19:20:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1GJK0vY094631 for ; Sun, 16 Feb 2014 19:20:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1GJK0hB094630; Sun, 16 Feb 2014 19:20:00 GMT (envelope-from gnats) Resent-Date: Sun, 16 Feb 2014 19:20:00 GMT Resent-Message-Id: <201402161920.s1GJK0hB094630@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-arm@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Stephen Woolerton Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFEFBF9F for ; Sun, 16 Feb 2014 19:15:41 +0000 (UTC) Received: from newred.freebsd.org (cgiserv.freebsd.org [IPv6:2001:1900:2254:206a::50:4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AC00916B6 for ; Sun, 16 Feb 2014 19:15:41 +0000 (UTC) Received: from cgiserv.freebsd.org ([127.0.1.6]) by newred.freebsd.org (8.14.7/8.14.7) with ESMTP id s1GJFfW5066004 for ; Sun, 16 Feb 2014 19:15:41 GMT (envelope-from nobody@cgiserv.freebsd.org) Received: (from nobody@localhost) by cgiserv.freebsd.org (8.14.7/8.14.7/Submit) id s1GJFfIr065999; Sun, 16 Feb 2014 19:15:41 GMT (envelope-from nobody) Message-Id: <201402161915.s1GJFfIr065999@cgiserv.freebsd.org> Date: Sun, 16 Feb 2014 19:15:41 GMT From: Stephen Woolerton To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: arm/186823: icu port won't compile on Raspberry Pi X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 19:20:00 -0000 >Number: 186823 >Category: arm >Synopsis: icu port won't compile on Raspberry Pi >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Feb 16 19:20:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: Stephen Woolerton >Release: FreeBSD 10.0-STABLE #0 r261419 >Organization: >Environment: FreeBSD raspberry-pi 10.0-STABLE FreeBSD 10.0-STABLE #0 r261419: Mon Feb 3 15:11:33 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm >Description: Raspberry Pi Model B with 512 MB RAM and I can't compile icu from ports. Using ports as at 12 Feb 2014. I have attached a SATA drive on the USB port and configured it for swap in case lack of memory is an issue, but no difference. pkgdata: cd ../lib/ && rm -f libicudata.so.52 && ln -s libicudata.so.52.1 libicudata.so.52 pkgdata: cd ../lib/ && rm -f libicudata.so && ln -s libicudata.so.52.1 libicudata.so gmake[3]: Leaving directory `/usr/ports/devel/icu/work/icu/source/data' gmake[2]: Making `all' in `extra' gmake[3]: Entering directory `/usr/ports/devel/icu/work/icu/source/extra' gmake[3]: Making `all' in `uconv' gmake[4]: Entering directory `/usr/ports/devel/icu/work/icu/source/extra/uconv' mkdir uconvmsg c++ -D_REENTRANT -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1 -DU_HAVE_TIMEZONE=0 -I../../common -I../../i18n -I./../toolutil -DU_ATTRIBUTE_DEPRECATED= -DUCONVMSG_LINK=uconvmsg -O -pipe -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long --std=c++0x -c -o uconv.o uconv.cpp cc -D_REENTRANT -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1 -DU_HAVE_TIMEZONE=0 -I../../common -I../../i18n -I./../toolutil -DU_ATTRIBUTE_DEPRECATED= -DUCONVMSG_LINK=uconvmsg -O -pipe -std=c99 -Wall -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -c -o uwmsg.o uwmsg.c LD_LIBRARY_PATH=../../lib:../../stubdata:../../tools/ctestfw:$LD_LIBRARY_PATH ../../bin/genrb -e UTF-8 -s resources -d uconvmsg root.txt LD_LIBRARY_PATH=../../lib:../../stubdata:../../tools/ctestfw:$LD_LIBRARY_PATH ../../bin/genrb -e UTF-8 -s resources -d uconvmsg fr.txt gmake -f pkgdataMakefile gmake[5]: Entering directory `/usr/ports/devel/icu/work/icu/source/extra/uconv' rm -rf pkgdata.inc gmake[5]: Leaving directory `/usr/ports/devel/icu/work/icu/source/extra/uconv' LD_LIBRARY_PATH=../../lib:../../stubdata:../../tools/ctestfw:$LD_LIBRARY_PATH ../../bin/pkgdata -p uconvmsg -O pkgdata.inc -m static -s uconvmsg -d uconvmsg -T uconvmsg uconvmsg/uconvmsg.lst pkgdata: cc -D_REENTRANT -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1 -DU_HAVE_TIMEZONE=0 -DU_ATTRIBUTE_DEPRECATED= -O -pipe -std=c99 -Wall -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -c -I../../common -I../../common -DPIC -fPIC -o uconvmsg/uconvmsg_dat.o uconvmsg/uconvmsg_dat.c pkgdata: cc -D_REENTRANT -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1 -DU_HAVE_TIMEZONE=0 -DU_ATTRIBUTE_DEPRECATED= -O -pipe -std=c99 -Wall -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -c -I../../common -I../../common -DPIC -fPIC -o uconvmsg/root_res.o uconvmsg/root_res.c pkgdata: cc -D_REENTRANT -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1 -DU_HAVE_TIMEZONE=0 -DU_ATTRIBUTE_DEPRECATED= -O -pipe -std=c99 -Wall -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -c -I../../common -I../../common -DPIC -fPIC -o uconvmsg/fr_res.o uconvmsg/fr_res.c pkgdata: ar r uconvmsg/libuconvmsg.a uconvmsg/uconvmsg_dat.o uconvmsg/root_res.o uconvmsg/fr_res.o ar: warning: creating uconvmsg/libuconvmsg.a pkgdata: ranlib uconvmsg/libuconvmsg.a c++ -O -pipe -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long --std=c++0x -o ../../bin/uconv uconv.o uwmsg.o -L../../lib -licui18n -L../../lib -licuuc -L../../stubdata -licudata -lm uconvmsg/libuconvmsg.a cd ../.. \ && CONFIG_FILES=extra/uconv/uconv.1 CONFIG_HEADERS= /bin/sh ./config.status config.status: creating extra/uconv/uconv.1 gmake[4]: Leaving directory `/usr/ports/devel/icu/work/icu/source/extra/uconv' gmake[4]: Entering directory `/usr/ports/devel/icu/work/icu/source/extra' gmake[4]: Nothing to be done for `all-local'. gmake[4]: Leaving directory `/usr/ports/devel/icu/work/icu/source/extra' gmake[3]: Leaving directory `/usr/ports/devel/icu/work/icu/source/extra' gmake[2]: Making `all' in `test' gmake[3]: Entering directory `/usr/ports/devel/icu/work/icu/source/test' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/usr/ports/devel/icu/work/icu/source/test' gmake[3]: Entering directory `/usr/ports/devel/icu/work/icu/source' Note: rebuild with "gmake VERBOSE=1 all-local" to show all compiler parameters. gmake[3]: Leaving directory `/usr/ports/devel/icu/work/icu/source' gmake[2]: Leaving directory `/usr/ports/devel/icu/work/icu/source' Segmentation fault (core dumped) ===>>> make failed for devel/icu ===>>> Aborting update ===>>> Update for devel/icu failed ===>>> Aborting update ===>>> Killing background jobs Terminated ===>>> You can restart from the point of failure with this command line: portmaster lang/gnustep-base devel/icu devel/libffi devel/pkgconf math/gmp devel/libtool security/gnutls security/libgpg-error security/libtasn1 security/nettle security/p11-kit security/ca_root_nss security/libgcrypt devel/binutils devel/bison math/mpfr lang/gcc math/mpc textproc/libxml2 textproc/libxslt ===>>> Exiting root@raspberry-pi:/usr/ports/devel/icu # ---------- root@raspberry-pi:~ # portmaster -L ===>>> Root ports (No dependencies, not depended on) ===>>> dialog4ports-0.1.5_2 ===>>> gmake-3.82_1 ===>>> libdispatch-210_1 ===>>> pkg-1.2.6 ===>>> portmaster-3.17.3 ===>>> screen-4.0.3_14 ===>>> 6 root ports ===>>> Trunk ports (No dependencies, are depended on) ===>>> autoconf-wrapper-20131203 ===>>> automake-wrapper-20131203 ===>>> cmake-modules-2.8.12.1_1 ===>>> libobjc2-1.7_1 ===>>> m4-1.4.17,1 ===>>> perl5-5.16.3_6 ===>>> 6 trunk ports ===>>> Branch ports (Have dependencies, are depended on) ===>>> autoconf-2.69 ===>>> 1 branch ports ===>>> Leaf ports (Have dependencies, not depended on) ===>>> automake-1.14 ===>>> cmake-2.8.12.1 ===>>> gnustep-make-2.6.6 ===>>> help2man-1.43.3_1 ===>>> 4 leaf ports ===>>> 17 total installed ports ===>>> There are no new versions available >How-To-Repeat: Attempt to install ICU from ports on a Raspberry Pi >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Sun Feb 16 21:30:05 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EF49F8B; Sun, 16 Feb 2014 21:30:05 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 451071115; Sun, 16 Feb 2014 21:30:05 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id B7E9117A3E; Sun, 16 Feb 2014 21:30:03 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us B7E9117A3E Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 16 Feb 2014 16:30:01 -0500 From: Glen Barber To: freebsd-arm@FreeBSD.org Subject: "No valid device tree blob found" error Message-ID: <20140216213001.GF1667@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="REpkP7z4J/KxIT5U" Content-Disposition: inline X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 21:30:05 -0000 --REpkP7z4J/KxIT5U Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Images for RPI-B and BEAGLEBONE (and I suspect PANDABOARD) are failing to boot this week. The images are built against r261948. Console messages during boot: ## Starting application at 0x88000054 ... Consoles: U-Boot console =20 Compatible API signature found @9f242240 MMC Device 2 not found MMC Device 3 not found Number of U-Boot devices: 2 FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@grind.freebsd.org, Sun Feb 16 18:10:43 UTC 2014) DRAM: 512MB Device: disk Loading /boot/defaults/loader.conf=20 /boot/kernel/kernel data=3D0x460bc8+0x2c7438 syms=3D[0x4+0x85a60+0x4+0x50c89] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 Using DTB provided by U-Boot. No valid device tree blob found!WARNING! Trying to fire up the kernel, but no device tree blob found! Any ideas if this is error on my part, or a problem in head/ ? The stable/10/ images boot fine, so I do not suspect any code changes in the build process. Thanks. Glen --REpkP7z4J/KxIT5U Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTAS3ZAAoJELls3eqvi17QJpEP/3TM2226Ct5+f43sH5weDbVF qpgICzCj/HOUgiWs17ZBWTogZ79nHRy2Gad3GOQhsg1tBJzkkaNXjLbTYTfkxgF4 a7YcqauTi0efRS+qhh5WPeRtYC+lWFaC40oeZ3/hz+hEbqEz2o6JV95+k6K43ZVK n+Lg6aaRqulaMKm97IOlCGXmiYOkzXAuqonDNAQFHA3Xbuxj0uI37gnSQZKD0Ahk xh5hSxgaUVSrLpmYSiXv+UFI8SiXwrYvRC7Jw4SoI5NexSrdmgu2ueLxVNs4gYXX ASx7SEPnpI3A3HoLSw1jhtu61Xpv9y3sNDuEUVff2JVKGpHmFOzGIjtjNhQf4Ezx 8NDufKE323zSB9BBcV6AN+yaPAkH5nPeBNCi6qLnpqR2mElmMa5U3P9joik7LRQt 8m9VH2AmziB42DOG3dgSckLLhfTb/297/6jJ+R3cJW9wiY0LwzGmHiLqz0YQwUMq hhUpckzP5H+UZaB6rK9QWkypYzupyfymGWqdMrCYfs2Mfdb2/wCrksPW8iuASykH 3J4jl/6yz6/NJz8/pIGzanemQJR5ZAlmCxx6V7c21PymkMApn3WjCQkZhwEixmmi wLmXov664RUi4Dh/g39y1vajBYjvTWALT5DaJWKVz3pEvSPGDX76+Ep7HZnvh/i5 afaZxqHKRssoeoAMIEwL =8nX8 -----END PGP SIGNATURE----- --REpkP7z4J/KxIT5U-- From owner-freebsd-arm@FreeBSD.ORG Sun Feb 16 21:31:55 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B98466A; Sun, 16 Feb 2014 21:31:55 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8BB8F1188; Sun, 16 Feb 2014 21:31:55 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 54F9617A84; Sun, 16 Feb 2014 21:31:54 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 54F9617A84 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 16 Feb 2014 16:31:52 -0500 From: Glen Barber To: freebsd-arm@FreeBSD.org Subject: Re: "No valid device tree blob found" error Message-ID: <20140216213152.GG1667@glenbarber.us> References: <20140216213001.GF1667@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NyVXgNZ34wipDCDo" Content-Disposition: inline In-Reply-To: <20140216213001.GF1667@glenbarber.us> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 21:31:55 -0000 --NyVXgNZ34wipDCDo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 16, 2014 at 04:30:01PM -0500, Glen Barber wrote: > Images for RPI-B and BEAGLEBONE (and I suspect PANDABOARD) are failing > to boot this week. >=20 > The images are built against r261948. Console messages during boot: >=20 > ## Starting application at 0x88000054 ... > Consoles: U-Boot console =20 > Compatible API signature found @9f242240 > MMC Device 2 not found > MMC Device 3 not found > Number of U-Boot devices: 2 >=20 > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (root@grind.freebsd.org, Sun Feb 16 18:10:43 UTC 2014) > DRAM: 512MB >=20 > Device: disk > Loading /boot/defaults/loader.conf=20 > /boot/kernel/kernel data=3D0x460bc8+0x2c7438 > syms=3D[0x4+0x85a60+0x4+0x50c89] >=20 > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... =20 > Using DTB provided by U-Boot. > No valid device tree blob found!WARNING! Trying to fire up the kernel, > but no device tree blob found! >=20 > Any ideas if this is error on my part, or a problem in head/ ? The > stable/10/ images boot fine, so I do not suspect any code changes in the > build process. >=20 Correction: RPI-B fails to boot. BEAGLEBONE boots after pressing 'q' when this message is displayed. Glen --NyVXgNZ34wipDCDo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTAS5IAAoJELls3eqvi17QwhAP/jo6ojRmsl0yvSbhaSxW10eT WcCfiLYHQjfzbvoeW2j/kXyzeqYAOxG4gFIxCSt1yAkUzesAiMS9mzn+jFfnMfEH /WVr96qKXhzucCwrNWCGtnINAcRygOMbZxrkSTlRdnwJ4cbB5xLXsCjEPtY5YIId n8d2pGemzsozyTCq/hhIvx9TXnILWofnEzAsDXyRRpTB9micl1lSnSX9noQZ1tv+ CkBdCcUlqwAzBCOgspPEaVyLoAMp4d6+FZ6bJ2kdqQRVc4PQHLS9c3xurjkAIViX +ISrxLBZGjZQGCd2hj7HXqe0anxfsblvaCSd+E3t0aYq7sbr7YveHbn233rVqTTA NEzNkrv/vqW6u/HLMCTRFcFkUIvU9FoGQca7mkpwtD9PMbxVpUWglsfKwzbORCcm b3KYPUn2IAbHynGNuiEthejw6P7Y5fx9wNRvZQofV59rMlSur1Xudi6blMcJjOyV ISh7m91wf/CXEf2RJ1qVOxmii7jPF4C7uKFrYcueXvWs3pkDKwnW8edGFlaXFWg/ +bibnrp4Nr7QcuDCItKYkHxh7n9UfQhhUHRCKlcCTjk+Aik8osbQcfPkdXO2o45g NVh3KJV1/dJjqPTQ3AZp55qvXjj3FYUFWuTxMU2YfUNRTDNPV7d6XAiCpn3jM2wf XxwdIuyneorGG0jqmIs3 =2P51 -----END PGP SIGNATURE----- --NyVXgNZ34wipDCDo-- From owner-freebsd-arm@FreeBSD.ORG Mon Feb 17 01:01:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59C89407 for ; Mon, 17 Feb 2014 01:01:26 +0000 (UTC) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1A3471FF1 for ; Mon, 17 Feb 2014 01:01:25 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id c10so4238046igq.0 for ; Sun, 16 Feb 2014 17:01:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qj4ySKrFcZiqLtNReXLjnUhASxJgzLP6LUjez33cBiM=; b=NLnFd6MLfCpFt0fMe72yD0hv84YhrNcZpdAHB9Wr3baDZ4xDeZDIfGaHXXzMs50Zoh 0meatlxoNzGfsRhohTw4YkLZeGNxN2OdoI2Adl7+gvwc/oX4g1AXK5CRXHS1OEe0onMq XByF+Xc2XHtgS2LnCEVAnw54SMFUiEqy12NFyzXR4xuAAt6VeqJHlDM2lzMzCq6jPw4Q kOnzGg4Acyc6/6bq8m68fDFcF7vcbgiSw8qzivtaLjHN5xvx93hJ2F389O0G4rObgiVh x7yZAXw3msVXeh8UmJe2ObziaDxbcKAj9RPQAshM6wBwZtfkSoW6b3E+sWaUbGZp/Owy +LFw== X-Gm-Message-State: ALoCoQnGljWZoeNWO1nZAkwY2LKOImGSOxTZm0AwnKyVeKKUYTIjwz6APp6ezVbuxDdgBpi/WHyhR1Lp9Q1mbjr/X+2+w6unRnCOS938aTikIXAEYwI0Rqk= X-Received: by 10.42.33.65 with SMTP id h1mr20615icd.72.1392598885139; Sun, 16 Feb 2014 17:01:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.128.200 with HTTP; Sun, 16 Feb 2014 17:01:10 -0800 (PST) In-Reply-To: <20140216163547.GB1667@glenbarber.us> References: <6620C833-9D56-4367-AA4D-D78D4BCA2D40@neville-neil.com> <20140211161142.GA1665@glenbarber.us> <20140211211746.28beee52@cuisine.seix> <20140211203645.GB1650@glenbarber.us> <20140212010827.GA1671@glenbarber.us> <20140212012025.GB1671@glenbarber.us> <20140213152802.GH1667@glenbarber.us> <20140216163547.GB1667@glenbarber.us> From: "Lundberg, Johannes" Date: Mon, 17 Feb 2014 10:01:10 +0900 Message-ID: Subject: Re: Raspberry Pi and BeagleBone images available on FreeBSD FTP mirrors To: Glen Barber Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 01:01:26 -0000 Hi Glen! With a slower card on Pandaboard I get same or similar result.. ... Spurious interrupt detected [0x000003ff] Spurious interrupt detected [0x000003ff] Spurious interrupt detected [0x000003ff] Spurious interrupt detected [0x000003ff] Fatal kernel mode data abort: 'Alignment Fault 1' trapframe: 0xeb8a1bc8 FSR=00000001, FAR=00000003, spsr=20000193 r0 =00000000, r1 =fffffffe, r2 =00c06055, r3 =00000003 r4 =00008000, r5 =c0656f68, r6 =c0656f48, r7 =00000000 r8 =00000000, r9 =80000000, r10=00000000, r11=eb8a1c88 r12=c0667b18, ssp=eb8a1c18, slr=20000193, pc =c057ce2c [ thread pid 10 tid 100002 ] Stopped at __qdivrem+0xc4: ldrh r0, [r3] -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Mon, Feb 17, 2014 at 1:35 AM, Glen Barber wrote: > On Sun, Feb 16, 2014 at 05:37:10PM +0900, Lundberg, Johannes wrote: > > Hi Glen > > > > This is what I get when booting your image (burnt to 4 GB ScanDisk Ultra > HC > > card) > > > > Do you have a slower SD card you can try? > > I do not have one of these boards, so am limited to what help I can > provide. > > Glen > > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. From owner-freebsd-arm@FreeBSD.ORG Mon Feb 17 11:06:43 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C31A7CD2 for ; Mon, 17 Feb 2014 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9509711AE for ; Mon, 17 Feb 2014 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1HB6hna032968 for ; Mon, 17 Feb 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1HB6huv032966 for freebsd-arm@FreeBSD.org; Mon, 17 Feb 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Feb 2014 11:06:43 GMT Message-Id: <201402171106.s1HB6huv032966@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 11:06:43 -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/186823 arm icu port won't compile on Raspberry Pi o arm/186486 arm WPS authentication is failing o arm/185617 arm 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBon o arm/185046 arm [armv6] issues with dhclient/sshd and jemalloc on rasp o arm/184078 arm cross installworld missing include files o arm/183926 arm Crash when ctrl-c while process is enter o arm/183740 arm mutex on some arm hardware requires dcache enabled o arm/183668 arm Panic when read unalign in ddb o arm/182544 arm [patch] ARM busdma_machdep-v6.c o arm/182060 arm make buildworld fails on Raspberry PI o arm/181722 arm gdb on ARM unable to sensibly debug core file from ass o arm/181718 arm threads caused hung on ARM/RPI o arm/181601 arm Sporadic failure of root mount on ARM/Raspberry o arm/180080 arm Unmapped buffers on ARMv7 big-RAM boards o arm/179688 arm [patch] [rpi] serial console eats some characters at m o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o arm/175803 arm building xdev for arm failing o ports/175605 arm please fix build binutils-2.23.1 in raspberry pi o arm/173617 arm Dreamplug exhibits eSATA file corruption using network o kern/171096 arm [arm][xscale][ixp]Allow 16bit access on PCI bus o arm/166256 arm build fail in pmap.c o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o ports/161044 arm devel/icu does not build on arm o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) p arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on 35 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Feb 17 13:08:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21B83741; Mon, 17 Feb 2014 13:08:14 +0000 (UTC) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB9951E31; Mon, 17 Feb 2014 13:08:13 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id q58so10380202wes.24 for ; Mon, 17 Feb 2014 05:08:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5HvC5vYYWnupnzis7vLiqUFqIG1NubP6CeY3EQWDRfE=; b=JA84IWt9VquOrUKxvLQFgGSICDQIKweP2BGo4OmPG9cq9mdc4dLt+Gx9MegN+IAcCV QiWeyxmevcfQbb+eHsgntGWm2DyEyXD9+hGzcC04apiFbABw/D6KE0+Nr/7ny5bw2cRZ 3sPSnWEftGCsK0xEOc98jC/RTMhiA618ljMxYafB0PrIvUs1hn2Bb++VChxlADYrpVml Q08O2h32JRbgD6C4zXaebqvjpAxp79sXtDj7oMtJ6DV7NQ5xcXmAioRiXSQgy63BDmK2 7BDelCbsopwIwgnp4n36iKxpFDQioXErOIGN4IXWSMxhgpD7DHEnNfwnOrHPwS/STTGc +gvw== MIME-Version: 1.0 X-Received: by 10.194.201.134 with SMTP id ka6mr39170wjc.93.1392642492086; Mon, 17 Feb 2014 05:08:12 -0800 (PST) Received: by 10.216.240.66 with HTTP; Mon, 17 Feb 2014 05:08:11 -0800 (PST) In-Reply-To: <20140216213001.GF1667@glenbarber.us> References: <20140216213001.GF1667@glenbarber.us> Date: Mon, 17 Feb 2014 10:08:11 -0300 Message-ID: Subject: Re: "No valid device tree blob found" error From: Luiz Otavio O Souza To: Glen Barber Content-Type: multipart/mixed; boundary=047d7ba97e640b198604f299d9c9 Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 13:08:15 -0000 --047d7ba97e640b198604f299d9c9 Content-Type: text/plain; charset=ISO-8859-1 On 16 February 2014 18:30, Glen Barber wrote: > Images for RPI-B and BEAGLEBONE (and I suspect PANDABOARD) are failing > to boot this week. > > The images are built against r261948. Console messages during boot: > > ## Starting application at 0x88000054 ... > Consoles: U-Boot console > Compatible API signature found @9f242240 > MMC Device 2 not found > MMC Device 3 not found > Number of U-Boot devices: 2 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (root@grind.freebsd.org, Sun Feb 16 18:10:43 UTC 2014) > DRAM: 512MB > > Device: disk > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=0x460bc8+0x2c7438 > syms=[0x4+0x85a60+0x4+0x50c89] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Using DTB provided by U-Boot. > No valid device tree blob found!WARNING! Trying to fire up the kernel, > but no device tree blob found! > > Any ideas if this is error on my part, or a problem in head/ ? The > stable/10/ images boot fine, so I do not suspect any code changes in the > build process. > Glen, I think it is related to r261819. Looking at the code it looks like the attached patch may fix it (i'm still updating my images to the latest -head and would probably need a few hours before i can test it myself). Can you check if it works for you ? Thanks, Luiz --047d7ba97e640b198604f299d9c9 Content-Type: text/plain; charset=US-ASCII; name="fdt-loader.diff" Content-Disposition: attachment; filename="fdt-loader.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hrrr9ksn1 SW5kZXg6IGhlYWQvc3lzL2Jvb3QvZmR0L2ZkdF9sb2FkZXJfY21kLmMKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g aGVhZC9zeXMvYm9vdC9mZHQvZmR0X2xvYWRlcl9jbWQuYwkocmV2aXNpb24gMjYyMDM2KQorKysg aGVhZC9zeXMvYm9vdC9mZHQvZmR0X2xvYWRlcl9jbWQuYwkod29ya2luZyBjb3B5KQpAQCAtMjMw LDcgKzIzMCw3IEBACiAJaW50IGVycjsKIAogCWZkdHBfc2l6ZSA9IGZkdF90b3RhbHNpemUoaGVh ZGVyKTsKLQllcnIgPSBmZHRfY2hlY2tfaGVhZGVyKCZoZWFkZXIpOworCWVyciA9IGZkdF9jaGVj a19oZWFkZXIoaGVhZGVyKTsKIAlpZiAoZXJyIDwgMCkgewogCQlzcHJpbnRmKGNvbW1hbmRfZXJy YnVmLCAiZXJyb3IgdmFsaWRhdGluZyBibG9iOiAlcyIsCiAJCSAgICBmZHRfc3RyZXJyb3IoZXJy KSk7Cg== --047d7ba97e640b198604f299d9c9-- From owner-freebsd-arm@FreeBSD.ORG Mon Feb 17 17:17:09 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B50415B7; Mon, 17 Feb 2014 17:17:09 +0000 (UTC) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 72FBA18DB; Mon, 17 Feb 2014 17:17:09 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id s1HHH8qX073799; Mon, 17 Feb 2014 17:17:08 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id s1HHH7mn073794; Mon, 17 Feb 2014 17:17:07 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 17 Feb 2014 17:17:07 GMT Message-Id: <201402171717.s1HHH7mn073794@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 17:17:09 -0000 TB --- 2014-02-17 16:50:22 - tinderbox 2.20 running on freebsd-stable.sentex.ca TB --- 2014-02-17 16:50:22 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2014-02-17 16:50:22 - starting RELENG_9 tinderbox run for arm/arm TB --- 2014-02-17 16:50:22 - cleaning the object tree TB --- 2014-02-17 16:50:22 - /usr/local/bin/svn stat /src TB --- 2014-02-17 16:50:27 - At svn revision 262088 TB --- 2014-02-17 16:50:28 - building world TB --- 2014-02-17 16:50:28 - CROSS_BUILD_TESTING=YES TB --- 2014-02-17 16:50:28 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-17 16:50:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-17 16:50:28 - SRCCONF=/dev/null TB --- 2014-02-17 16:50:28 - TARGET=arm TB --- 2014-02-17 16:50:28 - TARGET_ARCH=arm TB --- 2014-02-17 16:50:28 - TZ=UTC TB --- 2014-02-17 16:50:28 - __MAKE_CONF=/dev/null TB --- 2014-02-17 16:50:28 - cd /src TB --- 2014-02-17 16:50:28 - /usr/bin/make -B buildworld >>> World build started on Mon Feb 17 16:50:30 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c:79: warning: type of 'SYSCTL_HANDLER_ARGS' defaults to 'int' /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c:84: warning: implicit declaration of function 'sysctl_handle_64' /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c:84: error: 'oidp' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c:84: error: (Each undeclared identifier is reported only once /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c:84: error: for each function it appears in.) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c:84: error: 'req' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c: At top level: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c:95: error: expected ')' before '(' token *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2014-02-17 17:17:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-17 17:17:07 - ERROR: failed to build world TB --- 2014-02-17 17:17:07 - 1071.82 user 213.34 system 1605.13 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Mon Feb 17 17:53:22 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1BC9A06; Mon, 17 Feb 2014 17:53:21 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9EE161D10; Mon, 17 Feb 2014 17:53:21 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id s1HHrKvn064037; Mon, 17 Feb 2014 17:53:20 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id s1HHrKf7064026; Mon, 17 Feb 2014 17:53:20 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 17 Feb 2014 17:53:20 GMT Message-Id: <201402171753.s1HHrKf7064026@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_8 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 17:53:22 -0000 TB --- 2014-02-17 17:40:11 - tinderbox 2.20 running on freebsd-legacy2.sentex.ca TB --- 2014-02-17 17:40:11 - FreeBSD freebsd-legacy2.sentex.ca 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-17 17:40:11 - starting RELENG_8 tinderbox run for arm/arm TB --- 2014-02-17 17:40:11 - cleaning the object tree TB --- 2014-02-17 17:40:11 - /usr/local/bin/svn stat /src TB --- 2014-02-17 17:40:15 - At svn revision 262098 TB --- 2014-02-17 17:40:16 - building world TB --- 2014-02-17 17:40:16 - CROSS_BUILD_TESTING=YES TB --- 2014-02-17 17:40:16 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-17 17:40:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-17 17:40:16 - SRCCONF=/dev/null TB --- 2014-02-17 17:40:16 - TARGET=arm TB --- 2014-02-17 17:40:16 - TARGET_ARCH=arm TB --- 2014-02-17 17:40:16 - TZ=UTC TB --- 2014-02-17 17:40:16 - __MAKE_CONF=/dev/null TB --- 2014-02-17 17:40:16 - cd /src TB --- 2014-02-17 17:40:16 - /usr/bin/make -B buildworld >>> World build started on Mon Feb 17 17:40:16 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c:80: warning: type of 'SYSCTL_HANDLER_ARGS' defaults to 'int' /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c:85: warning: implicit declaration of function 'sysctl_handle_quad' /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c:85: error: 'oidp' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c:85: error: (Each undeclared identifier is reported only once /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c:85: error: for each function it appears in.) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c:85: error: 'req' undeclared (first use in this function) /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c: At top level: /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c:96: error: expected ')' before '(' token *** [vdev.o] Error code 1 Stop in /src/cddl/lib/libzpool. *** [all] Error code 1 Stop in /src/cddl/lib. *** [cddl/lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** [buildworld] Error code 1 Stop in /src. TB --- 2014-02-17 17:53:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-17 17:53:20 - ERROR: failed to build world TB --- 2014-02-17 17:53:20 - 642.45 user 158.81 system 788.91 real http://tinderbox.freebsd.org/tinderbox-freebsd8-build-RELENG_8-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Mon Feb 17 17:53:26 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07438A08; Mon, 17 Feb 2014 17:53:26 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CC72E1D12; Mon, 17 Feb 2014 17:53:25 +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 1WFSNa-000FIk-Q7; Mon, 17 Feb 2014 17:53:19 +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 s1HHrFc7027640; Mon, 17 Feb 2014 10:53:15 -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: U2FsdGVkX19IgKl3ne3Aot1xKfDLItWJ Subject: Re: "No valid device tree blob found" error From: Ian Lepore To: Luiz Otavio O Souza In-Reply-To: References: <20140216213001.GF1667@glenbarber.us> Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Feb 2014 10:53:15 -0700 Message-ID: <1392659595.1145.15.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Glen Barber , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 17:53:26 -0000 On Mon, 2014-02-17 at 10:08 -0300, Luiz Otavio O Souza wrote: > On 16 February 2014 18:30, Glen Barber wrote: > > Images for RPI-B and BEAGLEBONE (and I suspect PANDABOARD) are failing > > to boot this week. > > > > The images are built against r261948. Console messages during boot: > > > > ## Starting application at 0x88000054 ... > > Consoles: U-Boot console > > Compatible API signature found @9f242240 > > MMC Device 2 not found > > MMC Device 3 not found > > Number of U-Boot devices: 2 > > > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > > (root@grind.freebsd.org, Sun Feb 16 18:10:43 UTC 2014) > > DRAM: 512MB > > > > Device: disk > > Loading /boot/defaults/loader.conf > > /boot/kernel/kernel data=0x460bc8+0x2c7438 > > syms=[0x4+0x85a60+0x4+0x50c89] > > > > Hit [Enter] to boot immediately, or any other key for command prompt. > > Booting [/boot/kernel/kernel]... > > Using DTB provided by U-Boot. > > No valid device tree blob found!WARNING! Trying to fire up the kernel, > > but no device tree blob found! > > > > Any ideas if this is error on my part, or a problem in head/ ? The > > stable/10/ images boot fine, so I do not suspect any code changes in the > > build process. > > > > > Glen, > > I think it is related to r261819. Looking at the code it looks like > the attached patch may fix it (i'm still updating my images to the > latest -head and would probably need a few hours before i can test it > myself). > > Can you check if it works for you ? > > Thanks, > > Luiz I believe your patch is correct; when I copied the code to do the header check it came from a context where the header variable was the struct itself, not a pointer to it. Odd that the error message doesn't seem to match, though. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Feb 17 19:03:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 841D8EE8; Mon, 17 Feb 2014 19:03:35 +0000 (UTC) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E824F15CC; Mon, 17 Feb 2014 19:03:34 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id q58so10706939wes.24 for ; Mon, 17 Feb 2014 11:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gp6DPT/Ui1tYdmGdPHipRiNTYsAasMmI7CrKo/sGOJo=; b=nS/opc6drvc/vFHSBT3I+itIwP7FN3VGnhFDdL3Tx55WsAjg1Q8I5rgVImWAbyXRPU mHX8DCmFkcC9QX/qr2qNqCtomaZV8qxUx9zN2W/VCKbt+8Re3vNCA8EcO23+yMEcjkXZ HxHvX1La5Nh38y9tqEfXmAbxCLQWjochQHewoY1BhKujnCxd9ye5rRai0lGnacJrqNGy 6ZtKl2hkhY4xd0KYq2mp1SVR7Q0pinNWUa668HZocdXS/nUbaCw42ZBrlAQZDJd7IpJ8 4kkoXcZmVgNQduLfu3gob94hJ7pwh8JQgqQaCf8I5Y15pOY/diDSTlKEu/mrYO2mD6mg SZCA== MIME-Version: 1.0 X-Received: by 10.180.187.16 with SMTP id fo16mr14439858wic.26.1392663813252; Mon, 17 Feb 2014 11:03:33 -0800 (PST) Received: by 10.216.240.66 with HTTP; Mon, 17 Feb 2014 11:03:32 -0800 (PST) In-Reply-To: <20140216213152.GG1667@glenbarber.us> References: <20140216213001.GF1667@glenbarber.us> <20140216213152.GG1667@glenbarber.us> Date: Mon, 17 Feb 2014 16:03:32 -0300 Message-ID: Subject: Re: "No valid device tree blob found" error From: Luiz Otavio O Souza To: Glen Barber Content-Type: multipart/mixed; boundary=001a11c266c4e17bd304f29ecf2f Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 19:03:35 -0000 --001a11c266c4e17bd304f29ecf2f Content-Type: text/plain; charset=ISO-8859-1 On 16 February 2014 18:31, Glen Barber wrote: > On Sun, Feb 16, 2014 at 04:30:01PM -0500, Glen Barber wrote: >> Images for RPI-B and BEAGLEBONE (and I suspect PANDABOARD) are failing >> to boot this week. >> >> The images are built against r261948. Console messages during boot: >> >> ## Starting application at 0x88000054 ... >> Consoles: U-Boot console >> Compatible API signature found @9f242240 >> MMC Device 2 not found >> MMC Device 3 not found >> Number of U-Boot devices: 2 >> >> FreeBSD/armv6 U-Boot loader, Revision 1.2 >> (root@grind.freebsd.org, Sun Feb 16 18:10:43 UTC 2014) >> DRAM: 512MB >> >> Device: disk >> Loading /boot/defaults/loader.conf >> /boot/kernel/kernel data=0x460bc8+0x2c7438 >> syms=[0x4+0x85a60+0x4+0x50c89] >> >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... >> Using DTB provided by U-Boot. >> No valid device tree blob found!WARNING! Trying to fire up the kernel, >> but no device tree blob found! >> >> Any ideas if this is error on my part, or a problem in head/ ? The >> stable/10/ images boot fine, so I do not suspect any code changes in the >> build process. >> > > Correction: RPI-B fails to boot. BEAGLEBONE boots after pressing 'q' > when this message is displayed. > > Glen > Yeah, i had noted this difference already (and forgot to ask about it...). It works on BEAGLEBONE because the BEAGLEBONE kernel still has the FDT_DTB_STATIC option. I have booted mine without the static dtb blob included in kernel without any issue (using crochet images - other images which doesn't use ubldr may be broken by this change). If you guys think it is appropriate i can ask to commit the attached patch. Luiz --001a11c266c4e17bd304f29ecf2f Content-Type: text/plain; charset=US-ASCII; name="beaglebone-static-dtb.diff" Content-Disposition: attachment; filename="beaglebone-static-dtb.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hrs3hpww1 SW5kZXg6IHN5cy9hcm0vY29uZi9CRUFHTEVCT05FCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9hcm0vY29u Zi9CRUFHTEVCT05FCShyZXZpc2lvbiAyNjIwMzcpCisrKyBzeXMvYXJtL2NvbmYvQkVBR0xFQk9O RQkod29ya2luZyBjb3B5KQpAQCAtMTMyLDUgKzEzMiw3IEBACiAKICMgRmxhdHRlbmVkIERldmlj ZSBUcmVlCiBvcHRpb25zICAgICAgICAgRkRUCi1vcHRpb25zICAgICAgICAgRkRUX0RUQl9TVEFU SUMKKyMgTm90ZTogIERUQiBpcyBub3JtYWxseSBsb2FkZWQgYnkgYmVhZ2xlYm9uZSBVLUJvb3Qg YW5kIHRoZW4gaGFuZGVkCisjIHRvIGtlcm5lbCB2aWEgdWJsZHIuCisjb3B0aW9ucyAgICAgICAg IEZEVF9EVEJfU1RBVElDCiBtYWtlb3B0aW9ucyAgICAgRkRUX0RUU19GSUxFPWJlYWdsZWJvbmUu ZHRzCg== --001a11c266c4e17bd304f29ecf2f-- From owner-freebsd-arm@FreeBSD.ORG Mon Feb 17 19:11:54 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 050DB234; Mon, 17 Feb 2014 19:11:54 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C9C3116BB; Mon, 17 Feb 2014 19:11: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 1WFTbX-000MkI-Az; Mon, 17 Feb 2014 19:11:47 +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 s1HJBiID027813; Mon, 17 Feb 2014 12:11:44 -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/C2xiVIugc5HDNWW+g7Je8 Subject: Re: "No valid device tree blob found" error From: Ian Lepore To: Luiz Otavio O Souza In-Reply-To: References: <20140216213001.GF1667@glenbarber.us> <20140216213152.GG1667@glenbarber.us> Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Feb 2014 12:11:44 -0700 Message-ID: <1392664304.1145.21.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Glen Barber , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 19:11:54 -0000 On Mon, 2014-02-17 at 16:03 -0300, Luiz Otavio O Souza wrote: > On 16 February 2014 18:31, Glen Barber wrote: > > On Sun, Feb 16, 2014 at 04:30:01PM -0500, Glen Barber wrote: > >> Images for RPI-B and BEAGLEBONE (and I suspect PANDABOARD) are failing > >> to boot this week. > >> > >> The images are built against r261948. Console messages during boot: > >> > >> ## Starting application at 0x88000054 ... > >> Consoles: U-Boot console > >> Compatible API signature found @9f242240 > >> MMC Device 2 not found > >> MMC Device 3 not found > >> Number of U-Boot devices: 2 > >> > >> FreeBSD/armv6 U-Boot loader, Revision 1.2 > >> (root@grind.freebsd.org, Sun Feb 16 18:10:43 UTC 2014) > >> DRAM: 512MB > >> > >> Device: disk > >> Loading /boot/defaults/loader.conf > >> /boot/kernel/kernel data=0x460bc8+0x2c7438 > >> syms=[0x4+0x85a60+0x4+0x50c89] > >> > >> Hit [Enter] to boot immediately, or any other key for command prompt. > >> Booting [/boot/kernel/kernel]... > >> Using DTB provided by U-Boot. > >> No valid device tree blob found!WARNING! Trying to fire up the kernel, > >> but no device tree blob found! > >> > >> Any ideas if this is error on my part, or a problem in head/ ? The > >> stable/10/ images boot fine, so I do not suspect any code changes in the > >> build process. > >> > > > > Correction: RPI-B fails to boot. BEAGLEBONE boots after pressing 'q' > > when this message is displayed. > > > > Glen > > > > > Yeah, i had noted this difference already (and forgot to ask about it...). > > It works on BEAGLEBONE because the BEAGLEBONE kernel still has the > FDT_DTB_STATIC option. > > I have booted mine without the static dtb blob included in kernel > without any issue (using crochet images - other images which doesn't > use ubldr may be broken by this change). > > If you guys think it is appropriate i can ask to commit the attached patch. > > Luiz I think it's a good idea to leave the static dtb compiled in on platforms where it'll work. The code in initarm() tries to use the dtb passed in by ubldr or by u-boot using the linux boot abi, and only falls back to the static one if those aren't available. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Feb 17 22:38:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 274F1153 for ; Mon, 17 Feb 2014 22:38:08 +0000 (UTC) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 00349194D for ; Mon, 17 Feb 2014 22:38:07 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id un15so15912279pbc.32 for ; Mon, 17 Feb 2014 14:38:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc:content-type; bh=Iy8U8/CPt/9w1x3VtyXKkimCDBKVbzZp2C7CEHklk+E=; b=RBa9cQkB5NBc8U2DzHWj7a3uxSvoR2ARD8A8XtOAlX+pS+du9wXVmwzCZ/6IlWaKBT lue53GDmp2osY0IZrAg5jFS4tEn+1Dw3I/PzUT55tKcWWGqF9QqF3JlOl4E2Kw1IVYIV dcs1pb6eEXch9bYYEiRMHewVk/hgpmLQFCbfWYZvhJyinUdZ66j7ehMVekAhNyQWbfgt 55VmohLBx9HMcWD8ZLXficem4wezClt1zTQ3yAGH4q7BAGyx5JJVTm9rp55BYvrS4K3m /AvRfP3jpN2CEvKorSnGyphcRP5oGzTALcO2LleaVSnymEkBGWJ2B8bjOnf5E0SDTVQn 0VRA== X-Gm-Message-State: ALoCoQk1PIs/lLhSoExZkMaN+Si3KeQIpoLIVchaXatfQfy8vdjEQi0s1lKipudXzQRRC0aWUuC5 X-Received: by 10.68.133.193 with SMTP id pe1mr29197754pbb.56.1392676686975; Mon, 17 Feb 2014 14:38:06 -0800 (PST) MIME-Version: 1.0 Sender: glikely@secretlab.ca Received: by 10.70.88.202 with HTTP; Mon, 17 Feb 2014 14:37:46 -0800 (PST) From: Grant Likely Date: Mon, 17 Feb 2014 22:37:46 +0000 X-Google-Sender-Auth: Ws27j0yIBRb644ApD5xWgfKOwAo Message-ID: Subject: New devicetree lists To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Ian Campbell X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 22:38:08 -0000 Hi all, I don't normally follow this list, but I wanted to let you know about new lists for devicetree development that may interest you. The devicetree@vger.kernel.org mailinglist that carries most of the devicetree discussion is also overloaded with Linux specific discussion which makes it not so useful for freebsd and other users. So, two new lists have been created; devicetree-spec@vger.kernel.org for discussing core bindings, and devicetree-compiler@vger.kernel.org for discussing the toolchain. I'm hoping those lists will be useful for more cross-platform discussion about device tree. There is also a #devicetree channel on Freenode irc. g. http://vger.kernel.org/vger-lists.html#devicetree-compiler http://vger.kernel.org/vger-lists.html#devicetree-spec From owner-freebsd-arm@FreeBSD.ORG Tue Feb 18 16:31:10 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9257FF79 for ; Tue, 18 Feb 2014 16:31:10 +0000 (UTC) Received: from forward5h.mail.yandex.net (forward5h.mail.yandex.net [IPv6:2a02:6b8:0:f05::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 456FF1863 for ; Tue, 18 Feb 2014 16:31:10 +0000 (UTC) Received: from web22h.yandex.ru (web22h.yandex.ru [84.201.187.156]) by forward5h.mail.yandex.net (Yandex) with ESMTP id 2F41AD01F1E for ; Tue, 18 Feb 2014 20:30:54 +0400 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web22h.yandex.ru (Yandex) with ESMTP id C6B95A807C7; Tue, 18 Feb 2014 20:30:53 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1392741053; bh=hgMWboZY5R20tzpeD4DXwE+iaLGWOIhqKgsYDt3mtsU=; h=From:To:Subject:Date; b=PzuRFhBqLCoJuy40TGNiFxDu+d1WXwVyyafGhrAl+ty/gR7dMOltEjk8SihffwvjC Dc0saP6+bGMk8kRoKOXM266nUXVxt1mLjOrZInMubelOPgX1PsYIHdLP7Qx80zAIVU yctsllD1DBgWeQ3zQWTjkje1cqYyp0qJx8PXX3EQ= Received: from net245.234.188-30.ertelecom.ru (net245.234.188-30.ertelecom.ru [188.234.245.30]) by web22h.yandex.ru with HTTP; Tue, 18 Feb 2014 20:30:53 +0400 From: =?koi8-r?B?59XM0cXXIOfP28E=?= To: freebsd-arm@freebsd.org Subject: About FreeBSD support one more mini-pc MIME-Version: 1.0 Message-Id: <210081392741053@web22h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Tue, 18 Feb 2014 22:30:53 +0600 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailman-Approved-At: Tue, 18 Feb 2014 17:11:45 +0000 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 16:31:10 -0000 Good day! I see very interesting devices availaible here: http://imx.solid-run.com/ That devices based on Freescale i.MX6 chipsets. And my question is: 1. Is FreeBSD has has support that platform? 2. If not, is it interesting for any developers, that I'm buy that device for you and you will play with it and bring FreeBSD support on it? :) From owner-freebsd-arm@FreeBSD.ORG Tue Feb 18 18:52:07 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88BA7D70; Tue, 18 Feb 2014 18:52:07 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C98C516FB; Tue, 18 Feb 2014 18:52:06 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id k14so3635029wgh.35 for ; Tue, 18 Feb 2014 10:52:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B1JzHK+Y+I2dFVQYBbIoLnWPkZPcbCo8ePF8h5i63lA=; b=shQuq142Mp4dUhjceb+4vgKwVaGhL8TZlYxS7xOyFNnwH9ABdeAnR8oE1Wz2M2EQlR rd3hk1Cqeix7iWeoa9NzgkrA8YuzDnzxXa2p1tVUbTWep3mBXPT7PXaV6UllekHt8//d jyZKn4ySwH78YGCp/ycAL3HTc6ZOBgrkU4AxMPz7MjYUHq3wXpiRjEeKad7756hBk7H6 xBFDN20ybPQI0czPU3gABLVp8vjxFNEQX8FB328AINTOkocgzRCDyWzVJsGD35JTbkrh ktv2dmEk+uVgZnetR0oNYBo+4Efg3dDel6rQ7EAotR/DsUIBQOOPla/SgZv5k5wJJBx+ kvMQ== MIME-Version: 1.0 X-Received: by 10.180.19.138 with SMTP id f10mr11294428wie.11.1392749525017; Tue, 18 Feb 2014 10:52:05 -0800 (PST) Received: by 10.216.240.66 with HTTP; Tue, 18 Feb 2014 10:52:04 -0800 (PST) In-Reply-To: <1392659595.1145.15.camel@revolution.hippie.lan> References: <20140216213001.GF1667@glenbarber.us> <1392659595.1145.15.camel@revolution.hippie.lan> Date: Tue, 18 Feb 2014 15:52:04 -0300 Message-ID: Subject: Re: "No valid device tree blob found" error From: Luiz Otavio O Souza To: Ian Lepore Content-Type: multipart/mixed; boundary=bcaec53d550db40fd404f2b2c4d2 Cc: Glen Barber , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 18:52:07 -0000 --bcaec53d550db40fd404f2b2c4d2 Content-Type: text/plain; charset=ISO-8859-1 On 17 February 2014 14:53, Ian Lepore wrote: > On Mon, 2014-02-17 at 10:08 -0300, Luiz Otavio O Souza wrote: >> On 16 February 2014 18:30, Glen Barber wrote: >> > Images for RPI-B and BEAGLEBONE (and I suspect PANDABOARD) are failing >> > to boot this week. >> > >> > The images are built against r261948. Console messages during boot: >> > >> > ## Starting application at 0x88000054 ... >> > Consoles: U-Boot console >> > Compatible API signature found @9f242240 >> > MMC Device 2 not found >> > MMC Device 3 not found >> > Number of U-Boot devices: 2 >> > >> > FreeBSD/armv6 U-Boot loader, Revision 1.2 >> > (root@grind.freebsd.org, Sun Feb 16 18:10:43 UTC 2014) >> > DRAM: 512MB >> > >> > Device: disk >> > Loading /boot/defaults/loader.conf >> > /boot/kernel/kernel data=0x460bc8+0x2c7438 >> > syms=[0x4+0x85a60+0x4+0x50c89] >> > >> > Hit [Enter] to boot immediately, or any other key for command prompt. >> > Booting [/boot/kernel/kernel]... >> > Using DTB provided by U-Boot. >> > No valid device tree blob found!WARNING! Trying to fire up the kernel, >> > but no device tree blob found! >> > >> > Any ideas if this is error on my part, or a problem in head/ ? The >> > stable/10/ images boot fine, so I do not suspect any code changes in the >> > build process. >> > >> >> >> Glen, >> >> I think it is related to r261819. Looking at the code it looks like >> the attached patch may fix it (i'm still updating my images to the >> latest -head and would probably need a few hours before i can test it >> myself). >> >> Can you check if it works for you ? >> >> Thanks, >> >> Luiz > > I believe your patch is correct; when I copied the code to do the header > check it came from a context where the header variable was the struct > itself, not a pointer to it. Odd that the error message doesn't seem to > match, though. > > -- Ian The patch does indeed fix the issue. The error message has two different usage cases, when called from the fdt_copy() the output of command_errbuf/command_errmsg isn't displayed. An error from fdt_copy() is printed instead. When called from fdt_fixup() the error message was being overwritten. The attached patch fix all these issues. Now, when called from fdt_copy() i've added a missing '\n' at end of the error message: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by U-Boot. No valid device tree blob found! WARNING! Trying to fire up the kernel, but no device tree blob found! And from fdt_fixup() now it doesn't overwrite the error from fdt_load_dtb[_addr]() anymore: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... Type '?' for a list of commands, 'help' for more detailed help. loader> fdt ls Using DTB provided by U-Boot. error validating blob: FDT_ERR_BADMAGIC loader> Does the attached patch looks fine ? Luiz --bcaec53d550db40fd404f2b2c4d2 Content-Type: text/plain; charset=US-ASCII; name="fdt-loader.diff" Content-Disposition: attachment; filename="fdt-loader.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hrtiss0b0 SW5kZXg6IHN5cy9ib290L2ZkdC9mZHRfbG9hZGVyX2NtZC5jCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9i b290L2ZkdC9mZHRfbG9hZGVyX2NtZC5jCShyZXZpc2lvbiAyNjIxODMpCisrKyBzeXMvYm9vdC9m ZHQvZmR0X2xvYWRlcl9jbWQuYwkod29ya2luZyBjb3B5KQpAQCAtMjMwLDcgKzIzMCw3IEBACiAJ aW50IGVycjsKIAogCWZkdHBfc2l6ZSA9IGZkdF90b3RhbHNpemUoaGVhZGVyKTsKLQllcnIgPSBm ZHRfY2hlY2tfaGVhZGVyKCZoZWFkZXIpOworCWVyciA9IGZkdF9jaGVja19oZWFkZXIoaGVhZGVy KTsKIAlpZiAoZXJyIDwgMCkgewogCQlzcHJpbnRmKGNvbW1hbmRfZXJyYnVmLCAiZXJyb3IgdmFs aWRhdGluZyBibG9iOiAlcyIsCiAJCSAgICBmZHRfc3RyZXJyb3IoZXJyKSk7CkBAIC02NjcsNyAr NjY3LDcgQEAKIHsKIAljb25zdCBjaGFyICplbnY7CiAJY2hhciAqZXRoc3RyOwotCWludCBjaG9z ZW4sIGVyciwgZXRoX25vLCBsZW47CisJaW50IGNob3NlbiwgZXRoX25vLCBsZW47CiAJc3RydWN0 IHN5c19pbmZvICpzaTsKIAogCWVudiA9IE5VTEw7CkBAIC02NzUsMTMgKzY3NSw4IEBACiAJZXRo c3RyID0gTlVMTDsKIAlsZW4gPSAwOwogCi0JaWYgKGZkdHAgPT0gTlVMTCkgewotCQllcnIgPSBm ZHRfc2V0dXBfZmR0cCgpOwotCQlpZiAoZXJyKSB7Ci0JCQlzcHJpbnRmKGNvbW1hbmRfZXJyYnVm LCAiTm8gdmFsaWQgZGV2aWNlIHRyZWUgYmxvYiBmb3VuZCEiKTsKLQkJCXJldHVybiAoMCk7Ci0J CX0KLQl9CisJaWYgKGZkdHAgPT0gTlVMTCAmJiBmZHRfc2V0dXBfZmR0cCgpICE9IDApCisJCXJl dHVybiAoMCk7CiAKIAkvKiBDcmVhdGUgL2Nob3NlbiBub2RlIChpZiBub3QgZXhpc3RzKSAqLwog CWlmICgoY2hvc2VuID0gZmR0X3N1Ym5vZGVfb2Zmc2V0KGZkdHAsIDAsICJjaG9zZW4iKSkgPT0K QEAgLTc0Nyw3ICs3NDIsNyBAQAogCWlmIChmZHRwID09IE5VTEwpIHsKIAkJZXJyID0gZmR0X3Nl dHVwX2ZkdHAoKTsKIAkJaWYgKGVycikgewotCQkJcHJpbnRmKCJObyB2YWxpZCBkZXZpY2UgdHJl ZSBibG9iIGZvdW5kISIpOworCQkJcHJpbnRmKCJObyB2YWxpZCBkZXZpY2UgdHJlZSBibG9iIGZv dW5kIVxuIik7CiAJCQlyZXR1cm4gKDApOwogCQl9CiAJfQo= --bcaec53d550db40fd404f2b2c4d2-- From owner-freebsd-arm@FreeBSD.ORG Wed Feb 19 10:59:38 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C8D9590 for ; Wed, 19 Feb 2014 10:59:38 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id E90B617A8 for ; Wed, 19 Feb 2014 10:59:37 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 61327B828; Wed, 19 Feb 2014 12:59:34 +0200 (SAST) Date: Wed, 19 Feb 2014 12:59:34 +0200 From: John Hay To: freebsd-arm@freebsd.org Subject: status of AVILA and CAMBRIA code Message-ID: <20140219105934.GA74731@zibbi.meraka.csir.co.za> 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.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 10:59:38 -0000 Hi Guys, What is the status of AVILA and CAMBRIA builds in our tree? Have anybody had success recently? From the lists I can see that other people have also asked in September 2013, but I cannot figure out if there was any successes at that stage. :-) Currently we have some AVILA based systems running using FreeBSD-9 from January 2012. They are doing ok, but with the AVILAs be EOLed, we were thinking of using CAMBRIAs in the interrim and then start looking for some embedded board that can boot standalone, have an ethernet port and 3 X wifi (MiniPCI or something) and is supported by FreeBSD. :-) But that for another email. So I thought the easiest will be to just build a CAMBRIA kernel from the same Jan 2012 tree and then share the user level binaries between the two. It look ok at first but then at random times, I would see "athX: ath_rx_proc: no mbuf!" messages and sometimes the wifi would stop receiving with a "athX: ath_rx_proc: couldn't restart RX after RXEOL; resetting" "ath_rx_proc: unable to start recv logic". I looked with netstat -m, but did not see an obvious problem, so decided it is time for an upgrade. So I tried the latest current and latest 10-stable, but both AVILA and CAMBRIA kernels does not even print anything on the serial ports. I then tried various older builds finding various problems: Somewhere shortly after 2013-08-16 the kernel will panic with "Fatal kernel mode data abort: 'Alignment Fault 3'. I did not check if it was fixed later in the tree before the kernels stopped outputting to the serial port. On 2013-04-15 the kernel will stop after writing the gcc version 4.2.1 message. On 2013-03-20 creation of mdX ram disks for /etc and /var broke with a "mdmfs: newfs err 38" message. You can get past that by setting the vfs.unmapped_buf_allowed=0 tunable. On 2012-01-25 svn 230553 remounting partitions rw->ro started to take so long that the longest AVILA watchdog setting will still reset the machine before the remounting is finished. Undoing that commit gets one past that. We normally keep the CF mounted ro and when we need to make changes mount it rw, make the change and then mount it ro again. Somewhere along the line the ethernet npe0 device also broke, writing "npe0: npestart_locked: too many fragments 0". But I did not test the npe0 device with every build and only realised it this morning, so I do not know where it broke. :-) -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-arm@FreeBSD.ORG Wed Feb 19 12:58:58 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4D85B52; Wed, 19 Feb 2014 12:58:58 +0000 (UTC) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7351013CB; Wed, 19 Feb 2014 12:58:58 +0000 (UTC) Received: by mail-yh0-f52.google.com with SMTP id a41so321118yho.25 for ; Wed, 19 Feb 2014 04:58:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=Rq9JbySepSJlen7BZtrHxXBcKN0VleZkGWMl9TpW9lY=; b=dhsly0SthJIg4yJTxI0hZxBBKFsBk5INNiQ+vt8kvnYW44XAhBuTfFHhKcCxnyzgny o2ykay8zTsOORe2VpxZ1Nb2aDGqo5c0UMJbWg0ex/Ipzust0X9uZcxkjnr6+13LgcImz 2n344jvDlWjmH3AZBP2LstEHiZiP4PuTLfcI3BoJBjkmAa9vPHT5CiiUDm35oKN2698H /Y2DIr0x35VcCcN8TD6aVHcyGSRNqTF6mxeIZDEEJeZwiS2SrpwwH7rLOiIq4i9nNfDY z4Yh4liyKfnNRCiCfJb9haDSxpBxD3aZ1+ujiSi2HiVTD1WutW66Ycls7Qj0LtoYhtdS TYfw== X-Received: by 10.236.44.173 with SMTP id n33mr31437556yhb.98.1392814737747; Wed, 19 Feb 2014 04:58:57 -0800 (PST) Received: from [10.10.1.113] ([201.72.203.70]) by mx.google.com with ESMTPSA id c23sm374898yhk.23.2014.02.19.04.58.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 04:58:56 -0800 (PST) From: Luiz Otavio O Souza Content-Type: multipart/mixed; boundary="Apple-Mail=_93E3800A-CBBC-43A6-A941-EEADF69175A6" Subject: Enable I2C1 and I2C2 on BBB by default Message-Id: Date: Wed, 19 Feb 2014 09:58:47 -0300 To: freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 12:58:58 -0000 --Apple-Mail=_93E3800A-CBBC-43A6-A941-EEADF69175A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Is there any problem if i enable the second and the third I2C = controllers by default on BBB ? ATM only the first controller is enabled and it is only used to connect = the on-board devices (PMIC and HDMI framer), this iicbus isn=92t exposed = on the expansion headers. The two additional controllers are exposed on P9 expansion header, the = I2C1 is at pins 17 and 18 and the I2C2 is at pins 19 and 20. The I2C2 is the default iicbus used to read the cape eeprom contents = (when you have a cape installed). Both controllers had been tested and seems to work fine on my BBB. Regards, Luiz --Apple-Mail=_93E3800A-CBBC-43A6-A941-EEADF69175A6 Content-Disposition: attachment; filename=bbb-i2c.diff Content-Type: application/octet-stream; name="bbb-i2c.diff" Content-Transfer-Encoding: 7bit Index: src/sys/boot/fdt/dts/am335x.dtsi =================================================================== --- src/sys/boot/fdt/dts/am335x.dtsi (revision 262131) +++ src/sys/boot/fdt/dts/am335x.dtsi (working copy) @@ -210,6 +210,26 @@ i2c-device-id = <0>; }; + i2c1: i2c@4802a000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "ti,i2c"; + reg =< 0x4802a000 0x1000 >; + interrupts = <71>; + interrupt-parent = <&AINTC>; + i2c-device-id = <1>; + }; + + i2c2: i2c@4819c000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "ti,i2c"; + reg =< 0x4819c000 0x1000 >; + interrupts = <30>; + interrupt-parent = <&AINTC>; + i2c-device-id = <2>; + }; + pwm@48300000 { compatible = "ti,am335x-pwm"; #address-cells = <1>; Index: src/sys/boot/fdt/dts/beaglebone-black.dts =================================================================== --- src/sys/boot/fdt/dts/beaglebone-black.dts (revision 262131) +++ src/sys/boot/fdt/dts/beaglebone-black.dts (working copy) @@ -52,6 +52,12 @@ /* I2C0 */ "I2C0_SDA", "I2C0_SDA","i2c", "I2C0_SCL", "I2C0_SCL","i2c", + /* I2C1 */ + "SPI0_D1", "I2C1_SDA", "i2c", + "SPI0_CS0", "I2C1_SCL", "i2c", + /* I2C2 */ + "UART1_CTSn", "I2C2_SDA", "i2c", + "UART1_RTSn", "I2C2_SCL", "i2c", /* Ethernet */ "MII1_RX_ER", "gmii1_rxerr", "input_pulldown", "MII1_TX_EN", "gmii1_txen", "output", --Apple-Mail=_93E3800A-CBBC-43A6-A941-EEADF69175A6-- From owner-freebsd-arm@FreeBSD.ORG Wed Feb 19 17:43:29 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8EF0C4FE for ; Wed, 19 Feb 2014 17:43:29 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6B9EF1116 for ; Wed, 19 Feb 2014 17:43:29 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s1JHTcWO005477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Feb 2014 09:29:39 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s1JHTcHe005476; Wed, 19 Feb 2014 09:29:38 -0800 (PST) (envelope-from jmg) Date: Wed, 19 Feb 2014 09:29:38 -0800 From: John-Mark Gurney To: John Hay Subject: Re: status of AVILA and CAMBRIA code Message-ID: <20140219172938.GH34851@funkthat.com> Mail-Followup-To: John Hay , freebsd-arm@freebsd.org References: <20140219105934.GA74731@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140219105934.GA74731@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 19 Feb 2014 09:29:39 -0800 (PST) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 17:43:29 -0000 John Hay wrote this message on Wed, Feb 19, 2014 at 12:59 +0200: > What is the status of AVILA and CAMBRIA builds in our tree? Have anybody > had success recently? From the lists I can see that other people have > also asked in September 2013, but I cannot figure out if there was any > successes at that stage. :-) The AVILA boards are known to have issues... I still need to get the off_t fixes into the tree (need to reread bde's last email on it and act), and I've been seeing a panic, see message below w/ off_t fix for it... There is also a fix in the tree (not sure if it got merged) to address the stack unwinding issue too... > Currently we have some AVILA based systems running using FreeBSD-9 from > January 2012. They are doing ok, but with the AVILAs be EOLed, we were > thinking of using CAMBRIAs in the interrim and then start looking for > some embedded board that can boot standalone, have an ethernet port > and 3 X wifi (MiniPCI or something) and is supported by FreeBSD. :-) > But that for another email. > > So I thought the easiest will be to just build a CAMBRIA kernel from > the same Jan 2012 tree and then share the user level binaries between > the two. It look ok at first but then at random times, I would see > "athX: ath_rx_proc: no mbuf!" messages and sometimes the wifi would > stop receiving with a "athX: ath_rx_proc: couldn't restart RX after > RXEOL; resetting" "ath_rx_proc: unable to start recv logic". I looked > with netstat -m, but did not see an obvious problem, so decided it is > time for an upgrade. > > So I tried the latest current and latest 10-stable, but both AVILA and > CAMBRIA kernels does not even print anything on the serial ports. This is likely a gcc bug that didn't get merged to 10-stable: http://svnweb.freebsd.org/changeset/base/r260565 > I then tried various older builds finding various problems: > > Somewhere shortly after 2013-08-16 the kernel will panic with "Fatal > kernel mode data abort: 'Alignment Fault 3'. I did not check if it > was fixed later in the tree before the kernels stopped outputting to > the serial port. This should be addressed by when I commit my off_t fixes... A quick fix is in: https://www.freebsd.org/cgi/mid.cgi?20140113055215.GB2982@funkthat.com but that is not what will be committed... > On 2013-04-15 the kernel will stop after writing the gcc version 4.2.1 > message. This is probably due to the gcc switch over to EABI... > On 2013-03-20 creation of mdX ram disks for /etc and /var broke with > a "mdmfs: newfs err 38" message. You can get past that by setting > the vfs.unmapped_buf_allowed=0 tunable. > > On 2012-01-25 svn 230553 remounting partitions rw->ro started to take > so long that the longest AVILA watchdog setting will still reset the > machine before the remounting is finished. Undoing that commit gets > one past that. We normally keep the CF mounted ro and when we need to > make changes mount it rw, make the change and then mount it ro again. > > Somewhere along the line the ethernet npe0 device also broke, writing > "npe0: npestart_locked: too many fragments 0". But I did not test the > npe0 device with every build and only realised it this morning, so I > do not know where it broke. :-) Not sure about these issues... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Wed Feb 19 18:18:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5E74D82 for ; Wed, 19 Feb 2014 18:18:11 +0000 (UTC) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 972E013BF for ; Wed, 19 Feb 2014 18:18:11 +0000 (UTC) Received: by mail-oa0-f53.google.com with SMTP id m1so876812oag.12 for ; Wed, 19 Feb 2014 10:18:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=v4f7Zme+gJDuBMmkExmi5puB4pjwH754Gv/lxco9OjI=; b=SKk+3bCxIOOK1BUAgOKANWw4oEye4D2FTVF0CRhqiVswB/tJdeceD/EZrPVdNIlozH AVkunmmUjiz3AtcM3/g21cdlZWZq16r2IRnnCdwy3BaJaFHaA6plbcMNDlyFLuRqIovE 2+KU2K1zOOgWFiE3DWFKGgZmwjqlo7IOP6qweWdQTuZ/G9WaTjuNhHaDnnCwY6XYCg46 eojWGteyqWCv3FOtz3tI4osHr4PjVpyYhBK/Btu8fSaOdLvBTMlfZs66ou4TSRB8hxGF S41KtJUzn9EojdDP29iWVzeye6bD/kGQgMBtg+Yjuh4viPpD8NyYbUuwymCaMHEn0qaO S9JA== X-Gm-Message-State: ALoCoQkXYpZ6jqgIByy7N/BPfhHiot/hRsfYqPnRzXWEbzrNROOaY+shmff0SmcHCamKf2aKZ5zO X-Received: by 10.60.62.199 with SMTP id a7mr2580248oes.64.1392833884867; Wed, 19 Feb 2014 10:18:04 -0800 (PST) Received: from macmini.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id h4sm6203759oev.2.2014.02.19.10.18.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 10:18:04 -0800 (PST) Subject: Re: Enable I2C1 and I2C2 on BBB by default Mime-Version: 1.0 (Apple Message framework v1085) From: Warner Losh In-Reply-To: Date: Wed, 19 Feb 2014 11:17:59 -0700 Message-Id: <5BD1D8ED-1072-4329-A22A-68C6A4F01BEE@bsdimp.com> References: To: Luiz Otavio O Souza X-Mailer: Apple Mail (2.1085) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 18:18:11 -0000 On Feb 19, 2014, at 5:58 AM, Luiz Otavio O Souza wrote: > These changes look good to my eye.. Warner From owner-freebsd-arm@FreeBSD.ORG Wed Feb 19 18:41:14 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4C43E27 for ; Wed, 19 Feb 2014 18:41:14 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A6686166B for ; Wed, 19 Feb 2014 18:41:14 +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 1WGC4y-000ABW-8K; Wed, 19 Feb 2014 18:41:08 +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 s1JIf4JZ030175; Wed, 19 Feb 2014 11:41:04 -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: U2FsdGVkX18v3B6f1pbwVSlZlfVq/Lne Subject: Re: About FreeBSD support one more mini-pc From: Ian Lepore To: =?koi8-r?Q?=E7=D5=CC=D1=C5=D7_=E7=CF=DB=C1?= In-Reply-To: <210081392741053@web22h.yandex.ru> References: <210081392741053@web22h.yandex.ru> Content-Type: text/plain; charset="koi8-r" Date: Wed, 19 Feb 2014 11:41:04 -0700 Message-ID: <1392835264.1145.33.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s1JIf4JZ030175 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 18:41:14 -0000 On Tue, 2014-02-18 at 22:30 +0600, =E7=D5=CC=D1=C5=D7 =E7=CF=DB=C1 wrote: > Good day! >=20 > I see very interesting devices availaible here: http://imx.solid-run.co= m/ > That devices based on Freescale i.MX6 chipsets. >=20 > And my question is: > 1. Is FreeBSD has has support that platform? > 2. If not, is it interesting for any developers, that I'm buy that dev= ice for you and you will play with it and bring FreeBSD support on it? :) We have some support for imx6 now, and we're actively working to expand it. Devices that work include uart, sdcard, ethernet, and usb. We don't have wifi, audio, or video drivers yet. We don't have SMP yet, although some people have patches that have it working with perhaps some stability issues. I wouldn't expect too much trouble to get that box booting, but be sure to get a model that has a serial console port, since we don't have video drivers for a console yet. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Feb 19 18:48:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B27DFC7; Wed, 19 Feb 2014 18:48:23 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7B8F416B3; Wed, 19 Feb 2014 18:48:22 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hi5so5035833wib.9 for ; Wed, 19 Feb 2014 10:48:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lVeApSrAnZNdgXQr+76g+mjEQMGM926iP11UgrJui7A=; b=TJNT6TibHjaZJbxFZsOznLDjV9hE1Ed/kk3L4LHJqi8ql3pJcm3HmMy/eKoN7i1wCd 2W7IEjoANlDT9jvpNW7zHozhYFgvP/JkX4oZKmqtxy2WQohwvMHEsqOtIkpur1WvrSAo F3IR96RfAj5x4kSY2Lvlc4iTXdHGp6Xh+jx4rDbM4f+KBQynh7mG88xN6hzjHuaBvvuw pbuGKyj1k2OWEW4hHRyCZFs23LBDIdUH+o6y4wa7CeDKKCWF3Bl1w85NPZBq5h7vyz5t vbQnUvIzpfmb2XSB2KtzhmJ7T/yplD9Q/+htSDovWZu96qfk0FA2cm9pyoaz2/NprqjF zF7A== MIME-Version: 1.0 X-Received: by 10.180.19.138 with SMTP id f10mr3057014wie.11.1392835700775; Wed, 19 Feb 2014 10:48:20 -0800 (PST) Received: by 10.216.240.66 with HTTP; Wed, 19 Feb 2014 10:48:20 -0800 (PST) In-Reply-To: <1392664304.1145.21.camel@revolution.hippie.lan> References: <20140216213001.GF1667@glenbarber.us> <20140216213152.GG1667@glenbarber.us> <1392664304.1145.21.camel@revolution.hippie.lan> Date: Wed, 19 Feb 2014 15:48:20 -0300 Message-ID: Subject: Re: "No valid device tree blob found" error From: Luiz Otavio O Souza To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: Glen Barber , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 18:48:23 -0000 On 17 February 2014 16:11, Ian Lepore wrote: > On Mon, 2014-02-17 at 16:03 -0300, Luiz Otavio O Souza wrote: >> On 16 February 2014 18:31, Glen Barber wrote: >> > On Sun, Feb 16, 2014 at 04:30:01PM -0500, Glen Barber wrote: >> >> Images for RPI-B and BEAGLEBONE (and I suspect PANDABOARD) are failing >> >> to boot this week. >> >> >> >> The images are built against r261948. Console messages during boot: >> >> >> >> ## Starting application at 0x88000054 ... >> >> Consoles: U-Boot console >> >> Compatible API signature found @9f242240 >> >> MMC Device 2 not found >> >> MMC Device 3 not found >> >> Number of U-Boot devices: 2 >> >> >> >> FreeBSD/armv6 U-Boot loader, Revision 1.2 >> >> (root@grind.freebsd.org, Sun Feb 16 18:10:43 UTC 2014) >> >> DRAM: 512MB >> >> >> >> Device: disk >> >> Loading /boot/defaults/loader.conf >> >> /boot/kernel/kernel data=0x460bc8+0x2c7438 >> >> syms=[0x4+0x85a60+0x4+0x50c89] >> >> >> >> Hit [Enter] to boot immediately, or any other key for command prompt. >> >> Booting [/boot/kernel/kernel]... >> >> Using DTB provided by U-Boot. >> >> No valid device tree blob found!WARNING! Trying to fire up the kernel, >> >> but no device tree blob found! >> >> >> >> Any ideas if this is error on my part, or a problem in head/ ? The >> >> stable/10/ images boot fine, so I do not suspect any code changes in the >> >> build process. >> >> >> > >> > Correction: RPI-B fails to boot. BEAGLEBONE boots after pressing 'q' >> > when this message is displayed. >> > >> > Glen >> > >> >> >> Yeah, i had noted this difference already (and forgot to ask about it...). >> >> It works on BEAGLEBONE because the BEAGLEBONE kernel still has the >> FDT_DTB_STATIC option. >> >> I have booted mine without the static dtb blob included in kernel >> without any issue (using crochet images - other images which doesn't >> use ubldr may be broken by this change). >> >> If you guys think it is appropriate i can ask to commit the attached patch. >> >> Luiz > > I think it's a good idea to leave the static dtb compiled in on > platforms where it'll work. The code in initarm() tries to use the dtb > passed in by ubldr or by u-boot using the linux boot abi, and only falls > back to the static one if those aren't available. > > -- Ian Yeah. I agree. Luiz From owner-freebsd-arm@FreeBSD.ORG Wed Feb 19 20:32:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D679875F for ; Wed, 19 Feb 2014 20:32:48 +0000 (UTC) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 991D31192 for ; Wed, 19 Feb 2014 20:32:48 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id o6so666678oag.14 for ; Wed, 19 Feb 2014 12:32:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=f5StUgnhZVVMmru8wSdimNBd2shYl0buJGu9Ff94zGo=; b=jRLnViaFOYKZtvCuSdKZGVxtJRT5+BkPVsWqJ/g1hiuzzs2FEx5noDcLwZADvAccYV x2yNILnz/hKCwphb4oPT6sk92falFTPmetE/FLyFJTT6beHyw6UEvf+AfyBGuFDxwC0V QSBw6gSF14loxRRwnR/tHIg9+ovAIte1oPoajDtN22YRHvnoGiQj14/Pl2fKUXiF3sHv AQWFp4lDbkSYAa2wGDSocC6esTvPY7HuVY57csuE0OXOoTGZcCNm/eSmeDIVaN99BnCA ICPjLfwtp7oA7HFUfzP32ujM+/UiJj+KpoMDkXLlY/yswCVpmcW+39ICx3zpQ6+2xLjv sgfw== X-Gm-Message-State: ALoCoQnroOeDVmyD5Wl1CrvtQYW/G/n4sm22+7jXwq1tmxIT2qk+iY3tZtYds8J40p2Zr2SBY2a1 MIME-Version: 1.0 X-Received: by 10.182.194.100 with SMTP id hv4mr2665118obc.80.1392841960995; Wed, 19 Feb 2014 12:32:40 -0800 (PST) Received: by 10.182.104.169 with HTTP; Wed, 19 Feb 2014 12:32:40 -0800 (PST) In-Reply-To: <1392835264.1145.33.camel@revolution.hippie.lan> References: <210081392741053@web22h.yandex.ru> <1392835264.1145.33.camel@revolution.hippie.lan> Date: Wed, 19 Feb 2014 13:32:40 -0700 Message-ID: Subject: Re: About FreeBSD support one more mini-pc From: Tom Everett To: Ian Lepore Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 20:32:48 -0000 I would happily build a crochet-FreeBSD build for this, if it had a chance of working. I don't see a kernel config or any .dts files for this board on the tree, however, so those would have to be built out? ps:I'm happy to buy my own hardware for it. On Wed, Feb 19, 2014 at 11:41 AM, Ian Lepore wrote: > On Tue, 2014-02-18 at 22:30 +0600, =E7=D5=CC=D1=C5=D7 =E7=CF=DB=C1 wrote: > > Good day! > > > > I see very interesting devices availaible here: > http://imx.solid-run.com/ > > That devices based on Freescale i.MX6 chipsets. > > > > And my question is: > > 1. Is FreeBSD has has support that platform? > > 2. If not, is it interesting for any developers, that I'm buy that > device for you and you will play with it and bring FreeBSD support on it?= :) > > We have some support for imx6 now, and we're actively working to expand > it. Devices that work include uart, sdcard, ethernet, and usb. We > don't have wifi, audio, or video drivers yet. We don't have SMP yet, > although some people have patches that have it working with perhaps some > stability issues. > > I wouldn't expect too much trouble to get that box booting, but be sure > to get a model that has a serial console port, since we don't have video > drivers for a console yet. > > -- Ian > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > --=20 A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Wed Feb 19 20:45:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20F21E1F for ; Wed, 19 Feb 2014 20:45:50 +0000 (UTC) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DA708127C for ; Wed, 19 Feb 2014 20:45:49 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id rl12so603438iec.26 for ; Wed, 19 Feb 2014 12:45:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=cosgZ9NNVTlpdMO9uffq5cqcWw8B2sjeLmQ/QYGkWw4=; b=OXI9WhAAMACZTkGdHYlMpS514G4JyRnFXSnE98TYh9AdNOlRA33BNabFX3MeBzqyZa MfwCr6Vu2ea2HkS9VTCbez0zzlt3L8Wx8Qrojn3jiGb4c26LQVsbkRkJbjK6+BV/syNc UDHx8N0oDSpPXyLP3v5X6CyYe8WoVEDKdUBVNEbZf+cZ8hwpMa6ISvyUS69lafNafBvb 3ssVwNmUzQOaorRndFpzb6wmNYH1CZmewcnqJEfhYKxvYWnyZ2H8HYx6KPPgvIgi/Qe8 Oaop/xzklEQs0envFGqhh772vGRJ//tZFdPsD1j8rtp5VEGEbM+Oaiwi3Tle98QDDb3N 0rbA== X-Gm-Message-State: ALoCoQlJZWTb4Na1PmmZPpTx4YGhnQyex1Rzl6t7PrLJ5RkDpweNsSBFpU0yu1D0QLNIxYX8ZVMV X-Received: by 10.50.80.11 with SMTP id n11mr3343325igx.36.1392842435901; Wed, 19 Feb 2014 12:40:35 -0800 (PST) Received: from macmini.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id f9sm4218681igz.3.2014.02.19.12.40.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 12:40:35 -0800 (PST) Subject: Re: About FreeBSD support one more mini-pc Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: Warner Losh In-Reply-To: Date: Wed, 19 Feb 2014 13:40:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <210081392741053@web22h.yandex.ru> <1392835264.1145.33.camel@revolution.hippie.lan> To: Tom Everett X-Mailer: Apple Mail (2.1085) Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 20:45:50 -0000 On Feb 19, 2014, at 1:32 PM, Tom Everett wrote: > I would happily build a crochet-FreeBSD build for this, if it had a = chance > of working. I don't see a kernel config or any .dts files for this = board > on the tree, however, so those would have to be built out? Doesn't the board maker give yon ones that work on Linux? DTS is designed to be OS agnostic, but doesn't always achieve that design goal. Starting from Linux files typically is a good place to begin, = although from conversations with Ian I know that the iMX stuff falls farther from = the goals than others, so some manual tweaking would be in order... Warner > ps:I'm happy to buy my own hardware for it. >=20 >=20 >=20 > On Wed, Feb 19, 2014 at 11:41 AM, Ian Lepore wrote: >=20 >> On Tue, 2014-02-18 at 22:30 +0600, =D0=93=D1=83=D0=BB=D1=8F=D0=B5=D0=B2= =D0=93=D0=BE=D1=88=D0=B0 wrote: >>> Good day! >>>=20 >>> I see very interesting devices availaible here: >> http://imx.solid-run.com/ >>> That devices based on Freescale i.MX6 chipsets. >>>=20 >>> And my question is: >>> 1. Is FreeBSD has has support that platform? >>> 2. If not, is it interesting for any developers, that I'm buy that >> device for you and you will play with it and bring FreeBSD support on = it? :) >>=20 >> We have some support for imx6 now, and we're actively working to = expand >> it. Devices that work include uart, sdcard, ethernet, and usb. We >> don't have wifi, audio, or video drivers yet. We don't have SMP yet, >> although some people have patches that have it working with perhaps = some >> stability issues. >>=20 >> I wouldn't expect too much trouble to get that box booting, but be = sure >> to get a model that has a serial console port, since we don't have = video >> drivers for a console yet. >>=20 >> -- Ian >>=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 >=20 >=20 >=20 > --=20 > A better world shall emerge based on faith and understanding - = Douglas > MacArthur > _______________________________________________ > 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 Feb 19 20:47:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 034DAE8B for ; Wed, 19 Feb 2014 20:47:03 +0000 (UTC) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BA0531289 for ; Wed, 19 Feb 2014 20:47:02 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id g12so680680oah.13 for ; Wed, 19 Feb 2014 12:46:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=w8BgZL20G8HVcJbEDI4hlMOtUGmDLenR95bnCIpa6G8=; b=Px76FHw8VX1QVGvVOJBU16/8CqEsIZ6chey8MUdAwrt+WEdKniuc/rx8PHnBeq31cx FwFBf7ysfB95FObkfEgMDPf2gjyTsoZfOfPlJvSRPDhmETVYQnYym9xEQFr4Dd+xT2Z6 gywJTYv35N/5ycBpCTK759Dnx563H8PUqCBWgRzhrLidKi5XW8IjfXhmixCpjMcd0VUJ TqyT72q5QNF2lBGAYprRKPJXbIgtNuoX5zIhIRJJSUiGlHhPPH3MD71w+UwkER4saR9e kVmjSN8tHL+cdFMWhl00Hm7smbtGC4prhtH4zDUEDcnVwq/stk2ntTH/uV96qwtNAYOd Ak2A== X-Gm-Message-State: ALoCoQnrgv22sO0UZ8hEMfMxIPGKzzHEk1jWamRtn19fggtEdEymqHyQ+/V9PQKgPZk5aIJvh9Gb MIME-Version: 1.0 X-Received: by 10.60.46.98 with SMTP id u2mr14863200oem.44.1392842816531; Wed, 19 Feb 2014 12:46:56 -0800 (PST) Received: by 10.182.104.169 with HTTP; Wed, 19 Feb 2014 12:46:56 -0800 (PST) In-Reply-To: References: <210081392741053@web22h.yandex.ru> <1392835264.1145.33.camel@revolution.hippie.lan> Date: Wed, 19 Feb 2014 13:46:56 -0700 Message-ID: Subject: Re: About FreeBSD support one more mini-pc From: Tom Everett To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 20:47:03 -0000 It looks like there is a u-boot configuration created: http://imx.solid-run.com/wiki/index.php?title=3DBuilding_the_kernel_and_u-b= oot_for_the_CuBox-i_and_the_HummingBoard I don't see a dts file immediately apparent on their wiki. On Wed, Feb 19, 2014 at 1:40 PM, Warner Losh wrote: > > On Feb 19, 2014, at 1:32 PM, Tom Everett wrote: > > > I would happily build a crochet-FreeBSD build for this, if it had a > chance > > of working. I don't see a kernel config or any .dts files for this > board > > on the tree, however, so those would have to be built out? > > Doesn't the board maker give yon ones that work on Linux? DTS is > designed to be OS agnostic, but doesn't always achieve that design > goal. Starting from Linux files typically is a good place to begin, > although > from conversations with Ian I know that the iMX stuff falls farther from > the > goals than others, so some manual tweaking would be in order... > > Warner > > > ps:I'm happy to buy my own hardware for it. > > > > > > > > On Wed, Feb 19, 2014 at 11:41 AM, Ian Lepore wrote: > > > >> On Tue, 2014-02-18 at 22:30 +0600, =D0=93=D1=83=D0=BB=D1=8F=D0=B5=D0= =B2 =D0=93=D0=BE=D1=88=D0=B0 wrote: > >>> Good day! > >>> > >>> I see very interesting devices availaible here: > >> http://imx.solid-run.com/ > >>> That devices based on Freescale i.MX6 chipsets. > >>> > >>> And my question is: > >>> 1. Is FreeBSD has has support that platform? > >>> 2. If not, is it interesting for any developers, that I'm buy that > >> device for you and you will play with it and bring FreeBSD support on > it? :) > >> > >> We have some support for imx6 now, and we're actively working to expan= d > >> it. Devices that work include uart, sdcard, ethernet, and usb. We > >> don't have wifi, audio, or video drivers yet. We don't have SMP yet, > >> although some people have patches that have it working with perhaps so= me > >> stability issues. > >> > >> I wouldn't expect too much trouble to get that box booting, but be sur= e > >> to get a model that has a serial console port, since we don't have vid= eo > >> drivers for a console yet. > >> > >> -- Ian > >> > >> > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > >> > > > > > > > > -- > > A better world shall emerge based on faith and understanding - Douglas > > MacArthur > > _______________________________________________ > > 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 A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Wed Feb 19 20:49:58 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C1F9F41 for ; Wed, 19 Feb 2014 20:49:58 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D0AED12A5 for ; Wed, 19 Feb 2014 20:49:57 +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 1WGE5X-000LwT-Jo; Wed, 19 Feb 2014 20:49:51 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s1JKnmwt030351; Wed, 19 Feb 2014 13:49:48 -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: U2FsdGVkX19JUgy/uYuR/TzcfQhR9D6W Subject: Re: About FreeBSD support one more mini-pc From: Ian Lepore To: Warner Losh In-Reply-To: References: <210081392741053@web22h.yandex.ru> <1392835264.1145.33.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Feb 2014 13:49:48 -0700 Message-ID: <1392842988.1145.50.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 20:49:58 -0000 On Wed, 2014-02-19 at 13:40 -0700, Warner Losh wrote: > On Feb 19, 2014, at 1:32 PM, Tom Everett wrote: > > > I would happily build a crochet-FreeBSD build for this, if it had a chance > > of working. I don't see a kernel config or any .dts files for this board > > on the tree, however, so those would have to be built out? > > Doesn't the board maker give yon ones that work on Linux? DTS is > designed to be OS agnostic, but doesn't always achieve that design > goal. Starting from Linux files typically is a good place to begin, although > from conversations with Ian I know that the iMX stuff falls farther from the > goals than others, so some manual tweaking would be in order... > > Warner > I actually worked pretty hard to make the imx6 stuff work with the linux dts without a lot of our own extra properties thrown in. I'm not sure it's 100% there. I need to get ublr working reliably with my wandboards, and then it's possible we could have a single unified imx6 kernel that worked for all imx6 boards. When I last tried ubldr it would sometimes launch the kernel just fine and sometimes just mysteriously hang. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Feb 19 22:12:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 314C0DA5 for ; Wed, 19 Feb 2014 22:12:06 +0000 (UTC) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E5F3819E7 for ; Wed, 19 Feb 2014 22:12:05 +0000 (UTC) Received: by mail-ob0-f169.google.com with SMTP id wo20so1203162obc.0 for ; Wed, 19 Feb 2014 14:12:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OwpY1aS3NN4zWgg2BOg32LZfxYszgoslubxecpSEt8A=; b=QiwMDdjVjQfTg0on9trOrHWhIgKCzn0LEw6dEEBE+JHGtKMPFrroEsnfVIRUJHrcvE 2I42f3U6njJNyuWxyBtkYYCJNBYKKlPsw6AH+52ewzBIP7dX1iYrHr1KJ12v8mXb7LOx ef7ldCbd6aiGLrs//LriGrYyUAyKJCv0SdqAOcW3pIzWv090IoFZmRIsXAFSihusL5Br RXl1+X+bo81mAEtjk05HYgEWPUObpfnuJs6d5RAD08SCkyKrr+72x0S/Y6WUjp/ghAHd mfc7e3FsjeRVC1wq1lhutuYvK1NfmKu4mvZvCPUy4xh0WXIwowSo9FLCngkMixkPwJqZ vQqg== X-Gm-Message-State: ALoCoQkqqGCvizFPiXhtyGPvPH/5xcQJL4qQgj7YkeQk+Udbl/NWdWCbn1ni2QoRUQkA7OzVslD6 MIME-Version: 1.0 X-Received: by 10.182.87.69 with SMTP id v5mr3215991obz.77.1392847925148; Wed, 19 Feb 2014 14:12:05 -0800 (PST) Received: by 10.182.104.169 with HTTP; Wed, 19 Feb 2014 14:12:05 -0800 (PST) In-Reply-To: <1392842988.1145.50.camel@revolution.hippie.lan> References: <210081392741053@web22h.yandex.ru> <1392835264.1145.33.camel@revolution.hippie.lan> <1392842988.1145.50.camel@revolution.hippie.lan> Date: Wed, 19 Feb 2014 15:12:05 -0700 Message-ID: Subject: Re: About FreeBSD support one more mini-pc From: Tom Everett To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" , Warner Losh X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 22:12:06 -0000 Hey Ian, i am just about to ask for a pull from my repo with a working ubldr for wandboard, if you wanted to take a look: https://github.com/teverett/crochet-freebsd/commit/f61660c4134ef495cb5f7de26c2048fba1e65c8f On Wed, Feb 19, 2014 at 1:49 PM, Ian Lepore wrote: > On Wed, 2014-02-19 at 13:40 -0700, Warner Losh wrote: > > On Feb 19, 2014, at 1:32 PM, Tom Everett wrote: > > > > > I would happily build a crochet-FreeBSD build for this, if it had a > chance > > > of working. I don't see a kernel config or any .dts files for this > board > > > on the tree, however, so those would have to be built out? > > > > Doesn't the board maker give yon ones that work on Linux? DTS is > > designed to be OS agnostic, but doesn't always achieve that design > > goal. Starting from Linux files typically is a good place to begin, > although > > from conversations with Ian I know that the iMX stuff falls farther from > the > > goals than others, so some manual tweaking would be in order... > > > > Warner > > > > I actually worked pretty hard to make the imx6 stuff work with the linux > dts without a lot of our own extra properties thrown in. I'm not sure > it's 100% there. > > I need to get ublr working reliably with my wandboards, and then it's > possible we could have a single unified imx6 kernel that worked for all > imx6 boards. When I last tried ubldr it would sometimes launch the > kernel just fine and sometimes just mysteriously hang. > > -- Ian > > > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Wed Feb 19 23:13:04 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C9D31B8 for ; Wed, 19 Feb 2014 23:13:04 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1941E1FC1 for ; Wed, 19 Feb 2014 23:13:03 +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 1WGGK6-0006Lp-JU; Wed, 19 Feb 2014 23:13:02 +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 s1JNCxvm030536; Wed, 19 Feb 2014 16:12:59 -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/Vm7hKh7j04vXBcQD3vaHm Subject: Re: About FreeBSD support one more mini-pc From: Ian Lepore To: Tom Everett In-Reply-To: References: <210081392741053@web22h.yandex.ru> <1392835264.1145.33.camel@revolution.hippie.lan> <1392842988.1145.50.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Feb 2014 16:12:58 -0700 Message-ID: <1392851578.1145.55.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 23:13:04 -0000 On Wed, 2014-02-19 at 15:12 -0700, Tom Everett wrote: > Hey Ian, i am just about to ask for a pull from my repo with a working > ubldr for wandboard, if you wanted to take a look: > > https://github.com/teverett/crochet-freebsd/commit/f61660c4134ef495cb5f7de26c2048fba1e65c8f > My problem isn't with u-boot, it's in the ubldr->kernel handoff. I'm using u-boot-2014.01 these days and it needs no patching other than to the wandboard config.h to turn on API and USB and a few other handy things. But when I boot, sometimes it works but more often it goes like this: U-Boot 2014.01 (Feb 19 2014 - 15:31:16) CPU: Freescale i.MX6Q rev1.2 at 792 MHz Reset cause: POR Board: Wandboard DRAM: 2 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 FEC Waiting for PHY auto negotiation to complete... done BOOTP broadcast 1 *** Unhandled DHCP Option in OFFER/ACK: 69 ... *** Unhandled DHCP Option in OFFER/ACK: 42 DHCP client bound to address 172.22.42.236 Using FEC device TFTP from server 172.22.42.240; our IP address is 172.22.42.236 Filename '/wand/boot/ubldr'. Load address: 0x11000000 Loading: ############## 10.4 MiB/s done Bytes transferred = 195484 (2fb9c hex) ## Starting application at 0x11000054 ... Consoles: U-Boot console Compatible API signature found @8f564028 Number of U-Boot devices: 2 FreeBSD/armv6 U-Boot loader, Revision 1.2 (ilepore@revolution.hippie.lan, Wed Feb 19 15:41:25 MST 2014) DRAM: 2048MB Device: disk - /boot/kernel/kernel text=0x42f3d0 data=0x31d14+0x2df1c syms=[0x4+0x923b0+0x4+0x6e34d] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB compiled into kernel. Kernel entry at 0x12000100... Kernel args: (null) a And it hangs there forever. The 'a' I just added, that shows me that it gets into the kernel, I print that 'a' from the first few instructions of locore.S. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Feb 19 23:24:20 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAE60398 for ; Wed, 19 Feb 2014 23:24:20 +0000 (UTC) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B13910C0 for ; Wed, 19 Feb 2014 23:24:20 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id z10so1004555pdj.5 for ; Wed, 19 Feb 2014 15:24:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Dwki3b+3f5HKNN4MqyyKLcaabFqavu8XI+MR4a/bFT0=; b=UMqQ0cjmRqmC7n1OuFYe78niH573c8BKTTFcscIjTQvn/Lz3MC37Ar3v4nQlfIzsYd un93bXUSIstNjtkcuEGA+2i3jSPQhGN89tWamRHnXDgLVO0F41h9A30CULXZ1tXJ0FcX VKWZBwdFIxXpnqkzFyl6MIraLozLc5Rla3aYad2gxjcziWrjkfFtOIANaUTfRgLpgwbk kT9m7gXOY4Dvd7zo4Yd6KKC+jddmxSrtfeXlA1DUPtbi8k0XKxB+lsv073FiC+Ekqfb8 OoeXZxDmgLmDfi+izH/quaBMwPG+Ou/We/vg6GGh/tJQhE7rZz3yz906seEM10N2b0/6 wJvQ== X-Gm-Message-State: ALoCoQl1Id9+nogFprkyOAEG2pCSvjFQtl0Dxeptq2r2OezMn8NvATiogVu2oEjPHY9MawCseGRc MIME-Version: 1.0 X-Received: by 10.66.192.74 with SMTP id he10mr5242784pac.126.1392852254523; Wed, 19 Feb 2014 15:24:14 -0800 (PST) Received: by 10.68.162.67 with HTTP; Wed, 19 Feb 2014 15:24:14 -0800 (PST) In-Reply-To: <1392851578.1145.55.camel@revolution.hippie.lan> References: <210081392741053@web22h.yandex.ru> <1392835264.1145.33.camel@revolution.hippie.lan> <1392842988.1145.50.camel@revolution.hippie.lan> <1392851578.1145.55.camel@revolution.hippie.lan> Date: Wed, 19 Feb 2014 16:24:14 -0700 Message-ID: Subject: Re: About FreeBSD support one more mini-pc From: Tom Everett To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 23:24:20 -0000 Debugging at that level is beyond my knowledge of U-boot and the kernel. I can volunteer however that I'm using the previous U-boot; u-boot-2013.10. On Wed, Feb 19, 2014 at 4:12 PM, Ian Lepore wrote: > On Wed, 2014-02-19 at 15:12 -0700, Tom Everett wrote: > > Hey Ian, i am just about to ask for a pull from my repo with a working > > ubldr for wandboard, if you wanted to take a look: > > > > > https://github.com/teverett/crochet-freebsd/commit/f61660c4134ef495cb5f7de26c2048fba1e65c8f > > > > My problem isn't with u-boot, it's in the ubldr->kernel handoff. I'm > using u-boot-2014.01 these days and it needs no patching other than to > the wandboard config.h to turn on API and USB and a few other handy > things. But when I boot, sometimes it works but more often it goes like > this: > > U-Boot 2014.01 (Feb 19 2014 - 15:31:16) > > CPU: Freescale i.MX6Q rev1.2 at 792 MHz > Reset cause: POR > Board: Wandboard > DRAM: 2 GiB > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > In: serial > Out: serial > Err: serial > Net: FEC > Hit any key to stop autoboot: 0 > FEC Waiting for PHY auto negotiation to complete... done > BOOTP broadcast 1 > *** Unhandled DHCP Option in OFFER/ACK: 69 > ... > *** Unhandled DHCP Option in OFFER/ACK: 42 > DHCP client bound to address 172.22.42.236 > Using FEC device > TFTP from server 172.22.42.240; our IP address is 172.22.42.236 > Filename '/wand/boot/ubldr'. > Load address: 0x11000000 > Loading: ############## > 10.4 MiB/s > done > Bytes transferred = 195484 (2fb9c hex) > ## Starting application at 0x11000054 ... > Consoles: U-Boot console > Compatible API signature found @8f564028 > Number of U-Boot devices: 2 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (ilepore@revolution.hippie.lan, Wed Feb 19 15:41:25 MST 2014) > DRAM: 2048MB > > Device: disk > - > /boot/kernel/kernel text=0x42f3d0 data=0x31d14+0x2df1c > syms=[0x4+0x923b0+0x4+0x6e34d] > Hit [Enter] to boot immediately, or any other key for command > prompt. > Booting [/boot/kernel/kernel]... > Using DTB compiled into kernel. > Kernel entry at 0x12000100... > Kernel args: (null) > a > > And it hangs there forever. The 'a' I just added, that shows me that it > gets into the kernel, I print that 'a' from the first few instructions > of locore.S. > > -- Ian > > > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Thu Feb 20 04:04:09 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12FF1CA4 for ; Thu, 20 Feb 2014 04:04:09 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D50F61ADC for ; Thu, 20 Feb 2014 04:04:08 +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 1WGKrn-0004M5-BL; Thu, 20 Feb 2014 04:04:07 +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 s1K444BJ030782; Wed, 19 Feb 2014 21:04:04 -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: U2FsdGVkX19FKXMGIQymhr1WO56vX+ls Subject: Re: About FreeBSD support one more mini-pc From: Ian Lepore To: Tom Everett In-Reply-To: <1392851578.1145.55.camel@revolution.hippie.lan> References: <210081392741053@web22h.yandex.ru> <1392835264.1145.33.camel@revolution.hippie.lan> <1392842988.1145.50.camel@revolution.hippie.lan> <1392851578.1145.55.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Feb 2014 21:04:04 -0700 Message-ID: <1392869044.1145.58.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 04:04:09 -0000 On Wed, 2014-02-19 at 16:12 -0700, Ian Lepore wrote: > On Wed, 2014-02-19 at 15:12 -0700, Tom Everett wrote: > > Hey Ian, i am just about to ask for a pull from my repo with a working > > ubldr for wandboard, if you wanted to take a look: > > > > https://github.com/teverett/crochet-freebsd/commit/f61660c4134ef495cb5f7de26c2048fba1e65c8f > > > > My problem isn't with u-boot, it's in the ubldr->kernel handoff. I'm > using u-boot-2014.01 these days and it needs no patching other than to > the wandboard config.h to turn on API and USB and a few other handy > things. But when I boot, sometimes it works but more often it goes like > this: > > U-Boot 2014.01 (Feb 19 2014 - 15:31:16) > > CPU: Freescale i.MX6Q rev1.2 at 792 MHz > Reset cause: POR > Board: Wandboard > DRAM: 2 GiB > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > In: serial > Out: serial > Err: serial > Net: FEC > Hit any key to stop autoboot: 0 > FEC Waiting for PHY auto negotiation to complete... done > BOOTP broadcast 1 > *** Unhandled DHCP Option in OFFER/ACK: 69 > ... > *** Unhandled DHCP Option in OFFER/ACK: 42 > DHCP client bound to address 172.22.42.236 > Using FEC device > TFTP from server 172.22.42.240; our IP address is 172.22.42.236 > Filename '/wand/boot/ubldr'. > Load address: 0x11000000 > Loading: ############## > 10.4 MiB/s > done > Bytes transferred = 195484 (2fb9c hex) > ## Starting application at 0x11000054 ... > Consoles: U-Boot console > Compatible API signature found @8f564028 > Number of U-Boot devices: 2 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (ilepore@revolution.hippie.lan, Wed Feb 19 15:41:25 MST 2014) > DRAM: 2048MB > > Device: disk > - > /boot/kernel/kernel text=0x42f3d0 data=0x31d14+0x2df1c syms=[0x4+0x923b0+0x4+0x6e34d] > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Using DTB compiled into kernel. > Kernel entry at 0x12000100... > Kernel args: (null) > a > > And it hangs there forever. The 'a' I just added, that shows me that it > gets into the kernel, I print that 'a' from the first few instructions > of locore.S. Follow up on this... it is because I'm using a newer u-boot that has the dcache enabled by default. If I use the "dcache off" command to disable it, it boots perfectly every time. If I leave the cache enabled it fails to boot most of the time with symptoms that pretty much exactly match stale data in the caches. We enable the MMU in locore.S without invalidating old cache contents first, and that appears to be a bad thing. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Feb 20 19:09:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70AA897C; Thu, 20 Feb 2014 19:09:11 +0000 (UTC) Received: from mailgate-02.zdv.uni-mainz.de (mailgate-02.zdv.Uni-Mainz.DE [IPv6:2001:4c80:40:62d:203:ffff:fe5d:b2f6]) by mx1.freebsd.org (Postfix) with ESMTP id 7F27B13AF; Thu, 20 Feb 2014 19:09:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-mainz.de; i=@uni-mainz.de; q=dns/txt; s=ironport; t=1392923351; x=1424459351; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=j9+KBknJaV1kQcLkyGxWWPzaVxi9QeU+95eqM9cWXHI=; b=AwIhrEqrX5Q1fNZ4gaFjFeYRDVX31FAcbv8pqTQrh4Rt+Rd4pC59cxN+ pCyKL8riD2ODfyrs3VeBEZm2B2YtDiJC5ELlLYfujKFtoBNUVTa6Es0O2 vSYtv3i5gLWOUMLjrdwlVNh0rK2szxEvLKOkp7uu6sUY2JCkescKNusAN g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAKpRBlMKXgZY/2dsb2JhbABZgmVZV8AOgSZ0giUBAQUnUgwEAgEIEQQBAQEnBzIUCQgCBAEJBAUIh30BDM4lEwSOZAcGhDIEiRCVYotigy2CKg X-IPAS-Result: AqIEAKpRBlMKXgZY/2dsb2JhbABZgmVZV8AOgSZ0giUBAQUnUgwEAgEIEQQBAQEnBzIUCQgCBAEJBAUIh30BDM4lEwSOZAcGhDIEiRCVYotigy2CKg Received: from e14hub-02.zdv.uni-mainz.de ([10.94.6.88]) by mailgate-02.zdv.uni-mainz.de with ESMTP; 20 Feb 2014 20:09:07 +0100 Received: from e15be-02.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:8fb0) by E14HUB-02.zdv.Uni-Mainz.DE (2001:4c80:40:606:21d:d8ff:feb7:1c60) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 20 Feb 2014 20:08:15 +0100 Received: from e15be-03.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9238) by e15be-02.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:8fb0) with Microsoft SMTP Server (TLS) id 15.0.775.38; Thu, 20 Feb 2014 20:08:03 +0100 Received: from e15be-03.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9238]) by e15be-03.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9238%18]) with mapi id 15.00.0775.031; Thu, 20 Feb 2014 20:08:03 +0100 From: =?iso-8859-1?B?V2Vp3ywgSvxyZ2Vu?= To: 'Ian Lepore' , 'Tom Everett' Subject: RE: About FreeBSD support one more mini-pc Thread-Topic: About FreeBSD support one more mini-pc Thread-Index: AQHPLMx2lO8+uVBB/02TkpGpjfhkM5q82ewAgAAfLwCAAAI1AIAAApQAgAAW/YCAABEDAIAAUVUAgAEJdPA= Date: Thu, 20 Feb 2014 19:08:02 +0000 Message-ID: <38db362d34174f70a07c0b9ea39a54c4@e15be-03.zdv.Uni-Mainz.DE> References: <210081392741053@web22h.yandex.ru> <1392835264.1145.33.camel@revolution.hippie.lan> <1392842988.1145.50.camel@revolution.hippie.lan> <1392851578.1145.55.camel@revolution.hippie.lan> <1392869044.1145.58.camel@revolution.hippie.lan> In-Reply-To: <1392869044.1145.58.camel@revolution.hippie.lan> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.93.178.81] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'freebsd-arm@freebsd.org'" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 19:09:11 -0000 > -----Original Message----- > From: owner-freebsd-arm@freebsd.org [mailto:owner-freebsd-arm@freebsd.org= ] On Behalf Of > Ian Lepore > Sent: Thursday, February 20, 2014 5:04 AM > To: Tom Everett > Cc: freebsd-arm@freebsd.org > Subject: Re: About FreeBSD support one more mini-pc >=20 > On Wed, 2014-02-19 at 16:12 -0700, Ian Lepore wrote: > > On Wed, 2014-02-19 at 15:12 -0700, Tom Everett wrote: > > > Hey Ian, i am just about to ask for a pull from my repo with a workin= g > > > ubldr for wandboard, if you wanted to take a look: > > > > > > https://github.com/teverett/crochet- > freebsd/commit/f61660c4134ef495cb5f7de26c2048fba1e65c8f > > > > > > > My problem isn't with u-boot, it's in the ubldr->kernel handoff. I'm > > using u-boot-2014.01 these days and it needs no patching other than to > > the wandboard config.h to turn on API and USB and a few other handy > > things. But when I boot, sometimes it works but more often it goes lik= e > > this: > > > > U-Boot 2014.01 (Feb 19 2014 - 15:31:16) > > > > CPU: Freescale i.MX6Q rev1.2 at 792 MHz > > Reset cause: POR > > Board: Wandboard > > DRAM: 2 GiB > > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > > In: serial > > Out: serial > > Err: serial > > Net: FEC > > Hit any key to stop autoboot: 0 > > FEC Waiting for PHY auto negotiation to complete... done > > BOOTP broadcast 1 > > *** Unhandled DHCP Option in OFFER/ACK: 69 > > ... > > *** Unhandled DHCP Option in OFFER/ACK: 42 > > DHCP client bound to address 172.22.42.236 > > Using FEC device > > TFTP from server 172.22.42.240; our IP address is 172.22.42.236 > > Filename '/wand/boot/ubldr'. > > Load address: 0x11000000 > > Loading: ############## > > 10.4 MiB/s > > done > > Bytes transferred =3D 195484 (2fb9c hex) > > ## Starting application at 0x11000054 ... > > Consoles: U-Boot console > > Compatible API signature found @8f564028 > > Number of U-Boot devices: 2 > > > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > > (ilepore@revolution.hippie.lan, Wed Feb 19 15:41:25 MST 2014) > > DRAM: 2048MB > > > > Device: disk > > - > > /boot/kernel/kernel text=3D0x42f3d0 data=3D0x31d14+0x2df1c > syms=3D[0x4+0x923b0+0x4+0x6e34d] > > Hit [Enter] to boot immediately, or any other key for command p= rompt. > > Booting [/boot/kernel/kernel]... > > Using DTB compiled into kernel. > > Kernel entry at 0x12000100... > > Kernel args: (null) > > a > > > > And it hangs there forever. The 'a' I just added, that shows me that i= t > > gets into the kernel, I print that 'a' from the first few instructions > > of locore.S. >=20 > Follow up on this... it is because I'm using a newer u-boot that has the > dcache enabled by default. If I use the "dcache off" command to disable > it, it boots perfectly every time. If I leave the cache enabled it > fails to boot most of the time with symptoms that pretty much exactly > match stale data in the caches. >=20 > We enable the MMU in locore.S without invalidating old cache contents > first, and that appears to be a bad thing. >=20 > -- Ian >=20 Hm, I use an u-boot version from early December, which has already enabled the L1 Dcache. I did not experience any problems with that version. On Jan 29th code was committed to the u-boot repository to enable the L2 cache. I have not checked that version yet. But without a Dcache invalidate, I had problems to start the second core. Juergen Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-2= 6407 From owner-freebsd-arm@FreeBSD.ORG Thu Feb 20 19:45:26 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 292B18DB for ; Thu, 20 Feb 2014 19:45:26 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C2FCF179A for ; Thu, 20 Feb 2014 19:45:25 +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 1WGZYb-0000oR-HQ; Thu, 20 Feb 2014 19:45:17 +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 s1KJjEOV031760; Thu, 20 Feb 2014 12:45:14 -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: U2FsdGVkX1965GBFwz0QRz/tn5QLveaI Subject: RE: About FreeBSD support one more mini-pc From: Ian Lepore To: =?ISO-8859-1?Q?Wei=DF=2C_J=FCrgen?= In-Reply-To: <38db362d34174f70a07c0b9ea39a54c4@e15be-03.zdv.Uni-Mainz.DE> References: <210081392741053@web22h.yandex.ru> <1392835264.1145.33.camel@revolution.hippie.lan> <1392842988.1145.50.camel@revolution.hippie.lan> <1392851578.1145.55.camel@revolution.hippie.lan> <1392869044.1145.58.camel@revolution.hippie.lan> <38db362d34174f70a07c0b9ea39a54c4@e15be-03.zdv.Uni-Mainz.DE> Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 20 Feb 2014 12:45:14 -0700 Message-ID: <1392925514.1145.68.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s1KJjEOV031760 Cc: "'freebsd-arm@freebsd.org'" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 19:45:26 -0000 On Thu, 2014-02-20 at 19:08 +0000, Wei=DF, J=FCrgen wrote: > > -----Original Message----- > > From: owner-freebsd-arm@freebsd.org [mailto:owner-freebsd-arm@freebsd= .org] On Behalf Of > > Ian Lepore > > Sent: Thursday, February 20, 2014 5:04 AM > > To: Tom Everett > > Cc: freebsd-arm@freebsd.org > > Subject: Re: About FreeBSD support one more mini-pc > >=20 > > On Wed, 2014-02-19 at 16:12 -0700, Ian Lepore wrote: > > > On Wed, 2014-02-19 at 15:12 -0700, Tom Everett wrote: > > > > Hey Ian, i am just about to ask for a pull from my repo with a wo= rking > > > > ubldr for wandboard, if you wanted to take a look: > > > > > > > > https://github.com/teverett/crochet- > > freebsd/commit/f61660c4134ef495cb5f7de26c2048fba1e65c8f > > > > > > > > > > My problem isn't with u-boot, it's in the ubldr->kernel handoff. I= 'm > > > using u-boot-2014.01 these days and it needs no patching other than= to > > > the wandboard config.h to turn on API and USB and a few other handy > > > things. But when I boot, sometimes it works but more often it goes= like > > > this: > > > > > > U-Boot 2014.01 (Feb 19 2014 - 15:31:16) > > > > > > CPU: Freescale i.MX6Q rev1.2 at 792 MHz > > > Reset cause: POR > > > Board: Wandboard > > > DRAM: 2 GiB > > > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > > > In: serial > > > Out: serial > > > Err: serial > > > Net: FEC > > > Hit any key to stop autoboot: 0 > > > FEC Waiting for PHY auto negotiation to complete... done > > > BOOTP broadcast 1 > > > *** Unhandled DHCP Option in OFFER/ACK: 69 > > > ... > > > *** Unhandled DHCP Option in OFFER/ACK: 42 > > > DHCP client bound to address 172.22.42.236 > > > Using FEC device > > > TFTP from server 172.22.42.240; our IP address is 172.22.42= .236 > > > Filename '/wand/boot/ubldr'. > > > Load address: 0x11000000 > > > Loading: ############## > > > 10.4 MiB/s > > > done > > > Bytes transferred =3D 195484 (2fb9c hex) > > > ## Starting application at 0x11000054 ... > > > Consoles: U-Boot console > > > Compatible API signature found @8f564028 > > > Number of U-Boot devices: 2 > > > > > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > > > (ilepore@revolution.hippie.lan, Wed Feb 19 15:41:25 MST 201= 4) > > > DRAM: 2048MB > > > > > > Device: disk > > > - > > > /boot/kernel/kernel text=3D0x42f3d0 data=3D0x31d14+0x2df1c > > syms=3D[0x4+0x923b0+0x4+0x6e34d] > > > Hit [Enter] to boot immediately, or any other key for comma= nd prompt. > > > Booting [/boot/kernel/kernel]... > > > Using DTB compiled into kernel. > > > Kernel entry at 0x12000100... > > > Kernel args: (null) > > > a > > > > > > And it hangs there forever. The 'a' I just added, that shows me th= at it > > > gets into the kernel, I print that 'a' from the first few instructi= ons > > > of locore.S. > >=20 > > Follow up on this... it is because I'm using a newer u-boot that has = the > > dcache enabled by default. If I use the "dcache off" command to disa= ble > > it, it boots perfectly every time. If I leave the cache enabled it > > fails to boot most of the time with symptoms that pretty much exactly > > match stale data in the caches. > >=20 > > We enable the MMU in locore.S without invalidating old cache contents > > first, and that appears to be a bad thing. > >=20 > > -- Ian > >=20 >=20 > Hm, I use an u-boot version from early December, which has already > enabled the L1 Dcache. I did not experience any problems with that > version. On Jan 29th code was committed to the u-boot repository to > enable the L2 cache. I have not checked that version yet. >=20 > But without a Dcache invalidate, I had problems to start the second > core. I think it is the enabling of the L2 cache that's causing the problem, because I added your code for invalidating L1 idcache to the first processor startup path, and that didn't help. =20 Flushing the L2 very early in startup is problematic, because we don't know its register addresses until we can read the fdt data (we don't even know what kind of l2 it is), and processing fdt while still running in physical address mode with only pc-relative addressing allowed is more or less impossible. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Feb 20 22:12:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F65AE57; Thu, 20 Feb 2014 22:12:47 +0000 (UTC) Received: from mailgate-02.zdv.uni-mainz.de (mailgate-02.zdv.Uni-Mainz.DE [IPv6:2001:4c80:40:62d:203:ffff:fe5d:b2f6]) by mx1.freebsd.org (Postfix) with ESMTP id 5ECBE16D4; Thu, 20 Feb 2014 22:12:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-mainz.de; i=@uni-mainz.de; q=dns/txt; s=ironport; t=1392934368; x=1424470368; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4mR9HLTvGmZOANivCaAxRVV5fR+kXSip0cBRLTJNn8k=; b=WMf4XxcP45tt60cX1GcDMqd2hyYpTkCOpZr2s+HFo+P2qN3O4yCocdpr 3pmoCnlUeRYdRjWKwGD3Os5T9xlfLo4d31gFYphTb/pxViWm+0CGSuOPT nkBZccEMww8Bu0CBCi5xAfpzLEpcIoZssay9cTn3L8otCWADsL4I6eQ5t E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAEB9BlMKXgZY/2dsb2JhbABZgmWBMMARgSd0giUBAQQBeQUHBAIBCBEEAQEBJwcyFAkIAgQOBQiHdQgBzTwXjmQHBoQyBIkQlWKLYoMtgio X-IPAS-Result: AqIEAEB9BlMKXgZY/2dsb2JhbABZgmWBMMARgSd0giUBAQQBeQUHBAIBCBEEAQEBJwcyFAkIAgQOBQiHdQgBzTwXjmQHBoQyBIkQlWKLYoMtgio Received: from e14hub-02.zdv.uni-mainz.de ([10.94.6.88]) by mailgate-02.zdv.uni-mainz.de with ESMTP; 20 Feb 2014 23:12:45 +0100 Received: from e15be-03.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9238) by E14HUB-02.zdv.Uni-Mainz.DE (2001:4c80:40:606:21d:d8ff:feb7:1c60) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 20 Feb 2014 23:11:52 +0100 Received: from e15be-03.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9238) by e15be-03.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9238) with Microsoft SMTP Server (TLS) id 15.0.775.38; Thu, 20 Feb 2014 23:11:51 +0100 Received: from e15be-03.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9238]) by e15be-03.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9238%18]) with mapi id 15.00.0775.031; Thu, 20 Feb 2014 23:11:51 +0100 From: =?iso-8859-1?B?V2Vp3ywgSvxyZ2Vu?= To: 'Ian Lepore' Subject: RE: About FreeBSD support one more mini-pc Thread-Topic: About FreeBSD support one more mini-pc Thread-Index: AQHPLMx2lO8+uVBB/02TkpGpjfhkM5q82ewAgAAfLwCAAAI1AIAAApQAgAAW/YCAABEDAIAAUVUAgAEJdPD///2CAIAALfMg Date: Thu, 20 Feb 2014 22:11:51 +0000 Message-ID: <302a70c418f04def935dd421aa6d968d@e15be-03.zdv.Uni-Mainz.DE> References: <210081392741053@web22h.yandex.ru> <1392835264.1145.33.camel@revolution.hippie.lan> <1392842988.1145.50.camel@revolution.hippie.lan> <1392851578.1145.55.camel@revolution.hippie.lan> <1392869044.1145.58.camel@revolution.hippie.lan> <38db362d34174f70a07c0b9ea39a54c4@e15be-03.zdv.Uni-Mainz.DE> <1392925514.1145.68.camel@revolution.hippie.lan> In-Reply-To: <1392925514.1145.68.camel@revolution.hippie.lan> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.93.178.81] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'freebsd-arm@freebsd.org'" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 22:12:47 -0000 > -----Original Message----- > From: Ian Lepore [mailto:ian@FreeBSD.org] > Sent: Thursday, February 20, 2014 8:45 PM > To: Wei=DF, J=FCrgen > Cc: 'freebsd-arm@freebsd.org' > Subject: RE: About FreeBSD support one more mini-pc >=20 > On Thu, 2014-02-20 at 19:08 +0000, Wei=DF, J=FCrgen wrote: > > > -----Original Message----- > > > From: owner-freebsd-arm@freebsd.org [mailto:owner-freebsd-arm@freebsd= .org] On Behalf > Of > > > Ian Lepore > > > Sent: Thursday, February 20, 2014 5:04 AM > > > To: Tom Everett > > > Cc: freebsd-arm@freebsd.org > > > Subject: Re: About FreeBSD support one more mini-pc > > > > > > > > And it hangs there forever. The 'a' I just added, that shows me th= at it > > > > gets into the kernel, I print that 'a' from the first few instructi= ons > > > > of locore.S. > > > > > > Follow up on this... it is because I'm using a newer u-boot that has = the > > > dcache enabled by default. If I use the "dcache off" command to disa= ble > > > it, it boots perfectly every time. If I leave the cache enabled it > > > fails to boot most of the time with symptoms that pretty much exactly > > > match stale data in the caches. > > > > > > We enable the MMU in locore.S without invalidating old cache contents > > > first, and that appears to be a bad thing. > > > > > > -- Ian > > > > > > > Hm, I use an u-boot version from early December, which has already > > enabled the L1 Dcache. I did not experience any problems with that > > version. On Jan 29th code was committed to the u-boot repository to > > enable the L2 cache. I have not checked that version yet. > > > > But without a Dcache invalidate, I had problems to start the second > > core. >=20 > I think it is the enabling of the L2 cache that's causing the problem, > because I added your code for invalidating L1 idcache to the first > processor startup path, and that didn't help. For the first core you should wbinv the L1 Dcache when changing translation= s, as it was already invalidated (and enabled) by u-boot or even rom. By only= =20 invalidating the Dcache one may lose un"written back" data. The L1 Caches = of the other cores are not initialized by u-boot or rom and contain garbage.=20 They must not be written back to avoid corruption of main memory.=20 =20 > Flushing the L2 very early in startup is problematic, because we don't > know its register addresses until we can read the fdt data (we don't > even know what kind of l2 it is), and processing fdt while still running > in physical address mode with only pc-relative addressing allowed is > more or less impossible. >=20 > -- Ian >=20 As a PIPT cache, the L2 cache should be transparent to almost all operation= s with the exception of DMA. And DMA should be of no concern in early boot. The L2 cache operations are only added to the cpu_functions after the L2 cache is probed and attached. Or do I miss something? Juergen Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-2= 6407 From owner-freebsd-arm@FreeBSD.ORG Fri Feb 21 13:05:34 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C04B9DEE for ; Fri, 21 Feb 2014 13:05:34 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id EF7831A84 for ; Fri, 21 Feb 2014 13:05:33 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 91745B835; Fri, 21 Feb 2014 15:05:30 +0200 (SAST) Date: Fri, 21 Feb 2014 15:05:30 +0200 From: John Hay To: freebsd-arm@freebsd.org Subject: Re: status of AVILA and CAMBRIA code Message-ID: <20140221130530.GA202@zibbi.meraka.csir.co.za> References: <20140219105934.GA74731@zibbi.meraka.csir.co.za> <20140219172938.GH34851@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140219172938.GH34851@funkthat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 13:05:34 -0000 On Wed, Feb 19, 2014 at 09:29:38AM -0800, John-Mark Gurney wrote: > John Hay wrote this message on Wed, Feb 19, 2014 at 12:59 +0200: > > What is the status of AVILA and CAMBRIA builds in our tree? Have anybody > > had success recently? From the lists I can see that other people have > > also asked in September 2013, but I cannot figure out if there was any > > successes at that stage. :-) ... > > > > Somewhere along the line the ethernet npe0 device also broke, writing > > "npe0: npestart_locked: too many fragments 0". But I did not test the > > npe0 device with every build and only realised it this morning, so I > > do not know where it broke. :-) > > Not sure about these issues... Ok, I found the place. It is svn 246713 by kib: ########### Reform the busdma API so that new types may be added without modifying every architecture's busdma_machdep.c. It is done by unifying the bus_dmamap_load_buffer() routines so that they may be called from MI code. The MD busdma is then given a chance to do any final processing in the complete() callback. The cam changes unify the bus_dmamap_load* handling in cam drivers. The arm and mips implementations are updated to track virtual addresses for sync(). Previously this was done in a type specific way. Now it is done in a generic way by recording the list of virtuals in the map. Submitted by: jeff (sponsored by EMC/Isilon) Reviewed by: kan (previous version), scottl, mjacob (isp(4), no objections for target mode changes) Discussed with: ian (arm changes) Tested by: marius (sparc64), mips (jmallet), isci(4) on x86 (jharris), amd64 (Fabian Keil ########### After that tx packets will cause this message: npe0: npestart_locked: too many fragments. Then updating to 246881 by ian: ############# In _bus_dmamap_addseg(), the return value must be zero for error, or the size actually added to the segment (possibly smaller than the requested size if boundary crossings had to be avoided). ############# This makes it a bit better in that some packets seem to go through. It looks like 3 out of 4 will go out and the forth will cause the same message as above. I have added a printf just above bus_dmamap_load_mbuf_sg() in npestart_locked() to show some of the mbuf values: ############ npe0: npestart_locked: m_len 42, data 0xc0d3dcd6, next 0 npe0: npestart_locked: m_len 42, data 0xc0d45dd6, next 0 npe0: npestart_locked: m_len 42, data 0xc11872d6, next 0 npe0: npestart_locked: m_len 342, data 0xc11c2800, next 0 npe0: npestart_locked: too many fragments 0 npe0: npestart_locked: m_len 42, data 0xc0d434d6, next 0 npe0: npestart_locked: m_len 42, data 0xc0d449d6, next 0 npe0: npestart_locked: m_len 42, data 0xc0d428d6, next 0 npe0: npestart_locked: m_len 42, data 0xc0d402d6, next 0 npe0: npestart_locked: too many fragments 0 npe0: npestart_locked: m_len 42, data 0xc0d3e3d6, next 0 npe0: npestart_locked: m_len 42, data 0xc118d2d6, next 0 npe0: npestart_locked: m_len 342, data 0xc1192800, next 0 npe0: npestart_locked: m_len 342, data 0xc11b4800, next 0 npe0: npestart_locked: too many fragments 0 npe0: npestart_locked: m_len 42, data 0xc118b8d6, next 0 npe0: npestart_locked: m_len 42, data 0xc0d412d6, next 0 npe0: npestart_locked: m_len 42, data 0xc118e9d6, next 0 npe0: npestart_locked: m_len 42, data 0xc0d422d6, next 0 npe0: npestart_locked: too many fragments 0 npe0: npestart_locked: m_len 42, data 0xc0d424d6, next 0 npe0: npestart_locked: m_len 42, data 0xc118d0d6, next 0 npe0: npestart_locked: m_len 42, data 0xc0d415d6, next 0 npe0: npestart_locked: m_len 42, data 0xc0d40cd6, next 0 npe0: npestart_locked: too many fragments 0 npe0: npestart_locked: m_len 42, data 0xc118acd6, next 0 npe0: npestart_locked: m_len 42, data 0xc118e2d6, next 0 npe0: npestart_locked: m_len 42, data 0xc11891d6, next 0 npe0: npestart_locked: m_len 42, data 0xc1187ed6, next 0 npe0: npestart_locked: too many fragments 0 npe0: npestart_locked: m_len 42, data 0xc0d3d8d6, next 0 npe0: npestart_locked: m_len 42, data 0xc11897d6, next 0 npe0: npestart_locked: m_len 42, data 0xc118e8d6, next 0 npe0: npestart_locked: m_len 42, data 0xc118c0d6, next 0 npe0: npestart_locked: too many fragments 0 npe0: npestart_locked: m_len 42, data 0xc0d3e2d6, next 0 npe0: npestart_locked: m_len 42, data 0xc0d40ed6, next 0 npe0: npestart_locked: m_len 42, data 0xc1188ad6, next 0 npe0: npestart_locked: m_len 42, data 0xc0d3f8d6, next 0 npe0: npestart_locked: too many fragments 0 npe0: npestart_locked: m_len 42, data 0xc118e5d6, next 0 npe0: npestart_locked: m_len 42, data 0xc0d3d6d6, next 0 ############ Any ideas? John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-arm@FreeBSD.ORG Fri Feb 21 14:57:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59656A61 for ; Fri, 21 Feb 2014 14:57:18 +0000 (UTC) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1CEB9174D for ; Fri, 21 Feb 2014 14:57:17 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id i4so2106761oah.36 for ; Fri, 21 Feb 2014 06:57:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OeNUgPA4ss7t6y5h3jKVGvky1nS1dyOcHJHb8ZRUOI0=; b=EmBOKiLglWwY4F5pPLKGp8/d2rEZV8yGl7lzPGSGnCwBELoEbxl3zFZFHGjMDANWhX 0FXpDEqG6SfYokNVMMsHQX/zhTEsvDBbQr0mZex8fZOuNsvmGFwgGk5ZFXxM3BBgLH1n 0gqalYe148AfgYS4T1Hhp8wJwrCSxy8RhL58Pj2Al6fxb6Q/w1nXNGwH1C1a1o3w5jMP azaP7PbxhtUO3C7xw20Hf+LAH25z/FYWsQ1JEN8DFhUnTkUCJLyOQfglNZB54evMU6Y8 3nsqdpBKcYHY4K3l1N2Dits/FetJiX29y96UeXTx/2RG4pYdYz/d5FQLOvZ5MiGcwhfn 24pA== X-Gm-Message-State: ALoCoQlSY/bxoA7AGuQ68Tvmuisy3d6f8AchvA8iN0JaTclcoOcok1+0UenU0ExngsHQCLbScV2B MIME-Version: 1.0 X-Received: by 10.60.142.166 with SMTP id rx6mr9601079oeb.57.1392994630622; Fri, 21 Feb 2014 06:57:10 -0800 (PST) Received: by 10.182.165.167 with HTTP; Fri, 21 Feb 2014 06:57:10 -0800 (PST) X-Originating-IP: [2001:44b8:31b0:aa00:c685:8ff:fe35:3e2d] In-Reply-To: <87ob2gxfg0.fsf@gmail.com> References: <87ob2gxfg0.fsf@gmail.com> Date: Sat, 22 Feb 2014 01:57:10 +1100 Message-ID: Subject: Re: Beaglebone Black: crash during portsnap extract From: Jason Birch To: hhh@sdf.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 14:57:18 -0000 I think `portsnap fetch` is sufficient to trigger this with the snapshots from Feb 16th. $ uname -a FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r261948: Sun Feb 16 18:05:23 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE arm [ via ssh ] # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... none found. Fetching snapshot tag from portsnap.FreeBSD.org... done. Fetching snapshot metadata... done. Fetching snapshot generated at Fri Feb 21 00:01:19 UTC 2014: 226ed4090b222d40e48a3ad2f610dd81bef3c38f53deeb100% of 69 MB 659 kBps 01m47s Extracting snapshot... [ Halts here ] [ Over in the UART world ] mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 4 Failed mmcsd0: Error indicated: 4 Failed ... [ 30 identical lines omitted] ... mmcsd0: Error indicated: 4 Failed mmcsd0: Error indicated: 4 Failed mmcsd0: Error indicag_vfs_done():mmcsd0s2a[WRITE(offset=998113280, length=16384)]error = 5 panic: No b_bufobj 0xc11d0c20 KDB: enter: panic [ thread pid 12 tid 100007 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! db> c Uptime: 6m57s Automatic reboot in 15 seconds - press a key on the console to abort I see the same behaviour performing `portsnap fetch` over the UART connection. There's some trace/proc/reg love at https://gist.github.com/jbirch/9135611, but I'm afraid I don't know much more here. This is reliably reproducible so I'll be using it to learn how to effectively use ddb. JB On Mon, Feb 10, 2014 at 6:18 AM, wrote: > Hi all, > > my system is crashing every time I try to extract snapshot of ports tree > (portsnap extract). I had no problems coping the ports tree from a > different machine using sftp. Do you have suggestions why is it > happening? > > > The system (uname -a): > > FreeBSD beaglebone 10.0-STABLE FreeBSD 10.0-STABLE #0 r261548: Thu Feb 6 > 14:41:33 UTC 2014 root@localhsot:/root/crochet-freebsd/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE > arm > > > And the message: > > sdhci_ti0-slot0: Got data interrupt 0x00000010, but there is no active > command. > sdhci_ti0-slot0: ============== REGISTER DUMP ============== > sdhci_ti0-slot0: Sys addr: 0x00000000 | Version: 0x00003101 > sdhci_ti0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000001 > sdhci_ti0-slot0: Argument: 0x00005d16 | Trn mode: 0x0000183a > sdhci_ti0-slot0: Present: 0x01f70000 | Host ctl: 0x00000006 > sdhci_ti0-slot0: Power: 0x0000000d | Blk gap: 0x00000000 > sdhci_ti0-slot0: Wake-up: 0x00000000 | Clock: 0x00000007 > sdhci_ti0-slot0: Timeout: 0x0000000d | Int stat: 0x00000000 > sdhci_ti0-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb > sdhci_ti0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_ti0-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 > sdhci_ti0-slot0: =========================================== > mmcsd0: Error indicated: 2 Bad CRC > sdhci_ti0-slot0: Got data interrupt 0x00000010, but there is no active > command. > sdhci_ti0-slot0: ============== REGISTER DUMP ============== > sdhci_ti0-slot0: Sys addr: 0x00000000 | Version: 0x00003101 > sdhci_ti0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000008 > sdhci_ti0-slot0: Argument: 0x001e42be | Trn mode: 0x0000193a > sdhci_ti0-slot0: Present: 0x01f70000 | Host ctl: 0x00000006 > sdhci_ti0-slot0: Power: 0x0000000d | Blk gap: 0x00000000 > sdhci_ti0-slot0: Wake-up: 0x00000000 | Clock: 0x00000007 > sdhci_ti0-slot0: Timeout: 0x0000000d | Int stat: 0x00000000 > sdhci_ti0-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb > sdhci_ti0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_ti0-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 > sdhci_ti0-slot0: =========================================== > mmcsd0: Error indicated: 1 Timeout > sdhci_ti0-slot0: Got data interrupt 0x00000010, but there is no active > command. > sdhci_ti0-slot0: ============== REGISTER DUMP ============== > sdhci_ti0-slot0: Sys addr: 0x00000000 | Version: 0x00003101 > sdhci_ti0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000008 > sdhci_ti0-slot0: Argument: 0x001e42fe | Trn mode: 0x0000193a > sdhci_ti0-slot0: Present: 0x01f70000 | Host ctl: 0x00000006 > sdhci_ti0-slot0: Power: 0x0000000d | Blk gap: 0x00000000 > sdhci_ti0-slot0: Wake-up: 0x00000000 | Clock: 0x00000007 > sdhci_ti0-slot0: Timeout: 0x0000000d | Int stat: 0x00000000 > sdhci_ti0-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb > sdhci_ti0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 > sdhci_ti0-slot0: Caps: 0x06e10080 | Max curr: 0x00000000 > sdhci_ti0-slot0: =========================================== > mmcsd0: Error indicated: 1 Timeout > g_vfs_done():mmcsd0s2a[WRITE(offset=10072064, length=512)]error = 5 > panic: brelse: inappropriate B_PAGING or B_CLUSTER bp 0xcd17df48 > KDB: enter: panic > [ thread pid 12 tid 100007 ] > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > db> > > > Thank you for help > Henryk > _______________________________________________ > 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 Feb 21 15:41:48 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D1C6901 for ; Fri, 21 Feb 2014 15:41:48 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2DE791C14 for ; Fri, 21 Feb 2014 15:41:47 +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 1WGsEO-000Kjq-O0; Fri, 21 Feb 2014 15:41:40 +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 s1LFfbpr032912; Fri, 21 Feb 2014 08:41:37 -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: U2FsdGVkX19i49ZFTw4NNWbvBm+Qj8I5 Subject: Re: Beaglebone Black: crash during portsnap extract From: Ian Lepore To: Jason Birch In-Reply-To: References: <87ob2gxfg0.fsf@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Feb 2014 08:41:37 -0700 Message-ID: <1392997297.1145.88.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 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 15:41:48 -0000 On Sat, 2014-02-22 at 01:57 +1100, Jason Birch wrote: > I think `portsnap fetch` is sufficient to trigger this with the snapshots > from Feb 16th. > > $ uname -a > FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r261948: Sun > Feb 16 18:05:23 UTC 2014 > root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE > arm > > [ via ssh ] > # portsnap fetch > Looking up portsnap.FreeBSD.org mirrors... none found. > Fetching snapshot tag from portsnap.FreeBSD.org... done. > Fetching snapshot metadata... done. > Fetching snapshot generated at Fri Feb 21 00:01:19 UTC 2014: > 226ed4090b222d40e48a3ad2f610dd81bef3c38f53deeb100% of 69 MB 659 kBps > 01m47s > Extracting snapshot... > [ Halts here ] > > [ Over in the UART world ] > mmcsd0: Error indicated: 1 Timeout > mmcsd0: Error indicated: 4 Failed > mmcsd0: Error indicated: 4 Failed > ... [ 30 identical lines omitted] ... > mmcsd0: Error indicated: 4 Failed > mmcsd0: Error indicated: 4 Failed > mmcsd0: Error indicag_vfs_done():mmcsd0s2a[WRITE(offset=998113280, > length=16384)]error = 5 > panic: No b_bufobj 0xc11d0c20 > KDB: enter: panic > [ thread pid 12 tid 100007 ] > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > db> c > Uptime: 6m57s > Automatic reboot in 15 seconds - press a key on the console to abort > > I see the same behaviour performing `portsnap fetch` over the UART > connection. There's some trace/proc/reg love at > https://gist.github.com/jbirch/9135611, but I'm afraid I don't know much > more here. This is reliably reproducible so I'll be using it to learn how > to effectively use ddb. I recognize this, because a mistake of mine is involved... it got a timeout based on new timeout logic I added in r261945. As part of trying to recover from that I made the code do a controller reset, and that was a mistake, it leads to "everything after that fails." I fixed that in r261983, which does a lighter-weight reset that may let the controller recover and subsequent retries will work. I'm not saying updating to r261983 will fix everything, but it's more-correct code. What this doesn't explain is why it's getting a timeout in the first place. No single sdcard transaction is supposed to take longer than 250 milliseconds according to the SD spec. When I was testing with this stuff a few days ago, I had a 16gb card that was sometimes taking between 1-2 seconds to complete a write command, but the commands were completing successfully after that much time. I tried a samsung 8gb and a sandisk 4gb card and they worked fine. It made me wonder if the 16gb card was maybe some sort of grey market counterfeit. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Feb 21 16:06:13 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E0D7675; Fri, 21 Feb 2014 16:06:13 +0000 (UTC) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B8BAF1FA3; Fri, 21 Feb 2014 16:06:12 +0000 (UTC) Received: by mail-ea0-f170.google.com with SMTP id g15so1680352eak.29 for ; Fri, 21 Feb 2014 08:06:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lkDeeQVkOWjn2GBPHYlOU1FB22CRZU172Wh6Xa1VZ6E=; b=H7rhWxjZEhicNdwtC7lwuKvoBQhYIemh+VV9VrzQNSnHeBJJPclxlY19zh0dH0XYMb iVSj0XXl2eJGFacGaXYy7SVkkVHgC6Z0b5t1FPeZaCBiBpQnDrXn5V3lfynegxhgaJAz /Ev4SFqwUi213+4S8SFS98xsSZWDhWHbynJ6C5MUNKYjxO03hEE29GTe1j26w9K5TNNW nJfV1X4jLfGqS+8opU7Oudl8TtIy6ulQZY6zwgYdqU6jQo0N4wX7sMSbesqdRCcJeJkJ ywyxFHjw3pbnBQfOaeW5Crlzmi70GR38GaU07q9s9ayyFZyE/XSu7fZW6Hrw4p0GSNSu d70g== X-Received: by 10.14.193.193 with SMTP id k41mr9324149een.112.1392998770992; Fri, 21 Feb 2014 08:06:10 -0800 (PST) Received: from [192.168.0.118] (vpn.static.83-173-212-209.cybernet.ch. [83.173.212.209]) by mx.google.com with ESMTPSA id j41sm27973640eey.15.2014.02.21.08.06.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 08:06:10 -0800 (PST) Message-ID: <53077971.8060406@gmail.com> Date: Fri, 21 Feb 2014 17:06:09 +0100 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Beaglebone Black: crash during portsnap extract References: <87ob2gxfg0.fsf@gmail.com> <1392997297.1145.88.camel@revolution.hippie.lan> In-Reply-To: <1392997297.1145.88.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 16:06:13 -0000 Am 21.02.2014 16:41, schrieb Ian Lepore: > On Sat, 2014-02-22 at 01:57 +1100, Jason Birch wrote: >> I think `portsnap fetch` is sufficient to trigger this with the snapshots >> from Feb 16th. >> >> $ uname -a >> FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r261948: Sun >> Feb 16 18:05:23 UTC 2014 >> root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE >> arm >> >> [ via ssh ] >> # portsnap fetch >> Looking up portsnap.FreeBSD.org mirrors... none found. >> Fetching snapshot tag from portsnap.FreeBSD.org... done. >> Fetching snapshot metadata... done. >> Fetching snapshot generated at Fri Feb 21 00:01:19 UTC 2014: >> 226ed4090b222d40e48a3ad2f610dd81bef3c38f53deeb100% of 69 MB 659 kBps >> 01m47s >> Extracting snapshot... >> [ Halts here ] >> >> [ Over in the UART world ] >> mmcsd0: Error indicated: 1 Timeout >> mmcsd0: Error indicated: 4 Failed >> mmcsd0: Error indicated: 4 Failed >> ... [ 30 identical lines omitted] ... >> mmcsd0: Error indicated: 4 Failed >> mmcsd0: Error indicated: 4 Failed >> mmcsd0: Error indicag_vfs_done():mmcsd0s2a[WRITE(offset=998113280, >> length=16384)]error = 5 >> panic: No b_bufobj 0xc11d0c20 >> KDB: enter: panic >> [ thread pid 12 tid 100007 ] >> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >> db> c >> Uptime: 6m57s >> Automatic reboot in 15 seconds - press a key on the console to abort >> >> I see the same behaviour performing `portsnap fetch` over the UART >> connection. There's some trace/proc/reg love at >> https://gist.github.com/jbirch/9135611, but I'm afraid I don't know much >> more here. This is reliably reproducible so I'll be using it to learn how >> to effectively use ddb. > I recognize this, because a mistake of mine is involved... it got a > timeout based on new timeout logic I added in r261945. As part of > trying to recover from that I made the code do a controller reset, and > that was a mistake, it leads to "everything after that fails." I fixed > that in r261983, which does a lighter-weight reset that may let the > controller recover and subsequent retries will work. I'm not saying > updating to r261983 will fix everything, but it's more-correct code. > > What this doesn't explain is why it's getting a timeout in the first > place. No single sdcard transaction is supposed to take longer than 250 > milliseconds according to the SD spec. When I was testing with this > stuff a few days ago, I had a 16gb card that was sometimes taking > between 1-2 seconds to complete a write command, but the commands were > completing successfully after that much time. I tried a samsung 8gb and > a sandisk 4gb card and they worked fine. It made me wonder if the 16gb > card was maybe some sort of grey market counterfeit. > > Interesting, as I was actually going to complain about a similar (the same?) issue. I've this problems on the dreamplug, and the internal SD card gets corrupted each time after using portsnap. I'm not getting any panic though, it just gets stuck. Funny thing is, that even if I have a NFS share mounted or a ZFS pool mounted at /usr/ports (and /var/db/portsnap/ or any other specified portsnap working directory), portsnap manages to kill the filesystem of the SD card (why is it even touching it?) It doesn't happen with any other copy or extract command like cp, scp, tftp, tar etc. I didn't check for any timeout messages then though.... maybe I should. Mat From owner-freebsd-arm@FreeBSD.ORG Fri Feb 21 16:47:34 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E60F27A for ; Fri, 21 Feb 2014 16:47:34 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5F35E1353 for ; Fri, 21 Feb 2014 16:47:34 +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 1WGtG9-000Df2-0i; Fri, 21 Feb 2014 16:47:33 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s1LGlTJD032969; Fri, 21 Feb 2014 09:47:29 -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/r+hGK09HM5/9L++rz7iQu Subject: Re: status of AVILA and CAMBRIA code From: Ian Lepore To: John Hay In-Reply-To: <20140221130530.GA202@zibbi.meraka.csir.co.za> References: <20140219105934.GA74731@zibbi.meraka.csir.co.za> <20140219172938.GH34851@funkthat.com> <20140221130530.GA202@zibbi.meraka.csir.co.za> Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Feb 2014 09:47:29 -0700 Message-ID: <1393001249.1145.98.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 16:47:34 -0000 On Fri, 2014-02-21 at 15:05 +0200, John Hay wrote: > On Wed, Feb 19, 2014 at 09:29:38AM -0800, John-Mark Gurney wrote: > > John Hay wrote this message on Wed, Feb 19, 2014 at 12:59 +0200: > > > What is the status of AVILA and CAMBRIA builds in our tree? Have anybody > > > had success recently? From the lists I can see that other people have > > > also asked in September 2013, but I cannot figure out if there was any > > > successes at that stage. :-) > ... > > > > > > Somewhere along the line the ethernet npe0 device also broke, writing > > > "npe0: npestart_locked: too many fragments 0". But I did not test the > > > npe0 device with every build and only realised it this morning, so I > > > do not know where it broke. :-) > > > > Not sure about these issues... > > Ok, I found the place. It is svn 246713 by kib: > > ########### > Reform the busdma API so that new types may be added without modifying > every architecture's busdma_machdep.c. It is done by unifying the > bus_dmamap_load_buffer() routines so that they may be called from MI > code. The MD busdma is then given a chance to do any final processing > in the complete() callback. > > The cam changes unify the bus_dmamap_load* handling in cam drivers. > > The arm and mips implementations are updated to track virtual > addresses for sync(). Previously this was done in a type specific > way. Now it is done in a generic way by recording the list of > virtuals in the map. > > Submitted by: jeff (sponsored by EMC/Isilon) > Reviewed by: kan (previous version), scottl, > mjacob (isp(4), no objections for target mode changes) > Discussed with: ian (arm changes) > Tested by: marius (sparc64), mips (jmallet), isci(4) on x86 (jharris), > amd64 (Fabian Keil > ########### > > After that tx packets will cause this message: > npe0: npestart_locked: too many fragments. > > Then updating to 246881 by ian: > > ############# > In _bus_dmamap_addseg(), the return value must be zero for error, or the size > actually added to the segment (possibly smaller than the requested size if > boundary crossings had to be avoided). > ############# > > This makes it a bit better in that some packets seem to go through. It > looks like 3 out of 4 will go out and the forth will cause the same > message as above. > > I have added a printf just above bus_dmamap_load_mbuf_sg() in > npestart_locked() to show some of the mbuf values: > > ############ > npe0: npestart_locked: m_len 42, data 0xc0d3dcd6, next 0 > [...] > ############ > > Any ideas? > > John I can't see the path through the busdma code that leads to that result. It looks like there are two ways the mapping can fail, maybe it would help to know which path it's taking. In arm/busdma_machdep.c the two error paths out of the mapping loop are at lines 1066 and 1077, could you try putting printfs at those locations so we know which case is happening? Maybe printing some of the values involved with taking those exits would be helpful too. Maybe also check for map->sync_count being non-zero on entry to _bus_dmamap_load_buffer() and print something if it is. The printfs you did earlier make it look like there's never actually a second mbuf chained off the first (which makes sense for such small packets), I think that number should always be zero on entry because the outer loop in kern/subr_bus_dma.c should only ever run once. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Feb 21 18:53:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 054DEA34 for ; Fri, 21 Feb 2014 18:53:56 +0000 (UTC) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C377210A6 for ; Fri, 21 Feb 2014 18:53:55 +0000 (UTC) Received: by mail-pb0-f46.google.com with SMTP id um1so3808460pbc.5 for ; Fri, 21 Feb 2014 10:53:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=vaMYCw1++lVhzjAA4DOxB8Yb52zTJA1v7Rzh7NrH4So=; b=Kcs3t52hn8A52mf/UnqyqOaOGTCF+XoBJBQOG4Kxq16vCaGOLRlhaJwyMJnenD3MOj TAtmo6EvU5b+BgyRliDN9n9whIcsJ+GXo7TawsPtSlNft1vtyjFq4G4vgvjEluKjkJDB 5/7R2NTmxyoHhwF9EbvIm5wooFxr5athR+RkuUp9cLndw50wuSTzpbLzVLIJS6AFSY5g lYDXmrcg3WvajdXxUgq9GOUQ1zbHInYN1VYNaHOLG/HnVHe45w3TxryJLo02Uu2gfe33 27Ou7Z9wI/u2rVA6H8lA+2T+jNGZ3c59OQp5W8ZuqLnAFU1gPbPld2RlUvl03IlbIrgh CQaA== X-Gm-Message-State: ALoCoQk4aYKtOlNiOEejsUYyW0gGebckwNydqKNGcWPOx3Oz1Sq0JQdMx9eXstYIY9qi9q24s43X X-Received: by 10.68.194.97 with SMTP id hv1mr10769908pbc.162.1393008829791; Fri, 21 Feb 2014 10:53:49 -0800 (PST) Received: from macmini.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id iq10sm23767436pbc.14.2014.02.21.10.53.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 10:53:49 -0800 (PST) Subject: Re: About FreeBSD support one more mini-pc Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Warner Losh In-Reply-To: <1392925514.1145.68.camel@revolution.hippie.lan> Date: Fri, 21 Feb 2014 11:53:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <210081392741053@web22h.yandex.ru> <1392835264.1145.33.camel@revolution.hippie.lan> <1392842988.1145.50.camel@revolution.hippie.lan> <1392851578.1145.55.camel@revolution.hippie.lan> <1392869044.1145.58.camel@revolution.hippie.lan> <38db362d34174f70a07c0b9ea39a54c4@e15be-03.zdv.Uni-Mainz.DE> <1392925514.1145.68.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) Cc: "'freebsd-arm@freebsd.org'" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 18:53:56 -0000 On Feb 20, 2014, at 12:45 PM, Ian Lepore wrote: > On Thu, 2014-02-20 at 19:08 +0000, Wei=DF, J=FCrgen wrote: >>> -----Original Message----- >>> From: owner-freebsd-arm@freebsd.org = [mailto:owner-freebsd-arm@freebsd.org] On Behalf Of >>> Ian Lepore >>> Sent: Thursday, February 20, 2014 5:04 AM >>> To: Tom Everett >>> Cc: freebsd-arm@freebsd.org >>> Subject: Re: About FreeBSD support one more mini-pc >>>=20 >>> On Wed, 2014-02-19 at 16:12 -0700, Ian Lepore wrote: >>>> On Wed, 2014-02-19 at 15:12 -0700, Tom Everett wrote: >>>>> Hey Ian, i am just about to ask for a pull from my repo with a = working >>>>> ubldr for wandboard, if you wanted to take a look: >>>>>=20 >>>>> https://github.com/teverett/crochet- >>> freebsd/commit/f61660c4134ef495cb5f7de26c2048fba1e65c8f >>>>>=20 >>>>=20 >>>> My problem isn't with u-boot, it's in the ubldr->kernel handoff. = I'm >>>> using u-boot-2014.01 these days and it needs no patching other than = to >>>> the wandboard config.h to turn on API and USB and a few other handy >>>> things. But when I boot, sometimes it works but more often it goes = like >>>> this: >>>>=20 >>>> U-Boot 2014.01 (Feb 19 2014 - 15:31:16) >>>>=20 >>>> CPU: Freescale i.MX6Q rev1.2 at 792 MHz >>>> Reset cause: POR >>>> Board: Wandboard >>>> DRAM: 2 GiB >>>> MMC: FSL_SDHC: 0, FSL_SDHC: 1 >>>> In: serial >>>> Out: serial >>>> Err: serial >>>> Net: FEC >>>> Hit any key to stop autoboot: 0 >>>> FEC Waiting for PHY auto negotiation to complete... done >>>> BOOTP broadcast 1 >>>> *** Unhandled DHCP Option in OFFER/ACK: 69 >>>> ... >>>> *** Unhandled DHCP Option in OFFER/ACK: 42 >>>> DHCP client bound to address 172.22.42.236 >>>> Using FEC device >>>> TFTP from server 172.22.42.240; our IP address is = 172.22.42.236 >>>> Filename '/wand/boot/ubldr'. >>>> Load address: 0x11000000 >>>> Loading: ############## >>>> 10.4 MiB/s >>>> done >>>> Bytes transferred =3D 195484 (2fb9c hex) >>>> ## Starting application at 0x11000054 ... >>>> Consoles: U-Boot console >>>> Compatible API signature found @8f564028 >>>> Number of U-Boot devices: 2 >>>>=20 >>>> FreeBSD/armv6 U-Boot loader, Revision 1.2 >>>> (ilepore@revolution.hippie.lan, Wed Feb 19 15:41:25 MST = 2014) >>>> DRAM: 2048MB >>>>=20 >>>> Device: disk >>>> - >>>> /boot/kernel/kernel text=3D0x42f3d0 data=3D0x31d14+0x2df1c >>> syms=3D[0x4+0x923b0+0x4+0x6e34d] >>>> Hit [Enter] to boot immediately, or any other key for = command prompt. >>>> Booting [/boot/kernel/kernel]... >>>> Using DTB compiled into kernel. >>>> Kernel entry at 0x12000100... >>>> Kernel args: (null) >>>> a >>>>=20 >>>> And it hangs there forever. The 'a' I just added, that shows me = that it >>>> gets into the kernel, I print that 'a' from the first few = instructions >>>> of locore.S. >>>=20 >>> Follow up on this... it is because I'm using a newer u-boot that has = the >>> dcache enabled by default. If I use the "dcache off" command to = disable >>> it, it boots perfectly every time. If I leave the cache enabled it >>> fails to boot most of the time with symptoms that pretty much = exactly >>> match stale data in the caches. >>>=20 >>> We enable the MMU in locore.S without invalidating old cache = contents >>> first, and that appears to be a bad thing. >>>=20 >>> -- Ian >>>=20 >>=20 >> Hm, I use an u-boot version from early December, which has already >> enabled the L1 Dcache. I did not experience any problems with that >> version. On Jan 29th code was committed to the u-boot repository to >> enable the L2 cache. I have not checked that version yet. >>=20 >> But without a Dcache invalidate, I had problems to start the second >> core. >=20 > I think it is the enabling of the L2 cache that's causing the problem, > because I added your code for invalidating L1 idcache to the first > processor startup path, and that didn't help. =20 >=20 > Flushing the L2 very early in startup is problematic, because we don't > know its register addresses until we can read the fdt data (we don't > even know what kind of l2 it is), and processing fdt while still = running > in physical address mode with only pc-relative addressing allowed is > more or less impossible. Do we have the tools to find out at least the kernel part of memory? We = know the PA and VA of kernel area, and symbols like start and end would = be enough to bound it, no? At least that would get us up and running to = the point where we can parse the FDT to get its data... Or is there = something more subtle afoot here.... Warner= From owner-freebsd-arm@FreeBSD.ORG Fri Feb 21 18:54:20 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C236A73 for ; Fri, 21 Feb 2014 18:54:20 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2D3CD10A9 for ; Fri, 21 Feb 2014 18:54:19 +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 1WGvEo-000Ewy-8g for freebsd-arm@FreeBSD.org; Fri, 21 Feb 2014 18:54:18 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s1LIsGi5033157 for ; Fri, 21 Feb 2014 11:54:16 -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+YQVF/Zd51S2mhKqHCoAFn Subject: wandboard / imx6 speed From: Ian Lepore To: freebsd-arm Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Feb 2014 11:54:15 -0700 Message-ID: <1393008855.1145.125.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 18:54:20 -0000 Just a progress update.... Building on the temperature sensor code written recently by Steve Lawrance, I commited changes for imx6 last night that run the processor at full speed as long as the temperature stays below the "throttle point", a configurable temperature that defaults to 10C below the max temp the chip can handle. (I haven't been able to get any of my boards over 55C yet, and the max temp is 95C on solo/dual and 105C on quad.) There are some new sysctls under dev.imx6_anatop.0 to show temperature and frequency. It's not clear that's where they'll always live in the sysctl mibs, other systems use dev.cpu.#. For imx6 these things aren't really per-cpu, there're per-SoC and maybe we need a dev.soc or hw.imx6 or something like that. dev.imx6_anatop.0.cpu_mhz: 984 dev.imx6_anatop.0.temperature: 38.5C dev.imx6_anatop.0.throttle_temperature: 95.0C To change the throttle_temperature, you have to specify a new value in deci-kelvins or add 'C' or 'F' as suffix to the number. The max cpu freq is taken from the OTP data burned into the chip. My wandboard dual doesn't have the right value, it comes up with 792 as the max speed, but the chip markings are the numbers for a 1Ghz part. It appears that Wanboard shipped some units without blowing the right speed fuses. I'm thinking of adding a sysctl/tuneable to override the OTP data to get around it (and to just generally allow for overclocking, because I'm an OC kind of guy at heart). -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Feb 21 19:13:38 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63BF4349 for ; Fri, 21 Feb 2014 19:13:38 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 35E931270 for ; Fri, 21 Feb 2014 19:13:37 +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 1WGvXV-0001rm-3d for freebsd-arm@FreeBSD.org; Fri, 21 Feb 2014 19:13:37 +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 s1LJDYP6033207 for ; Fri, 21 Feb 2014 12:13:34 -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/v0OIisON+byWdi+NFr0jS Subject: u-boot-2014.01 and freebsd arm From: Ian Lepore To: freebsd-arm Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Feb 2014 12:13:34 -0700 Message-ID: <1393010014.1145.137.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 19:13:38 -0000 Just an FYI, I've updated locally to u-boot version 2014.01 for my wandboards. It works fine without needing any patches except for the options you want to add/change in configs/wandboard.h, with one caveat: u-boot now enables the caches and our kernel startup code isn't coping well with that right now. I'm going to look into fixing that, but you can get around it for now by adding the CONFIG_SYS_DCACHE_OFF option or just putting "dcache flush;dcache off;" in your boot command in the u-boot env. I haven't tried the newer u-boot on my other boards yet (BBW, rpi). If anyone feels like doing a bit of work on u-boot, I think it would be great if we could get FFS support into u-boot so that we can boot from a disk image that doesn't need an msdos partition just to hold ubldr. There is a patchset for this that no longer applies cleanly (at least to 2014.01, I haven't tried earlier versions). It's available at http://www.springdaemons.com/stas/u-boot-ffs.patch if anyone wants to give it a shot. The work to be done is really two tasks: re-integrate the changes with the latest u-boot code, and then get the u-boot folks to incorporate those changes upstream. It doesn't have to be the same person tackling both problems, but the second part will be easier if the first part is done with an eye to making the changes "fit" in their world -- adopt their mechanisms and coding style as much as possible. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Feb 21 19:20:29 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E9736F7 for ; Fri, 21 Feb 2014 19:20:29 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 55BE312CB for ; Fri, 21 Feb 2014 19:20:28 +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 1WGve8-0006Vh-21; Fri, 21 Feb 2014 19:20:28 +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 s1LJKPm5033228; Fri, 21 Feb 2014 12:20:25 -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/Y1PN6CRJgztneAYLQfH+c Subject: Re: About FreeBSD support one more mini-pc From: Ian Lepore To: Warner Losh In-Reply-To: References: <210081392741053@web22h.yandex.ru> <1392835264.1145.33.camel@revolution.hippie.lan> <1392842988.1145.50.camel@revolution.hippie.lan> <1392851578.1145.55.camel@revolution.hippie.lan> <1392869044.1145.58.camel@revolution.hippie.lan> <38db362d34174f70a07c0b9ea39a54c4@e15be-03.zdv.Uni-Mainz.DE> <1392925514.1145.68.camel@revolution.hippie.lan> Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 21 Feb 2014 12:20:25 -0700 Message-ID: <1393010425.1145.143.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s1LJKPm5033228 Cc: "'freebsd-arm@freebsd.org'" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 19:20:29 -0000 On Fri, 2014-02-21 at 11:53 -0700, Warner Losh wrote: > On Feb 20, 2014, at 12:45 PM, Ian Lepore wrote: >=20 > > On Thu, 2014-02-20 at 19:08 +0000, Wei=DF, J=FCrgen wrote: > >>> -----Original Message----- > >>> From: owner-freebsd-arm@freebsd.org [mailto:owner-freebsd-arm@freeb= sd.org] On Behalf Of > >>> Ian Lepore > >>> Sent: Thursday, February 20, 2014 5:04 AM > >>> To: Tom Everett > >>> Cc: freebsd-arm@freebsd.org > >>> Subject: Re: About FreeBSD support one more mini-pc > >>>=20 > >>> On Wed, 2014-02-19 at 16:12 -0700, Ian Lepore wrote: > >>>> On Wed, 2014-02-19 at 15:12 -0700, Tom Everett wrote: > >>>>> Hey Ian, i am just about to ask for a pull from my repo with a wo= rking > >>>>> ubldr for wandboard, if you wanted to take a look: > >>>>>=20 > >>>>> https://github.com/teverett/crochet- > >>> freebsd/commit/f61660c4134ef495cb5f7de26c2048fba1e65c8f > >>>>>=20 > >>>>=20 > >>>> My problem isn't with u-boot, it's in the ubldr->kernel handoff. = I'm > >>>> using u-boot-2014.01 these days and it needs no patching other tha= n to > >>>> the wandboard config.h to turn on API and USB and a few other hand= y > >>>> things. But when I boot, sometimes it works but more often it goe= s like > >>>> this: > >>>>=20 > [...]=20 > >>>> And it hangs there forever. The 'a' I just added, that shows me t= hat it > >>>> gets into the kernel, I print that 'a' from the first few instruct= ions > >>>> of locore.S. > >>>=20 > >>> Follow up on this... it is because I'm using a newer u-boot that ha= s the > >>> dcache enabled by default. If I use the "dcache off" command to di= sable > >>> it, it boots perfectly every time. If I leave the cache enabled it > >>> fails to boot most of the time with symptoms that pretty much exact= ly > >>> match stale data in the caches. > >>>=20 > >>> We enable the MMU in locore.S without invalidating old cache conten= ts > >>> first, and that appears to be a bad thing. > >>>=20 > >>> -- Ian > >>>=20 > >>=20 > >> Hm, I use an u-boot version from early December, which has already > >> enabled the L1 Dcache. I did not experience any problems with that > >> version. On Jan 29th code was committed to the u-boot repository to > >> enable the L2 cache. I have not checked that version yet. > >>=20 > >> But without a Dcache invalidate, I had problems to start the second > >> core. > >=20 > > I think it is the enabling of the L2 cache that's causing the problem= , > > because I added your code for invalidating L1 idcache to the first > > processor startup path, and that didn't help. =20 > >=20 > > Flushing the L2 very early in startup is problematic, because we don'= t > > know its register addresses until we can read the fdt data (we don't > > even know what kind of l2 it is), and processing fdt while still runn= ing > > in physical address mode with only pc-relative addressing allowed is > > more or less impossible. >=20 > Do we have the tools to find out at least the kernel part of memory? We= know the PA and VA of kernel area, and symbols like start and end would = be enough to bound it, no? At least that would get us up and running to t= he point where we can parse the FDT to get its data... Or is there someth= ing more subtle afoot here.... The problem is that until the MMU is turned on we can't access normal data, bss, or even call a named function. You can only run position- independant code, and that doesn't mean PLT and GOT stuff, it means you can only get the address of something as an offset from the current PC. The FDT code isn't amenable to running like that. However, I think the suggestion offered by Juergen is a good one: if the MMU is on at entry, then our locore.S code needs to treat it as a mapping (set ttb) change and do the cache maintenance sequences you would do for that, as opposed to the sequences required to turn it on for the first time. Hopefully that's all that's needed and the L2 cache isn't involved in the problem. I'm going to give that a try this weekend. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Feb 21 23:40:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32D7F6FA; Fri, 21 Feb 2014 23:40:41 +0000 (UTC) Received: from mailgate-02.zdv.uni-mainz.de (mailgate-02.zdv.Uni-Mainz.DE [IPv6:2001:4c80:40:62d:203:ffff:fe5d:b2f6]) by mx1.freebsd.org (Postfix) with ESMTP id 82D1C1A43; Fri, 21 Feb 2014 23:40:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-mainz.de; i=@uni-mainz.de; q=dns/txt; s=ironport; t=1393026041; x=1424562041; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=21Skx9xIqtIN6zm3enSIoeWsZn+oDKUtfCoM+eck4TE=; b=NOtCi8BgrOk3nATt9QJ9zj/x3IuiW6uu3re7CzdCKrwBFt9g6ljz/N59 EmrEVRWSEyJ7u5fAiW4pJ3v8ddnpX++0KX29RPU94/GLh8IDnY1weBwq5 sEXBCu7rarQIczmWKJjRkFPuFMpxNaRoC3ExDURJcbOZVQ4pBDuTQFLv5 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEALHiB1MKXgZY/2dsb2JhbABagmWBM8BDgSF0giUBAQQBeRACAQhGMiUCBAENBQiHdQgBy04XjmQHhDgEiRCVZ4tkgy2CKg X-IPAS-Result: AqEEALHiB1MKXgZY/2dsb2JhbABagmWBM8BDgSF0giUBAQQBeRACAQhGMiUCBAENBQiHdQgBy04XjmQHhDgEiRCVZ4tkgy2CKg Received: from e14hub-02.zdv.uni-mainz.de ([10.94.6.88]) by mailgate-02.zdv.uni-mainz.de with ESMTP; 22 Feb 2014 00:40:38 +0100 Received: from e15be-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9090) by E14HUB-02.zdv.Uni-Mainz.DE (2001:4c80:40:606:21d:d8ff:feb7:1c60) with Microsoft SMTP Server (TLS) id 14.3.174.1; Sat, 22 Feb 2014 00:39:43 +0100 Received: from e15be-03.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9238) by e15be-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9090) with Microsoft SMTP Server (TLS) id 15.0.775.38; Sat, 22 Feb 2014 00:39:42 +0100 Received: from e15be-03.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9238]) by e15be-03.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9238%18]) with mapi id 15.00.0775.031; Sat, 22 Feb 2014 00:39:42 +0100 From: =?iso-8859-1?B?V2Vp3ywgSvxyZ2Vu?= To: 'Ian Lepore' , 'Warner Losh' Subject: RE: About FreeBSD support one more mini-pc Thread-Topic: About FreeBSD support one more mini-pc Thread-Index: AQHPLMx2lO8+uVBB/02TkpGpjfhkM5q82ewAgAAfLwCAAAI1AIAAApQAgAAW/YCAABEDAIAAUVUAgAEJdPD///2CAIABg/WAgAAHcYCAADK9sA== Date: Fri, 21 Feb 2014 23:39:41 +0000 Message-ID: References: <210081392741053@web22h.yandex.ru> <1392835264.1145.33.camel@revolution.hippie.lan> <1392842988.1145.50.camel@revolution.hippie.lan> <1392851578.1145.55.camel@revolution.hippie.lan> <1392869044.1145.58.camel@revolution.hippie.lan> <38db362d34174f70a07c0b9ea39a54c4@e15be-03.zdv.Uni-Mainz.DE> <1392925514.1145.68.camel@revolution.hippie.lan> <1393010425.1145.143.camel@revolution.hippie.lan> In-Reply-To: <1393010425.1145.143.camel@revolution.hippie.lan> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.93.178.81] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'freebsd-arm@freebsd.org'" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 23:40:41 -0000 >=20 > The problem is that until the MMU is turned on we can't access normal > data, bss, or even call a named function. You can only run position- > independant code, and that doesn't mean PLT and GOT stuff, it means you > can only get the address of something as an offset from the current PC. > The FDT code isn't amenable to running like that. >=20 > However, I think the suggestion offered by Juergen is a good one: if > the MMU is on at entry, then our locore.S code needs to treat it as a > mapping (set ttb) change and do the cache maintenance sequences you > would do for that, as opposed to the sequences required to turn it on > for the first time. Hopefully that's all that's needed and the L2 cache > isn't involved in the problem. I'm going to give that a try this > weekend. >=20 After some reseach, I at least understand, why I can boot FreeBSD with ubldr without any problems. I thought that the temperatures in my living room cannot be responsible for this. I use mkimage to generate an uImage from ubldr. And the bootm command=20 of u-boot, when booting an uImage disables and flushes all the L1 caches ..= ....=20 Juergen Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-2= 6407 From owner-freebsd-arm@FreeBSD.ORG Sat Feb 22 00:06:32 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F367A1D for ; Sat, 22 Feb 2014 00:06:32 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2680B1C2B for ; Sat, 22 Feb 2014 00:06:31 +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 1WH06r-0008lm-1q; Sat, 22 Feb 2014 00:06:25 +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 s1M06MCn033485; Fri, 21 Feb 2014 17:06:22 -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: U2FsdGVkX19CyIOOCIVIndjn6Phgm8tA Subject: RE: About FreeBSD support one more mini-pc From: Ian Lepore To: =?ISO-8859-1?Q?Wei=DF=2C_J=FCrgen?= In-Reply-To: References: <210081392741053@web22h.yandex.ru> <1392835264.1145.33.camel@revolution.hippie.lan> <1392842988.1145.50.camel@revolution.hippie.lan> <1392851578.1145.55.camel@revolution.hippie.lan> <1392869044.1145.58.camel@revolution.hippie.lan> <38db362d34174f70a07c0b9ea39a54c4@e15be-03.zdv.Uni-Mainz.DE> <1392925514.1145.68.camel@revolution.hippie.lan> <1393010425.1145.143.camel@revolution.hippie.lan> Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 21 Feb 2014 17:06:22 -0700 Message-ID: <1393027582.1149.6.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s1M06MCn033485 Cc: "'freebsd-arm@freebsd.org'" , 'Warner Losh' X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 00:06:32 -0000 On Fri, 2014-02-21 at 23:39 +0000, Wei=DF, J=FCrgen wrote: > >=20 > > The problem is that until the MMU is turned on we can't access normal > > data, bss, or even call a named function. You can only run position- > > independant code, and that doesn't mean PLT and GOT stuff, it means y= ou > > can only get the address of something as an offset from the current P= C. > > The FDT code isn't amenable to running like that. > >=20 > > However, I think the suggestion offered by Juergen is a good one: if > > the MMU is on at entry, then our locore.S code needs to treat it as a > > mapping (set ttb) change and do the cache maintenance sequences you > > would do for that, as opposed to the sequences required to turn it on > > for the first time. Hopefully that's all that's needed and the L2 ca= che > > isn't involved in the problem. I'm going to give that a try this > > weekend. > >=20 >=20 > After some reseach, I at least understand, why I can boot FreeBSD with > ubldr without any problems. I thought that the temperatures in my livin= g > room cannot be responsible for this. >=20 The temperature problem had nothing to do with ubldr. That problem first showed last summer and affected all cortex-a9 chips because of a code generation bug in the assembler (they called it a feature, but I say it was a bug). > I use mkimage to generate an uImage from ubldr. And the bootm command=20 > of u-boot, when booting an uImage disables and flushes all the L1 cache= s ......=20 So the type of file being loaded affects u-boot's behavior. It's like they're just making it up as they go. :) I think we may be close to where we can switch to having a single generic IMX6 kernel config and let the fdt data be handled by u-boot and ubldr. I'll play with that this evening and see how it goes. Oh, something I never mentioned... the freebsd arm kernel can now be loaded at any 1MB boundary in physical ram, it doesn't have to be the KERNPHYSADDR address it was compiled for. For now, ubldr still only knows how to load it at the address it was loaded for, but from u-boot you should be able to load it at any address and launch it with "go addr +100" (except I don't think u-boot actually lets you do inline expressions like that). -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Feb 22 01:42:31 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4124F6E6 for ; Sat, 22 Feb 2014 01:42:31 +0000 (UTC) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 077A71558 for ; Sat, 22 Feb 2014 01:42:30 +0000 (UTC) Received: by mail-ig0-f182.google.com with SMTP id uy17so867936igb.3 for ; Fri, 21 Feb 2014 17:42:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=iZfgemVnyfOAG3M967ANnb/sXZ5sHEVPYhJeesx8DPs=; b=PSZs8eoVGjf4VOmkJLdmSVNeOdg1DYmp9viPcD5nTnMphTQAhBmjuZxXj5WKVLkzx0 B3l+se7jSfV0NhRJzi/Ze4SDB/36uZRpeu+/ejsJgctetiYqhIYXWCeNoHQb8qekvz33 MHZEkybWo7aHYHIsGuR1NbA7YahDX8XjRQ4fBttm1gk0CilwVt+hoZ1FkDZY9vvZSlGh 1S+uADYsSTyjbShk+a4lyC+Ft/b9YPnliV9myWWaLNyPXLXr63Drb6A3krnctT3VvC0B Uo6AysTi6NxU0nLtjFD0KZV0RqIVk3ZC8wVpSQcoHsjoDYHgDGI3ZzqRXpuinE3W8/dm X2Og== X-Gm-Message-State: ALoCoQmx9pqwspdhzO4Ceblk2q7Q+/oXJhlTQZUlz1u3Pw/fo47LkME2N/fZnk0xfKX5e+MnU518 X-Received: by 10.43.52.65 with SMTP id vl1mr5013361icb.86.1393033344687; Fri, 21 Feb 2014 17:42:24 -0800 (PST) Received: from macmini.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id r6sm490361igg.10.2014.02.21.17.42.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 17:42:24 -0800 (PST) Subject: Re: svn commit: r262244 - head/sys/arm/freescale/imx Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201402201429.s1KETxk3090247@svn.freebsd.org> Date: Fri, 21 Feb 2014 18:42:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201402201429.s1KETxk3090247@svn.freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.1085) Cc: arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 01:42:31 -0000 On Feb 20, 2014, at 7:29 AM, Ian Lepore wrote: > + * Resist the temptation to change the #if 0 to #ifdef EARLY_PRINTF = here. It > + * makes sense now, but if multiple SOCs do that it will make = early_putc another > + * duplicate symbol to be eliminated on the path to a generic kernel. > + */ > +#if 0=20 > +static void=20 > +imx6_early_putc(int c) > +{ > + volatile uint32_t * UART_STAT_REG =3D (uint32_t *)0x02020098; > + volatile uint32_t * UART_TX_REG =3D (uint32_t *)0x02020040; > + const uint32_t UART_TXRDY =3D (1 << 3); > + > + while ((*UART_STAT_REG & UART_TXRDY) =3D=3D 0) > + continue; > + *UART_TX_REG =3D c; > +} > +early_putc_t *early_putc =3D imx6_early_putc; > +#endif I'm starting to think we should have code like this in a platform board = specific file that's matched based on the top-level compatible = strings... Doing this is like 8th on my list right now... Warner From owner-freebsd-arm@FreeBSD.ORG Sat Feb 22 11:24:31 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF0EC638; Sat, 22 Feb 2014 11:24:31 +0000 (UTC) Received: from mailgate-02.zdv.uni-mainz.de (mailgate-02.zdv.Uni-Mainz.DE [IPv6:2001:4c80:40:62d:203:ffff:fe5d:b2f6]) by mx1.freebsd.org (Postfix) with ESMTP id BD9031D46; Sat, 22 Feb 2014 11:24:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-mainz.de; i=@uni-mainz.de; q=dns/txt; s=ironport; t=1393068271; x=1424604271; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=F5zi11snfzPA/GOmQc2PUNcElW4+79TiA8pd3uMqdxE=; b=SZ8AYybEG9+fTAVWLn8sYp/ULLcNZ2T+4Vpt7G8p/BuNiKudRpRomDY1 g4k3cVrG+vfbgJMol8rWCELcdEnwGiuJ44udoV2Kx4Vbi6KShr9o+4wFu qFKF/1EuU/7BdlyhATaIxi0d2A7Zz2BxFpkU/WNEpy+qb3dLslylSy+Do w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAJ+ICFMKXgZY/2dsb2JhbABagmWBM8BJgSB0giYBBXkQAgEIRjIlAgQKBAUIh30BygcXjmQHhDgEiRCFMZA2i2SDLYIq X-IPAS-Result: AqAEAJ+ICFMKXgZY/2dsb2JhbABagmWBM8BJgSB0giYBBXkQAgEIRjIlAgQKBAUIh30BygcXjmQHhDgEiRCFMZA2i2SDLYIq Received: from e14hub-02.zdv.uni-mainz.de ([10.94.6.88]) by mailgate-02.zdv.uni-mainz.de with ESMTP; 22 Feb 2014 12:24:19 +0100 Received: from e15be-02.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:8fb0) by E14HUB-02.zdv.Uni-Mainz.DE (2001:4c80:40:606:21d:d8ff:feb7:1c60) with Microsoft SMTP Server (TLS) id 14.3.174.1; Sat, 22 Feb 2014 12:23:25 +0100 Received: from e15be-03.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9238) by e15be-02.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:8fb0) with Microsoft SMTP Server (TLS) id 15.0.775.38; Sat, 22 Feb 2014 12:23:24 +0100 Received: from e15be-03.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9238]) by e15be-03.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9238%18]) with mapi id 15.00.0775.031; Sat, 22 Feb 2014 12:23:24 +0100 From: =?iso-8859-1?B?V2Vp3ywgSvxyZ2Vu?= To: 'Ian Lepore' Subject: RE: About FreeBSD support one more mini-pc Thread-Topic: About FreeBSD support one more mini-pc Thread-Index: AQHPLMx2lO8+uVBB/02TkpGpjfhkM5q82ewAgAAfLwCAAAI1AIAAApQAgAAW/YCAABEDAIAAUVUAgAEJdPD///2CAIABg/WAgAAHcYCAADK9sIAAHScAgADDWVA= Date: Sat, 22 Feb 2014 11:23:23 +0000 Message-ID: <4c23a9bb88a6471c87fe9b0d0eba84df@e15be-03.zdv.Uni-Mainz.DE> References: <210081392741053@web22h.yandex.ru> <1392835264.1145.33.camel@revolution.hippie.lan> <1392842988.1145.50.camel@revolution.hippie.lan> <1392851578.1145.55.camel@revolution.hippie.lan> <1392869044.1145.58.camel@revolution.hippie.lan> <38db362d34174f70a07c0b9ea39a54c4@e15be-03.zdv.Uni-Mainz.DE> <1392925514.1145.68.camel@revolution.hippie.lan> <1393010425.1145.143.camel@revolution.hippie.lan> <1393027582.1149.6.camel@revolution.hippie.lan> In-Reply-To: <1393027582.1149.6.camel@revolution.hippie.lan> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.93.178.81] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'freebsd-arm@freebsd.org'" , 'Warner Losh' X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 11:24:31 -0000 I just updated u-boot sources and added CONFIG_CMD_ELF. I used unmodified ubldr and unmodified FreeBSD WANDBOARD-DUAL. bootelf disables L1 dcache as well. U-Boot 2014.01-14265-g0881289-dirty (Feb 22 2014 - 10:38:34) CPU: Freescale i.MX6DL rev1.1 at 792 MHz Reset cause: POR Board: Wandboard DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 MMC: no card present MMC init failed Using default environment In: serial Out: serial Err: serial Net: FEC [PRIME] USB: USB0: lowlevel init failed USB1: USB EHCI 1.00 scanning bus 1 for devices... 2 USB Device(s) found Hit any key to stop autoboot: 0=20 =3D> dhcp BOOTP broadcast 1 *** Unhandled DHCP Option in OFFER/ACK: 42 *** Unhandled DHCP Option in OFFER/ACK: 42 DHCP client bound to address 192.168.11.2 Using FEC device TFTP from server 192.168.11.254; our IP address is 192.168.11.2 Filename 'uImage'. Load address: 0x12000000 Loading: ################# 7.7 MiB/s done Bytes transferred =3D 241128 (3ade8 hex) =3D> dcache Data (writethrough) Cache is ON =3D> bootelf ## Starting application at 0x10100054 ... Consoles: U-Boot console =20 Compatible API signature found @4f55f708 MMC: no card present MMC: no card present Number of U-Boot devices: 1 FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@freebsd-src.zdv.Uni-Mainz.DE, Mon Feb 17 23:42:21 CET 2014) DRAM: 1024MB Device: net Loading /boot/defaults/loader.conf=20 /boot/kernel/kernel data=3D0x4cca48+0x2f5b8 syms=3D[0x4+0x7d7f0+0x4+0x4d862= ] | Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 Using DTB from loaded file. Kernel entry at 0x12000100... Kernel args: (null) KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r262310+5331843(master): Sat Feb 22 00:04:22 CET 20= 14 root@freebsd-src.zdv.Uni-Mainz.DE:/usr/obj/arm.armv6/s/export/freebsd-g= it/freebsd/sys/WANDBOARD-DUAL arm I finally downloaded ubldr and used go to start the image. Now the FreeBSD kernel fails to boot! =3D> dhcp 0x10100000 BOOTP broadcast 1 *** Unhandled DHCP Option in OFFER/ACK: 42 *** Unhandled DHCP Option in OFFER/ACK: 42 DHCP client bound to address 192.168.11.2 Using FEC device TFTP from server 192.168.11.254; our IP address is 192.168.11.2 Filename 'uImage'. Load address: 0x10100000 Loading: ################# 7.7 MiB/s done Bytes transferred =3D 241128 (3ade8 hex) =3D> go 0x10100054 ## Starting application at 0x10100054 ... Consoles: U-Boot console =20 Compatible API signature found @4f55f708 MMC: no card present MMC: no card present Number of U-Boot devices: 1 FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@freebsd-src.zdv.Uni-Mainz.DE, Mon Feb 17 23:42:21 CET 2014) DRAM: 1024MB Device: net - /boot/kernel/kernel data=3D0x4cca48+0x2f5b8 syms=3D[0x4+0x7d7f0+0x4+0x4d862= ] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 Using DTB compiled into kernel. Kernel entry at 0x12000100... Kernel args: (null) Regards Juergen Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-2= 6407 From owner-freebsd-arm@FreeBSD.ORG Sat Feb 22 16:02:08 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5921949; Sat, 22 Feb 2014 16:02:08 +0000 (UTC) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6D4D313D8; Sat, 22 Feb 2014 16:02:07 +0000 (UTC) Received: from srg.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) by ns.kevlo.org (8.14.8/8.14.8) with ESMTP id s1MG1jS8071318 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 23 Feb 2014 00:01:45 +0800 (CST) (envelope-from kevlo@FreeBSD.org) Message-ID: <5308C9F7.5090300@FreeBSD.org> Date: Sun, 23 Feb 2014 00:01:59 +0800 From: Kevin Lo User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: u-boot-2014.01 and freebsd arm References: <1393010014.1145.137.camel@revolution.hippie.lan> In-Reply-To: <1393010014.1145.137.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 16:02:08 -0000 On 2014/02/22 03:13, Ian Lepore wrote: > Just an FYI, I've updated locally to u-boot version 2014.01 for my > wandboards. It works fine without needing any patches except for the > options you want to add/change in configs/wandboard.h, with one caveat: > u-boot now enables the caches and our kernel startup code isn't coping > well with that right now. I'm going to look into fixing that, but you > can get around it for now by adding the CONFIG_SYS_DCACHE_OFF option or > just putting "dcache flush;dcache off;" in your boot command in the > u-boot env. > > I haven't tried the newer u-boot on my other boards yet (BBW, rpi). > > If anyone feels like doing a bit of work on u-boot, I think it would be > great if we could get FFS support into u-boot so that we can boot from a > disk image that doesn't need an msdos partition just to hold ubldr. > There is a patchset for this that no longer applies cleanly (at least to > 2014.01, I haven't tried earlier versions). It's available at > http://www.springdaemons.com/stas/u-boot-ffs.patch if anyone wants to > give it a shot. > > The work to be done is really two tasks: re-integrate the changes with > the latest u-boot code, and then get the u-boot folks to incorporate > those changes upstream. It doesn't have to be the same person tackling > both problems, but the second part will be easier if the first part is > done with an eye to making the changes "fit" in their world -- adopt > their mechanisms and coding style as much as possible. It seems that there is a license issue preventing integration of UFS support into U-Boot's source. See all discussion threads: http://marc.info/?t=127792848100003&r=1&w=2 > > -- Ian Kevin From owner-freebsd-arm@FreeBSD.ORG Sat Feb 22 21:14:01 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5726BCAC for ; Sat, 22 Feb 2014 21:14:01 +0000 (UTC) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by mx1.freebsd.org (Postfix) with ESMTP id 1BC951D28 for ; Sat, 22 Feb 2014 21:14:00 +0000 (UTC) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2104.sfr.fr (SMTP Server) with ESMTP id 40ABF7000138 for ; Sat, 22 Feb 2014 22:06:02 +0100 (CET) Received: from e330 (91.168.102.84.rev.sfr.net [84.102.168.91]) by msfrf2104.sfr.fr (SMTP Server) with ESMTP id 06E1A70000FC for ; Sat, 22 Feb 2014 22:06:01 +0100 (CET) X-SFR-UUID: 20140222210602283.06E1A70000FC@msfrf2104.sfr.fr Date: Sat, 22 Feb 2014 22:06:01 +0100 From: francesco scaglione To: freebsd-arm@freebsd.org Subject: Raspberry Pi ssh login Message-ID: <20140222210601.GA6201@e330> Mail-Followup-To: freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mutt/1.5.21 (2010-09-15) Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 21:14:01 -0000 I've downloaded an image from here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/10.0/ copied it on my SD card and booted the Raspberry Pi. Now, since the machine is headless, I'm trying to login through ssh from another computer, as "pi" or as "root", but without success. Is there a default password? Thank you very much, Francesco From owner-freebsd-arm@FreeBSD.ORG Sat Feb 22 21:30:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2CC82F06 for ; Sat, 22 Feb 2014 21:30:12 +0000 (UTC) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E99D41E08 for ; Sat, 22 Feb 2014 21:30:11 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id i4so5656654oah.11 for ; Sat, 22 Feb 2014 13:30:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=pYUKzrpQQ2t05SLE4uRQ+u3khY9Uo+lz23CyEkHVAXk=; b=Z+sHjDwzzOef+LahkmGHKYPdVNTjKnnrj+jUZr97hNSzOzZdTzql1fcE8jdOnhnovx UWi+A/xO+8XuybYUobBgH+jR7hm8ShMYsgbjo6cBYA1qxyRrRdZZtUIxGLU8TomYZQfF tEQuX2ZLwdqaWZww6BjQ6GiGejdRDB0aZg4LxMo2nfM7tn2io+z8VIv8HHHBwBeQiQhX 43pZQNeJaGr0Ur+7W6EsT63PAKlEnsd/MlBWLfbFCbPCx6XgIxzzqMNAuknQM5BY8177 zQGtut+lbUam05S8YTNvzt72yx7HijM6aIr9uvHkphtpICL/amLsS+foDY39Q93HHxPx RGsw== X-Gm-Message-State: ALoCoQlQ63GH+fPZIGMkeb/LgNIW0v/JAOZpl5POaSeVCXkgcxscTN+S2/ve/Y7CHMhpfkOLBSUZ MIME-Version: 1.0 X-Received: by 10.60.84.143 with SMTP id z15mr15715379oey.27.1393104605047; Sat, 22 Feb 2014 13:30:05 -0800 (PST) Received: by 10.182.104.169 with HTTP; Sat, 22 Feb 2014 13:30:04 -0800 (PST) In-Reply-To: <20140222210601.GA6201@e330> References: <20140222210601.GA6201@e330> Date: Sat, 22 Feb 2014 14:30:04 -0700 Message-ID: Subject: Re: Raspberry Pi ssh login From: Tom Everett To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 21:30:12 -0000 If I recall correctly, the root login on FreeBSD can't ssh in, so "root" is not an option. You might try making a serial connection to the pi, and creating yourself an account that can ssh in. On Sat, Feb 22, 2014 at 2:06 PM, francesco scaglione < francesco.scaglione@sfr.fr> wrote: > I've downloaded an image from here: > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/10.0/ > > copied it on my SD card and booted the Raspberry Pi. Now, since the > machine is headless, I'm trying to login through ssh from another > computer, as "pi" or as "root", but without success. Is there a > default password? > > Thank you very much, > Francesco > > _______________________________________________ > 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" > -- A better world shall emerge based on faith and understanding - Douglas MacArthur