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
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
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
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
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
> >>
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
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
>
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
>
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.
>>
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:
> >
> > -
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
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
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
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
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
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
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 \
> >
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
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
>
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
> > $
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
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
-
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.
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
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
25 matches
Mail list logo
