[Top][All Lists]

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

Re: [Qemu-devel] Memory on stellaris board

From: Peter Maydell
Subject: Re: [Qemu-devel] Memory on stellaris board
Date: Thu, 10 Mar 2016 06:24:50 +0700

On 10 March 2016 at 03:56, Aurelio Remonda
<address@hidden> wrote:
> On Mon, Mar 7, 2016 at 8:37 PM, Peter Maydell <address@hidden>
> wrote:
>> On 8 March 2016 at 02:58, Aurelio Remonda
>> <address@hidden> wrote:
>> > Hello, sorry for taking so long, I am working on this again.
>> > About your last response, I was looking at the struct
>> > stellaris_board_info
>> > ,which contains
>> > dc0, and this entire struct is const. If we need to calculate dc0 based
>> > on
>> > the provided RAM size
>> > or default value at least the dc0 field should not be const.
>> Yes, certainly.
>> You might also need to look at the magic hex numbers in
>> the stellaris_board[] array -- one is labelled /* dc0 */
>> so might be related.
> Thanks Peter!
> I have a question about the set_memory_options function, when the m flag is
> present, this function takes the size value (or the default_ram_size) and
> perform
> an QEMU_ALIGN_UP. Let's say you want the board default ram_size, the default
> dc0 value should be 0xff00 (65280) when the align is made this value becomes
> 0x00ffff (65535). This align will make the dc0 value change, so I have to
> make some
> operations on ram_size so dc0 will be as exact as it should.
> Something like this:
>     ram_size |= ((ram_size-1)>>8);
>     board->dc0 |= (ram_size & 0xffff)<<16;
> On stellaris_init function
> Then the sram_size and the flash_size are exposed like always. I change the
> magic hex numbers
> in the stellaris_board[] array from 0x00ff007f to 0x0000007f as the
> flash_size
> will not change even with the flag. The default_ram_size is also changed for
> this board to
> be 64K on lm3s6965evb_class_init func:
>    mc->default_ram_size = 0x0000ff00;
> What do you think of this approach? Thank you!

You should reject unworkable ram sizes rather than silently
changing what the user asked for; this matches our preferred
approach where the user asks for more RAM than the board
can support.

-- PMM

reply via email to

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