Re: [Qemu-devel] Memory on stellaris board

[Aurelio Remonda]

El 9 mar. 2016 8:25 PM, "Peter Maydell" <address@hidden> escribió:
>
> 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.

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.