From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56655) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adoOX-0000yY-N1 for qemu-devel@nongnu.org; Wed, 09 Mar 2016 19:24:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adoOW-0003LH-B5 for qemu-devel@nongnu.org; Wed, 09 Mar 2016 19:24:01 -0500 Received: from mail-vk0-x235.google.com ([2607:f8b0:400c:c05::235]:35432) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adoOW-0003LB-3t for qemu-devel@nongnu.org; Wed, 09 Mar 2016 19:24:00 -0500 Received: by mail-vk0-x235.google.com with SMTP id e6so76869364vkh.2 for ; Wed, 09 Mar 2016 16:23:59 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 9 Mar 2016 21:23:59 -0300 Message-ID: From: Aurelio Remonda Content-Type: multipart/alternative; boundary=001a11425b64ab71d5052da6d409 Subject: Re: [Qemu-devel] Memory on stellaris board List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers --001a11425b64ab71d5052da6d409 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El 9 mar. 2016 8:25 PM, "Peter Maydell" escribi= =C3=B3: > > On 10 March 2016 at 03:56, Aurelio Remonda > wrote: > > > > > > On Mon, Mar 7, 2016 at 8:37 PM, Peter Maydell > > wrote: > >> > >> On 8 March 2016 at 02:58, Aurelio Remonda > >> 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 |=3D ((ram_size-1)>>8); > > board->dc0 |=3D (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 =3D 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=C3=A1ximum? 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. --001a11425b64ab71d5052da6d409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


El 9 mar. 2016 8:25 PM, "Peter Maydell" <peter.maydell@linaro.org> escribi=C3=B3:
>
> 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 ag= ain.
> >> > 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 calc= ulate dc0 based
> >> > on
> >> > the provided RAM size
> >> > or default value at least the dc0 field should not be co= nst.
> >>
> >> 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_s= ize) and
> > perform
> > an QEMU_ALIGN_UP. Let's say you want the board default ram_si= ze, the default
> > dc0 value should be 0xff00 (65280) when the align is made this va= lue 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:
> >=C2=A0 =C2=A0 =C2=A0ram_size |=3D ((ram_size-1)>>8);
> >=C2=A0 =C2=A0 =C2=A0board->dc0 |=3D (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 t= he
> > 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:
> >=C2=A0 =C2=A0 mc->default_ram_size =3D 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=C3=A1ximum? 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()) an= d exit.

--001a11425b64ab71d5052da6d409--