Re: [Qemu-devel] Memory on stellaris board

[Aurelio Remonda <aurelio.remonda@tallertechnologies.com>]

I don't quite understand what you mean with non-round-number, are you suggesting
we only accept for example:
64K-128K-256K-512K-1024k(or 1M)-2048K(or 2M)
4096K(or 4M)-8192K(or 8M)-16384K(or 16M)
If that's the case we will never have, for example, the exact default
dc0 value (0x00ff007f)
because you need to divide the given size by 1024 reverting what the
prefix (K or M) have
done and then multiply this value by 1000.

So in the case of the default value 0xff00=65280 will become
0xfaf9=64249 and goes
directly to dc0. Then the sram_size would be just ram_size and not a
value calculated
based on dc0.

Again the problem of this es that you will never get the manual
default dc0 value even if
you run the program without the -m flag.

Thanks


On Wed, Mar 9, 2016 at 10:54 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 10 March 2016 at 07:23, Aurelio Remonda
> <aurelio.remonda@tallertechnologies.com> wrote:
>>
>> El 9 mar. 2016 8:25 PM, "Peter Maydell" <peter.maydell@linaro.org> escribió:
>>> 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.
>>
>> With unworkable you mean RAM values over dc0 máximum? I make sure that it
>> does not exceed 0xffff before i replace the dc0 value so if it goes over 16M
>> the program report the problem (via error_report()) and exit.
>
> Also if the user asks for a non-round-number ram size:
> don't round ram_size up or down, just fail if the user asked
> for something that's not representable in a dc0 value.
>
> thanks
> -- PMM



-- 
Aurelio Remonda

Taller Technologies Argentina

Software Engineer

San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: +54-351-4217888 / 4218211