Re: sparc64 boot issue on qemu
Jason A. Donenfeld wrote: > Wow, that's magic, and works perfectly: > https://data.zx2c4.com/openbsd-qemu-sparc64-pretty-vga-with-serif-font.png > Pretty font too. > > It sounds like the issue we're facing here is that the addr function > is missing from QEMU's firmware? Would it be quasi interesting to > remove use of it from OpenBSD? Or should we take this over to QEMU > instead and get it implemented? They should impliment emulation of the hardware properly. Or maybe relabel their work as "qemu sparc64-best-bullshit-we-got"
Re: sparc64 boot issue on qemu
On Mon, Jun 1, 2020 at 2:37 PM Mark Cave-Ayland wrote: > Oh wow it looks great! Totally. I was super impressed as well. > I also have commit access to OpenBIOS so I can tidy that up > and get it posted over on the OpenBIOS mailing list. Probably the main thing > is to > figure out what to do if the specified word doesn't exist. I'll also try and > find a > few mins to fire up my Mac Mini to see if it exists there to work out if it > should be > restricted to SPARC only. > > Note that I did my last merge a few days ago so it will be a little while > before it > hits QEMU git master, but I can certainly get it added in time for the next > official > QEMU release. Oh, whoops, I just sent it to qemu-devel. Feel free to discard that and commit it to the proper place. Given your forth chops, it makes sense that you're in fact an OpenBIOS committer. :) Jason
Re: sparc64 boot issue on qemu
On 01/06/2020 21:08, Jason A. Donenfeld wrote:
> On Mon, Jun 1, 2020 at 1:54 PM Mark Cave-Ayland
> wrote:
>>
>> On 01/06/2020 08:23, Jason A. Donenfeld wrote:
>>
>>> On Sun, May 31, 2020 at 3:18 AM Mark Cave-Ayland
>>> wrote:
AFAICT the problem here is the Forth being used at
https://github.com/openbsd/src/blob/master/sys/arch/sparc64/dev/fb.c#L511:
since the
addr word isn't part of the IEEE-1275 specification, it is currently
unimplemented in
OpenBIOS.
>>>
>>> Actually, it looks to me like after this line runs:
>>>
>>> OF_interpret("stdout @ is my-self "
>>> "addr char-height addr char-width "
>>> "addr window-top addr window-left",
>>> 4, &windowleft, &windowtop, &romwidth, &romheight);
>>>
>>> windowleft and windowtop contain legit addresses, but romwidth and
>>> romheight have garbage in them. It might be possible to chalk this up
>>> to bogus QEMU firmware, in which case, whatever.
>>
>> Sadly I think that's more due to luck than anything else. If you have a
>> working boot
>> loader then can you try booting qemu-system-sparc64 with -prom-env
>> 'auto-boot?=false'
>> and then entering the following definition of addr at the Forth prompt:
>>
>> : addr
>> parse-word $find if
>> cell +
>> then
>> ;
>>
>> followed by:
>>
>> boot
>>
>> That should give you a definition of addr that will return the address of a
>> value
>> type in Forth.
>
> Wow, that's magic, and works perfectly:
> https://data.zx2c4.com/openbsd-qemu-sparc64-pretty-vga-with-serif-font.png
> Pretty font too.
>
> It sounds like the issue we're facing here is that the addr function
> is missing from QEMU's firmware? Would it be quasi interesting to
> remove use of it from OpenBSD? Or should we take this over to QEMU
> instead and get it implemented?
Oh wow it looks great! I also have commit access to OpenBIOS so I can tidy that
up
and get it posted over on the OpenBIOS mailing list. Probably the main thing is
to
figure out what to do if the specified word doesn't exist. I'll also try and
find a
few mins to fire up my Mac Mini to see if it exists there to work out if it
should be
restricted to SPARC only.
Note that I did my last merge a few days ago so it will be a little while
before it
hits QEMU git master, but I can certainly get it added in time for the next
official
QEMU release.
ATB,
Mark.
Re: sparc64 boot issue on qemu
On Mon, Jun 1, 2020 at 2:08 PM Jason A. Donenfeld wrote:
>
> Hi Mark,
>
> On Mon, Jun 1, 2020 at 1:54 PM Mark Cave-Ayland
> wrote:
> >
> > On 01/06/2020 08:23, Jason A. Donenfeld wrote:
> >
> > > On Sun, May 31, 2020 at 3:18 AM Mark Cave-Ayland
> > > wrote:
> > >>
> > >> AFAICT the problem here is the Forth being used at
> > >> https://github.com/openbsd/src/blob/master/sys/arch/sparc64/dev/fb.c#L511:
> > >> since the
> > >> addr word isn't part of the IEEE-1275 specification, it is currently
> > >> unimplemented in
> > >> OpenBIOS.
> > >
> > > Actually, it looks to me like after this line runs:
> > >
> > > OF_interpret("stdout @ is my-self "
> > > "addr char-height addr char-width "
> > > "addr window-top addr window-left",
> > > 4, &windowleft, &windowtop, &romwidth, &romheight);
> > >
> > > windowleft and windowtop contain legit addresses, but romwidth and
> > > romheight have garbage in them. It might be possible to chalk this up
> > > to bogus QEMU firmware, in which case, whatever.
> >
> > Sadly I think that's more due to luck than anything else. If you have a
> > working boot
> > loader then can you try booting qemu-system-sparc64 with -prom-env
> > 'auto-boot?=false'
> > and then entering the following definition of addr at the Forth prompt:
> >
> > : addr
> > parse-word $find if
> > cell +
> > then
> > ;
> >
> > followed by:
> >
> > boot
> >
> > That should give you a definition of addr that will return the address of a
> > value
> > type in Forth.
>
> Wow, that's magic, and works perfectly:
> https://data.zx2c4.com/openbsd-qemu-sparc64-pretty-vga-with-serif-font.png
> Pretty font too.
>
> It sounds like the issue we're facing here is that the addr function
> is missing from QEMU's firmware? Would it be quasi interesting to
> remove use of it from OpenBSD? Or should we take this over to QEMU
> instead and get it implemented?
I just sent a patch up to qemu-devel. We'll see what they think. You
should be CC'd on it.
https://lore.kernel.org/qemu-devel/20200601203143.93424-1-ja...@zx2c4.com/
Last nit would be figuring out how to prevent it from prompting me for
"root device: ", "swap device: ", but I'm guessing that's just some
prom variable or partition label I need to fiddle with, rather than a
real bug worthy of this list.
Jason
Re: sparc64 boot issue on qemu
Hi Mark,
On Mon, Jun 1, 2020 at 1:54 PM Mark Cave-Ayland
wrote:
>
> On 01/06/2020 08:23, Jason A. Donenfeld wrote:
>
> > On Sun, May 31, 2020 at 3:18 AM Mark Cave-Ayland
> > wrote:
> >>
> >> AFAICT the problem here is the Forth being used at
> >> https://github.com/openbsd/src/blob/master/sys/arch/sparc64/dev/fb.c#L511:
> >> since the
> >> addr word isn't part of the IEEE-1275 specification, it is currently
> >> unimplemented in
> >> OpenBIOS.
> >
> > Actually, it looks to me like after this line runs:
> >
> > OF_interpret("stdout @ is my-self "
> > "addr char-height addr char-width "
> > "addr window-top addr window-left",
> > 4, &windowleft, &windowtop, &romwidth, &romheight);
> >
> > windowleft and windowtop contain legit addresses, but romwidth and
> > romheight have garbage in them. It might be possible to chalk this up
> > to bogus QEMU firmware, in which case, whatever.
>
> Sadly I think that's more due to luck than anything else. If you have a
> working boot
> loader then can you try booting qemu-system-sparc64 with -prom-env
> 'auto-boot?=false'
> and then entering the following definition of addr at the Forth prompt:
>
> : addr
> parse-word $find if
> cell +
> then
> ;
>
> followed by:
>
> boot
>
> That should give you a definition of addr that will return the address of a
> value
> type in Forth.
Wow, that's magic, and works perfectly:
https://data.zx2c4.com/openbsd-qemu-sparc64-pretty-vga-with-serif-font.png
Pretty font too.
It sounds like the issue we're facing here is that the addr function
is missing from QEMU's firmware? Would it be quasi interesting to
remove use of it from OpenBSD? Or should we take this over to QEMU
instead and get it implemented?
Jason
Re: sparc64 boot issue on qemu
On 01/06/2020 08:23, Jason A. Donenfeld wrote:
> On Sun, May 31, 2020 at 3:18 AM Mark Cave-Ayland
> wrote:
>>
>> AFAICT the problem here is the Forth being used at
>> https://github.com/openbsd/src/blob/master/sys/arch/sparc64/dev/fb.c#L511:
>> since the
>> addr word isn't part of the IEEE-1275 specification, it is currently
>> unimplemented in
>> OpenBIOS.
>
> Actually, it looks to me like after this line runs:
>
> OF_interpret("stdout @ is my-self "
> "addr char-height addr char-width "
> "addr window-top addr window-left",
> 4, &windowleft, &windowtop, &romwidth, &romheight);
>
> windowleft and windowtop contain legit addresses, but romwidth and
> romheight have garbage in them. It might be possible to chalk this up
> to bogus QEMU firmware, in which case, whatever.
Sadly I think that's more due to luck than anything else. If you have a working
boot
loader then can you try booting qemu-system-sparc64 with -prom-env
'auto-boot?=false'
and then entering the following definition of addr at the Forth prompt:
: addr
parse-word $find if
cell +
then
;
followed by:
boot
That should give you a definition of addr that will return the address of a
value
type in Forth.
ATB,
Mark.
Re: sparc64 boot issue on qemu
On Sun, May 31, 2020 at 7:22 AM Otto Moerbeek wrote: > Thanks, the following works indeed. > > -Otto > > Index: bootblk.fth > === > RCS file: /cvs/src/sys/arch/sparc64/stand/bootblk/bootblk.fth,v > retrieving revision 1.9 > diff -u -p -r1.9 bootblk.fth > --- bootblk.fth 2 Apr 2020 06:06:22 - 1.9 > +++ bootblk.fth 31 May 2020 13:17:25 - > @@ -716,7 +716,8 @@ create cur-blockno -1 l, -1 l, \ Curren > 2drop > ; > > -" load-base " evaluate constant loader-base > +\\ Do not overwrite bootblocks > +" load-base " evaluate 2000 + constant loader-base > > : load-file-signon ( load-file len boot-path len -- load-file len boot-path > len ) > ." Loading file" space 2over type cr ." from device" space 2dup type cr I can confirm that this enabled -current to boot now perfectly, so in case it helps: OK zx2c4@
Re: sparc64 boot issue on qemu
On Sun, May 31, 2020 at 3:18 AM Mark Cave-Ayland
wrote:
>
> AFAICT the problem here is the Forth being used at
> https://github.com/openbsd/src/blob/master/sys/arch/sparc64/dev/fb.c#L511:
> since the
> addr word isn't part of the IEEE-1275 specification, it is currently
> unimplemented in
> OpenBIOS.
Actually, it looks to me like after this line runs:
OF_interpret("stdout @ is my-self "
"addr char-height addr char-width "
"addr window-top addr window-left",
4, &windowleft, &windowtop, &romwidth, &romheight);
windowleft and windowtop contain legit addresses, but romwidth and
romheight have garbage in them. It might be possible to chalk this up
to bogus QEMU firmware, in which case, whatever.
Jason
Re: sparc64 boot issue on qemu
Mark Cave-Ayland wrote: > On 31/05/2020 15:58, Theo de Raadt wrote: > > >> AFAICT the problem here is the Forth being used at > >> https://github.com/openbsd/src/blob/master/sys/arch/sparc64/dev/fb.c#L511: > >> since the > >> addr word isn't part of the IEEE-1275 specification, it is currently > >> unimplemented in > >> OpenBIOS. > >> > >> Why is addr needed here? Does the fb.c driver try and change these values > >> rather than > >> just read them? > > > > Why does that matter? > > > > sparc64 isn't a IEEE-1275 openfirmware. > > > > It is a Sun openfirmware, meaning it is more than the vague > > specification. An emulation must be able to emulate THE REAL HARDWARE. > > > > This should work. > > Well there are plenty of SUN-ims already included in OpenBIOS to enable > Solaris to > boot as far it does; I'm not against them, I was just commenting that this > was the > reason why it is currently unimplemented. I still think this is conceptually backwards. IEEE-1275 is the bastard step-child, it is a sub-set of what OpenFirmware actually is and was. These aren't minor extentions. They are fundamentals which started on 32-bit sparc and carried forward into 64-bit sparc. > A simple addr implementation for Forth values should be fairly easy to put > together. > Since I don't have access to any Sun hardware, can someone confirm the > semantics of > the addr word for me? In particular what does it return for: > > - Values (presumably this is a pointer to a 64-bit value?) On sparc64, cell_t is 64 bit, so that seems true. > - Defers (does it return a pointer to the deferred word?) > - Words (is it the same as the ' word?) It seems to only be used for values. Can't speak to the rest. Did something weird happen where other 32 architectures heading into 64 bit territory (powerpc? arm?) decided to keep cell_t as 32-bit when when transitioning to 64-bit? That's a pretty poisonous situation. I guess the answer is to assume those are fully 32-bit OFW, but clearly there are purely 64-bit OFW 'in the wild'. It seems ridiculously easy to fall into the trap of sustaining legacy, and not keeping architecture clean.
Re: sparc64 boot issue on qemu
On 31/05/2020 15:58, Theo de Raadt wrote: >> AFAICT the problem here is the Forth being used at >> https://github.com/openbsd/src/blob/master/sys/arch/sparc64/dev/fb.c#L511: >> since the >> addr word isn't part of the IEEE-1275 specification, it is currently >> unimplemented in >> OpenBIOS. >> >> Why is addr needed here? Does the fb.c driver try and change these values >> rather than >> just read them? > > Why does that matter? > > sparc64 isn't a IEEE-1275 openfirmware. > > It is a Sun openfirmware, meaning it is more than the vague > specification. An emulation must be able to emulate THE REAL HARDWARE. > > This should work. Well there are plenty of SUN-ims already included in OpenBIOS to enable Solaris to boot as far it does; I'm not against them, I was just commenting that this was the reason why it is currently unimplemented. > For another 64-bit cell_t usage see dev/prtc.c. > > For another "addr" usage, see romgetcursoraddr() A simple addr implementation for Forth values should be fairly easy to put together. Since I don't have access to any Sun hardware, can someone confirm the semantics of the addr word for me? In particular what does it return for: - Values (presumably this is a pointer to a 64-bit value?) - Defers (does it return a pointer to the deferred word?) - Words (is it the same as the ' word?) ATB, Mark.
Re: sparc64 boot issue on qemu
Mark Cave-Ayland wrote:
> On 30/05/2020 00:19, Jason A. Donenfeld wrote:
>
> > Note that you need to run this with `-nographic`, because the kernel
> > crashes when trying to use vgafb on sparc64/qemu. I've witnessed two
> > varieties crashes:
> >
> > - https://data.zx2c4.com/openbsd-6.7-sparc64-vga-panic-miniroot67.png
> > This happens when booting up miniroot67.fs
> >
> > -
> > https://data.zx2c4.com/openbsd-6.7-sparc64-vga-panic-after-installation.png
> > This happens after installation openbsd onto disk properly, and then
> > booting up into it.
> >
> > Passing `-nographic` prevents these from happening, since vgafb doesn't
> > bind to anything.
> >
> > I don't have a bsd.gdb in order to addr2line this, but if the miniroot
> > panic is related to the normal panic, and we then assume alignment
> > issues in fb_get_console_metrics, then I wonder if the below patch would
> > make a difference. On the other hand, a "data access fault" makes it
> > seem more likely that OF_interpret is just getting bogus addresses from
> > buggy qemu firmware.
> >
> > I probably have another two hours to go in waiting for this thing to
> > build...
> >
> > Jason
> >
> > --- a/sys/arch/sparc64/dev/fb.c
> > +++ b/sys/arch/sparc64/dev/fb.c
> > @@ -507,6 +507,7 @@ int
> > fb_get_console_metrics(int *fontwidth, int *fontheight, int *wtop, int
> > *wleft)
> > {
> > cell_t romheight, romwidth, windowtop, windowleft;
> > + uint64_t romheight_64, romwidth_64, windowtop_64, windowleft_64;
> >
> > /*
> > * Get the PROM font metrics and address
> > @@ -520,10 +521,15 @@ fb_get_console_metrics(int *fontwidth, int
> > *fontheight, int *wtop, int *wleft)
> > windowtop == 0 || windowleft == 0)
> > return (1);
> >
> > - *fontwidth = (int)*(uint64_t *)romwidth;
> > - *fontheight = (int)*(uint64_t *)romheight;
> > - *wtop = (int)*(uint64_t *)windowtop;
> > - *wleft = (int)*(uint64_t *)windowleft;
> > + memcpy(&romheight_64, (void *)romheight, sizeof(romheight_64));
> > + memcpy(&romwidth_64, (void *)romwidth, sizeof(romwidth_64));
> > + memcpy(&windowtop_64, (void *)windowtop, sizeof(windowtop_64));
> > + memcpy(&windowleft_64, (void *)windowleft, sizeof(windowleft_64));
> > +
> > + *fontwidth = (int)romwidth_64;
> > + *fontheight = (int)romheight_64;
> > + *wtop = (int)windowtop_64;
> > + *wleft = (int)windowleft_64;
> >
> > return (0);
> > }
>
> AFAICT the problem here is the Forth being used at
> https://github.com/openbsd/src/blob/master/sys/arch/sparc64/dev/fb.c#L511:
> since the
> addr word isn't part of the IEEE-1275 specification, it is currently
> unimplemented in
> OpenBIOS.
>
> Why is addr needed here? Does the fb.c driver try and change these values
> rather than
> just read them?
Why does that matter?
sparc64 isn't a IEEE-1275 openfirmware.
It is a Sun openfirmware, meaning it is more than the vague
specification. An emulation must be able to emulate THE REAL HARDWARE.
This should work.
For another 64-bit cell_t usage see dev/prtc.c.
For another "addr" usage, see romgetcursoraddr()
Re: sparc64 boot issue on qemu
On Sun, May 31, 2020 at 03:22:45PM +0200, Otto Moerbeek wrote:
> On Sun, May 31, 2020 at 09:49:34AM +0100, Mark Cave-Ayland wrote:
> > Thanks for the test case which enables me to reproduce the issue. With
> > ?fcode-verbose
> > enabled you see this at the end of the FCode execution:
FWIW, on latest OpenBoot on machines such as the T4-2 there exists no
other variable but fcode-debug?.
> > Now that 0x8a is completely wrong since according to
> > https://github.com/openbsd/src/blob/master/sys/arch/sparc64/stand/bootblk/bootblk.fth
> > the last instruction should be exit which is 0x33.
> >
> > Since the FCode itself is located at load-base (0x4000) it looks to me from
> > the above
> > debug that you're loading ofwboot at the same address, overwriting the
> > FCode. Once
> > do-boot has finished executing, the FCode interpreter returns to execute
> > the exit
> > word which has now been overwritten: so instead of returning to the updated
> > client
> > context via exit to execute ofwboot, it executes expect which asks for
> > input from the
> > keyboard and then crashes because the stack is incorrect.
> >
> > My recommendation would be to load ofwboot at 0x6000 instead of 0x4000
> > which I
> > believe will fix the issue. It's interesting you mention that this works on
> > real
> > hardware, since it doesn't agree with my reading of the IEEE-1275
> > specification so
> > you're certainly relying on some undocumented behaviour here.
Neither Forth nor boot blocks are my area of good expertise, but your
analysis reads fine to me.
> Thanks, the following works indeed.
I threw the diff (with minor crank) onto a guest domain on my T4-2 box
that I'm currently using for CURRENT ofwboot testing and it continues to
work just fine:
{0} ok setenv fcode-debug? true
fcode-debug? = true
{0} ok boot -V
NOTICE: Entering OpenBoot.
NOTICE: Fetching Guest MD from HV.
NOTICE: Starting additional cpus.
NOTICE: Initializing LDC services.
NOTICE: Probing PCI devices.
NOTICE: Finished PCI probing.
SPARC T4-2, No Keyboard
Copyright (c) 1998, 2018, Oracle and/or its affiliates. All rights
reserved.
OpenBoot 4.38.16, 8. GB memory available, Serial #xxx.
Ethernet address xxx, Host ID: xxx.
Boot device: /virtual-devices@100/channel-devices@200/disk@0 File and
args: -V
OpenBSD IEEE 1275 Bootblock 2.1
Booting from device /virtual-devices@100/channel-devices@200/disk@0
Try superblock read
FFS v2
ufs-open complete
.Looking for ofwboot in directory...
.
..
home
tmp
usr
var
bsd
sys
bsd.rd
altroot
bin
dev
etc
mnt
root
sbin
.cshrc
.profile
ofwboot
Found it
.Loading 1a398 bytes of file...
Copying 4000 bytes to 6000
Copying 4000 bytes to a000
Copying 4000 bytes to e000
Copying 4000 bytes to 12000
Copying 4000 bytes to 16000
Copying 4000 bytes to 1a000
Copying 2800 bytes to 1e000
>> OpenBSD BOOT 1.21
Re: sparc64 boot issue on qemu
On Sun, May 31, 2020 at 09:49:34AM +0100, Mark Cave-Ayland wrote: > On 30/05/2020 10:54, Otto Moerbeek wrote: > > > https://cdn.openbsd.org/pub/OpenBSD/snapshots/sparc64/ > > contains the unpatched miniroot. > > > > https://www.drijf.net/openbsd/disk.qcow2 > > > > is the disk image based on the miniroot containing the patch in the > > firts post in this thread. > > > > Thanks for looking into this. > > > > Note that we did *not* observe boot failure on any real sparc64 > > hardware. The bootblock changes I did for the 6.7 release were tested > > on many different machines. > > Thanks for the test case which enables me to reproduce the issue. With > ?fcode-verbose > enabled you see this at the end of the FCode execution: > > ... > ... > 5acf : [ 0x8b7 ] > 5ad0 : b(lit) [ 0x10 ] > 5ad6 : [ 0x81e ] > 5ad7 : 0= [ 0x34 ] > 5ad8 : swap [ 0x49 ] > 5ad9 : drop [ 0x46 ] > 5ada : b?branch [ 0x14 ] >(offset) 5 > 5ade : (compile) [ 0x8c8 ] > 5adf : (compile) b(>resolve) [ 0xb2 ] > OpenBSD IEEE 1275 Bootblock 2.0 > Booting from device /pci@1fe,0/pci@1,1/ide@3/ide@1/cdrom@0 > Try superblock read > FFS v1 > ufs-open complete > .Looking for ofwboot in directory... > . > .. > ofwboot > Found it > .Loading 1a1c8 bytes of file... > Copying 2000 bytes to 4000 > Copying 2000 bytes to 6000 > Copying 2000 bytes to 8000 > Copying 2000 bytes to a000 > Copying 2000 bytes to c000 > Copying 2000 bytes to e000 > Copying 2000 bytes to 1 > Copying 2000 bytes to 12000 > Copying 2000 bytes to 14000 > Copying 2000 bytes to 16000 > Copying 2000 bytes to 18000 > Copying 2000 bytes to 1a000 > Copying 2000 bytes to 1c000 > Copying 2000 bytes to 1e000 > 5ae0 : expect [ 0x8a ] > > > Now that 0x8a is completely wrong since according to > https://github.com/openbsd/src/blob/master/sys/arch/sparc64/stand/bootblk/bootblk.fth > the last instruction should be exit which is 0x33. > > Since the FCode itself is located at load-base (0x4000) it looks to me from > the above > debug that you're loading ofwboot at the same address, overwriting the FCode. > Once > do-boot has finished executing, the FCode interpreter returns to execute the > exit > word which has now been overwritten: so instead of returning to the updated > client > context via exit to execute ofwboot, it executes expect which asks for input > from the > keyboard and then crashes because the stack is incorrect. > > My recommendation would be to load ofwboot at 0x6000 instead of 0x4000 which I > believe will fix the issue. It's interesting you mention that this works on > real > hardware, since it doesn't agree with my reading of the IEEE-1275 > specification so > you're certainly relying on some undocumented behaviour here. > > > ATB, > > Mark. Thanks, the following works indeed. -Otto Index: bootblk.fth === RCS file: /cvs/src/sys/arch/sparc64/stand/bootblk/bootblk.fth,v retrieving revision 1.9 diff -u -p -r1.9 bootblk.fth --- bootblk.fth 2 Apr 2020 06:06:22 - 1.9 +++ bootblk.fth 31 May 2020 13:17:25 - @@ -716,7 +716,8 @@ create cur-blockno -1 l, -1 l, \ Curren 2drop ; -" load-base " evaluate constant loader-base +\\ Do not overwrite bootblocks +" load-base " evaluate 2000 + constant loader-base : load-file-signon ( load-file len boot-path len -- load-file len boot-path len ) ." Loading file" space 2over type cr ." from device" space 2dup type cr
Re: sparc64 boot issue on qemu
On 30/05/2020 00:19, Jason A. Donenfeld wrote:
> Note that you need to run this with `-nographic`, because the kernel
> crashes when trying to use vgafb on sparc64/qemu. I've witnessed two
> varieties crashes:
>
> - https://data.zx2c4.com/openbsd-6.7-sparc64-vga-panic-miniroot67.png
> This happens when booting up miniroot67.fs
>
> - https://data.zx2c4.com/openbsd-6.7-sparc64-vga-panic-after-installation.png
> This happens after installation openbsd onto disk properly, and then
> booting up into it.
>
> Passing `-nographic` prevents these from happening, since vgafb doesn't
> bind to anything.
>
> I don't have a bsd.gdb in order to addr2line this, but if the miniroot
> panic is related to the normal panic, and we then assume alignment
> issues in fb_get_console_metrics, then I wonder if the below patch would
> make a difference. On the other hand, a "data access fault" makes it
> seem more likely that OF_interpret is just getting bogus addresses from
> buggy qemu firmware.
>
> I probably have another two hours to go in waiting for this thing to
> build...
>
> Jason
>
> --- a/sys/arch/sparc64/dev/fb.c
> +++ b/sys/arch/sparc64/dev/fb.c
> @@ -507,6 +507,7 @@ int
> fb_get_console_metrics(int *fontwidth, int *fontheight, int *wtop, int
> *wleft)
> {
> cell_t romheight, romwidth, windowtop, windowleft;
> + uint64_t romheight_64, romwidth_64, windowtop_64, windowleft_64;
>
> /*
>* Get the PROM font metrics and address
> @@ -520,10 +521,15 @@ fb_get_console_metrics(int *fontwidth, int *fontheight,
> int *wtop, int *wleft)
> windowtop == 0 || windowleft == 0)
> return (1);
>
> - *fontwidth = (int)*(uint64_t *)romwidth;
> - *fontheight = (int)*(uint64_t *)romheight;
> - *wtop = (int)*(uint64_t *)windowtop;
> - *wleft = (int)*(uint64_t *)windowleft;
> + memcpy(&romheight_64, (void *)romheight, sizeof(romheight_64));
> + memcpy(&romwidth_64, (void *)romwidth, sizeof(romwidth_64));
> + memcpy(&windowtop_64, (void *)windowtop, sizeof(windowtop_64));
> + memcpy(&windowleft_64, (void *)windowleft, sizeof(windowleft_64));
> +
> + *fontwidth = (int)romwidth_64;
> + *fontheight = (int)romheight_64;
> + *wtop = (int)windowtop_64;
> + *wleft = (int)windowleft_64;
>
> return (0);
> }
AFAICT the problem here is the Forth being used at
https://github.com/openbsd/src/blob/master/sys/arch/sparc64/dev/fb.c#L511:
since the
addr word isn't part of the IEEE-1275 specification, it is currently
unimplemented in
OpenBIOS.
Why is addr needed here? Does the fb.c driver try and change these values
rather than
just read them?
ATB,
Mark.
Re: sparc64 boot issue on qemu
On 30/05/2020 10:54, Otto Moerbeek wrote: > https://cdn.openbsd.org/pub/OpenBSD/snapshots/sparc64/ > contains the unpatched miniroot. > > https://www.drijf.net/openbsd/disk.qcow2 > > is the disk image based on the miniroot containing the patch in the > firts post in this thread. > > Thanks for looking into this. > > Note that we did *not* observe boot failure on any real sparc64 > hardware. The bootblock changes I did for the 6.7 release were tested > on many different machines. Thanks for the test case which enables me to reproduce the issue. With ?fcode-verbose enabled you see this at the end of the FCode execution: ... ... 5acf : [ 0x8b7 ] 5ad0 : b(lit) [ 0x10 ] 5ad6 : [ 0x81e ] 5ad7 : 0= [ 0x34 ] 5ad8 : swap [ 0x49 ] 5ad9 : drop [ 0x46 ] 5ada : b?branch [ 0x14 ] (offset) 5 5ade : (compile) [ 0x8c8 ] 5adf : (compile) b(>resolve) [ 0xb2 ] OpenBSD IEEE 1275 Bootblock 2.0 Booting from device /pci@1fe,0/pci@1,1/ide@3/ide@1/cdrom@0 Try superblock read FFS v1 ufs-open complete .Looking for ofwboot in directory... . .. ofwboot Found it .Loading 1a1c8 bytes of file... Copying 2000 bytes to 4000 Copying 2000 bytes to 6000 Copying 2000 bytes to 8000 Copying 2000 bytes to a000 Copying 2000 bytes to c000 Copying 2000 bytes to e000 Copying 2000 bytes to 1 Copying 2000 bytes to 12000 Copying 2000 bytes to 14000 Copying 2000 bytes to 16000 Copying 2000 bytes to 18000 Copying 2000 bytes to 1a000 Copying 2000 bytes to 1c000 Copying 2000 bytes to 1e000 5ae0 : expect [ 0x8a ] Now that 0x8a is completely wrong since according to https://github.com/openbsd/src/blob/master/sys/arch/sparc64/stand/bootblk/bootblk.fth the last instruction should be exit which is 0x33. Since the FCode itself is located at load-base (0x4000) it looks to me from the above debug that you're loading ofwboot at the same address, overwriting the FCode. Once do-boot has finished executing, the FCode interpreter returns to execute the exit word which has now been overwritten: so instead of returning to the updated client context via exit to execute ofwboot, it executes expect which asks for input from the keyboard and then crashes because the stack is incorrect. My recommendation would be to load ofwboot at 0x6000 instead of 0x4000 which I believe will fix the issue. It's interesting you mention that this works on real hardware, since it doesn't agree with my reading of the IEEE-1275 specification so you're certainly relying on some undocumented behaviour here. ATB, Mark.
Re: sparc64 boot issue on qemu
On Sat, May 30, 2020 at 07:21:15PM +, Miod Vallat wrote: > Yet another case where the emulator does not match the real hardware. > > Why bother with them? > > Get qemu to fix their shit so that the frame buffer metrics variable are > aligned on 64-bit boundaries. There might not be a written specification > for this requirement, but that's the way real hardware behaves, and it > makes complete sense (the variables are OFW cells, which are 64-bit > values and 64-bit aligned). I'm not sure if sparc's OFW is different, but in the device trees as used on arm and probably mips as well, 64-bit values are represented using two 32-bit cells. So I think a requirement of 64-bit would not be correct anyway, and it should be 32-bit instead. I saw some mailthread on the U-Boot lists regarding some alignment requirements of some payloads. Even though they confused the diff- erence between "alignment of payload that will be put somewhere" and "alignment of where the payload actually ends up with", it seems like they also only require 32-bit alignment. The tools that create the image with the payloads, which they discussed, also makes sure all payloads are aligned to 32-bit.
Re: sparc64 boot issue on qemu
Yet another case where the emulator does not match the real hardware. Why bother with them? Get qemu to fix their shit so that the frame buffer metrics variable are aligned on 64-bit boundaries. There might not be a written specification for this requirement, but that's the way real hardware behaves, and it makes complete sense (the variables are OFW cells, which are 64-bit values and 64-bit aligned). If you really want to accomodate their broken firmware, you can avoid using memcpy by relying upon sparc64 being big-endian and do something like: - *fontwidth = (int)*(uint64_t *)romwidth; - *fontheight = (int)*(uint64_t *)romheight; - *wtop = (int)*(uint64_t *)windowtop; - *wleft = (int)*(uint64_t *)windowleft; + *fontwidth = *(uint32_t *)(romwidth + 4); + *fontheight = *(uint32_t *)(romheight + 4); + *wtop = *(uint32_t *)(windowtop + 4); + *wleft = *(uint32_t *)(windowleft + 4); Miod
Re: sparc64 boot issue on qemu
On Sat, May 30, 2020 at 10:11:08AM +0100, Mark Cave-Ayland wrote: > On 30/05/2020 10:03, Otto Moerbeek wrote: > > > Hi, > > > > thanks for the hints, but an unpatched 6.7 miniroot still fails to > > boot for me > > > > qemu-system-sparc64 -machine sun4u -m 1024 -drive \ > > file=miniroot67.img,format=raw -nographic -serial stdio -monitor none > > > > OpenBIOS for Sparc64 > > Configuration device id QEMU version 1 machine id 0 > > kernel cmdline > > CPUs: 1 x SUNW,UltraSPARC-IIi > > UUID: ---- > > Welcome to OpenBIOS v1.1 built on Oct 28 2019 17:08 > > Type 'help' for detailed information > > Trying disk:a... > > Not a bootable ELF image > > Not a bootable a.out image > > > > Loading FCode image... > > Loaded 6882 bytes > > entry point is 0x4000 > > Evaluating FCode... > > OpenBSD IEEE 1275 Bootblock 2.0 > > .. > > > > And then hangs > > > > While the patched bootblocks do boot (but hang later after > > > > scsibus1 at softraid0: 256 targets > > > > > > as before, > > > > -Otto > > Hmmm odd. Is it possible for you to upload your miniroot somewhere for me to > take a > quick look? I don't have a great deal of time right now, but I can run it > through a > debugger to see if anything obvious shows up. > > > ATB, > > Mark. https://cdn.openbsd.org/pub/OpenBSD/snapshots/sparc64/ contains the unpatched miniroot. https://www.drijf.net/openbsd/disk.qcow2 is the disk image based on the miniroot containing the patch in the firts post in this thread. Thanks for looking into this. Note that we did *not* observe boot failure on any real sparc64 hardware. The bootblock changes I did for the 6.7 release were tested on many different machines. -Otto
Re: sparc64 boot issue on qemu
On 29/05/2020 23:56, Jason A. Donenfeld wrote: > Oh that's a nice observation about `boot disk -V`. Doing so actually > got me booting up entirely: > > $ qemu-img convert -O qcow2 miniroot66.fs disk.qcow2 > $ qemu-img resize disk.qcow2 20G > $ qemu-system-sparc64 -m 1024 -drive file=disk.qcow2,if=ide -net > nic,model=ne2k_pci -net user -boot a -nographic -monitor none -serial > stdio I think the problem here is that you're asking OpenBIOS to boot from the (empty) floppy disk with "-boot a" rather than the qcow2 image which is normally attached to the first hard disk "-boot c". As this is the default, then I would expect the command line above to work if you simply drop "-boot a". Also is there a particular reason for using the ne2k_pci NIC instead of the default in-built sunhme device? I try and keep the documentation at https://wiki.qemu.org/Documentation/Platforms/SPARC as accurate as I can, so do look there for latest best practices and command line examples. Finally the version of qemu-system-sparc64 you are running can also boot from a virtio-blk-pci device (again see the above wiki page for details) if you are looking for the best emulated disk performance. ATB, Mark.
Re: sparc64 boot issue on qemu
On 30/05/2020 10:03, Otto Moerbeek wrote: > Hi, > > thanks for the hints, but an unpatched 6.7 miniroot still fails to > boot for me > > qemu-system-sparc64 -machine sun4u -m 1024 -drive \ > file=miniroot67.img,format=raw -nographic -serial stdio -monitor none > > OpenBIOS for Sparc64 > Configuration device id QEMU version 1 machine id 0 > kernel cmdline > CPUs: 1 x SUNW,UltraSPARC-IIi > UUID: ---- > Welcome to OpenBIOS v1.1 built on Oct 28 2019 17:08 > Type 'help' for detailed information > Trying disk:a... > Not a bootable ELF image > Not a bootable a.out image > > Loading FCode image... > Loaded 6882 bytes > entry point is 0x4000 > Evaluating FCode... > OpenBSD IEEE 1275 Bootblock 2.0 > .. > > And then hangs > > While the patched bootblocks do boot (but hang later after > > scsibus1 at softraid0: 256 targets > > > as before, > > -Otto Hmmm odd. Is it possible for you to upload your miniroot somewhere for me to take a quick look? I don't have a great deal of time right now, but I can run it through a debugger to see if anything obvious shows up. ATB, Mark.
Re: sparc64 boot issue on qemu
On Sat, May 30, 2020 at 09:29:36AM +0100, Mark Cave-Ayland wrote: > On 29/05/2020 23:56, Jason A. Donenfeld wrote: > > > Oh that's a nice observation about `boot disk -V`. Doing so actually > > got me booting up entirely: > > > > $ qemu-img convert -O qcow2 miniroot66.fs disk.qcow2 > > $ qemu-img resize disk.qcow2 20G > > $ qemu-system-sparc64 -m 1024 -drive file=disk.qcow2,if=ide -net > > nic,model=ne2k_pci -net user -boot a -nographic -monitor none -serial > > stdio > > I think the problem here is that you're asking OpenBIOS to boot from the > (empty) > floppy disk with "-boot a" rather than the qcow2 image which is normally > attached to > the first hard disk "-boot c". As this is the default, then I would expect the > command line above to work if you simply drop "-boot a". > > Also is there a particular reason for using the ne2k_pci NIC instead of the > default > in-built sunhme device? I try and keep the documentation at > https://wiki.qemu.org/Documentation/Platforms/SPARC as accurate as I can, so > do look > there for latest best practices and command line examples. > > Finally the version of qemu-system-sparc64 you are running can also boot from > a > virtio-blk-pci device (again see the above wiki page for details) if you are > looking > for the best emulated disk performance. > > > ATB, > > Mark. Hi, thanks for the hints, but an unpatched 6.7 miniroot still fails to boot for me qemu-system-sparc64 -machine sun4u -m 1024 -drive \ file=miniroot67.img,format=raw -nographic -serial stdio -monitor none OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 kernel cmdline CPUs: 1 x SUNW,UltraSPARC-IIi UUID: ---- Welcome to OpenBIOS v1.1 built on Oct 28 2019 17:08 Type 'help' for detailed information Trying disk:a... Not a bootable ELF image Not a bootable a.out image Loading FCode image... Loaded 6882 bytes entry point is 0x4000 Evaluating FCode... OpenBSD IEEE 1275 Bootblock 2.0 .. And then hangs While the patched bootblocks do boot (but hang later after scsibus1 at softraid0: 256 targets as before, -Otto
Re: sparc64 boot issue on qemu
On Fri, May 29, 2020 at 4:56 PM Jason A. Donenfeld wrote: > > Oh that's a nice observation about `boot disk -V`. Doing so actually > got me booting up entirely: > > $ qemu-img convert -O qcow2 miniroot66.fs disk.qcow2 > $ qemu-img resize disk.qcow2 20G > $ qemu-system-sparc64 -m 1024 -drive file=disk.qcow2,if=ide -net > nic,model=ne2k_pci -net user -boot a -nographic -monitor none -serial > stdio > OpenBIOS for Sparc64 > Configuration device id QEMU version 1 machine id 0 > kernel cmdline > CPUs: 1 x SUNW,UltraSPARC-IIi > UUID: ---- > Welcome to OpenBIOS v1.1 built on Oct 28 2019 17:08 > Type 'help' for detailed information > Trying /obio/SUNW,fdtwo... > No valid state has been set by load or init-program > > 0 > boot disk -V Not a Linux kernel image > Not a bootable ELF image > Not a bootable a.out image > > Loading FCode image... > Loaded 6882 bytes > entry point is 0x4000 > Evaluating FCode... > OpenBSD IEEE 1275 Bootblock 2.0 > Booting from device /pci@1fe,0/pci@1,1/ide@3/ide@0/disk@0 > Try superblock read > FFS v1 > ufs-open complete > .Looking for ofwboot in directory... > . > .. > ofwboot > Found it > .Loading 1a0e0 bytes of file... > Copying 2000 bytes to 4000 > Copying 2000 bytes to 6000 > Copying 2000 bytes to 8000 > Copying 2000 bytes to a000 > Copying 2000 bytes to c000 > Copying 2000 bytes to e000 > Copying 2000 bytes to 1 > Copying 2000 bytes to 12000 > Copying 2000 bytes to 14000 > Copying 2000 bytes to 16000 > Copying 2000 bytes to 18000 > Copying 2000 bytes to 1a000 > Copying 2000 bytes to 1c000 > Copying 2000 bytes to 1e000 > reserved fcode word. > >> OpenBSD BOOT 1.17 > Trying bsd... > open /etc/random.seed: No such file or directory > Booting /pci@1fe,0/pci@1,1/ide@3/ide@0/disk@0/bsd > 4211776@0x100+7104@0x1404440+3247928@0x1c0+946376@0x1f18f38 > symbols @ 0xfef50340 139 start=0x100 > console is /pci@1fe,0/pci@1,1/ebus@1/su > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2020 OpenBSD. All rights reserved. https://www.OpenBSD.org > > OpenBSD 6.7 (RAMDISK) #298: Thu May 7 19:11:18 MDT 2020 > dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/RAMDISK > real mem = 1073741824 (1024MB) > avail mem = 1044135936 (995MB) > unknown option `V' > mainbus0 at root: OpenBiosTeam,OpenBIOS > cpu0 at mainbus0: SUNW,UltraSPARC-IIi (rev 9.1) @ 100 MHz > cpu0: physical 256K instruction (64 b/l), 16K data (32 b/l), 256K > external (64 b/l) > psycho0 at mainbus0: SUNW,sabre, impl 0, version 0, ign 7c0 > psycho0: bus range 0-2, PCI bus 0 > psycho0: dvma map c000-dfff > pci0 at psycho0 > ppb0 at pci0 dev 1 function 1 "Sun Simba" rev 0x11 > pci1 at ppb0 bus 1 > ebus0 at pci1 dev 1 function 0 "Sun PCIO EBus2" rev 0x01 > clock1 at ebus0 addr 2000-3fff: mk48t59 > "power" at ebus0 addr 7240-7243 ivec 0x1 not configured > "fdthree" at ebus0 addr 0- not configured > com0 at ebus0 addr 3f8-3ff ivec 0x2b: ns16550a, 16 byte fifo > com0: console > pckbc0 at ebus0 addr 60-67 ivec 0x29 > pckbd0 at pckbc0 (kbd slot) > wskbd0 at pckbd0 > "Bochs VGA" rev 0x02 at pci1 dev 2 function 0 not configured > pciide0 at pci1 dev 3 function 0 "CMD Technology PCI0646" rev 0x07: > DMA, channel 0 configured to native-PCI, channel 1 configured to > native-PCI > pciide0: using ivec 0x7e0 for native-PCI interrupt > wd0 at pciide0 channel 0 drive 0: > wd0: 16-sector PIO, LBA48, 20480MB, 41943040 sectors > wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 > atapiscsi0 at pciide0 channel 1 drive 0 > scsibus0 at atapiscsi0: 2 targets > cd0 at scsibus0 targ 0 lun 0: removable > cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 > ppb1 at pci0 dev 1 function 0 "Sun Simba" rev 0x11 > pci2 at ppb1 bus 2 > ne0 at pci2 dev 0 function 0 "Realtek 8029" rev 0x00: ivec 0x7d0, > address 52:54:00:12:34:56 > softraid0 at root > scsibus1 at softraid0: 256 targets > bootpath: /pci@1fe,0/pci@1,1/ide@3,0/ide@0,0/disk@0,0 > root on rd0a swap on rd0b dump on rd0b > WARNING: CHECK AND RESET THE DATE! > erase ^?, werase ^W, kill ^U, intr ^C, status ^T > > Welcome to the OpenBSD/sparc64 6.7 installation program. > (I)nstall, (U)pgrade, (A)utoinstall or (S)hell? Actually, it looks like the `disk debug -V` trick works for 6.7 but fails for -current: snapshots/miniroot67.img Loading FCode image... Loaded 6882 bytes entry point is 0x4000 Evaluating FCode... OpenBSD IEEE 1275 Bootblock 2.0 Booting from device /pci@1fe,0/pci@1,1/ide@3/ide@0/disk@0 Try superblock read FFS v1 ufs-open complete .Looking for ofwboot in directory... . .. ofwboot Found it .Loading 1a0e0 bytes of file... Copying 2000 bytes to 4000 Copying 2000 bytes to 6000 Copying 2000 bytes to 8000 Copying 2000 bytes to a000 Copying 2000 bytes to c000 Copying 2000 bytes to e000 Copying 2000 bytes to 1 Copying 2000 bytes to 12000 Copying 2000 bytes to 14000 Copying 2000 bytes to 16000 Copying 2000 byt
Re: sparc64 boot issue on qemu
Note that you need to run this with `-nographic`, because the kernel
crashes when trying to use vgafb on sparc64/qemu. I've witnessed two
varieties crashes:
- https://data.zx2c4.com/openbsd-6.7-sparc64-vga-panic-miniroot67.png
This happens when booting up miniroot67.fs
- https://data.zx2c4.com/openbsd-6.7-sparc64-vga-panic-after-installation.png
This happens after installation openbsd onto disk properly, and then
booting up into it.
Passing `-nographic` prevents these from happening, since vgafb doesn't
bind to anything.
I don't have a bsd.gdb in order to addr2line this, but if the miniroot
panic is related to the normal panic, and we then assume alignment
issues in fb_get_console_metrics, then I wonder if the below patch would
make a difference. On the other hand, a "data access fault" makes it
seem more likely that OF_interpret is just getting bogus addresses from
buggy qemu firmware.
I probably have another two hours to go in waiting for this thing to
build...
Jason
--- a/sys/arch/sparc64/dev/fb.c
+++ b/sys/arch/sparc64/dev/fb.c
@@ -507,6 +507,7 @@ int
fb_get_console_metrics(int *fontwidth, int *fontheight, int *wtop, int *wleft)
{
cell_t romheight, romwidth, windowtop, windowleft;
+ uint64_t romheight_64, romwidth_64, windowtop_64, windowleft_64;
/*
* Get the PROM font metrics and address
@@ -520,10 +521,15 @@ fb_get_console_metrics(int *fontwidth, int *fontheight,
int *wtop, int *wleft)
windowtop == 0 || windowleft == 0)
return (1);
- *fontwidth = (int)*(uint64_t *)romwidth;
- *fontheight = (int)*(uint64_t *)romheight;
- *wtop = (int)*(uint64_t *)windowtop;
- *wleft = (int)*(uint64_t *)windowleft;
+ memcpy(&romheight_64, (void *)romheight, sizeof(romheight_64));
+ memcpy(&romwidth_64, (void *)romwidth, sizeof(romwidth_64));
+ memcpy(&windowtop_64, (void *)windowtop, sizeof(windowtop_64));
+ memcpy(&windowleft_64, (void *)windowleft, sizeof(windowleft_64));
+
+ *fontwidth = (int)romwidth_64;
+ *fontheight = (int)romheight_64;
+ *wtop = (int)windowtop_64;
+ *wleft = (int)windowleft_64;
return (0);
}
Re: sparc64 boot issue on qemu
On Fri, May 29, 2020 at 4:56 PM Jason A. Donenfeld wrote: > > Oh that's a nice observation about `boot disk -V`. Doing so actually > got me booting up entirely: > > $ qemu-img convert -O qcow2 miniroot66.fs disk.qcow2 Er, copy and paste error. The below is actually from miniroot67.fs.
Re: sparc64 boot issue on qemu
Oh that's a nice observation about `boot disk -V`. Doing so actually got me booting up entirely: $ qemu-img convert -O qcow2 miniroot66.fs disk.qcow2 $ qemu-img resize disk.qcow2 20G $ qemu-system-sparc64 -m 1024 -drive file=disk.qcow2,if=ide -net nic,model=ne2k_pci -net user -boot a -nographic -monitor none -serial stdio OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 kernel cmdline CPUs: 1 x SUNW,UltraSPARC-IIi UUID: ---- Welcome to OpenBIOS v1.1 built on Oct 28 2019 17:08 Type 'help' for detailed information Trying /obio/SUNW,fdtwo... No valid state has been set by load or init-program 0 > boot disk -V Not a Linux kernel image Not a bootable ELF image Not a bootable a.out image Loading FCode image... Loaded 6882 bytes entry point is 0x4000 Evaluating FCode... OpenBSD IEEE 1275 Bootblock 2.0 Booting from device /pci@1fe,0/pci@1,1/ide@3/ide@0/disk@0 Try superblock read FFS v1 ufs-open complete .Looking for ofwboot in directory... . .. ofwboot Found it .Loading 1a0e0 bytes of file... Copying 2000 bytes to 4000 Copying 2000 bytes to 6000 Copying 2000 bytes to 8000 Copying 2000 bytes to a000 Copying 2000 bytes to c000 Copying 2000 bytes to e000 Copying 2000 bytes to 1 Copying 2000 bytes to 12000 Copying 2000 bytes to 14000 Copying 2000 bytes to 16000 Copying 2000 bytes to 18000 Copying 2000 bytes to 1a000 Copying 2000 bytes to 1c000 Copying 2000 bytes to 1e000 reserved fcode word. >> OpenBSD BOOT 1.17 Trying bsd... open /etc/random.seed: No such file or directory Booting /pci@1fe,0/pci@1,1/ide@3/ide@0/disk@0/bsd 4211776@0x100+7104@0x1404440+3247928@0x1c0+946376@0x1f18f38 symbols @ 0xfef50340 139 start=0x100 console is /pci@1fe,0/pci@1,1/ebus@1/su Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2020 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.7 (RAMDISK) #298: Thu May 7 19:11:18 MDT 2020 dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/RAMDISK real mem = 1073741824 (1024MB) avail mem = 1044135936 (995MB) unknown option `V' mainbus0 at root: OpenBiosTeam,OpenBIOS cpu0 at mainbus0: SUNW,UltraSPARC-IIi (rev 9.1) @ 100 MHz cpu0: physical 256K instruction (64 b/l), 16K data (32 b/l), 256K external (64 b/l) psycho0 at mainbus0: SUNW,sabre, impl 0, version 0, ign 7c0 psycho0: bus range 0-2, PCI bus 0 psycho0: dvma map c000-dfff pci0 at psycho0 ppb0 at pci0 dev 1 function 1 "Sun Simba" rev 0x11 pci1 at ppb0 bus 1 ebus0 at pci1 dev 1 function 0 "Sun PCIO EBus2" rev 0x01 clock1 at ebus0 addr 2000-3fff: mk48t59 "power" at ebus0 addr 7240-7243 ivec 0x1 not configured "fdthree" at ebus0 addr 0- not configured com0 at ebus0 addr 3f8-3ff ivec 0x2b: ns16550a, 16 byte fifo com0: console pckbc0 at ebus0 addr 60-67 ivec 0x29 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0 "Bochs VGA" rev 0x02 at pci1 dev 2 function 0 not configured pciide0 at pci1 dev 3 function 0 "CMD Technology PCI0646" rev 0x07: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide0: using ivec 0x7e0 for native-PCI interrupt wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 20480MB, 41943040 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 ppb1 at pci0 dev 1 function 0 "Sun Simba" rev 0x11 pci2 at ppb1 bus 2 ne0 at pci2 dev 0 function 0 "Realtek 8029" rev 0x00: ivec 0x7d0, address 52:54:00:12:34:56 softraid0 at root scsibus1 at softraid0: 256 targets bootpath: /pci@1fe,0/pci@1,1/ide@3,0/ide@0,0/disk@0,0 root on rd0a swap on rd0b dump on rd0b WARNING: CHECK AND RESET THE DATE! erase ^?, werase ^W, kill ^U, intr ^C, status ^T Welcome to the OpenBSD/sparc64 6.7 installation program. (I)nstall, (U)pgrade, (A)utoinstall or (S)hell?
