On Sat, Oct 1, 2016 at 1:47 AM, Manjukumar Harthikote Matha <[email protected]> wrote: > > >> -----Original Message----- >> From: Mike Looijmans [mailto:[email protected]] >> Sent: Friday, September 30, 2016 12:32 AM >> To: Nathan Rossi >> Cc: Manjukumar Harthikote Matha; [email protected] >> Subject: Re: [meta-xilinx] [PATCH] arm-trusted-firmware: Use constants for >> memory >> addresses >> >> On 29-09-16 16:22, Nathan Rossi wrote: >> > On Thu, Sep 29, 2016 at 7:46 PM, Mike Looijmans <[email protected]> >> wrote: >> >> On 28-09-16 17:20, Nathan Rossi wrote: >> >>> >> >>> On Wed, Sep 28, 2016 at 10:50 AM, Manjukumar Harthikote Matha >> >>> <[email protected]> wrote: >> >>>> >> >>>> Hi Mike, >> >>>> >> >>>> <.....> >> >>>>>>> >> >>>>>>> LD[unexport] = "1" >> >>>>>>> >> >>>>>>> +ZYNQMP_ATF_MEM_BASE = "0xfffe5000" >> >>>>>>> +ZYNQMP_ATF_MEM_SIZE = "0x16000" >> >>>>>> >> >>>>>> Maybe reading the load address from elf might help. I think MEM_BASE >> >>>>>> address might change going forward. >> >>>>>> >> >>>>>> For example: >> >>>>>> https://github.com/Xilinx/arm-trusted- >> firmware/commit/eb4fa652d424b895 >> >>>>>> 7a927c6137e2ae3652b0b1bb >> >>>>>> >> >>>>> >> >>>>> This patch was to accommodate that. The current version will load it at >> >>>>> the wrong >> >>>>> location. >> >>>>> >> >>>> I am looking to see if we can read from the generated elf and populate >> >>>> the MEM_BASE and MEM_SIZE >> >>>> With the current patch, I think it will be maintenance burden every >> >>>> release, trying to mitigate it if possible. >> >>> >> >>> >> >>> The generated bl31.elf is populated with the correct entry point address: >> >>> Entry point address: 0xfffe5000 >> >>> >> >>> Which is pointing to bl31_entrypoint, >> >>> >> >>> https://github.com/Xilinx/arm-trusted- >> firmware/blob/eb4fa652d424b8957a927c6137e2ae3652b0b1bb/bl31/bl31.ld.S#L35 >> >>> >> >>> Which could be used as an alternate source of the address: >> >>> 625: 00000000fffe5000 212 FUNC GLOBAL DEFAULT 1 >> >>> bl31_entrypoint >> >>> >> >>> My only query is whether the ZYNQ_ATF_MEM_* variables make sense as >> >>> overrides? Essentially if there is a potential use case when bl31 >> >>> needs to be built to execute in an older/newer environment that >> >>> differs from the default values (of the current version used)? >> >>> >> >> >> >> What I really wanted is the opposite, get the address from the binary. >> >> That >> >> would solve the "magic number" that you have to put in the recipe. I >> >> couldn't find a way to do that, so I did the opposite, make sure that both >> >> code and recipe share the same magic number. >> >> >> >> I had no intention of making this "configurable" or so, I just wanted it >> >> consistent. >> >> >> >> >> > >> > That makes it simpler then :). I have a sent a patch that does the >> > dynamic reading from the elf to solve this. If you could please give >> > it a test and let me know that it works as you expect. >> >> Looks fine, and a lot better than what I came up with. Probably won't be able >> to test today though.
Did you manage to get around to giving it a test Mike? Would like to have some confirmation that it works in a functional environment before I merge it :). >> > > > Whats the patch, is it on mailing list? Sorry didn't see your query. The patch is here: https://lists.yoctoproject.org/pipermail/meta-xilinx/2016-September/002083.html And staged here at the moment: https://github.com/nathanrossi/meta-xilinx/commit/e3b2e6e6102ad8c2f88cd90788ca6c9de6597b5b Regards, Nathan > > Thanks > Manju > > > This email and any attachments are intended for the sole use of the named > recipient(s) and contain(s) confidential information that may be proprietary, > privileged or copyrighted under applicable law. If you are not the intended > recipient, do not read, copy, or forward this email message or any > attachments. Delete this email message and any attachments immediately. > -- _______________________________________________ meta-xilinx mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
