qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] Memory on stellaris board
@ 2016-02-03 13:00 Aurelio Remonda
  2016-02-03 13:34 ` Peter Maydell
  0 siblings, 1 reply; 17+ messages in thread
From: Aurelio Remonda @ 2016-02-03 13:00 UTC (permalink / raw)
  To: qemu-devel

Hello, i was trying to understand how does the sram and flash size
works on lm3s6965evb, i found a hardcoded 0x00ff007f as dc0 value and
how flash_size and sram_size are calculated based on that hexadecimal.
I mean this:

flash_size = (((board->dc0 & 0xffff) + 1) << 1) * 1024;
sram_size = ((board->dc0 >> 18) + 1) * 1024;
On stellaris.c

When i use the -m [size] flag while running qemu how does the flag
affect does flash_size and sram_size values? Or it doesn't? Where can
i see that the memory has indeed change?

When i debug qemu with or whitout the flag i keep getting the same
sram_size and flash_size values (the ones calculated with 0x00ff007f)

Thank you!!

-- 
Aurelio Remonda

Software Engineer

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] Memory on stellaris board
  2016-02-03 13:00 [Qemu-devel] Memory on stellaris board Aurelio Remonda
@ 2016-02-03 13:34 ` Peter Maydell
  2016-02-03 13:45   ` Aurelio Remonda
  0 siblings, 1 reply; 17+ messages in thread
From: Peter Maydell @ 2016-02-03 13:34 UTC (permalink / raw)
  To: Aurelio Remonda; +Cc: QEMU Developers

On 3 February 2016 at 13:00, Aurelio Remonda
<aurelio.remonda@tallertechnologies.com> wrote:
> Hello, i was trying to understand how does the sram and flash size
> works on lm3s6965evb, i found a hardcoded 0x00ff007f as dc0 value and
> how flash_size and sram_size are calculated based on that hexadecimal.
> I mean this:
>
> flash_size = (((board->dc0 & 0xffff) + 1) << 1) * 1024;
> sram_size = ((board->dc0 >> 18) + 1) * 1024;
> On stellaris.c
>
> When i use the -m [size] flag while running qemu how does the flag
> affect does flash_size and sram_size values? Or it doesn't? Where can
> i see that the memory has indeed change?

This board model ignores -m. We just implement a model of this particular
bit of hardware, which has a fixed amount of RAM in it.

thanks
-- PMM

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] Memory on stellaris board
  2016-02-03 13:34 ` Peter Maydell
@ 2016-02-03 13:45   ` Aurelio Remonda
  2016-02-05 16:09     ` Aurelio Remonda
  0 siblings, 1 reply; 17+ messages in thread
From: Aurelio Remonda @ 2016-02-03 13:45 UTC (permalink / raw)
  To: Peter Maydell; +Cc: QEMU Developers

On Wed, Feb 3, 2016 at 10:34 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 3 February 2016 at 13:00, Aurelio Remonda
> <aurelio.remonda@tallertechnologies.com> wrote:
>> Hello, i was trying to understand how does the sram and flash size
>> works on lm3s6965evb, i found a hardcoded 0x00ff007f as dc0 value and
>> how flash_size and sram_size are calculated based on that hexadecimal.
>> I mean this:
>>
>> flash_size = (((board->dc0 & 0xffff) + 1) << 1) * 1024;
>> sram_size = ((board->dc0 >> 18) + 1) * 1024;
>> On stellaris.c
>>
>> When i use the -m [size] flag while running qemu how does the flag
>> affect does flash_size and sram_size values? Or it doesn't? Where can
>> i see that the memory has indeed change?
>
> This board model ignores -m. We just implement a model of this particular
> bit of hardware, which has a fixed amount of RAM in it.

Thanks for the quick answer, do you think it is worth to make the m
flag work for this model?
Can you give me a hint on where to look?(another board that use it) so
i can add this feature
for this model.
Thanks!


-- 
Aurelio Remonda

