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.mayd...@linaro.org> wrote: > On 10 March 2016 at 07:23, Aurelio Remonda > <aurelio.remo...@tallertechnologies.com> wrote: >> >> El 9 mar. 2016 8:25 PM, "Peter Maydell" <peter.mayd...@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
