From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Simek Date: Mon, 7 Sep 2020 10:27:34 +0200 Subject: [PATCH 1/2] spl: Use standard FIT entries In-Reply-To: References: <9f4859ccaf3f75d68325fd8918dea0c1149e6dbc.1599130989.git.michal.simek@xilinx.com> Message-ID: <97da80b5-45f9-1cc9-493d-48bbcb8695ae@xilinx.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Simon, On 07. 09. 20 3:43, Simon Glass wrote: > Hi Michal, > > On Thu, 3 Sep 2020 at 05:03, Michal Simek wrote: >> >> SPL is creating fit-images DT node when loadables are recorded in selected >> configuration. Entries which are created are using entry-point and >> load-addr property names. But there shouldn't be a need to use non standard >> properties because entry/load are standard FIT properties. But using >> standard FIT properties enables option to use generic FIT functions to >> descrease SPL size. Here is result for ZynqMP virt configuration: >> xilinx_zynqmp_virt: spl/u-boot-spl:all -82 spl/u-boot-spl:rodata -22 spl/u-boot-spl:text -60 >> >> The patch causes change in run time fit image record. >> Before: >> fit-images { >> uboot { >> os = "u-boot"; >> type = "firmware"; >> size = <0xfd520>; >> entry-point = <0x8000000>; >> load-addr = <0x8000000>; >> }; >> }; >> >> After: >> fit-images { >> uboot { >> os = "u-boot"; >> type = "firmware"; >> size = <0xfd520>; >> entry = <0x8000000>; >> load = <0x8000000>; >> }; >> }; >> >> Replacing calling fdt_getprop_u32() by fit_image_get_entry/load() also >> enables support for reading entry/load properties recorded in 64bit format. >> >> Signed-off-by: Michal Simek >> --- > > Reviewed-by: Simon Glass > > Isn't there a test that could be updated here? Are we testing SPL flow? > >> >> Would be good to know history of fit-images and it's property names but >> there shouldn't be a need to use non standard names where we have >> FIT_*_PROP recorded as macros in include/image.h. > > I agree. > >> Concern regarding backward compatibility is definitely valid but not sure >> how many systems can be affected by this change. > > Me neither. Probably a good idea to fix it. Fix means keep existing code with warning and add new one next to it. M