Software Engineer

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] Memory on stellaris board
  2016-02-03 13:45   ` Aurelio Remonda
@ 2016-02-05 16:09     ` Aurelio Remonda
  2016-02-05 16:23       ` Peter Maydell
  0 siblings, 1 reply; 17+ messages in thread
From: Aurelio Remonda @ 2016-02-05 16:09 UTC (permalink / raw)
  To: Peter Maydell; +Cc: QEMU Developers

Hello, im working on this feature right now.
i have a working patch but maybe I can make some changes to make it look better:
for example in some point i check ram_size like this:
if (ram_size == 0x8000000)
Maybe if i make ram_addr_t default_ram_size global (is a local
variable of set_memory_options function)
i can use it instead of hardcoded 0x8000000.
Thanks!

On Wed, Feb 3, 2016 at 10:45 AM, Aurelio Remonda
<aurelio.remonda@tallertechnologies.com> wrote:
> On Wed, Feb 3, 2016 at 10:34 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 3 February 2016 at 13:00, Aurelio Remonda
>> <aurelio.remonda@tallertechnologies.com> wrote:
>>> Hello, i was trying to understand how does the sram and flash size
>>> works on lm3s6965evb, i found a hardcoded 0x00ff007f as dc0 value and
>>> how flash_size and sram_size are calculated based on that hexadecimal.
>>> I mean this:
>>>
>>> flash_size = (((board->dc0 & 0xffff) + 1) << 1) * 1024;
>>> sram_size = ((board->dc0 >> 18) + 1) * 1024;
>>> On stellaris.c
>>>
>>> When i use the -m [size] flag while running qemu how does the flag
>>> affect does flash_size and sram_size values? Or it doesn't? Where can
>>> i see that the memory has indeed change?
>>
>> This board model ignores -m. We just implement a model of this particular
>> bit of hardware, which has a fixed amount of RAM in it.
>
> Thanks for the quick answer, do you think it is worth to make the m
> flag work for this model?
> Can you give me a hint on where to look?(another board that use it) so
> i can add this feature
> for this model.
> Thanks!
>
>
> --
> Aurelio Remonda
>
> Software Engineer
>
> San Lorenzo 47, 3rd Floor, Office 5
> Córdoba, Argentina
> Phone: +54-351-4217888 / 4218211



-- 
Aurelio Remonda

Software Engineer

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] Memory on stellaris board
  2016-02-05 16:09     ` Aurelio Remonda
@ 2016-02-05 16:23       ` Peter Maydell
  2016-02-05 16:55         ` Aurelio Remonda
  0 siblings, 1 reply; 17+ messages in thread
From: Peter Maydell @ 2016-02-05 16:23 UTC (permalink / raw)
  To: Aurelio Remonda; +Cc: QEMU Developers

On 5 February 2016 at 16:09, Aurelio Remonda
<aurelio.remonda@tallertechnologies.com> wrote:
> Hello, im working on this feature right now.
> i have a working patch but maybe I can make some changes to make it look better:
> for example in some point i check ram_size like this:
> if (ram_size == 0x8000000)
> Maybe if i make ram_addr_t default_ram_size global (is a local
> variable of set_memory_options function)
> i can use it instead of hardcoded 0x8000000.

No, don't do that.

Why do you care about whether the ram size is the default or not?

thanks
-- PMM

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] Memory on stellaris board
  2016-02-05 16:23       ` Peter Maydell
@ 2016-02-05 16:55         ` Aurelio Remonda
  2016-02-05 17:00           ` Peter Maydell
  0 siblings, 1 reply; 17+ messages in thread
From: Aurelio Remonda @ 2016-02-05 16:55 UTC (permalink / raw)
  To: Peter Maydell; +Cc: QEMU Developers

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

El 5 feb. 2016 1:24 PM, "Peter Maydell" <peter.maydell@linaro.org> escribió:

> On 5 February 2016 at 16:09, Aurelio Remonda
> <aurelio.remonda@tallertechnologies.com> wrote:
> > Hello, im working on this feature right now.
> > i have a working patch but maybe I can make some changes to make it look
> better:
> > for example in some point i check ram_size like this:
> > if (ram_size == 0x8000000)
> > Maybe if i make ram_addr_t default_ram_size global (is a local
> > variable of set_memory_options function)
> > i can use it instead of hardcoded 0x8000000.
>
> No, don't do that.
>
> Why do you care about whether the ram size is the default or not?
>
> thanks
> -- PMM
>

Im making something like this:

    if (ram_size == 0x8000000)  /* default value, means whitout -m flag */
   {
    sram_size = ((board->dc0 >> 18) + * 1024;
    }
  else if (ram_size >= UINT_MAX) /* more than 4GB */
  sram_size = UINT_MAX;
  else
  sram_size = ram_size

So in case someone does not use the -m flag i want to be sure the ram is

calculated like it was before.

If the flag is indeed used you have a limit given by the size of sram_size
(32 bits)

in that case if you try using the -m option with a size greater than 4GB
you will always get a

4GB (4294967296 to be precise).

[-- Attachment #2: Type: text/html, Size: 1889 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] Memory on stellaris board
  2016-02-05 16:55         ` Aurelio Remonda
