qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-arm] v7m reset vs rom loading ordering


From: Dr. David Alan Gilbert
Subject: [Qemu-arm] v7m reset vs rom loading ordering
Date: Sat, 26 Dec 2015 19:07:59 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

Hi,
  I'm having problems with the v7m reset code happening before the loading
of the ROM code, and hence getting the wrong starting location.
I'm using the stm32f205 model (modified to take an m4 and change the
sizes of ram/flash for the 401), with a board that's the same as the
netduino. It has the stm's internal flash and an alias for that flash at
address 0.

arm_cpu_reset does:
        rom = rom_ptr(0);
        if (rom) {
            /* Address zero is covered by ROM which hasn't yet been
             * copied into physical memory.
             */
            initial_msp = ldl_p(rom);
            initial_pc = ldl_p(rom + 4);
        } else {
            /* Address zero not covered by a ROM blob, or the ROM blob
             * is in non-modifiable memory and this is a second reset after
             * it got copied into memory. In the latter case, rom_ptr
             * will return a NULL pointer and we should use ldl_phys instead.
             */
            initial_msp = ldl_phys(s->as, 0);
            initial_pc = ldl_phys(s->as, 4);
        }

I seem to be ending up on the bottom half of this (because of the alias?)
and it ends up loading both 0, even though I can see load_elf has already
been called.
The reset gets called after the realize triggered in the netduino board's
init function; but all that happens before the rom_check_and_register_reset
is called and gets the ROM data in the right place.

In Michael's world he has the extra comment (from 'remove extra cpu_reset'):
+    /* Realizing cpu calls cpu_reset(), which must have rom image
+     * already mapped to find the correct entry point.
+     */

so it sounds like the same problem, even in his world.
(I've hit this both on head and head with Michael's patches from the
start of December applied).

I've bodged around this by adding a call to arm_load_kernel to armv7m_realize
so that the arm reset handler is called and then doing a system_reset
after I get to the hmp; but obviously that's not the fix.
What's the right fix here - is the 'rom_ptr(0)' that arm_cpu_reset
doing sane given that I've got an alias?   Or does the load need
to be delayed?

Dave
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]