1 Introduction
I came to the QEMU project with the goal of writing a new machine. We are
reverse
engineering this machine and do not have the SoC reference manual. We do have
the flash code, the bare metal startup code. Thus we're having to guess and
infer a
lot about the machine from the code. Since this is an ARM A9, my initial
thought
was to base the new machine on the vexpress-a9.
I've been asking lots of questions in #q...@irc.oftc.net and some of the folks
there (mainly pm215 and f4bug) suggested I put these questions and my comments
into writing and send out to the mailing list to help new people become familiar
with the project.
I confess, I am ignorant. Some of the questions may not be QEMU questions at
all
but ARM architecture, hardware, or other questions. Please bear with me and
help
me out.
It is believed we are using an ARM Cortex A9 MPCORE machine with 4 cores and
with TrustZone (and possibly hypervisor) functionality. The machine
eventually
loads and runs linux, but we believe there are at least three levels of
bootloaders
prior to linux:
1. bootrom
2. first-level bootloader.
3. second-level bootloader via an embedded elf file.
It appears that only two of the four cores are used and it appears to be an
asymmetric
multiprocessing design, in which the two cores are running different OSes,
one a
bare metal and the other linux.
The goal is to define the minimum amount of machine (cpu, sram, dram, itcm,
dtcm,
gic, flash, ?) be able to reverse engineer code up to the second-level
bootloader.
Then hopefully we can leverage QEMU's capabilities, e.g., exception reporting in
the debug output, to determine missing functionality.
The QEMU project was git cloned on 4/16/2020. The work is being done under
Fedora 31.
1
2 Questions
2.1 Top-Level Architecture
There is a MachineClass, MachineState, and MachineInstance. What are purposes
of these logical divisions?
2.2 Miscellaneous
1. Apparently the CPU has properties. What are the specific properties and
their
defaults? How do you change a property's default value?
2. Ditto previous question for other machine components.
3. How do you model and implement startup from power on reset?
(a) Bootrom code is modeled by specifying -bios !file? on the command
line.
What format should the code in !file? be?
(b) Bootrom code performs required initializations, e.g., populating
the in-
terrupt vector table at the appropriate spot, GIC? other
registers? Copy-
ing code to DRAM?
(c) Once bootrom code is finished, what happens? Should it simply
branch
to the first-level bootloader (which is supposedly loaded into
DRAM)?
Is the reset vector used somehow?
4. I'm using the -pflash command-line option to map a copy of the flash
code.
Do you simply specify the address of an existing memory (DRAM) of where
to load the file? Is there a way to specify an entry point address (of
where to
begin execution). How does this interact with the -bios option?
5. There may be custom hardware involved, e.g., GPIOs, I2Cs, etc. How
would
these be defined in the machine?
6. Documentation for routing the monitor to another place (e.g., a telnet
termi-
nal) could be better. pm215 gave me the following complex set of
command-
line options:
-chardev
socket,id=monitor,host=127.0.0.1,port=4444,server,nowait,telnet -mon
chardev=monitor,mode=readline
7. Ditto above comment for the -d option.
8. How are multiple cores traced in the debug output?
9. The vexpress code had clocks, voltages, etc. defined. Are these
necessary
for a bare-metal, base functioning machine? Exactly which components
are
absolutely required? E.g., is the busdev required?
2
10. Terminology questions:
(a) Throughout there is mention of highmem/lowmem. What does
this
mean?
(b) Throughout there are "PL" devices, e.g., PL111. What
does "PL"
mean?
3 Conclusion
That's all for now - thanks for all help/suggestions/pointers/etc.
3
Randy Yates, DSP/Embedded Firmware Developer
Digital Signal Labs
http://www.digitalsignallabs.com
