Malcolm Kay wrote:
On Fri, 27 May 2005 03:13 pm, Scott Long wrote:
Scott Long wrote:
Malcolm Kay wrote:
I have installed FreeBSD 5.4 RELEASE on a new machine,
Celeron + SATA drive, without and problems, include a
kernel rebuild to support a PCI serial card.
But now I wish to change the graphic, beastie, that appears
in the boot menu. I am certainly no expert or even acolyte
in forth programming but the job appears to be simple
enough -- just change the characters in the
'beastie' constructions and if we don't exceed the
available screen space all should be well!
Well what I got was a cycling reboot going back ech time to
the BIOS splash screen and advancing an apparently
negligable distance into the FBSD
boot sequence.
I had actually copied /boot/beastie.4th to
/boot/phoenix.4th, edited the copy and pointed
/boot/loader.rc at phoenix.4th instead of beastie.4th.
Recovery by booting from the distribution CD and entering
"Fixit" to change
the pointer back to beastie.4th.
Most variants on my original attempt ended up the same way,
but some crashed with a "directory full" message which
seems quite strange as my images have always been smaller
than the original 'beastie'.
Replacing the colourised version of my 'phoenix' with a
copy of the monochrome version worked.
At present I have a phoenix.4th file which works but does
not exhibit the full image. The differences to the original
beastie.4th file are shown here
with escape characters replaced by '{esc}' to limit mail
confusion.
With the line:
( 2dup at-xy ." {esc}[1m^ ^" 1+ )
uncommented the system goes back to an infinite boot loop.
This all seems very strange and unbelievable -- I must
surely be doing something very stupid. Does anyone have any
idea what that might be?
Seems to work for me with the commented lines fixed. Btw,
you by no doubt have noticed that it's somewhat inconvenient
to do 4th programming by modifying the boot scripts and then
praying that the reboot works. It's possible to do 90% of
the testing in userland, like I did when I wrote
beastie.4th.
Go to /sys/boot/ficl. Do 'make clean && make testmain'.
This will create a binary called 'testmain' either in the
'.' directory or in /usr/obj/usr/src/sys/boot/ficl. Copy
this binary to your home directory. Then copy screen.4th,
frames.4th, and beastie.4th from /boot to your home
directory. Next create a file called init.4th
containing the following:
: boot drop exit ;
: reboot drop exit ;
load screen.4th
load frames.4th
load beastie.4th
beastie-start
Then run it via './testmain init.4th'. The countdown timer
won't work and most of the keys naturally won't do what they
are supposed to do, but everything else in the menu should
work just as it would at boot. I tested your colorized
phoenix this way just now and it worked.
Oh, one thing I forgot to mention is that you'll need to
comment out the 'include' lines in beastie.4th since the
testmain environment doesn't implement those words.
I found I also needed to do something about
getsenv
setenv
and
unsetenv
The following at the start of init.4th worked:
----------------------------------------------
: getenv
2dup s" loader_color" compare 0= if
2drop
s" NO"
exit
then
2dup s" beastie_disable" compare 0= if
2drop
-1
exit
then
2drop
-1
exit
;
: setenv drop drop ;
: unsetenv drop ;
------------------------------------------------
Where the fourth line might also be
s" YES"
Symptoms suggested to me that I had a memory problem but
memtest86 ran without difficulty.
I also found much works differently at boot. Closer examination
shows that a number of things take different paths oftem using
BIOS or simplified code when called at boot -- I wonder whether
there is some anomaly in memory allocation when run from boot
that raises its ugly head on my machine.
I have achieved what I want by using a empirically derived
context but the underlying problem persists.
Anyway thanks for your input.
Malcolm
Look at rev 1.11 of /sys/boot/ficl/loader.c. I guess I never merged it
back to RELENG_5. Yes, not having a working getenv word makes some
things act different, but emulating the real functionality would require
simulating a lot more of the underlying loader environment, and that's
more work than I'm able to do right now.
Scott
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
