DragonFly boot2 - moved out of commits thread

[Oliver Fromme]

lybsd.org>
User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/7.1-PRERELEASE (i386))
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Date: 06 Mar 2009 18:28:10 GMT
Lines: 146
NNTP-Posting-Host: 212.17.241.231
X-Trace: 1236364090 crater_reader.dragonflybsd.org 880 212.17.241.231
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:13534

Bill Hacker wrote:
 > Oliver Fromme wrote:
 > > Bill Hacker wrote:
 > > > Oliver Fromme wrote:
 > > > > http://wiki.freebsd.org/OliverFromme/BootLoader
 > > > > 
 > > > > I think DragonFly should be able to port it over without
 > > > > difficulty.  Last time I looked, DF's boot loader was
 > > > > still pretty much the same as FreeBSD's.
 > > > 
 > > > Good start.
 > > > 
 > > > And 'compliments'  on not going off and coding it in flavor-of-the month 
 > > > language....
 > > 
 > > I don't understand that remark.  The boot loader is written
 > > in C, so I don't have much choice other than to code the
 > > graphics support in C, too.  I'm certainly not going to
 > > port the whole boot loader to a different language.  There
 > > aren't many languages anyway that are suitable for such a
 > > rather low-level piece of software.
 > 
 > Once upon a time ... soembody was going to do a bootloader in (IIRC) Lua.
 > 
 > Nice enough language - but why add to the complexity and dependencies 
 > when not much *else* is done in the core - or anywhere else - in it.

I don't like Lua, but it is better than Forth.  In fact,
a *lot* better.  If the boot loader had embedded Lua
instead of FICL, I would be much happier now.

In terms of performance, size, dependencies and complexity
of integrating it into a C program (such as the loader),
Lua and FICL are on the same level.  But when Mike Smith
started to look for an embeddable language in 1997/98,
Lua was not an option, for several reasons:

 - At that time, Lua was almost unknown in the UNIX world.
 - Lua is not a standard.  Forth is.
 - At that time, Lua seemed somewhat immature because it
   underwent substantial changes between releases.  On the
   other hand, FICL was quite stable, with only subtle
   changes between versions.
 - Prior to Lua 5.0, the Lua license was legally unclear.
   (Today it has an MIT license, which is good.)

And of course, there were precedents:  Forth was used in
the Open Firmware (called "OpenBoot" when invented by Sun).

The reason why Forth was so popular for boot loaders is
simple:  The core of a Forth interpreter is ridiculously
simple and small.  When Sun introduced OpenBoot in 1988,
it fit into an 8 KByte ROM.



 > >  > (though it is a travesty what FICL'ization has done to the sheer 
 > >  > elegance of 'real' Forth... but that wasn't your doing...)
 > > 
 > > I don't like Forth.  But some people decided that it should
 > > be embedded in the boot loader, and I can't change that, so
 > > I need to deal with it.
 > 
 > Actually one CAN change it. The CPU won't care.

Of course you _can_ change it, technically.  The question
is whether such a change would be accepted by the people
who feel responsible for the boot loader.  Mike Smith
isn't an active BSD devloper anymore, AFAIK, but there
are others who think that there's no sufficiently good
reason to replace FICL.

 > But you might have liked it better if it hadn't been bastardized by 
 > crossbreeding it with C.

What exactly do you mean by that?  You can't write a boot
loader in 100% Forth, if you mean that.  You will always
need write some code for low-level things (in FreeBSD and
DragonFly BSD, these are in the BTX library), some code
for doing I/O, memory allocation and so on (this is in
libstand), and some initialization stuff that interfaces
the loader with the earlier boot stages (this part is in
sys/boot/i386/loader/*).  All of that is not part of FICL,
so you can't implement it in Forth.

 > > If you create a theme for DragonFly BSD, I'd be happy to
 > > add it to my collection.
 > 
 > I've made several attemps to modify the published DragonFly logo, but no 
 > joy so far.
 > 
 > The 4-bit color-depth is now per your earlier guidance, but the tools I 
 > am using are doing something ELSE that is unwanted, so now that it 
 > actually loads, I'm getting something that looks like fabric scraps from 
 > me Mum's cleaning-rag bag.

I don't know what tools you use, but I strongly recommend
you use ppmtopcx (from the netpbm tools) to generate the
PCX file.  It will print the number of colors used, so you
can easily verify that it's not more than 16 colors.

My code will accept PCX files produced by ppmtopcx if
they have a maximum of 16 colors.

 > A menu could make a good deal of that much easier to use than what the 
 > loader prompt supplies.
 > 
 > But the underlying tools need work also. AFAICS, they are no longer up 
 > to the needs of recognizing modern hardware as well as they might do.

The boot loader does not have its own hardware drivers, so
it depends on the BIOS for accessing devices.  For example,
if a disk controller is not recognized by your BIOS, then
you can't boot from it.  The same goes for USB keyboards
and other kinds of hardware that you might want to use in
the loader.

 > Meanwhile - perhaps you could pick up the DragonFlyBSD logo off the site 
 > and see about getting it slimmed-down to a 4-bit .pcx that works?

I'll have a look at it if time permits.  No promise though.

 > Or perhaps its creator could do so, given the .pcx parameters?

As I wrote above, the current maximum is 640 x 480 at 4 bit
depth (i.e. 16 colors).  I used ppmtopcx during development
and and testing, so I'm pretty sure that my code will eat
any PCX file created by ppmtopcx, modulo the above maximum.

By the way, GIMP always saves PCX files with 8 bit depth,
even if it uses less than 256 colors.  So, when using GIMP,
save it as PPM first, then use ppmtopcx to convert to PCX.
ppmtopcx is pretty smart:  It reduces the bit depth to the
smallest value required to store the number of colors that
are actually used in the image.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd