On Sun, 4 May 2003, Manuel Kasper wrote:
> > Hi, is the AMD-pcnet driver (pcn*) included in the m0n0wall kernel?
> > I'd like to run m0n0wall in a vmware environment, and vmware emulates
> > the AMD cards. Also, is m0n0wall compiled for 486 only? (options I486_CPU)
> > or will it run on emulated 586/686?
> The kernel that ships with m0n0wall is entirely targeted at net45xx' - no
> pcn driver, i486 only (it will probably panic if run on 586/686). If you
> want to run m0n0wall on another system, you'll have to compile a custom
Indeed. I gave it a try under Virtual PC on the Mac, and it panicked with
"CPU class not configured". On the one hand, I doubt that it would cost
much to include the 586/686 support, but on the other hand there's the
question of how worthwhile it is for the normal build. In general, it
1) User-space code is not a problem, since the 586/686 are fully
upward-compatible with the 486 in user mode.
2) Kernel C code is also not an issue, since the only 486 instructions
removed in the 586/686 are TLB-related and thus wouldn't come from a
3) Including multiple CPU choices probably has no effect on speed, since I
expect that the differences are accomodated by some one-time setup at boot
4) Thus, the only real cost is in making the kernel a bit larger, provided
that the build procedure can still target the 486 for the compiled code
while including the 586/686 support.
Speaking of making the kernel larger, if the MATH_EMULATE option really
does what it says, then I don't see why it's needed on the 4501, since the
SC520 has an FPU. I suspect the FPU emulation costs quite a bit more
space than 586/686 support would, and I believe the only 486+ processor
that needs it is the 486SX.
BTW, does FreeBSD have deficient FPU emulation? GCC has an option to
avoid FPU trig instructions for cases where they're not supported by the
emulation, and that option claims to be enabled by default for FreeBSD.
Does VMWare have the option to run the emulated RTC on UTC? If not, the
timezone would need to be configured correctly even if it ran. The file
/etc/wall_cmos_clock is already present in m0n0wall, though I think this
is a mistake since I expect most people would set the 4501's RTC to UTC,
and with /etc/wall_cmos_clock present, the time would be screwed up with a
non-UTC /etc/localtime file.
I think proper timezone handling is desirable, and that comes in three
1) Allowing for a non-default timezone.
2) Maintaining the timezone config across firmware updates.
3) Having a way to set the timezone in the GUI and/or console menu.
Because it's desirable to establish the timezone as early as possible in
the boot process, it needs to be separate from config.xml. I tweaked it
for #1 and #2, but not #3 (which I handled by installing a /conf/localtime
manually). I'll email the changes.
> BTW, if you want to run it under VMware, you should probably be looking
> for the lnc driver instead...
I did something simlar with GRUB, where I included the "tulip" driver as
well as the "natsemi" driver so I could test it under VPC as well as on
the real 4501.