Re: sparc64 boot issue on qemu

2020-06-01 Thread Theo de Raadt
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

2020-06-01 Thread Jason A. Donenfeld
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

2020-06-01 Thread Mark Cave-Ayland
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 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

2020-06-01 Thread Jason A. Donenfeld
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 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

2020-06-01 Thread Jason A. Donenfeld
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 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

2020-06-01 Thread Mark Cave-Ayland
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 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

2020-06-01 Thread Jason A. Donenfeld
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

2020-06-01 Thread Jason A. Donenfeld
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 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

2020-05-31 Thread Theo de Raadt
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

2020-05-31 Thread Mark Cave-Ayland
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

2020-05-31 Thread Theo de Raadt
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(_64, (void *)romheight, sizeof(romheight_64));
> > +   memcpy(_64, (void *)romwidth, sizeof(romwidth_64));
> > +   memcpy(_64, (void *)windowtop, sizeof(windowtop_64));
> > +   memcpy(_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

2020-05-31 Thread Klemens Nanni
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

2020-05-31 Thread Otto Moerbeek
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

2020-05-31 Thread Mark Cave-Ayland
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(_64, (void *)romheight, sizeof(romheight_64));
> + memcpy(_64, (void *)romwidth, sizeof(romwidth_64));
> + memcpy(_64, (void *)windowtop, sizeof(windowtop_64));
> + memcpy(_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

2020-05-31 Thread Mark Cave-Ayland
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

2020-05-30 Thread Patrick Wildt
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

2020-05-30 Thread Miod Vallat
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

2020-05-30 Thread Otto Moerbeek
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

2020-05-30 Thread Mark Cave-Ayland
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

2020-05-30 Thread Mark Cave-Ayland
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

2020-05-30 Thread Otto Moerbeek
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

2020-05-29 Thread Jason A. Donenfeld
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 

Re: sparc64 boot issue on qemu

2020-05-29 Thread Jason A. Donenfeld
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(_64, (void *)romheight, sizeof(romheight_64));
+   memcpy(_64, (void *)romwidth, sizeof(romwidth_64));
+   memcpy(_64, (void *)windowtop, sizeof(windowtop_64));
+   memcpy(_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

2020-05-29 Thread Jason A. Donenfeld
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

2020-05-29 Thread Jason A. Donenfeld
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?



sparc64 boot issue on qemu

2020-05-29 Thread Otto Moerbeek
On Thu, May 28, 2020 at 10:11:28AM +0200, Otto Moerbeek wrote:

> On Thu, May 28, 2020 at 01:21:21AM -0600, Jason A. Donenfeld wrote:
> 
> > On Thu, May 28, 2020 at 1:19 AM Otto Moerbeek  wrote:
> > > Of course.., I was running it from a !wxallowed mount. BTW, qemu is in
> > > packages, no need to build it yourself.
> > 
> > Sure, but now I've been somewhat nerd sniped and am playing with this
> > fcode forth implementation in qemu :-P. I wonder if there's something
> > missing in the 64-bit extensions to IEEE 1275, in table.fs...
> 
> OK, can reproduce. I'll see if I can find out something.
> 
>   -Otto
> 

After running the bootblocks in debug mode (using boot disk -V) and
seeing ofwboot was found and loaded, I added some debug code to the
bootblocks and now it correctly starts ofwboot on qemu


Trying disk:a...
Not a bootable ELF image
Not a bootable a.out image

Loading FCode image...
Loaded 6936 bytes
entry point is 0x4000
Evaluating FCode...
OpenBSD IEEE 1275 Bootblock 2.0
..free mem
close boot dev
start loaded program
>> 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:a/bsd
4225784@0x100+1288@0x1407af8+3249436@0x1c0+944868@0x1f1951c 
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
real mem = 2147483648 (2048MB)
avail mem = 2099232768 (2001MB)
random: boothowto does not indicate good seed
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, 3MB, 6400 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

It hangs at this point here, but I that's clearly another issue.

Puzzled...

-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 29 May 2020 11:53:36 -
@@ -850,16 +850,22 @@ create cur-blockno -1 l, -1 l,\ Curren
   " /ofwboot" load-file( -- load-base )
then
 
+   ." free mem" cr
+
\ Free memory for reading disk blocks
cur-block 0<> if
   dev-block dev-blocksize free-mem
then
 
+   ." close boot dev" cr
+
\ Close boot device
boot-ihandle dup -1 <> if
   cif-close -1 to boot-ihandle 
then

+   ." start loaded program" cr
+
dup 0<> if " to load-base init-program" evaluate then
 ;