Re: genuine cpu I386_CPU kernel support
On 22 Sep 2009, at 19:03, Nate Eldredge wrote: On Tue, 22 Sep 2009, John Baldwin wrote: My comment is to just use 4.x (seriously). A true 386 is going to be quite slow and the overhead of many things added that work well on newer processors is going to be very painful on a 386 (probably on a 486 as well). 4.x runs fine on a 386 and should support all the hardware you can stick into a machine with an 80386 CPU. Unless, of course, you plan to put it on a network. I doubt that 4.x is up to date with respect to security patches. I don't know if they were all applied on 4.x, but I think at least the older ones are. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: genuine cpu I386_CPU kernel support
Rui Paulo wrote: On 22 Sep 2009, at 19:03, Nate Eldredge wrote: On Tue, 22 Sep 2009, John Baldwin wrote: My comment is to just use 4.x (seriously). A true 386 is going to be quite slow and the overhead of many things added that work well on newer processors is going to be very painful on a 386 (probably on a 486 as well). 4.x runs fine on a 386 and should support all the hardware you can stick into a machine with an 80386 CPU. Unless, of course, you plan to put it on a network. I doubt that 4.x is up to date with respect to security patches. I don't know if they were all applied on 4.x, but I think at least the older ones are. 4.11 fell out of security support some while back, but http://www.freebsd.org/security/index.html only lists what's still in, not what fell out when. Free/ Net/ Open/ Dragon etc all derive from Bill Jollitz port of BSD to 386. Would be nice if we could still keep that first platform walking, even if speed can't be called running ;-) Maybe I'll get time to chase down all that came before http://svn.freebsd.org/viewvc/base?view=revisionrevision=137784 Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail ASCII plain text not HTML Base64. http://asciiribbon.org Virused Microsoft PCs cause spam. http://berklix.com/free/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: genuine cpu I386_CPU kernel support
On 23 Sep 2009, at 16:54, Julian H. Stacey wrote: 4.11 fell out of security support some while back, but http://www.freebsd.org/security/index.html only lists what's still in, not what fell out when. Right, but IIRC there were some folks patch 4-STABLE after the security officer dropped it. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: genuine cpu I386_CPU kernel support
On Wednesday 23 September 2009 11:54:34 am Julian H. Stacey wrote: Rui Paulo wrote: On 22 Sep 2009, at 19:03, Nate Eldredge wrote: On Tue, 22 Sep 2009, John Baldwin wrote: My comment is to just use 4.x (seriously). A true 386 is going to be quite slow and the overhead of many things added that work well on newer processors is going to be very painful on a 386 (probably on a 486 as well). 4.x runs fine on a 386 and should support all the hardware you can stick into a machine with an 80386 CPU. Unless, of course, you plan to put it on a network. I doubt that 4.x is up to date with respect to security patches. I don't know if they were all applied on 4.x, but I think at least the older ones are. 4.11 fell out of security support some while back, but http://www.freebsd.org/security/index.html only lists what's still in, not what fell out when. Free/ Net/ Open/ Dragon etc all derive from Bill Jollitz port of BSD to 386. Would be nice if we could still keep that first platform walking, even if speed can't be called running ;-) Maybe I'll get time to chase down all that came before http://svn.freebsd.org/viewvc/base?view=revisionrevision=137784 Other things added since then assume at least a 486. Not having cmpxchg is a bit of a killer. The umtx stuff used by libthr assumes it can do a cmpxchg in userland for example. One idea kicked around many years ago was catching the illegal instruction faults for userland and emulating cmpxchg, but that would be a good bit of work. FreeBSD now also makes liberal use of 'xadd' for reference counts (see refcount_*()) so you would need to support that on a 386 as well. There may be other places that I'm not aware of that have similar assumptions. FWIW, I would probably not be in favor of putting any patches into the tree if you do manage to get it all working. I suspect the userbase of FreeBSD/80386 is even smaller than FreeBSD/alpha or FreeBSD/sparc64 and 80386 support would add a lot of ugly #ifdef's for miniscule gain. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: genuine cpu I386_CPU kernel support
John Baldwin wrote: On Wednesday 23 September 2009 11:54:34 am Julian H. Stacey wrote: Rui Paulo wrote: On 22 Sep 2009, at 19:03, Nate Eldredge wrote: On Tue, 22 Sep 2009, John Baldwin wrote: My comment is to just use 4.x (seriously). A true 386 is going to be quite slow and the overhead of many things added that work well on newer processors is going to be very painful on a 386 (probably on a 486 as well). 4.x runs fine on a 386 and should support all the hardware you can stick into a machine with an 80386 CPU. Unless, of course, you plan to put it on a network. I doubt that 4.x is up to date with respect to security patches. I don't know if they were all applied on 4.x, but I think at least the older ones are. 4.11 fell out of security support some while back, but http://www.freebsd.org/security/index.html only lists what's still in, not what fell out when. Free/ Net/ Open/ Dragon etc all derive from Bill Jollitz port of BSD to 386. Would be nice if we could still keep that first platform walking, even if speed can't be called running ;-) Maybe I'll get time to chase down all that came before http://svn.freebsd.org/viewvc/base?view=revisionrevision=137784 Other things added since then assume at least a 486. Not having cmpxchg is a bit of a killer. I think a 386 can assume non-SMP in which case that can be simulated just fine :-) it also simplifies a lot of the other breakages.. #if (CPU == 80386) defined(SMP) #error can't have smp on a 386 #endif The umtx stuff used by libthr assumes it can do a cmpxchg in userland for example. One idea kicked around many years ago was catching the illegal instruction faults for userland and emulating cmpxchg, but that would be a good bit of work. FreeBSD now also makes liberal use of 'xadd' for reference counts (see refcount_*()) so you would need to support that on a 386 as well. There may be other places that I'm not aware of that have similar assumptions. FWIW, I would probably not be in favor of putting any patches into the tree if you do manage to get it all working. I suspect the userbase of FreeBSD/80386 is even smaller than FreeBSD/alpha or FreeBSD/sparc64 and 80386 support would add a lot of ugly #ifdef's for miniscule gain. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: genuine cpu I386_CPU kernel support
On Wednesday 23 September 2009 1:21:59 pm Julian Elischer wrote: John Baldwin wrote: On Wednesday 23 September 2009 11:54:34 am Julian H. Stacey wrote: Rui Paulo wrote: On 22 Sep 2009, at 19:03, Nate Eldredge wrote: On Tue, 22 Sep 2009, John Baldwin wrote: My comment is to just use 4.x (seriously). A true 386 is going to be quite slow and the overhead of many things added that work well on newer processors is going to be very painful on a 386 (probably on a 486 as well). 4.x runs fine on a 386 and should support all the hardware you can stick into a machine with an 80386 CPU. Unless, of course, you plan to put it on a network. I doubt that 4.x is up to date with respect to security patches. I don't know if they were all applied on 4.x, but I think at least the older ones are. 4.11 fell out of security support some while back, but http://www.freebsd.org/security/index.html only lists what's still in, not what fell out when. Free/ Net/ Open/ Dragon etc all derive from Bill Jollitz port of BSD to 386. Would be nice if we could still keep that first platform walking, even if speed can't be called running ;-) Maybe I'll get time to chase down all that came before http://svn.freebsd.org/viewvc/base?view=revisionrevision=137784 Other things added since then assume at least a 486. Not having cmpxchg is a bit of a killer. I think a 386 can assume non-SMP in which case that can be simulated just fine :-) it also simplifies a lot of the other breakages.. #if (CPU == 80386) defined(SMP) #error can't have smp on a 386 #endif No, it actually does not. The in-kernel version of cmpset for 386 was to disable interrupts while doing a cmp and jmp around a mov (even 386's have preemption, so you do have to disable interrupts). You can't do that in userland (cli is a privileged instruction), which probably mandates doing a cmpxchg emulator in the kernel for userland code. That and disabling interrupts is actually far less efficient than spl() for a UP 80386 machine. I suspect newer kernels will run slower on an 80386 than 4.x. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: genuine cpu I386_CPU kernel support
On Wed, 23 Sep 2009, John Baldwin wrote: On Wednesday 23 September 2009 1:21:59 pm Julian Elischer wrote: John Baldwin wrote: Other things added since then assume at least a 486. Not having cmpxchg is a bit of a killer. I think a 386 can assume non-SMP in which case that can be simulated just fine :-) it also simplifies a lot of the other breakages.. #if (CPU == 80386) defined(SMP) #error can't have smp on a 386 #endif No, it actually does not. The in-kernel version of cmpset for 386 was to disable interrupts while doing a cmp and jmp around a mov (even 386's have preemption, so you do have to disable interrupts). You can't do that in userland (cli is a privileged instruction), which probably mandates doing a cmpxchg emulator in the kernel for userland code. That and disabling interrupts is actually far less efficient than spl() for a UP 80386 machine. I suspect newer kernels will run slower on an 80386 than 4.x. Another issue that I know affected Linux is that the 386 would allow kernel code (CPL 0) to write to a page that was marked read-only. The 486 and later would generate a page fault. Linux takes advantage of the 486 behavior to avoid having to do explicit access checks when copying to user space, though AFAIK it checks the CPU at boot time to decide if this can be done. I haven't checked whether FreeBSD uses this feature, but it would be another thing to watch out for. -- Nate Eldredge n...@thatsmathematics.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Adding support for the Intel SS4000-E NAS aka the EM-7210
Hi, Sorry for the cross post but i didn't get any bites on arm@ so I am gonna try my luck here. I am trying to add support for the Intel SS4000-E/EM7210 to FreeBSD, I have copied all of the files for the EP80219 as this seems to be what the board is based on, and modified the interrupt assignment code. See the patch agains sys/arm here: http://www.tomjudge.com/tmp/em-7210-patch I am also having trouble with loading the kernel at the default location, (instructions from here: http://wiki.freebsd.org/FreeBSDAvila) as RedBoot reports that there is no memory at the load address. Currently when I try to load this kernel at the phys address using reboot and try to run the kernel I get nothing outputed on the console. I used the phys address from the addresses that the linux kernel is loaded into out of flash. (see output below) Could someone please give me some hints on what I am doing wrong and need to change? The board is currently supported by the Linux kernel (as the em7210.c) so I was hoping that adding support to FreeBSD would not be difficult. More information about the system can be found here: http://em7210.kwaak.net/ Thanks in advance for any help, Tom $ sudo cu -l cuau0 -s 115200 Password: Connected +No network interfaces found EM-7210 ver.T04 2005-12-12 (For ver.AA) == Executing boot script in 1.000 seconds - enter ^C to abort ^C RedBoot ^C RedBoot fis load rammode RedBoot go +Ethernet eth0: MAC address 00:0e:0c:b6:bf:1a IP: 10.9.9.1/255.255.255.0, Gateway: 10.9.9.1 Default server: 10.9.9.10, DNS server IP: 0.0.0.0 EM-7210 (RAM mode) 2005-12-22 == Executing boot script in 1.000 seconds - enter ^C to abort ^C RedBoot ^C RedBoot fis list Name FLASH addr Mem addrLength Entry point RedBoot 0xF000 0xF000 0x0004 0x RedBoot config0xF1FC 0xF1FC 0x1000 0x FIS directory 0xF1FE 0xF1FE 0x0002 0x rammode 0xF006 0x0020 0x0004 0x0020 log 0xF004 0xF004 0x0002 0x naskey0xF00A 0xF00A 0x0002 0x01008000 zImage0xF00C 0x01008000 0x0020 0x01008000 ramdisk.gz0xF02C 0x0180 0x0040 0x0180 vendor0xF06C 0xF06C 0x0188 0x0180 wmdata0xF1F4 0xF1F4 0x0008 0x0180 RedBoot ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: genuine cpu I386_CPU kernel support
On Wed, Sep 23, 2009 at 05:54:34PM +0200, Julian H. Stacey wrote: 4.11 fell out of security support some while back, but http://www.freebsd.org/security/index.html only lists what's still in, not what fell out when. Then see http://people.freebsd.org/~linimon/schedule/milestones.html. (Yes, I know the data for 7.2 and 8.0 are stale.) 4.11 support was extended again and again but ended 01/31/2007. Towards the end it was consuming a lot of people's time to support it, since everything newer had changed dramatically. Free/ Net/ Open/ Dragon etc all derive from Bill Jollitz port of BSD to 386. Would be nice if we could still keep that first platform walking, even if speed can't be called running ;-) The same comment applies. Everything has changed dramatically. Maybe I'll get time to chase down all that came before http://svn.freebsd.org/viewvc/base?view=revisionrevision=137784 I honestly can't see why you would want to waste your time like this, but it's yours to waste I suppose. (Even a notorious packrat like me has gotten rid of hardware from that era.) mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
USB Device identification in dmesg and usbconfig
Hi, I have been working on getting at least some support for the Function (F1-12) keys on my MS Natural 4000 keyboard. Here is the original PR on the subject: usb/116947. My patch can be found here: http://svn.tomjudge.com/freebsd/patches/ms-natural-4000/usb-natural4000.patch and I have submitted an update to the PR. When I reboot into the kernel the quirk is detected correctly and the function keys work. However the device does not seem to be correctly identified here is the dmesg output: ugen2.3: vendor 0x045e at usbus2 ukbd0: vendor 0x045e product 0x00db, class 0/0, rev 2.00/1.73, addr 3 on usbus2 kbd2 at ukbd0 uhid0: vendor 0x045e product 0x00db, class 0/0, rev 2.00/1.73, addr 3 on usbus2 Here is usbconfig list output: ugen2.3: product 0x00db vendor 0x045e at usbus2, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON How do I get the output to match other devices like this: ugen2.4: Microsoft at usbus2 ums0: Microsoft Microsoft Optical Mouse with Ti, class 0/0, rev 2.00/1.20, addr 4 on usbus2 ums0: 3 buttons and [XYZ] coordinates ID=17 Thanks Tom ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: USB Device identification in dmesg and usbconfig
On Wed, 23 Sep 2009 22:44:54 + Tom Judge t...@tomjudge.com wrote: Hi, I have been working on getting at least some support for the Function (F1-12) keys on my MS Natural 4000 keyboard. Here is the original PR on the subject: usb/116947. My patch can be found here: http://svn.tomjudge.com/freebsd/patches/ms-natural-4000/usb-natural4000.patch and I have submitted an update to the PR. When I reboot into the kernel the quirk is detected correctly and the function keys work. However the device does not seem to be correctly identified here is the dmesg output: ugen2.3: vendor 0x045e at usbus2 ukbd0: vendor 0x045e product 0x00db, class 0/0, rev 2.00/1.73, addr 3 on usbus2 kbd2 at ukbd0 uhid0: vendor 0x045e product 0x00db, class 0/0, rev 2.00/1.73, addr 3 on usbus2 Here is usbconfig list output: ugen2.3: product 0x00db vendor 0x045e at usbus2, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON How do I get the output to match other devices like this: ugen2.4: Microsoft at usbus2 ums0: Microsoft Microsoft Optical Mouse with Ti, class 0/0, rev 2.00/1.20, addr 4 on usbus2 ums0: 3 buttons and [XYZ] coordinates ID=17 I'm starting to suspect this is a bug in the USB code that Microsoft devices use. I've seen this on two PCs now, both on 7.x and 8.0-RC1; sometimes they'll identify properly by getting the strings out of the device (e.g. Microsoft 3-Button Mouse with IntelliEye(TM)) but most of the time I'll just see the generic device and product IDs. -- Bruce Cran ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
