? about kernel size..

John Clark jeclark2006 at aim.com
Tue Mar 8 23:23:32 UTC 2016


On Mar 8, 2016, at 3:14 PM, Ian Lepore <ian at freebsd.org> wrote:

> Jeez, really?  This thread is going to be hijacked to discuss the
> theoretical possiblity of running on 40 year old hardware?
> 
> Unbelievable.
> 
> — Ian

Some one trying to run something like FreeBSD on a non-MMU processor, is going … 40 years back in time(technically the 286 is a 35 or so year old design…)…

Demand the project has at least a serviceable MMU…

A few years ago, the boss got the big idea to use an 8051 based processor board for a system controller unit… ugh…
I started my career using the 8048 and the ‘graduated’ to the 8051… then moved to a different company to work on ‘real’ machines… PDP-11s…

In way the system controller was an not so pleasant walk down memory lane…

John Clark.


> 
> On Tue, 2016-03-08 at 15:09 -0800, John Clark via freebsd-embedded
> wrote:
>> Not to barge in to your discussion… but yes there were Unix variants
>> that worked on the 286. Xenix was one such OS. Xenix being
>> Microsoft’s idea of avoiding the Unix name…
>> 
>> Originally Xenix ran on PDP-11, and was ported to other machines that
>> have long passed into the oblivion of technological Hell.
>> 
>> As for ‘preemetive multitasking… of course one can run a preemptive
>> scheduler on almost any CPU that has a clock interrupt.
>> 
>> I wrote one for the 286 based on the kernel described in Douglas
>> Comer’s “Xinu” book.
>> 
>> Products with that hack where produced for about 8 years… in the
>> early-mid-80s. I wrote it such that it would run in a DOS box and
>> allow for machine control of various robotic systems for industrial
>> inspection machines.
>> 
>> In any case one can develop a multitasking kernel to run in a non-MMU
>> based system… just lends itself to crapping out on the least
>> provocation…
>> 
>> What an MMU provides is hardware ‘address translation’ such that the
>> application can run in an ‘virtual absolute’ addressing space,
>> have memory protection such that errant code can’t clobber other
>> tasks or the kernel, and also given appropriate devices,
>> have ‘swapping’ for larger than real memory applications.
>> 
>> The 286 ‘segment’ registers gave a bit of ‘translation’ capability in
>> that one could address relative to the segment registers, and so,
>> code and data could be place in available member and context switched
>> would update the segment registers.
>> 
>> The segment registers were a crappy way of accessing memory if one
>> had long linear arrays of data to process… such as image processing…
>> which happened to be the application of my work at the time…
>> 
>> And one could always implement an external MMU which was popular with
>> the Motorola M68K which was sort of the contemporary alternative to
>> the Intel x86 line.
>> 
>> John Clark.
>> 
>> On Mar 8, 2016, at 2:25 PM, Markus Hitter <mah at jump-ing.de> wrote:
>> 
>>> Am 08.03.2016 um 22:56 schrieb Brad Walker:
>>>> But, are you saying that no engineering has been done on this yet
>>>> OR no
>>>> amount of engineering could make it work?
>>> 
>>> If I recall correctly from some 25 years ago, memory address
>>> mapping
>>> (which is what a MMU does) is mandatory for preemtive multitasking.
>>> An
>>> i286 can't run a Unix-like OS either.
>>> 
>>> 
>>> In 2008 I tried to get FreeBSD down to its minimum, too. The
>>> success
>>> post is about all what's left today:
>>> 
>>> https://lists.freebsd.org/pipermail/freebsd-embedded/2008-October/0
>>> 00604.html
>>> 
>>> The task to get there is simple and straightforward, but time
>>> consuming:
>>> go step by step through the kernel configuration to disable
>>> whatever you
>>> can spare. Configure, build, try, repeat. If you need a small
>>> entire
>>> system, do the same for packages and every single file you copy
>>> into
>>> your system image.
>>> 
>>> 
>>> Markus
>>> 



More information about the freebsd-embedded mailing list