@ 2016-02-05 17:00           ` Peter Maydell
  2016-02-11 12:46             ` Aurelio Remonda
  0 siblings, 1 reply; 17+ messages in thread
From: Peter Maydell @ 2016-02-05 17:00 UTC (permalink / raw)
  To: Aurelio Remonda; +Cc: QEMU Developers

On 5 February 2016 at 16:55, Aurelio Remonda
<aurelio.remonda@tallertechnologies.com> wrote:
> Im making something like this:
>
>     if (ram_size == 0x8000000)  /* default value, means whitout -m flag */
>    {
>     sram_size = ((board->dc0 >> 18) + * 1024;
>     }
>   else if (ram_size >= UINT_MAX) /* more than 4GB */
>   sram_size = UINT_MAX;
>   else
>   sram_size = ram_size
>
> So in case someone does not use the -m flag i want to be sure the ram is
> calculated like it was before.

The right way to do this is to set the MachineClass default_ram_size
to what you want your default value to be. Then you should calculate
the dc0 etc values to expose to the guest based on the ram size
(which might be the default or might be user specified).
If the user asks for a value that you can't handle (eg it is too big)
then you should report the problem (via error_report()) and exit.

thanks
-- PMM

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] Memory on stellaris board
  2016-02-05 17:00           ` Peter Maydell
@ 2016-02-11 12:46             ` Aurelio Remonda
  2016-02-11 13:01               ` Peter Maydell
  0 siblings, 1 reply; 17+ messages in thread
From: Aurelio Remonda @ 2016-02-11 12:46 UTC (permalink / raw)
  To: Peter Maydell; +Cc: QEMU Developers

On Fri, Feb 5, 2016 at 2:00 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 5 February 2016 at 16:55, Aurelio Remonda
> <aurelio.remonda@tallertechnologies.com> wrote:
>> Im making something like this:
>>
>>     if (ram_size == 0x8000000)  /* default value, means whitout -m flag */
>>    {
>>     sram_size = ((board->dc0 >> 18) + * 1024;
>>     }
>>   else if (ram_size >= UINT_MAX) /* more than 4GB */
>>   sram_size = UINT_MAX;
>>   else
>>   sram_size = ram_size
>>
>> So in case someone does not use the -m flag i want to be sure the ram is
>> calculated like it was before.
>
> The right way to do this is to set the MachineClass default_ram_size
> to what you want your default value to be. Then you should calculate
> the dc0 etc values to expose to the guest based on the ram size
> (which might be the default or might be user specified).

But stellaris board has a hardcoded dc0 value, when you place the -m flag
with for example 256M you shouldn't calculate any sram_size from dc0, you
just assign that as your ram size.

> If the user asks for a value that you can't handle (eg it is too big)
> then you should report the problem (via error_report()) and exit.

Fair enough.

Thank you!

-- 
Aurelio Remonda

Software Engineer

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] Memory on stellaris board
  2016-02-11 12:46             ` Aurelio Remonda
@ 2016-02-11 13:01               ` Peter Maydell
  2016-03-07 19:58                 ` Aurelio Remonda
  0 siblings, 1 reply; 17+ messages in thread
From: Peter Maydell @ 2016-02-11 13:01 UTC (permalink / raw)
  To: Aurelio Remonda; +Cc: QEMU Developers

