On Tue, Jan 12, 2016 at 2:00 PM, Peter Crosthwaite <crosthwaitepe...@gmail.com> wrote: > On Tue, Jan 12, 2016 at 1:59 PM, Alistair Francis > <alistair.fran...@xilinx.com> wrote: >> 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. >> > > Should be PRIx64 though.
Then I get a compiler warning as the macro is a long long unsigned int. Thanks, Alistair > > Regards, > Peter > >> Re sending now. >> >> Thanks, >> >> Alistair >> >>> >>> thanks >>> -- PMM >>> >