Blue swirl wrote:
>>1. Permissions in the config/scripts directory do not have execute "x" bit
>>set. I needed to do a
>>chmod 755 config/scripts/*
>They have x bit set in the distribution, maybe there was some error in
I am doing a very standard
which is the latest snapshot file from development page
gunzip -c openbios-devel.tar.gz | tar xvf -
Again, something that works out-of-the-box for 99.9% of all open source
I did it again just now, and still, there is no "x" bit set on these files.
Here is what I can see in the tar file
# gunzip -c openbios-devel.tar.gz | tar tvf - | grep scripts
drwxr-xr-x 0/0 0 May 7 04:49 2006 openbios-devel/config/scripts/
-rw-r--r-- 0/0 365 May 7 04:48 2006
-rw-r--r-- 0/0 245 Apr 27 01:08 2006
-rw-r--r-- 0/0 267 May 7 04:49 2006
No "x" bits getting into the snapshot at all.
I'm behind a corporate proxy and still haven't figured out svn yet. That's
why I used wget and more traditional means.
[mailto:email@example.com]On Behalf Of Blue Swirl
Sent: Saturday, 10 June 2006 7:57 AM
Subject: Re: [OpenBIOS] Numerous problems running Makefile for
You're right, with this method I don't see the x bits either. I'm using svn,
and then the bits are there.
Don't just search. Find. Check out the new MSN Search!
Free your System - May the Forth be with you
Taking the current snapshot from the OpenBIOS web site, I get a few problems
trying to build OpenBIOS for sparc32 as per the README file. I am using
Solaris 10 on Sparc64 (Enterprise 220R) with GCC 3.4.3
1. Permissions in the config/scripts directory do not have execute "x" bit
set. I needed to do a
chmod 755 config/scripts/*
to fix this. Otherwise I can't get past the first step in the README file
2. The Makefile uses $(PWD) which is not available under "sh" shell. To get
this to work right you apparently need bash shell. Without it, the line
@ln -s $(PWD)/include/$(ARCH) $(ODIR)/target/include/asm
for the "directories" target actually links to /include/$(ARCH) because
$(PWD) is an empty string. This of course causes the make process to fail
hopelessly because the links aren't established correctly. So, there should
be a note in the README warning about this, or else the Makefile needs to be
more tolerant. I've built a lot of open source software lately as I have
been configuring my Enterprise 220R box, and OpenBIOS is the only package so
far that has failed because the shell for make was sh. Maybe bash has
become the de-facto standard shell on Linux, but on Solaris it's sh by
default, and on MinGW, it is also sh.
3. Even with all that done, I am still getting problems, this time running
Building OpenBIOS on sparc64 for sparc32
Cleaning up... ok
Initializing build tree...ok.
Creating target Makefile...ok.
Creating config files...ok.
make: Entering directory `/software/source/openbios-devel'
gcc -O2 -g -Wall -W -DFCOMPILER -DBOOTSTRAP
BITWIDTH -USWAP_ENDIANNESS -Iinclude -Ikernel/include
-Iobj-sparc32/target/include -c -o obj-sparc32/host/kernel/bootstrap.o
In file included from include/openbios/sysinclude.h:5,
obj-sparc32/target/include/asm/types.h:18:20: endian.h: No such file or
make: *** [obj-sparc32/host/kernel/bootstrap.o] Error 1
make: Leaving directory `/software/source/openbios-devel'
In other words, now endian.h is missing.
The only place I could find it was
bash-3.00# find ./ -name endian.h
Now, according to mconfig.h, we have
/* Define to 1 if you have the <endian.h> header file. */
#define HAVE_ENDIAN_H 1
so it should be doing a
cp -p utils/ofclient/endian.h kernel/include
fixes the problem and I get a bit further
4. Now I get
gcc -Wa,-xarch=v8 -Wa,-32 -m32 -mcpu=supersparc $EXTRACFLAGS -Os -Wall -W
VE_BITWIDTH_EQUALS_HOST_BITWIDTH -USWAP_ENDIANNESS -fno-builtin -g
ecls -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations
-Wendif-labels -Wstrict-aliasing -Iinclude -Ikernel/include
t/include -c -o obj-sparc32/target/drivers/iommu.o drivers/iommu.c
drivers/iommu.c:15:21: asm/asi.h: No such file or directory
Again, another reference to an include file under
obj-sparc32/target/include/asm is missing.
The asi.h file can be found under arch/sparc32 directory. Maybe we need a
filesystem link added or else to copy asi.h or change the #include reference
5. Finally, GCC is picking up on lots of unused variables. Do we need to
review the build.log files and do a bit of spring cleaning ?
Anyhow, that's a long enough e-mail for now.
Comments please !
Senior Systems & Software Engineer
Otis Elevator Company Pty Ltd
50 Airds Rd Minto NSW 2566 AUSTRALIA
at your service
For further information on our products and services please visit us at
How about this version, does the memory allocation work?
I changed the build rules a bit so that it's easier to override the
FREE pop-up blocking with the new MSN Toolbar - get it now!
Can you please advise the "right way" to extract an ISO CD-ROM image from
the SunOS distribution media under Windows (not Solaris / Unix / Linux !)
I've extracted SunOS 4.1.4 installation CD using Nero to get track 1 (the
only track) but it isn't giving me the same boot-up sequence as those that
have been posted to the list.
Because I'm running QEMU on Win32, I don't seem to be able to get -nographic
to work (a problem opening stdio by QEMU), so perhaps this makes the
OpenBIOS console behave differently.
I changed the obp_dumb_memalloc code to use malloc and iommu/sbus code to do
real mapping, do they still work?
I also added links to chipset documentation and rearranged Sbus code.
Initial reaction from Qemu developers about switching to OpenBIOS was very
Express yourself instantly with MSN Messenger! Download today it's FREE!
>> It seems it wants something like
>> as the device
>device[sd(0,2,0):b] ("halt" to halt): cdrom
>boot (press RETURN to try default list): netbsd
>device[cdrom] ("halt" to halt):
>It prints no error, but does not do anything either.
It tried to boot from the cdrom but didn't find anything it liked there.
Or it failed to expand the alias. I seem to recall that Solaris etc use
the comma-separated args in the boot command rather than space-separated
args. Perhaps NetBSD is looking for something similar.
I think you're going to have to go grub around in the NetBSD code. :)
/__)_ _ _ _ Q: How many heterosexual males does it take to screw in a
/ (// (/(/ light bulb in San Francisco? A: Both of them.
>NetBSD booting from CD:
> [sparc] Booting file 'cdrom' without parameters.
> Loading a.out image...
> Loaded 8388615 bytes
> entry point is 0x4000
> Jumping to entry point...
> obmem:>> NetBSD/sparc Secondary Boot, Revision 1.15
> >> (builds(a)b3.netbsd.org, Mon Dec 19 03:43:03 UTC 2005)
> Booting diag
> Cannot load diag: error=20
> device[sd(0,2,0):b] ("halt" to halt):
Interesting - it seems to be picking up the diag-file setting from OF
- the name "diag" - perhaps because "diag-switch?" is set to true. That
implies that the loader is making calls into OF and getting at least
some stuff it likes.
In any case, it's now at the BSD device prompt, which is also good. You
should be able to type in a BSD-style boot-spec here to disk, partition,
and name of the kernel here. Unfortunately Sparc-to-BSD device mapping
is a bit funky so you may have to grep through the BSD docs for details.
If you typed in "bsd" at the above prompt, it should try to load the
file named "bsd" from the default device listed above in square
>NetBSD kernel directly:
> [sparc] Kernel already loaded
> OBP version 3, revision 2.25 (plugin rev 2)
> Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
> The NetBSD Foundation, Inc. All rights reserved.
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California. All rights reserved.
> NetBSD 3.0 (GENERIC) #0: Mon Dec 19 04:01:27 UTC 2005
> total memory = 127 MB
> avail memory = 120 MB
> data fault: pc=0xf02a4f3c addr=0x7ff000
> panic: kernel fault
As a guess it's trying to print or create the "bootpath" and hit a bad
or uninitialized pointer - 0x7ff000. It got the total and available
memory, so at least that's good. Pity it halted instead of dropping
into the BSD debugger - you could get a stack-trace then.
It may be trying to get args from the OF "boot" command, which should
pass args to the loaded image. Perhaps it doesn't have any args, or
perhaps they're bogus?
/__)_ _ _ _ "Grub first, then ethics." -- Bertolt Brecht
/ (// (/(/
>Can someone just give me a quick overview of the "right way" to start up
>QEMU so that it will load the OpenBIOS firmware instead of PROLL, and how
>point QEMU to my Solaris installation CD image file.
Just rename openbios-builtin.elf.nostrip to proll.elf. I don't know if
OpenBIOS can be compiled in Solaris, please report if you try.
>Do I need any hacks / patches to QEMU to use OpenBIOS instead of PROLL ?
The attached patch to CVS version of Qemu fixes several critical problems in
>What debugging switches should I enable with QEMU to help me figure out why
>things aren't working when trying to boot the SunOS 4.1.4 (Solaris 1.1.2)
>installation CD ?
>Is there a "best way" to build OpenBIOS to ensure maximum useful debugging
>information is produced ?
I don't think Qemu debugging switches are that helpful, but enabling
CONFIG_DEBUG_OBP in OpenBIOS shows the OBP calls.
>If I'm repeating a whole lot of old questions, is there a FAQ for the QEMU
>OpenBIOS (Sparc32) combination that someone can point me to ?
Well, the combination didn't even exist a couple of months ago...
FREE pop-up blocking with the new MSN Toolbar - get it now!