Customizing Microblaze in QEMU
Published:
The Microblaze QEMU port contributed in 2009 by Edgar E. Iglesias from Axis Communications AB (Sweden) makes QEMU a very useful tool for Microblaze OS prototyping.
The problem is that the port is limited to emulating a fixed set of hardware (Petalogix s3adsp1800 Spartan3a board) with fixed addresses in memory, interrupt controller, timers, UARTs, ETH, etc.
Of course, you could adapt your application (e.g. Linux or eCos kernel) to take this limitation into consideration, but why make things harder than they should be? We’ve decided to simplify this process by removing the need to tamper with the kernel code. Instead, by making a few simple alterations to the QEMU, we allowed it to use an external “peripherial” file (mb.per) with hardware definitions.
An example mb.per file for the Petalogix board (think of it as the “default” file, as these are the settings QEMU originally starts with):
#
# petalogix s3adsp1800 board microblaze definition
#
fpgaid 0x0C000000
ddr 0x90000000 134217728
irq 0x81800000 0
sysbus xilinx,uartlite 0x84000000 3
timer 0x83C00000 0 2 62000000
eth 0x81000000 1
flash 0xA0000000 16777216
When QEMU is launched with the file above, it will run Microblaze @ spartan3adsp with 128MB of DDR memory mapped @ 0×90000000, irq controller @ 0×81800000, one UARTLITE serial @ 0×84000000, IRQ=3, two 62 MHz timers @ 0x83C00000, IRQ=2, one ethlite @ 0×81000000, IRQ=1 and 16MB flash driver @ 0xA0000000.
The idea is very simple, and the general shape of the .per file is:
# fpgaid id
# 0x04000000 : Virtex2
# 0x05000000 : Virtex2pro
# 0x06000000 : Spartan3
# 0x07000000 : Virtex4
# 0x08000000 : Virtex5
# 0x09000000 : Spartan3e
# 0x0A000000 : Spartan3a
# 0x0B000000 : Spartan3an
# 0x0C000000 : Spartan3adsp
# 0x0D000000 : Spartan6
# 0x0E000000 : Virtex6
# ddr addr size
# irq addr sys_irq
# sysbus name addr irq
# timer addr irq count clock_speed
# eth addr irq
# flash addr size
Using this “fix” we’ve successfully started eCos and Linux kernels prepared by us for other targets (Spartan6).
All this data can be retrieved from the .dts/.dtb Device Tree file, so one idea for the future would be to make QEMU read the necessary information from the mb.dtb file.
Attachments:
