From owner-freebsd-stable@FreeBSD.ORG Sat Jun 4 06:35:08 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B60D216A41C for ; Sat, 4 Jun 2005 06:35:08 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C13C43D48 for ; Sat, 4 Jun 2005 06:35:07 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j546fbAo037722; Sat, 4 Jun 2005 00:41:37 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42A14B27.5020207@samsco.org> Date: Sat, 04 Jun 2005 00:33:11 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Malcolm Kay References: <200505271427.13508.malcolm.kay@internode.on.net> <4296B306.9080300@samsco.org> <4296B39D.9030107@samsco.org> <200506041518.16541.malcolm.kay@internode.on.net> In-Reply-To: <200506041518.16541.malcolm.kay@internode.on.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-stable@freebsd.org Subject: Re: Context sensitivity in beastie.4th? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2005 06:35:08 -0000 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