diff mbox series

[U-Boot,v2,3/3] common: Generic loader for file system

Message ID 1527138244-16058-4-git-send-email-tien.fong.chee@intel.com
State Superseded
Delegated to: Tom Rini
Headers show
Series Generic file system firmware loader DM | expand

Commit Message

Chee, Tien Fong May 24, 2018, 5:04 a.m. UTC
From: Tien Fong Chee <tien.fong.chee@intel.com>

This is file system generic loader which can be used to load
the file image from the storage into target such as memory.
The consumer driver would then use this loader to program whatever,
ie. the FPGA device.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
---
 drivers/misc/Kconfig     |  11 +++
 drivers/misc/Makefile    |   1 +
 drivers/misc/fs_loader.c | 240 +++++++++++++++++++++++++++++++++++++++++++++++
 include/dm/uclass-id.h   |   1 +
 include/fs_loader.h      |  28 ++++++
 5 files changed, 281 insertions(+)
 create mode 100644 drivers/misc/fs_loader.c
 create mode 100644 include/fs_loader.h

Comments

Marek Vasut June 6, 2018, 8:39 a.m. UTC | #1
On 05/24/2018 07:04 AM, tien.fong.chee@intel.com wrote:
> From: Tien Fong Chee <tien.fong.chee@intel.com>
> 
> This is file system generic loader which can be used to load
> the file image from the storage into target such as memory.
> The consumer driver would then use this loader to program whatever,
> ie. the FPGA device.
> 
> Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
> ---
[...]
> +static int fs_loader_probe(struct udevice *dev)
> +{
> +	return 0;
> +};
> +
> +static const struct udevice_id fs_loader_ids[] = {
> +	{ .compatible = "fs_loader"},

Why exactly is there a DT compatible for a firmware loader?

> +	{ }
> +};
> +
> +U_BOOT_DRIVER(fs_loader) = {
> +	.name			= "fs_loader",
> +	.id			= UCLASS_FS_FIRMWARE_LOADER,
> +	.of_match		= fs_loader_ids,
> +	.probe			= fs_loader_probe,
> +	.ofdata_to_platdata	= fs_loader_ofdata_to_platdata,
> +	.platdata_auto_alloc_size	= sizeof(struct device_platdata),
> +};
> +
> +UCLASS_DRIVER(fs_loader) = {
> +	.id		= UCLASS_FS_FIRMWARE_LOADER,
> +	.name		= "fs_loader",
> +};

[...]
Chee, Tien Fong June 7, 2018, 4:04 a.m. UTC | #2
On Wed, 2018-06-06 at 10:39 +0200, Marek Vasut wrote:
> On 05/24/2018 07:04 AM, tien.fong.chee@intel.com wrote:
> > 
> > From: Tien Fong Chee <tien.fong.chee@intel.com>
> > 
> > This is file system generic loader which can be used to load
> > the file image from the storage into target such as memory.
> > The consumer driver would then use this loader to program whatever,
> > ie. the FPGA device.
> > 
> > Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
> > ---
> [...]
> > 
> > +static int fs_loader_probe(struct udevice *dev)
> > +{
> > +	return 0;
> > +};
> > +
> > +static const struct udevice_id fs_loader_ids[] = {
> > +	{ .compatible = "fs_loader"},
> Why exactly is there a DT compatible for a firmware loader?
> 
Correct me if i'm wrong, this is required to look the platform data
from DTS, right? Details of DTS in patch 2.
> > 
> > +	{ }
> > +};
> > +
> > +U_BOOT_DRIVER(fs_loader) = {
> > +	.name			= "fs_loader",
> > +	.id			= UCLASS_FS_FIRMWARE_LOADER,
> > +	.of_match		= fs_loader_ids,
> > +	.probe			= fs_loader_probe,
> > +	.ofdata_to_platdata	= fs_loader_ofdata_to_platdata,
> > +	.platdata_auto_alloc_size	= sizeof(struct
> > device_platdata),
> > +};
> > +
> > +UCLASS_DRIVER(fs_loader) = {
> > +	.id		= UCLASS_FS_FIRMWARE_LOADER,
> > +	.name		= "fs_loader",
> > +};
> [...]
Marek Vasut June 7, 2018, 6:51 a.m. UTC | #3
On 06/07/2018 06:04 AM, Chee, Tien Fong wrote:
> On Wed, 2018-06-06 at 10:39 +0200, Marek Vasut wrote:
>> On 05/24/2018 07:04 AM, tien.fong.chee@intel.com wrote:
>>>
>>> From: Tien Fong Chee <tien.fong.chee@intel.com>
>>>
>>> This is file system generic loader which can be used to load
>>> the file image from the storage into target such as memory.
>>> The consumer driver would then use this loader to program whatever,
>>> ie. the FPGA device.
>>>
>>> Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
>>> ---
>> [...]
>>>
>>> +static int fs_loader_probe(struct udevice *dev)
>>> +{
>>> +	return 0;
>>> +};
>>> +
>>> +static const struct udevice_id fs_loader_ids[] = {
>>> +	{ .compatible = "fs_loader"},
>> Why exactly is there a DT compatible for a firmware loader?
>>
> Correct me if i'm wrong, this is required to look the platform data
> from DTS, right? Details of DTS in patch 2.

How so ? The FW loader should behave as a library for other drivers to
use, not like a driver.

>>>
>>> +	{ }
>>> +};
>>> +
>>> +U_BOOT_DRIVER(fs_loader) = {
>>> +	.name			= "fs_loader",
>>> +	.id			= UCLASS_FS_FIRMWARE_LOADER,
>>> +	.of_match		= fs_loader_ids,
>>> +	.probe			= fs_loader_probe,
>>> +	.ofdata_to_platdata	= fs_loader_ofdata_to_platdata,
>>> +	.platdata_auto_alloc_size	= sizeof(struct
>>> device_platdata),
>>> +};
>>> +
>>> +UCLASS_DRIVER(fs_loader) = {
>>> +	.id		= UCLASS_FS_FIRMWARE_LOADER,
>>> +	.name		= "fs_loader",
>>> +};
>> [...]
Chee, Tien Fong June 7, 2018, 8:36 a.m. UTC | #4
On Thu, 2018-06-07 at 08:51 +0200, Marek Vasut wrote:
> On 06/07/2018 06:04 AM, Chee, Tien Fong wrote:
> > 
> > On Wed, 2018-06-06 at 10:39 +0200, Marek Vasut wrote:
> > > 
> > > On 05/24/2018 07:04 AM, tien.fong.chee@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee <tien.fong.chee@intel.com>
> > > > 
> > > > This is file system generic loader which can be used to load
> > > > the file image from the storage into target such as memory.
> > > > The consumer driver would then use this loader to program
> > > > whatever,
> > > > ie. the FPGA device.
> > > > 
> > > > Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
> > > > ---
> > > [...]
> > > > 
> > > > 
> > > > +static int fs_loader_probe(struct udevice *dev)
> > > > +{
> > > > +	return 0;
> > > > +};
> > > > +
> > > > +static const struct udevice_id fs_loader_ids[] = {
> > > > +	{ .compatible = "fs_loader"},
> > > Why exactly is there a DT compatible for a firmware loader?
> > > 
> > Correct me if i'm wrong, this is required to look the platform data
> > from DTS, right? Details of DTS in patch 2.
> How so ? The FW loader should behave as a library for other drivers
> to
> use, not like a driver.
> 
The fs_loader node in DTS just provide a way for user to tell the
firmware loader what storage device and default partition to load data
from. Default partition can be overriden through the variable
environment.

Caller/other drivers can create different firmware loader instance
based on different fs_loader node(different storage device) for their
loading purpose.

Why this cannot be used by other driver?
> > 
> > > 
> > > > 
> > > > 
> > > > +	{ }
> > > > +};
> > > > +
> > > > +U_BOOT_DRIVER(fs_loader) = {
> > > > +	.name			= "fs_loader",
> > > > +	.id			=
> > > > UCLASS_FS_FIRMWARE_LOADER,
> > > > +	.of_match		= fs_loader_ids,
> > > > +	.probe			= fs_loader_probe,
> > > > +	.ofdata_to_platdata	=
> > > > fs_loader_ofdata_to_platdata,
> > > > +	.platdata_auto_alloc_size	= sizeof(struct
> > > > device_platdata),
> > > > +};
> > > > +
> > > > +UCLASS_DRIVER(fs_loader) = {
> > > > +	.id		= UCLASS_FS_FIRMWARE_LOADER,
> > > > +	.name		= "fs_loader",
> > > > +};
> > > [...]
>
Marek Vasut June 7, 2018, 8:41 a.m. UTC | #5
On 06/07/2018 10:36 AM, Chee, Tien Fong wrote:
> On Thu, 2018-06-07 at 08:51 +0200, Marek Vasut wrote:
>> On 06/07/2018 06:04 AM, Chee, Tien Fong wrote:
>>>
>>> On Wed, 2018-06-06 at 10:39 +0200, Marek Vasut wrote:
>>>>
>>>> On 05/24/2018 07:04 AM, tien.fong.chee@intel.com wrote:
>>>>>
>>>>>
>>>>> From: Tien Fong Chee <tien.fong.chee@intel.com>
>>>>>
>>>>> This is file system generic loader which can be used to load
>>>>> the file image from the storage into target such as memory.
>>>>> The consumer driver would then use this loader to program
>>>>> whatever,
>>>>> ie. the FPGA device.
>>>>>
>>>>> Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
>>>>> ---
>>>> [...]
>>>>>
>>>>>
>>>>> +static int fs_loader_probe(struct udevice *dev)
>>>>> +{
>>>>> +	return 0;
>>>>> +};
>>>>> +
>>>>> +static const struct udevice_id fs_loader_ids[] = {
>>>>> +	{ .compatible = "fs_loader"},
>>>> Why exactly is there a DT compatible for a firmware loader?
>>>>
>>> Correct me if i'm wrong, this is required to look the platform data
>>> from DTS, right? Details of DTS in patch 2.
>> How so ? The FW loader should behave as a library for other drivers
>> to
>> use, not like a driver.
>>
> The fs_loader node in DTS just provide a way for user to tell the
> firmware loader what storage device and default partition to load data
> from. Default partition can be overriden through the variable
> environment.

So that's sitting in the chosen node ? But why do you need to match on it ?

> Caller/other drivers can create different firmware loader instance
> based on different fs_loader node(different storage device) for their
> loading purpose.

They can, but that could be done even without the DT compatible.

> Why this cannot be used by other driver?
I don't understand the question.
Chee, Tien Fong June 7, 2018, 9:45 a.m. UTC | #6
On Thu, 2018-06-07 at 10:41 +0200, Marek Vasut wrote:
> On 06/07/2018 10:36 AM, Chee, Tien Fong wrote:
> > 
> > On Thu, 2018-06-07 at 08:51 +0200, Marek Vasut wrote:
> > > 
> > > On 06/07/2018 06:04 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Wed, 2018-06-06 at 10:39 +0200, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 05/24/2018 07:04 AM, tien.fong.chee@intel.com wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > From: Tien Fong Chee <tien.fong.chee@intel.com>
> > > > > > 
> > > > > > This is file system generic loader which can be used to
> > > > > > load
> > > > > > the file image from the storage into target such as memory.
> > > > > > The consumer driver would then use this loader to program
> > > > > > whatever,
> > > > > > ie. the FPGA device.
> > > > > > 
> > > > > > Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
> > > > > > ---
> > > > > [...]
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > +static int fs_loader_probe(struct udevice *dev)
> > > > > > +{
> > > > > > +	return 0;
> > > > > > +};
> > > > > > +
> > > > > > +static const struct udevice_id fs_loader_ids[] = {
> > > > > > +	{ .compatible = "fs_loader"},
> > > > > Why exactly is there a DT compatible for a firmware loader?
> > > > > 
> > > > Correct me if i'm wrong, this is required to look the platform
> > > > data
> > > > from DTS, right? Details of DTS in patch 2.
> > > How so ? The FW loader should behave as a library for other
> > > drivers
> > > to
> > > use, not like a driver.
> > > 
> > The fs_loader node in DTS just provide a way for user to tell the
> > firmware loader what storage device and default partition to load
> > data
> > from. Default partition can be overriden through the variable
> > environment.
> So that's sitting in the chosen node ? But why do you need to match
> on it ?
> 
This is new device tree binding for firmware loader called fs_loader
node. firmware loader need to know where is the storage device it need
to load from. Those storage device would be defined in fs_loader node.
> > 
> > Caller/other drivers can create different firmware loader instance
> > based on different fs_loader node(different storage device) for
> > their
> > loading purpose.
> They can, but that could be done even without the DT compatible.
> 
Yes, once you get dev, you can set the storage type and partiiton
attributes through accessing dev->platdata.
> > 
> > Why this cannot be used by other driver?
> I don't understand the question.
> 
I means why u say this firmware loader cannot be used by other drivers.
I have tested with FPGA Manager driver(as caller).
Marek Vasut June 7, 2018, 9:50 a.m. UTC | #7
On 06/07/2018 11:45 AM, Chee, Tien Fong wrote:
> On Thu, 2018-06-07 at 10:41 +0200, Marek Vasut wrote:
>> On 06/07/2018 10:36 AM, Chee, Tien Fong wrote:
>>>
>>> On Thu, 2018-06-07 at 08:51 +0200, Marek Vasut wrote:
>>>>
>>>> On 06/07/2018 06:04 AM, Chee, Tien Fong wrote:
>>>>>
>>>>>
>>>>> On Wed, 2018-06-06 at 10:39 +0200, Marek Vasut wrote:
>>>>>>
>>>>>>
>>>>>> On 05/24/2018 07:04 AM, tien.fong.chee@intel.com wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: Tien Fong Chee <tien.fong.chee@intel.com>
>>>>>>>
>>>>>>> This is file system generic loader which can be used to
>>>>>>> load
>>>>>>> the file image from the storage into target such as memory.
>>>>>>> The consumer driver would then use this loader to program
>>>>>>> whatever,
>>>>>>> ie. the FPGA device.
>>>>>>>
>>>>>>> Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
>>>>>>> ---
>>>>>> [...]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> +static int fs_loader_probe(struct udevice *dev)
>>>>>>> +{
>>>>>>> +	return 0;
>>>>>>> +};
>>>>>>> +
>>>>>>> +static const struct udevice_id fs_loader_ids[] = {
>>>>>>> +	{ .compatible = "fs_loader"},
>>>>>> Why exactly is there a DT compatible for a firmware loader?
>>>>>>
>>>>> Correct me if i'm wrong, this is required to look the platform
>>>>> data
>>>>> from DTS, right? Details of DTS in patch 2.
>>>> How so ? The FW loader should behave as a library for other
>>>> drivers
>>>> to
>>>> use, not like a driver.
>>>>
>>> The fs_loader node in DTS just provide a way for user to tell the
>>> firmware loader what storage device and default partition to load
>>> data
>>> from. Default partition can be overriden through the variable
>>> environment.
>> So that's sitting in the chosen node ? But why do you need to match
>> on it ?
>>
> This is new device tree binding for firmware loader called fs_loader
> node. firmware loader need to know where is the storage device it need
> to load from. Those storage device would be defined in fs_loader node.

This is a configuration. You do not need (new) a DT compatible for that.
So why is the DT compatible even needed in the FW loader at all ?

>>> Caller/other drivers can create different firmware loader instance
>>> based on different fs_loader node(different storage device) for
>>> their
>>> loading purpose.
>> They can, but that could be done even without the DT compatible.
>>
> Yes, once you get dev, you can set the storage type and partiiton
> attributes through accessing dev->platdata.

Can you show me the DT patch needed for this to work ?

>>> Why this cannot be used by other driver?
>> I don't understand the question.
>>
> I means why u say this firmware loader cannot be used by other drivers.
> I have tested with FPGA Manager driver(as caller).

It must be used by other drivers, that is the point.
Chee, Tien Fong June 7, 2018, 10:11 a.m. UTC | #8
On Thu, 2018-06-07 at 11:50 +0200, Marek Vasut wrote:
> On 06/07/2018 11:45 AM, Chee, Tien Fong wrote:
> > 
> > On Thu, 2018-06-07 at 10:41 +0200, Marek Vasut wrote:
> > > 
> > > On 06/07/2018 10:36 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Thu, 2018-06-07 at 08:51 +0200, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 06/07/2018 06:04 AM, Chee, Tien Fong wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Wed, 2018-06-06 at 10:39 +0200, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 05/24/2018 07:04 AM, tien.fong.chee@intel.com wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > From: Tien Fong Chee <tien.fong.chee@intel.com>
> > > > > > > > 
> > > > > > > > This is file system generic loader which can be used to
> > > > > > > > load
> > > > > > > > the file image from the storage into target such as
> > > > > > > > memory.
> > > > > > > > The consumer driver would then use this loader to
> > > > > > > > program
> > > > > > > > whatever,
> > > > > > > > ie. the FPGA device.
> > > > > > > > 
> > > > > > > > Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com
> > > > > > > > >
> > > > > > > > ---
> > > > > > > [...]
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > +static int fs_loader_probe(struct udevice *dev)
> > > > > > > > +{
> > > > > > > > +	return 0;
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +static const struct udevice_id fs_loader_ids[] = {
> > > > > > > > +	{ .compatible = "fs_loader"},
> > > > > > > Why exactly is there a DT compatible for a firmware
> > > > > > > loader?
> > > > > > > 
> > > > > > Correct me if i'm wrong, this is required to look the
> > > > > > platform
> > > > > > data
> > > > > > from DTS, right? Details of DTS in patch 2.
> > > > > How so ? The FW loader should behave as a library for other
> > > > > drivers
> > > > > to
> > > > > use, not like a driver.
> > > > > 
> > > > The fs_loader node in DTS just provide a way for user to tell
> > > > the
> > > > firmware loader what storage device and default partition to
> > > > load
> > > > data
> > > > from. Default partition can be overriden through the variable
> > > > environment.
> > > So that's sitting in the chosen node ? But why do you need to
> > > match
> > > on it ?
> > > 
> > This is new device tree binding for firmware loader called
> > fs_loader
> > node. firmware loader need to know where is the storage device it
> > need
> > to load from. Those storage device would be defined in fs_loader
> > node.
> This is a configuration. You do not need (new) a DT compatible for
> that.
> So why is the DT compatible even needed in the FW loader at all ?
> 
I thought DT compatible is used by driver to find the fs_loader node in
DTS. May be i am wrong.
> > 
> > > 
> > > > 
> > > > Caller/other drivers can create different firmware loader
> > > > instance
> > > > based on different fs_loader node(different storage device) for
> > > > their
> > > > loading purpose.
> > > They can, but that could be done even without the DT compatible.
> > > 
> > Yes, once you get dev, you can set the storage type and partiiton
> > attributes through accessing dev->platdata.
> Can you show me the DT patch needed for this to work ?
> 
I can send you the patches separately, but this driver is designed to
work with/without DT.
> > 
> > > 
> > > > 
> > > > Why this cannot be used by other driver?
> > > I don't understand the question.
> > > 
> > I means why u say this firmware loader cannot be used by other
> > drivers.
> > I have tested with FPGA Manager driver(as caller).
> It must be used by other drivers, that is the point.
> 
yes, it can be used by FPGA manager driver.
Marek Vasut June 7, 2018, 10:29 a.m. UTC | #9
On 06/07/2018 12:11 PM, Chee, Tien Fong wrote:
> On Thu, 2018-06-07 at 11:50 +0200, Marek Vasut wrote:
>> On 06/07/2018 11:45 AM, Chee, Tien Fong wrote:
>>>
>>> On Thu, 2018-06-07 at 10:41 +0200, Marek Vasut wrote:
>>>>
>>>> On 06/07/2018 10:36 AM, Chee, Tien Fong wrote:
>>>>>
>>>>>
>>>>> On Thu, 2018-06-07 at 08:51 +0200, Marek Vasut wrote:
>>>>>>
>>>>>>
>>>>>> On 06/07/2018 06:04 AM, Chee, Tien Fong wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, 2018-06-06 at 10:39 +0200, Marek Vasut wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 05/24/2018 07:04 AM, tien.fong.chee@intel.com wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> From: Tien Fong Chee <tien.fong.chee@intel.com>
>>>>>>>>>
>>>>>>>>> This is file system generic loader which can be used to
>>>>>>>>> load
>>>>>>>>> the file image from the storage into target such as
>>>>>>>>> memory.
>>>>>>>>> The consumer driver would then use this loader to
>>>>>>>>> program
>>>>>>>>> whatever,
>>>>>>>>> ie. the FPGA device.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com
>>>>>>>>>>
>>>>>>>>> ---
>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> +static int fs_loader_probe(struct udevice *dev)
>>>>>>>>> +{
>>>>>>>>> +	return 0;
>>>>>>>>> +};
>>>>>>>>> +
>>>>>>>>> +static const struct udevice_id fs_loader_ids[] = {
>>>>>>>>> +	{ .compatible = "fs_loader"},
>>>>>>>> Why exactly is there a DT compatible for a firmware
>>>>>>>> loader?
>>>>>>>>
>>>>>>> Correct me if i'm wrong, this is required to look the
>>>>>>> platform
>>>>>>> data
>>>>>>> from DTS, right? Details of DTS in patch 2.
>>>>>> How so ? The FW loader should behave as a library for other
>>>>>> drivers
>>>>>> to
>>>>>> use, not like a driver.
>>>>>>
>>>>> The fs_loader node in DTS just provide a way for user to tell
>>>>> the
>>>>> firmware loader what storage device and default partition to
>>>>> load
>>>>> data
>>>>> from. Default partition can be overriden through the variable
>>>>> environment.
>>>> So that's sitting in the chosen node ? But why do you need to
>>>> match
>>>> on it ?
>>>>
>>> This is new device tree binding for firmware loader called
>>> fs_loader
>>> node. firmware loader need to know where is the storage device it
>>> need
>>> to load from. Those storage device would be defined in fs_loader
>>> node.
>> This is a configuration. You do not need (new) a DT compatible for
>> that.
>> So why is the DT compatible even needed in the FW loader at all ?
>>
> I thought DT compatible is used by driver to find the fs_loader node in
> DTS. May be i am wrong.

There should be no FW loader in the DTS. Why would there be one ?

>>>
>>>>
>>>>>
>>>>> Caller/other drivers can create different firmware loader
>>>>> instance
>>>>> based on different fs_loader node(different storage device) for
>>>>> their
>>>>> loading purpose.
>>>> They can, but that could be done even without the DT compatible.
>>>>
>>> Yes, once you get dev, you can set the storage type and partiiton
>>> attributes through accessing dev->platdata.
>> Can you show me the DT patch needed for this to work ?
>>
> I can send you the patches separately, but this driver is designed to
> work with/without DT.

This is not a driver though, it should be a library (or so) for drivers
to use.

>>>
>>>>
>>>>>
>>>>> Why this cannot be used by other driver?
>>>> I don't understand the question.
>>>>
>>> I means why u say this firmware loader cannot be used by other
>>> drivers.
>>> I have tested with FPGA Manager driver(as caller).
>> It must be used by other drivers, that is the point.
>>
> yes, it can be used by FPGA manager driver.
>
Chee, Tien Fong June 11, 2018, 5:01 a.m. UTC | #10
On Thu, 2018-06-07 at 12:29 +0200, Marek Vasut wrote:
> On 06/07/2018 12:11 PM, Chee, Tien Fong wrote:
> > 
> > On Thu, 2018-06-07 at 11:50 +0200, Marek Vasut wrote:
> > > 
> > > On 06/07/2018 11:45 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Thu, 2018-06-07 at 10:41 +0200, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 06/07/2018 10:36 AM, Chee, Tien Fong wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Thu, 2018-06-07 at 08:51 +0200, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 06/07/2018 06:04 AM, Chee, Tien Fong wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Wed, 2018-06-06 at 10:39 +0200, Marek Vasut wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 05/24/2018 07:04 AM, tien.fong.chee@intel.com
> > > > > > > > > wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > From: Tien Fong Chee <tien.fong.chee@intel.com>
> > > > > > > > > > 
> > > > > > > > > > This is file system generic loader which can be
> > > > > > > > > > used to
> > > > > > > > > > load
> > > > > > > > > > the file image from the storage into target such as
> > > > > > > > > > memory.
> > > > > > > > > > The consumer driver would then use this loader to
> > > > > > > > > > program
> > > > > > > > > > whatever,
> > > > > > > > > > ie. the FPGA device.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Tien Fong Chee <tien.fong.chee@intel
> > > > > > > > > > .com
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > ---
> > > > > > > > > [...]
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > +static int fs_loader_probe(struct udevice *dev)
> > > > > > > > > > +{
> > > > > > > > > > +	return 0;
> > > > > > > > > > +};
> > > > > > > > > > +
> > > > > > > > > > +static const struct udevice_id fs_loader_ids[] = {
> > > > > > > > > > +	{ .compatible = "fs_loader"},
> > > > > > > > > Why exactly is there a DT compatible for a firmware
> > > > > > > > > loader?
> > > > > > > > > 
> > > > > > > > Correct me if i'm wrong, this is required to look the
> > > > > > > > platform
> > > > > > > > data
> > > > > > > > from DTS, right? Details of DTS in patch 2.
> > > > > > > How so ? The FW loader should behave as a library for
> > > > > > > other
> > > > > > > drivers
> > > > > > > to
> > > > > > > use, not like a driver.
> > > > > > > 
> > > > > > The fs_loader node in DTS just provide a way for user to
> > > > > > tell
> > > > > > the
> > > > > > firmware loader what storage device and default partition
> > > > > > to
> > > > > > load
> > > > > > data
> > > > > > from. Default partition can be overriden through the
> > > > > > variable
> > > > > > environment.
> > > > > So that's sitting in the chosen node ? But why do you need to
> > > > > match
> > > > > on it ?
> > > > > 
> > > > This is new device tree binding for firmware loader called
> > > > fs_loader
> > > > node. firmware loader need to know where is the storage device
> > > > it
> > > > need
> > > > to load from. Those storage device would be defined in
> > > > fs_loader
> > > > node.
> > > This is a configuration. You do not need (new) a DT compatible
> > > for
> > > that.
> > > So why is the DT compatible even needed in the FW loader at all ?
> > > 
> > I thought DT compatible is used by driver to find the fs_loader
> > node in
> > DTS. May be i am wrong.
> There should be no FW loader in the DTS. Why would there be one ?
> 
 I added DTS support for user to define storage type and default
partition. So you want me to remove the DTS?
Removing the DTS, then user can only set storage type and partition
through dev instance. So, this design OK for you?
> > 
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > Caller/other drivers can create different firmware loader
> > > > > > instance
> > > > > > based on different fs_loader node(different storage device)
> > > > > > for
> > > > > > their
> > > > > > loading purpose.
> > > > > They can, but that could be done even without the DT
> > > > > compatible.
> > > > > 
> > > > Yes, once you get dev, you can set the storage type and
> > > > partiiton
> > > > attributes through accessing dev->platdata.
> > > Can you show me the DT patch needed for this to work ?
> > > 
> > I can send you the patches separately, but this driver is designed
> > to
> > work with/without DT.
> This is not a driver though, it should be a library (or so) for
> drivers
> to use.
> 
Yes, this is designed for other drivers to use.
> > 
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > Why this cannot be used by other driver?
> > > > > I don't understand the question.
> > > > > 
> > > > I means why u say this firmware loader cannot be used by other
> > > > drivers.
> > > > I have tested with FPGA Manager driver(as caller).
> > > It must be used by other drivers, that is the point.
> > > 
> > yes, it can be used by FPGA manager driver.
> > 
>
Marek Vasut June 11, 2018, 9:39 a.m. UTC | #11
On 06/11/2018 07:01 AM, Chee, Tien Fong wrote:
[...]
>>>> This is a configuration. You do not need (new) a DT compatible
>>>> for
>>>> that.
>>>> So why is the DT compatible even needed in the FW loader at all ?
>>>>
>>> I thought DT compatible is used by driver to find the fs_loader
>>> node in
>>> DTS. May be i am wrong.
>> There should be no FW loader in the DTS. Why would there be one ?
>>
>  I added DTS support for user to define storage type and default
> partition. So you want me to remove the DTS?
> Removing the DTS, then user can only set storage type and partition
> through dev instance. So, this design OK for you?

How does Linux do it ?

[...]
Chee, Tien Fong June 11, 2018, 11:53 a.m. UTC | #12
On Mon, 2018-06-11 at 11:39 +0200, Marek Vasut wrote:
> On 06/11/2018 07:01 AM, Chee, Tien Fong wrote:
> [...]
> > 
> > > 
> > > > 
> > > > > 
> > > > > This is a configuration. You do not need (new) a DT
> > > > > compatible
> > > > > for
> > > > > that.
> > > > > So why is the DT compatible even needed in the FW loader at
> > > > > all ?
> > > > > 
> > > > I thought DT compatible is used by driver to find the fs_loader
> > > > node in
> > > > DTS. May be i am wrong.
> > > There should be no FW loader in the DTS. Why would there be one ?
> > > 
> >  I added DTS support for user to define storage type and default
> > partition. So you want me to remove the DTS?
> > Removing the DTS, then user can only set storage type and partition
> > through dev instance. So, this design OK for you?
> How does Linux do it ?
> 
Linux firmware loading method is different with this
Linux loading firmware with
1. Firmware search paths - which is hardcoded in root file system
2. Built-in firmware - part of kernel binaries

This patch loading firmware with
1. Storage type and partition specified in DTS, but storage type can
be overridden dev instance and partition through U-boot variable
environment.

Or:

2. Storage type can be set through dev instance, and partition through
U-boot variable environment. No DTS is required.

> [...]
Marek Vasut June 11, 2018, 11:55 a.m. UTC | #13
On 06/11/2018 01:53 PM, Chee, Tien Fong wrote:
> On Mon, 2018-06-11 at 11:39 +0200, Marek Vasut wrote:
>> On 06/11/2018 07:01 AM, Chee, Tien Fong wrote:
>> [...]
>>>
>>>>
>>>>>
>>>>>>
>>>>>> This is a configuration. You do not need (new) a DT
>>>>>> compatible
>>>>>> for
>>>>>> that.
>>>>>> So why is the DT compatible even needed in the FW loader at
>>>>>> all ?
>>>>>>
>>>>> I thought DT compatible is used by driver to find the fs_loader
>>>>> node in
>>>>> DTS. May be i am wrong.
>>>> There should be no FW loader in the DTS. Why would there be one ?
>>>>
>>>  I added DTS support for user to define storage type and default
>>> partition. So you want me to remove the DTS?
>>> Removing the DTS, then user can only set storage type and partition
>>> through dev instance. So, this design OK for you?
>> How does Linux do it ?
>>
> Linux firmware loading method is different with this
> Linux loading firmware with
> 1. Firmware search paths - which is hardcoded in root file system
> 2. Built-in firmware - part of kernel binaries
> 
> This patch loading firmware with
> 1. Storage type and partition specified in DTS, but storage type can
> be overridden dev instance and partition through U-boot variable
> environment.
> 
> Or:
> 
> 2. Storage type can be set through dev instance, and partition through
> U-boot variable environment. No DTS is required.

And why can we not do as Linux does ?
Chee, Tien Fong June 11, 2018, 12:42 p.m. UTC | #14
On Mon, 2018-06-11 at 13:55 +0200, Marek Vasut wrote:
> On 06/11/2018 01:53 PM, Chee, Tien Fong wrote:
> > 
> > On Mon, 2018-06-11 at 11:39 +0200, Marek Vasut wrote:
> > > 
> > > On 06/11/2018 07:01 AM, Chee, Tien Fong wrote:
> > > [...]
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > This is a configuration. You do not need (new) a DT
> > > > > > > compatible
> > > > > > > for
> > > > > > > that.
> > > > > > > So why is the DT compatible even needed in the FW loader
> > > > > > > at
> > > > > > > all ?
> > > > > > > 
> > > > > > I thought DT compatible is used by driver to find the
> > > > > > fs_loader
> > > > > > node in
> > > > > > DTS. May be i am wrong.
> > > > > There should be no FW loader in the DTS. Why would there be
> > > > > one ?
> > > > > 
> > > >  I added DTS support for user to define storage type and
> > > > default
> > > > partition. So you want me to remove the DTS?
> > > > Removing the DTS, then user can only set storage type and
> > > > partition
> > > > through dev instance. So, this design OK for you?
> > > How does Linux do it ?
> > > 
> > Linux firmware loading method is different with this
> > Linux loading firmware with
> > 1. Firmware search paths - which is hardcoded in root file system
> > 2. Built-in firmware - part of kernel binaries
> > 
> > This patch loading firmware with
> > 1. Storage type and partition specified in DTS, but storage type
> > can
> > be overridden dev instance and partition through U-boot variable
> > environment.
> > 
> > Or:
> > 
> > 2. Storage type can be set through dev instance, and partition
> > through
> > U-boot variable environment. No DTS is required.
> And why can we not do as Linux does ?
> 
Because we don't have root file system, but i have mimicked the search
path in our variable environment, but with both storage type and
partition.
Marek Vasut June 11, 2018, 1:38 p.m. UTC | #15
On 06/11/2018 02:42 PM, Chee, Tien Fong wrote:
> On Mon, 2018-06-11 at 13:55 +0200, Marek Vasut wrote:
>> On 06/11/2018 01:53 PM, Chee, Tien Fong wrote:
>>>
>>> On Mon, 2018-06-11 at 11:39 +0200, Marek Vasut wrote:
>>>>
>>>> On 06/11/2018 07:01 AM, Chee, Tien Fong wrote:
>>>> [...]
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This is a configuration. You do not need (new) a DT
>>>>>>>> compatible
>>>>>>>> for
>>>>>>>> that.
>>>>>>>> So why is the DT compatible even needed in the FW loader
>>>>>>>> at
>>>>>>>> all ?
>>>>>>>>
>>>>>>> I thought DT compatible is used by driver to find the
>>>>>>> fs_loader
>>>>>>> node in
>>>>>>> DTS. May be i am wrong.
>>>>>> There should be no FW loader in the DTS. Why would there be
>>>>>> one ?
>>>>>>
>>>>>  I added DTS support for user to define storage type and
>>>>> default
>>>>> partition. So you want me to remove the DTS?
>>>>> Removing the DTS, then user can only set storage type and
>>>>> partition
>>>>> through dev instance. So, this design OK for you?
>>>> How does Linux do it ?
>>>>
>>> Linux firmware loading method is different with this
>>> Linux loading firmware with
>>> 1. Firmware search paths - which is hardcoded in root file system
>>> 2. Built-in firmware - part of kernel binaries
>>>
>>> This patch loading firmware with
>>> 1. Storage type and partition specified in DTS, but storage type
>>> can
>>> be overridden dev instance and partition through U-boot variable
>>> environment.
>>>
>>> Or:
>>>
>>> 2. Storage type can be set through dev instance, and partition
>>> through
>>> U-boot variable environment. No DTS is required.
>> And why can we not do as Linux does ?
>>
> Because we don't have root file system, but i have mimicked the search
> path in our variable environment, but with both storage type and
> partition.

OK, so user can configure environment variable to inform U-Boot where to
look for firmware, good (although, this probably fails in early env,
dunno of that's a problem).

But why do we need the DT part of things ? I don't think we do need it
at all.
Chee, Tien Fong June 11, 2018, 1:55 p.m. UTC | #16
On Mon, 2018-06-11 at 15:38 +0200, Marek Vasut wrote:
> On 06/11/2018 02:42 PM, Chee, Tien Fong wrote:
> > 
> > On Mon, 2018-06-11 at 13:55 +0200, Marek Vasut wrote:
> > > 
> > > On 06/11/2018 01:53 PM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Mon, 2018-06-11 at 11:39 +0200, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 06/11/2018 07:01 AM, Chee, Tien Fong wrote:
> > > > > [...]
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > This is a configuration. You do not need (new) a DT
> > > > > > > > > compatible
> > > > > > > > > for
> > > > > > > > > that.
> > > > > > > > > So why is the DT compatible even needed in the FW
> > > > > > > > > loader
> > > > > > > > > at
> > > > > > > > > all ?
> > > > > > > > > 
> > > > > > > > I thought DT compatible is used by driver to find the
> > > > > > > > fs_loader
> > > > > > > > node in
> > > > > > > > DTS. May be i am wrong.
> > > > > > > There should be no FW loader in the DTS. Why would there
> > > > > > > be
> > > > > > > one ?
> > > > > > > 
> > > > > >  I added DTS support for user to define storage type and
> > > > > > default
> > > > > > partition. So you want me to remove the DTS?
> > > > > > Removing the DTS, then user can only set storage type and
> > > > > > partition
> > > > > > through dev instance. So, this design OK for you?
> > > > > How does Linux do it ?
> > > > > 
> > > > Linux firmware loading method is different with this
> > > > Linux loading firmware with
> > > > 1. Firmware search paths - which is hardcoded in root file
> > > > system
> > > > 2. Built-in firmware - part of kernel binaries
> > > > 
> > > > This patch loading firmware with
> > > > 1. Storage type and partition specified in DTS, but storage
> > > > type
> > > > can
> > > > be overridden dev instance and partition through U-boot
> > > > variable
> > > > environment.
> > > > 
> > > > Or:
> > > > 
> > > > 2. Storage type can be set through dev instance, and partition
> > > > through
> > > > U-boot variable environment. No DTS is required.
> > > And why can we not do as Linux does ?
> > > 
> > Because we don't have root file system, but i have mimicked the
> > search
> > path in our variable environment, but with both storage type and
> > partition.
> OK, so user can configure environment variable to inform U-Boot where
> to
> look for firmware, good (although, this probably fails in early env,
> dunno of that's a problem).
> 
Without DTS, then you need to configure env variable, so that SPL and
U-boot only know what storage type and partiton to look for firmware.

> But why do we need the DT part of things ? I don't think we do need
> it
> at all.
> 
Leverage the flexibility and benefits of the DT such as changing both
storage type and partitions without changing the codes.
Marek Vasut June 11, 2018, 2:03 p.m. UTC | #17
On 06/11/2018 03:55 PM, Chee, Tien Fong wrote:
[...]
>>>>> Linux firmware loading method is different with this
>>>>> Linux loading firmware with
>>>>> 1. Firmware search paths - which is hardcoded in root file
>>>>> system
>>>>> 2. Built-in firmware - part of kernel binaries
>>>>>
>>>>> This patch loading firmware with
>>>>> 1. Storage type and partition specified in DTS, but storage
>>>>> type
>>>>> can
>>>>> be overridden dev instance and partition through U-boot
>>>>> variable
>>>>> environment.
>>>>>
>>>>> Or:
>>>>>
>>>>> 2. Storage type can be set through dev instance, and partition
>>>>> through
>>>>> U-boot variable environment. No DTS is required.
>>>> And why can we not do as Linux does ?
>>>>
>>> Because we don't have root file system, but i have mimicked the
>>> search
>>> path in our variable environment, but with both storage type and
>>> partition.
>> OK, so user can configure environment variable to inform U-Boot where
>> to
>> look for firmware, good (although, this probably fails in early env,
>> dunno of that's a problem).
>>
> Without DTS, then you need to configure env variable, so that SPL and
> U-boot only know what storage type and partiton to look for firmware.

I guess that's fine ?

>> But why do we need the DT part of things ? I don't think we do need
>> it
>> at all.
>>
> Leverage the flexibility and benefits of the DT such as changing both
> storage type and partitions without changing the codes. 

DT is a hardware description. Does this describe hardware ? No
Chee, Tien Fong June 11, 2018, 2:13 p.m. UTC | #18
On Mon, 2018-06-11 at 16:03 +0200, Marek Vasut wrote:
> On 06/11/2018 03:55 PM, Chee, Tien Fong wrote:
> [...]
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > Linux firmware loading method is different with this
> > > > > > Linux loading firmware with
> > > > > > 1. Firmware search paths - which is hardcoded in root file
> > > > > > system
> > > > > > 2. Built-in firmware - part of kernel binaries
> > > > > > 
> > > > > > This patch loading firmware with
> > > > > > 1. Storage type and partition specified in DTS, but storage
> > > > > > type
> > > > > > can
> > > > > > be overridden dev instance and partition through U-boot
> > > > > > variable
> > > > > > environment.
> > > > > > 
> > > > > > Or:
> > > > > > 
> > > > > > 2. Storage type can be set through dev instance, and
> > > > > > partition
> > > > > > through
> > > > > > U-boot variable environment. No DTS is required.
> > > > > And why can we not do as Linux does ?
> > > > > 
> > > > Because we don't have root file system, but i have mimicked the
> > > > search
> > > > path in our variable environment, but with both storage type
> > > > and
> > > > partition.
> > > OK, so user can configure environment variable to inform U-Boot
> > > where
> > > to
> > > look for firmware, good (although, this probably fails in early
> > > env,
> > > dunno of that's a problem).
> > > 
> > Without DTS, then you need to configure env variable, so that SPL
> > and
> > U-boot only know what storage type and partiton to look for
> > firmware.
> I guess that's fine ?
> 
Yes, it is already supported in this patches.
> > 
> > > 
> > > But why do we need the DT part of things ? I don't think we do
> > > need
> > > it
> > > at all.
> > > 
> > Leverage the flexibility and benefits of the DT such as changing
> > both
> > storage type and partitions without changing the codes. 
> DT is a hardware description. Does this describe hardware ? No
> 
Okay, then i will remove DT part.
Marek Vasut June 11, 2018, 2:15 p.m. UTC | #19
On 06/11/2018 04:13 PM, Chee, Tien Fong wrote:
> On Mon, 2018-06-11 at 16:03 +0200, Marek Vasut wrote:
>> On 06/11/2018 03:55 PM, Chee, Tien Fong wrote:
>> [...]
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Linux firmware loading method is different with this
>>>>>>> Linux loading firmware with
>>>>>>> 1. Firmware search paths - which is hardcoded in root file
>>>>>>> system
>>>>>>> 2. Built-in firmware - part of kernel binaries
>>>>>>>
>>>>>>> This patch loading firmware with
>>>>>>> 1. Storage type and partition specified in DTS, but storage
>>>>>>> type
>>>>>>> can
>>>>>>> be overridden dev instance and partition through U-boot
>>>>>>> variable
>>>>>>> environment.
>>>>>>>
>>>>>>> Or:
>>>>>>>
>>>>>>> 2. Storage type can be set through dev instance, and
>>>>>>> partition
>>>>>>> through
>>>>>>> U-boot variable environment. No DTS is required.
>>>>>> And why can we not do as Linux does ?
>>>>>>
>>>>> Because we don't have root file system, but i have mimicked the
>>>>> search
>>>>> path in our variable environment, but with both storage type
>>>>> and
>>>>> partition.
>>>> OK, so user can configure environment variable to inform U-Boot
>>>> where
>>>> to
>>>> look for firmware, good (although, this probably fails in early
>>>> env,
>>>> dunno of that's a problem).
>>>>
>>> Without DTS, then you need to configure env variable, so that SPL
>>> and
>>> U-boot only know what storage type and partiton to look for
>>> firmware.
>> I guess that's fine ?
>>
> Yes, it is already supported in this patches.
>>>
>>>>
>>>> But why do we need the DT part of things ? I don't think we do
>>>> need
>>>> it
>>>> at all.
>>>>
>>> Leverage the flexibility and benefits of the DT such as changing
>>> both
>>> storage type and partitions without changing the codes. 
>> DT is a hardware description. Does this describe hardware ? No
>>
> Okay, then i will remove DT part.

Wait for feedback from sjg at least.
Simon Glass June 11, 2018, 7:38 p.m. UTC | #20
Hi,

On 11 June 2018 at 08:15, Marek Vasut <marex@denx.de> wrote:
> On 06/11/2018 04:13 PM, Chee, Tien Fong wrote:
>> On Mon, 2018-06-11 at 16:03 +0200, Marek Vasut wrote:
>>> On 06/11/2018 03:55 PM, Chee, Tien Fong wrote:
>>> [...]
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Linux firmware loading method is different with this
>>>>>>>> Linux loading firmware with
>>>>>>>> 1. Firmware search paths - which is hardcoded in root file
>>>>>>>> system
>>>>>>>> 2. Built-in firmware - part of kernel binaries
>>>>>>>>
>>>>>>>> This patch loading firmware with
>>>>>>>> 1. Storage type and partition specified in DTS, but storage
>>>>>>>> type
>>>>>>>> can
>>>>>>>> be overridden dev instance and partition through U-boot
>>>>>>>> variable
>>>>>>>> environment.
>>>>>>>>
>>>>>>>> Or:
>>>>>>>>
>>>>>>>> 2. Storage type can be set through dev instance, and
>>>>>>>> partition
>>>>>>>> through
>>>>>>>> U-boot variable environment. No DTS is required.
>>>>>>> And why can we not do as Linux does ?
>>>>>>>
>>>>>> Because we don't have root file system, but i have mimicked the
>>>>>> search
>>>>>> path in our variable environment, but with both storage type
>>>>>> and
>>>>>> partition.
>>>>> OK, so user can configure environment variable to inform U-Boot
>>>>> where
>>>>> to
>>>>> look for firmware, good (although, this probably fails in early
>>>>> env,
>>>>> dunno of that's a problem).
>>>>>
>>>> Without DTS, then you need to configure env variable, so that SPL
>>>> and
>>>> U-boot only know what storage type and partiton to look for
>>>> firmware.
>>> I guess that's fine ?
>>>
>> Yes, it is already supported in this patches.
>>>>
>>>>>
>>>>> But why do we need the DT part of things ? I don't think we do
>>>>> need
>>>>> it
>>>>> at all.
>>>>>
>>>> Leverage the flexibility and benefits of the DT such as changing
>>>> both
>>>> storage type and partitions without changing the codes.
>>> DT is a hardware description. Does this describe hardware ? No
>>>
>> Okay, then i will remove DT part.
>
> Wait for feedback from sjg at least.

I think using device tree is fine for this, but I suggest that the
binding file (when you add it) should mention that the node for this
driver should go in /chosen. That's what we use for settings, etc.

Things to do:
- Add a sandbox driver for this uclass, and a test in test/dm/...
- Add some documentation about it somehwere
- Add a device-tree binding file - see doc/device-tree-bindings

Regards,
Simon
Chee, Tien Fong June 12, 2018, 4:25 a.m. UTC | #21
On Mon, 2018-06-11 at 13:38 -0600, Simon Glass wrote:
> Hi,
> 
> On 11 June 2018 at 08:15, Marek Vasut <marex@denx.de> wrote:
> > 
> > On 06/11/2018 04:13 PM, Chee, Tien Fong wrote:
> > > 
> > > On Mon, 2018-06-11 at 16:03 +0200, Marek Vasut wrote:
> > > > 
> > > > On 06/11/2018 03:55 PM, Chee, Tien Fong wrote:
> > > > [...]
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Linux firmware loading method is different with this
> > > > > > > > > Linux loading firmware with
> > > > > > > > > 1. Firmware search paths - which is hardcoded in root
> > > > > > > > > file
> > > > > > > > > system
> > > > > > > > > 2. Built-in firmware - part of kernel binaries
> > > > > > > > > 
> > > > > > > > > This patch loading firmware with
> > > > > > > > > 1. Storage type and partition specified in DTS, but
> > > > > > > > > storage
> > > > > > > > > type
> > > > > > > > > can
> > > > > > > > > be overridden dev instance and partition through U-
> > > > > > > > > boot
> > > > > > > > > variable
> > > > > > > > > environment.
> > > > > > > > > 
> > > > > > > > > Or:
> > > > > > > > > 
> > > > > > > > > 2. Storage type can be set through dev instance, and
> > > > > > > > > partition
> > > > > > > > > through
> > > > > > > > > U-boot variable environment. No DTS is required.
> > > > > > > > And why can we not do as Linux does ?
> > > > > > > > 
> > > > > > > Because we don't have root file system, but i have
> > > > > > > mimicked the
> > > > > > > search
> > > > > > > path in our variable environment, but with both storage
> > > > > > > type
> > > > > > > and
> > > > > > > partition.
> > > > > > OK, so user can configure environment variable to inform U-
> > > > > > Boot
> > > > > > where
> > > > > > to
> > > > > > look for firmware, good (although, this probably fails in
> > > > > > early
> > > > > > env,
> > > > > > dunno of that's a problem).
> > > > > > 
> > > > > Without DTS, then you need to configure env variable, so that
> > > > > SPL
> > > > > and
> > > > > U-boot only know what storage type and partiton to look for
> > > > > firmware.
> > > > I guess that's fine ?
> > > > 
> > > Yes, it is already supported in this patches.
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > But why do we need the DT part of things ? I don't think we
> > > > > > do
> > > > > > need
> > > > > > it
> > > > > > at all.
> > > > > > 
> > > > > Leverage the flexibility and benefits of the DT such as
> > > > > changing
> > > > > both
> > > > > storage type and partitions without changing the codes.
> > > > DT is a hardware description. Does this describe hardware ? No
> > > > 
> > > Okay, then i will remove DT part.
> > Wait for feedback from sjg at least.
> I think using device tree is fine for this, but I suggest that the
> binding file (when you add it) should mention that the node for this
> driver should go in /chosen. That's what we use for settings, etc.
> 
Okay, sure. So, we agree supporting device tree is good to go.

> Things to do:
> - Add a sandbox driver for this uclass, and a test in test/dm/...
> - Add some documentation about it somehwere
> - Add a device-tree binding file - see doc/device-tree-bindings
> 
Okay, let me try.

> Regards,
> Simon
diff mbox series

Patch

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index be900cf..59f716b 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -268,4 +268,15 @@  config GDSYS_RXAUI_CTRL
 	depends on MISC
 	help
 	  Support gdsys FPGA's RXAUI control.
+
+config FS_LOADER
+	bool "Enable loader driver for file system"
+	depends on DM
+	help
+	  This is file system generic loader which can be used to load
+	  the file image from the storage into target such as memory.
+
+	  The consumer driver would then use this loader to program whatever,
+	  ie. the FPGA device.
+
 endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e362609..74364a0 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -53,3 +53,4 @@  obj-$(CONFIG_ROCKCHIP_EFUSE) += rockchip-efuse.o
 obj-$(CONFIG_STM32_RCC) += stm32_rcc.o
 obj-$(CONFIG_SYS_DPAA_QBMAN) += fsl_portals.o
 obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o
+obj-$(CONFIG_FS_LOADER) += fs_loader.o
diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
new file mode 100644
index 0000000..127f7f1
--- /dev/null
+++ b/drivers/misc/fs_loader.c
@@ -0,0 +1,240 @@ 
+/*
+ * Copyright (C) 2018 Intel Corporation <www.intel.com>
+ *
+ * SPDX-License-Identifier:    GPL-2.0
+ */
+#include <common.h>
+#include <dm.h>
+#include <errno.h>
+#include <fdtdec.h>
+#include <fs.h>
+#include <fs_loader.h>
+#include <linux/string.h>
+#include <malloc.h>
+#include <spl.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct firmware_priv {
+	const char *name;	/* Filename */
+	u32 offset;		/* Offset of reading a file */
+};
+
+static int select_fs_dev(struct udevice *dev)
+{
+	int ret;
+	struct device_platdata *plat;
+
+	plat = dev->platdata;
+	if (!strcmp("mmc", plat->name)) {
+		ret = fs_set_blk_dev("mmc", plat->devpart, FS_TYPE_ANY);
+	} else if (!strcmp("usb", plat->name)) {
+		ret = fs_set_blk_dev("usb", plat->devpart, FS_TYPE_ANY);
+	} else if (!strcmp("sata", plat->name)) {
+		ret = fs_set_blk_dev("sata", plat->devpart, FS_TYPE_ANY);
+	} else if (!strcmp("ubi", plat->name)) {
+		if (plat->ubivol)
+			ret = fs_set_blk_dev("ubi", NULL, FS_TYPE_UBIFS);
+		else
+			ret = -ENODEV;
+	} else {
+		debug("Error: unsupported storage device.\n");
+		return -ENODEV;
+	}
+
+	if (ret)
+		debug("Error: could not access storage.\n");
+
+	return ret;
+}
+
+static void set_storage_devpart(struct udevice *dev, char *devpart)
+{
+	struct device_platdata *plat;
+
+	plat = dev->platdata;
+	plat->devpart = devpart;
+}
+
+static void set_storage_mtdpart(struct udevice *dev, char *mtdpart)
+{
+	struct device_platdata *plat;
+
+	plat = dev->platdata;
+	plat->mtdpart = mtdpart;
+}
+
+static void set_storage_ubivol(struct udevice *dev, char *ubivol)
+{
+	struct device_platdata *plat;
+
+	plat = dev->platdata;
+	plat->ubivol = ubivol;
+}
+
+/**
+ * _request_firmware_prepare - Prepare firmware struct.
+ *
+ * @firmware_p: Pointer to pointer to firmware image.
+ * @name: Name of firmware file.
+ * @dbuf: Address of buffer to load firmware into.
+ * @size: Size of buffer.
+ * @offset: Offset of a file for start reading into buffer.
+ *
+ * Return: Negative value if fail, 0 for successful.
+ */
+static int _request_firmware_prepare(struct firmware **firmware_p,
+				    const char *name, void *dbuf,
+				    size_t size, u32 offset)
+{
+	struct firmware *firmware;
+	struct firmware_priv *fw_priv;
+
+	*firmware_p = NULL;
+
+	if (!name || name[0] == '\0')
+		return -EINVAL;
+
+	firmware = calloc(1, sizeof(*firmware));
+	if (!firmware)
+		return -ENOMEM;
+
+	fw_priv = calloc(1, sizeof(*fw_priv));
+	if (!fw_priv) {
+		free(firmware);
+		return -ENOMEM;
+	}
+
+	fw_priv->name = name;
+	fw_priv->offset = offset;
+	firmware->data = dbuf;
+	firmware->size = size;
+	firmware->priv = fw_priv;
+	*firmware_p = firmware;
+
+	return 0;
+}
+
+/**
+ * fw_get_filesystem_firmware - load firmware into an allocated buffer.
+ * @dev: An instance of a driver.
+ * @firmware_p: pointer to firmware image.
+ *
+ * Return: Size of total read, negative value when error.
+ */
+static int fw_get_filesystem_firmware(struct udevice *dev,
+				     struct firmware *firmware_p)
+{
+	struct firmware_priv *fw_priv = NULL;
+	loff_t actread;
+	char *dev_part, *ubi_mtdpart, *ubi_volume;
+	int ret;
+
+	dev_part = env_get("fw_dev_part");
+	if (dev_part)
+		set_storage_devpart(dev, dev_part);
+
+	ubi_mtdpart = env_get("fw_ubi_mtdpart");
+	if (ubi_mtdpart)
+		set_storage_mtdpart(dev, ubi_mtdpart);
+
+	ubi_volume = env_get("fw_ubi_volume");
+	if (ubi_volume)
+		set_storage_ubivol(dev, ubi_volume);
+
+	ret = select_fs_dev(dev);
+	if (ret)
+		goto out;
+
+	fw_priv = firmware_p->priv;
+
+	ret = fs_read(fw_priv->name, (ulong)firmware_p->data, fw_priv->offset,
+		     firmware_p->size, &actread);
+	if (ret) {
+		debug("Error: %d Failed to read %s from flash %lld != %d.\n",
+		      ret, fw_priv->name, actread, firmware_p->size);
+	} else {
+		ret = actread;
+	}
+
+out:
+	return ret;
+}
+
+/**
+ * request_firmware_into_buf - Load firmware into a previously allocated buffer.
+ * @dev: An instance of a driver.
+ * @firmware_p: Pointer to firmware image.
+ * @name: Name of firmware file.
+ * @buf: Address of buffer to load firmware into.
+ * @size: Size of buffer.
+ * @offset: Offset of a file for start reading into buffer.
+ *
+ * The firmware is loaded directly into the buffer pointed to by @buf and
+ * the @firmware_p data member is pointed at @buf.
+ *
+ * Return: Size of total read, negative value when error.
+ */
+int request_firmware_into_buf(struct udevice *dev,
+			      struct firmware **firmware_p,
+			      const char *name,
+			      void *buf, size_t size, u32 offset)
+{
+	int ret;
+
+	ret = _request_firmware_prepare(firmware_p, name, buf, size, offset);
+	if (ret < 0) /* error */
+		return ret;
+
+	ret = fw_get_filesystem_firmware(dev, *firmware_p);
+
+	return ret;
+}
+
+static int fs_loader_ofdata_to_platdata(struct udevice *dev)
+{
+	struct device_platdata *plat;
+	const void *blob;
+	int node;
+
+	plat = dev->platdata;
+	blob = gd->fdt_blob;
+	node = dev_of_offset(dev);
+	plat->name = (char *)fdt_getprop(blob, node,
+				"storage_device", NULL);
+
+	plat->devpart = (char *)fdt_getprop(blob, node,
+				"devpart", NULL);
+
+	plat->mtdpart = (char *)fdt_getprop(blob, node,
+				"mtdpart", NULL);
+
+	plat->ubivol = (char *)fdt_getprop(blob, node,
+				"ubivol", NULL);
+
+	return 0;
+}
+
+static int fs_loader_probe(struct udevice *dev)
+{
+	return 0;
+};
+
+static const struct udevice_id fs_loader_ids[] = {
+	{ .compatible = "fs_loader"},
+	{ }
+};
+
+U_BOOT_DRIVER(fs_loader) = {
+	.name			= "fs_loader",
+	.id			= UCLASS_FS_FIRMWARE_LOADER,
+	.of_match		= fs_loader_ids,
+	.probe			= fs_loader_probe,
+	.ofdata_to_platdata	= fs_loader_ofdata_to_platdata,
+	.platdata_auto_alloc_size	= sizeof(struct device_platdata),
+};
+
+UCLASS_DRIVER(fs_loader) = {
+	.id		= UCLASS_FS_FIRMWARE_LOADER,
+	.name		= "fs_loader",
+};
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index d7f9df3..39e88ac 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -36,6 +36,7 @@  enum uclass_id {
 	UCLASS_DMA,		/* Direct Memory Access */
 	UCLASS_EFI,		/* EFI managed devices */
 	UCLASS_ETH,		/* Ethernet device */
+	UCLASS_FS_FIRMWARE_LOADER,		/* Generic loader */
 	UCLASS_GPIO,		/* Bank of general-purpose I/O pins */
 	UCLASS_FIRMWARE,	/* Firmware */
 	UCLASS_I2C,		/* I2C bus */
diff --git a/include/fs_loader.h b/include/fs_loader.h
new file mode 100644
index 0000000..0f0ea00
--- /dev/null
+++ b/include/fs_loader.h
@@ -0,0 +1,28 @@ 
+/*
+ * Copyright (C) 2018 Intel Corporation <www.intel.com>
+ *
+ * SPDX-License-Identifier:    GPL-2.0
+ */
+#ifndef _FS_LOADER_H_
+#define _FS_LOADER_H_
+
+#include <dm.h>
+
+struct firmware {
+	size_t size;		/* Size of a file */
+	const u8 *data;		/* Buffer for file */
+	void *priv;		/* Firmware loader private fields */
+};
+
+struct device_platdata {
+	char *name;	/* Such as mmc, usb,and sata. */
+	char *devpart;  /* Use the load command dev:part conventions */
+	char *mtdpart;	/* MTD partition for ubi part */
+	char *ubivol;	/* UBI volume-name for ubifsmount */
+};
+
+int request_firmware_into_buf(struct udevice *dev,
+			      struct firmware **firmware_p,
+			      const char *name,
+			      void *buf, size_t size, u32 offset);
+#endif