From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33963) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aeNng-0008KB-IF for qemu-devel@nongnu.org; Fri, 11 Mar 2016 09:12:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aeNnf-0006qK-L1 for qemu-devel@nongnu.org; Fri, 11 Mar 2016 09:12:20 -0500 Received: from mail-vk0-x230.google.com ([2607:f8b0:400c:c05::230]:33266) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aeNnf-0006q4-F9 for qemu-devel@nongnu.org; Fri, 11 Mar 2016 09:12:19 -0500 Received: by mail-vk0-x230.google.com with SMTP id k1so135285129vkb.0 for ; Fri, 11 Mar 2016 06:12:19 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: Date: Fri, 11 Mar 2016 11:12:18 -0300 Message-ID: From: Aurelio Remonda Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 I don't quite understand what you mean with non-round-number, are you sugge= sting 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=3D65280 will become 0xfaf9=3D64249 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 w= rote: > On 10 March 2016 at 07:23, Aurelio Remonda > wrote: >> >> El 9 mar. 2016 8:25 PM, "Peter Maydell" escri= bi=C3=B3: >>> 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 t= hat 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 --=20 Aurelio Remonda Taller Technologies Argentina Software Engineer San Lorenzo 47, 3rd Floor, Office 5 C=C3=B3rdoba, Argentina Phone: +54-351-4217888 / 4218211