On Tue, Jan 12, 2016 at 1:01 AM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 12 January 2016 at 00:24, Alistair Francis > <alistair.fran...@xilinx.com> wrote: >> On Mon, Jan 11, 2016 at 8:04 AM, Peter Maydell <peter.mayd...@linaro.org> >> wrote: >>> There are a couple of problems you're running into: >>> >>> (1) machine->ram_size is a ram_addr_t so might be 32 bit; you >>> can do what virt.c does to avoid the warning and use a local >>> uin64_t variable for the comparison >> >> Ok, I now create a uint64_t variable to store the value. >> >>> >>> (2) complaint about reassigning back to ram_size. this is spurious >>> but you can avoid it by making this board behave the same way as >>> virt.c, vexpress.c etc do if presented with an unsupported >>> ram_size -- you should fail, rather than truncating and continuing. >> >> If I'm using a 64-bit variable to store the value won't this no longer >> be a problem? > > I think you should do the same thing the other boards do anyway.
Ok, I have changed it to exit instead of resize. > >>> (3) %llx is not the correct format string for a ram_addr_t: >>> use RAM_ADDR_FMT. (This isn't making the compiler complain, >>> but I noticed it looking at the code.) >> >> Again, isn't this fixed by changing to a variable? > > %llx isn't right for uint64_t either :-) I still have a %llx for the macro as it isn't a ram_addr_t. Re sending now. Thanks, Alistair > > thanks > -- PMM >
