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:
>>>>
&
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
>> a
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.
>>
>
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 happen
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 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
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
> C
On 17/08/18 14:27, Mark Kettenis wrote:
>> Obviously I can't categorically state that QEMU's emulation is perfect,
>> but it can now reliably run all of Linux, MacOS, NetBSD and FreeBSD in
>> my local tests which makes me suspect that OpenBSD is trying to do
>> something different here.
>
> Runs
On 17/08/18 13:55, Solene Rapenne wrote:
> I'm using the macppc port since 6.1 to -current and apart failing
> harware I don't have any issue while playing Doom or rebuilind ports :)
Hmmm. 6.1 is the latest version that I can boot to userspace, even if it
faults quickly after a few keypresses (QE
On 17/08/18 13:37, Solene Rapenne wrote:
> Mark Cave-Ayland wrote:
>> Hi all,
>>
>> I was just wondering what is the current state of the openbsd/macppc
>> port? As part of my recent work on qemu-system-ppc I now have a patch
>> that can boot OpenBSD macppc unde
On 17/08/18 13:34, Jonathan Gray wrote:
> On Fri, Aug 17, 2018 at 12:15:10PM +0100, Mark Cave-Ayland wrote:
>> Hi all,
>>
>> I was just wondering what is the current state of the openbsd/macppc
>> port? As part of my recent work on qemu-system-ppc I now have a pat
Hi all,
I was just wondering what is the current state of the openbsd/macppc
port? As part of my recent work on qemu-system-ppc I now have a patch
that can boot OpenBSD macppc under the New World (-M mac99,via=pmu)
machine but I'm seeing quite a bit of instability in OpenBSD compared to
all my oth
On 14/08/17 21:18, Mark Kettenis wrote:
>> So tracing through HME register writes it seems the difference between
>> OpenBSD and the other OSs is that OpenBSD appears to write to the
>> virtual address 0x40008098000 with a standard (0x80) primary ASI,
>> whereas the other OSs seem to write directl
On 14/08/17 14:25, Mark Kettenis wrote:
>> Great, thanks for the information - the fact that the nsphy0 has been
>> detected correctly means that the access still works. Looks like I'll
>> have to go digging deeper.
>
> The OpenBSD code uses %asi if necessary to let the hardware do the
> byteswap
On 13/08/17 16:52, Kaashif Hymabaccus wrote:
> Hello Mark,
>
> I have a Sun Ultra 5 with the following dmesg:
>
> console is /pci@1f,0/pci@1,1/ebus@1/se@14,40:a
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California. All rights reserved.
> Copyright
Hi all,
Does anyone have any real Sun hardware containing a PCI hme card running
OpenBSD, and if so does it work with the current 6.1 release?
I've been working on a virtual hme device for qemu-system-sparc64 in the
hope of getting working networking on *BSD images and I have a driver
that now wo
On 17/04/16 20:42, Mark Kettenis wrote:
> Ran into an interesting problem with the sparc64 pmap bootstrapping
> code. Early on, we ask the firmware what physical memory is
> available. Later we use this memory to set up the kernel page tables,
> kernel stack and per-cpu data structures. We expl
Hi all,
From my work on running OpenBSD under OpenBIOS/QEMU, I found a couple
of bugs in the NetBSD OF bindings for SPARC64 which also seem to be
relevant to OpenBSD. I've applied patches to OpenBIOS to compensate for
these bugs which allows OpenBSD to boot under QEMU, but thought that as
the
On 09/09/14 21:26, Miod Vallat wrote:
Interesting. Longer term the aim of the QEMU project is to move the
hardwired machine types into pluggable devices, e.g. you can build a whole
machine on the command line from multiple -device parameters or preload the
default machine types such as sun4u usi
On 09/09/14 20:04, Bryan Steele wrote:
Neat! :-)
It seems the GENERIC sparc64 kernel already has PCMCIA/CardBus ne(4), so
adding 'ne* at pci?' might "just work".
OpenBSD/sparc64 already supports sun4v LDOMS, so there's drivers implementing
the virtual protocols (..vnet(4)/vdsk(4)). Does QEMU s
On 09/09/14 19:57, Brad Smith wrote:
The Realtek hardware in that dmesg is an NE2000 PCI adapter which
the sparc64 kernel config indeed does not have a driver for at the
very moment, although it could be added. Having a QEMU driver for
the Happy Meal MAC would provide the best level of compatibi
On 09/09/14 19:54, Mark Kettenis wrote:
Sweet.
The RealTek 8129 should be supported by the rl(4) driver, and is
AFAICT included in the RAMDISK kernel. Not sure why it doesn't
attach. If it is easy to hook up QEMU's e1000 hardware emulation to
the emulated sparc64 hardware, that should be supp
Hi all,
Following up from my posts at the beginning of the summer, I'm pleased
to announce that as of today, qemu-system-sparc64 built from QEMU git
master will successfully install OpenBSD from an .iso and boot back into
it in serial mode with its default sun4u emulation:
$ ./qemu-system-s
On 08/05/14 20:28, Mark Kettenis wrote:
Hi Mark,
Interesting to see sparc64 support in QEMU.
Yeah, it's been a work in progress for quite a while now. There seems to
be two main areas of interest: firstly for people who are now migrating
away from SPARC but need to keep a legacy application
On 06/05/14 19:18, Mark Cave-Ayland wrote:
(cut)
As soon as I step into address 0x1001804 then this is where things start
to go wrong; the TLB (TTE) entry for 0x180 which is accessed by %sp
is marked as privileged, but ASI 0x11 is user access only. QEMU's
current behaviour for this
Hi all,
I'm currently working on a set of patches for OpenBIOS (the OF
implementation for QEMU) in order to get the various *BSD kernels to
boot under QEMU SPARC64 with some success, but I'm struggling with a
privilege violation trap which occurs on the first window fill trap
after OpenBSD ta
26 matches
Mail list logo