On 11 February 2016 at 12:46, Aurelio Remonda
<aurelio.remonda@tallertechnologies.com> wrote:
> On Fri, Feb 5, 2016 at 2:00 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> The right way to do this is to set the MachineClass default_ram_size
>> to what you want your default value to be. Then you should calculate
>> the dc0 etc values to expose to the guest based on the ram size
>> (which might be the default or might be user specified).
>
> But stellaris board has a hardcoded dc0 value, when you place the -m flag
> with for example 256M you shouldn't calculate any sram_size from dc0, you
> just assign that as your ram size.

What I am suggesting is that dc0 should not be hardcoded, but
that you should work out what dc0 to use based on the user
provided RAM size.

thanks
-- PMM

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] Memory on stellaris board
  2016-02-11 13:01               ` Peter Maydell
@ 2016-03-07 19:58                 ` Aurelio Remonda
  2016-03-07 23:37                   ` Peter Maydell
  0 siblings, 1 reply; 17+ messages in thread
From: Aurelio Remonda @ 2016-03-07 19:58 UTC (permalink / raw)
  To: Peter Maydell; +Cc: QEMU Developers

[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]

On Thu, Feb 11, 2016 at 10:01 AM, Peter Maydell <peter.maydell@linaro.org>
wrote:

> On 11 February 2016 at 12:46, Aurelio Remonda
> <aurelio.remonda@tallertechnologies.com> wrote:
> > On Fri, Feb 5, 2016 at 2:00 PM, Peter Maydell <peter.maydell@linaro.org>
> wrote:
> >> The right way to do this is to set the MachineClass default_ram_size
> >> to what you want your default value to be. Then you should calculate
> >> the dc0 etc values to expose to the guest based on the ram size
> >> (which might be the default or might be user specified).
> >
> > But stellaris board has a hardcoded dc0 value, when you place the -m flag
> > with for example 256M you shouldn't calculate any sram_size from dc0, you
> > just assign that as your ram size.
>
> What I am suggesting is that dc0 should not be hardcoded, but
> that you should work out what dc0 to use based on the user
> provided RAM size.
>
> thanks
> -- PMM
>

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.
What do you think?
Thanks

-- 

Aurelio Remonda

Taller Technologies Argentina

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

[-- Attachment #2: Type: text/html, Size: 4317 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] Memory on stellaris board
  2016-03-07 19:58                 ` Aurelio Remonda
@ 2016-03-07 23:37                   ` Peter Maydell
  2016-03-09 20:56                     ` Aurelio Remonda
  0 siblings, 1 reply; 17+ messages in thread
From: Peter Maydell @ 2016-03-07 23:37 UTC (permalink / raw)
  To: Aurelio Remonda; +Cc: QEMU Developers

On 8 March 2016 at 02:58, Aurelio Remonda
<aurelio.remonda@tallertechnologies.com> 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
-- PMM

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] Memory on stellaris board
  2016-03-07 23:37                   ` Peter Maydell
@ 2016-03-09 20:56                     ` Aurelio Remonda
  2016-03-09 23:24                       ` Peter Maydell
  0 siblings, 1 reply; 17+ messages in thread
From: Aurelio Remonda @ 2016-03-09 20:56 UTC (permalink / raw)
  To: Peter Maydell; +Cc: QEMU Developers

[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]

On Mon, Mar 7, 2016 at 8:37 PM, Peter Maydell <peter.maydell@linaro.org>
wrote:
>
> On 8 March 2016 at 02:58, Aurelio Remonda
> <aurelio.remonda@tallertechnologies.com> 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!


-- 

Aurelio Remonda

Taller Technologies Argentina

Software Engineer

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

[-- Attachment #2: Type: text/html, Size: 2495 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] Memory on stellaris board
  2016-03-09 20:56                     ` Aurelio Remonda
@ 2016-03-09 23:24                       ` Peter Maydell
  2016-03-10  0:23                         ` Aurelio Remonda
  0 siblings, 1 reply; 17+ messages in thread
From: Peter Maydell @ 2016-03-09 23:24 UTC (permalink / raw)
  To: Aurelio Remonda; +Cc: QEMU Developers

