On 16 October 2015 at 21:35, Ilya Lipnitskiy <ilya.lipnits...@gmail.com> wrote: > On Fri, Oct 16, 2015 at 11:09 AM, Peter Maydell > <peter.mayd...@linaro.org> wrote: > >> You might find it helpful to turn on QEMU's debug logging >> (see the -d and -D options). Chances are that some insn >> in your new code is faulting (probably UNDEFing). > I think have figured it out, looks like my code was doing two bad things: > 1. Trying to save registers to a nonexistent stack ($sp == 0 when > stmia is called) > 2. Clobbering r4 that is used globally throughout head.S > > Removing the stmia/ldmia, and using r7 instead of r4 appears to have > resolved the issue. > > It is a mystery how this code has been working on actual hardware, and > why reverting SHA 6ec1588e097 somehow made QEMU work. Any clues why?
I have a feeling that if you take an exception in early boot and there is RAM at address 0 then you'll effectively just reenter the kernel again from its lowest address (since there's nothing in the vector tables yet), which means that if you're lucky and the second time around things work you might not notice. If there's no RAM at 0 then you go into an infinite series of exceptions. Alternatively, the trashing of some important register might have not been noticed if that register's value should have been 0 anyway (eg if it was related to the base address of RAM). You can probably figure out what happened by looking at the debug tracing of execution in the situation where there is RAM at 0 in QEMU. thanks -- PMM
