> Am 06.06.2015 um 16:47 schrieb Jonathan Gray <j...@jsg.id.au>: > > 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.
Yeah, I removed that define quite a while ago. I have 4 boards and SoCs that run FDT only and don’t care about any boardid. > >> >> 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. Agreed. My idea was an OpenBSD-ports-only patch, but it would be better if one just doesn't rely on the boardid at all. > >> >>> 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. Great! > > 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:
