? 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