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. Regards, Peter > Re sending now. > > Thanks, > > Alistair > >> >> thanks >> -- PMM >>