From bugmaster at FreeBSD.org Mon Dec 1 03:06:53 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Dec 1 03:07:36 2008 Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org Message-ID: <200812011106.mB1B6qFF052501@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 aduane at juniper.net Thu Dec 4 14:25:19 2008 From: aduane at juniper.net (Andrew Duane) Date: Thu Dec 4 14:25:26 2008 Subject: How to support a TrueIDE (ATA) NANDrive chip Message-ID: <0FCFCF6165E968449991746EB91D614D01FF35C9@antipi.jnpr.net> We have an SST NANDrive chip on our board that supports the simple ATA command set. What's the easiest way to get support for this into our kernel so we can partition and mount the device? Using "da" and "umass" isn't really an option, since it is neither SCSI, nor attached to USB. Pulling in all of "ata" seems like overkill; all we really need is read/write block and some simple sense commands. They are all synchronous, it's low traffic and we are more concerned with simplicity than performance. Is there some subset of "ata" I can use that won't involve pci bus, controllers, etc? We just want to be able to write the LBA, SECT_CNT, and GO command and read the data. -- Andrew Duane Juniper Networks 978-589-0551 10 Technology Park Dr aduane@juniper.net Westford, MA 01886-3418 From imp at bsdimp.com Thu Dec 4 14:39:04 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Dec 4 14:39:11 2008 Subject: Looking to formalize board support in embedded platforms. Message-ID: <20081204.153726.-1548257878.imp@bsdimp.com> I've spent a little bit of time implementing the start of board files for the arm port. The initial push has been for the at91 subport only, and many improvements could be made to this. I've written up my initial thoughts on this on the FreeBSD wiki http://wiki.freebsd.org/FreeBSDArmBoards/. It could use much improvement, I'm sure. One idea that hasn't been reflected there yet, was shown to me by Sam Laffler who suggested using linker sets to allow boards to 'probe', 'init' and other standardized functions. This is an interesting idea and I plan on working on adding it to the above links when Sam has results to share. I'd also like to expand the above wiki page to be a 'best practices' guide for all architectures where there's great diversity of boards/cpus/etc (eg, not the homogeneous env that x86 provides). I'm also soliciting comments on the above boards in addition to the above. Send them to me, or post them here. From antab at valka.is Thu Dec 4 22:22:02 2008 From: antab at valka.is (Arnar Mar Sig) Date: Thu Dec 4 22:22:13 2008 Subject: Looking to formalize board support in embedded platforms. In-Reply-To: <20081204.153726.-1548257878.imp@bsdimp.com> References: <20081204.153726.-1548257878.imp@bsdimp.com> Message-ID: <987F43D1-F7F8-4276-99BA-81F45D1F4BB0@valka.is> On Dec 4, 2008, at 11:37 PM, M. Warner Losh wrote: > I've spent a little bit of time implementing the start of board files > for the arm port. The initial push has been for the at91 subport only, > and many improvements could be made to this. I've written up my > initial thoughts on this on the FreeBSD wiki > http://wiki.freebsd.org/FreeBSDArmBoards/. It could use much > improvement, I'm sure. Some comments: What is the point of a std.* file for every board, cant this be in the config file? I can understand the reason for having std.at91 and std.xscale that board configs can include to set cpu dependent options. But imo it would be cleaner to skip the std.* files for the boards. "There's some suggestions that there be a separate "boards" directory. I'm not sure that I like it." Depends on have many board we have, with 2 board it doesn't matter much, but with 10+ board all with a separate std.*, *.c and maybe files.* then its probably best to add the "boards" directory. > > One idea that hasn't been reflected there yet, was shown to me by Sam > Laffler who suggested using linker sets to allow boards to 'probe', > 'init' and other standardized functions. This is an interesting idea > and I plan on working on adding it to the above links when Sam has > results to share. Sounds interesting > > I'd also like to expand the above wiki page to be a 'best practices' > guide for all architectures where there's great diversity of > boards/cpus/etc (eg, not the homogeneous env that x86 provides). Good thing. > > I'm also soliciting comments on the above boards in addition to the > above. Send them to me, or post them here. > _______________________________________________ > 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 > " Another thing semi related to board settings, device clocks. I see that in some of the device drivers for at91 the peripheral input clock is hard coded. This is probably fine for cpu's with one clock zone (don't know if at91 has one or many), but for cpu's like avr32 where you have many clock zones and peripherals can be connected to any one of them then hard coding this will not work. I think we need a clock framework (extension to the device driver framework?) to be able to lookup the peripherals input clock so the driver can calculates its prescalers right. This would also allow use to dynamically change the frequency for zones to get better power efficiency. Greets Arnar Mar Sig Valka ehf From imp at bsdimp.com Thu Dec 4 22:29:56 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Dec 4 22:30:03 2008 Subject: Looking to formalize board support in embedded platforms. In-Reply-To: <987F43D1-F7F8-4276-99BA-81F45D1F4BB0@valka.is> References: <20081204.153726.-1548257878.imp@bsdimp.com> <987F43D1-F7F8-4276-99BA-81F45D1F4BB0@valka.is> Message-ID: <20081204.232813.-1592326736.imp@bsdimp.com> In message: <987F43D1-F7F8-4276-99BA-81F45D1F4BB0@valka.is> Arnar Mar Sig writes: : On Dec 4, 2008, at 11:37 PM, M. Warner Losh wrote: : > I've spent a little bit of time implementing the start of board files : > for the arm port. The initial push has been for the at91 subport only, : > and many improvements could be made to this. I've written up my : > initial thoughts on this on the FreeBSD wiki : > http://wiki.freebsd.org/FreeBSDArmBoards/. It could use much : > improvement, I'm sure. : Some comments: : What is the point of a std.* file for every board, cant this be in the : config file? I can understand the reason for having std.at91 and : std.xscale that board configs can include to set cpu dependent : options. But imo it would be cleaner to skip the std.* files for the : boards. The thinking here is that each of the board defines a certain set of things that are standard for all users of that board, and that the kernel config just stitches together the non-board specific parts for the kernel. Each of these boards may have slightly different load addresses, and the like, and putting that in the kernels for the board is very repetitive and error prone. It is a hierarchy: boards define the most specific thing, and then include the next more general thing (usually the SoC definitions), which in turn includes the next more general thing (say, the family of devices) and so on until we get to the std.arm file which is what's standard for all arm boards. In any event, that's why it is there. I'll keep track of your comments. It may mean that how we're doing things is wrong, and your reaction to the solution to the wrongness informs us that something else is wrong... I'm not sure yet... : "There's some suggestions that there be a separate "boards" directory. : I'm not sure that I like it." : Depends on have many board we have, with 2 board it doesn't matter : much, but with 10+ board all with a separate std.*, *.c and maybe : files.* then its probably best to add the "boards" directory. I'll keep that in mind. You may be right... : > One idea that hasn't been reflected there yet, was shown to me by Sam : > Laffler who suggested using linker sets to allow boards to 'probe', : > 'init' and other standardized functions. This is an interesting idea : > and I plan on working on adding it to the above links when Sam has : > results to share. : Sounds interesting I'm very interested to see how his experiments work out. : > I'd also like to expand the above wiki page to be a 'best practices' : > guide for all architectures where there's great diversity of : > boards/cpus/etc (eg, not the homogeneous env that x86 provides). : Good thing. I hope so... : > I'm also soliciting comments on the above boards in addition to the : > above. Send them to me, or post them here. : > _______________________________________________ : > 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 : > " : : : Another thing semi related to board settings, device clocks. : I see that in some of the device drivers for at91 the peripheral input : clock is hard coded. This is probably fine for cpu's with one clock : zone (don't know if at91 has one or many), but for cpu's like avr32 : where you have many clock zones and peripherals can be connected to : any one of them then hard coding this will not work. The AT91 has several clock zones. We're trying to move away from having these clocks hard coded. It works for the moment, but doesn't scale well. We also need a generic hierarchical clock framework as well, since differing clock domains are a common feature of embedded processors. : I think we need a clock framework (extension to the device driver : framework?) to be able to lookup the peripherals input clock so the : driver can calculates its prescalers right. This would also allow use : to dynamically change the frequency for zones to get better power : efficiency. Absolutely! On the AT91 there's also a number of different ways to drive the core CPU frequency that help save energy, at the cost of a slight increase in latency to the memory chips. Some folks want less energy use, others want faster RAM access to improve their execution times (some folks are greedy and want both). Having the ability to control the clock domains would help this out a lot. This is an area that's rich for research, I think. People have done some interesting things here in Linux, and I think we can learn from their successes and failures. Thanks again for all your comments! I appreciate them. Warner : Greets : Arnar Mar Sig : Valka ehf : : From stas at FreeBSD.org Fri Dec 5 00:33:28 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Fri Dec 5 00:33:35 2008 Subject: How to support a TrueIDE (ATA) NANDrive chip In-Reply-To: <0FCFCF6165E968449991746EB91D614D01FF35C9@antipi.jnpr.net> References: <0FCFCF6165E968449991746EB91D614D01FF35C9@antipi.jnpr.net> Message-ID: <20081205113502.f9871231.stas@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 4 Dec 2008 17:23:41 -0500 Andrew Duane mentioned: > We have an SST NANDrive chip on our board that supports the simple ATA > command set. What's the easiest way to get support for this into our > kernel so we can partition and mount the device? > > Using "da" and "umass" isn't really an option, since it is neither SCSI, > nor attached to USB. Pulling in all of "ata" seems like overkill; all we > really need is read/write block and some simple sense commands. They are > all synchronous, it's low traffic and we are more concerned with > simplicity than performance. Is there some subset of "ata" I can use > that won't involve pci bus, controllers, etc? We just want to be able to > write the LBA, SECT_CNT, and GO command and read the data. > Why not attach the ATA stack to the register space the chip provides. Doesn't look like an overkill to me. It should work pretty well. I'm using something like this for AT91 CF controller. I'v attached it source, it might be useful to you. It's simple enough. - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkk457sACgkQK/VZk+smlYHvAQCfYOd+soOVtbmLr1mFC51irI3w YnQAni7TgWtsukf4ZcOS1lR9r/qAynyu =H60J -----END PGP SIGNATURE----- From raj at semihalf.com Fri Dec 5 07:30:09 2008 From: raj at semihalf.com (Rafal Jaworowski) Date: Fri Dec 5 07:30:14 2008 Subject: i2c(8) diagnostic tool for review Message-ID: <493943FC.8080001@semihalf.com> This nice little program is helpful with inspecting an I2C bus, when bringing up a new system, or just for diagnostic purposes: http://people.freebsd.org/~raj/patches/misc/i2c.diff Note the patch extends the /dev/iicX interface with a ioctl for the 'repeated start' method. More detailed description of the tool is in the manual page: http://people.freebsd.org/~raj/patches/misc/i2c-man.txt Any comments welcome. Rafal From imp at bsdimp.com Fri Dec 5 11:09:06 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Dec 5 11:09:12 2008 Subject: How to support a TrueIDE (ATA) NANDrive chip In-Reply-To: <20081205113502.f9871231.stas@FreeBSD.org> References: <0FCFCF6165E968449991746EB91D614D01FF35C9@antipi.jnpr.net> <20081205113502.f9871231.stas@FreeBSD.org> Message-ID: <20081205.120806.1661913579.imp@bsdimp.com> In message: <20081205113502.f9871231.stas@FreeBSD.org> Stanislav Sedov writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : On Thu, 4 Dec 2008 17:23:41 -0500 : Andrew Duane mentioned: : : > We have an SST NANDrive chip on our board that supports the simple ATA : > command set. What's the easiest way to get support for this into our : > kernel so we can partition and mount the device? : > : > Using "da" and "umass" isn't really an option, since it is neither SCSI, : > nor attached to USB. Pulling in all of "ata" seems like overkill; all we : > really need is read/write block and some simple sense commands. They are : > all synchronous, it's low traffic and we are more concerned with : > simplicity than performance. Is there some subset of "ata" I can use : > that won't involve pci bus, controllers, etc? We just want to be able to : > write the LBA, SECT_CNT, and GO command and read the data. : > : : Why not attach the ATA stack to the register space the chip provides. : Doesn't look like an overkill to me. It should work pretty well. : I'm using something like this for AT91 CF controller. I'v attached : it source, it might be useful to you. It's simple enough. I'd concur. I believe that we can configure the ata stuff such that we don't get pci, et al, in this case. If not, we should fix that. Warner From bms at FreeBSD.org Sat Dec 6 02:26:16 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Sat Dec 6 02:26:22 2008 Subject: i2c(8) diagnostic tool for review In-Reply-To: <493943FC.8080001@semihalf.com> References: <493943FC.8080001@semihalf.com> Message-ID: <493A4F45.9040105@FreeBSD.org> Looks good, though I haven't built or tested it. I've found smbmsg to be very useful, although of course if you are working with raw i2c, it's not useful. I noticed that the x1226 clock chip doesn't seem to show up on the NSLUG atthe i2c address I'd expect it to, this will come in very useful for that. I am doubtful I'll get free time to look at that right away-- I have new stuff brewing and want to try to hand off stuff where possible. cheers BMS From stas at FreeBSD.org Sat Dec 6 06:45:58 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Sat Dec 6 06:46:04 2008 Subject: i2c(8) diagnostic tool for review In-Reply-To: <493943FC.8080001@semihalf.com> References: <493943FC.8080001@semihalf.com> Message-ID: <20081206171829.82f0618a.stas@FreeBSD.org> On Fri, 05 Dec 2008 16:08:44 +0100 Rafal Jaworowski mentioned: > This nice little program is helpful with inspecting an I2C bus, when bringing > up a new system, or just for diagnostic purposes: > http://people.freebsd.org/~raj/patches/misc/i2c.diff > > Note the patch extends the /dev/iicX interface with a ioctl for the 'repeated > start' method. > > More detailed description of the tool is in the manual page: > http://people.freebsd.org/~raj/patches/misc/i2c-man.txt > > Any comments welcome. > Great! I haven't tried the tool itself yet, but there're some comments for the source itself. Hopefully, it'll be useful. > +The options are as follows: > +.Bl -tag -width ".Fl d Ar direction" > +.It Fl a Ar address > +7-bit address on the I2C device to operate on (hex). > +.It Fl f Ar device > +I2C bus to use (default is /dev/iic0). > +.It Fl d Ar r|w > +transfer direction: r - read, w - write. > +.It Fl w Ar 0|8|16 > +device addressing width (in bits). > +.It Fl o Ar offset > +offset within the device for data transfer (hex). > +.It Fl c Ar count > +number of bytes to transfer (dec). > +.It Fl m Ar ss|rs|no > +addressing mode, i.e., I2C bus operations performed after the offset for the > +transfer has been written to the device and before the actual read/write > +operation. rs - repeated start; ss - stop start; no - none. > +.It Fl v > +be verbose I think options here should come sorted if there're no specific needs. At least -v in the middle looks weird. > +.if ${MACHINE_ARCH} == "arm" > +_i2c= i2c > +.endif It there any specific reason the utility is limited to arm? I2C interface is generic enough, and I think the utility will be useful for other platforms as well. > +#define I2C_DEV "/dev/iic0" > +#define I2C_MODE_NOTSET 0 > +#define I2C_MODE_NONE 1 > +#define I2C_MODE_STOP_START 2 > +#define I2C_MODE_REPEATED_START 3 #define and name should delimited by tab according to style(9) > +static void > +usage(void) > +{ > + > + fprintf(stderr, "usage: %s -a addr [-f device] [-d [r|w]] [-o offset] " > + "[-w [0|8|16]] [-c count] [-m [ss|rs|no]] [-b] [-v]\n", > + getprogname()); > + fprintf(stderr, " %s -s [-f device] [-n skip_addr] -v\n", > + getprogname()); > + fprintf(stderr, " %s -r [-f device] -v\n", getprogname()); > + exit(1); > +} You're using sysexit codes everywhere, I suppose the exit code here should be EX_USAGE too? At least, it looks inconsistent to other parts of the code. Also it might make sense to mark the function as __dead2 as it never returns. This will enable a number of possible optimisations to gcc. > + token = strsep(&skip_addr, ".."); > + if (token) > + addr_range.end = strtoul(token, 0, 16); > + } I think there's a check missing around strtoul? > + if (token == NULL) > + break; > + sk_addr[i] = strtoul(token, 0, 16); > + } The same as above. > + tokens = (int *)malloc((len / 2 + 1) * sizeof(int)); > + index = skip_get_tokens(skip_addr, tokens, > + len / 2 + 1); > + } The check around malloc is missing. Also, len should be checked to be non-zero. > +prepare_buf(int size, uint32_t off) > +{ > + char *buf; > + > + buf = malloc(size); > + if (buf == NULL) > + return (buf); Consider adding a check around size. > +static int > +i2c_write(char *dev, struct options i2c_opt, char *i2c_buf) > +{ > + struct iiccmd cmd; > + int ch, i, error, fd, bufsize; > + char *err_msg, *buf; > + > + /* > + * Read data to be written to the chip from stdin > + */ > + if (i2c_opt.verbose && !i2c_opt.binary) > + fprintf(stderr, "Enter %u bytes of data: ", i2c_opt.count); > + > + for (i = 0; i < i2c_opt.count; i++) { > + ch = getchar(); > + if (ch == EOF) { > + free(i2c_buf); > + err(1, "not enough data, exiting\n"); > + } > + i2c_buf[i] = ch; > + } > + > + fd = open(dev, O_RDWR); > + if (fd == -1) { > + free(i2c_buf); > + err(1, "open failed"); > + } > + > + /* > + * Write offset where the data will go > + */ > + cmd.slave = i2c_opt.addr; > + error = ioctl(fd, I2CSTART, &cmd); > + if (error == -1) { > + err_msg = "ioctl: error sending start condition"; > + goto err1; > + } > + > + if (i2c_opt.width) { > + bufsize = i2c_opt.width / 8; > + buf = prepare_buf(bufsize, i2c_opt.off); > + if (buf == NULL) { > + err_msg = "error: offset malloc"; > + goto err1; > + } > + > + cmd.count = bufsize; > + cmd.buf = buf; > + error = ioctl(fd, I2CWRITE, &cmd); > + free(buf); > + if (error == -1) { > + err_msg = "ioctl: error when write offset"; > + goto err1; > + } > + } You're freeing i2c_buf on every exit, but not here. Why? Probably, it'll be better to move the buffer freeing duty to the calling function as the i2c_buf comes as an argument. It'll also help to eliminate a lot of code here. There're also a lot of places where buffer is not freed later in this function. > + i2c_opt.addr = (strtoul(optarg, 0, 16) << 1); > + i2c_opt.addr_set = 1; > + break; > + case 'f': > + dev = optarg; > + break; > + case 'd': > + i2c_opt.dir = optarg[0]; > + break; > + case 'o': > + i2c_opt.off = strtoul(optarg, 0, 16); > + break; > + case 'w': > + i2c_opt.width = atoi(optarg); > + break; > + case 'c': > + i2c_opt.count = atoi(optarg); > + break; > + case 'm': I think the checks around strtoul and atoi should be added to properly inform user about bad arguments passed, instead of just silently ignoring junk. > + if (i2c_opt.scan) { > + if (i2c_opt.addr_set) > + usage(); > + } else if (i2c_opt.reset) { > + if (i2c_opt.addr_set) > + usage(); > + } else if ((i2c_opt.dir == 'r' || i2c_opt.dir == 'w')) { > + if ((i2c_opt.addr_set == 0) || > + !(i2c_opt.width == 0 || i2c_opt.width == 8 || > + i2c_opt.width == 16)) > + usage(); > + } else > + usage(); I think this code could be simplifed, e.g. checks could be combined into a single if, like else if (i2c_opt.reset && i2c_opt.addr_set) an eliminating the default usage() case. There're also a number of minor spelling errors and extra spaces, I can look for them if needed. Thanks for a good work! -- Stanislav Sedov ST4096-RIPE From bugmaster at FreeBSD.org Mon Dec 8 03:06:54 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Dec 8 03:07:34 2008 Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org Message-ID: <200812081106.mB8B6rWL014214@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 raj at semihalf.com Mon Dec 8 06:27:57 2008 From: raj at semihalf.com (Rafal Jaworowski) Date: Mon Dec 8 06:28:04 2008 Subject: i2c(8) diagnostic tool for review In-Reply-To: <20081206171829.82f0618a.stas@FreeBSD.org> References: <493943FC.8080001@semihalf.com> <20081206171829.82f0618a.stas@FreeBSD.org> Message-ID: <493D2EE9.4060808@semihalf.com> Stanislav Sedov wrote: > On Fri, 05 Dec 2008 16:08:44 +0100 > Rafal Jaworowski mentioned: > >> This nice little program is helpful with inspecting an I2C bus, when bringing >> up a new system, or just for diagnostic purposes: >> http://people.freebsd.org/~raj/patches/misc/i2c.diff >> >> Note the patch extends the /dev/iicX interface with a ioctl for the 'repeated >> start' method. >> >> More detailed description of the tool is in the manual page: >> http://people.freebsd.org/~raj/patches/misc/i2c-man.txt >> >> Any comments welcome. >> > > Great! > I haven't tried the tool itself yet, but there're some comments for > the source itself. Hopefully, it'll be useful. Thanks a lot for the review and comments. We'll try to correct all identified issues. [...] >> +.if ${MACHINE_ARCH} == "arm" >> +_i2c= i2c >> +.endif > > It there any specific reason the utility is limited to arm? I2C interface > is generic enough, and I think the utility will be useful for other platforms > as well. It should work on any platform, actually it was also used on PowerPC MPC85XX without problems. It's only this current version of the patch that had build limited to ARM. Rafal From mah at jump-ing.de Tue Dec 9 10:11:44 2008 From: mah at jump-ing.de (Markus Hitter) Date: Tue Dec 9 10:11:52 2008 Subject: How to notify for maintenance Message-ID: Hello all, my TinyBSD box is running fine and for security reasons, I've removed (almost) everything executable. One of the few remainings is lighttpd, to make a web server. The small problem now is, this box needs some moderately complex maintenance from time to time which I want to do from the outside (another computer). Storing root keys and software to use it on the same computer running lighttpd doesn't make me feel good. The question is: How would I securely notify another computer to do this (automatic) maintenance? Whatever I think of, this requires at least an ssh certificate and is pretty universal allowing it to be used to trigger harmful things as well. Any insight to best practices is welcome. Thanks, Markus Hitter - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From brix at FreeBSD.org Tue Dec 9 12:29:01 2008 From: brix at FreeBSD.org (Henrik Brix Andersen) Date: Tue Dec 9 12:29:08 2008 Subject: How to notify for maintenance In-Reply-To: References: Message-ID: <20081209200929.GA42936@tirith.brixandersen.dk> On Tue, Dec 09, 2008 at 07:11:29PM +0100, Markus Hitter wrote: > The small problem now is, this box needs some moderately complex > maintenance from time to time which I want to do from the outside > (another computer). Storing root keys and software to use it on the > same computer running lighttpd doesn't make me feel good. > > The question is: How would I securely notify another computer to do > this (automatic) maintenance? Whatever I think of, this requires at > least an ssh certificate and is pretty universal allowing it to be > used to trigger harmful things as well. Turn the scenario the other way around and have the trusted 'remote' computer initiate the maintenance at given intervals? Brix -- Henrik Brix Andersen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 217 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-embedded/attachments/20081209/d86c45ad/attachment.pgp From mah at jump-ing.de Tue Dec 9 13:29:56 2008 From: mah at jump-ing.de (Markus Hitter) Date: Tue Dec 9 13:30:03 2008 Subject: How to notify for maintenance In-Reply-To: <20081209200929.GA42936@tirith.brixandersen.dk> References: <20081209200929.GA42936@tirith.brixandersen.dk> Message-ID: <734FD4D0-D897-4742-B7A7-E4BA42AB39D7@jump-ing.de> Am 09.12.2008 um 21:09 schrieb Henrik Brix Andersen: > Turn the scenario the other way around and have the trusted 'remote' > computer initiate the maintenance at given intervals? The unfortunate thing I forgot is, the web server is the only one meant to run around the clock. All others go to sleep, but can be woken on demand (by a special network ping). MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From brix at FreeBSD.org Tue Dec 9 13:50:55 2008 From: brix at FreeBSD.org (Henrik Brix Andersen) Date: Tue Dec 9 13:51:04 2008 Subject: How to notify for maintenance In-Reply-To: <734FD4D0-D897-4742-B7A7-E4BA42AB39D7@jump-ing.de> References: <20081209200929.GA42936@tirith.brixandersen.dk> <734FD4D0-D897-4742-B7A7-E4BA42AB39D7@jump-ing.de> Message-ID: <20081209215052.GC42936@tirith.brixandersen.dk> On Tue, Dec 09, 2008 at 10:29:37PM +0100, Markus Hitter wrote: > Am 09.12.2008 um 21:09 schrieb Henrik Brix Andersen: > > > Turn the scenario the other way around and have the trusted 'remote' > > computer initiate the maintenance at given intervals? > > The unfortunate thing I forgot is, the web server is the only one > meant to run around the clock. All others go to sleep, but can be > woken on demand (by a special network ping). How about making them wake-up on a timer event instead? Many BIOS'es support this. If this isn't good for you, you could perform the WoL as described above and still have the trusted, newly awakened host initiate the connection. Brix -- Henrik Brix Andersen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 217 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-embedded/attachments/20081209/2d922f01/attachment.pgp From mah at jump-ing.de Wed Dec 10 02:12:52 2008 From: mah at jump-ing.de (Markus Hitter) Date: Wed Dec 10 02:12:59 2008 Subject: How to notify for maintenance In-Reply-To: <20081209215052.GC42936@tirith.brixandersen.dk> References: <20081209200929.GA42936@tirith.brixandersen.dk> <734FD4D0-D897-4742-B7A7-E4BA42AB39D7@jump-ing.de> <20081209215052.GC42936@tirith.brixandersen.dk> Message-ID: Am 09.12.2008 um 22:50 schrieb Henrik Brix Andersen: > you could perform the WoL as described > above and still have the trusted, newly awakened host initiate the > connection. This one sounds the best, I'll follow that path. Many thanks, Henrik :-) MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From bms at incunabulum.net Sat Dec 13 09:06:36 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Sat Dec 13 09:06:42 2008 Subject: npe(4) closet cleaning Message-ID: <4943EB97.40109@incunabulum.net> Hi, Here is a patch I found I needed with the Freecom FSG3 to get other PHY drivers to attach. I have not committed it because it's strictly development code at the moment. cheers BMS -------------- next part -------------- Index: sys/arm/xscale/ixp425/if_npe.c =================================================================== --- sys/arm/xscale/ixp425/if_npe.c (revision 186036) +++ sys/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,6 +740,18 @@ 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; @@ -1598,6 +1617,14 @@ 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); + 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 +1632,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 +1645,7 @@ if (phy != sc->sc_phy) /* XXX */ return; + v = (phy << NPE_MII_ADDR_SHL) | (reg << NPE_MII_REG_SHL) | data | NPE_MII_WRITE | NPE_MII_GO; From bms at incunabulum.net Sat Dec 13 09:11:05 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Sat Dec 13 09:11:11 2008 Subject: ARM closet cleaning: static kenv Message-ID: <4943ECA5.6030203@incunabulum.net> This is a patch for avila_machdep to tell it to use a statically compiled kenv vector. I found I needed it when hacking on the NSLU2. cheers BMS -------------- next part -------------- Index: sys/arm/xscale/ixp425/avila_machdep.c =================================================================== --- sys/arm/xscale/ixp425/avila_machdep.c (revision 186036) +++ sys/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))); } From bms at incunabulum.net Sat Dec 13 09:12:48 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Sat Dec 13 09:12:57 2008 Subject: ARM closet cleaning: Freecom FSG3 configs Message-ID: <4943ED0C.4000006@incunabulum.net> Here are the configs for the FSG3 I was hacking on, pulled from a temporary svn branch. cheers BMS -------------- next part -------------- Index: sys/arm/conf/FSG3.hints =================================================================== --- sys/arm/conf/FSG3.hints (revision 0) +++ sys/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: sys/arm/conf/FSG3.env =================================================================== --- sys/arm/conf/FSG3.env (revision 0) +++ sys/arm/conf/FSG3.env (revision 0) @@ -0,0 +1 @@ +boot_verbose=YES Index: sys/arm/conf/FSG3 =================================================================== --- sys/arm/conf/FSG3 (revision 0) +++ sys/arm/conf/FSG3 (revision 0) @@ -0,0 +1,153 @@ +# FSG3 - kernel configuration file for FreeBSD/arm on Freecom FSG3. +# + +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 Dec 13 13:30:02 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sat Dec 13 13:30:09 2008 Subject: MIPS port repository question In-Reply-To: <20081115.100002.-1384053695.imp@bsdimp.com> References: <491EE062.2070705@incunabulum.net> <20081115.100002.-1384053695.imp@bsdimp.com> Message-ID: <49442957.9030300@incunabulum.net> M. Warner Losh wrote: > Most of the mips stuff has been pushed into the tree. The bleeding > edge stuff is still just in p4. I didn't merge your bfe(4) changes > into svn, but if you have something that's stable, there's no reason > not to do so. OK, it's still in p4 branch mips2. I committed the change there which lets the PHY for bfe(4) attach on the Sentry5. The Sentry5 machine itself is now with gonzo@. cheers BMS From brix at FreeBSD.org Sun Dec 14 06:58:11 2008 From: brix at FreeBSD.org (Henrik Brix Andersen) Date: Sun Dec 14 06:58:18 2008 Subject: iicbus(4) speed selection Message-ID: <20081214145807.GA18293@tirith.brixandersen.dk> Hi, One of the parameters to our iicbus_reset method is a speed selection, which can be either IIC_SLOW, IIC_FAST or IIC_FASTEST. Both arm/at91/at91_twi.c and dev/pcf/pcf.c interpret these as 1.5kb/s, 45kb/s and 90kb/s respectively, which has me wondering. Knowing I2C, I would have expected something like 10kb/s, 100kb/s and 400kb/s. Does anybody know why these speeds were selected when implementing the above mentioned drivers? Are new drivers required to match these speeds? Brix -- Henrik Brix Andersen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 217 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-embedded/attachments/20081214/e883fe8d/attachment.pgp From imp at bsdimp.com Sun Dec 14 09:15:18 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sun Dec 14 09:15:24 2008 Subject: iicbus(4) speed selection In-Reply-To: <20081214145807.GA18293@tirith.brixandersen.dk> References: <20081214145807.GA18293@tirith.brixandersen.dk> Message-ID: <20081214.091357.1649769204.imp@bsdimp.com> In message: <20081214145807.GA18293@tirith.brixandersen.dk> Henrik Brix Andersen writes: : Hi, : : One of the parameters to our iicbus_reset method is a speed selection, : which can be either IIC_SLOW, IIC_FAST or IIC_FASTEST. : : Both arm/at91/at91_twi.c and dev/pcf/pcf.c interpret these as 1.5kb/s, : 45kb/s and 90kb/s respectively, which has me wondering. Knowing I2C, I : would have expected something like 10kb/s, 100kb/s and 400kb/s. : : Does anybody know why these speeds were selected when implementing the : above mentioned drivers? Are new drivers required to match these : speeds? These speeds were pulled out of the air. I copied pcf's conventions. I think that really on the at91_twi the speeds were set in the TWI's hardware and the comments are just wrong. Warner From bugmaster at FreeBSD.org Mon Dec 15 03:06:50 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Dec 15 03:07:40 2008 Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org Message-ID: <200812151106.mBFB6n2f004283@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 Tue Dec 16 10:22:57 2008 From: mah at jump-ing.de (Markus Hitter) Date: Tue Dec 16 10:23:05 2008 Subject: Wake-on-lan packages don't get through Message-ID: <5CED6A5A-C532-4042-B7F3-264BD0C9791B@jump-ing.de> Hello all, glad to have found a binary[1] wake-on-lan program, I obvserve different behaviour of /usr/bin/wol on my full-size FreeBSD and my TinyBSD. From the full-size BSD (VirtualBox on Linux), i could capture this package after issueing wol: 18:50:30.019039 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 130) piccard.jump-ing.de.37597 > 255.255.255.255.40000: [bad udp cksum b716!] UDP, length 102 This package woke the targeted Macintosh. Doing the same on the embedded Flepo, I get: 01:38:35.500497 IP (tos 0x0, ttl 64, id 40022, offset 0, flags [none], proto UDP (17), length 130, bad cksum 0 (->d401)!) git.jump- ing.de.50582 > 255.255.255.255.40000: [bad udp cksum a1e4!] UDP, length 102 The later doesn't get through the switch, I can capture it on the sending host only. Accordingly, the Mac keeps sleeping. As both "wol" binaries are the very same (copied), I can rule out compilation errors. To be more funny, the Flepo serves web pages just fine. What does go wrong here? Thanks for any enlightenment, Markus [1] Using wakeonlan requires Perl, which in turn would more than double the size of the installation on the embedded box. - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From fb-embedded at psconsult.nl Tue Dec 16 11:29:49 2008 From: fb-embedded at psconsult.nl (Paul Schenkeveld) Date: Tue Dec 16 11:29:56 2008 Subject: Wake-on-lan packages don't get through In-Reply-To: <5CED6A5A-C532-4042-B7F3-264BD0C9791B@jump-ing.de> References: <5CED6A5A-C532-4042-B7F3-264BD0C9791B@jump-ing.de> Message-ID: <20081216191305.GA19656@psconsult.nl> Hi, On Tue, Dec 16, 2008 at 07:22:39PM +0100, Markus Hitter wrote: > > Hello all, > > glad to have found a binary[1] wake-on-lan program, I obvserve different > behaviour of /usr/bin/wol on my full-size FreeBSD and my TinyBSD. From the > full-size BSD (VirtualBox on Linux), i could capture this package after > issueing wol: > > 18:50:30.019039 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP > (17), length 130) piccard.jump-ing.de.37597 > 255.255.255.255.40000: [bad > udp cksum b716!] UDP, length 102 > > This package woke the targeted Macintosh. Doing the same on the embedded > Flepo, I get: > > 01:38:35.500497 IP (tos 0x0, ttl 64, id 40022, offset 0, flags [none], > proto UDP (17), length 130, bad cksum 0 (->d401)!) git.jump-ing.de.50582 > > 255.255.255.255.40000: [bad udp cksum a1e4!] UDP, length 102 > > The later doesn't get through the switch, I can capture it on the sending > host only. Accordingly, the Mac keeps sleeping. Please show a tcpdump -e output here. The wake-on-lan packet should be sent to the ethernet broadcast address (ff:ff:ff:ff:ff:ff) for the switch to send it to all ports (which is needed since it can't learn mac address from switched off nodes). On some of my machines I need to explicitely send the packet to the IP LAN broadcast address, e.g. 192.168.1.255 (assuming /24 netmask). > As both "wol" binaries are the very same (copied), I can rule out > compilation errors. To be more funny, the Flepo serves web pages just fine. > What does go wrong here? What about the kernels, are they the same version? and does your embedded system have more than one ethernet interface? > Thanks for any enlightenment, > Markus HTH > [1] Using wakeonlan requires Perl, which in turn would more than double the > size of the installation on the embedded box. > > - - - - - - - - - - - - - - - - - - - > Dipl. Ing. Markus Hitter > http://www.jump-ing.de/ Paul Schenkeveld From mah at jump-ing.de Wed Dec 17 07:38:37 2008 From: mah at jump-ing.de (Markus Hitter) Date: Wed Dec 17 07:38:44 2008 Subject: Wake-on-lan packages don't get through In-Reply-To: <20081216191305.GA19656@psconsult.nl> References: <5CED6A5A-C532-4042-B7F3-264BD0C9791B@jump-ing.de> <20081216191305.GA19656@psconsult.nl> Message-ID: <5B4E8A71-CD88-4C0F-BD47-74B1DF6B4E0E@jump-ing.de> Am 16.12.2008 um 20:13 schrieb Paul Schenkeveld: > On Tue, Dec 16, 2008 at 07:22:39PM +0100, Markus Hitter wrote: >> >> 18:50:30.019039 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], >> proto UDP >> (17), length 130) piccard.jump-ing.de.37597 > >> 255.255.255.255.40000: [bad >> udp cksum b716!] UDP, length 102 >> >> This package woke the targeted Macintosh. Doing the same on the >> embedded >> Flepo, I get: >> >> 01:38:35.500497 IP (tos 0x0, ttl 64, id 40022, offset 0, flags >> [none], >> proto UDP (17), length 130, bad cksum 0 (->d401)!) git.jump-ing.de. >> 50582 > >> 255.255.255.255.40000: [bad udp cksum a1e4!] UDP, length 102 >> >> The later doesn't get through the switch, I can capture it on the >> sending >> host only. Accordingly, the Mac keeps sleeping. > > Please show a tcpdump -e output here. (did that privately) > What about the kernels, are they the same version? and does your > embedded system have more than one ethernet interface? These two machines have different hardware, and the kernel of the embedded box is stripped, so yes, this might be different kernel behaviour. What bugs me is: neither ethernet package contains correct checksums. How is this possible if normal network operations obviously work just fine? Do I really have to debug the kernel driver? It's the "re" driver. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From mah at jump-ing.de Thu Dec 18 00:58:54 2008 From: mah at jump-ing.de (Markus Hitter) Date: Thu Dec 18 00:59:01 2008 Subject: Wake-on-lan packages don't get through In-Reply-To: <20081216191305.GA19656@psconsult.nl> References: <5CED6A5A-C532-4042-B7F3-264BD0C9791B@jump-ing.de> <20081216191305.GA19656@psconsult.nl> Message-ID: Am 16.12.2008 um 20:13 schrieb Paul Schenkeveld: > On some of my machines I need to explicitely send the packet to the > IP LAN broadcast address, e.g. 192.168.1.255 (assuming /24 netmask). This did the trick, finally. Those checksums reported as being bad were obviously a red herring. Thanks for helping, MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From fb-embedded at psconsult.nl Thu Dec 18 01:59:37 2008 From: fb-embedded at psconsult.nl (Paul Schenkeveld) Date: Thu Dec 18 01:59:48 2008 Subject: Wake-on-lan packages don't get through In-Reply-To: References: <5CED6A5A-C532-4042-B7F3-264BD0C9791B@jump-ing.de> <20081216191305.GA19656@psconsult.nl> Message-ID: <20081218095930.GA85416@psconsult.nl> Hi, On Thu, Dec 18, 2008 at 09:58:53AM +0100, Markus Hitter wrote: > > Am 16.12.2008 um 20:13 schrieb Paul Schenkeveld: > >> On some of my machines I need to explicitely send the packet to the >> IP LAN broadcast address, e.g. 192.168.1.255 (assuming /24 netmask). > > This did the trick, finally. Those checksums reported as being bad were > obviously a red herring. Does your network card support checksum offload (TXCSUM set in ifconfig options)? In that case tcpdump on the output interface will show bad checksums as the checksum gets calculated later on by the card. If you tcpdump on another computer in the same LAN you'll see the wake-on-lan packets with correct checksums. > Thanks for helping, You're welcome. > MarKus Regards, Paul Schenkeveld From mah at jump-ing.de Thu Dec 18 04:53:22 2008 From: mah at jump-ing.de (Markus Hitter) Date: Thu Dec 18 04:53:29 2008 Subject: Wake-on-lan packages don't get through In-Reply-To: <20081218095930.GA85416@psconsult.nl> References: <5CED6A5A-C532-4042-B7F3-264BD0C9791B@jump-ing.de> <20081216191305.GA19656@psconsult.nl> <20081218095930.GA85416@psconsult.nl> Message-ID: Am 18.12.2008 um 10:59 schrieb Paul Schenkeveld: > Does your network card support checksum offload (TXCSUM set in > ifconfig > options)? In that case tcpdump on the output interface will show bad > checksums as the checksum gets calculated later on by the card. Yes it does and I'm glad to see there's no need to fix the driver :-) MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ From gjb at semihalf.com Fri Dec 19 06:30:09 2008 From: gjb at semihalf.com (Grzegorz Bernacki) Date: Fri Dec 19 06:30:25 2008 Subject: Multiple virtual mappings considered harmful on ARM Message-ID: <494BAA90.7000801@semihalf.com> Hi, I've investigated lately problem with data corruption when copying big files on ARM machine. Below are my findings. 1. High level scenario. Problem occurs during copying of big files (~300MB and more). Calculated MD5 checksums for original and copied files are different. Chunks of data which get corrupted have always 32 bytes in length i.e. cache line length. 2. Root cause. The root cause of the problem is additional virtual mapping of read/write buffers at cluster read/write (sys/kern/vfs_cluster.c, cluster_rbuild(), cluster_wbuild(). Buffers for sequential read/write operation are concatenated and sent to device as one big buffer. Concatenation of buffers uses pmap_qenter(), which puts *additional* mapping in the KVA for physical area already mapped. For each buffer we extract pages it contains and then all the pages from all the buffers are mapped into new virtual address of new buffer. So we end up with at least two virtual addresses for each page. Such scenario on systems with virtual cache (most ARMs) leads to serious problems: we can have unflushed modified data pertaining to the same physical pages cached in separate cache blocks: data written back first (associated with virtual mapping #1) is potentially overwritten by data associated with virtual mapping #2 when its cache content is written back later, or vice versa. 3. Workaround for FFS read/write problems - avoid clustered reading/writing on ARM: # mount -o noclusterr -o noclusterw /dev/da0a /mnt/ 4. More general solution. This is the second time we indentified a problem of the same nature related to multiple virtual mapping on ARM, and are wondering about some more general solution that would prevent us from such problems (very subtle and hard to nail down) in the future. We were thinking at least about an extension to DIAGNOSTIC that would detect such attempts or so. Any other suggestions or comments welcome. From gjb at semihalf.com Fri Dec 19 06:57:00 2008 From: gjb at semihalf.com (Grzegorz Bernacki) Date: Fri Dec 19 06:57:11 2008 Subject: Multiple virtual mappings considered harmful on ARM In-Reply-To: <200812191452.mBJEqnaM040259@casselton.net> References: <200812191452.mBJEqnaM040259@casselton.net> Message-ID: <494BB647.2060807@semihalf.com> Mark Tinguely wrote: > > which version of FreeBSD (7 or -current). > It is -current. pozdrawiam, Grzesiek From tinguely at casselton.net Fri Dec 19 07:03:42 2008 From: tinguely at casselton.net (Mark Tinguely) Date: Fri Dec 19 07:03:58 2008 Subject: Multiple virtual mappings considered harmful on ARM In-Reply-To: <494BAA90.7000801@semihalf.com> Message-ID: <200812191452.mBJEqnaM040259@casselton.net> > I've investigated lately problem with data corruption when copying big files > on ARM machine. Below are my findings. ... which version of FreeBSD (7 or -current). --Mark Tinguely. From tinguely at casselton.net Fri Dec 19 08:11:29 2008 From: tinguely at casselton.net (Mark Tinguely) Date: Fri Dec 19 08:11:40 2008 Subject: Multiple virtual mappings considered harmful on ARM In-Reply-To: <494BB647.2060807@semihalf.com> Message-ID: <200812191611.mBJGBRna044291@casselton.net> Looking at the pmap code real quick, I think the original authors assumed quick kernel entries were not shared. Since they can be, we should have to add pv_entrys and the cache vac/fix process on the pmap_kenter_internal called routines too. I am still thinking the ARM code should revolve to FreeBSD style (recursive page tables, make SMP ready, etc). --Mark. From imp at bsdimp.com Fri Dec 19 08:48:47 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Dec 19 08:48:59 2008 Subject: Multiple virtual mappings considered harmful on ARM In-Reply-To: <494BAA90.7000801@semihalf.com> References: <494BAA90.7000801@semihalf.com> Message-ID: <20081219.094732.461359941.imp@bsdimp.com> In message: <494BAA90.7000801@semihalf.com> Grzegorz Bernacki writes: : 2. Root cause. ... : So we end up with at least two virtual addresses for each page. ... : 4. More general solution. : This is the second time we indentified a problem of the same nature related to : multiple virtual mapping on ARM, and are wondering about some more general : solution that would prevent us from such problems (very subtle and hard to : nail down) in the future. We were thinking at least about an extension to : DIAGNOSTIC that would detect such attempts or so. Any other suggestions or : comments welcome. I think this is an excellent idea. MIPS will need this too, since it too suffers from the virtual aliasing problem. Warner From xcllnt at mac.com Fri Dec 19 10:30:40 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri Dec 19 10:30:51 2008 Subject: Multiple virtual mappings considered harmful on ARM In-Reply-To: <494BAA90.7000801@semihalf.com> References: <494BAA90.7000801@semihalf.com> Message-ID: On Dec 19, 2008, at 6:07 AM, Grzegorz Bernacki wrote: > 2. Root cause. > The root cause of the problem is additional virtual mapping of read/ > write > buffers at cluster read/write (sys/kern/vfs_cluster.c, > cluster_rbuild(), > cluster_wbuild(). Buffers for sequential read/write operation are > concatenated > and sent to device as one big buffer. Concatenation of buffers uses > pmap_qenter(), which puts *additional* mapping in the KVA for > physical area > already mapped. For each buffer we extract pages it contains and > then all the > pages from all the buffers are mapped into new virtual address of > new buffer. > So we end up with at least two virtual addresses for each page. Could this also affect I-cache coherency by virtue of not flushing the D-cache properly before synchronizing the I-cache, as you mention reading? -- Marcel Moolenaar xcllnt@mac.com From bugmaster at FreeBSD.org Mon Dec 22 03:06:49 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Dec 22 03:07:40 2008 Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org Message-ID: <200812221106.mBMB6mvu060524@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 Tue Dec 23 05:46:11 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Dec 23 05:46:18 2008 Subject: STR9104 ARM system available Message-ID: <4950EBA1.2090209@incunabulum.net> [Mail to embedded I'm not subscribed to freebsd-arm] Hi, I have been collating my bits, and I have an Emprex p2p Download Engine NAS-100 available. Cash flow is king at the moment, but I'd rather donate it than go to the trouble of selling it on. The STR9104 is a low power ARM-based system-on-chip. Cavium acquired Star, and sent links to Linksys GPL source tarballs. These contain some but not all of the story. As documented in earlier threads on this list, it is possible to crack into the boot loader by deliberately corrupting the flash environment region. There is also a guy working on pushing support for this SoC into Linux 2.6; link not to hand, easily searchable on the web. Let me know if you're interested in working on getting FreeBSD onto this platform, and I can send this box to you. thanks, BMS From bms at incunabulum.net Tue Dec 23 06:03:53 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Dec 23 06:03:59 2008 Subject: STR9104 ARM system available In-Reply-To: <4950EBA1.2090209@incunabulum.net> References: <4950EBA1.2090209@incunabulum.net> Message-ID: <4950EFC6.3050002@incunabulum.net> link re-dug: http://tinyhack.com/2008/06/05/porting-linux-kernel-26254-to-star-str9100-agestar/ From bugmaster at FreeBSD.org Mon Dec 29 03:06:53 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Dec 29 03:07:36 2008 Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org Message-ID: <200812291106.mBTB6qDT024394@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 matt at smiffytech.com Tue Dec 30 03:37:48 2008 From: matt at smiffytech.com (Matthew Smith) Date: Tue Dec 30 03:37:54 2008 Subject: Best FreeBSD version for NanoBSD on an old SBC Message-ID: <495993FF.1060701@smiffytech.com> Hi Folks I am putting together a machine to act as a GPS-disciplined time server (NTPd with kernel PPS) and acquire data from my 1-Wire weather system (OWW). The hardware I have to hand are a Pentium SBC with 16Mb RAM and a 12Gb laptop disc. I assume that the best OS to put on this would be NanoBSD but was wondering if there was a specific version of FreeBSD that would be best to base it on. (Recent experience with a certain other Unix-like OS has taught me that newer versions suck with older hardware; I don't know if this is the case with FreeBSD.) I can get away with putting a bigger disc on although I don't particularly want to as this would cause issues with the power supply. (Using a vehicle power supply so that I can run it on float-charged gel cells.) The RAM, however, can't go any bigger. Any advice on this would be appreciated. Cheers M -- Matthew Smith Smiffytech - Technology Consulting & Web Application Development Business: http://www.smiffytech.com/ Personal: http://www.smiffysplace.com/ LinkedIn: http://www.linkedin.com/in/smiffy From philip.mullis at syx.ca Tue Dec 30 04:02:32 2008 From: philip.mullis at syx.ca (Philip Mullis) Date: Tue Dec 30 04:02:39 2008 Subject: Best FreeBSD version for NanoBSD on an old SBC In-Reply-To: <495993FF.1060701@smiffytech.com> References: <495993FF.1060701@smiffytech.com> Message-ID: <495998B3.4010008@syx.ca> you have to check the hardware in detail and make sure all the chipsets are supported, youll also want to research if there are any major imporements to driver support in later FreeBSD versions, that been said you can make some tiny foot prints and with kernel customization and packages you can fit a hapilty running os running 7.x on a 256meg card, i have 6.4 in a 14meg gz'd which mfsroot's on boot. so what you have seems quick ample you'll just need to make sure to trim where possible 6.x or 7.x its your choice, but research first. Hope that helps some Regards, Philip Mullis Matthew Smith wrote: > Hi Folks > > I am putting together a machine to act as a GPS-disciplined time > server (NTPd with kernel PPS) and acquire data from my 1-Wire weather > system (OWW). > > The hardware I have to hand are a Pentium SBC with 16Mb RAM and a 12Gb > laptop disc. > > I assume that the best OS to put on this would be NanoBSD but was > wondering if there was a specific version of FreeBSD that would be > best to base it on. (Recent experience with a certain other Unix-like > OS has taught me that newer versions suck with older hardware; I don't > know if this is the case with FreeBSD.) > > I can get away with putting a bigger disc on although I don't > particularly want to as this would cause issues with the power supply. > (Using a vehicle power supply so that I can run it on float-charged > gel cells.) The RAM, however, can't go any bigger. > > Any advice on this would be appreciated. > > Cheers > > M > From bms at FreeBSD.org Tue Dec 30 17:20:52 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Tue Dec 30 17:20:59 2008 Subject: Best FreeBSD version for NanoBSD on an old SBC In-Reply-To: <495993FF.1060701@smiffytech.com> References: <495993FF.1060701@smiffytech.com> Message-ID: <495A53CD.7070007@FreeBSD.org> Matthew Smith wrote: > Hi Folks > > I am putting together a machine to act as a GPS-disciplined time > server (NTPd with kernel PPS) and acquire data from my 1-Wire weather > system (OWW). > > The hardware I have to hand are a Pentium SBC with 16Mb RAM and a 12Gb > laptop disc. > > I assume that the best OS to put on this would be NanoBSD but was > wondering if there was a specific version of FreeBSD that would be > best to base it on. (Recent experience with a certain other Unix-like > OS has taught me that newer versions suck with older hardware; I don't > know if this is the case with FreeBSD.) NanoBSD is absolutely great. XORP, Inc. are using it for their LiveCD/LiveUSB builds at the moment. I got good results on a 400MHz Celeron w/128MB of memory. The key thing is to be able to leave enough in the base install for what you need -- it doesn't strip absolutely everything, and whilst the XORP LiveCD is now considerably smaller, and thus quicker to download, than it was (thanks to NanoBSD), it is quite a generic place to start: http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/other/LiveCD/ The stuff there is intended to be checked out and copied 'on top' of a FreeBSD 7-STABLE source tree checkout. The USB stick generation stuff has been merged back to FreeBSD itself, but not the LiveCD bits. Of course NanoBSD would work just fine w/o the patches for making ATA drive images. You would probably do much better with CompactFlash in your rig. For DRAM, 16MB may be seriously pushing it now, 32MB is really a realistic minimum for FreeBSD on x86 these days on any platform. > > I can get away with putting a bigger disc on although I don't > particularly want to as this would cause issues with the power supply. > (Using a vehicle power supply so that I can run it on float-charged > gel cells.) The RAM, however, can't go any bigger. Gels are nice, though I believe they can't be reconditioned. Of course the embeddability situation should get better as time goes on. I would LOVE to see pfSense running on non-x86 embedded hardware. Don't forget I have an Emprex STR9104 ARM to donate to an interested developer. cheers, BMS From matt at smiffytech.com Tue Dec 30 23:07:31 2008 From: matt at smiffytech.com (Matthew Smith) Date: Tue Dec 30 23:07:37 2008 Subject: Best FreeBSD version for NanoBSD on an old SBC In-Reply-To: <495A53CD.7070007@FreeBSD.org> References: <495993FF.1060701@smiffytech.com> <495A53CD.7070007@FreeBSD.org> Message-ID: <495AA9B0.9050104@smiffytech.com> Thanks for your reply, Bruce. Quoth Bruce M. Simpson at 2008-12-31 03:31... ... > The key thing is to be able to leave enough in the base install for > what you need -- it doesn't strip absolutely everything, and whilst the > XORP LiveCD is now considerably smaller, and thus quicker to download, > than it was (thanks to NanoBSD), it is quite a generic place to start: > http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/other/LiveCD/ Ta. I'll have a look at that. > Of course NanoBSD would work just fine w/o the patches for making > ATA drive images. You would probably do much better with CompactFlash in > your rig. For DRAM, 16MB may be seriously pushing it now, 32MB is really > a realistic minimum for FreeBSD on x86 these days on any platform. Not sure if CF would be totally suitable for this as I believe that ntpd needs to do a lot of logging - don't know if CF still has the issue with a finite number of writes. (Also trying to do this on virtually zero budget and with what I've got so don't really want to start forking out for extra bits.) I'm surprised about the RAM though seeing as how my first Unix box (IBM 6150), which ran the whole company, started off with only 8Mb! (And that was a card about the size of a keyboard.) I've run minimal Linux distributions on this hardware (the x86 SBC, not the 6150) so wonder what in FreeBSD is gobbling up the resources - and whether it can be pruned out. I'm sure that there is a load of stuff in the kernel that is unnecessary for simple, old, hardware on a headless machine - but then maybe this is already removed on NanoBSD. > Gels are nice, though I believe they can't be reconditioned. > Of course the embeddability situation should get better as time goes on. This is and physically small alternative to yet another UPS - and should probably be able to run the system for a fair while too. I should be able to squeeze these, 13.8V PSU, the SBC, GPS module and 1-Wire interface all into an old PC case. Cheers M -- Matthew Smith Smiffytech - Technology Consulting & Web Application Development Business: http://www.smiffytech.com/ Personal: http://www.smiffysplace.com/ LinkedIn: http://www.linkedin.com/in/smiffy From imp at bsdimp.com Tue Dec 30 23:20:25 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Dec 30 23:20:32 2008 Subject: Best FreeBSD version for NanoBSD on an old SBC In-Reply-To: <495AA9B0.9050104@smiffytech.com> References: <495993FF.1060701@smiffytech.com> <495A53CD.7070007@FreeBSD.org> <495AA9B0.9050104@smiffytech.com> Message-ID: <20081230.161804.1573371236.imp@bsdimp.com> In message: <495AA9B0.9050104@smiffytech.com> Matthew Smith writes: : Thanks for your reply, Bruce. : : Quoth Bruce M. Simpson at 2008-12-31 03:31... : ... : > The key thing is to be able to leave enough in the base install for : > what you need -- it doesn't strip absolutely everything, and whilst the : > XORP LiveCD is now considerably smaller, and thus quicker to download, : > than it was (thanks to NanoBSD), it is quite a generic place to start: : > http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/other/LiveCD/ : Ta. I'll have a look at that. : : > Of course NanoBSD would work just fine w/o the patches for making : > ATA drive images. You would probably do much better with CompactFlash in : > your rig. For DRAM, 16MB may be seriously pushing it now, 32MB is really : > a realistic minimum for FreeBSD on x86 these days on any platform. : Not sure if CF would be totally suitable for this as I believe that ntpd : needs to do a lot of logging - don't know if CF still has the issue with : a finite number of writes. (Also trying to do this on virtually zero : budget and with what I've got so don't really want to start forking out : for extra bits.) CF is fine for this application. Most CF cards can cope with the limited traffic of an NTP server. : I'm surprised about the RAM though seeing as how my first Unix box (IBM : 6150), which ran the whole company, started off with only 8Mb! (And : that was a card about the size of a keyboard.) I've run minimal Linux : distributions on this hardware (the x86 SBC, not the 6150) so wonder : what in FreeBSD is gobbling up the resources - and whether it can be : pruned out. I'm sure that there is a load of stuff in the kernel that : is unnecessary for simple, old, hardware on a headless machine - but : then maybe this is already removed on NanoBSD. You can run FreeBSD on a 16MB box, but you have to do some careful tricks to change the current bias in optimization of the kernel from speed to size. And you have to carefully prune your kernel to the bone. And you have to trim the applications that are run as well, since that's where the bulk of the memory usage comes from. Linux has these same issues, the knobs to optimize for them are better labeled and documented. Warner From gjb at semihalf.com Wed Dec 31 11:18:48 2008 From: gjb at semihalf.com (Grzegorz Bernacki) Date: Wed Dec 31 11:18:59 2008 Subject: Multiple virtual mappings considered harmful on ARM In-Reply-To: References: <494BAA90.7000801@semihalf.com> Message-ID: <495B5531.8040604@semihalf.com> Marcel Moolenaar wrote: > > On Dec 19, 2008, at 6:07 AM, Grzegorz Bernacki wrote: > >> 2. Root cause. >> The root cause of the problem is additional virtual mapping of read/write >> buffers at cluster read/write (sys/kern/vfs_cluster.c, cluster_rbuild(), >> cluster_wbuild(). Buffers for sequential read/write operation are >> concatenated >> and sent to device as one big buffer. Concatenation of buffers uses >> pmap_qenter(), which puts *additional* mapping in the KVA for physical >> area >> already mapped. For each buffer we extract pages it contains and then >> all the >> pages from all the buffers are mapped into new virtual address of new >> buffer. >> So we end up with at least two virtual addresses for each page. > > Could this also affect I-cache coherency by virtue of not > flushing the D-cache properly before synchronizing the > I-cache, as you mention reading? > I am not sure. I can't think of scenario which might lead to I-cache incoherency. Have you experienced any issues with I-cache which might be related described problem? pozdrawiam, Grzesiek From tinguely at casselton.net Wed Dec 31 14:32:18 2008 From: tinguely at casselton.net (Mark Tinguely) Date: Wed Dec 31 14:32:24 2008 Subject: Multiple virtual mappings considered harmful on ARM In-Reply-To: <495B5531.8040604@semihalf.com> Message-ID: <200812311432.mBVEWF6O047499@casselton.net> > Marcel Moolenaar wrote: > > > > On Dec 19, 2008, at 6:07 AM, Grzegorz Bernacki wrote: > > > >> 2. Root cause. > >> The root cause of the problem is additional virtual mapping of read/write > >> buffers at cluster read/write (sys/kern/vfs_cluster.c, cluster_rbuild(), > >> cluster_wbuild(). Buffers for sequential read/write operation are > >> concatenated > >> and sent to device as one big buffer. Concatenation of buffers uses > >> pmap_qenter(), which puts *additional* mapping in the KVA for physical > >> area > >> already mapped. For each buffer we extract pages it contains and then > >> all the > >> pages from all the buffers are mapped into new virtual address of new > >> buffer. > >> So we end up with at least two virtual addresses for each page. > > > > Could this also affect I-cache coherency by virtue of not > > flushing the D-cache properly before synchronizing the > > I-cache, as you mention reading? > > > > I am not sure. I can't think of scenario which might lead to I-cache incoherency. > Have you experienced any issues with I-cache which might be related described problem? > > pozdrawiam, > Grzesiek If would be surprised for you to see an I-cache problems. pmap_qenter() writes back any managed cache pages (already under the control of a pv_entry) and then calls pmap_kenter_internal(), which tries to writeback and invalid any previously mapped pages. At the end of the pmap_qenter() the caches are clean. The problem is the new mapping is added with cache turned on, and the old mapping's page table caching is not modified either, so if either side modifies the page, there can be this caching problem. I think that the pmap_kenter_internal() should become a special kind of managed page (controlled by a pv_entry and a special flag, (I called PVF_UNMAN) that runs through the pmap_fix_cache(), so the mappings for the shared page should have the cache turned off. There are special checks The less obvious question is should PG_UNMANAGED pages be simularly managed? Or put another way, could the PG_UNMANAGED page be remapped by the I/O caching programs? My guts says yes. Doing so also forces BUS_DMA_COHERENT pages to turn off the caches on the share page. I have a crude workup of my idea, but I have to admit, I don't have the equipment to even try to compile it. There concerns about pv_entry use increase, there is lock issues, performance, and even could we cause a problem trying get a pv_entry at the wrong time, such as interrupt. Maybe the kernel pv_entrys need to come from a special pool. I have some crude ideas to flush the caches less often in the ARM11's virtual index / physical tag caches and ideas for the multicore physical index / physical tag cache. --Mark Tinguely