On Sat, Jun 06, 2015 at 03:43:46PM +0200, Patrick Wildt wrote:
>
> > Am 06.06.2015 um 15:06 schrieb Jonathan Gray <j...@jsg.id.au>:
> >
> > On Sun, May 24, 2015 at 02:34:04AM +0200, Patrick Wildt wrote:
> >> Just some random input.
> >>
> >> QEMU supports emulating a few ARM boards. One of those is
> >> the cubieboard which OpenBSD already supports. Unfortunately
> >> it looks like that even though it does emulate its ethernet controller,
> >> it does not emulate any storage.
> >>
> >> Qemu also supports emulating a ???virt??? machine. This is essentially
> >> a basic machine that only provides virtio devices. This means that
> >> if you use the virtio mmio interface you can get access to peripherals
> >> like storage, ethernet, random number generator, and some more.
> >>
> >> Now this platform is very simple to support if you have FDT, but
> >> even without it, it???s easily doable.
> >>
> >> As far as I know that platform is supported by Bitrig and recently
> >> also FreeBSD.
> >>
> >> The people who work on the ARM subtree already have enough
> >> on their plates to worry about another platform. If you want this
> >> to happen, feel free to step up and have a look. It???s not that hard
> >> and I bet it???s a chance for people to get into hacking OpenBSD.
> >>
> >> \Patrick
> >
> > The virt target sets a board id of -1.
>
> Yes, because they expect you to go with time and use the device
> tree tables. I think there???s a big push to go away from these board
> ids and they start to not be reliable anymore. -1 probably means
> ???don???t use it???.
Right, -1 seems to mean "use fdt". You might want to change
"BOARD_ID_VIRT 0xffffffff" and the code that uses it in case
real hardware sets it.
>
> I have FreeScale LS1021A TWR which doesn???t even set the
> boardid and it???s random everytime I boot it up. But in that case
> you can set it in the u-boot env. One could probably patch the
> qemu in ports to set some other id.
I'd rather avoid patching qemu, it's unlikely anyone other
than OpenBSD would care about such patches.
>
> > The virtio ranges are present
> > in the vexpress-a9 and vexpress-a15 targets which annoyingly have
> > different load addresses and memory maps but share the same
> > board id.
> >
> > Seems to be an interrupt problem of some sort with the a15
> > target but the a9 one works.
>
> Oh, I had enough of those??? We have some changes in the
> Bitrig agtimer which might make it work better. No guarantees.
Thanks, turns out only the interrupt for the "secure physical timer" (29)
was hooked up, and not the interrupt for "non-secure physical timer" (30).
Works with that hooked up.
OpenBSD/vexpress booting ...
arg0 0x0 arg1 0x8e0 arg2 0x80000100
atag core flags 1 pagesize 1000 rootdev 0
atag mem start 0x80000000 size 0x8000000
atag cmdline [sd0a]
bootfile: sd0a
bootargs:
memory size derived from u-boot
bootconf.mem[0].address = 80000000 pages 32768/0x08000000
Allocating page tables
freestart = 0x80767000, free_pages = 30873 (0x00007899)
IRQ stack: p0x80795000 v0xc0795000
ABT stack: p0x80796000 v0xc0796000
UND stack: p0x80797000 v0xc0797000
SVC stack: p0x80798000 v0xc0798000
Creating L1 page table at 0x80768000
Mapping kernel
Constructing L2 page tables
undefined page pmap [ using 384116 bytes of bsd ELF symbol table ]
board type: 2272
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2015 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 5.7-current (GENERIC) #78: Sun Jun 7 00:03:42 AEST 2015
j...@imx.jsg.id.au:/usr/src/sys/arch/armv7/compile/GENERIC
real mem = 134217728 (128MB)
avail mem = 123506688 (117MB)
warning: no entropy supplied by boot loader
mainbus0 at root
cortex0 at mainbus0
ampintc0 at cortex0 nirq 160
agtimer0 at cortex0: tick rate 24000 KHz
cpu0 at mainbus0: ARM Cortex A15 R2 rev 1 (ARMv7 core)
cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu0: 32KB(64b/l,2way) I-cache, 32KB(64b/l,2way) wr-back D-cache
vexpress0 at mainbus0: ARM VExpress
pluart0 at vexpress0 console
virtio0 at vexpress0: Virtio Entropy Device
viornd0 at virtio0
virtio1 at vexpress0: Virtio Memory Balloon Device
viomb0 at virtio1
virtio2 at vexpress0: Virtio Network Device
vio0 at virtio2: address 52:54:00:12:34:56
virtio3 at vexpress0: Virtio SCSI host Device
vioscsi0 at virtio3: qsize 1024
scsibus0 at vioscsi0: 255 targets
sd0 at scsibus0 targ 0 lun 0: <QEMU, QEMU HARDDISK, 2.3.> SCSI3 0/direct fixed
sd0: 1024MB, 512 bytes/sector, 2097152 sectors, thin
cd0 at scsibus0 targ 2 lun 0: <QEMU, QEMU CD-ROM, 2.3.> SCSI3 5/cdrom removable
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
boot device: sd0
root on sd0a (bfa4a02f29558655.a) swap on sd0b dump on sd0b
WARNING: CHECK AND RESET THE DATE!
Automatic boot in progress: starting file system checks.
/dev/rsd0a: file system is clean; not checking
setting tty flags
pf enabled
starting network
DHCPREQUEST on vio0 to 255.255.255.255
DHCPACK from 192.168.1.1 (00:60:e0:48:36:c0)
bound to 192.168.1.159 -- renewal in 21600 seconds.
starting early daemons: syslogd pflogd ntpd.
starting RPC daemons:.
savecore: no core dump
checking quotas: done.
clearing /tmp
kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.
starting network daemons: sshd smtpd sndiod.
starting local daemons: cron.
Sat Jun 6 23:04:07 AEST 2015
OpenBSD/armv7 (vexpress.jsg.id.au) (console)
login:
