[U-Boot] [PATCH v2] SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode

[U-Boot] [PATCH v2] SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode

[Michal Simek]

Support loading FIT in SPL for RAM bootmode.
CONFIG_SPL_LOAD_FIT_ADRESS points to address where FIT image is stored
in memory.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---

Changes in v2:
- Fix empty line
- Fix addr name and remove SPL_LOAD_FIT macro

 common/spl/spl.c | 45 ++++++++++++++++++++++++++++++++++++---------
 1 file changed, 36 insertions(+), 9 deletions(-)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index 0fc5b058be31..3faa751e4b43 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -136,20 +136,47 @@ __weak void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
 	image_entry();
 }
 
+#ifndef CONFIG_SPL_LOAD_FIT_ADDRESS
+# define CONFIG_SPL_LOAD_FIT_ADDRESS	0
+#endif
+
 #ifdef CONFIG_SPL_RAM_DEVICE
+static ulong spl_ram_load_read(struct spl_load_info *load, ulong sector,
+			       ulong count, void *buf)
+{
+	debug("%s: sector %lx, count %lx, buf %lx\n",
+	      __func__, sector, count, (ulong)buf);
+	memcpy(buf, (void *)(CONFIG_SPL_LOAD_FIT_ADDRESS + sector), count);
+	return count;
+}
+
 static int spl_ram_load_image(void)
 {
-	const struct image_header *header;
+	struct image_header *header;
 
-	/*
-	 * Get the header.  It will point to an address defined by handoff
-	 * which will tell where the image located inside the flash. For
-	 * now, it will temporary fixed to address pointed by U-Boot.
-	 */
-	header = (struct image_header *)
-		(CONFIG_SYS_TEXT_BASE -	sizeof(struct image_header));
+	header = (struct image_header *)CONFIG_SPL_LOAD_FIT_ADDRESS;
 
-	spl_parse_image_header(header);
+	if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
+	    image_get_magic(header) == FDT_MAGIC) {
+		struct spl_load_info load;
+
+		debug("Found FIT\n");
+		load.bl_len = 1;
+		load.read = spl_ram_load_read;
+		spl_load_simple_fit(&load, 0, header);
+	} else {
+		debug("Legacy image\n");
+		/*
+		 * Get the header.  It will point to an address defined by
+		 * handoff which will tell where the image located inside
+		 * the flash. For now, it will temporary fixed to address
+		 * pointed by U-Boot.
+		 */
+		header = (struct image_header *)
+			(CONFIG_SYS_TEXT_BASE -	sizeof(struct image_header));
+
+		spl_parse_image_header(header);
+	}
 
 	return 0;
 }
-- 
1.9.1

[U-Boot] [PATCH v2] SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode

[Lokesh Vutla]

On 5/17/2016 10:30 PM, Michal Simek wrote:
> Support loading FIT in SPL for RAM bootmode.
> CONFIG_SPL_LOAD_FIT_ADRESS points to address where FIT image is stored
> in memory.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2:
> - Fix empty line
> - Fix addr name and remove SPL_LOAD_FIT macro
>
>   common/spl/spl.c | 45 ++++++++++++++++++++++++++++++++++++---------
>   1 file changed, 36 insertions(+), 9 deletions(-)
>
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index 0fc5b058be31..3faa751e4b43 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -136,20 +136,47 @@ __weak void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
>   	image_entry();
>   }
>
> +#ifndef CONFIG_SPL_LOAD_FIT_ADDRESS
> +# define CONFIG_SPL_LOAD_FIT_ADDRESS	0
> +#endif
> +

May be a good idea to default this to CONFIG_SYS_TEXT_BASE instead of 0?

Other than that patch looks good to me.
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

Thanks and regards,
Lokesh

>   #ifdef CONFIG_SPL_RAM_DEVICE
> +static ulong spl_ram_load_read(struct spl_load_info *load, ulong sector,
> +			       ulong count, void *buf)
> +{
> +	debug("%s: sector %lx, count %lx, buf %lx\n",
> +	      __func__, sector, count, (ulong)buf);
> +	memcpy(buf, (void *)(CONFIG_SPL_LOAD_FIT_ADDRESS + sector), count);
> +	return count;
> +}
> +
>   static int spl_ram_load_image(void)
>   {
> -	const struct image_header *header;
> +	struct image_header *header;
>
> -	/*
> -	 * Get the header.  It will point to an address defined by handoff
> -	 * which will tell where the image located inside the flash. For
> -	 * now, it will temporary fixed to address pointed by U-Boot.
> -	 */
> -	header = (struct image_header *)
> -		(CONFIG_SYS_TEXT_BASE -	sizeof(struct image_header));
> +	header = (struct image_header *)CONFIG_SPL_LOAD_FIT_ADDRESS;
>
> -	spl_parse_image_header(header);
> +	if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
> +	    image_get_magic(header) == FDT_MAGIC) {
> +		struct spl_load_info load;
> +
> +		debug("Found FIT\n");
> +		load.bl_len = 1;
> +		load.read = spl_ram_load_read;
> +		spl_load_simple_fit(&load, 0, header);
> +	} else {
> +		debug("Legacy image\n");
> +		/*
> +		 * Get the header.  It will point to an address defined by
> +		 * handoff which will tell where the image located inside
> +		 * the flash. For now, it will temporary fixed to address
> +		 * pointed by U-Boot.
> +		 */
> +		header = (struct image_header *)
> +			(CONFIG_SYS_TEXT_BASE -	sizeof(struct image_header));
> +
> +		spl_parse_image_header(header);
> +	}
>
>   	return 0;
>   }
>

[U-Boot] [PATCH v2] SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode

[Michal Simek]

On 18.5.2016 17:12, Lokesh Vutla wrote:
> 
> 
> On 5/17/2016 10:30 PM, Michal Simek wrote:
>> Support loading FIT in SPL for RAM bootmode.
>> CONFIG_SPL_LOAD_FIT_ADRESS points to address where FIT image is stored
>> in memory.
>>
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>> Reviewed-by: Simon Glass <sjg@chromium.org>
>> ---
>>
>> Changes in v2:
>> - Fix empty line
>> - Fix addr name and remove SPL_LOAD_FIT macro
>>
>>   common/spl/spl.c | 45 ++++++++++++++++++++++++++++++++++++---------
>>   1 file changed, 36 insertions(+), 9 deletions(-)
>>
>> diff --git a/common/spl/spl.c b/common/spl/spl.c
>> index 0fc5b058be31..3faa751e4b43 100644
>> --- a/common/spl/spl.c
>> +++ b/common/spl/spl.c
>> @@ -136,20 +136,47 @@ __weak void __noreturn
>> jump_to_image_no_args(struct spl_image_info *spl_image)
>>       image_entry();
>>   }
>>
>> +#ifndef CONFIG_SPL_LOAD_FIT_ADDRESS
>> +# define CONFIG_SPL_LOAD_FIT_ADDRESS    0
>> +#endif
>> +
> 
> May be a good idea to default this to CONFIG_SYS_TEXT_BASE instead of 0?

The problem is that if u-boot is in FIT that it will be loaded to
TEXT_BASE address.
Maybe easier to just don't define any value which end up in compilation
error.

Thanks,
Michal

[U-Boot] [PATCH v2] SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode

[Lokesh Vutla]

On 5/18/2016 8:52 PM, Michal Simek wrote:
> On 18.5.2016 17:12, Lokesh Vutla wrote:
>>
>>
>> On 5/17/2016 10:30 PM, Michal Simek wrote:
>>> Support loading FIT in SPL for RAM bootmode.
>>> CONFIG_SPL_LOAD_FIT_ADRESS points to address where FIT image is stored
>>> in memory.
>>>
>>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>>> Reviewed-by: Simon Glass <sjg@chromium.org>
>>> ---
>>>
>>> Changes in v2:
>>> - Fix empty line
>>> - Fix addr name and remove SPL_LOAD_FIT macro
>>>
>>>    common/spl/spl.c | 45 ++++++++++++++++++++++++++++++++++++---------
>>>    1 file changed, 36 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/common/spl/spl.c b/common/spl/spl.c
>>> index 0fc5b058be31..3faa751e4b43 100644
>>> --- a/common/spl/spl.c
>>> +++ b/common/spl/spl.c
>>> @@ -136,20 +136,47 @@ __weak void __noreturn
>>> jump_to_image_no_args(struct spl_image_info *spl_image)
>>>        image_entry();
>>>    }
>>>
>>> +#ifndef CONFIG_SPL_LOAD_FIT_ADDRESS
>>> +# define CONFIG_SPL_LOAD_FIT_ADDRESS    0
>>> +#endif
>>> +
>>
>> May be a good idea to default this to CONFIG_SYS_TEXT_BASE instead of 0?
>
> The problem is that if u-boot is in FIT that it will be loaded to
> TEXT_BASE address.
> Maybe easier to just don't define any value which end up in compilation
> error.

Yeah, you were right. Initially I was thinking there won't be a problem
overriding the data. You can leave it as is.

Thanks and regards,
Lokesh

>
> Thanks,
> Michal
>

[U-Boot] [PATCH v2] SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode

[Andreas Dannenberg]

On Tue, May 17, 2016 at 07:00:24PM +0200, Michal Simek wrote:
> Support loading FIT in SPL for RAM bootmode.
> CONFIG_SPL_LOAD_FIT_ADRESS points to address where FIT image is stored
> in memory.
> 
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> ---

Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>


That's a very useful addition to the SPL FIT toolbox! I have a use case
where I may need to decrypt/authenticate an SPL FIT image in its entirety
before processing it so this can be used for this as well.


--
Andreas Dannenberg
Texas Instruments Inc

[U-Boot] [PATCH v2] SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode

[Michal Simek]

On 19.5.2016 18:15, Andreas Dannenberg wrote:
> On Tue, May 17, 2016 at 07:00:24PM +0200, Michal Simek wrote:
>> Support loading FIT in SPL for RAM bootmode.
>> CONFIG_SPL_LOAD_FIT_ADRESS points to address where FIT image is stored
>> in memory.
>>
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>> Reviewed-by: Simon Glass <sjg@chromium.org>
>> ---
> 
> Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>
> 
> 
> That's a very useful addition to the SPL FIT toolbox! I have a use case
> where I may need to decrypt/authenticate an SPL FIT image in its entirety
> before processing it so this can be used for this as well.

Do you have also use case where you need to load more files from FIT?
There is loadable entry in FIT config entry.

Thanks,
Michal

[U-Boot] [PATCH v2] SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode

[Andreas Dannenberg]

Hi Michal,

On Thu, May 19, 2016 at 06:38:04PM +0200, Michal Simek wrote:
> On 19.5.2016 18:15, Andreas Dannenberg wrote:
> > On Tue, May 17, 2016 at 07:00:24PM +0200, Michal Simek wrote:
> >> Support loading FIT in SPL for RAM bootmode.
> >> CONFIG_SPL_LOAD_FIT_ADRESS points to address where FIT image is stored
> >> in memory.
> >>
> >> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> >> Reviewed-by: Simon Glass <sjg@chromium.org>
> >> ---
> > 
> > Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>
> > 
> > 
> > That's a very useful addition to the SPL FIT toolbox! I have a use case
> > where I may need to decrypt/authenticate an SPL FIT image in its entirety
> > before processing it so this can be used for this as well.
> 
> Do you have also use case where you need to load more files from FIT?
> There is loadable entry in FIT config entry.

Not yet but I may get there. I'm experimenting with using U-Boot to load
and install a secure monitor mode application (specifically, OP-TEE OS),
so that will need to come from somewhere eventually and FIT would be a
natural place for that binary to reside since we can easily authenticate
it.

Thanks and Regards,
Andreas
 

[U-Boot] [PATCH v2] SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode

[Michal Simek]

Hi Andreas,

2016-05-19 20:16 GMT+02:00 Andreas Dannenberg <dannenberg@ti.com>:

> Hi Michal,
>
> On Thu, May 19, 2016 at 06:38:04PM +0200, Michal Simek wrote:
> > On 19.5.2016 18:15, Andreas Dannenberg wrote:
> > > On Tue, May 17, 2016 at 07:00:24PM +0200, Michal Simek wrote:
> > >> Support loading FIT in SPL for RAM bootmode.
> > >> CONFIG_SPL_LOAD_FIT_ADRESS points to address where FIT image is stored
> > >> in memory.
> > >>
> > >> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> > >> Reviewed-by: Simon Glass <sjg@chromium.org>
> > >> ---
> > >
> > > Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>
> > >
> > >
> > > That's a very useful addition to the SPL FIT toolbox! I have a use case
> > > where I may need to decrypt/authenticate an SPL FIT image in its
> entirety
> > > before processing it so this can be used for this as well.
> >
> > Do you have also use case where you need to load more files from FIT?
> > There is loadable entry in FIT config entry.
>
> Not yet but I may get there. I'm experimenting with using U-Boot to load
> and install a secure monitor mode application (specifically, OP-TEE OS),
> so that will need to come from somewhere eventually and FIT would be a
> natural place for that binary to reside since we can easily authenticate
> it.


ok what arch?
What's the flow which you want to support?
SPL to load OPTEE and ATF and full u-boot and jump to ATF which runs OPTEE
and run to U-Boot?

Thanks,
Michal

[U-Boot] [PATCH v2] SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode

[Andreas Dannenberg]

Hi Michael,

On Thu, May 19, 2016 at 08:33:28PM +0200, Michal Simek wrote:
> Hi Andreas,
> 
> 2016-05-19 20:16 GMT+02:00 Andreas Dannenberg <dannenberg@ti.com>:
> 
> > Hi Michal,
> >
> > On Thu, May 19, 2016 at 06:38:04PM +0200, Michal Simek wrote:
> > > On 19.5.2016 18:15, Andreas Dannenberg wrote:
> > > > On Tue, May 17, 2016 at 07:00:24PM +0200, Michal Simek wrote:
> > > >> Support loading FIT in SPL for RAM bootmode.
> > > >> CONFIG_SPL_LOAD_FIT_ADRESS points to address where FIT image is stored
> > > >> in memory.
> > > >>
> > > >> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> > > >> Reviewed-by: Simon Glass <sjg@chromium.org>
> > > >> ---
> > > >
> > > > Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>
> > > >
> > > >
> > > > That's a very useful addition to the SPL FIT toolbox! I have a use case
> > > > where I may need to decrypt/authenticate an SPL FIT image in its
> > entirety
> > > > before processing it so this can be used for this as well.
> > >
> > > Do you have also use case where you need to load more files from FIT?
> > > There is loadable entry in FIT config entry.
> >
> > Not yet but I may get there. I'm experimenting with using U-Boot to load
> > and install a secure monitor mode application (specifically, OP-TEE OS),
> > so that will need to come from somewhere eventually and FIT would be a
> > natural place for that binary to reside since we can easily authenticate
> > it.
> 
> 
> ok what arch?
> What's the flow which you want to support?
> SPL to load OPTEE and ATF and full u-boot and jump to ATF which runs OPTEE
> and run to U-Boot?

I working with TI's current SoCs and those are ARMv7-A and there is no
ATF but instead a proprietary solution comprising ROM code and some
low-level code that gets loaded/authenticated/executed by said ROM in a
secure fashion before the regular boot flow starts (SPL, U-Boot, and so
on). There is flexibility to load/install a new secure monitor code
during SPL, U-Boot, or in fact at any other time (even after let's say
Linux is booted up) but from an overall system architecture POV we need
that new secure monitor (OP-TEE OS in this case) to be up before the
Kernel is loaded.

Anyways the goal is not only to get it working but also to have a
solution that plays nice with everything else and can be contributed
upstream.

Thanks and Regards,
Andreas

[U-Boot] [PATCH v2] SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode

[Michal Simek]

On 19.5.2016 21:26, Andreas Dannenberg wrote:
> Hi Michael,
> 
> On Thu, May 19, 2016 at 08:33:28PM +0200, Michal Simek wrote:
>> Hi Andreas,
>>
>> 2016-05-19 20:16 GMT+02:00 Andreas Dannenberg <dannenberg@ti.com>:
>>
>>> Hi Michal,
>>>
>>> On Thu, May 19, 2016 at 06:38:04PM +0200, Michal Simek wrote:
>>>> On 19.5.2016 18:15, Andreas Dannenberg wrote:
>>>>> On Tue, May 17, 2016 at 07:00:24PM +0200, Michal Simek wrote:
>>>>>> Support loading FIT in SPL for RAM bootmode.
>>>>>> CONFIG_SPL_LOAD_FIT_ADRESS points to address where FIT image is stored
>>>>>> in memory.
>>>>>>
>>>>>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>>>>>> Reviewed-by: Simon Glass <sjg@chromium.org>
>>>>>> ---
>>>>>
>>>>> Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>
>>>>>
>>>>>
>>>>> That's a very useful addition to the SPL FIT toolbox! I have a use case
>>>>> where I may need to decrypt/authenticate an SPL FIT image in its
>>> entirety
>>>>> before processing it so this can be used for this as well.
>>>>
>>>> Do you have also use case where you need to load more files from FIT?
>>>> There is loadable entry in FIT config entry.
>>>
>>> Not yet but I may get there. I'm experimenting with using U-Boot to load
>>> and install a secure monitor mode application (specifically, OP-TEE OS),
>>> so that will need to come from somewhere eventually and FIT would be a
>>> natural place for that binary to reside since we can easily authenticate
>>> it.
>>
>>
>> ok what arch?
>> What's the flow which you want to support?
>> SPL to load OPTEE and ATF and full u-boot and jump to ATF which runs OPTEE
>> and run to U-Boot?
> 
> I working with TI's current SoCs and those are ARMv7-A and there is no
> ATF but instead a proprietary solution comprising ROM code and some
> low-level code that gets loaded/authenticated/executed by said ROM in a
> secure fashion before the regular boot flow starts (SPL, U-Boot, and so
> on). There is flexibility to load/install a new secure monitor code
> during SPL, U-Boot, or in fact at any other time (even after let's say
> Linux is booted up) but from an overall system architecture POV we need
> that new secure monitor (OP-TEE OS in this case) to be up before the
> Kernel is loaded.
> 
> Anyways the goal is not only to get it working but also to have a
> solution that plays nice with everything else and can be contributed
> upstream.

Ok. I see. I will definitely keep my eyes on this one. Because I have
sent SPL for ZynqMP and if you look closely to setting I use without FIT
falcon bootmode to be able to load ATF and full u-boot to the memory.
For FIT I have sent patches to extend format with fpga part which bootm
supports. I have also additional patches (not in mainline) to load
bitstream from SPL.
But the goal should be that SPL will be able to load FPGA and several
images. Just to make long story short support fpga and loadables
sections in FIT format.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160520/8d49cf89/attachment.sig>