Re: Booting NetBSD/evbarm on QEMU (IntegratorCP)

[Sergio López <slp%sinrega.org@localhost>]

2013/2/7 Nick Hudson <skrll%netbsd.org@localhost>:
> Cool. I wanted to do this myself, but never got around to it.
>
> I'd prefer to see it called INTEGRATOR_CP and match the real hardware as
> close as
> possible. If someone has real hardware to test on that'd be even better.
>

I'm OK with naming it like that, but I can't do much about real
hardware support. I think it should work, perhaps with minor changes
related with bootstrapping. Apparently, it's no easy to found one of
those boards nowadays, so probably the main use for this port will be
running it under QEMU.

>> It can be used with something like this: "qemu-system-arm -M
>> integratorcp -cpu arm1136 -m 128m -kernel netbsd.gz.ub -serial stdio
>> -net nic -net tap". This image doesn't contain a ramdisk, so you'll
>> need an NFS with NetBSD/evbarm root, and a properly configured DHCP
>> server.
>
> I doubt the CPU will make a difference to qemu, so maybe default to the
> minimum CPU.
>
> "Integrator/CP is compatible with the following Integrator Core Modules:
> ARM920T,
> ARM922T-XA10, ARM926EJ-S, ARM946E-S and ARM966E-S, ARM1026EJ-S and
> ARM1136J(F)-S."

QEMU is able to take advantage from ARMv6 power saving features to
reduce CPU usage on host machine (without this, it'll try to eat as
much CPU as it can). Also, I think the virtual MMU could take
advantage from ASIDs, but I'm not sure about this one.

Anyway, I just tried to compile a kernel with built-in support for
ARMv9/10/11, and it worked nicely (when I started working on this I
thought it was giving me some trouble, but probably I was being fooled
by another issue), so perhaps this could be the default configuration.

> There appears to be a few magic numbers in there - can these be replaced,
> please? I'll look at some of the other details later

I think you're talking about some addresses in
"integrator_sdram_bounds" from "integrator_qemu_machdep.c". This code
comes from the original "integrator_machdep.c", but it can be cleaned
it up a bit more, if it's needed.

Thinking about this, probably the fact that I decided to duplicate
those files deserves an explanation, because it could be the wrong
decision.

Theoretically, being able to boot on QEMU only required changing the
type of plcomm devices (from PL010 to PL011), adding the smc network
driver, and few tweaks here and there. But with the original code from
"initarm", the MMU was properly initialized, but the kernel crashed as
soon as it tried to make use of the VM's pool subsystem, so I assumed
there were some changes in the layer between common and machine
dependent code that were not applied to this port.

At this point, I've changed "initarm" to make use of arm/arm32 common
functions, and since that implied substantial changes to the most
relevant function, I've decided to put them in another file. But, if
it's preferred, I can put all code in the same file with build time
conditionals.

Sergio.