On 10 March 2016 at 03:56, Aurelio Remonda
<aurelio.remonda@tallertechnologies.com> wrote:
>
>
> On Mon, Mar 7, 2016 at 8:37 PM, Peter Maydell <peter.maydell@linaro.org>
> wrote:
>>
>> On 8 March 2016 at 02:58, Aurelio Remonda
>> <aurelio.remonda@tallertechnologies.com> 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.

thanks
-- PMM

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] Memory on stellaris board
  2016-03-09 23:24                       ` Peter Maydell
@ 2016-03-10  0:23                         ` Aurelio Remonda
  2016-03-10  1:54                           ` Peter Maydell
  0 siblings, 1 reply; 17+ messages in thread
From: Aurelio Remonda @ 2016-03-10  0:23 UTC (permalink / raw)
  To: Peter Maydell; +Cc: QEMU Developers

[-- Attachment #1: Type: text/plain, Size: 2495 bytes --]

El 9 mar. 2016 8:25 PM, "Peter Maydell" <peter.maydell@linaro.org> escribió:
>
> On 10 March 2016 at 03:56, Aurelio Remonda
> <aurelio.remonda@tallertechnologies.com> wrote:
> >
> >
> > On Mon, Mar 7, 2016 at 8:37 PM, Peter Maydell <peter.maydell@linaro.org>
> > wrote:
> >>
> >> On 8 March 2016 at 02:58, Aurelio Remonda
> >> <aurelio.remonda@tallertechnologies.com> 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.

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.

[-- Attachment #2: Type: text/html, Size: 3404 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] Memory on stellaris board
  2016-03-10  0:23                         ` Aurelio Remonda
@ 2016-03-10  1:54                           ` Peter Maydell
  2016-03-11 14:12                             ` Aurelio Remonda
  0 siblings, 1 reply; 17+ messages in thread
From: Peter Maydell @ 2016-03-10  1:54 UTC (permalink / raw)
  To: Aurelio Remonda; +Cc: QEMU Developers

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] Memory on stellaris board
  2016-03-10  1:54                           ` Peter Maydell
@ 2016-03-11 14:12                             ` Aurelio Remonda
  2016-03-11 22:31                               ` Peter Maydell
  0 siblings, 1 reply; 17+ messages in thread
From: Aurelio Remonda @ 2016-03-11 14:12 UTC (permalink / raw)
  To: Peter Maydell; +Cc: QEMU Developers

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Qemu-devel] Memory on stellaris board
  2016-03-11 14:12                             ` Aurelio Remonda
@ 2016-03-11 22:31                               ` Peter Maydell
  0 siblings, 0 replies; 17+ messages in thread
From: Peter Maydell @ 2016-03-11 22:31 UTC (permalink / raw)
  To: Aurelio Remonda; +Cc: QEMU Developers

On 11 March 2016 at 21:12, Aurelio Remonda
<aurelio.remonda@tallertechnologies.com> wrote:
> 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)

What I am suggesting is that we should accept the memory
sizes which correspond to what can be represented in dc0
(which presumably correspond to possible real hardware
configurations) and not any memory sizes which can't be
represented by a dc0 value.

> 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.

I don't know what you mean here, because ram_size is given
to the board code as a value in bytes. The M and K prefix
stuff is just user convenience when they specify values on
the command line.

thanks
-- PMM

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2016-03-11 22:32 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-03 13:00 [Qemu-devel] Memory on stellaris board Aurelio Remonda
2016-02-03 13:34 ` Peter Maydell
2016-02-03 13:45   ` Aurelio Remonda
2016-02-05 16:09     ` Aurelio Remonda
2016-02-05 16:23       ` Peter Maydell
2016-02-05 16:55         ` Aurelio Remonda
2016-02-05 17:00           ` Peter Maydell
2016-02-11 12:46             ` Aurelio Remonda
2016-02-11 13:01               ` Peter Maydell
2016-03-07 19:58                 ` Aurelio Remonda
2016-03-07 23:37                   ` Peter Maydell
2016-03-09 20:56                     ` Aurelio Remonda
2016-03-09 23:24                       ` Peter Maydell
2016-03-10  0:23                         ` Aurelio Remonda
2016-03-10  1:54                           ` Peter Maydell
2016-03-11 14:12                             ` Aurelio Remonda
2016-03-11 22:31                               ` Peter Maydell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).