[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] armv7m/stm32f205 not starting if code linked from 0x080
From: |
Liviu Ionescu |
Subject: |
Re: [Qemu-devel] armv7m/stm32f205 not starting if code linked from 0x08000000 |
Date: |
Mon, 8 Jun 2015 21:12:23 +0300 |
> On 08 Jun 2015, at 20:43, Peter Maydell <address@hidden> wrote:
>
> ... Unfortunately the test we're doing to decide is calling rom_ptr(),
> which only looks at the addresses the ROMs are registered to
> be copied into; it doesn't know about aliasing.
I guessed so.
> If you fudge the if() statement to use 0x08000000 rather
> than 0 as the address passed to rom_ptr() it will probably
> work.
I tried the following:
rom = 0x08000000; //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);
unfortunately it crashes with a segmentation fault a bit later.
> I'm not sure what the correct fix for this is, though.
the actual configuration is:
- a flash region is created at 0
- an alias region is create somewhere else (at 0x08000000 for stm32, different
for other vendors)
- the application image can be linked either at 0, or at the aliased address,
and there is no way to enforce one of them
- the application image is loaded by the famous ELF loader either at 0 or at
the aliased address, both cases are equally possible, and as such both must be
supported
- the reset code tries to fetch the two pointers (msp & pc) from 0 and 4, but
the content might not be at zero, but in the aliased region, and both cases
must be supported.
> ... two-phase reset ... the CPU *comes out* of reset,
> ... the reset function is the best we
> can do, and you end up with this ugly hack.
yes, I guess I understand what you mean, but in this case I don't think the
problem is that theoretical, it is just an implementation issue, the original
arm reset code was not written with aliased regions in mind.
I don't say it is simple, because I don't know enough details on how memory
regions and aliases are implemented, but I guess that someone that has more
qemu experience than I do can find a nice solution.
regards,
Liviu
- [Qemu-devel] armv7m/stm32f205 not starting if code linked from 0x08000000, Liviu Ionescu, 2015/06/08
- Re: [Qemu-devel] armv7m/stm32f205 not starting if code linked from 0x08000000, Peter Maydell, 2015/06/08
- Re: [Qemu-devel] armv7m/stm32f205 not starting if code linked from 0x08000000,
Liviu Ionescu <=
- Re: [Qemu-devel] armv7m/stm32f205 not starting if code linked from 0x08000000, Peter Maydell, 2015/06/08
- Re: [Qemu-devel] armv7m/stm32f205 not starting if code linked from 0x08000000, Liviu Ionescu, 2015/06/08
- Re: [Qemu-devel] armv7m/stm32f205 not starting if code linked from 0x08000000, Peter Maydell, 2015/06/08
- Re: [Qemu-devel] armv7m/stm32f205 not starting if code linked from 0x08000000, Liviu Ionescu, 2015/06/08
- Re: [Qemu-devel] armv7m/stm32f205 not starting if code linked from 0x08000000, Peter Maydell, 2015/06/08
- Re: [Qemu-devel] armv7m/stm32f205 not starting if code linked from 0x08000000, Liviu Ionescu, 2015/06/08
- Re: [Qemu-devel] armv7m/stm32f205 not starting if code linked from 0x08000000, Peter Maydell, 2015/06/08
- Re: [Qemu-devel] armv7m/stm32f205 not starting if code linked from 0x08000000, Liviu Ionescu, 2015/06/08
- Re: [Qemu-devel] armv7m/stm32f205 not starting if code linked from 0x08000000, Peter Maydell, 2015/06/08
- Re: [Qemu-devel] armv7m/stm32f205 not starting if code linked from 0x08000000, Liviu Ionescu, 2015/06/08