On Sat, Jun 06, 2015 at 05:37:38PM +0200, Patrick Wildt wrote:
>
> > 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.
It turns out the virt target doesn't setup the u-boot tags either
because it sets "vbi->bootinfo.get_dtb = machvirt_dtb;" unlike
any of the other qemu targets. That needs to be patched out
to be able to boot without fdt.
Otherwise qemu will not setup the tags:
static inline bool have_dtb(const struct arm_boot_info *info)
{
return info->dtb_filename || info->get_dtb;
}
if (!have_dtb(info)) {
if (old_param) {
set_kernel_args_old(info);
} else {
set_kernel_args(info);
}
}
And the gic is not at the offset from periphbase the code expects like
exynos.
And it uses yet another load address/memory map and seems to have
different interrupt/timer problems. None of the other agtimer
changes seem to help there.
OpenBSD/vexpress booting ...
arg0 0x0 arg1 0xffffffff arg2 0x40000100
atag core flags 1 pagesize 1000 rootdev 0
atag mem start 0x40000000 size 0x8000000
atag cmdline [sd0a]
bootfile: sd0a
bootargs:
memory size derived from u-boot
bootconf.mem[0].address = 40000000 pages 32768/0x08000000
Allocating page tables
freestart = 0x4076b000, free_pages = 30869 (0x00007895)
IRQ stack: p0x40799000 v0xc0799000
ABT stack: p0x4079a000 v0xc079a000
UND stack: p0x4079b000 v0xc079b000
SVC stack: p0x4079c000 v0xc079c000
Creating L1 page table at 0x4076c000
Mapping kernel
Constructing L2 page tables
undefined page pmap [ using 391336 bytes of bsd ELF symbol table ]
board type: 4294967295
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) #144: Mon Jun 8 19:55:45 AEST 2015
j...@imx.jsg.id.au:/sys/arch/armv7/compile/GENERIC
real mem = 134217728 (128MB)
avail mem = 123490304 (117MB)
warning: no entropy supplied by boot loader
mainbus0 at root
cortex0 at mainbus0
ampintc0 at cortex0 nirq 160
agtimer0 at cortex0: tick rate 62500 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 Virtual Machine
pluart0 at vexpress0 console
virtio0 at vexpress0: Virtio Unknown (0) Device
virtio1 at vexpress0: Virtio Unknown (0) Device
virtio2 at vexpress0: Virtio Unknown (0) Device
virtio3 at vexpress0: Virtio Unknown (0) Device
virtio4 at vexpress0: Virtio Unknown (0) Device
virtio5 at vexpress0: Virtio Unknown (0) Device
virtio6 at vexpress0: Virtio Unknown (0) Device
virtio7 at vexpress0: Virtio Unknown (0) Device
virtio8 at vexpress0: Virtio Unknown (0) Device
virtio9 at vexpress0: Virtio Unknown (0) Device
virtio10 at vexpress0: Virtio Unknown (0) Device
virtio11 at vexpress0: Virtio Unknown (0) Device
virtio12 at vexpress0: Virtio Unknown (0) Device
virtio13 at vexpress0: Virtio Unknown (0) Device
virtio14 at vexpress0: Virtio Unknown (0) Device
virtio15 at vexpress0: Virtio Unknown (0) Device
virtio16 at vexpress0: Virtio Unknown (0) Device
virtio17 at vexpress0: Virtio Unknown (0) Device
virtio18 at vexpress0: Virtio Unknown (0) Device
virtio19 at vexpress0: Virtio Unknown (0) Device
virtio20 at vexpress0: Virtio Unknown (0) Device
virtio21 at vexpress0: Virtio Unknown (0) Device
virtio22 at vexpress0: Virtio Unknown (0) Device
virtio23 at vexpress0: Virtio Unknown (0) Device
virtio24 at vexpress0: Virtio Unknown (0) Device
virtio25 at vexpress0: Virtio Unknown (0) Device
virtio26 at vexpress0: Virtio Unknown (0) Device
virtio27 at vexpress0: Virtio Unknown (0) Device
virtio28 at vexpress0: Virtio Entropy Device
viornd0 at virtio28
virtio29 at vexpress0: Virtio Memory Balloon Device
viomb0 at virtio29
virtio30 at vexpress0: Virtio Network Device
vio0 at virtio30: address 52:54:00:12:34:56
virtio31 at vexpress0: Virtio SCSI host Device
vioscsi0 at virtio31: 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
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!
