From owner-freebsd-embedded@FreeBSD.ORG Sun Oct 12 21:06:51 2008 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C53551065689 for ; Sun, 12 Oct 2008 21:06:51 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id 773058FC0A for ; Sun, 12 Oct 2008 21:06:51 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from [85.21.245.235] (helo=orion.SpringDaemons.com) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1Kp89I-0003Uh-1P; Mon, 13 Oct 2008 01:06:48 +0400 Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 10F48398F1; Mon, 13 Oct 2008 01:07:23 +0400 (MSD) Date: Mon, 13 Oct 2008 01:07:23 +0400 From: Stanislav Sedov To: "Bruce M. Simpson" Message-Id: <20081013010723.cce11b21.stas@FreeBSD.org> In-Reply-To: <48F099D4.2050302@incunabulum.net> References: <48F099D4.2050302@incunabulum.net> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Mon__13_Oct_2008_01_07_23_+0400_i5BgizE7z88p7wxm" Cc: freebsd-embedded@FreeBSD.org Subject: Re: HOWTO: Build NSLU2 U-Boot on FreeBSD X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2008 21:06:51 -0000 --Signature=_Mon__13_Oct_2008_01_07_23_+0400_i5BgizE7z88p7wxm Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, 11 Oct 2008 13:19:32 +0100 "Bruce M. Simpson" mentioned: > Get stas@FreeBSD.org's updated u-boot tarball: > uboot-atamantb.tar.bz2 > Untar it I've extracted the build specific part of my patch abd placed it here: http://www.SpringDaemons.com/stas/uboot.patch With this patch upplied u-boot 1.3.3 should be happily buildable with devel/arm-rtems-gcc. Let me know if it is not. --=20 Stanislav Sedov ST4096-RIPE --Signature=_Mon__13_Oct_2008_01_07_23_+0400_i5BgizE7z88p7wxm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjyZwsACgkQK/VZk+smlYFcxgCfYStsLQOgPaXZkjbC3SFE39sL 6MYAn0QvxMH3OCl1W1P3QV4hG8W0jOgA =4Olx -----END PGP SIGNATURE----- --Signature=_Mon__13_Oct_2008_01_07_23_+0400_i5BgizE7z88p7wxm-- From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 13 06:26:26 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 565641065695 for ; Mon, 13 Oct 2008 06:26:26 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 2EB088FC14 for ; Mon, 13 Oct 2008 06:26:26 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 7A97117850D; Mon, 13 Oct 2008 02:26:25 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 13 Oct 2008 02:26:25 -0400 X-Sasl-enc: U3zkgyO6Hvt02QcJXFvLbzdl0Lnv0SuWyYRnhV3C2ymk 1223879185 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id EB9C613A9E; Mon, 13 Oct 2008 02:26:24 -0400 (EDT) Message-ID: <48F2EA0D.9080502@incunabulum.net> Date: Mon, 13 Oct 2008 07:26:21 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: "M. Warner Losh" References: <48ECF8F5.8090805@incunabulum.net> <20081008.150716.570083949.imp@bsdimp.com> In-Reply-To: <20081008.150716.570083949.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-embedded@freebsd.org Subject: Re: Broadcom MIPS kernel bit-rot X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 06:26:26 -0000 M. Warner Losh wrote: > I think this may be a change in the SGI style ELF binaries to a > Traditional SYS V style that we did before we imported the code, but > after you did the original work on the sentry... > I've committed a fix to SVN now. It seems that the required fix was to enforce the order of the ELF program segments using a GNU ld PHDRS config section. I also minimized the diff with the existing ldscript.mips file. At the same time I fixed the dynamic hash load -- it turns out CFE will not load PT_DYNAMIC segments, however it will blindly load PT_LOAD segments containing dynamic ELF sections. Now we get symbol lookup in backtraces, however it also seems DDB isn't always smart enough to find the nearest symbol. From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 13 07:51:30 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E06B1065697 for ; Mon, 13 Oct 2008 07:51:30 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 165C68FC17 for ; Mon, 13 Oct 2008 07:51:30 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 849B3177D8E for ; Mon, 13 Oct 2008 03:51:29 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 13 Oct 2008 03:51:29 -0400 X-Sasl-enc: jC/oiLKI83ncUuAwdyKg8iM8MH6BGzZps/3APqVCuEJ4 1223884289 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 0B4DC2B434 for ; Mon, 13 Oct 2008 03:51:28 -0400 (EDT) Message-ID: <48F2FDFF.7020109@incunabulum.net> Date: Mon, 13 Oct 2008 08:51:27 +0100 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: freebsd-embedded@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Possible i2c driver problem w/NSLU2 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 07:51:30 -0000 Hi, Posting here to make sure this info doesn't get lost. The diff I posted to this list for FSG3 support contained an x1260rtc driver. It appears not all FSG3 units have this RTC chip, however, the NSLU2 certainly has the x1205 wihch should be register-level compatible. However I haven't seen the driver working yet. The hardwired hint may well be incorrect, according to posts on nslu2-linux.org, it's meant to be at 0x6f. This post on the NetBSD port-arm list suggests they needed to patch the machine-independent i2c driver there to get things working on the NSLU2: http://mail-index.netbsd.org/port-arm/2008/06/06/msg000240.html cheers BMS From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 13 11:06:47 2008 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD5611065688 for ; Mon, 13 Oct 2008 11:06:47 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B90208FC0A for ; Mon, 13 Oct 2008 11:06:47 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id m9DB6lWM029385 for ; Mon, 13 Oct 2008 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id m9DB6lGC029381 for freebsd-embedded@FreeBSD.org; Mon, 13 Oct 2008 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 13 Oct 2008 11:06:47 GMT Message-Id: <200810131106.m9DB6lGC029381@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-embedded@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 11:06:47 -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 kern/101228 embedded [nanobsd] [patch] Two more entries for FlashDevice.sub o misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c o misc/15876 embedded [picobsd] PicoBSD message of the day problems 4 problems total. From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 13 18:12:14 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CB401065689 for ; Mon, 13 Oct 2008 18:12:14 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 21FAC8FC24 for ; Mon, 13 Oct 2008 18:12:14 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 97DDA178EEA for ; Mon, 13 Oct 2008 14:12:13 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 13 Oct 2008 14:12:13 -0400 X-Sasl-enc: 1Uw0XxDuO/8l6TTx6/uwkZ7hrRx8wVchlNUZlVZfvR2X 1223921532 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 51C532BA39 for ; Mon, 13 Oct 2008 14:12:12 -0400 (EDT) Message-ID: <48F38F7A.8000902@incunabulum.net> Date: Mon, 13 Oct 2008 19:12:10 +0100 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: freebsd-embedded@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/mixed; boundary="------------050603050405090201050903" Subject: [PATCH] Probe and attach bfe(4) on WGT634U X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 18:12:14 -0000 This is a multi-part message in MIME format. --------------050603050405090201050903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Here is a patch (against -CURRENT in SVN) which gets bfe(4) to probe and attach to the on-board EMAC core on the Netgear WGT634U. Note that it doesn't currently work -- there appears to be an interrupt routing problem -- however the fact that we are able to read the PHY registers suggests we are firmly on the right track. This PHY is in fact the "roboswitch"; there are additional registers in the PHY space which control VLAN filtering, etc which the bmphy(4) driver doesn't handle. If you comment out the BOOTP directives in the SENTRY5 config, you'll see that it will attempt to network boot, however no packets actually leave the interface and the BOOTP appears to stall. The documentation states that MIPS hardware interrupt 1 is used for the EMAC core, however, lots of "stray hard interrupt 2" messages suggests it's using 2. I'm not sure if the interrupt routing is working properly -- simply using 2 doesn't solve the problem. The uart really needs to be made to work in native mode -- at the moment, the CFE firmware console driver is used, and this doesn't appear to support interrupt-driven I/O -- and as such, it isn't possible to break into DDB using the ALT_BREAK_TO_DEBUGGER sequence. cheers BMS --------------050603050405090201050903 Content-Type: text/plain; name="bfe-siba.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bfe-siba.diff" Index: mips/conf/SENTRY5 =================================================================== --- mips/conf/SENTRY5 (revision 183816) +++ mips/conf/SENTRY5 (working copy) @@ -21,9 +21,11 @@ # # * The Broadcom CPUs have no FPU. Attempting to detect one by reading CP1's # status register causes an unhandled boot-time exception. An FPU emulator -# will be necessary to support multi-user boot. +# will be necessary to support multi-user boot (or build with -msoft-float). # +# XXX This gets to mountroot w/o bfe or pci in, but that is useless. + machine mips ident SENTRY5 cpu CPU_MIPS4KC @@ -36,27 +38,27 @@ # bus enumeration there files "../sentry5/files.sentry5" hints "SENTRY5.hints" +env "SENTRY5.env" -# sentry5 normally ships with cfe firmware; use the console for now -options CFE -options CFE_CONSOLE -options ALT_BREAK_TO_DEBUGGER - -# cfe loader expects kernel at 0x80001000 for mips32 w/o backwards -# offsets in the linked elf image (see ldscript hack) -# XXX can we conditionalize the linker stuff on options CFE? -options KERNVIRTADDR=0x80001000 - -makeoptions LDSCRIPT_NAME= ldscript.mips.cfe - #makeoptions ARCH_FLAGS=-march=mips32 makeoptions MIPS_LITTLE_ENDIAN=defined makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols makeoptions MODULES_OVERRIDE="" +makeoptions LDSCRIPT_NAME= ldscript.mips.cfe options DDB options KDB +options ALT_BREAK_TO_DEBUGGER +options KTR +options KTR_VERBOSE +options KTR_MASK=KTR_BUSDMA + +# Use the CFE console for now. +# It defaults to uart1 on the wgt634u, so won't clash with uart0. +options CFE +options CFE_CONSOLE + options SCHED_4BSD #4BSD scheduler options INET #InterNETworking options NFSCLIENT #Network Filesystem Client @@ -64,35 +66,55 @@ options PSEUDOFS #Pseudo-filesystem framework options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions +options MUTEX_NOINLINE #Mutex inlines are space hogs +options RWLOCK_NOINLINE #rwlock inlines are space hogs +options SX_NOINLINE #sx inliens are space hogs + +# XXX Until we can get disk drivers to attach above, +# we will need to attempt network boot. +# XXX stray hard interrupt 2... +# bfe interrupt handling ain't right, temporary reroute +# manual path applied, need to get to nitty gritty of how +# interrupt routing works on the siba. +#options BOOTP +#options BOOTP_NFSROOT +#options BOOTP_NFSV3 +#options BOOTP_WIRED_TO=bfe0 +#options BOOTP_COMPAT + +options NFSCLIENT #Network Filesystem Client +options NFSLOCKD #Network Lock Manager +options NFS_ROOT #NFS usable as /, requires NFSCLIENT + # Debugging for use in -current options INVARIANTS options INVARIANT_SUPPORT -#options BUS_DEBUG -#makeoptions BUS_DEBUG +options VERBOSE_SYSINIT +options BUS_DEBUG +# XXX notyet; need to be auto probed children of siba_cc. +# XXX clock divisor most likely incorrect when banging uart manually. +device uart +device uart_ns8250 + device siba # Sonics SiliconBackplane -device pci # siba_pcib -device bfe # XXX will build both pci and siba -device miibus # attachments +device bfe +device miibus +# No PCI while we figure stuff out. +#device pci # siba_pcib + # pci devices # notyet: #device ath # in pci slot #device ath_hal # in pci slot -device usb # USB Bus (required) -device uhci # UHCI PCI->USB interface -device ehci # EHCI PCI->USB interface (USB 2.0) +#device usb # USB Bus (required) +#device uhci # UHCI PCI->USB interface +#device ehci # EHCI PCI->USB interface (USB 2.0) -# need to teach the code to ignore the bridge.... - - -# XXX notyet; need to be auto probed children of siba_cc. -#device uart -#device uart_ns8250 - device loop device ether device md Index: mips/conf/SENTRY5.hints =================================================================== --- mips/conf/SENTRY5.hints (revision 183815) +++ mips/conf/SENTRY5.hints (working copy) @@ -1,5 +1,19 @@ # $FreeBSD$ hint.siba.0.at="nexus0" -hint.siba.0.maddr="0x18000000" -hint.siba.0.msize="0x1000" -# XXX irq? +hint.siba.0.maddr=0x18000000 +hint.siba.0.msize=0x1000 + +# XXX uart hints are not actually used yet. + +# uart0 +#hint.uart.0.at="siba0" +#hint.uart.0.maddr=0x18000300 +#hint.uart.0.msize=0x8 +#hint.uart.0.irq=0 + +# uart1 +#hint.uart.1.at="siba0" +#hint.uart.1.maddr="0x18000400" +#hint.uart.1.msize="0x8" +#hint.uart.1.irq=0 +#hint.uart.1.disabled=1 Index: mips/mips/busdma_machdep.c =================================================================== --- mips/mips/busdma_machdep.c (revision 183815) +++ mips/mips/busdma_machdep.c (working copy) @@ -25,7 +25,7 @@ * */ -#define NO_DMA +//#define NO_DMA /*- * Copyright (c) 1997, 1998, 2001 The NetBSD Foundation, Inc. Index: mips/sentry5/siba_cc.c =================================================================== --- mips/sentry5/siba_cc.c (revision 183815) +++ mips/sentry5/siba_cc.c (working copy) @@ -61,7 +61,7 @@ static int siba_cc_attach(device_t); static int siba_cc_probe(device_t); -static void siba_cc_intr(void *v); +//static void siba_cc_intr(void *v); static int siba_cc_probe(device_t dev) @@ -85,7 +85,7 @@ { //struct siba_cc_softc *sc = device_get_softc(dev); struct resource *mem; - struct resource *irq; + //struct resource *irq; int rid; /* @@ -101,6 +101,7 @@ return (ENXIO); } +#if 0 rid = 0; irq = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid, 0); if (irq == NULL) { @@ -124,17 +125,28 @@ device_printf(dev, "unable to setup intr\n"); return (ENXIO); } +#endif - /* TODO: attach uart child */ +#if 0 + device_add_child(dev, "uart", 0); + device_add_child(dev, "uart", 1); + bus_generic_probe(dev); + bus_generic_attach(dev); +#endif return (0); } +#if 0 +// XXX: interrupt not actually used, except for the UARTs, +// or external interface, which is assumed to be parallel flash. static void -siba_cc_intr(void *v) +siba_cc_intr(void *v __unused) { + printf("%s: called\n", __func__); } +#endif static device_method_t siba_cc_methods[] = { /* Device interface */ Index: mips/sentry5/s5_machdep.c =================================================================== --- mips/sentry5/s5_machdep.c (revision 183815) +++ mips/sentry5/s5_machdep.c (working copy) @@ -91,6 +91,7 @@ mips_init(void) { int i; + char *p; printf("entry: mips_init()\n"); @@ -129,6 +130,23 @@ physmem = realmem; + /* use static kernel environment if so configured */ + if (envmode == 1) + kern_envp = static_env; + + /* + * Catch case of boot_verbose set in environment. + */ + if ((p = getenv("boot_verbose")) != NULL) { + if (strcmp(p, "yes") == 0 || strcmp(p, "YES") == 0) { + boothowto |= RB_VERBOSE; + } + freeenv(p); + } + + if (boothowto & RB_VERBOSE) + bootverbose = 1; + init_param1(); init_param2(physmem); mips_cpu_init(); @@ -156,8 +174,7 @@ void platform_reset(void) { - -#if defined(CFE) +#if 0 && defined(CFE) cfe_exit(0, 0); #else *((volatile uint8_t *)MIPS_PHYS_TO_KSEG1(SENTRY5_EXTIFADR)) = 0x80; Index: mips/sentry5/files.sentry5 =================================================================== --- mips/sentry5/files.sentry5 (revision 183815) +++ mips/sentry5/files.sentry5 (working copy) @@ -10,5 +10,9 @@ dev/siba/siba_pcib.c optional siba pci mips/sentry5/siba_cc.c optional siba +mips/sentry5/uart_cpu_sentry5.c optional uart +mips/sentry5/uart_bus_sentry5.c optional uart +dev/uart/uart_dev_ns8250.c optional uart + # notyet #mips/sentry5/siba_mips.c optional siba Index: mips/sentry5/uart_cpu_sentry5.c =================================================================== --- mips/sentry5/uart_cpu_sentry5.c (revision 0) +++ mips/sentry5/uart_cpu_sentry5.c (revision 0) @@ -0,0 +1,101 @@ +/*- + * Copyright (c) 2006 Wojciech A. Koszek + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $Id$ + */ +/* + * Skeleton of this file was based on respective code for ARM + * code written by Olivier Houchard. + */ +/* + * XXXMIPS: This file is hacked from arm/... . XXXMIPS here means this file is + * experimental and was written for MIPS32 port. + */ +#include "opt_uart.h" + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include + +#include + +#include +#include + +#include + +bus_space_tag_t uart_bus_space_io; +bus_space_tag_t uart_bus_space_mem; + +extern struct uart_ops sentry5_usart_ops; +extern struct bus_space sentry5_bs_tag; + +int +uart_cpu_eqres(struct uart_bas *b1, struct uart_bas *b2) +{ + return ((b1->bsh == b2->bsh && b1->bst == b2->bst) ? 1 : 0); +} + +int +uart_cpu_getdev(int devtype, struct uart_devinfo *di) +{ + + /* XXX Don't attach this at boot-time as a console. */ + if (devtype == UART_DEV_CONSOLE) + return (ENXIO); + + di->ops = uart_getops(&uart_ns8250_class); + di->bas.chan = 0; + di->bas.bst = 0; +#if 0 + di->bas.regshft = 0; + di->bas.rclk = 0; +#else + /* XXX hardcoded values for 200MHz BCM5365P */ + di->bas.regshft = 1; + di->bas.rclk = 1843200; +#endif + di->baudrate = 115200; + di->databits = 8; + di->stopbits = 1; + di->parity = UART_PARITY_NONE; + +#if 0 + uart_bus_space_io = MIPS_PHYS_TO_KSEG1(SENTRY5_UART1ADR); + uart_bus_space_mem = MIPS_PHYS_TO_KSEG1(SENTRY5_UART1ADR); + di->bas.bsh = MIPS_PHYS_TO_KSEG1(SENTRY5_UART1ADR); +#else + /* XXX try uart 0 */ + uart_bus_space_io = MIPS_PHYS_TO_KSEG1(SENTRY5_UART0ADR); + uart_bus_space_mem = MIPS_PHYS_TO_KSEG1(SENTRY5_UART0ADR); + di->bas.bsh = MIPS_PHYS_TO_KSEG1(SENTRY5_UART0ADR); +#endif + + return (0); +} Index: mips/sentry5/uart_bus_sentry5.c =================================================================== --- mips/sentry5/uart_bus_sentry5.c (revision 0) +++ mips/sentry5/uart_bus_sentry5.c (revision 0) @@ -0,0 +1,95 @@ +/*- + * Copyright (c) 2007 Bruce M. Simpson. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * $Id$ + */ +/* + * Skeleton of this file was based on respective code for ARM + * code written by Olivier Houchard. + */ + +/* + * XXXMIPS: This file is hacked from arm/... . XXXMIPS here means this file is + * experimental and was written for MIPS32 port. + */ +#include "opt_uart.h" + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include +#include +#include + +#include + +#include "uart_if.h" + +static int uart_sentry5_probe(device_t dev); + +extern struct uart_class sentry5_uart_class; + +static device_method_t uart_sentry5_methods[] = { + /* Device interface */ + DEVMETHOD(device_probe, uart_sentry5_probe), + DEVMETHOD(device_attach, uart_bus_attach), + DEVMETHOD(device_detach, uart_bus_detach), + { 0, 0 } +}; + +static driver_t uart_sentry5_driver = { + uart_driver_name, + uart_sentry5_methods, + sizeof(struct uart_softc), +}; + +extern SLIST_HEAD(uart_devinfo_list, uart_devinfo) uart_sysdevs; +static int +uart_sentry5_probe(device_t dev) +{ + struct uart_softc *sc; + + sc = device_get_softc(dev); + sc->sc_sysdev = SLIST_FIRST(&uart_sysdevs); + sc->sc_class = &uart_ns8250_class; + bcopy(&sc->sc_sysdev->bas, &sc->sc_bas, sizeof(sc->sc_bas)); + sc->sc_sysdev->bas.bst = 0; + sc->sc_sysdev->bas.bsh = MIPS_PHYS_TO_KSEG1(SENTRY5_UART1ADR); + sc->sc_bas.bst = 0; + sc->sc_bas.bsh = MIPS_PHYS_TO_KSEG1(SENTRY5_UART1ADR); + return(uart_bus_probe(dev, 0, 0, 0, 0)); +} + +DRIVER_MODULE(uart, obio, uart_sentry5_driver, uart_devclass, 0, 0); Index: dev/siba/siba.c =================================================================== --- dev/siba/siba.c (revision 183815) +++ dev/siba/siba.c (working copy) @@ -44,7 +44,6 @@ /* * TODO: De-mipsify this code. * TODO: cpu clock calculation. -> move to siba_cc instance - * TODO: Hardwire IRQs for attached cores on siba at probe time. * TODO: Support detach. * TODO: Power management. * TODO: code cleanup. @@ -150,11 +149,20 @@ case SIBA_DEVID_CHIPCOMMON: irq = 0; break; + /* XXX: For some reason it seems to want irq2 */ case SIBA_DEVID_ETHERNET: +#ifdef notyet irq = 1; +#else + irq = 2; +#endif break; case SIBA_DEVID_IPSEC: +#ifdef notyet irq = 2; +#else + irq = 0xFF; +#endif break; case SIBA_DEVID_USB: irq = 3; @@ -479,6 +487,7 @@ uint32_t idlo, idhi, rev; uint16_t vendorid, devid; bus_addr_t baseaddr; + u_long corelen; sdi = malloc(sizeof(*sdi), M_DEVBUF, M_WAITOK | M_ZERO); resource_list_init(&sdi->sdi_rl); @@ -500,10 +509,16 @@ /* * Determine memory window on bus and irq if one is needed. */ + if (idx == 0) + corelen = 0x300; /* leave room for uart */ + else + corelen = SIBA_CORE_LEN; + baseaddr = sc->sc_maddr + (idx * SIBA_CORE_LEN); resource_list_add(&sdi->sdi_rl, SYS_RES_MEMORY, MIPS_MEM_RID, /* XXX */ - baseaddr, baseaddr + SIBA_CORE_LEN - 1, SIBA_CORE_LEN); + baseaddr, + baseaddr + corelen - 1, corelen); if (sdi->sdi_irq != 0xff) { resource_list_add(&sdi->sdi_rl, SYS_RES_IRQ, Index: dev/bfe/if_bfe.c =================================================================== --- dev/bfe/if_bfe.c (revision 183815) +++ dev/bfe/if_bfe.c (working copy) @@ -29,6 +29,7 @@ __FBSDID("$FreeBSD$"); #include +#include #include #include #include @@ -59,28 +60,11 @@ #include -MODULE_DEPEND(bfe, pci, 1, 1, 1); -MODULE_DEPEND(bfe, ether, 1, 1, 1); -MODULE_DEPEND(bfe, miibus, 1, 1, 1); - /* "device miibus" required. See GENERIC if you get errors here. */ #include "miibus_if.h" #define BFE_DEVDESC_MAX 64 /* Maximum device description length */ -static struct bfe_type bfe_devs[] = { - { BCOM_VENDORID, BCOM_DEVICEID_BCM4401, - "Broadcom BCM4401 Fast Ethernet" }, - { BCOM_VENDORID, BCOM_DEVICEID_BCM4401B0, - "Broadcom BCM4401-B0 Fast Ethernet" }, - { 0, 0, NULL } -}; - -static int bfe_probe (device_t); -static int bfe_attach (device_t); -static int bfe_detach (device_t); -static int bfe_suspend (device_t); -static int bfe_resume (device_t); static void bfe_release_resources (struct bfe_softc *); static void bfe_intr (void *); static int bfe_encap (struct bfe_softc *, struct mbuf **); @@ -91,7 +75,6 @@ static void bfe_init_locked (void *); static void bfe_stop (struct bfe_softc *); static void bfe_watchdog (struct bfe_softc *); -static int bfe_shutdown (device_t); static void bfe_tick (void *); static void bfe_txeof (struct bfe_softc *); static void bfe_rxeof (struct bfe_softc *); @@ -105,9 +88,6 @@ static void bfe_pci_setup (struct bfe_softc *, u_int32_t); static int bfe_ifmedia_upd (struct ifnet *); static void bfe_ifmedia_sts (struct ifnet *, struct ifmediareq *); -static int bfe_miibus_readreg (device_t, int, int); -static int bfe_miibus_writereg (device_t, int, int, int); -static void bfe_miibus_statchg (device_t); static int bfe_wait_bit (struct bfe_softc *, u_int32_t, u_int32_t, u_long, const int); static void bfe_get_config (struct bfe_softc *sc); @@ -128,60 +108,8 @@ static void bfe_cam_write (struct bfe_softc *, u_char *, int); static int sysctl_bfe_stats (SYSCTL_HANDLER_ARGS); -static device_method_t bfe_methods[] = { - /* Device interface */ - DEVMETHOD(device_probe, bfe_probe), - DEVMETHOD(device_attach, bfe_attach), - DEVMETHOD(device_detach, bfe_detach), - DEVMETHOD(device_shutdown, bfe_shutdown), - DEVMETHOD(device_suspend, bfe_suspend), - DEVMETHOD(device_resume, bfe_resume), +devclass_t bfe_devclass; - /* bus interface */ - DEVMETHOD(bus_print_child, bus_generic_print_child), - DEVMETHOD(bus_driver_added, bus_generic_driver_added), - - /* MII interface */ - DEVMETHOD(miibus_readreg, bfe_miibus_readreg), - DEVMETHOD(miibus_writereg, bfe_miibus_writereg), - DEVMETHOD(miibus_statchg, bfe_miibus_statchg), - - { 0, 0 } -}; - -static driver_t bfe_driver = { - "bfe", - bfe_methods, - sizeof(struct bfe_softc) -}; - -static devclass_t bfe_devclass; - -DRIVER_MODULE(bfe, pci, bfe_driver, bfe_devclass, 0, 0); -DRIVER_MODULE(miibus, bfe, miibus_driver, miibus_devclass, 0, 0); - -/* - * Probe for a Broadcom 4401 chip. - */ -static int -bfe_probe(device_t dev) -{ - struct bfe_type *t; - - t = bfe_devs; - - while (t->bfe_name != NULL) { - if (pci_get_vendor(dev) == t->bfe_vid && - pci_get_device(dev) == t->bfe_did) { - device_set_desc(dev, t->bfe_name); - return (BUS_PROBE_DEFAULT); - } - t++; - } - - return (ENXIO); -} - struct bfe_dmamap_arg { bus_addr_t bfe_busaddr; }; @@ -430,7 +358,7 @@ } } -static int +int bfe_attach(device_t dev) { struct ifnet *ifp = NULL; @@ -447,9 +375,13 @@ /* * Map control/status registers. */ - pci_enable_busmaster(dev); + if (sc->bfe_bus_type == BFE_BUS_PCI) { + pci_enable_busmaster(dev); + rid = PCIR_BAR(0); + } else if (sc->bfe_bus_type == BFE_BUS_SIBA) { + rid = 0x20; /* XXX MIPS hardcoded */ + } - rid = PCIR_BAR(0); sc->bfe_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, RF_ACTIVE); if (sc->bfe_res == NULL) { @@ -475,6 +407,8 @@ goto fail; } + // kdb_enter(KDB_WHY_UNSET, "bfe dmamem alloc done"); + SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev), SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, "stats", CTLTYPE_INT | CTLFLAG_RW, sc, 0, sysctl_bfe_stats, @@ -498,13 +432,16 @@ ifp->if_snd.ifq_drv_maxlen = BFE_TX_QLEN; IFQ_SET_READY(&ifp->if_snd); + //device_printf(dev, "attempting to get config\n"); bfe_get_config(sc); /* Reset the chip and turn on the PHY */ + //device_printf(dev, "attempting to reset chip\n"); BFE_LOCK(sc); bfe_chip_reset(sc); BFE_UNLOCK(sc); + //device_printf(dev, "attempting to probe phy\n"); if (mii_phy_probe(dev, &sc->bfe_miibus, bfe_ifmedia_upd, bfe_ifmedia_sts)) { device_printf(dev, "MII without any PHY!\n"); @@ -512,6 +449,7 @@ goto fail; } + //device_printf(dev, "attempting to attach i/f to stack\n"); ether_ifattach(ifp, sc->bfe_enaddr); /* @@ -524,6 +462,7 @@ /* * Hook interrupt last to avoid having to lock softc */ + //device_printf(dev, "attempting to hook irqs\n"); error = bus_setup_intr(dev, sc->bfe_irq, INTR_TYPE_NET | INTR_MPSAFE, NULL, bfe_intr, sc, &sc->bfe_intrhand); @@ -537,7 +476,7 @@ return (error); } -static int +int bfe_detach(device_t dev) { struct bfe_softc *sc; @@ -576,7 +515,7 @@ * Stop all chip I/O so that the kernel's probe routines don't * get confused by errant DMAs when rebooting. */ -static int +int bfe_shutdown(device_t dev) { struct bfe_softc *sc; @@ -590,7 +529,7 @@ return (0); } -static int +int bfe_suspend(device_t dev) { struct bfe_softc *sc; @@ -603,7 +542,7 @@ return (0); } -static int +int bfe_resume(device_t dev) { struct bfe_softc *sc; @@ -624,7 +563,7 @@ return (0); } -static int +int bfe_miibus_readreg(device_t dev, int phy, int reg) { struct bfe_softc *sc; @@ -638,7 +577,7 @@ return (ret); } -static int +int bfe_miibus_writereg(device_t dev, int phy, int reg, int val) { struct bfe_softc *sc; @@ -651,7 +590,7 @@ return (0); } -static void +void bfe_miibus_statchg(device_t dev) { struct bfe_softc *sc; @@ -840,9 +779,34 @@ return (0); } +/* + * XXX: The SiBa version of bfe does not have an eeprom. + * We may also need to know the external clock speed of + * the SoC to set up the MDIO registers correctly. + */ static void -bfe_get_config(struct bfe_softc *sc) +bfe_siba_get_config(struct bfe_softc *sc) { + + /* XXX this is bogus */ + sc->bfe_enaddr[0] = 0x00; + sc->bfe_enaddr[1] = 0x0f; + sc->bfe_enaddr[2] = 0xb5; + sc->bfe_enaddr[3] = 0x3d; + sc->bfe_enaddr[4] = 0x52; + sc->bfe_enaddr[5] = 0x90; + + sc->bfe_phyaddr = 0x01; /* XXX */ + + /* unused fields */ + sc->bfe_mdc_port = 0; + sc->bfe_core_unit = 0; + sc->bfe_dma_offset = 0; +} + +static void +bfe_pci_get_config(struct bfe_softc *sc) +{ u_int8_t eeprom[128]; bfe_read_eeprom(sc, eeprom); @@ -862,6 +826,17 @@ } static void +bfe_get_config(struct bfe_softc *sc) +{ + + if (sc->bfe_bus_type == BFE_BUS_PCI) { + bfe_pci_get_config(sc); + } else if (sc->bfe_bus_type == BFE_BUS_SIBA) { + bfe_siba_get_config(sc); + } +} + +static void bfe_pci_setup(struct bfe_softc *sc, u_int32_t cores) { u_int32_t bar_orig, pci_rev, val; @@ -934,7 +909,8 @@ BFE_LOCK_ASSERT(sc); /* Set the interrupt vector for the enet core */ - bfe_pci_setup(sc, BFE_INTVEC_ENET0); + if (sc->bfe_bus_type == BFE_BUS_PCI) + bfe_pci_setup(sc, BFE_INTVEC_ENET0); /* is core up? */ val = CSR_READ_4(sc, BFE_SBTMSLOW) & @@ -1455,6 +1431,8 @@ BFE_LOCK(sc); + device_printf(sc->bfe_dev, "bfe_intr called\n"); + istat = CSR_READ_4(sc, BFE_ISTAT); /* @@ -1972,3 +1950,7 @@ return (error); } + +MODULE_DEPEND(bfe, ether, 1, 1, 1); +MODULE_DEPEND(bfe, miibus, 1, 1, 1); +DRIVER_MODULE(miibus, bfe, miibus_driver, miibus_devclass, 0, 0); Index: dev/bfe/if_bfereg.h =================================================================== --- dev/bfe/if_bfereg.h (revision 183815) +++ dev/bfe/if_bfereg.h (working copy) @@ -421,6 +421,7 @@ #define BCOM_VENDORID 0x14E4 #define BCOM_DEVICEID_BCM4401 0x4401 +#define BCOM_DEVICEID_BCM4713 0x4713 #define BCOM_DEVICEID_BCM4401B0 0x170c #define PCI_SETBIT(dev, reg, x, s) \ @@ -430,6 +431,7 @@ #define BFE_TX_LIST_CNT 128 #define BFE_RX_LIST_CNT 128 + #define BFE_TX_LIST_SIZE BFE_TX_LIST_CNT * sizeof(struct bfe_desc) #define BFE_RX_LIST_SIZE BFE_RX_LIST_CNT * sizeof(struct bfe_desc) #define BFE_RX_OFFSET 30 @@ -457,6 +459,9 @@ #define BFE_INC(x, y) (x) = ((x) == ((y)-1)) ? 0 : (x)+1 +#define BFE_BUS_PCI (0) /* device lives on a PCI bus */ +#define BFE_BUS_SIBA (1) /* device lives on a SiBa bus */ + struct bfe_tx_data { struct mbuf *bfe_mbuf; bus_dmamap_t bfe_map; @@ -612,6 +617,7 @@ u_int8_t bfe_phyaddr; /* Address of the card's PHY */ u_int8_t bfe_mdc_port; u_int8_t bfe_core_unit; + u_int8_t bfe_bus_type; u_char bfe_enaddr[6]; int bfe_if_flags; }; @@ -623,4 +629,16 @@ char *bfe_name; }; +int bfe_attach(device_t); +int bfe_detach(device_t); +int bfe_suspend(device_t); +int bfe_resume(device_t); +int bfe_shutdown(device_t); + +int bfe_miibus_readreg(device_t, int, int); +int bfe_miibus_writereg(device_t, int, int, int); +void bfe_miibus_statchg(device_t); + +extern devclass_t bfe_devclass; + #endif /* _BFE_H */ Index: dev/mii/miidevs =================================================================== --- dev/mii/miidevs (revision 183815) +++ dev/mii/miidevs (working copy) @@ -130,6 +130,7 @@ model BROADCOM BCM5201 0x0021 BCM5201 10/100baseTX PHY model BROADCOM BCM5221 0x001e BCM5221 10/100baseTX PHY model BROADCOM BCM4401 0x0036 BCM4401 10/100baseTX PHY +model BROADCOM BCM5365 0x0037 BCM5365 10/100baseTX PHY model xxBROADCOM BCM5400 0x0004 Broadcom 1000baseTX PHY model xxBROADCOM BCM5401 0x0005 BCM5401 10/100/1000baseTX PHY model xxBROADCOM BCM5411 0x0007 BCM5411 10/100/1000baseTX PHY Index: dev/mii/bmtphy.c =================================================================== --- dev/mii/bmtphy.c (revision 183815) +++ dev/mii/bmtphy.c (working copy) @@ -124,6 +124,7 @@ MII_PHY_DESC(BROADCOM, BCM4401), MII_PHY_DESC(BROADCOM, BCM5201), MII_PHY_DESC(BROADCOM, BCM5221), + MII_PHY_DESC(BROADCOM, BCM5365), /* TODO: Add switch driver. */ MII_PHY_END }; --------------050603050405090201050903-- From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 13 18:36:12 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 229A01065691 for ; Mon, 13 Oct 2008 18:36:12 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id EDA6B8FC12 for ; Mon, 13 Oct 2008 18:36:11 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id A1AAE179799 for ; Mon, 13 Oct 2008 14:17:08 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 13 Oct 2008 14:17:08 -0400 X-Sasl-enc: 7b+QqhazfvkC5aazFYKyL/cq6PQSTyN2lFHnsWl1bt9H 1223921828 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 2171722CAD for ; Mon, 13 Oct 2008 14:17:07 -0400 (EDT) Message-ID: <48F390A2.5010006@FreeBSD.org> Date: Mon, 13 Oct 2008 19:17:06 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: freebsd-embedded@freebsd.org References: <48F0BDF9.7080300@incunabulum.net> In-Reply-To: <48F0BDF9.7080300@incunabulum.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Emprex / Star / Cavium followup X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 18:36:12 -0000 Bruce M Simpson wrote: > > It's been around 3 months since I originally fired off questions about > this, neither Emprex nor Star have replied, perhaps now that Cavium > have bought Star, we may be more likely to get answers to these > questions. Further to this: The NSD-100 is in fact using ARMBoot, which is a GPLed firmware project. By not releasing the firmware patches for the STR9104 in the product, the author(s) of the firmware patches (presumably Star) are violating the GPL there too. From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 13 18:46:52 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AFD21065690 for ; Mon, 13 Oct 2008 18:46:52 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id CCE368FC2C for ; Mon, 13 Oct 2008 18:46:51 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 892C01610FF for ; Mon, 13 Oct 2008 14:46:50 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 13 Oct 2008 14:46:50 -0400 X-Sasl-enc: UUrZHIyndA+xDr6OPiW/MLi+RR4qicWIGFzN4kKkqEVm 1223923610 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 0FEA12BEB8 for ; Mon, 13 Oct 2008 14:46:49 -0400 (EDT) Message-ID: <48F39798.3010606@incunabulum.net> Date: Mon, 13 Oct 2008 19:46:48 +0100 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: freebsd-embedded@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ELF loader problem with CFE on ASUS WL500g X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 18:46:52 -0000 Hi, I just tried to boot the WGT634U kernel on the ASUS WL500g. CFE version is 1.0.37. It appears there's yet another problem with the ELF loader there -- it now looks at the p_paddr field. As this is out of range for physical memory (GNU ld set it the same as p_vaddr), it balks. Any suggestions for workarounds? I tried using the GNU ld "MEMORY" directive, however, it seems to munge p_vaddr also. It looks like objcopy's --change-section-lma option, with a negative offset, would do what I want, however it will need to be scripted to work on named sections. cheers BMS From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 13 18:58:24 2008 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88C5E106569A for ; Mon, 13 Oct 2008 18:58:24 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 496BE8FC08 for ; Mon, 13 Oct 2008 18:58:24 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m9DItlrR044167; Mon, 13 Oct 2008 12:55:47 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 13 Oct 2008 12:56:48 -0600 (MDT) Message-Id: <20081013.125648.1239212699.imp@bsdimp.com> To: bms@incunabulum.net From: "M. Warner Losh" In-Reply-To: <48F39798.3010606@incunabulum.net> References: <48F39798.3010606@incunabulum.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-embedded@FreeBSD.org Subject: Re: ELF loader problem with CFE on ASUS WL500g X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 18:58:24 -0000 In message: <48F39798.3010606@incunabulum.net> Bruce M Simpson writes: : Hi, : : I just tried to boot the WGT634U kernel on the ASUS WL500g. : : CFE version is 1.0.37. : : It appears there's yet another problem with the ELF loader there -- it : now looks at the p_paddr field. As this is out of range for physical : memory (GNU ld set it the same as p_vaddr), it balks. I thought you could fix this with linker script tweaks... : Any suggestions for workarounds? I tried using the GNU ld "MEMORY" : directive, however, it seems to munge p_vaddr also. bummer... It sounds a bit like we need to do the normal tricks of 'early' boot loaders: turn on the mmu and then jump to . to transition from PA to VA addresses... : It looks like objcopy's --change-section-lma option, with a negative : offset, would do what I want, however it will need to be scripted to : work on named sections. You might try to mock-up a test with a newer version of binutils than 2.15 we're using? Warner From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 13 19:26:41 2008 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDF6D1065687 for ; Mon, 13 Oct 2008 19:26:41 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 7ECD18FC27 for ; Mon, 13 Oct 2008 19:26:41 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 0818E15E504; Mon, 13 Oct 2008 15:26:41 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 13 Oct 2008 15:26:41 -0400 X-Sasl-enc: FpY5E5gmVDu0iUDxxaCaN8ytMzaNiQhmUmpzSztyulZ0 1223926000 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 3712AC42D; Mon, 13 Oct 2008 15:26:40 -0400 (EDT) Message-ID: <48F3A0EE.7040003@incunabulum.net> Date: Mon, 13 Oct 2008 20:26:38 +0100 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: "M. Warner Losh" References: <48F39798.3010606@incunabulum.net> <20081013.125648.1239212699.imp@bsdimp.com> In-Reply-To: <20081013.125648.1239212699.imp@bsdimp.com> X-Enigmail-Version: 0.95.6 Content-Type: multipart/mixed; boundary="------------000707010509060807020608" Cc: freebsd-embedded@FreeBSD.org Subject: Re: ELF loader problem with CFE on ASUS WL500g X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 19:26:41 -0000 This is a multi-part message in MIME format. --------------000707010509060807020608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit M. Warner Losh wrote: > I thought you could fix this with linker script tweaks... > Not in an automated way. It'll let you set a *fixed* LMA by adding AT(...) to the PHDR linker script section, but that's not very useful. Trying to use a non-constant expression produces an error; and LOADADDR() wants a *section*, not a *segment*. The first thing I tried was to use the "load -addr" option in CFE; it totally ignores this option as it only applies to raw images. I tried the GNU ld MEMORY { ... } section, but it changes the VMA as well as the LMA. I seem to remember I had headaches like this when trying to build FreeBSD with the MinGW toolchain to boot on an SGI Visual Workstation. > bummer... It sounds a bit like we need to do the normal tricks of > 'early' boot loaders: turn on the mmu and then jump to . to transition > from PA to VA addresses... > > : It looks like objcopy's --change-section-lma option, with a negative > : offset, would do what I want, however it will need to be scripted to > : work on named sections. > > You might try to mock-up a test with a newer version of binutils than > 2.15 we're using? > I tried the attached script, which produces a BFD error: BFD: kernel.rebased: section `.hash' can't be allocated in segment 3 One common problem with these Broadcom based platforms is that they almost always ship with CFE, and it's convenient to use the inbuilt ELF loader for bootstrapping. Unfortunately CFE comes with bugs attached, and there are usually no alternative boot loaders available due to Broadcom's less than, shall we say, "open" attitude towards open source. *ahem* So yeah, it sounds like we probably need something like the ARM ELF trampoline for MIPS ideally. It would probably also be relatively easy to write a small C tool with libelf to do the rebasing CFE expects. I have a train to catch in a few hours, I'd better not get in too deep... later BMS --------------000707010509060807020608 Content-Type: text/plain; name="fnord.sh" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fnord.sh" #!/bin/sh OBJCOPY=mips-rtems-objcopy KERNEL=kernel REBASE=0x80000000 SECTIONS=$(mips-rtems-objdump -h $KERNEL | grep ' \.' | awk '{ if (substr($4,0,2) == "80") print $2}') OCOPTS="" for i in $SECTIONS ; do OCOPTS="$OCOPTS --change-section-lma ${i}-${REBASE}" done set -x exec $OBJCOPY $OCOPTS $KERNEL ${KERNEL}.rebased --------------000707010509060807020608-- From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 13 19:49:49 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10A811065687 for ; Mon, 13 Oct 2008 19:49:49 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A24258FC0A for ; Mon, 13 Oct 2008 19:49:48 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m9DJkIg9045094; Mon, 13 Oct 2008 13:46:19 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 13 Oct 2008 13:47:20 -0600 (MDT) Message-Id: <20081013.134720.1079617746.imp@bsdimp.com> To: bms@incunabulum.net From: "M. Warner Losh" In-Reply-To: <48F3A0EE.7040003@incunabulum.net> References: <48F39798.3010606@incunabulum.net> <20081013.125648.1239212699.imp@bsdimp.com> <48F3A0EE.7040003@incunabulum.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-embedded@freebsd.org Subject: Re: ELF loader problem with CFE on ASUS WL500g X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2008 19:49:49 -0000 In message: <48F3A0EE.7040003@incunabulum.net> Bruce M Simpson writes: : M. Warner Losh wrote: : > I thought you could fix this with linker script tweaks... : > : : Not in an automated way. It'll let you set a *fixed* LMA by adding : AT(...) to the PHDR linker script section, but that's not very useful. : Trying to use a non-constant expression produces an error; and : LOADADDR() wants a *section*, not a *segment*. : : The first thing I tried was to use the "load -addr" option in CFE; it : totally ignores this option as it only applies to raw images. : : I tried the GNU ld MEMORY { ... } section, but it changes the VMA as : well as the LMA. : : I seem to remember I had headaches like this when trying to build : FreeBSD with the MinGW toolchain to boot on an SGI Visual Workstation. :-( : > bummer... It sounds a bit like we need to do the normal tricks of : > 'early' boot loaders: turn on the mmu and then jump to . to transition : > from PA to VA addresses... : > : > : It looks like objcopy's --change-section-lma option, with a negative : > : offset, would do what I want, however it will need to be scripted to : > : work on named sections. : > : > You might try to mock-up a test with a newer version of binutils than : > 2.15 we're using? : > : : I tried the attached script, which produces a BFD error: : BFD: kernel.rebased: section `.hash' can't be allocated in segment 3 That sucks. : One common problem with these Broadcom based platforms is that they : almost always ship with CFE, and it's convenient to use the inbuilt ELF : loader for bootstrapping. Correct. I understand that... : Unfortunately CFE comes with bugs attached, and there are usually no : alternative boot loaders available due to Broadcom's less than, shall we : say, "open" attitude towards open source. *ahem* : : So yeah, it sounds like we probably need something like the ARM ELF : trampoline for MIPS ideally. That's what I'm talking about. Using CFE to boot FreeBSD kernel. we're unlikely to be able to put the u-boot syscall features into CFE, so we won't be able to leverage that work... : It would probably also be relatively easy to write a small C tool with : libelf to do the rebasing CFE expects. That's the other alternative... Warner From owner-freebsd-embedded@FreeBSD.ORG Tue Oct 14 08:36:00 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AACD1065697 for ; Tue, 14 Oct 2008 08:36:00 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id D89B98FC24 for ; Tue, 14 Oct 2008 08:35:59 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 4FBF417A598 for ; Tue, 14 Oct 2008 04:35:59 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 14 Oct 2008 04:35:59 -0400 X-Sasl-enc: xpOI+iZLm+3opfrZ8OmNTpOqQC2Hb+cbgXd+TVApgbNi 1223973355 Received: from [10.92.40.134] (unknown [82.132.136.205]) by mail.messagingengine.com (Postfix) with ESMTPSA id 1EC5A2BAFC for ; Tue, 14 Oct 2008 04:35:51 -0400 (EDT) Message-ID: <48F459BD.6050002@incunabulum.net> Date: Tue, 14 Oct 2008 09:35:09 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: freebsd-embedded@freebsd.org References: <48F0BDF9.7080300@incunabulum.net> <48F390A2.5010006@FreeBSD.org> In-Reply-To: <48F390A2.5010006@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Emprex / Star / Cavium followup X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 08:36:00 -0000 Bruce M. Simpson wrote: > Bruce M Simpson wrote: >> >> It's been around 3 months since I originally fired off questions >> about this, neither Emprex nor Star have replied, perhaps now that >> Cavium have bought Star, we may be more likely to get answers to >> these questions. The transition to Cavium, and my follow-up contact, appears to have spurred them into action. I received a reply that the necessary materials are being hosted by Linksys, look for the WAP4400N here: http://www-hk.linksys.com/servlet/Satellite?c=L_Content_C1&childpagename=HK%2FLayout&cid=1145862125829&pagename=Linksys%2FCommon%2FVisitorWrapper thanks BMS From owner-freebsd-embedded@FreeBSD.ORG Tue Oct 14 08:39:29 2008 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E71B106568A for ; Tue, 14 Oct 2008 08:39:29 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 676468FC14 for ; Tue, 14 Oct 2008 08:39:29 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 1776A17A219 for ; Tue, 14 Oct 2008 04:39:29 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 14 Oct 2008 04:39:29 -0400 X-Sasl-enc: y4MCUG5mD3vrgtUcKTblVIJHIpcjEIAmdq2GxQ/8FemO 1223973565 Received: from [10.92.40.134] (unknown [82.132.136.205]) by mail.messagingengine.com (Postfix) with ESMTPSA id 4D55C2BAFC for ; Tue, 14 Oct 2008 04:39:19 -0400 (EDT) Message-ID: <48F45A8F.8050609@incunabulum.net> Date: Tue, 14 Oct 2008 09:38:39 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: freebsd-embedded@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Recommendations for PC based logic analyzer / grabbers? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 08:39:29 -0000 Does anyone know of a good, inexpensive source for PC-based logic analyzers? Don't need full PCI capture, full state analysis, or anything like that: being able to look at peripheral buses, e.g. a CFI flash parallel bus, LPC, ISA, i2c, and/or 10/100Mbit MDIO interfaces would be most useful. This guy has covered some of the grabber bases, however being able to get at really small arbitrary layouts e.g. with miniature pogo pins would be even better: http://www.knjn.com/ShopCablesProbing.html I see a lot of Chinese USB2 based stuff popping up on eBay. Trouble is of course, they require Windows, and they don't have grabbers I can easily attach to hardware with the probe cables. Trouble with MiniLA is, whilst the designs are public, no one seems to be manufacturing them. I found Tony Bybell, the maintainer of GTKWave, is responsive and helpful to queries. From owner-freebsd-embedded@FreeBSD.ORG Tue Oct 14 09:29:40 2008 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A224106568B for ; Tue, 14 Oct 2008 09:29:40 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from semihalf.com (semihalf.com [206.130.101.55]) by mx1.freebsd.org (Postfix) with ESMTP id 17BF68FC12 for ; Tue, 14 Oct 2008 09:29:40 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by semihalf.com (8.13.1/8.13.1) with ESMTP id m9E9Tc1b018905; Tue, 14 Oct 2008 03:29:39 -0600 Message-ID: <48F4667F.4080900@semihalf.com> Date: Tue, 14 Oct 2008 11:29:35 +0200 From: Rafal Jaworowski Organization: Semihalf MIME-Version: 1.0 To: "Bruce M. Simpson" References: <48F099D4.2050302@incunabulum.net> In-Reply-To: <48F099D4.2050302@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-embedded@FreeBSD.org Subject: Re: HOWTO: Build NSLU2 U-Boot on FreeBSD X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 09:29:40 -0000 Bruce M. Simpson wrote: > Building NSLU2 U-boot firmware on FreeBSD hosts *snip* > Toolchain setup > > cd /usr/ports/devel/cross-binutils > env TGTARCH=arm TGTABI=rtems make install > > cd /usr/ports/devel/cross-gcc > env TGTARCH=arm TGTABI=rtems make install > > Get stas@FreeBSD.org's updated u-boot tarball: > uboot-atamantb.tar.bz2 > Untar it *snip* > env CROSS_COMPILE=arm-rtems- gmake distclean > env CROSS_COMPILE=arm-rtems- gmake nslu2_config > env CROSS_COMPILE=arm-rtems- gmake In general it should be possible to build U-Boot with our in-tree cross tool chain. I recall Marcel got this working with some patches against U-Boot build scripts, tools or makefiles; they were even accepted to main line U-Boot IIRC. There's also another approach possible: using U-Boot native and ready to use build tools (ELDK) via Linux compat layer. I was working in such setup some time ago and it was fine with some minor tweaks because of differences in some of the GNU tools and ours. FWIW, my old notes on this from FreeBSD 5.x/6 timeframe can be found here: http://www.denx.de/wiki/view/DULG/ELDKInstallationUnderFreeBSD Rafal From owner-freebsd-embedded@FreeBSD.ORG Tue Oct 14 09:30:04 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B23F106568C for ; Tue, 14 Oct 2008 09:30:04 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from semihalf.com (semihalf.com [206.130.101.55]) by mx1.freebsd.org (Postfix) with ESMTP id 651A28FC12 for ; Tue, 14 Oct 2008 09:30:04 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by semihalf.com (8.13.1/8.13.1) with ESMTP id m9E9ANTF015146; Tue, 14 Oct 2008 03:10:24 -0600 Message-ID: <48F461FD.1050800@semihalf.com> Date: Tue, 14 Oct 2008 11:10:21 +0200 From: Rafal Jaworowski Organization: Semihalf MIME-Version: 1.0 To: "M. Warner Losh" References: <48F39798.3010606@incunabulum.net> <20081013.125648.1239212699.imp@bsdimp.com> <48F3A0EE.7040003@incunabulum.net> <20081013.134720.1079617746.imp@bsdimp.com> In-Reply-To: <20081013.134720.1079617746.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-embedded@freebsd.org Subject: Re: ELF loader problem with CFE on ASUS WL500g X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 09:30:04 -0000 M. Warner Losh wrote: > : Unfortunately CFE comes with bugs attached, and there are usually no > : alternative boot loaders available due to Broadcom's less than, shall we > : say, "open" attitude towards open source. *ahem* > : > : So yeah, it sounds like we probably need something like the ARM ELF > : trampoline for MIPS ideally. > > That's what I'm talking about. Using CFE to boot FreeBSD kernel. > we're unlikely to be able to put the u-boot syscall features into CFE, > so we won't be able to leverage that work... But CFE has its own notion of API that standalone apps ("applets" as they call it) can utilise. It shouldn't be too difficult to provide glue for loader(8) to work on top of CFE, provided the firmware exports some necessary functionality (console, net, maybe storage). Rafal From owner-freebsd-embedded@FreeBSD.ORG Tue Oct 14 10:43:44 2008 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25663106569E for ; Tue, 14 Oct 2008 10:43:44 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout5.freenet.de (mout5.freenet.de [IPv6:2001:748:100:40::2:7]) by mx1.freebsd.org (Postfix) with ESMTP id AE7D38FC1A for ; Tue, 14 Oct 2008 10:43:43 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.14] (helo=4.mx.freenet.de) by mout5.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #65) id 1KphNL-0003V2-Pb; Tue, 14 Oct 2008 12:43:39 +0200 Received: from m8bb2.m.pppool.de ([89.49.139.178]:57416 helo=ernst.jennejohn.org) by 4.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #65) id 1KphNL-0007Ai-Fj; Tue, 14 Oct 2008 12:43:39 +0200 Date: Tue, 14 Oct 2008 12:43:36 +0200 From: Gary Jennejohn To: Rafal Jaworowski Message-ID: <20081014124336.16e25346@ernst.jennejohn.org> In-Reply-To: <48F4667F.4080900@semihalf.com> References: <48F099D4.2050302@incunabulum.net> <48F4667F.4080900@semihalf.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-embedded@FreeBSD.org Subject: Re: HOWTO: Build NSLU2 U-Boot on FreeBSD X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 10:43:44 -0000 On Tue, 14 Oct 2008 11:29:35 +0200 Rafal Jaworowski wrote: > Bruce M. Simpson wrote: > > Building NSLU2 U-boot firmware on FreeBSD hosts > > *snip* > > > Toolchain setup > > > > cd /usr/ports/devel/cross-binutils > > env TGTARCH=arm TGTABI=rtems make install > > > > cd /usr/ports/devel/cross-gcc > > env TGTARCH=arm TGTABI=rtems make install > > > > Get stas@FreeBSD.org's updated u-boot tarball: > > uboot-atamantb.tar.bz2 > > Untar it > > *snip* > > > env CROSS_COMPILE=arm-rtems- gmake distclean > > env CROSS_COMPILE=arm-rtems- gmake nslu2_config > > env CROSS_COMPILE=arm-rtems- gmake > > In general it should be possible to build U-Boot with our in-tree cross tool > chain. I recall Marcel got this working with some patches against U-Boot build > scripts, tools or makefiles; they were even accepted to main line U-Boot IIRC. > > There's also another approach possible: using U-Boot native and ready to use > build tools (ELDK) via Linux compat layer. I was working in such setup some > time ago and it was fine with some minor tweaks because of differences in some > of the GNU tools and ours. FWIW, my old notes on this from FreeBSD 5.x/6 > timeframe can be found here: > http://www.denx.de/wiki/view/DULG/ELDKInstallationUnderFreeBSD > Doesn't work anymore with more recent versions of u-boot. It tries to generate some native utilities which use Linux headers which conflict with the native FreeBSD headers. Judicious tweeking of include paths may solve the problem, but I only spent a little time on it. This is an unfortunate trend which I've also observed with Linux. It is still possible to cross compile Linux 2.4.25 under FreeBSD, but the Linux (and u-boot) developers keep adding more and more Linux-specific utilities so that e.g. Linux 2.6.* _must_ be compiled under Linux. BTW I always use the ELDK since I work as a consultant for DENX. --- Gary Jennejohn From owner-freebsd-embedded@FreeBSD.ORG Tue Oct 14 11:09:10 2008 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 181181065696 for ; Tue, 14 Oct 2008 11:09:10 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id BC8988FC1F for ; Tue, 14 Oct 2008 11:09:09 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from [78.110.49.49] (helo=quasar.ht-systems.ru) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1KphTp-0005Nf-VQ; Tue, 14 Oct 2008 14:50:22 +0400 Received: by quasar.ht-systems.ru (Postfix, from userid 1024) id E118374E01; Tue, 14 Oct 2008 14:50:20 +0400 (MSD) Date: Tue, 14 Oct 2008 14:50:20 +0400 From: Stanislav Sedov To: gary.jennejohn@freenet.de Message-Id: <20081014145020.13a1faae.stas@FreeBSD.org> In-Reply-To: <20081014124336.16e25346@ernst.jennejohn.org> References: <48F099D4.2050302@incunabulum.net> <48F4667F.4080900@semihalf.com> <20081014124336.16e25346@ernst.jennejohn.org> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Tue__14_Oct_2008_14_50_20_+0400_NO8FSE+_PD1P8WsX" Cc: freebsd-embedded@FreeBSD.org Subject: Re: HOWTO: Build NSLU2 U-Boot on FreeBSD X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 11:09:10 -0000 --Signature=_Tue__14_Oct_2008_14_50_20_+0400_NO8FSE+_PD1P8WsX Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 14 Oct 2008 12:43:36 +0200 Gary Jennejohn mentioned: > >=20 >=20 > Doesn't work anymore with more recent versions of u-boot. It tries to > generate some native utilities which use Linux headers which conflict > with the native FreeBSD headers. > Patch I've posted fixes that. =20 > Judicious tweeking of include paths may solve the problem, but I only > spent a little time on it. >=20 > This is an unfortunate trend which I've also observed with Linux. > It is still possible to cross compile Linux 2.4.25 under FreeBSD, but > the Linux (and u-boot) developers keep adding more and more > Linux-specific utilities so that e.g. Linux 2.6.* _must_ be compiled > under Linux. >=20 Well, I've managed to build Linux with a bit of header tweaking too. I was even thinking about making a port, when I was working on embedded Linux. Hopefully, I don't work on it anymore:-) --=20 Stanislav Sedov ST4096-RIPE --Signature=_Tue__14_Oct_2008_14_50_20_+0400_NO8FSE+_PD1P8WsX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkj0eWwACgkQK/VZk+smlYE4wACfdBItZ6KMVeGqtE3mUL6dIZBC aqkAnigrxkWj70V4qLlBvnn/1unJ4kDO =GbTT -----END PGP SIGNATURE----- --Signature=_Tue__14_Oct_2008_14_50_20_+0400_NO8FSE+_PD1P8WsX-- From owner-freebsd-embedded@FreeBSD.ORG Tue Oct 14 14:52:55 2008 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FC18106568B for ; Tue, 14 Oct 2008 14:52:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 9EB958FC0C for ; Tue, 14 Oct 2008 14:52:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m9EEnYO5064470; Tue, 14 Oct 2008 08:49:34 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 14 Oct 2008 08:50:19 -0600 (MDT) Message-Id: <20081014.085019.1723235775.imp@bsdimp.com> To: gary.jennejohn@freenet.de From: "M. Warner Losh" In-Reply-To: <20081014124336.16e25346@ernst.jennejohn.org> References: <48F099D4.2050302@incunabulum.net> <48F4667F.4080900@semihalf.com> <20081014124336.16e25346@ernst.jennejohn.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-embedded@FreeBSD.org Subject: Re: HOWTO: Build NSLU2 U-Boot on FreeBSD X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 14:52:55 -0000 In message: <20081014124336.16e25346@ernst.jennejohn.org> Gary Jennejohn writes: : Linux-specific utilities so that e.g. Linux 2.6.* _must_ be compiled : under Linux. Well, it is three hacks away from being able to build in FreeBSD. Two of the hacks are standards issues, while one is just a difference in elf.h. Warner From owner-freebsd-embedded@FreeBSD.ORG Tue Oct 14 16:29:54 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92C231065686 for ; Tue, 14 Oct 2008 16:29:54 +0000 (UTC) (envelope-from philip.mullis@syx.ca) Received: from smtpout1.syx.ca (smtpout.syx.ca [69.77.170.152]) by mx1.freebsd.org (Postfix) with ESMTP id 69AC88FC18 for ; Tue, 14 Oct 2008 16:29:53 +0000 (UTC) (envelope-from philip.mullis@syx.ca) Received: from mail.syx.ca (unknown [192.168.21.1]) by smtpout1.syx.ca (Postfix) with ESMTP id 3F155181C1B for ; Tue, 14 Oct 2008 11:52:15 -0400 (EDT) Received: from [192.168.22.188] ([192.168.22.188]) by mail.syx.ca with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 11:52:15 -0400 Message-ID: <48F4C02F.1060407@syx.ca> Date: Tue, 14 Oct 2008 11:52:15 -0400 From: Philip Mullis User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: freebsd-embedded@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2008 15:52:15.0249 (UTC) FILETIME=[D4482010:01C92E14] Subject: storage selection for embedded devices X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 16:29:54 -0000 I was wondering if anyone has extended experience in this area with embedded devices. I have a fixed embedded image which runs happily out of a 1Gig compact flash card. However I have some applications that I want to install to my device that will perform writes alot to the cf. I'm worried about reliability and degradation of the cf, so to get around this I'm looking at using an external usb hard drive or memory stick (I have 2 usb ports on my embedded devices, its a pcengines alix2c3) Is this a methodology most people use? or is simply buying a larger compact flash card the recommended approach. Ive read the sandisk wear leveling white paper, yet I also hear many people such as professional photographers swearing by the write once rule with cf cards. This leaves me to believe they are misinformed on the technology or the white paper is wrong. If someone could provide further information or recommendations that would be greatly appreciated. Thanks Philip Mullis From owner-freebsd-embedded@FreeBSD.ORG Tue Oct 14 17:02:05 2008 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61642106568F for ; Tue, 14 Oct 2008 17:02:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0269C8FC26 for ; Tue, 14 Oct 2008 17:02:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m9EGxML2066173; Tue, 14 Oct 2008 10:59:22 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 14 Oct 2008 11:00:22 -0600 (MDT) Message-Id: <20081014.110022.635731567.imp@bsdimp.com> To: philip.mullis@syx.ca From: "M. Warner Losh" In-Reply-To: <48F4C02F.1060407@syx.ca> References: <48F4C02F.1060407@syx.ca> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-embedded@FreeBSD.org Subject: Re: storage selection for embedded devices X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 17:02:05 -0000 In message: <48F4C02F.1060407@syx.ca> Philip Mullis writes: : I was wondering if anyone has extended experience in this area with : embedded devices. : : I have a fixed embedded image which runs happily out of a 1Gig compact : flash card. : : However I have some applications that I want to install to my device : that will perform writes alot to the cf. : : I'm worried about reliability and degradation of the cf, so to get : around this I'm looking at using an external usb hard drive or memory : stick (I have 2 usb ports on my embedded devices, its a pcengines alix2c3) : : Is this a methodology most people use? or is simply buying a larger : compact flash card the recommended approach. I've deployed CF cards into systems for a number of years (since 2000). They are way more reliable than spinning media in the environments that I deploy my company's gear into. We have most of the CF dedicated to a read-only partition. A small modification partition was also provided. We also had a 'fail safe' tarball on the read-only part of the media that would revert the box to a default state that was sane in the event of data corruption on the /mod filesystem. The reason we bothered with that in one of our products was due to a FreeBSD bug in the vm that caused oddness in the mmapped file we used to store our configuration. I've also tried to wear out a CF part by writing to the part, both directly and through a filesystem, millions of times. I was unable to keep a machine running long enough to cause a failure (my mistake was doing it in a lab where people liked to unplug things). We had about one part in 100 wear out in the first year of being in the field. It was believed, but never confirmed, that many of these failures were due to static discharge when changing the part out rather than a failure of the flash cell... : Ive read the sandisk wear leveling white paper, yet I also hear many : people such as professional photographers swearing by the write once : rule with cf cards. This leaves me to believe they are misinformed on : the technology or the white paper is wrong. They are misinformed. Very misinformed. Given how cheap CF cards are these days, it is cheap insurance for them to do a 'write once' with their pictures. Since their living is critically dependent on every picture being perfect, I can see their paranoia. Especially if there's a step that involves taking the flash from the camera and putting it into a reader. The more times you do this, the greater the chance for a static event to damage the part. On the other hand, my main console server is running off a SD part that's been through the wash three times (bad habit of mine: leaving these things in my jeans and not checking the pockets carefully enough). : If someone could provide further information or recommendations that : would be greatly appreciated. Hope this helps. Warner From owner-freebsd-embedded@FreeBSD.ORG Tue Oct 14 17:49:39 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A050C1065687 for ; Tue, 14 Oct 2008 17:49:39 +0000 (UTC) (envelope-from olivier@gautherot.net) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by mx1.freebsd.org (Postfix) with ESMTP id 7F16E8FC08 for ; Tue, 14 Oct 2008 17:49:39 +0000 (UTC) (envelope-from olivier@gautherot.net) Received: by rv-out-0506.google.com with SMTP id b25so2075141rvf.43 for ; Tue, 14 Oct 2008 10:49:38 -0700 (PDT) Received: by 10.140.201.15 with SMTP id y15mr5076284rvf.145.1224005234920; Tue, 14 Oct 2008 10:27:14 -0700 (PDT) Received: by 10.141.113.11 with HTTP; Tue, 14 Oct 2008 10:27:14 -0700 (PDT) Message-ID: Date: Tue, 14 Oct 2008 15:27:14 -0200 From: "Olivier Gautherot" To: "M. Warner Losh" In-Reply-To: <20081014.110022.635731567.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48F4C02F.1060407@syx.ca> <20081014.110022.635731567.imp@bsdimp.com> Cc: freebsd-embedded@freebsd.org Subject: Re: storage selection for embedded devices X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 17:49:39 -0000 Philip, Warner, On Tue, Oct 14, 2008 at 3:00 PM, M. Warner Losh wrote: > In message: <48F4C02F.1060407@syx.ca> > Philip Mullis writes: > : I was wondering if anyone has extended experience in this area with > : embedded devices. > : > : I have a fixed embedded image which runs happily out of a 1Gig compact > : flash card. > : > : However I have some applications that I want to install to my device > : that will perform writes alot to the cf. > > I've deployed CF cards into systems for a number of years (since > 2000). They are way more reliable than spinning media in the > environments that I deploy my company's gear into. > > We have most of the CF dedicated to a read-only partition. A small > modification partition was also provided. I wonder if you're talking about the same thing (may be just me...) Philip, what frequency of writes are you talking about? I think this is key to the discussion. Are you planning enough RAM to avoid swap? Can your system count with a RAM disk and regular dump of the content to FLASH? If this is the case, a USB stick should be a safe approach. The algorithm Sandisk is referring to enhances the statistical lifespan by shuffling the cells and using spare ones when the main array wears out (trial-and-error algorithm). The typical lifespan of a cell is 100k write cycles: try to evaluate whether this is compatible with the use you plan for your device. > I've also tried to wear out a CF part by writing to the part, both > directly and through a filesystem, millions of times. I was unable to > keep a machine running long enough to cause a failure (my mistake was > doing it in a lab where people liked to unplug things). The technology has surely evolved since I last dealt with it in an industrial environment. However, I would not swear by the "millions of times" as such: Sandisk is famous for leveling the writes over the whole array. Now, if your partition is relatively empty, your device will support more cycles. In any case, using 10% of the FLASH blocks can surely lead you to the millions of cycles without problem. > : Ive read the sandisk wear leveling white paper, yet I also hear many > : people such as professional photographers swearing by the write once > : rule with cf cards. That's paranoia, especially with todays technologies. -- Olivier Gautherot olivier@gautherot.net Cel:+56 98 730 9361 www.gautherot.net http://www.linkedin.com/in/ogautherot From owner-freebsd-embedded@FreeBSD.ORG Tue Oct 14 17:50:23 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB7F41065698 for ; Tue, 14 Oct 2008 17:50:23 +0000 (UTC) (envelope-from philip.mullis@syx.ca) Received: from smtpout1.syx.ca (smtpout1.syx.ca [69.77.170.152]) by mx1.freebsd.org (Postfix) with ESMTP id 817388FC12 for ; Tue, 14 Oct 2008 17:50:23 +0000 (UTC) (envelope-from philip.mullis@syx.ca) Received: from mail.syx.ca (unknown [192.168.21.1]) by smtpout1.syx.ca (Postfix) with ESMTP id 721F6182BFA for ; Tue, 14 Oct 2008 13:50:20 -0400 (EDT) Received: from [192.168.22.188] ([192.168.22.188]) by mail.syx.ca with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 13:50:20 -0400 Message-ID: <48F4DBDC.9020904@syx.ca> Date: Tue, 14 Oct 2008 13:50:20 -0400 From: Philip Mullis User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Olivier Gautherot References: <48F4C02F.1060407@syx.ca> <20081014.110022.635731567.imp@bsdimp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2008 17:50:20.0452 (UTC) FILETIME=[53644E40:01C92E25] Cc: freebsd-embedded@freebsd.org Subject: Re: storage selection for embedded devices X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 17:50:23 -0000 In a non-busy environment I am looking at just over 100 writes,consisting of files ranging from a few 100kbytes to a max of 40mbytes each. The calculated max writes that would ever be reached in one day would be 8000. (Id love to leave these in memory and sync them of, however there is not enough memory on the alix2c3 to do this in most scenarios). Ive got the whole system down to less than 80mb which gets loaded into a read-only memory filesystem on boot leaving me with most of the cf to be mounted in as rw. I used freebsd 6.4 for the image. The Alix2c3 has 256megs Ram and is a geode 500mhz processor, it runs quite nicely, and eats less than 6watts most of the time :) Olivier Gautherot wrote: > Philip, Warner, > > On Tue, Oct 14, 2008 at 3:00 PM, M. Warner Losh wrote: > >> In message: <48F4C02F.1060407@syx.ca> >> Philip Mullis writes: >> : I was wondering if anyone has extended experience in this area with >> : embedded devices. >> : >> : I have a fixed embedded image which runs happily out of a 1Gig compact >> : flash card. >> : >> : However I have some applications that I want to install to my device >> : that will perform writes alot to the cf. >> >> I've deployed CF cards into systems for a number of years (since >> 2000). They are way more reliable than spinning media in the >> environments that I deploy my company's gear into. >> >> We have most of the CF dedicated to a read-only partition. A small >> modification partition was also provided. >> > > I wonder if you're talking about the same thing (may be just me...) > > Philip, what frequency of writes are you talking about? I think this > is key to the discussion. Are you planning enough RAM to avoid swap? > Can your system count with a RAM disk and regular dump of the content > to FLASH? If this is the case, a USB stick should be a safe approach. > > The algorithm Sandisk is referring to enhances the statistical > lifespan by shuffling the cells and using spare ones when the main > array wears out (trial-and-error algorithm). The typical lifespan of a > cell is 100k write cycles: try to evaluate whether this is compatible > with the use you plan for your device. > > > >> I've also tried to wear out a CF part by writing to the part, both >> directly and through a filesystem, millions of times. I was unable to >> keep a machine running long enough to cause a failure (my mistake was >> doing it in a lab where people liked to unplug things). >> > > The technology has surely evolved since I last dealt with it in an > industrial environment. However, I would not swear by the "millions of > times" as such: Sandisk is famous for leveling the writes over the > whole array. Now, if your partition is relatively empty, your device > will support more cycles. In any case, using 10% of the FLASH blocks > can surely lead you to the millions of cycles without problem. > > > >> : Ive read the sandisk wear leveling white paper, yet I also hear many >> : people such as professional photographers swearing by the write once >> : rule with cf cards. >> > > That's paranoia, especially with todays technologies. > > > From owner-freebsd-embedded@FreeBSD.ORG Tue Oct 14 20:30:17 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A9241065699 for ; Tue, 14 Oct 2008 20:30:17 +0000 (UTC) (envelope-from wkoszek@freebsd.czest.pl) Received: from freebsd.czest.pl (l95h.icis.pcz.pl [212.87.224.105]) by mx1.freebsd.org (Postfix) with ESMTP id 9B21C8FC22 for ; Tue, 14 Oct 2008 20:30:16 +0000 (UTC) (envelope-from wkoszek@freebsd.czest.pl) Received: from freebsd.czest.pl (l95h.icis.pcz.pl [212.87.224.105]) by freebsd.czest.pl (8.14.2/8.14.2) with ESMTP id m9EJcnav016973; Tue, 14 Oct 2008 19:38:49 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.2/8.14.2/Submit) id m9EJcnOv016972; Tue, 14 Oct 2008 19:38:49 GMT (envelope-from wkoszek) Date: Tue, 14 Oct 2008 19:38:49 +0000 From: "Wojciech A. Koszek" To: "Bruce M. Simpson" Message-ID: <20081014193849.GA16758@FreeBSD.org> Mail-Followup-To: "Bruce M. Simpson" , freebsd-embedded@freebsd.org References: <48F45A8F.8050609@incunabulum.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <48F45A8F.8050609@incunabulum.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-3.0 (freebsd.czest.pl [212.87.224.105]); Tue, 14 Oct 2008 19:38:49 +0000 (UTC) Cc: freebsd-embedded@freebsd.org Subject: Re: Recommendations for PC based logic analyzer / grabbers? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 20:30:17 -0000 On Tue, Oct 14, 2008 at 09:38:39AM +0100, Bruce M. Simpson wrote: > Does anyone know of a good, inexpensive source for PC-based logic analyzers? > > Don't need full PCI capture, full state analysis, or anything like that: > being able to look at peripheral buses, e.g. a CFI flash parallel bus, LPC, > ISA, i2c, and/or 10/100Mbit MDIO interfaces would be most useful. > > This guy has covered some of the grabber bases, however being able to get > at really small arbitrary layouts e.g. with miniature pogo pins would be > even better: > http://www.knjn.com/ShopCablesProbing.html > > I see a lot of Chinese USB2 based stuff popping up on eBay. Trouble is of > course, they require Windows, and they don't have grabbers I can easily > attach to hardware with the probe cables. > > Trouble with MiniLA is, whilst the designs are public, no one seems to be > manufacturing them. I found Tony Bybell, the maintainer of GTKWave, is > responsive and helpful to queries. My needs are exactly the same. So I'm willing to see any recommendations as a responses to your mail. If any of you have any expirience with PC-based PCI/USB oscilloscopes which are student-affordable, please share as well. Ideally, it would be a hardware being able to measure signals up to 50-60Mhz. I did however a bit of Googling and this was one of the most interesting devices: http://www.pctestinstruments.com/ Unfortunately, this product works only under Windows and the company's response about any kind of support for POSIX-compliant systems was *very* strong "NO". They claimed they have several clients working with their product under Wine and VMWare. -- Wojciech A. Koszek wkoszek@FreeBSD.org http://people.freebsd.org/~wkoszek/ From owner-freebsd-embedded@FreeBSD.ORG Thu Oct 16 11:33:19 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28CEF1065698 for ; Thu, 16 Oct 2008 11:33:19 +0000 (UTC) (envelope-from antab@valka.is) Received: from vxout-2.c.is (vxout-2.c.is [213.176.128.14]) by mx1.freebsd.org (Postfix) with ESMTP id AB3468FC26 for ; Thu, 16 Oct 2008 11:33:18 +0000 (UTC) (envelope-from antab@valka.is) Received: from mail.internet.is (mail.aknet.is [193.4.194.58]) by vxout-2.c.is (Postfix) with ESMTP id BEED455D9E8; Thu, 16 Oct 2008 11:13:33 +0000 (GMT) Received: from postur.valka.is (postur.valka.is [194.144.27.37]) by mail.internet.is (Postfix) with ESMTP id 6FE1D3A4ED; Thu, 16 Oct 2008 11:13:33 +0000 (CUT) Date: Thu, 16 Oct 2008 11:06:09 -0000 MIME-Version: 1.0 Message-ID: <061E11D86E3DFF459604DF5B36F0805F1BA6B3@salka01.valka.local> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-TNEF-Correlator: Thread-Topic: Recommendations for PC based logic analyzer / grabbers? thread-index: AckuOqtvxU1wQxK/SLqu9t2ArBfKowBQrlw1 References: <48F45A8F.8050609@incunabulum.net> <20081014193849.GA16758@FreeBSD.org> From: =?iso-8859-1?Q?Arnar_Mar_Sigur=F0sson?= To: "Wojciech A. Koszek" , "Bruce M. Simpson" X-Vodafone-MailScanner-Information: Virusskannad hja Vodafone X-Vodafone-MailScanner-ID: BEED455D9E8.03BF7 X-Vodafone-MailScanner: Found to be clean - Enginn virus fannst X-Vodafone-MailScanner-SpamCheck: ekki ruslpostur, SpamAssassin (notcached, stigagjof=0.001, required 5, autolearn=disabled, HTML_MESSAGE 0.00) X-MailScanner-From: antab@valka.is Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-embedded@freebsd.org Subject: RE: Recommendations for PC based logic analyzer / grabbers? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2008 11:33:19 -0000 -----Original Message----- > From: owner-freebsd-embedded@freebsd.org on behalf of Wojciech A. = Koszek > Sent: Tue 10/14/2008 7:38 PM > To: Bruce M. Simpson > Cc: freebsd-embedded@freebsd.org > Subject: Re: Recommendations for PC based logic analyzer / grabbers? =20 > On Tue, Oct 14, 2008 at 09:38:39AM +0100, Bruce M. Simpson wrote: > > Does anyone know of a good, inexpensive source for PC-based logic = analyzers? > >=20 > > Don't need full PCI capture, full state analysis, or anything like = that: > > being able to look at peripheral buses, e.g. a CFI flash parallel = bus, LPC,=20 > > ISA, i2c, and/or 10/100Mbit MDIO interfaces would be most useful. > >=20 > > This guy has covered some of the grabber bases, however being able = to get=20 > > at really small arbitrary layouts e.g. with miniature pogo pins = would be=20 > > even better: > > http://www.knjn.com/ShopCablesProbing.html > >=20 > > I see a lot of Chinese USB2 based stuff popping up on eBay. Trouble = is of=20 > > course, they require Windows, and they don't have grabbers I can = easily=20 > > attach to hardware with the probe cables. > >=20 > Trouble with MiniLA is, whilst the designs are public, no one seems to = be=20 > manufacturing them. I found Tony Bybell, the maintainer of GTKWave, is = > responsive and helpful to queries. >=20 > My needs are exactly the same. >=20 > So I'm willing to see any recommendations as a responses to your mail. >=20 > If any of you have any expirience with PC-based PCI/USB oscilloscopes = which are > student-affordable, please share as well. Ideally, it would be a = hardware being > able to measure signals up to 50-60Mhz. >=20 > I did however a bit of Googling and this was one of the most = interesting=20 > devices: >=20 > http://www.pctestinstruments.com/ >=20 > Unfortunately, this product works only under Windows and the company's = response > about any kind of support for POSIX-compliant systems was *very* = strong "NO". > They claimed they have several clients working with their product = under Wine and > VMWare. I've also been looking for a "cheap" USB logic analyzer, but the problem = with most is the Windows only support. I was going to buy one of thous and try to = reverse engineer the communication protocol: http://www.easysync.co.uk/index.html?lang=3Den-uk&target=3Dd17.html But if anyone knows of any that supports bsd out of the box then it = would be great if anyone could point them out. _______________________________________________ freebsd-embedded@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-embedded To unsubscribe, send any mail to = "freebsd-embedded-unsubscribe@freebsd.org" From owner-freebsd-embedded@FreeBSD.ORG Thu Oct 16 22:02:31 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F7DA1065698 for ; Thu, 16 Oct 2008 22:02:31 +0000 (UTC) (envelope-from isaac@ceetoneresearch.com) Received: from madmax.bizintegrators.com (madmax.bizintegrators.com [64.94.184.54]) by mx1.freebsd.org (Postfix) with ESMTP id 10F888FC1F for ; Thu, 16 Oct 2008 22:02:30 +0000 (UTC) (envelope-from isaac@ceetoneresearch.com) Received: from [10.0.222.99] (dsl027-135-177.nyc1.dsl.speakeasy.net [216.27.135.177]) (authenticated bits=0) by madmax.bizintegrators.com (8.13.4/8.13.4) with ESMTP id m9GLmTgC027547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Oct 2008 17:48:35 -0400 (EDT) Message-Id: From: Isaac Levy To: Philip Mullis In-Reply-To: <48F4DBDC.9020904@syx.ca> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 16 Oct 2008 17:48:22 -0400 References: <48F4C02F.1060407@syx.ca> <20081014.110022.635731567.imp@bsdimp.com> <48F4DBDC.9020904@syx.ca> X-Mailer: Apple Mail (2.929.2) X-Loftmail-Check: No X-Scanned-By: MIMEDefang 2.57 on 64.94.184.88 Cc: freebsd-embedded@freebsd.org Subject: Re: storage selection for embedded devices X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2008 22:02:31 -0000 Hi all, > Olivier Gautherot wrote: >> Philip, Warner, >> >> On Tue, Oct 14, 2008 at 3:00 PM, M. Warner Losh =20 >> wrote: >> >>> In message: <48F4C02F.1060407@syx.ca> >>> Philip Mullis writes: >>> : I was wondering if anyone has extended experience in this area =20 >>> with >>> : embedded devices. >>> : >>> : I have a fixed embedded image which runs happily out of a 1Gig =20 >>> compact >>> : flash card. >>> : >>> : However I have some applications that I want to install to my =20 >>> device >>> : that will perform writes alot to the cf. >>> >>> I've deployed CF cards into systems for a number of years (since >>> 2000). They are way more reliable than spinning media in the >>> environments that I deploy my company's gear into. >>> >>> We have most of the CF dedicated to a read-only partition. A small >>> modification partition was also provided. >>> >> >> I wonder if you're talking about the same thing (may be just me...) >> >> Philip, what frequency of writes are you talking about? I think this >> is key to the discussion. Are you planning enough RAM to avoid swap? >> Can your system count with a RAM disk and regular dump of the content >> to FLASH? If this is the case, a USB stick should be a safe approach. >> >> The algorithm Sandisk is referring to enhances the statistical >> lifespan by shuffling the cells and using spare ones when the main >> array wears out (trial-and-error algorithm). The typical lifespan =20 >> of a >> cell is 100k write cycles: try to evaluate whether this is compatible >> with the use you plan for your device. >> >> >> >>> I've also tried to wear out a CF part by writing to the part, both >>> directly and through a filesystem, millions of times. I was =20 >>> unable to >>> keep a machine running long enough to cause a failure (my mistake =20= >>> was >>> doing it in a lab where people liked to unplug things). >>> >> >> The technology has surely evolved since I last dealt with it in an >> industrial environment. However, I would not swear by the "millions =20= >> of >> times" as such: Sandisk is famous for leveling the writes over the >> whole array. Now, if your partition is relatively empty, your device >> will support more cycles. In any case, using 10% of the FLASH blocks >> can surely lead you to the millions of cycles without problem. >> >> >> >>> : Ive read the sandisk wear leveling white paper, yet I also hear =20= >>> many >>> : people such as professional photographers swearing by the write =20= >>> once >>> : rule with cf cards. >>> >> >> That's paranoia, especially with todays technologies. >> >> >> On Oct 14, 2008, at 1:50 PM, Philip Mullis wrote: > In a non-busy environment I am looking at just over 100 > writes,consisting of files ranging from a few 100kbytes to a max of > 40mbytes each. > > The calculated max writes that would ever be reached in one day =20 > would be > 8000. (Id love to leave these in memory and sync them of, however =20 > there > is not enough memory on the alix2c3 to do this in most scenarios). > > Ive got the whole system down to less than 80mb which gets loaded =20 > into a > read-only memory filesystem on boot leaving me with most of the cf =20 > to be > mounted in as rw. I used freebsd 6.4 for the image. > > The Alix2c3 has 256megs Ram and is a geode 500mhz processor, it runs > quite nicely, and eats less than 6watts most of the time :) > I just wanted to chime in with some metrics, (although lacking total =20 context/details): =46rom a presentation on the NanoBSD build scripts, on FreeBSD, here's =20= this: -- http://www.bsdcan.org/2006/papers/nanobsd.pdf Page 12 of the slides states: Counting flash writes + 200.000 writes, worst case: =96Superblock updated 1/s =3D 55 hours lifetime =96File written 1/m =3D 138 days lifetime =96File written 1/h =3D 22 years lifetime =96File written 1/d =3D 547 years lifetime -- Now, the details of the writes is not clear here, but the point is =20 clear- writes to CF cards *must* be minimized. After working with =20 Soekris boards for years, and now PCEngines, I can testify that =20 typical UNIX installs on CF cards, (lots of writes), wrecks the cards =20= fast. CF cards do funky wear-leveling stuff, so tricks I've seen people try =20= which move files around simply exacerbate the problem... -- Here's a general approach to CF as boot drive use, (and the purpose of =20= the NanoBSD build scripts on FreeBSD): 1) obviously: Tiny Kernel, userland, etc... stripped down system to =20 taste/sanity 2) 4 notable partitions on CF media: - boot sector - 1st half, read-only root and userland - 2nd half, read-only root and userland - a small partition to mount as needed and write config files to =20 (is unmounted unless a config needs to be written) For system updates, build a new image, and dd it to the second =20 partition- reset bootloader to boot from second partition, and =20 viola... minimal writes. This is very flexible, can be piped over =20 ssh, etc... 3) A couple of memory disks for /etc /var and /tmp, (5mb each is Nano =20= default)- /etc gets the files from the small r/w partition above. That's just a quick conceptual overview of one successful method of =20 running UNIX on CF cards- hope it's helpful! More info specifically =20 on NanoBSD can be found here: http://www.freebsd.org/doc/en/articles/nanobsd/index.html I'd love to know what similar systems exist for other UNIX systems if =20= anybody has done anything interesting?! (esp. any noteworthy PicoBSD =20= differences) Best, .ike From owner-freebsd-embedded@FreeBSD.ORG Fri Oct 17 11:34:50 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C33331065686 for ; Fri, 17 Oct 2008 11:34:50 +0000 (UTC) (envelope-from jkv@unixcluster.dk) Received: from mail1-hoer.fullrate.dk (mail1-hoer.fullrate.dk [90.185.1.42]) by mx1.freebsd.org (Postfix) with ESMTP id 83CE08FC13 for ; Fri, 17 Oct 2008 11:34:50 +0000 (UTC) (envelope-from jkv@unixcluster.dk) Received: from unixcluster.dk (unknown [90.185.104.134]) by mail1-hoer.fullrate.dk (Postfix) with ESMTP id 2513A50F0C for ; Mon, 13 Oct 2008 20:07:45 +0200 (CEST) Received: from jkvs-macbook.local (unknown [10.0.0.148]) by unixcluster.dk (Postfix) with ESMTPSA id E769511442 for ; Mon, 13 Oct 2008 20:07:44 +0200 (CEST) Message-ID: <48F38E70.3020201@unixcluster.dk> Date: Mon, 13 Oct 2008 20:07:44 +0200 From: jkv User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: freebsd-embedded@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Problems with updatep2(nanobsd) on soekris 4801 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2008 11:34:50 -0000 Hi, Im currently experiencing some unexpected problems on my nanobsd(freebsd 7.0-release) running on a soekris 4801. The system have been running good for some time, but yesterday i decided to update the system with a few more packages. As described in the documentations i made a new image(using the same nanobsd conf file as i used at the initial setup) and tried to update partition 2 with the updatep2 script, but for some reason this causes my system to crash. Any ideas? Regards, Johnny (10.0.0.45 is the freebsd which i use for compiling the images) nanobsd# nc 10.0.0.45 5555 | sh updatep2 ad1: FAILURE - device detached ad1: detached g_vfs_done():ad1s1a[READ(offset=376012800, length=11776)]error = 6 vnode_pager_getpages: I/O read error Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc04cedb1 stack pointer = 0x28:0xc8008a80 frame pointer = 0x28:0xc8008a80 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1046 (cron) trap number = 12 panic: page fault Uptime: 4m51s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort Some additional information: # fdisk /dev/ad1 ******* Working on device /dev/ad1 ******* parameters extracted from in-core disklabel are: cylinders=3933 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=3933 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 1826433 (891 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 787/ head 15/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 1826559, size 1826433 (891 Meg), flag 0 beg: cyl 788/ head 1/ sector 1; end: cyl 551/ head 15/ sector 63 The data for partition 3 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 3652992, size 11088 (5 Meg), flag 0 beg: cyl 552/ head 0/ sector 1; end: cyl 562/ head 15/ sector 63 The data for partition 4 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 3664080, size 300384 (146 Meg), flag 0 beg: cyl 563/ head 0/ sector 1; end: cyl 860/ head 15/ sector 63 # # mount /dev/ad1s1a on / (ufs, local, read-only) devfs on /dev (devfs, local) /dev/md0 on /etc (ufs, local) /dev/md1 on /var (ufs, local) From owner-freebsd-embedded@FreeBSD.ORG Fri Oct 17 11:34:51 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 114041065687 for ; Fri, 17 Oct 2008 11:34:51 +0000 (UTC) (envelope-from jkv@unixcluster.dk) Received: from mail1-hoer.fullrate.dk (mail1-hoer.fullrate.dk [90.185.1.42]) by mx1.freebsd.org (Postfix) with ESMTP id 83E078FC16 for ; Fri, 17 Oct 2008 11:34:50 +0000 (UTC) (envelope-from jkv@unixcluster.dk) Received: from unixcluster.dk (unknown [90.185.104.134]) by mail1-hoer.fullrate.dk (Postfix) with ESMTP id 273C550A6A for ; Mon, 13 Oct 2008 18:53:08 +0200 (CEST) Received: from jkvs-macbook.local (unknown [10.0.0.148]) by unixcluster.dk (Postfix) with ESMTPSA id BB96911442 for ; Mon, 13 Oct 2008 18:53:08 +0200 (CEST) Message-ID: <48F37CF3.3000906@unixcluster.dk> Date: Mon, 13 Oct 2008 18:53:07 +0200 From: jkv User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: freebsd-embedded@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Problems with updatep2(nanobsd) on soekris 4801 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2008 11:34:51 -0000 Hi, Im currently experiencing some unexpected problems on my nanobsd(freebsd 7.0-release) running on a soekris 4801. The system have been running good for some time, but yesterday i decided to update the system with a few more packages. As described in the documentations i made a new image(using the same nanobsd conf file as i used at the initial setup) and tried to update partition 2 with the updatep2 script, but for some reason this causes my system to crash. Any ideas? Regards, Johnny (10.0.0.45 is the freebsd which i use for compiling the images) nanobsd# nc 10.0.0.45 5555 | sh updatep2 ad1: FAILURE - device detached ad1: detached g_vfs_done():ad1s1a[READ(offset=376012800, length=11776)]error = 6 vnode_pager_getpages: I/O read error Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc04cedb1 stack pointer = 0x28:0xc8008a80 frame pointer = 0x28:0xc8008a80 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1046 (cron) trap number = 12 panic: page fault Uptime: 4m51s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort Some additional information: # fdisk /dev/ad1 ******* Working on device /dev/ad1 ******* parameters extracted from in-core disklabel are: cylinders=3933 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=3933 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 1826433 (891 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 787/ head 15/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 1826559, size 1826433 (891 Meg), flag 0 beg: cyl 788/ head 1/ sector 1; end: cyl 551/ head 15/ sector 63 The data for partition 3 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 3652992, size 11088 (5 Meg), flag 0 beg: cyl 552/ head 0/ sector 1; end: cyl 562/ head 15/ sector 63 The data for partition 4 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 3664080, size 300384 (146 Meg), flag 0 beg: cyl 563/ head 0/ sector 1; end: cyl 860/ head 15/ sector 63 # # mount /dev/ad1s1a on / (ufs, local, read-only) devfs on /dev (devfs, local) /dev/md0 on /etc (ufs, local) /dev/md1 on /var (ufs, local) From owner-freebsd-embedded@FreeBSD.ORG Fri Oct 17 13:09:40 2008 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7294106568E for ; Fri, 17 Oct 2008 13:09:40 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id 566448FC23 for ; Fri, 17 Oct 2008 13:09:39 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from [78.110.49.49] (helo=quasar.ht-systems.ru) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1Kqp5E-000694-NA; Fri, 17 Oct 2008 17:09:36 +0400 Received: by quasar.ht-systems.ru (Postfix, from userid 1024) id 90E2C74E01; Fri, 17 Oct 2008 17:09:35 +0400 (MSD) Date: Fri, 17 Oct 2008 17:09:30 +0400 From: Stanislav Sedov To: jkv Message-Id: <20081017170930.2487dd9d.stas@FreeBSD.org> In-Reply-To: <48F38E70.3020201@unixcluster.dk> References: <48F38E70.3020201@unixcluster.dk> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Fri__17_Oct_2008_17_09_30_+0400_hMy=T=qYY98UkWnj" Cc: freebsd-embedded@freebsd.org Subject: Re: Problems with updatep2(nanobsd) on soekris 4801 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2008 13:09:40 -0000 --Signature=_Fri__17_Oct_2008_17_09_30_+0400_hMy=T=qYY98UkWnj Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 13 Oct 2008 20:07:44 +0200 jkv mentioned: > Hi, >=20 > Im currently experiencing some unexpected problems on my nanobsd(freebsd= =20 > 7.0-release) running on a soekris 4801. > The system have been running good for some time, but yesterday i decided= =20 > to update the system with a few more packages. > As described in the documentations i made a new image(using the same=20 > nanobsd conf file as i used at the initial setup) and tried to update=20 > partition 2 with the updatep2 script, but for some reason this causes my= =20 > system to crash. >=20 > Any ideas? >=20 > Regards, > Johnny >=20 > (10.0.0.45 is the freebsd which i use for compiling the images) >=20 > nanobsd# nc 10.0.0.45 5555 | sh updatep2 >=20 > >=20 > ad1: FAILURE - device detached > ad1: detached > g_vfs_done():ad1s1a[READ(offset=3D376012800, length=3D11776)]error =3D 6 > vnode_pager_getpages: I/O read error >=20 Looks like your hard drive failed. --=20 Stanislav Sedov ST4096-RIPE --Signature=_Fri__17_Oct_2008_17_09_30_+0400_hMy=T=qYY98UkWnj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkj4jo8ACgkQK/VZk+smlYHOnwCfXCGScmf/e/h6ReCnxAs3nfUd lCgAn3H4xtnYfmrBCqbmOe9aHmEa3VL6 =TAAW -----END PGP SIGNATURE----- --Signature=_Fri__17_Oct_2008_17_09_30_+0400_hMy=T=qYY98UkWnj--