From bugmaster at FreeBSD.org Mon Oct 6 11:06:53 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 6 11:07:30 2008 Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org Message-ID: <200810061106.m96B6qKE035430@freefall.freebsd.org> 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 bms at incunabulum.net Mon Oct 6 17:21:49 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon Oct 6 17:21:56 2008 Subject: Most useful JTAG page ever. Message-ID: <48EA492B.6040804@incunabulum.net> At least two folk have asked me for this link: http://www.freelabs.com/~whitis/electronics/jtag/ He hits the nail on the head, explains clearly the political and economic problems JTAG has faced, and explains graphically how it fits together with clear schematic diagrams. cheers BMS From stevefranks at ieee.org Mon Oct 6 21:13:19 2008 From: stevefranks at ieee.org (Steve Franks) Date: Mon Oct 6 21:14:07 2008 Subject: Most useful JTAG page ever. In-Reply-To: <48EA492B.6040804@incunabulum.net> References: <48EA492B.6040804@incunabulum.net> Message-ID: <539c60b90810061348w5120260fo25762ee06883da77@mail.gmail.com> On Mon, Oct 6, 2008 at 10:21 AM, Bruce M Simpson wrote: > At least two folk have asked me for this link: > > http://www.freelabs.com/~whitis/electronics/jtag/ > > He hits the nail on the head, explains clearly the political and economic > problems JTAG has faced, and explains graphically how it fits together with > clear schematic diagrams. > > cheers > BMS > _______________________________________________ > 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" > Note that ports/devel/urjtag has become a relatively comprehensive tool for operating jtag dongles with bsdl & svf files. It operates on alot of the things mentioned as properietary or difficult in this document, but the Xilinx brand cable is still slow (ft2232 cables are best). Yes, I am the new maintainer, so I'm biased ;) Steve From bms at incunabulum.net Tue Oct 7 01:28:18 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue Oct 7 01:28:24 2008 Subject: Most useful JTAG page ever. In-Reply-To: <539c60b90810061348w5120260fo25762ee06883da77@mail.gmail.com> References: <48EA492B.6040804@incunabulum.net> <539c60b90810061348w5120260fo25762ee06883da77@mail.gmail.com> Message-ID: <48EABB2F.8060408@incunabulum.net> Steve Franks wrote: > Note that ports/devel/urjtag has become a relatively comprehensive > tool for operating jtag dongles with bsdl & svf files. It operates on > alot of the things mentioned as properietary or difficult in this > document, but the Xilinx brand cable is still slow (ft2232 cables are > best). Yes, I am the new maintainer, so I'm biased ;) > urjtag has already been a most excellent and useful tool for tracking that flash writes were doing the right thing on Friday (got U-Boot onto the Linksys NSLU2, with help from Rink Springer and Rafal Jaworowski), thanks for taking the helm. I have a USB Altera ByteBlaster clone on order from Hong Kong, I'll see how it fares with urjtag when it arrives. [I hear the BDI3000 is the "must have" fashion accessory this year, for folk who have bankroll though.] At the moment I'm trying to figure out where I've gone wrong with the JTAG pinout for the Freecom FSG3. Its shipping version of RedBoot is a bit friendlier than the NSLU2's. cheers BMS From bms at incunabulum.net Tue Oct 7 01:40:41 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue Oct 7 01:40:48 2008 Subject: Problems with NSLU2 and U-Boot Message-ID: <48EABE17.3010104@incunabulum.net> I am trying to get the NSLU2 to natively boot FreeBSD from flash itself w/o any TFTP server. Thanks to Rink and Rafal's help, I managed to get U-Boot installed and working on the Linksys NSLU2. Using hints from the OpenMoko page, I generated a U-Boot image from an NSLU2 kernel build from -CURRENT, and managed to boot it over the network -- however -- the kernel is not coming up. mkimage hints here: http://wiki.openmoko.org/wiki/FreeBSD If I add 'options VERBOSE_SYSINIT' to the kernel config, I can see that the kernel is going off into space... right after init_turnstile0() is called. MMU problems? [I had to track this down with nm, as addr2line seems to only print the first patch.] I saw similar symptoms when trying to boot with the simple ELF trampoline, from both RedBoot and U-Boot on the NSLU2. An ELF kernel loaded into RedBoot seemed to work just fine, providing the load address was given explicitly. [Recall: The problem with RedBoot on the NSLU2 is that its boot-time settings cannot be changed, it is locked into executing a Linux-style image at a hard wired address, so a change of firmware may be necessary in order to boot FreeBSD natively on that platform.] cheers BMS From bms at incunabulum.net Tue Oct 7 04:15:09 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue Oct 7 04:15:17 2008 Subject: Freecom FSG3 pc Message-ID: <48EAE24A.2070205@incunabulum.net> I tried booting a kernel on the FSG3 once again. The board will power from both 5V and 12V supply voltages, this is mostly to deal with driving a PATA drive. The default Redboot config can be rewritten with fconfig -l, which is useful -- it expects to load a Linux zImage style kernel from the first partition, see here: http://www.nslu2-linux.org/wiki/FSG3/FisCmds It is necessary to hold down the config reset button at the back to get Redboot to init the network ports. You need to CTRL-C it to stop it loading a recovery Linux kernel image. Kernel config is mostly as per NSLU2, but with some twists. There is an onboard Via VT6421A SATA/PATA controller, and an NEC EHCI controller, however neither of them appear to probe on the PCI bus. it looks like neither of them are activated by the firmware so they most likely need to have base addresses set up from scratch by the PCI code, something I believe we don't yet support? It appears the PHY on board should be supported by the "rlswitch" driver. I keep getting this even with full miibus compiled in: %%% npe0: on ixp0 npe0: [MPSAFE] npe0: [ITHREAD] npe0: using npe.0.mac=A override npe0: using npe.0.mii=A override npe0: remember to fix rx q setup npe0: using npe.0.phy=5 override npe0: Cannot find my PHY. device_attach: npe0 attach returned 6 npe1: on ixp0 npe1: [MPSAFE] npe1: [ITHREAD] npe1: using npe.1.mac=B override npe1: using npe.1.mii=A override npe1: remember to fix rx q setup npe1: using npe.1.phy=4 override npe1: Cannot find my PHY. device_attach: npe1 attach returned 6 %%% I've tried forcing the PHY numbers to what's in a Linux dmesg (5 and 4 respectively), hints look like this: %%% hint.npe.0.at="ixp0" hint.npe.0.mac="A" hint.npe.0.mii="A" hint.npe.0.phy=5 hint.npe.1.at="ixp0" hint.npe.1.mac="B" hint.npe.1.mii="A" hint.npe.1.phy=4 %%% No joy, even if I switch the PHY numbers around. Which datasheets am I going to have to look at? ... I've attached a boot.log for the curious. cheers BMS -------------- next part -------------- +Ethernet eth0: MAC address 00:01:db:00:54:d0 IP: 192.168.123.150/255.255.255.0, Gateway: 192.168.123.1 Default server: 0.0.0.0, DNS server IP: 192.168.123.1 RedBoot(tm) bootstrap and debug environment [ROM] Red Hat certified release, version 1.94 - built 11:47:48, Jun 10 2005 Platform: Freecom Storage Gateway (FSG) (XScale) BE Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc. RAM: 0x00000000-0x04000000, 0x0001db58-0x03fd0000 available FLASH: 0x50000000 - 0x50400000, 32 blocks of 0x00020000 bytes each. FREECOM ermergency button pressed! == Executing boot script in 5.000 seconds - enter ^C to abort ^C RedBoot> help load Load a file load [-r] [-v] [-d] [-h ] [-m ] [-c ] [-b ] RedBoot> load -h 192.168.123.17 -v -b 0x200000 kernel Using default protocol (TFTP) Address offset = 0x40000000 Entry point: 0x00200100, address range: 0x00200000-0x00423518 RedBoot> go GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #9: Tue Oct 7 05:08:49 BST 2008 root@anglepoise.lon.incunabulum.net:/home/obj/nanobsd.testusb/arm/home/bms/svn/head/sys/FSG3 Preloaded elf kernel "elf kernel" at 0xc043a2bc. CPU: IXP425 266MHz rev 1 (ARMv5TE) (XScale core) DC enabled IC enabled WB enabled LABT branch prediction enabled 32KB/32B 32-way Instruction cache 32KB/32B 32-way write-back-locking Data cache real memory = 67108864 (64 MB) Physical memory chunk(s): 0x10544000 - 0x13ec5fff, 60301312 bytes (14722 pages) avail memory = 59650048 (56 MB) ULE: setup cpu 0 firmware: 'npe_fw' version 0: 35900 bytes loaded at 0xc0419b04 random: mem: null: ixp0: on motherboard pcib0: on ixp0 pci0: on pcib0 pci0: domain=0, physical bus=0 ixpclk0: on ixp0 ixpiic0: on ixp0 iicbb0: on ixpiic0 iicbus0: on iicbb0 master-only iic0: on iicbus0 x1226rtc0: at addr 0x6f on iicbus0 x1226rtc0: registered as a time-of-day clock (resolution 1000us) ixpwdog0: on ixp0 uart0: on ixp0 uart0: [FILTER] uart0: fast interrupt uart0: console (115200,n,8,1) uart1: on ixp0 uart1: [FILTER] uart1: fast interrupt ixpqmgr0: on ixp0 ixpqmgr0: [MPSAFE] ixpqmgr0: [ITHREAD] ixpqmgr0: [MPSAFE] ixpqmgr0: [ITHREAD] npe0: on ixp0 npe0: [MPSAFE] npe0: [ITHREAD] npe0: using npe.0.mac=A override npe0: using npe.0.mii=A override npe0: remember to fix rx q setup npe0: using npe.0.phy=4 override npe0: Cannot find my PHY. device_attach: npe0 attach returned 6 npe1: on ixp0 npe1: [MPSAFE] npe1: [ITHREAD] npe1: using npe.1.mac=B override npe1: using npe.1.mii=A override npe1: remember to fix rx q setup npe1: using npe.1.phy=5 override npe1: Cannot find my PHY. device_attach: npe1 attach returned 6 ixpclk0: [FILTER] Timecounter "IXP425 Timer" frequency 66666600 Hz quality 1000 Timecounters tick every 10.000 msec lo0: bpf attached Trying to mount root from ufs:/dev/da0s1a Manual root filesystem specification: : Mount using filesystem eg. ufs:/dev/da0a ? List valid disk boot devices Abort manual input mountroot> From gary.jennejohn at freenet.de Tue Oct 7 11:23:35 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Tue Oct 7 11:23:42 2008 Subject: Most useful JTAG page ever. In-Reply-To: <48EABB2F.8060408@incunabulum.net> References: <48EA492B.6040804@incunabulum.net> <539c60b90810061348w5120260fo25762ee06883da77@mail.gmail.com> <48EABB2F.8060408@incunabulum.net> Message-ID: <20081007132322.0fa40197@ernst.jennejohn.org> On Tue, 07 Oct 2008 02:28:15 +0100 Bruce M Simpson wrote: > I have a USB Altera ByteBlaster clone on order from Hong Kong, I'll see > how it fares with urjtag when it arrives. [I hear the BDI3000 is the > "must have" fashion accessory this year, for folk who have bankroll though.] > I have a BDI2000. When I asked a colleague, who sells BDIs, whether it was worth upgrading he answered "No" rather emphatically. --- Gary Jennejohn From bms at incunabulum.net Wed Oct 8 18:16:24 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Wed Oct 8 18:16:29 2008 Subject: Broadcom MIPS kernel bit-rot Message-ID: <48ECF8F5.8090805@incunabulum.net> It appears that the build for Broadcom MIPS kernels has bit-rotted. I am able to build a kernel with SENTRY5 config, however it will no longer boot on the WGT634U. The root cause appears to be a change in the ld behaviour. For whatever reason, the linker will now produce an ELF kernel which has offsets pointing backwards in the file, even though it didn't before, and "makeoptions LDSCRIPT_NAME" is being used to coax it to use the config which used to work for CFE. CFE, of course, is unable to load ELF kernels via TFTP, unless their program headers appear in the order in which they are actually accessed. This is purely a limitation of how CFE implements TFTP ELF load. Looking in the Perforce history I can't see anything which could obviously have broken this, it is clear however that ld is now behaving very differently. Questions: Has the version of ld/binutils in FreeBSD changed in -CURRENT since the MIPS code was imported to the main tree? That's all I can really think of at the moment, not much I can try here. U-Boot isn't on the Sentry5. cheers BMS From imp at bsdimp.com Wed Oct 8 21:07:08 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Oct 8 21:07:14 2008 Subject: Broadcom MIPS kernel bit-rot In-Reply-To: <48ECF8F5.8090805@incunabulum.net> References: <48ECF8F5.8090805@incunabulum.net> Message-ID: <20081008.150716.570083949.imp@bsdimp.com> 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... Warner In message: <48ECF8F5.8090805@incunabulum.net> Bruce M Simpson writes: : It appears that the build for Broadcom MIPS kernels has bit-rotted. : : I am able to build a kernel with SENTRY5 config, however it will no : longer boot on the WGT634U. : : The root cause appears to be a change in the ld behaviour. For whatever : reason, the linker will now produce an ELF kernel which has offsets : pointing backwards in the file, even though it didn't before, and : "makeoptions LDSCRIPT_NAME" is being used to coax it to use the config : which used to work for CFE. : : CFE, of course, is unable to load ELF kernels via TFTP, unless their : program headers appear in the order in which they are actually accessed. : This is purely a limitation of how CFE implements TFTP ELF load. : : Looking in the Perforce history I can't see anything which could : obviously have broken this, it is clear however that ld is now behaving : very differently. : : Questions: : Has the version of ld/binutils in FreeBSD changed in -CURRENT since the : MIPS code was imported to the main tree? : : That's all I can really think of at the moment, not much I can try here. : U-Boot isn't on the Sentry5. : : cheers : BMS : _______________________________________________ : 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 stas at FreeBSD.org Wed Oct 8 23:23:58 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Wed Oct 8 23:24:05 2008 Subject: Problems with NSLU2 and U-Boot In-Reply-To: <48EABE17.3010104@incunabulum.net> References: <48EABE17.3010104@incunabulum.net> Message-ID: <20081009025641.e6d015bb.stas@FreeBSD.org> On Tue, 07 Oct 2008 02:40:39 +0100 Bruce M Simpson mentioned: > I am trying to get the NSLU2 to natively boot FreeBSD from flash itself > w/o any TFTP server. > > Thanks to Rink and Rafal's help, I managed to get U-Boot installed and > working on the Linksys NSLU2. > Using hints from the OpenMoko page, I generated a U-Boot image from an > NSLU2 kernel build from -CURRENT, and managed to boot it over the > network -- however -- the kernel is not coming up. > mkimage hints here: http://wiki.openmoko.org/wiki/FreeBSD > > If I add 'options VERBOSE_SYSINIT' to the kernel config, I can see that > the kernel is going off into space... right after init_turnstile0() is > called. MMU problems? > > [I had to track this down with nm, as addr2line seems to only print the > first patch.] > > I saw similar symptoms when trying to boot with the simple ELF > trampoline, from both RedBoot and U-Boot on the NSLU2. An ELF kernel > loaded into RedBoot seemed to work just fine, providing the load address > was given explicitly. > > [Recall: The problem with RedBoot on the NSLU2 is that its boot-time > settings cannot be changed, it is locked into executing a Linux-style > image at a hard wired address, so a change of firmware may be necessary > in order to boot FreeBSD natively on that platform.] > Are you sure that u-boot loads your kernel to correct address. Have you tryed loading a plain ELF image (or binary) and jumping to entry point? -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-embedded/attachments/20081008/548c1124/attachment.pgp From bms at incunabulum.net Sat Oct 11 12:10:33 2008 From: bms at incunabulum.net (Bruce M. Simpson) Date: Sat Oct 11 12:10:42 2008 Subject: FSG3 phy attempt Message-ID: <48F097B5.8010207@incunabulum.net> Hi, Here's a diff containing all my work on attempting to get the PHY up on the FSG3. It is unsuccessful but might be a starting point for someone else. I can forward my last mail to Pyun about it if that helps. thanks BMS -------------- next part -------------- Index: dev/mii/rlswitch.c =================================================================== --- dev/mii/rlswitch.c (revision 183760) +++ dev/mii/rlswitch.c (working copy) @@ -59,7 +59,8 @@ #include "miibus_if.h" //#define RL_DEBUG -#define RL_VLAN +//#define RL_VLAN +//#define RL_IS_RTL8305SB static int rlswitch_probe(device_t); static int rlswitch_attach(device_t); @@ -119,6 +120,7 @@ sc->mii_dev = device_get_parent(dev); mii = device_get_softc(sc->mii_dev); +#if 1 /* * We handle all pseudo PHY in a single instance, so never allow * non-zero * instances! @@ -127,6 +129,7 @@ device_printf(dev, "ignoring this PHY, non-zero instance\n"); return (ENXIO); } +#endif LIST_INSERT_HEAD(&mii->mii_phys, sc, mii_list); @@ -359,9 +362,11 @@ MIIBUS_WRITEREG(sc->mii_dev, 4, 25, val); #endif +#if 0 #ifdef RL_DEBUG rlswitch_phydump(dev); #endif +#endif MIIBUS_MEDIAINIT(sc->mii_dev); return (0); } Index: dev/iicbus/x1226rtc.c =================================================================== --- dev/iicbus/x1226rtc.c (revision 0) +++ dev/iicbus/x1226rtc.c (revision 0) @@ -0,0 +1,223 @@ +/*- + * Copyright (c) 2008 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 ``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 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. + */ + +#include +__FBSDID("$FreeBSD$"); + +/* + * Intersil/Xicor X1226 RTC on I2C "2-wire" bus. + * + * Note: The Linksys NSLU2 actually has an X1205 on the board. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "iicbus_if.h" +#include "clock_if.h" + +#ifndef IIC_M_WR +#define IIC_M_WR 0 /* write operation */ +#endif + +#define X1226_ADDR 0x6f /* slave address */ + +#define X1226_RTC_SIZE 8 /* size of BCD register space */ +#define X1226_SC 0x30 /* base of date registers */ +#define X1226_HR 0x32 /* hours */ +#define X1226_HR_PM 0x20 /* HR: time is PM */ +#define X1226_HR_MIL 0x80 /* HR: time is in 24 hour format */ +#define X1226_SR 0x3f /* status register */ +#define X1226_SR_WEL 0x02 /* SR: write enable latch */ +#define X1226_SR_RWEL 0x04 /* SR: register write enable latch */ + +#define MAX_IIC_DATA_SIZE 7 + +struct x1226rtc_softc { + device_t sc_dev; +}; + +static int +x1226rtc_probe(device_t dev) +{ + + /* XXX really probe? */ + device_set_desc(dev, "Intersil/Xicor X1226 RTC"); + return (0); +} + +static int +x1226rtc_attach(device_t dev) +{ + struct x1226rtc_softc *sc = device_get_softc(dev); + + sc->sc_dev = dev; + + clock_register(dev, 1000); + return (0); +} + +static int +x1226rtc_read(device_t dev, uint8_t address, uint8_t *data, uint8_t size) +{ + struct iic_msg msg[] = { + { X1226_ADDR, IIC_M_WR, 1, &address }, + { X1226_ADDR, IIC_M_RD, size, data }, + }; + + return (iicbus_transfer(dev, msg, 2)); +} + +static int +x1226rtc_write(device_t dev, uint8_t address, uint8_t *data, uint8_t size) +{ + uint8_t buffer[MAX_IIC_DATA_SIZE + 1]; + struct iic_msg msg[] = { + { X1226_ADDR, IIC_M_WR, size + 1, buffer }, + }; + + if (size > MAX_IIC_DATA_SIZE) + return (ENOMEM); + + buffer[0] = address; + memcpy(buffer + 1, data, size); + + return (iicbus_transfer(dev, msg, 1)); +} + +static uint8_t +x1226rtc_get_hours(uint8_t val) +{ + uint8_t ret; + + if ((val & X1226_HR_MIL) != 0) + ret = FROMBCD(val & 0x3f); + else if ((val & X1226_HR_PM) != 0) + ret = FROMBCD(val & 0x1f); + else + ret = FROMBCD(val & 0x1f) + 12; + + return (ret); +} + +static int +x1226rtc_gettime(device_t dev, struct timespec *ts) +{ + uint8_t date[X1226_RTC_SIZE]; + struct clocktime ct; + int error; + + error = x1226rtc_read(dev, X1226_SC, date, X1226_RTC_SIZE); + if (error == 0) { + ct.nsec = 0; + ct.sec = FROMBCD(date[0] & 0x7f); /* SC */ + ct.min = FROMBCD(date[1] & 0x7f); /* MN */ + ct.hour = x1226rtc_get_hours(date[2]); /* HR */ + ct.day = FROMBCD(date[3] & 0x3f); /* DT */ + ct.mon = FROMBCD(date[4] & 0x1f); /* MO */ + ct.year = FROMBCD(date[5]); /* YR */ + ct.dow = FROMBCD(date[6] & 0x07) - 1; /* DW */ + ct.year += (FROMBCD(date[7]) & 0x39) * 100; /* Y2K */ + + error = clock_ct_to_ts(&ct, ts); + if (error) { + device_printf(dev, "error %d converting to timespec\n", + error); + } + } else { + device_printf(dev, "error %d reading SRAM\n", error); + } + + return (error); +} + +static int +x1226rtc_settime(device_t dev, struct timespec *ts) +{ + uint8_t date[X1226_RTC_SIZE]; + uint8_t sr; + struct clocktime ct; + int error; + + clock_ts_to_ct(ts, &ct); + + date[0] = TOBCD(ct.sec); + date[1] = TOBCD(ct.min); + date[2] = TOBCD(ct.hour) | X1226_HR_MIL; + date[3] = TOBCD(ct.day); + date[4] = TOBCD(ct.mon); + date[5] = TOBCD(ct.year % 100); + date[6] = TOBCD(ct.dow); + date[7] = TOBCD(ct.year / 100); + + sr = X1226_SR_WEL; + error = x1226rtc_write(dev, X1226_SR, &sr, 1); + if (error) { + device_printf(dev, "failed to set %s bit\n", "WEL"); + return (EIO); + } + + sr = X1226_SR_WEL | X1226_SR_WEL; + error = x1226rtc_write(dev, X1226_SR, &sr, 1); + if (error) { + device_printf(dev, "failed to set %s bit\n", "RWEL"); + return (EIO); + } + + error = x1226rtc_write(dev, X1226_SC, date, X1226_RTC_SIZE); + if (error) + device_printf(dev, "error %d writing to SRAM\n", error); + + return (error); +} + +static device_method_t x1226rtc_methods[] = { + DEVMETHOD(device_probe, x1226rtc_probe), + DEVMETHOD(device_attach, x1226rtc_attach), + + DEVMETHOD(clock_gettime, x1226rtc_gettime), + DEVMETHOD(clock_settime, x1226rtc_settime), + + {0, 0}, +}; + +static driver_t x1226rtc_driver = { + "x1226rtc", + x1226rtc_methods, + sizeof(struct x1226rtc_softc), +}; +static devclass_t x1226rtc_devclass; + +DRIVER_MODULE(x1226rtc, iicbus, x1226rtc_driver, x1226rtc_devclass, 0, 0); +MODULE_VERSION(x1226rtc, 1); +MODULE_DEPEND(x1226rtc, iicbus, 1, 1, 1); Index: arm/xscale/ixp425/if_npe.c =================================================================== --- arm/xscale/ixp425/if_npe.c (revision 183760) +++ arm/xscale/ixp425/if_npe.c (working copy) @@ -83,6 +83,8 @@ #include #include +#include "miidevs.h" + #include #include "miibus_if.h" @@ -140,6 +142,9 @@ struct npestats *sc_stats; bus_dmamap_t sc_stats_map; bus_addr_t sc_stats_phys; /* phys addr of sc_stats */ + int sc_force_bmsr; + int sc_force_idr1; + int sc_force_idr2; }; /* @@ -244,6 +249,8 @@ static uint32_t npe_getimageid(struct npe_softc *); static int npe_setloopback(struct npe_softc *, int ena); #endif +static int npe_miibus_readreg(device_t dev, int phy, int reg); +static void npe_miibus_writereg(device_t dev, int phy, int reg, int data); /* NB: all tx done processing goes through one queue */ static int tx_doneqid = -1; @@ -733,10 +740,45 @@ if (!override_unit(dev, "phy", &sc->sc_phy, 0, MII_NPHY-1)) sc->sc_phy = npeconfig[unit].phy; + /* + * Allow PHY OUI/model and BMSR to be forced, as some boards have + * a PHY which does not have ID registers (e.g. the RTL8305SB + * on a Freecom FSG3). + */ + if (!override_unit(dev, "force_bmsr", &sc->sc_force_bmsr, 0, 0xFFFF)) + sc->sc_force_bmsr = 0; + if (!override_unit(dev, "force_idr1", &sc->sc_force_idr1, 0, 0xFFFF)) + sc->sc_force_idr1 = 0; + if (!override_unit(dev, "force_idr2", &sc->sc_force_idr2, 0, 0xFFFF)) + sc->sc_force_idr2 = 0; + KASSERT(npes[npeconfig[unit].npeid] == NULL, ("npe %u already setup", npeconfig[unit].npeid)); npes[npeconfig[unit].npeid] = sc; +#if 0 + /* + * Attempt to soft-reset the RTL8305SB. + */ + if ((MII_OUI(sc->sc_force_idr1, sc->sc_force_idr2) == + MII_OUI_xxREALTEK) && + (MII_MODEL(sc->sc_force_idr2) == MII_MODEL_xxREALTEK_RTL8305SC) && + (MII_REV(sc->sc_force_idr2) == 0x01)) { + int i; + + device_printf(sc->sc_dev, + "attempting to soft-reset RTL8305SB\n"); + npe_miibus_writereg(sc->sc_dev, 3, 0x16, 0x8000); + for (i = 0; i <= 4; i++) { + npe_miibus_writereg(sc->sc_dev, i, 0x0, 0x8000); + // restart autoneg, clear powerdown bit + npe_miibus_writereg(sc->sc_dev, i, 0x0, 0x0020); + } + // disable loopback, enable all ports. + npe_miibus_writereg(sc->sc_dev, 3, 0x16, 0x03FF); + } +#endif + return 0; } @@ -1598,6 +1640,20 @@ if (phy != sc->sc_phy) /* XXX no auto-detect */ return 0xffff; + + if (reg == MII_BMSR && sc->sc_force_bmsr != 0x0000) + return (sc->sc_force_bmsr); + if (reg == MII_PHYIDR1 && sc->sc_force_idr1 != 0x0000) + return (sc->sc_force_idr1); + if (reg == MII_PHYIDR2 && sc->sc_force_idr2 != 0x0000) + return (sc->sc_force_idr2); + +#if 1 + /* Do NOT allow PHY 5 to be read. */ + if (sc->sc_force_bmsr != 0x0000 && phy == 5) + return (0xffff); +#endif + v = (phy << NPE_MII_ADDR_SHL) | (reg << NPE_MII_REG_SHL) | NPE_MII_GO; npe_mii_mdio_write(sc, NPE_MAC_MDIO_CMD, v); @@ -1605,6 +1661,7 @@ v = npe_mii_mdio_read(sc, NPE_MAC_MDIO_STS); else v = 0xffff | NPE_MII_READ_FAIL; + return (v & NPE_MII_READ_FAIL) ? 0xffff : (v & 0xffff); #undef MAXTRIES } @@ -1617,6 +1674,13 @@ if (phy != sc->sc_phy) /* XXX */ return; + +#if 1 + /* Do NOT allow PHY 5 to be written. */ + if (sc->sc_force_bmsr != 0x0000 && phy == 5) + return; +#endif + v = (phy << NPE_MII_ADDR_SHL) | (reg << NPE_MII_REG_SHL) | data | NPE_MII_WRITE | NPE_MII_GO; Index: arm/xscale/ixp425/avila_machdep.c =================================================================== --- arm/xscale/ixp425/avila_machdep.c (revision 183760) +++ arm/xscale/ixp425/avila_machdep.c (working copy) @@ -259,6 +259,7 @@ vm_offset_t freemem_after; vm_offset_t lastaddr; uint32_t memsize; + char *p; set_cpufuncs(); lastaddr = fake_preload_metadata(); @@ -475,16 +476,29 @@ phys_avail[i++] = trunc_page(0x10000000 + memsize - 1); phys_avail[i++] = 0; phys_avail[i] = 0; - + + /* 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; + /* Do basic tuning, hz etc */ init_param1(); init_param2(physmem); kdb_init(); - /* use static kernel environment if so configured */ - if (envmode == 1) - kern_envp = static_env; - return ((void *)(kernelstack.pv_va + USPACE_SVC_STACK_TOP - sizeof(struct pcb))); } Index: arm/conf/FSG3.hints =================================================================== --- arm/conf/FSG3.hints (revision 0) +++ arm/conf/FSG3.hints (revision 0) @@ -0,0 +1,49 @@ +# $FreeBSD$ + +# +# Device wiring for the Freecom FSG3 +# + +# DBGU is unit 0 +hint.uart.0.at="ixp0" +hint.uart.0.addr=0xc8000000 +hint.uart.0.irq=15 +hint.uart.0.flags=0x10 +# USART0 is unit 1 +hint.uart.1.at="ixp0" +hint.uart.1.addr=0xc8001000 +hint.uart.1.irq=13 + +# NPE Hardware Queue Manager +hint.ixpqmgr.0.at="ixp0" + +# NPE NIC's, requires ixpqmgr +hint.npe.0.at="ixp0" +hint.npe.0.mac="A" +hint.npe.0.mii="A" +hint.npe.0.phy=5 +# XXX BMSR for PHY 5 must always be forced. +# XXX Don't use the rlswitch shared driver +# for this side of the switch; use a different OUI. +hint.npe.0.force_bmsr=0x402C +hint.npe.0.force_idr1=0x000C +hint.npe.0.force_idr2=0xC851 + +hint.npe.1.at="ixp0" +hint.npe.1.mac="B" +hint.npe.1.mii="A" +hint.npe.1.phy=4 +# Realtek RTL8305SB (Rev 1) +# XXX BMSR must always be forced -- RTL8305SB has no ID registers. +hint.npe.1.force_bmsr=0x4024 +hint.npe.1.force_idr1=0x001C +hint.npe.1.force_idr2=0xC851 + +# RTC +hint.x1226rtc.0.at="iicbus0" +hint.x1226rtc.0.addr=0x6f + +#not yet +# Slug LED +# Slug button +# Slug Buzzer Index: arm/conf/FSG3.env =================================================================== --- arm/conf/FSG3.env (revision 0) +++ arm/conf/FSG3.env (revision 0) @@ -0,0 +1 @@ +boot_verbose=YES Index: arm/conf/FSG3 =================================================================== --- arm/conf/FSG3 (revision 0) +++ arm/conf/FSG3 (revision 0) @@ -0,0 +1,153 @@ +# NSLU - kernel configuration file for FreeBSD/arm on Linksys NSLU2 +# + +machine arm +ident FSG3 + +options PHYSADDR=0x10000000 +options KERNPHYSADDR=0x10200000 +options KERNVIRTADDR=0xc0200000 # Used in ldscript.arm +options FLASHADDR=0x50000000 +options LOADERRAMADDR=0x00000000 +options STARTUP_PAGETABLE_ADDR=0x10000000 + +# XXX 0x0 is not free in NSLU2 loader, but it *might* be free +# in the U-Boot loader. +# Allow 4MB (XXX) for kernel image. +# XXX Changing this appears to bloat the tramp, why? +#options FLASHADDR=0x01d00000 +#options LOADERRAMADDR=0x01d00000 + +include "../xscale/ixp425/std.avila" +#To statically compile in device wiring instead of /boot/device.hints +hints "FSG3.hints" #Default places to look for devices. + +# For some reason the kernel ain't bootp-ing. +#env "FSG3.env" # XXX set mountroot + +# XXX need tramp w/o symbols for <1MB +#makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols +makeoptions DEBUG=-g3 #Build kernel with gdb(1) debug symbols + +makeoptions CONF_CFLAGS=-mcpu=xscale +options HZ=100 +options DEVICE_POLLING + +# XXX +options VERBOSE_SYSINIT + +# Debugging for use in -current +options KDB +options GDB +options DDB #Enable the kernel debugger + +options ALT_BREAK_TO_DEBUGGER + +#options INVARIANTS #Enable calls of extra sanity checking +#options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS +#options WITNESS #Enable checks to detect deadlocks and cycles +#options WITNESS_SKIPSPIN #Don't run witness on spinlocks for speed +#options DIAGNOSTIC + +options SCHED_ULE #ULE scheduler +options INET #InterNETworking +#options INET6 #IPv6 communications protocols +options FFS #Berkeley Fast Filesystem +options SOFTUPDATES #Enable FFS soft updates support +options UFS_ACL #Support for access control lists +options UFS_DIRHASH #Improve performance on big directories +#options NFSCLIENT #Network Filesystem Client +#options NFSSERVER #Network Filesystem Server +#options NFSLOCKD #Network Lock Manager +#options NFS_ROOT #NFS usable as /, requires NFSCLIENT +#options MSDOSFS #MSDOS Filesystem +#options CD9660 #ISO 9660 Filesystem +#options PROCFS #Process filesystem (requires PSEUDOFS) +options PSEUDOFS #Pseudo-filesystem framework +options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI +options KTRACE #ktrace(1) support +options SYSVSHM #SYSV-style shared memory +options SYSVMSG #SYSV-style message queues +options SYSVSEM #SYSV-style semaphores +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. +options BOOTP +options BOOTP_NFSROOT +options BOOTP_NFSV3 +options BOOTP_WIRED_TO=npe0 +options BOOTP_COMPAT + +options NFSCLIENT #Network Filesystem Client +options NFSLOCKD #Network Lock Manager +options NFS_ROOT #NFS usable as /, requires NFSCLIENT + +#options GEOM_MBR +#options GEOM_PART_MBR + +device mem # Memory and kernel memory devices +device pci +device uart + +# I2C Bus +device iicbus +device iicbb +device iic + +device ixpiic # I2C bus glue +device ixpwdog # watchdog timer + +device x1226rtc # I2C real-time clock + +####### netwerk + +device npe # Network Processing Engine +device npe_fw +device firmware +device qmgr # Q Manager (required by npe) + +# XXX There is an RTL8305SB with 5 physical ports. Two are configured +# as miibus PHYs, however the SB rev does NOT have ID registers, and +# attempting to probe the BMSR seems to cause problems with the PHY. +# +# The rlswitch driver is written for the RTL8305SC, which is a totally +# different chip -- the vlan register setup is not the same. +# +# ukphy is part of mii, we use that for the first port, but reject any +# attempts to read or write PHY ID 5 (npe0). +# +device mii +device rlswitch + +device ether +device bpf + +device pty +device loop + +options XSCALE_CACHE_READ_WRITE_ALLOCATE +device md # XXX .ko candidate? +device random # Entropy device + +#options ARM_USE_SMALL_ALLOC + +# XXX only needed for bootstrap rootfs from usb +#device usb +#options USB_DEBUG # XXX not needed <1MB? +#device ohci +#device ehci +#device umass +#device scbus # SCSI bus (required for SCSI) +#device da # Direct Access (disks) + +# XXX PCI devices have not yet been configured, so +# the kernel never sees the onboard VIA VT6421A. +#device atacore +#device atapci +#device atavia +#device atadisk From bms at incunabulum.net Sat Oct 11 12:19:34 2008 From: bms at incunabulum.net (Bruce M. Simpson) Date: Sat Oct 11 12:19:41 2008 Subject: HOWTO: Build NSLU2 U-Boot on FreeBSD Message-ID: <48F099D4.2050302@incunabulum.net> Thanks to Rink Springer and Rafal Jaworowski. ---------------------- Building NSLU2 U-boot firmware on FreeBSD hosts Quick start Make sure you have a JTAG adapter as a get-out-of-jail-free card in case you trash the flash, "portinstall devel/urjtag" to get a driver for it. Recommend getting one like the Olimex OCD as it has heaps more useful functionality than just rewriting the flash, and should also work with OpenOCD. 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 Fetch NSLU2 patch set from NSLU2-Linux: http://trac.nslu2-linux.org/kernel/browser/trunk/patches/u-boot/0001-ixp-Support-for-NSLU2.patch Apply (patch -p1) inside uboot-atamantb. Apply Ix*.diff (provided) inside cpu/ixp/npe. U-Boot doesn't grok being built for an RTEMS target, so it needs some sweet lovin'. Fetch encumbered NPE microcode from Intel: http://downloadcenter.intel.com/ Search for IPL_IXP400NPELIBRARY-2_1.ZIP (Yes yes, I know, we can't redistribute it, for now anyway...there will be a workaround) Unzip... Copy ./cpu/ixp/npe/IxNpeMicrocode.c.orig into uboot-atamantb/cpu/ixp/npe? Remove mkimage from tools/Makefile (it needs rentokil to build on FreeBSD; and besides, you can use "portinstall devel/u-boot" to get mkimage) Now: env CROSS_COMPILE=arm-rtems- gmake distclean env CROSS_COMPILE=arm-rtems- gmake nslu2_config env CROSS_COMPILE=arm-rtems- gmake Voila, you should have u-boot firmware images, which you can now use to reflash an NSLU2. -------------- next part -------------- --- ./cpu/ixp/npe/include/IxOsalEndianess.h.orig 2008-10-03 12:11:18.000000000 +0100 +++ ./cpu/ixp/npe/include/IxOsalEndianess.h 2008-10-03 13:11:48.000000000 +0100 @@ -59,6 +59,32 @@ /* get ntohl/ntohs/htohl/htons macros definitions for WinCE */ #include +#elif defined (__rtems__) + +# ifdef htonl +# undef htonl +# endif +# ifdef ntohl +# undef ntohl +# endif + +# if BYTE_ORDER == BIG_ENDIAN + +# define ntohl(a) (a) +# define htonl(a) (a) +# elif BYTE_ORDER == LITTLE_ENDIAN +# define SWAP_LONG(x) \ + ((__u32)( \ + (((__u32)(x) & (__u32)0x000000ffUL) << 24) | \ + (((__u32)(x) & (__u32)0x0000ff00UL) << 8) | \ + (((__u32)(x) & (__u32)0x00ff0000UL) >> 8) | \ + (((__u32)(x) & (__u32)0xff000000UL) >> 24) )) +# define ntohl(a) SWAP_LONG(a) +# define htonl(a) SWAP_LONG(a) +# else +# error meep +# endif + #else #error Unknown OS, please add a section with the include file for htonl/htons/ntohl/ntohs @@ -123,6 +149,14 @@ #define IX_OSAL_WINCE_LE +#elif defined (__rtems__) && defined (__BIG_ENDIAN) + +#define IX_OSAL_LINUX_BE /* XXX */ + +#elif defined (__rtems__) && defined (__BIG_ENDIAN) + +#define IX_OSAL_LINUX_LE /* XXX */ + #else #error Unknown OS/Endianess combination - only vxWorks BE LE, Linux BE LE, WinCE BE LE are supported -------------- next part -------------- --- ./cpu/ixp/npe/include/IxOsalMemAccess.h.orig 2008-10-03 13:24:52.000000000 +0100 +++ ./cpu/ixp/npe/include/IxOsalMemAccess.h 2008-10-03 13:26:07.000000000 +0100 @@ -324,7 +324,9 @@ #endif /* wince */ -#if defined (__vxworks) || (defined (__linux) && defined (IX_OSAL_STATIC_MEMORY_MAP)) || \ +#if defined (__vxworks) || \ + defined (__rtems__) || \ + (defined (__linux) && defined (IX_OSAL_STATIC_MEMORY_MAP)) || \ (defined (__wince) && defined (IX_OSAL_STATIC_MEMORY_MAP)) #define IX_OSAL_READ_LONG_IO(wAddr) IX_OSAL_READ_LONG_RAW(wAddr) From bms at incunabulum.net Sat Oct 11 12:41:25 2008 From: bms at incunabulum.net (Bruce M. Simpson) Date: Sat Oct 11 12:41:32 2008 Subject: Problems with NSLU2 and U-Boot In-Reply-To: <20081009025641.e6d015bb.stas@FreeBSD.org> References: <48EABE17.3010104@incunabulum.net> <20081009025641.e6d015bb.stas@FreeBSD.org> Message-ID: <48F09EF2.4060709@incunabulum.net> Stanislav Sedov wrote: > Are you sure that u-boot loads your kernel to correct address. Have > you tryed loading a plain ELF image (or binary) and jumping to entry > point? > I just tried booting kernel.bin on the NSLU2, as a raw memory image, via tftp, and got exactly the same result. I repeated it with U-Boot. It appears as though it relocates the embedded ELF image to the correct address during load and execution, but I can't be sure because I don't have any OCD capability just now. Again, the hang happens right after init_turnstile0() appears to have been called: %%% DHCP client bound to address 192.168.123.151 Using NPE0 device TFTP from server 192.168.123.17; our IP address is 192.168.123.151 Filename 'kernel.nslu2.ub'. Load address: 0x400000 Loading: ################################################################# ################################################################# ################################################################# ########### done Bytes transferred = 3013309 (2dfabd hex) => bootm ## Booting kernel from Legacy Image at 00400000 ... Image Name: kernel Image Type: ARM Unknown OS Kernel Image (uncompressed) Data Size: 3013245 Bytes = 2.9 MB Load Address: 00200000 Entry Point: 00200100 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #24: Sat Oct 11 13:13:24 BST 2008 root@anglepoise.lon.incunabulum.net:/home/obj/nanobsd.testusb/arm/home/bms/svn/head/sys/MY_NSLU subsystem 900000 0xc028127c(0)... done. subsystem 1000000 0xc0375120(0)... done. 0xc0389700(0)... done. subsystem 1800000 0xc027ecd8(0)... done. 0xc027f0d8(0xc041ca90)... done. 0xc027f0d8(0xc041cc44)... done. 0xc027f0d8(0xc0415c4c)... done. 0xc027f0d8(0xc0416008)... done. 0xc027f0d8(0xc041ce8c)... done. 0xc027f0d8(0xc0416904)... done. 0xc027f0d8(0xc041cfb8)... done. 0xc027f0d8(0xc041d510)... done. 0xc027f0d8(0xc041d96c)... done. 0xc027f0d8(0xc04168c0)... done. 0xc027f0d8(0xc041d6a0)... done. 0xc027f0d8(0xc041d65c)... done. 0xc027f0d8(0xc041d618)... done. 0xc027f0d8(0xc041d5d4)... done. 0xc027f0d8(0xc041d590)... done. 0xc027f0d8(0xc041d9b0)... done. 0xc027f0d8(0xc041687c)... done. 0xc027f0d8(0xc041eb98)... done. 0xc027f0d8(0xc0416dd4)... done. 0xc027f0d8(0xc041ec24)... done. 0xc027f0d8(0xc0416e18)... done. 0xc027f0d8(0xc041f15c)... done. 0xc027f0d8(0xc041f1a4)... done. 0xc027f0d8(0xc041f118)... done. 0xc027f0d8(0xc041f0d4)... done. 0xc027f0d8(0xc041f728)... done. 0xc027f0d8(0xc041f868)... done. 0xc027f0d8(0xc041f8ac)... done. 0xc027f0d8(0xc0416e5c)... done. 0xc027f0d8(0xc04201ac)... done. 0xc027f0d8(0xc04201f0)... done. 0xc027f0d8(0xc0420234)... done. 0xc027f0d8(0xc0420b2c)... done. 0xc027f0d8(0xc0420c50)... done. 0xc027f0d8(0xc0420ec8)... done. 0xc027f0d8(0xc0421614)... done. 0xc027f0d8(0xc0417018)... done. 0xc027f0d8(0xc0421690)... done. 0xc027f0d8(0xc04216d4)... done. 0xc027f0d8(0xc0421964)... done. 0xc027f0d8(0xc0421a68)... done. 0xc027f0d8(0xc0421c48)... done. 0xc027f0d8(0xc0421ea4)... done. 0xc027f0d8(0xc04170ac)... done. 0xc027f0d8(0xc04171c4)... done. 0xc027f0d8(0xc04223e8)... done. 0xc027f0d8(0xc04175d4)... done. 0xc027f0d8(0xc0422590)... done. 0xc027f0d8(0xc04176ec)... done. 0xc027f0d8(0xc0410388)... done. 0xc027f0d8(0xc04137c4)... done. 0xc027f0d8(0xc04227e0)... done. 0xc027f0d8(0xc0422844)... done. 0xc027f0d8(0xc0422a58)... done. 0xc027f0d8(0xc0422ae8)... done. 0xc027f0d8(0xc0422b2c)... done. 0xc027f0d8(0xc0422b70)... done. 0xc027f0d8(0xc0422dc0)... done. 0xc027f0d8(0xc0423298)... done. 0xc027f0d8(0xc0423780)... done. 0xc027f0d8(0xc0423c5c)... done. 0xc027f0d8(0xc0423e58)... done. 0xc027f0d8(0xc04240e4)... done. 0xc027f0d8(0xc042437c)... done. 0xc027f0d8(0xc042469c)... done. 0xc027f0d8(0xc0424700)... done. 0xc027f0d8(0xc0417cdc)... done. 0xc027f0d8(0xc0424898)... done. 0xc027f0d8(0xc0424854)... done. 0xc027f0d8(0xc0424ed4)... done. 0xc027f0d8(0xc04254a0)... done. 0xc027f0d8(0xc0425aa4)... done. 0xc027f0d8(0xc0425c38)... done. 0xc027f0d8(0xc0425c9c)... done. 0xc027f0d8(0xc0425d10)... done. 0xc027f0d8(0xc0414728)... done. 0xc027f0d8(0xc0425e1c)... done. 0xc027f0d8(0xc0425dd8)... done. 0xc027f0d8(0xc0414844)... done. 0xc027f0d8(0xc04264dc)... done. 0xc027f0d8(0xc04269e0)... done. 0xc027f0d8(0xc0426c68)... done. 0xc027f0d8(0xc0426c24)... done. 0xc027f0d8(0xc0426be0)... done. 0xc027f0d8(0xc0426e3c)... done. 0xc027f0d8(0xc0426ea0)... done. 0xc027f0d8(0xc0414888)... done. 0xc027f0d8(0xc04101a4)... done. 0xc027f0d8(0xc04103ec)... done. 0xc027f0d8(0xc0427470)... done. 0xc027f0d8(0xc0427848)... done. 0xc027f0d8(0xc0427934)... done. 0xc027f0d8(0xc0427a48)... done. 0xc027f0d8(0xc0427a8c)... done. 0xc027f0d8(0xc0427ad0)... done. 0xc027f0d8(0xc042845c)... done. 0xc027f0d8(0xc0428b50)... done. 0xc027f0d8(0xc04102e4)... done. 0xc027f0d8(0xc0429330)... done. 0xc027f0d8(0xc04296f4)... done. 0xc027f0d8(0xc042a174)... done. 0xc027f0d8(0xc042a1b8)... done. 0xc027f0d8(0xc042a1fc)... done. 0xc027f0d8(0xc042a240)... done. 0xc027f0d8(0xc042a284)... done. 0xc027f0d8(0xc042a2c8)... done. 0xc027f0d8(0xc042a30c)... done. 0xc027f0d8(0xc042a350)... done. 0xc027f0d8(0xc042a394)... done. 0xc027f0d8(0xc042a3d8)... done. 0xc027f0d8(0xc042a41c)... done. 0xc027f0d8(0xc042a460)... done. 0xc027f0d8(0xc042a4a4)... done. 0xc027f0d8(0xc042a4e8)... done. 0xc027f0d8(0xc042a52c)... done. 0xc027f0d8(0xc042b1c0)... done. 0xc027f0d8(0xc042b32c)... done. 0xc027f0d8(0xc042b3c0)... done. 0xc027f0d8(0xc042b800)... done. 0xc027f0d8(0xc041c084)... done. 0xc027f0d8(0xc04131dc)... done. 0xc027f0d8(0xc04102a0)... done. 0xc027f0d8(0xc042ca28)... done. 0xc027f0d8(0xc041c338)... done. 0xc027f0d8(0xc041c37c)... done. 0xc027f0d8(0xc042d01c)... done. 0xc027f0d8(0xc042d080)... done. 0xc027f0d8(0xc042d1a0)... done. 0xc027f0d8(0xc041c3c0)... done. 0xc027f0d8(0xc041c634)... done. 0xc027f0d8(0xc041c6bc)... done. 0xc027f0d8(0xc041c8a4)... done. 0xc027f0d8(0xc041c9bc)... done. 0xc027f0d8(0xc041025c)... done. 0xc029562c(0)... done. 0xc026b04c(0)... done. subsystem 1a00000 0xc037aa30(0)... done. subsystem 1ac0000 0xc0281388(0)... done. subsystem 1b00000 0xc0266bdc(0)... done. 0xc027cab4(0)... done. 0xc02816e0(0xc042aa2c)... done. 0xc02816e0(0xc0422adc)... done. 0xc02816e0(0xc0421608)... done. 0xc0293110(0xc0413964)... done. 0xc02816e0(0xc0425f14)... done. 0xc02816e0(0xc041745c)... done. 0xc0293110(0xc0417468)... done. 0xc0293110(0xc041bfe8)... done. 0xc02816e0(0xc0417470)... done. 0xc02816e0(0xc041c880)... done. 0xc0293110(0xc0423e48)... done. 0xc02816e0(0xc041c88c)... done. 0xc02816e0(0xc0421d48)... done. 0xc02816e0(0xc041f968)... done. 0xc02816e0(0xc041eb74)... done. 0xc02816e0(0xc0424458)... done. 0xc02816e0(0xc0427284)... done. 0xc02816e0(0xc0427398)... done. 0xc02816e0(0xc04245e0)... done. 0xc02816e0(0xc041eb80)... done. 0xc02816e0(0xc04275ec)... done. 0xc02816e0(0xc041c898)... done. 0xc0293110(0xc04170a4)... done. 0xc02816e0(0xc0427a3c)... done. 0xc02816e0(0xc042ca04)... done. 0xc02816e0(0xc0424a50)... done. 0xc02816e0(0xc0427b94)... done. 0xc02816e0(0xc0424a5c)... done. 0xc02816e0(0xc042ccc8)... done. 0xc02816e0(0xc04175c8)... done. 0xc02816e0(0xc0420b0c)... done. 0xc02816e0(0xc04284e0)... done. 0xc02816e0(0xc04140b8)... done. 0xc0282f2c(0)... done. 0xc02816e0(0xc0425a90)... done. 0xc02816e0(0xc0420d3c)... done. 0xc02816e0(0xc041cc30)... done. 0xc02816e0(0xc042a160)... done. 0xc03897d0(0)... done. 0xc02be458(0)... %%% It also looks as though the DDB symbol lookup isn't working. The dynamic symbol table is present in the ELF image. mkimage simply wraps the ELF image with a U-Boot header. cheers BMS From bms at incunabulum.net Sat Oct 11 12:46:03 2008 From: bms at incunabulum.net (Bruce M. Simpson) Date: Sat Oct 11 12:46:10 2008 Subject: [Fwd: Re: OpenOCD] Message-ID: <48F0A008.1040900@incunabulum.net> Forwarding here as others might also have dongles that work, and debugging NSLU2 ARM would cleary need OCD capability to figure out exactly what is going wrong here. thanks BMS -------------- next part -------------- An embedded message was scrubbed... From: Bruce M Simpson Subject: Re: OpenOCD Date: Sat, 11 Oct 2008 05:44:23 +0100 Size: 4716 Url: http://lists.freebsd.org/pipermail/freebsd-embedded/attachments/20081011/c324f041/OpenOCD.eml From outbackdingo at gmail.com Sat Oct 11 13:12:11 2008 From: outbackdingo at gmail.com (Outback Dingo) Date: Sat Oct 11 13:12:19 2008 Subject: HOWTO: Build NSLU2 U-Boot on FreeBSD In-Reply-To: <48F099D4.2050302@incunabulum.net> References: <48F099D4.2050302@incunabulum.net> Message-ID: <5635aa0d0810110612l4a5abf79ic2394885d865c888@mail.gmail.com> I know its a bit off topic but it would be nice to see FreeBSD running on some other pieces of equiptment like a Ubiquiti NS2 or PS2 On Sat, Oct 11, 2008 at 7:19 PM, Bruce M. Simpson wrote: > Thanks to Rink Springer and Rafal Jaworowski. > > ---------------------- > > Building NSLU2 U-boot firmware on FreeBSD hosts > > Quick start > > Make sure you have a JTAG adapter as a get-out-of-jail-free card in case > you trash the flash, "portinstall devel/urjtag" to get a driver for it. > Recommend getting one like the Olimex OCD as it has heaps more useful > functionality than just rewriting the flash, and should also work with > OpenOCD. > > 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 > > Fetch NSLU2 patch set from NSLU2-Linux: > > http://trac.nslu2-linux.org/kernel/browser/trunk/patches/u-boot/0001-ixp-Support-for-NSLU2.patch > > Apply (patch -p1) inside uboot-atamantb. > > Apply Ix*.diff (provided) inside cpu/ixp/npe. > U-Boot doesn't grok being built for an RTEMS target, > so it needs some sweet lovin'. > > Fetch encumbered NPE microcode from Intel: > http://downloadcenter.intel.com/ > Search for IPL_IXP400NPELIBRARY-2_1.ZIP > (Yes yes, I know, we can't redistribute it, for now anyway...there will > be a workaround) > > Unzip... > Copy ./cpu/ixp/npe/IxNpeMicrocode.c.orig into uboot-atamantb/cpu/ixp/npe? > > Remove mkimage from tools/Makefile (it needs rentokil to build on FreeBSD; > and besides, you can use "portinstall devel/u-boot" to get mkimage) > > Now: > > env CROSS_COMPILE=arm-rtems- gmake distclean > env CROSS_COMPILE=arm-rtems- gmake nslu2_config > env CROSS_COMPILE=arm-rtems- gmake > > Voila, you should have u-boot firmware images, which you can now use to > reflash an NSLU2. > > > > --- ./cpu/ixp/npe/include/IxOsalEndianess.h.orig 2008-10-03 > 12:11:18.000000000 +0100 > +++ ./cpu/ixp/npe/include/IxOsalEndianess.h 2008-10-03 > 13:11:48.000000000 +0100 > @@ -59,6 +59,32 @@ > /* get ntohl/ntohs/htohl/htons macros definitions for WinCE */ > #include > > +#elif defined (__rtems__) > + > +# ifdef htonl > +# undef htonl > +# endif > +# ifdef ntohl > +# undef ntohl > +# endif > + > +# if BYTE_ORDER == BIG_ENDIAN > + > +# define ntohl(a) (a) > +# define htonl(a) (a) > +# elif BYTE_ORDER == LITTLE_ENDIAN > +# define SWAP_LONG(x) \ > + ((__u32)( \ > + (((__u32)(x) & (__u32)0x000000ffUL) << 24) | \ > + (((__u32)(x) & (__u32)0x0000ff00UL) << 8) | \ > + (((__u32)(x) & (__u32)0x00ff0000UL) >> 8) | \ > + (((__u32)(x) & (__u32)0xff000000UL) >> 24) )) > +# define ntohl(a) SWAP_LONG(a) > +# define htonl(a) SWAP_LONG(a) > +# else > +# error meep > +# endif > + > #else > > #error Unknown OS, please add a section with the include file for > htonl/htons/ntohl/ntohs > @@ -123,6 +149,14 @@ > > #define IX_OSAL_WINCE_LE > > +#elif defined (__rtems__) && defined (__BIG_ENDIAN) > + > +#define IX_OSAL_LINUX_BE /* XXX */ > + > +#elif defined (__rtems__) && defined (__BIG_ENDIAN) > + > +#define IX_OSAL_LINUX_LE /* XXX */ > + > #else > > #error Unknown OS/Endianess combination - only vxWorks BE LE, Linux BE LE, > WinCE BE LE are supported > > --- ./cpu/ixp/npe/include/IxOsalMemAccess.h.orig 2008-10-03 > 13:24:52.000000000 +0100 > +++ ./cpu/ixp/npe/include/IxOsalMemAccess.h 2008-10-03 > 13:26:07.000000000 +0100 > @@ -324,7 +324,9 @@ > > #endif /* wince */ > > -#if defined (__vxworks) || (defined (__linux) && defined > (IX_OSAL_STATIC_MEMORY_MAP)) || \ > +#if defined (__vxworks) || \ > + defined (__rtems__) || \ > + (defined (__linux) && defined > (IX_OSAL_STATIC_MEMORY_MAP)) || \ > (defined (__wince) && defined > (IX_OSAL_STATIC_MEMORY_MAP)) > > #define IX_OSAL_READ_LONG_IO(wAddr) > IX_OSAL_READ_LONG_RAW(wAddr) > > _______________________________________________ > 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 bms at incunabulum.net Sat Oct 11 13:29:47 2008 From: bms at incunabulum.net (Bruce M. Simpson) Date: Sat Oct 11 13:29:54 2008 Subject: Problems with NSLU2 and U-Boot In-Reply-To: <48F09EF2.4060709@incunabulum.net> References: <48EABE17.3010104@incunabulum.net> <20081009025641.e6d015bb.stas@FreeBSD.org> <48F09EF2.4060709@incunabulum.net> Message-ID: <48F0AA48.3040008@incunabulum.net> Bruce M. Simpson wrote: > I just tried booting kernel.bin on the NSLU2, as a raw memory image, > via tftp, and got exactly the same result. > I repeated it with U-Boot. It appears as though it relocates the > embedded ELF image to the correct address during load and execution, > but I can't be sure because I don't have any OCD capability just now. I grabbed the patches for the IXO dude's USB JTAG design here: http://www.ixo.de/info/usb_jtag/ FWIW they apply fine to the snapshot I rolled of OpenOCD, and it appears to talk to the USB Blaster clone OK. Now whilst this appears to detect the chain, I don't have TRST lines pulled out on the board -- I only have VCC, GND, TMS, TCK, TDO and TDI pulled out with teflon coated wire (the *really* thin stuff). So I can't halt the xScale core and capture registers, etc. It seems there is a TRSTn line but I'll have to warm up the iron another time... From bms at incunabulum.net Sat Oct 11 14:53:51 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sat Oct 11 14:53:58 2008 Subject: Emprex / Star / Cavium followup Message-ID: <48F0BDF9.7080300@incunabulum.net> It appears Cavium bought Star Semiconductor in July/August. I've followed up with emails to Cavium and Emprex today asking "Where's the GPLed code release?" re: the NSD-100 "P2P appliance" which made its way onto the market without the source code being released to comply with the terms of the GPL. 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. cheers BMS From stas at FreeBSD.org Sun Oct 12 21:06:51 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Sun Oct 12 21:06:58 2008 Subject: HOWTO: Build NSLU2 U-Boot on FreeBSD In-Reply-To: <48F099D4.2050302@incunabulum.net> References: <48F099D4.2050302@incunabulum.net> Message-ID: <20081013010723.cce11b21.stas@FreeBSD.org> 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. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-embedded/attachments/20081012/5cec55de/attachment.pgp From bms at incunabulum.net Mon Oct 13 06:26:26 2008 From: bms at incunabulum.net (Bruce M. Simpson) Date: Mon Oct 13 06:26:32 2008 Subject: Broadcom MIPS kernel bit-rot In-Reply-To: <20081008.150716.570083949.imp@bsdimp.com> References: <48ECF8F5.8090805@incunabulum.net> <20081008.150716.570083949.imp@bsdimp.com> Message-ID: <48F2EA0D.9080502@incunabulum.net> 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 bms at incunabulum.net Mon Oct 13 07:51:30 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon Oct 13 07:51:37 2008 Subject: Possible i2c driver problem w/NSLU2 Message-ID: <48F2FDFF.7020109@incunabulum.net> 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 bugmaster at FreeBSD.org Mon Oct 13 11:06:47 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 13 11:07:29 2008 Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org Message-ID: <200810131106.m9DB6lGC029381@freefall.freebsd.org> 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 bms at incunabulum.net Mon Oct 13 18:12:14 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon Oct 13 18:12:21 2008 Subject: [PATCH] Probe and attach bfe(4) on WGT634U Message-ID: <48F38F7A.8000902@incunabulum.net> 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 -------------- next part -------------- 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 }; From bms at FreeBSD.org Mon Oct 13 18:36:12 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Mon Oct 13 18:36:17 2008 Subject: Emprex / Star / Cavium followup In-Reply-To: <48F0BDF9.7080300@incunabulum.net> References: <48F0BDF9.7080300@incunabulum.net> Message-ID: <48F390A2.5010006@FreeBSD.org> 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 bms at incunabulum.net Mon Oct 13 18:46:52 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon Oct 13 18:46:57 2008 Subject: ELF loader problem with CFE on ASUS WL500g Message-ID: <48F39798.3010606@incunabulum.net> 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 imp at bsdimp.com Mon Oct 13 18:58:24 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Mon Oct 13 18:58:31 2008 Subject: ELF loader problem with CFE on ASUS WL500g In-Reply-To: <48F39798.3010606@incunabulum.net> References: <48F39798.3010606@incunabulum.net> Message-ID: <20081013.125648.1239212699.imp@bsdimp.com> 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 bms at incunabulum.net Mon Oct 13 19:26:41 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Mon Oct 13 19:26:48 2008 Subject: ELF loader problem with CFE on ASUS WL500g In-Reply-To: <20081013.125648.1239212699.imp@bsdimp.com> References: <48F39798.3010606@incunabulum.net> <20081013.125648.1239212699.imp@bsdimp.com> Message-ID: <48F3A0EE.7040003@incunabulum.net> 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 -------------- next part -------------- #!/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 From imp at bsdimp.com Mon Oct 13 19:49:49 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Mon Oct 13 19:49:56 2008 Subject: ELF loader problem with CFE on ASUS WL500g In-Reply-To: <48F3A0EE.7040003@incunabulum.net> References: <48F39798.3010606@incunabulum.net> <20081013.125648.1239212699.imp@bsdimp.com> <48F3A0EE.7040003@incunabulum.net> Message-ID: <20081013.134720.1079617746.imp@bsdimp.com> 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 bms at incunabulum.net Tue Oct 14 08:36:00 2008 From: bms at incunabulum.net (Bruce M. Simpson) Date: Tue Oct 14 08:36:06 2008 Subject: Emprex / Star / Cavium followup In-Reply-To: <48F390A2.5010006@FreeBSD.org> References: <48F0BDF9.7080300@incunabulum.net> <48F390A2.5010006@FreeBSD.org> Message-ID: <48F459BD.6050002@incunabulum.net> 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 bms at incunabulum.net Tue Oct 14 08:39:29 2008 From: bms at incunabulum.net (Bruce M. Simpson) Date: Tue Oct 14 08:39:36 2008 Subject: Recommendations for PC based logic analyzer / grabbers? Message-ID: <48F45A8F.8050609@incunabulum.net> 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 raj at semihalf.com Tue Oct 14 09:29:40 2008 From: raj at semihalf.com (Rafal Jaworowski) Date: Tue Oct 14 09:29:46 2008 Subject: HOWTO: Build NSLU2 U-Boot on FreeBSD In-Reply-To: <48F099D4.2050302@incunabulum.net> References: <48F099D4.2050302@incunabulum.net> Message-ID: <48F4667F.4080900@semihalf.com> 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 raj at semihalf.com Tue Oct 14 09:30:04 2008 From: raj at semihalf.com (Rafal Jaworowski) Date: Tue Oct 14 09:30:12 2008 Subject: ELF loader problem with CFE on ASUS WL500g In-Reply-To: <20081013.134720.1079617746.imp@bsdimp.com> References: <48F39798.3010606@incunabulum.net> <20081013.125648.1239212699.imp@bsdimp.com> <48F3A0EE.7040003@incunabulum.net> <20081013.134720.1079617746.imp@bsdimp.com> Message-ID: <48F461FD.1050800@semihalf.com> 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 gary.jennejohn at freenet.de Tue Oct 14 10:43:44 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Tue Oct 14 10:43:51 2008 Subject: HOWTO: Build NSLU2 U-Boot on FreeBSD In-Reply-To: <48F4667F.4080900@semihalf.com> References: <48F099D4.2050302@incunabulum.net> <48F4667F.4080900@semihalf.com> Message-ID: <20081014124336.16e25346@ernst.jennejohn.org> 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 stas at FreeBSD.org Tue Oct 14 11:09:10 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Tue Oct 14 11:09:16 2008 Subject: HOWTO: Build NSLU2 U-Boot on FreeBSD In-Reply-To: <20081014124336.16e25346@ernst.jennejohn.org> References: <48F099D4.2050302@incunabulum.net> <48F4667F.4080900@semihalf.com> <20081014124336.16e25346@ernst.jennejohn.org> Message-ID: <20081014145020.13a1faae.stas@FreeBSD.org> On Tue, 14 Oct 2008 12:43:36 +0200 Gary Jennejohn mentioned: > > > > 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. > 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. > 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:-) -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-embedded/attachments/20081014/6a528f0d/attachment.pgp From imp at bsdimp.com Tue Oct 14 14:52:55 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Oct 14 14:53:01 2008 Subject: HOWTO: Build NSLU2 U-Boot on FreeBSD In-Reply-To: <20081014124336.16e25346@ernst.jennejohn.org> References: <48F099D4.2050302@incunabulum.net> <48F4667F.4080900@semihalf.com> <20081014124336.16e25346@ernst.jennejohn.org> Message-ID: <20081014.085019.1723235775.imp@bsdimp.com> 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 philip.mullis at syx.ca Tue Oct 14 16:29:54 2008 From: philip.mullis at syx.ca (Philip Mullis) Date: Tue Oct 14 16:30:03 2008 Subject: storage selection for embedded devices Message-ID: <48F4C02F.1060407@syx.ca> 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 imp at bsdimp.com Tue Oct 14 17:02:05 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Oct 14 17:02:11 2008 Subject: storage selection for embedded devices In-Reply-To: <48F4C02F.1060407@syx.ca> References: <48F4C02F.1060407@syx.ca> Message-ID: <20081014.110022.635731567.imp@bsdimp.com> 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 olivier at gautherot.net Tue Oct 14 17:49:39 2008 From: olivier at gautherot.net (Olivier Gautherot) Date: Tue Oct 14 17:50:10 2008 Subject: storage selection for embedded devices In-Reply-To: <20081014.110022.635731567.imp@bsdimp.com> References: <48F4C02F.1060407@syx.ca> <20081014.110022.635731567.imp@bsdimp.com> Message-ID: 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 philip.mullis at syx.ca Tue Oct 14 17:50:23 2008 From: philip.mullis at syx.ca (Philip Mullis) Date: Tue Oct 14 17:50:32 2008 Subject: storage selection for embedded devices In-Reply-To: References: <48F4C02F.1060407@syx.ca> <20081014.110022.635731567.imp@bsdimp.com> Message-ID: <48F4DBDC.9020904@syx.ca> 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 wkoszek at freebsd.org Tue Oct 14 20:30:17 2008 From: wkoszek at freebsd.org (Wojciech A. Koszek) Date: Tue Oct 14 20:30:23 2008 Subject: Recommendations for PC based logic analyzer / grabbers? In-Reply-To: <48F45A8F.8050609@incunabulum.net> References: <48F45A8F.8050609@incunabulum.net> Message-ID: <20081014193849.GA16758@FreeBSD.org> 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 antab at valka.is Thu Oct 16 11:33:19 2008 From: antab at valka.is (=?iso-8859-1?Q?Arnar_Mar_Sigur=F0sson?=) Date: Thu Oct 16 11:33:26 2008 Subject: Recommendations for PC based logic analyzer / grabbers? References: <48F45A8F.8050609@incunabulum.net> <20081014193849.GA16758@FreeBSD.org> Message-ID: <061E11D86E3DFF459604DF5B36F0805F1BA6B3@salka01.valka.local> -----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? > 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. 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=en-uk&target=d17.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 isaac at ceetoneresearch.com Thu Oct 16 22:02:31 2008 From: isaac at ceetoneresearch.com (Isaac Levy) Date: Thu Oct 16 22:02:38 2008 Subject: storage selection for embedded devices In-Reply-To: <48F4DBDC.9020904@syx.ca> References: <48F4C02F.1060407@syx.ca> <20081014.110022.635731567.imp@bsdimp.com> <48F4DBDC.9020904@syx.ca> Message-ID: Hi all, > 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. >> >> >> 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 > 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 :) > I just wanted to chime in with some metrics, (although lacking total context/details): From a presentation on the NanoBSD build scripts, on FreeBSD, here's this: -- http://www.bsdcan.org/2006/papers/nanobsd.pdf Page 12 of the slides states: Counting flash writes + 200.000 writes, worst case: ?Superblock updated 1/s = 55 hours lifetime ?File written 1/m = 138 days lifetime ?File written 1/h = 22 years lifetime ?File written 1/d = 547 years lifetime -- Now, the details of the writes is not clear here, but the point is clear- writes to CF cards *must* be minimized. After working with Soekris boards for years, and now PCEngines, I can testify that typical UNIX installs on CF cards, (lots of writes), wrecks the cards fast. CF cards do funky wear-leveling stuff, so tricks I've seen people try which move files around simply exacerbate the problem... -- Here's a general approach to CF as boot drive use, (and the purpose of the NanoBSD build scripts on FreeBSD): 1) obviously: Tiny Kernel, userland, etc... stripped down system to 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 (is unmounted unless a config needs to be written) For system updates, build a new image, and dd it to the second partition- reset bootloader to boot from second partition, and viola... minimal writes. This is very flexible, can be piped over ssh, etc... 3) A couple of memory disks for /etc /var and /tmp, (5mb each is Nano default)- /etc gets the files from the small r/w partition above. That's just a quick conceptual overview of one successful method of running UNIX on CF cards- hope it's helpful! More info specifically 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 anybody has done anything interesting?! (esp. any noteworthy PicoBSD differences) Best, .ike From jkv at unixcluster.dk Fri Oct 17 11:34:50 2008 From: jkv at unixcluster.dk (jkv) Date: Fri Oct 17 11:35:03 2008 Subject: Problems with updatep2(nanobsd) on soekris 4801 Message-ID: <48F38E70.3020201@unixcluster.dk> 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 jkv at unixcluster.dk Fri Oct 17 11:34:51 2008 From: jkv at unixcluster.dk (jkv) Date: Fri Oct 17 11:35:03 2008 Subject: Problems with updatep2(nanobsd) on soekris 4801 Message-ID: <48F37CF3.3000906@unixcluster.dk> 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 stas at FreeBSD.org Fri Oct 17 13:09:40 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Fri Oct 17 13:09:47 2008 Subject: Problems with updatep2(nanobsd) on soekris 4801 In-Reply-To: <48F38E70.3020201@unixcluster.dk> References: <48F38E70.3020201@unixcluster.dk> Message-ID: <20081017170930.2487dd9d.stas@FreeBSD.org> On Mon, 13 Oct 2008 20:07:44 +0200 jkv mentioned: > 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 > Looks like your hard drive failed. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-embedded/attachments/20081017/531c1c47/attachment.pgp From bugmaster at FreeBSD.org Mon Oct 20 11:06:49 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 20 11:07:30 2008 Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org Message-ID: <200810201106.m9KB6mrm082614@freefall.freebsd.org> 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 mah at jump-ing.de Sat Oct 25 11:52:30 2008 From: mah at jump-ing.de (Markus Hitter) Date: Sat Oct 25 11:52:39 2008 Subject: Fill a partition entirely Message-ID: <8DCB3D53-4C5E-43FD-A437-C551A36003DE@jump-ing.de> Hello all, recently I received such a GEODE-based diskless desktop PC and now I'm attepting to get a minimum system onto it using (a heftily tweaked) tinyBSD. The plan is to put a memory based, read-only root file system onto a pen drive and to use the remaining part of the pen drive for user data. In principle everything works, but when trying to optimise, I can't get this root file system to fill up to more tham about 60%, no matter how I set inode count, root reserved space and fragment size. This is the snippet for creating the partition: PART_ONE_SIZE=`du -s ${WORKDIR} | cut -f 1` # Fix: let PART_ONE_SIZE=${PART_ONE_SIZE}*2 LABELFILE=`mktemp -t tinybsd` echo "a: ${PART_ONE_SIZE} * 4.2BSD" > ${LABELFILE} echo "b: * * 4.2BSD" >> ${LABELFILE} bsdlabel -R -B /dev/${MD} ${LABELFILE} rm -f ${LABELFILE} newfs -m 0 -n /dev/${MD}a mount /dev/${MD}a ${IMGMNT} tar -C ${WORKDIR} -cf- --exclude kernel . | \ tar -C ${IMGMNT} -xf- For some reason I can't imagine, the later "tar" starts complaining "No space left on device" half the way and the situation ends up with ("df -i"): Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/md1a 6778 4596 2182 68% 22 1000 2% /tmp/ tinybsd.HhlvvDXC To me, this doesn't look like "No space left on device" at all. What is missing here, how can I shrink the partition to just hold the needed files? Thanks, MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From bms at incunabulum.net Sun Oct 26 13:37:36 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sun Oct 26 13:37:42 2008 Subject: Breaking into the Emprex NAS-100 firmware Message-ID: <4904729C.9080108@incunabulum.net> Hi, I just had a chance to look at this. So, Emprex are shipping a box (the NAS100) in violation of the GPL w/o releasing all relevant source code. After I contacted Cavium about the GPL issues with their acquisition of Star Semiconductor, they sent me links to the binaries which Linksys were required to release for the WAP4400N. I downloaded the WAP4400N materials and cross-compiled mtd-utils using Star's provided toolchain binaries (Gentoo crossdev is often broken for me). I then used mtd_debug to extract an image of the mtd0 partition, using a USB2 flash disk for data exchange. I quickly noticed that the ARMboot image targetted for the WAP4400N, built from Linksys provided sources, doesn't match the ARMboot image inside the NAS100. As far as I can tell this is down to two things: 1. The environment region for ARMboot is inside ARMboot's flash partition, at the very end (0x1E000 to 0x20000, 4096 bytes including the 4-byte CRC32 at the start of the region). [The image for the WAP4400N assumes it's at 0x20000 and is 8192 bytes long.. so don't use that image.] 2. The PHY drivers are slightly different. So I looked at the STR9100 board support, and after noting the binary differences in the flash layout, skimmed some of the code to do with environment variable processing. On a whim, I decided to deliberately corrupt the contents of the environment in the flash by modifying it with a hex editor and rewriting it w/mtd_debug, and rebooted. There is a CRC-32 at the start and it wasn't 100% clear which region was being used for it. Having done this, I noticed that ARMboot drops into its prompt (after attempting to execute its 'firstboot' routine and hitting CTRL-C). I was able to run Emprex's shipped kernel using "go 0x10020000", which seems to point to them not using the U-Boot image facility in ARMboot. The majority of Star's patches to ARMboot are to add support for some of the onboard peripherals (Ethernet MAC, timers, UART etc). BY THE WAY... There is a funny bug in ARMboot which I've seen on little endian ARM such as these, and that is, you need to configure an alias of the *reverse* of the IP address of the default gateway in order for it to boot from the network successfully. It seems to need a default gateway in order to use its bootp code, even when the server is on a directly attached network. Simply flipping the octets in the BOOTP/DHCP option given out to the box doesn't work, an actual alias on the gateway is needed. As far as I know this bug hasn't been fixed. So I guess now the way ahead is lit for folk to get U-Boot or similar onto this platform, as well as hopefully porting FreeBSD in future. If anyone is interested in following this up please contact me, I might not have free time to look at this in any detail. thanks BMS From bms at FreeBSD.org Sun Oct 26 19:21:20 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Sun Oct 26 19:21:26 2008 Subject: Breaking into the Emprex NAS-100 firmware In-Reply-To: <4904729C.9080108@incunabulum.net> References: <4904729C.9080108@incunabulum.net> Message-ID: <4904C32D.4040303@FreeBSD.org> I tried booting armboot (compilde from source) from armboot installed on the device. Didn't work, even when rebased to 0x20000. I'm guessing that's an MMU mode issue. Haven't tried a kernel (yet). Someone out there is working on Linux 2.6 support, perhaps information sharing is possible. From espartano.mail at gmail.com Sun Oct 26 21:05:31 2008 From: espartano.mail at gmail.com (Espartano) Date: Sun Oct 26 21:05:38 2008 Subject: Problem with CPU Geode panic: CPU class not configured :( Message-ID: hi people, first and foremost apologize me for my bad english. I have an alix2c3 machine with this features: CPU: 500 MHz AMD Geode LX800 DRAM: 256 MB DDR DRAM Storage: CompactFlash socket Power: DC jack or passive POE, min. 7V to max. 20V Three front panel LEDs, pushbutton Expansion: 1 miniPCI slot, LPC bus Connectivity: 3 Ethernet channels (Via VT6105M 10/100) I/O: DB9 serial port, dual USB port Board size: 6 x 6" (152.4 x 152.4 mm) - same as WRAP.1E Firmware: tinyBIOS I have installed NanoBSD in this machine but when it try to boot i get this message: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE #0: Sat Oct 25 01:28:04 CDT 2008 root@:/usr/obj/nanobsd.ALIX_PF/usr/src/sys/ALIX Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Geode(TM) Integrated Processor by AMD PCS (Unknown-class CPU) Origin = "AuthenticAMD" Id = 0x5a2 Stepping = 2 Features=0x88a93d AMD Features=0xc0400000 panic: CPU class not configured Uptime: 1s this is my kernel configuration file: # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.474.2.2.2.1 2008/02/06 03:24:28 scottl Exp $ machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident ALIX_FIREWALL options CPU_GEODE # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device #options NFSCLIENT # Network Filesystem Client #options NFSSERVER # Network Filesystem Server #options NFS_ROOT # NFS usable as /, requires NFSCLIENT #options MSDOSFS # MSDOS Filesystem #options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework #options GEOM_PART_GPT # GUID Partition Tables. #options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] #options COMPAT_FREEBSD4 # Compatible with FreeBSD4 #options COMPAT_FREEBSD5 # Compatible with FreeBSD5 #options COMPAT_FREEBSD6 # Compatible with FreeBSD6 #options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing options DEVICE_POLLING options IPSEC device tun #Tunnel driver (ppp(8), nos-tun(8)) device gre #IP over IP tunneling device if_bridge #Bridge interface device pf #PF OpenBSD packet-filter firewall device pflog #logging support interface for PF device pfsync #synchronization interface for PF device carp #Common Address Redundancy Protocol device enc #IPsec interface device crypto options ALTQ options ALTQ_CBQ # Class Bases Queueing options ALTQ_RED # Random Early Detection options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler options ALTQ_CDNR # Traffic conditioner options ALTQ_PRIQ # Priority Queueing options ALTQ_NOPCC # Required if the TSC is unusable options ALTQ_DEBUG # To make an SMP kernel, the next two lines are needed #options SMP # Symmetric MultiProcessor Kernel #device apic # I/O APIC # CPU frequency control device cpufreq # Bus support. device eisa device pci # Floppy drives #device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device ataraid # ATA RAID drives #device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. #device ahd # AHA39320/29320 and onboard AIC79xx devices #options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. #device amd # AMD 53C974 (Tekram DC-390(T)) #device hptiop # Highpoint RocketRaid 3xxx series #device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aha # Adaptec 154x SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) #device ch # SCSI media changers device da # Direct Access (disks) #device sa # Sequential Access (tape etc) #device cd # CD #device pass # Passthrough device (direct SCSI access) #device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device amr # AMI MegaRAID #device arcmsr # Areca SATA II RAID #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options #device hptmv # Highpoint RocketRAID 182x #device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx #device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID #device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers #device aac # Adaptec FSA RAID #device aacp # SCSI passthrough for aac (requires CAM) #device ida # Compaq Smart RAID #device mfi # LSI MegaRAID SAS #device mlx # Mylex DAC960 family #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver #device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc #device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') #device em # Intel PRO/1000 adapter Gigabit Ethernet Card #device ixgb # Intel PRO/10GbE Ethernet Card #device le # AMD Am7900 LANCE and Am79C9xx PCnet #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support #device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet #device bfe # Broadcom BCM440x 10/100 Ethernet #device bge # Broadcom BCM570xx Gigabit Ethernet #device dc # DEC/Intel 21143 and various workalikes #device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device lge # Level 1 LXT1001 gigabit Ethernet #device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet #device nfe # nVidia nForce MCP on-board Ethernet #device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking #device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') #device re # RealTek 8139C+/8169/8169S/8110S #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device stge # Sundance/Tamarack TC9021 gigabit Ethernet #device ti # Alteon Networks Tigon I/II gigabit Ethernet #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # Wireless NIC cards device wlan # 802.11 support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device wlan_scan_ap # 802.11 AP mode scanning device wlan_scan_sta # 802.11 STA mode scanning #device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) device ath_rate_sample # SampleRate tx rate control for ath #device awi # BayStack 660 and others #device ral # Ralink Technology RT2500 wireless NICs. device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling #device faith # IPv6-to-IPv4 relaying (translation) #device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device ehci # EHCI PCI->USB interface (USB 2.0) #device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse #device ural # Ralink Technology RT2500USB wireless NICs #device rum # Ralink Technology RT2501USB wireless NICs #device urio # Diamond Rio 500 MP3 player #device uscanner # Scanners # USB Ethernet, requires miibus #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cdce # Generic USB over Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) #device fwip # IP over FireWire (RFC 2734,3146) #device dcons # Dumb console driver #device dcons_crom # Configuration ROM for dcons My NanoBSD configuration file is this: NANO_NAME=ALIX_PF NANO_KERNEL=ALIX NANO_SRC=/usr/src NANO_TOOLS=tools/tools/nanobsd NANO_BOOT0CFG="-o nopacket -s 1 -m 3" NANO_NEWFS="-b 4096 -f 512 -i 8192 -O1 -U" NANO_DRIVE=ad0 NANO_IMAGES=2 NANO_CODESIZE=0 NANO_PACKAGE_DIR=${NANO_SRC}/${NANO_TOOLS}/Pkg NANO_RAM_ETCSIZE=10540 NANO_RAM_TMPVARSIZE=10540 FlashDevice sandisk 512 #lyle CONF_INSTALL=' NO_ACPI=YES NO_CVS=YES NO_FORTRAN=YES NO_HTML=YES NO_LPR=YES NO_MAN=YES NO_SENDMAIL=YES NO_SHAREDOCS=YES NO_EXAMPLES=YES NO_CALENDAR=YES NO_MISC=YES NO_SHARE=YES ' CONF_WORLD=' WITHOUT_BLUETOOTH=YES WITHOUT_ZFS=YES WITHOUT_CVS=YES WITHOUT_EXAMPLES=YES WITHOUT_GAMES=YES WITHOUT_HTML=YES WITHOUT_INET6=YES WITHOUT_IPFILTER=YES WITHOUT_IPX=YES WITHOUT_IPX_SUPPORT=YES WITHOUT_NIS=YES WITHOUT_SENDMAIL=YES WITHOUT_USB=YES NO_MODULES=YES NO_INFO=YES ' customize_cmd cust_pkg but my NanoBSD image fail when it try to boot, can someone help me please ? thanks in advance. -- "Linux is for people who hate Windows, BSD is for people who love UNIX". "Social Engineer -> Because there is no patch for human stupidity" "The Unix Guru's View of Sex unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; umount ; sleep." "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing." From mike at sentex.net Sun Oct 26 23:38:22 2008 From: mike at sentex.net (Mike Tancsa) Date: Sun Oct 26 23:38:35 2008 Subject: Problem with CPU Geode panic: CPU class not configured :( In-Reply-To: References: Message-ID: <200810262301.m9QN1XqM077618@lava.sentex.ca> At 04:35 PM 10/26/2008, Espartano wrote: >hi people, first and foremost apologize me for my bad english. I have >an alix2c3 machine with this features: Hi, Not sure about 7.0R, but 7.1PRE-RELEASE or RELENG_7 works well with the file geode.c from HEAD. (diff below) For CPU options, I use machine i386 cpu I486_CPU cpu I586_CPU option CPU_GEODE option CPU_ELAN option CPU_SOEKRIS (Not sure if the ELAN part is needed, probably not) The glxsb works well as does the watchdogd driver # cat /var/run/dmesg.boot Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #1: Fri Oct 24 16:14:31 EDT 2008 mdtancsa@buildhost.sentex.ca:/usr/obj/nanobsd.alix/usr/src/sys/nano5501 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Geode(TM) Integrated Processor by AMD PCS (498.05-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x5a2 Stepping = 2 Features=0x88a93d AMD Features=0xc0400000 real memory = 268435456 (256 MB) avail memory = 253198336 (241 MB) pnpbios: Bad PnP BIOS data checksum K6-family MTRR support enabled (2 registers) cryptosoft0: on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 Geode LX: PC Engines ALIX.2 v0.99 tinyBIOS V1.4a (C)1997-2007 glxsb0: mem 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 vr0: port 0x1000-0x10ff mem 0xe0000000-0xe00000ff irq 10 at device 9.0 on pci0 vr0: Quirks: 0x6 vr0: Revision: 0x96 miibus0: on vr0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:0d:b9:15:6c:48 vr0: [ITHREAD] vr1: port 0x1400-0x14ff mem 0xe0040000-0xe00400ff irq 11 at device 10.0 on pci0 vr1: Quirks: 0x6 vr1: Revision: 0x96 miibus1: on vr1 ukphy1: PHY 1 on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr1: Ethernet address: 00:0d:b9:15:6c:49 vr1: [ITHREAD] isab0: port 0x6000-0x6007,0x6100-0x61ff,0x6200-0x623f,0x9d00-0x9d7f,0x9c00-0x9c3f at device 15.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 15.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] ohci0: mem 0xefffe000-0xefffefff irq 15 at device 15.4 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 4 ports with 4 removable, self powered ehci0: mem 0xefffd000-0xefffdfff irq 15 at device 15.5 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 4 ports with 4 removable, self powered cpu0 on motherboard orm0: at iomem 0xe0000-0xea7ff pnpid ORM0000 on isa0 uart4: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart4: [FILTER] uart4: console (9600,n,8,1) RTC BIOS diagnostic error 80 Timecounter "TSC" frequency 498052729 Hz quality 800 Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. ad0: 1953MB at ata0-master PIO4 Trying to mount root from ufs:/dev/ad0s1a --- sys/i386/i386/geode.c 2007-09-18 05:19:44.000000000 -0400 +++ sys/i386/i386/geode.c.good 2008-09-12 17:13:18.000000000 -0400 @@ -25,7 +25,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/i386/i386/geode.c,v 1.10 2007/09/18 09:19:44 phk Exp $"); +__FBSDID("$FreeBSD: src/sys/i386/i386/geode.c,v 1.11 2008/02/10 19:14:42 phk Exp $"); #include #include @@ -40,41 +40,50 @@ #include static struct bios_oem bios_soekris = { - { 0xf0000, 0xf1000 }, - { - { "Soekris", 0, 8 }, /* Soekris Engineering. */ - { "net4", 0, 8 }, /* net45xx */ - { "comBIOS", 0, 54 }, /* comBIOS ver. 1.26a 20040819 ... */ - { NULL, 0, 0 }, - } + { 0xf0000, 0xf1000 }, + { + { "Soekris", 0, 8 }, /* Soekris Engineering. */ + { "net4", 0, 8 }, /* net45xx */ + { "comBIOS", 0, 54 }, /* comBIOS ver. 1.26a 20040819 ... */ + { NULL, 0, 0 }, + } }; static struct bios_oem bios_soekris_55 = { - { 0xf0000, 0xf1000 }, - { - { "Soekris", 0, 8 }, /* Soekris Engineering. */ - { "net5", 0, 8 }, /* net5xxx */ - { "comBIOS", 0, 54 }, /* comBIOS ver. 1.26a 20040819 ... */ - { NULL, 0, 0 }, - } + { 0xf0000, 0xf1000 }, + { + { "Soekris", 0, 8 }, /* Soekris Engineering. */ + { "net5", 0, 8 }, /* net5xxx */ + { "comBIOS", 0, 54 }, /* comBIOS ver. 1.26a 20040819 ... */ + { NULL, 0, 0 }, + } }; static struct bios_oem bios_pcengines = { - { 0xf9000, 0xfa000 }, - { - { "PC Engines WRAP", 0, 28 }, /* PC Engines WRAP.1C v1.03 */ - { "tinyBIOS", 0, 28 }, /* tinyBIOS V1.4a (C)1997-2003 */ - { NULL, 0, 0 }, - } + { 0xf9000, 0xfa000 }, + { + { "PC Engines WRAP", 0, 28 }, /* PC Engines WRAP.1C v1.03 */ + { "tinyBIOS", 0, 28 }, /* tinyBIOS V1.4a (C)1997-2003 */ + { NULL, 0, 0 }, + } +}; + +static struct bios_oem bios_pcengines_55 = { + { 0xf9000, 0xfa000 }, + { + { "PC Engines ALIX", 0, 28 }, /* PC Engines ALIX */ + { "tinyBIOS", 0, 28 }, /* tinyBIOS V1.4a (C)1997-2005 */ + { NULL, 0, 0 }, + } }; static struct bios_oem bios_advantech = { - { 0xfe000, 0xff000 }, - { - { "**** PCM-582", 5, 33 }, /* PCM-5823 BIOS V1.12 ... */ - { "GXm-Cx5530", -11, 35 }, /* 06/07/2002-GXm-Cx5530... */ - { NULL, 0, 0 }, - } + { 0xfe000, 0xff000 }, + { + { "**** PCM-582", 5, 33 }, /* PCM-5823 BIOS V1.12 ... */ + { "GXm-Cx5530", -11, 35 }, /* 06/07/2002-GXm-Cx5530... */ + { NULL, 0, 0 }, + } }; static unsigned cba; @@ -117,6 +126,11 @@ } a = rdmsr(0x5140000c); + if (bit >= 16) { + a += 0x80; + bit -= 16; + } + if (onoff) outl(a, 1 << bit); else @@ -256,11 +270,13 @@ * by the bios, see p161 in data sheet. */ cba = pci_read_config(self, 0x64, 4); - printf("Geode CBA@ 0x%x\n", cba); + if (bootverbose) + printf("Geode CBA@ 0x%x\n", cba); geode_counter = cba + 0x08; outl(cba + 0x0d, 2); - printf("Geode rev: %02x %02x\n", - inb(cba + 0x3c), inb(cba + 0x3d)); + if (bootverbose) + printf("Geode rev: %02x %02x\n", + inb(cba + 0x3c), inb(cba + 0x3d)); tc_init(&geode_timecounter); EVENTHANDLER_REGISTER(watchdog_list, geode_watchdog, NULL, 0); @@ -270,13 +286,14 @@ case 0x0510100b: gpio = pci_read_config(self, PCIR_BAR(0), 4); gpio &= ~0x1f; - printf("Geode GPIO@ = %x\n", gpio); - if ( bios_oem_strings(&bios_soekris, - bios_oem, BIOS_OEM_MAXLEN) > 0 ) { + if (bootverbose) + printf("Geode GPIO@ = %x\n", gpio); + if (bios_oem_strings(&bios_soekris, + bios_oem, sizeof bios_oem) > 0 ) { led1b = 20; led1 = led_create(led_func, &led1b, "error"); - } else if ( bios_oem_strings(&bios_pcengines, - bios_oem, BIOS_OEM_MAXLEN) > 0 ) { + } else if (bios_oem_strings(&bios_pcengines, + bios_oem, sizeof bios_oem) > 0 ) { led1b = -2; led2b = -3; led3b = -18; @@ -289,27 +306,41 @@ */ led_func(&led1b, 1); } - if ( strlen(bios_oem) ) + if (*bios_oem) printf("Geode %s\n", bios_oem); break; case 0x01011078: - if ( bios_oem_strings(&bios_advantech, - bios_oem, BIOS_OEM_MAXLEN) > 0 ) { + if (bios_oem_strings(&bios_advantech, + bios_oem, sizeof bios_oem) > 0 ) { printf("Geode %s\n", bios_oem); EVENTHANDLER_REGISTER(watchdog_list, advantech_watchdog, NULL, 0); } break; case 0x20801022: - if ( bios_oem_strings(&bios_soekris_55, - bios_oem, BIOS_OEM_MAXLEN) > 0 ) { - printf("Geode LX: %s\n", bios_oem); + if (bios_oem_strings(&bios_soekris_55, + bios_oem, sizeof bios_oem) > 0 ) { led1b = 6; led1 = led_create(cs5536_led_func, &led1b, "error"); + } else if (bios_oem_strings(&bios_pcengines_55, + bios_oem, sizeof bios_oem) > 0 ) { + led1b = -6; + led2b = -25; + led3b = -27; + led1 = led_create(cs5536_led_func, &led1b, "led1"); + led2 = led_create(cs5536_led_func, &led2b, "led2"); + led3 = led_create(cs5536_led_func, &led3b, "led3"); + /* + * Turn on first LED so we don't make + * people think their box just died. + */ + cs5536_led_func(&led1b, 1); } - printf("MFGPT bar: %jx\n", rdmsr(0x5140000d)); - EVENTHANDLER_REGISTER(watchdog_list, cs5536_watchdog, - NULL, 0); + if (*bios_oem) + printf("Geode LX: %s\n", bios_oem); + if (bootverbose) + printf("MFGPT bar: %jx\n", rdmsr(0x5140000d)); + EVENTHANDLER_REGISTER(watchdog_list, cs5536_watchdog, NULL, 0); break; } return (ENXIO); From mah at jump-ing.de Sun Oct 26 23:48:12 2008 From: mah at jump-ing.de (Markus Hitter) Date: Sun Oct 26 23:48:18 2008 Subject: Problem with CPU Geode panic: CPU class not configured :( In-Reply-To: References: Message-ID: <76CEC935-4D7E-4CEB-9A5D-49D52DCE7183@jump-ing.de> Am 26.10.2008 um 21:35 schrieb Espartano: > CPU: Geode(TM) Integrated Processor by AMD PCS (Unknown-class CPU) > Origin = "AuthenticAMD" Id = 0x5a2 Stepping = 2 > Features=0x88a93d > AMD Features=0xc0400000 > panic: CPU class not configured Hmm. The CPU class of the LX800 is I586_CPU, no others required. See a snippet from my own, very similar, Flepo Alpha: FreeBSD 7.0-RELEASE #0: Mon Oct 27 02:01:45 GMT-2 2008 root@fortinybsd.jump-ing.de:/usr/obj/usr/src/sys/TINYBSD Timecounter "i8254" frequency 1193117 Hz quality 0 CPU: Geode(TM) Integrated Processor by AMD PCS (498.03-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x5a2 Stepping = 2 Features=0x88a93d AMD Features=0xc0400000 real memory = 469434368 (447 MB) Somehow, the class of your CPU isn't recognized, "Unknown-class" doesn't sound sane. Are there newer firmwares available? HTH, MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From espartano.mail at gmail.com Mon Oct 27 03:18:54 2008 From: espartano.mail at gmail.com (Espartano) Date: Mon Oct 27 03:19:00 2008 Subject: Problem with CPU Geode panic: CPU class not configured :( In-Reply-To: <76CEC935-4D7E-4CEB-9A5D-49D52DCE7183@jump-ing.de> References: <76CEC935-4D7E-4CEB-9A5D-49D52DCE7183@jump-ing.de> Message-ID: On Sun, Oct 26, 2008 at 5:48 PM, Markus Hitter wrote: > > Am 26.10.2008 um 21:35 schrieb Espartano: > >> CPU: Geode(TM) Integrated Processor by AMD PCS (Unknown-class CPU) >> Origin = "AuthenticAMD" Id = 0x5a2 Stepping = 2 >> Features=0x88a93d >> AMD Features=0xc0400000 >> panic: CPU class not configured > > Hmm. The CPU class of the LX800 is I586_CPU, no others required. > thanks for your answer, i had removed the option: options CPU_GEODE from the kernel config file then nanobsd image boot ok :) -- "Linux is for people who hate Windows, BSD is for people who love UNIX". "Social Engineer -> Because there is no patch for human stupidity" "The Unix Guru's View of Sex unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; umount ; sleep." "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing." From bugmaster at FreeBSD.org Mon Oct 27 11:07:10 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 27 11:07:39 2008 Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org Message-ID: <200810271107.m9RB79d8001897@freefall.freebsd.org> 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 mah at jump-ing.de Mon Oct 27 12:45:46 2008 From: mah at jump-ing.de (Markus Hitter) Date: Mon Oct 27 12:45:52 2008 Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org In-Reply-To: <200810271107.m9RB79d8001897@freefall.freebsd.org> References: <200810271107.m9RB79d8001897@freefall.freebsd.org> Message-ID: <52C0B09D-DABF-44C1-881B-8F4F38588511@jump-ing.de> Am 27.10.2008 um 11:07 schrieb FreeBSD bugmaster: > 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 Being not involved in FreeBSD's central development, I'm wondering why those bugs don't get fixed/commited. Three of those four bugs have easily reviewable patches attached, so finding a fix can't be the reason for the delay. Locally I've made tinybsd much speedier, does it make sense to commit the result or even splitting the changes into small, reviewable pieces? MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From linimon at lonesome.com Mon Oct 27 17:04:47 2008 From: linimon at lonesome.com (Mark Linimon) Date: Mon Oct 27 17:04:54 2008 Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org In-Reply-To: <52C0B09D-DABF-44C1-881B-8F4F38588511@jump-ing.de> References: <200810271107.m9RB79d8001897@freefall.freebsd.org> <52C0B09D-DABF-44C1-881B-8F4F38588511@jump-ing.de> Message-ID: <20081027164314.GB21631@soaustin.net> > I'm wondering why those bugs don't get fixed/commited. Simple lack of sufficient developer time. I'm always trying to figure out ways to get more people involved, so keep posting PRs and maybe someone will work with you. mcl From gonzo at bluezbox.com Mon Oct 27 17:52:06 2008 From: gonzo at bluezbox.com (Oleksandr Tymoshenko) Date: Mon Oct 27 17:52:14 2008 Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org In-Reply-To: <52C0B09D-DABF-44C1-881B-8F4F38588511@jump-ing.de> References: <200810271107.m9RB79d8001897@freefall.freebsd.org> <52C0B09D-DABF-44C1-881B-8F4F38588511@jump-ing.de> Message-ID: <4905FB1D.7000806@bluezbox.com> Markus Hitter wrote: > > Am 27.10.2008 um 11:07 schrieb FreeBSD bugmaster: > >> 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 > > Being not involved in FreeBSD's central development, I'm wondering why > those bugs don't get fixed/commited. Three of those four bugs have > easily reviewable patches attached, so finding a fix can't be the reason > for the delay. picosbsd is not widely used these days, so it's not that critical. Also provided patches are a bit outdated and require some work to apply. I started fixing these issues just to get rid of this annoying weekly email but was distracted by other things. From espartano.mail at gmail.com Tue Oct 28 05:38:49 2008 From: espartano.mail at gmail.com (Espartano) Date: Tue Oct 28 05:40:06 2008 Subject: Problem with NanoBSD login Message-ID: hi people, i have created a NanoBSD image, it boot pretty well. I'm trying to authenticate as root using a serial console but NanoBSD doesn't show the correct login prompt, instead NanoBSD show strange chars and it doesn't let me login in the system. this is what NanoBSD show at boot time: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE-p5 #0: Mon Oct 27 01:48:08 CST 2008 root@:/usr/obj/nanobsd.ALIX_PF/usr/src/sys/ALIX Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Geode(TM) Integrated Processor by AMD PCS (498.05-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x5a2 Stepping = 2 Features=0x88a93d AMD Features=0xc0400000 real memory = 268435456 (256 MB) avail memory = 253214720 (241 MB) pnpbios: Bad PnP BIOS data checksum K6-family MTRR support enabled (2 registers) kbd0 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) cryptosoft0: on motherboard cpu0 on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 pci0: at device 1.2 (no driver attached) vr0: port 0x1000-0x10ff mem 0xe0000000-0xe00000ff irq 10 at device 9.0 on pci0 vr0: Quirks: 0x2 miibus0: on vr0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: using obsoleted if_watchdog interface vr0: Ethernet address: 00:0d:b9:12:6f:00 vr0: [ITHREAD] vr1: port 0x1400-0x14ff mem 0xe0040000-0xe00400ff irq 11 at device 10.0 on pci0 vr1: Quirks: 0x2 miibus1: on vr1 ukphy1: PHY 1 on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr1: using obsoleted if_watchdog interface vr1: Ethernet address: 00:0d:b9:12:6f:01 vr1: [ITHREAD] vr2: port 0x1800-0x18ff mem 0xe0080000-0xe00800ff irq 12 at device 11.0 on pci0 vr2: Quirks: 0x2 miibus2: on vr2 ukphy2: PHY 1 on miibus2 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr2: using obsoleted if_watchdog interface vr2: Ethernet address: 00:0d:b9:12:6f:02 vr2: [ITHREAD] isab0: port 0x6000-0x6007,0x6100-0x61ff,0x6200-0x623f,0x9d00-0x9d7f,0x9c00-0x9c3f at device 15.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 15.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 15.3 (no driver attached) pci0: at device 15.4 (no driver attached) pci0: at device 15.5 (no driver attached) pmtimer0 on isa0 orm0: at iomem 0xe0000-0xeafff pnpid ORM0000 on isa0 ppc0: parallel port not found. sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled RTC BIOS diagnostic '''?GG'?(R)8u?mecounter "TSC" frequency 498052832 Hz quality 800 Timecounters tick every 1.000 msec Fast IPsec: Initialized Security Association Processing. ad0: 488MB at ata0-master WDMA2 Trying to mount root from ufs:/dev/ad0s1a cp: utimes: /var/var: No such file or directory cp: chown: /var/var: No such file or directory cp: chmod: /var/var: No such file or directory cp: chflags: /var/var: No such file or directory Loading configuration files. No suitable dump device was found. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1a: clean, 547545 free (13473 frags, 66759 blocks, 1.4% fragmentation) /dev/ad0s3: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s3: clean, 2829 free (21 frags, 351 blocks, 0.7% fragmentation) Setting hostuuid: 7ddaa94a-bfde-11d3-a30a-000db9126f00. Setting hostid: 0xd83cf1ce. Mounting local file systems:. Setting hostname: NANOBSD. net.inet6.ip6.auto_linklocal: 1 -> 0 vr: link state changed to UP DHCPDISCOVER on vr0 to 255.255.255.255 port 67 interval 3 DHCPOFFER from 192.168.1.254 DHCPREQUEST on vr0 to 255.255.255.255 port 67 DHCPACK from 192.168.1.254 bound to 192.168.1.66 -- renewal in 43200 seconds.v r1: link state changed to DOWN lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 vr0: flags=8843 metric 0 mtu 1500 options=b ether 00:0d:b9:12:6f:00 inet 192.168.1.66 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active vr1: flags=8843 metric 0 mtu 1500 options=b ether 00:0d:b9:12:6f:01 inet 1v72.16.1.1 netmasrk 0xffffff00 bro2adcast 172.16.1.:255 media: Eth ernet autoselectl (none) statusi: no carrier Adnditional routingk options:. Star ting devd. state changed to DOWN Generating host.conf. Additional IP options:. Mounting NFS file systems:. ELF ldconfig path: /lib /usr/lib /usr/local/lib a.out ldconfig path: /usr/lib/aout ldconfig: /usr/lib/aout: No such file or directory Creating and/or trimming log files:. Starting syslogd. /etc/rc: WARNING: Dump device does not exist. Savecore not run. Initial i386 initialization:. Additional ABI support:. Clearing /tmp (X related). Starting local daemons:. Updating motd. Mounting late file systems:. Generating public/private rsa1 key pair. Your identification has been saved in /etc/ssh/ssh_host_key. Your public key has been saved in /etc/ssh/ssh_host_key.pub. The key fingerprint is: 70:c3:d5:d2:8d:d3:68:d7:e8:91:fb:16:b0:1d:50:70 root@NANOBSD Generating public/private dsa key pair. Your identification has been saved in /etc/ssh/ssh_host_dsa_key. Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub. The key fingerprint is: 96:d8:bf:d2:39:30:5b:b7:9b:12:00:1d:67:84:f4:ff root@NANOBSD Generating public/private rsa key pair. Your identification has been saved in /etc/ssh/ssh_host_rsa_key. Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub. The key fingerprint is: fe:51:26:b5:12:7b:1f:ab:8e:6a:be:a6:3c:1a:c4:63 root@NANOBSD Starting sshd. mailwrapper: cannot exec /usr/libexec/sendmail/sendmail: No such file or directory /etc/rc: WARNING: /etc/mail/submit.cf is not readable. Starting cron. Local package initialization:. Starting background file system checks in 60 seconds. Sat Jan 1 00:01:04 UTC 2000 ???? At this point the keyboard doesn't respond me and i can't authenticate as root and change the password for use ssh later, however i believe that NanoBSD has not crashed or panic because it respond pings even more it respond ssh request but the root acount doesn't have a password :( This is my kernel config file: machine i386 cpu I486_CPU cpu I586_CPU #cpu I686_CPU ident ALIX_FIREWALL #options CPU_GEODE # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device #options NFSCLIENT # Network Filesystem Client #options NFSSERVER # Network Filesystem Server #options NFS_ROOT # NFS usable as /, requires NFSCLIENT #options MSDOSFS # MSDOS Filesystem #options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 #options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing options DEVICE_POLLING options IPSEC device tun #Tunnel driver (ppp(8), nos-tun(8)) device gre #IP over IP tunneling device if_bridge #Bridge interface device pf #PF OpenBSD packet-filter firewall device pflog #logging support interface for PF device pfsync #synchronization interface for PF device carp #Common Address Redundancy Protocol device enc #IPsec interface device crypto options ALTQ options ALTQ_CBQ # Class Bases Queueing options ALTQ_RED # Random Early Detection options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler options ALTQ_CDNR # Traffic conditioner options ALTQ_PRIQ # Priority Queueing options ALTQ_NOPCC # Required if the TSC is unusable options ALTQ_DEBUG # To make an SMP kernel, the next two lines are needed #options SMP # Symmetric MultiProcessor Kernel #device apic # I/O APIC # CPU frequency control device cpufreq # Bus support. device eisa device pci # Floppy drives #device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device ataraid # ATA RAID drives #device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. #device ahd # AHA39320/29320 and onboard AIC79xx devices #options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. #device amd # AMD 53C974 (Tekram DC-390(T)) #device hptiop # Highpoint RocketRaid 3xxx series #device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aha # Adaptec 154x SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) #device ch # SCSI media changers device da # Direct Access (disks) #device sa # Sequential Access (tape etc) #device cd # CD #device pass # Passthrough device (direct SCSI access) #device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device amr # AMI MegaRAID #device arcmsr # Areca SATA II RAID #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options #device hptmv # Highpoint RocketRAID 182x #device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx #device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID #device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers #device aac # Adaptec FSA RAID #device aacp # SCSI passthrough for aac (requires CAM) #device ida # Compaq Smart RAID #device mfi # LSI MegaRAID SAS #device mlx # Mylex DAC960 family #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver #device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc #device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') #device em # Intel PRO/1000 adapter Gigabit Ethernet Card #device ixgb # Intel PRO/10GbE Ethernet Card #device le # AMD Am7900 LANCE and Am79C9xx PCnet #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support #device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet #device bfe # Broadcom BCM440x 10/100 Ethernet #device bge # Broadcom BCM570xx Gigabit Ethernet #device dc # DEC/Intel 21143 and various workalikes #device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device lge # Level 1 LXT1001 gigabit Ethernet #device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet #device nfe # nVidia nForce MCP on-board Ethernet #device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking #device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') #device re # RealTek 8139C+/8169/8169S/8110S #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device stge # Sundance/Tamarack TC9021 gigabit Ethernet #device ti # Alteon Networks Tigon I/II gigabit Ethernet #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # Wireless NIC cards device wlan # 802.11 support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device wlan_scan_ap # 802.11 AP mode scanning device wlan_scan_sta # 802.11 STA mode scanning #device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) device ath_rate_sample # SampleRate tx rate control for ath #device awi # BayStack 660 and others #device ral # Ralink Technology RT2500 wireless NICs. device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) #device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device ehci # EHCI PCI->USB interface (USB 2.0) #device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse #device ural # Ralink Technology RT2500USB wireless NICs #device rum # Ralink Technology RT2501USB wireless NICs #device urio # Diamond Rio 500 MP3 player #device uscanner # Scanners # USB Ethernet, requires miibus #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cdce # Generic USB over Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) #device fwip # IP over FireWire (RFC 2734,3146) #device dcons # Dumb console driver #device dcons_crom # Configuration ROM for dcons And this is my NanoBSD configuration file: NANO_NAME=ALIX_PF NANO_SRC=/usr/src NANO_TOOLS=tools/tools/nanobsd NANO_PACKAGE_DIR=${NANO_SRC}/${NANO_TOOLS}/Pkg NANO_KERNEL=ALIX NANO_BOOT0CFG="-o nopacket -s 1 -m 3" NANO_NEWFS="-b 4096 -f 512 -i 8192 -O1 -U" NANO_DRIVE=ad0 NANO_IMAGES=1 NANO_CODESIZE=0 NANO_CONFSIZE=2048 NANO_DATASIZE=0 NANO_RAM_ETCSIZE=10240 NANO_RAM_TMPVARSIZE=10240 NANO_SECTS=63 NANO_HEADS=16 FlashDevice sandisk 512mb CONF_BUILD=' #NO_KLDLOAD=YES NO_NETGRAPH=YES NO_PAM=YES ' CONF_INSTALL=' NO_ACPI=YES NO_BLUETOOTH=YES NO_CVS=YES NO_FORTRAN=YES NO_HTML=YES NO_LPR=YES NO_MAN=YES NO_SENDMAIL=YES NO_SHAREDOCS=YES NO_EXAMPLES=YES NO_INSTALLLIB=YES NO_CALENDAR=YES NO_MISC=YES #NO_SHARE=YES ' CONF_WORLD=' NO_MODULES=YES NO_KERBEROS=YES NO_GAMES=YES NO_RESCUE=YES NO_LOCALES=YES NO_SYSCONS=YES NO_INFO=YES ' customize_cmd cust_install_files customize_cmd cust_pkg customize_cmd cust_allow_ssh_root Someone have any idea ? Thanks in advanced. -- "Linux is for people who hate Windows, BSD is for people who love UNIX". "Social Engineer -> Because there is no patch for human stupidity" "The Unix Guru's View of Sex unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; umount ; sleep." "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing." From mah at jump-ing.de Tue Oct 28 06:25:04 2008 From: mah at jump-ing.de (Markus Hitter) Date: Tue Oct 28 06:25:14 2008 Subject: Problem with NanoBSD login In-Reply-To: References: Message-ID: <42AA8307-6A3D-4ABC-B962-870E83090199@jump-ing.de> Am 28.10.2008 um 06:38 schrieb Espartano: > hi people, i have created a NanoBSD image, it boot pretty well. > > I'm trying to authenticate as root using a serial console but NanoBSD > doesn't show the correct login prompt, instead NanoBSD show strange > chars and it doesn't let me login in the system. [...] > cp: utimes: /var/var: No such file or directory > cp: chown: /var/var: No such file or directory > cp: chmod: /var/var: No such file or directory > cp: chflags: /var/var: No such file or directory Why is it looking for /var/var ? This dir usually doesn't exist. > Sat Jan 1 00:01:04 UTC 2000 > ???? Looks like you did something wrong in /etc/ttys, especially in it's line for /dev/ttyd0. Did you perhaps configure it to dial a modem? > At this point the keyboard doesn't respond me and i can't authenticate > as root and change the password for use ssh later, There are switches in /etc/ssh/sshd_config with the self-explaining names PermitRootLogin and AllowEmptyPassword. This could help you. HTH, MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From espartano.mail at gmail.com Tue Oct 28 08:45:29 2008 From: espartano.mail at gmail.com (Espartano) Date: Tue Oct 28 08:45:35 2008 Subject: Problem with NanoBSD login In-Reply-To: <42AA8307-6A3D-4ABC-B962-870E83090199@jump-ing.de> References: <42AA8307-6A3D-4ABC-B962-870E83090199@jump-ing.de> Message-ID: On Tue, Oct 28, 2008 at 12:25 AM, Markus Hitter wrote: > > Am 28.10.2008 um 06:38 schrieb Espartano: > >> hi people, i have created a NanoBSD image, it boot pretty well. >> >> I'm trying to authenticate as root using a serial console but NanoBSD >> doesn't show the correct login prompt, instead NanoBSD show strange >> chars and it doesn't let me login in the system. > > [...] >> >> cp: utimes: /var/var: No such file or directory >> cp: chown: /var/var: No such file or directory >> cp: chmod: /var/var: No such file or directory >> cp: chflags: /var/var: No such file or directory > > Why is it looking for /var/var ? This dir usually doesn't exist. I don't know, i didn't change anything for do that, i going to investigate. > >> Sat Jan 1 00:01:04 UTC 2000 >> ???? > > Looks like you did something wrong in /etc/ttys, especially in it's line for > /dev/ttyd0. Did you perhaps configure it to dial a modem? :O That was my mistake, i didn't configure the file /etc/ttys, already i have changed this line: ttyd0 "/usr/libexec/getty std.9600" dialup off secure to ttyd0 "/usr/libexec/getty std.9600" dialup on secure now all is fine thanks a lot :) -- "Linux is for people who hate Windows, BSD is for people who love UNIX". "Social Engineer -> Because there is no patch for human stupidity" "The Unix Guru's View of Sex unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; umount ; sleep." "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing." From mah at jump-ing.de Wed Oct 29 22:11:23 2008 From: mah at jump-ing.de (Markus Hitter) Date: Wed Oct 29 22:11:29 2008 Subject: FreeBSD kompakt Message-ID: <40D69C3A-16B9-4370-B9D5-FCD6FDF87EE4@jump-ing.de> Hello all, as promised, I've extracted the tinybsd related files from my current environment. Currently I build images with less than 6 MB disk space used. This is the bare minimum, of course. You can boot, log in, have a shell (/bin/sh only) and that's it. Cron, syslog and the likes should work. The main reason why I'm sending this is, I modified tinybsd pretty hefty, resulting in an almost-rewrite. Nevertheless, everything works as before, just a lot faster: kernel is built on demand only, the remaining part takes about 20 seconds. Additionally, the full file hierarchy is left aside, directories are created as needed. For more details I've left some comments in the script. Please let me know what you think about this and which parts I should extract as a precise patch for inclusion in FreeBSD. -------------- next part -------------- Cheers, MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From imp at bsdimp.com Wed Oct 29 22:32:36 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Wed Oct 29 22:32:42 2008 Subject: FreeBSD kompakt In-Reply-To: <40D69C3A-16B9-4370-B9D5-FCD6FDF87EE4@jump-ing.de> References: <40D69C3A-16B9-4370-B9D5-FCD6FDF87EE4@jump-ing.de> Message-ID: <20081029.163106.1474621784.imp@bsdimp.com> In message: <40D69C3A-16B9-4370-B9D5-FCD6FDF87EE4@jump-ing.de> Markus Hitter writes: : : Hello all, : : as promised, I've extracted the tinybsd related files from my current : environment. Currently I build images with less than 6 MB disk space : used. This is the bare minimum, of course. You can boot, log in, have : a shell (/bin/sh only) and that's it. Cron, syslog and the likes : should work. : : The main reason why I'm sending this is, I modified tinybsd pretty : hefty, resulting in an almost-rewrite. Nevertheless, everything works : as before, just a lot faster: kernel is built on demand only, the : remaining part takes about 20 seconds. Additionally, the full file : hierarchy is left aside, directories are created as needed. For more : details I've left some comments in the script. : : Please let me know what you think about this and which parts I should : extract as a precise patch for inclusion in FreeBSD. I'd love to let you know what we think, but I didn't see it in the post. Maybe it got eaten? If so, can you put it up on the net somewhere. Warner From isaac at ceetoneresearch.com Thu Oct 30 00:37:29 2008 From: isaac at ceetoneresearch.com (Isaac Levy) Date: Thu Oct 30 00:37:38 2008 Subject: FreeBSD kompakt In-Reply-To: <20081029.163106.1474621784.imp@bsdimp.com> References: <40D69C3A-16B9-4370-B9D5-FCD6FDF87EE4@jump-ing.de> <20081029.163106.1474621784.imp@bsdimp.com> Message-ID: <8102C9D2-7B6D-4202-BF48-D1B288E3FA46@ceetoneresearch.com> On Oct 29, 2008, at 6:31 PM, M. Warner Losh wrote: > In message: <40D69C3A-16B9-4370-B9D5-FCD6FDF87EE4@jump-ing.de> > Markus Hitter writes: > : > : Hello all, > : > : as promised, I've extracted the tinybsd related files from my > current > : environment. Currently I build images with less than 6 MB disk space > : used. This is the bare minimum, of course. You can boot, log in, > have > : a shell (/bin/sh only) and that's it. Cron, syslog and the likes > : should work. > : > : The main reason why I'm sending this is, I modified tinybsd pretty > : hefty, resulting in an almost-rewrite. Nevertheless, everything > works > : as before, just a lot faster: kernel is built on demand only, the > : remaining part takes about 20 seconds. Additionally, the full file > : hierarchy is left aside, directories are created as needed. For more > : details I've left some comments in the script. > : > : Please let me know what you think about this and which parts I > should > : extract as a precise patch for inclusion in FreeBSD. > > I'd love to let you know what we think, but I didn't see it in the > post. Maybe it got eaten? If so, can you put it up on the net > somewhere. > > Warner I'd really love to see this too! 6mb is pretty cool! Best, .ike From mah at jump-ing.de Thu Oct 30 07:07:42 2008 From: mah at jump-ing.de (Markus Hitter) Date: Thu Oct 30 07:07:49 2008 Subject: FreeBSD kompakt In-Reply-To: <20081029.163106.1474621784.imp@bsdimp.com> References: <40D69C3A-16B9-4370-B9D5-FCD6FDF87EE4@jump-ing.de> <20081029.163106.1474621784.imp@bsdimp.com> Message-ID: <10F69690-4A9B-4C39-A193-B541F0BF74B8@jump-ing.de> Am 29.10.2008 um 23:31 schrieb M. Warner Losh: > In message: <40D69C3A-16B9-4370-B9D5-FCD6FDF87EE4@jump-ing.de> > Markus Hitter writes: > : Please let me know what you think about this and which parts I > should > : extract as a precise patch for inclusion in FreeBSD. > > I'd love to let you know what we think, but I didn't see it in the > post. Maybe it got eaten? Yes, attachments obviously get stripped. Even if they're 12 kB only ;-) > If so, can you put it up on the net somewhere. Try These build commands should work: TINYDIR=/root/tinybsd cd /root tar -xvzf tinybsd-kompakt.tar.gz mv tinybsd-kompakt tinybsd ${TINYDIR}/tinybsd sectors=45000 conf=really-minimum mfsroot=yes \ image=/root/really-minimum.bin batch For running it I use qemu (on Ubuntu, as FreeBSD runs inside a virtual machine already): qemu -cpu pentium -drive file=really-minimum.bin Please let me know if you run into failures, as the above files are ripped out of a more complete setup. /etc/passwd and friends get copied over from the build machine, so passwords should be the same. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/