[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v5 2/5] hw/arm/digic: prepare DIGIC-based boards s
From: |
Peter Crosthwaite |
Subject: |
Re: [Qemu-devel] [RFC v5 2/5] hw/arm/digic: prepare DIGIC-based boards support |
Date: |
Thu, 5 Dec 2013 10:25:48 +1000 |
On Thu, Dec 5, 2013 at 7:20 AM, Antony Pavlov <address@hidden> wrote:
> On Wed, 4 Dec 2013 20:29:05 +0000
> Peter Maydell <address@hidden> wrote:
>
>> On 4 December 2013 20:22, Antony Pavlov <address@hidden> wrote:
>> > Here is my proposition:
>> >
>> > 1. qemu board code setup CPU to start from 0xFFFF0000. (0xffff0000 is a
>> > ROM address
>> > on DIGIC chips)
>>
>> Sort of. What we need is:
>> 1a. Add a "hivecs" property to the ARM CPU object (which
>> just sets env->cp15.c1_sys bit 13)
>>
>> (this is about half a dozen lines of code max)
>>
>> 1b DIGIC board init code creates the CPU and sets the hivecs property on it
>>
>> (another handful of lines of code)
>
> Ok, I'll try to make the work at the weekend.
>
>> > 2. we need somehow put a 'jump-to-beginning-of-ROM' instruction to
>> > 0xffff0000.
>> > (We can't put barebox to 0xffff0000 as barebox image is bigger that 64K.)
>> >
>> > There is at least two possibilities to do so:
>> > * we can use specially prepared ROM image;
>> > * qemu board code can insert by itself a 'jump-to-beginning-of-ROM'
>> > instruction
>> > after loading ROM image (as qemu MIPS Malta board code does).
>>
>> The board code should definitely not be writing random instructions into
>> memory. You need to provide a ROM image which will do the work.
>>
But the bootloader does this already. We have support for board
configurable secondary bootloops. Is this as simple as supporting
board configurable primary boot fragments?
arm_boot needs to be patched to do its bootstrap magic with no -kernel
arg I guess. I have something of that nature in my own tree, where I
have a command line argument that forces arm-boot to use the linux
bootstrap stuff (primary and secondary bootloops and all that)
regardless of image type.
Regards,
Peter
>> > 3. CPU starts as usual. Branching to barebox code in ROM happends in a
>> > natural way!
>>
>> This bit's OK :-)
>>
>> thanks
>> -- PMM
>
>
> --
> --
> Best regards,
> Antony Pavlov
>
[Qemu-devel] [RFC 0/2] ARM: make possible to use high vectors for reset exception, Antony Pavlov, 2013/12/06
Re: [Qemu-devel] [RFC 1/2] ARM: cpu: add "hivecs" property (high vectors on reset), Peter Maydell, 2013/12/06
[Qemu-devel] [RFC 2/2] ARM: arm_cpu_reset: make possible to use high vectors for reset_exc, Antony Pavlov, 2013/12/06
Re: [Qemu-devel] [RFC 2/2] ARM: arm_cpu_reset: make possible to use high vectors for reset_exc, Peter Crosthwaite, 2013/12/06
Re: [Qemu-devel] [RFC 2/2] ARM: arm_cpu_reset: make possible to use high vectors for reset_exc, Antony Pavlov, 2013/12/07