On 27.7.2018 10:40, Chee, Tien Fong wrote:
> On Thu, 2018-07-26 at 11:03 +0200, Michal Simek wrote:
>> On 25.7.2018 18:03, Tom Rini wrote:
>>>
>>> On Wed, Jul 25, 2018 at 09:47:17AM -0600, Simon Glass wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 25 July 2018 at 03:48, Michal Simek <michal.si...@xilinx.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 25.7.2018 08:31, Chee, Tien Fong wrote:
>>>>>>
>>>>>> On Wed, 2018-07-18 at 16:48 +0200, Michal Simek wrote:
>>>>>>>
>>>>>>> On 6.7.2018 10:28, tien.fong.c...@intel.com wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> From: Tien Fong Chee <tien.fong.c...@intel.com>
>>>>>>>>
>>>> [...]
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Also that DT binding is quite weird and I don't think you
>>>>>>> will get
>>>>>>> ACK
>>>>>>> for this from device tree community at all. I think that
>>>>>>> calling via
>>>>>>> platdata and avoid DT nodes would be better way to go.
>>>>>> Why do you think DT binding is weird? The DT is designed
>>>>>> based on Simon
>>>>>> proposal, and i believe following the rules in DTS spec.
>>>>>> There are some DT benefits with current design, i think
>>>>>> someone may be
>>>>>> maintainer need to made the final decision on the design.
>>>>> It is software configuration in file which should mostly
>>>>> describe
>>>>> hardware and state for hardware configuration.
>>>>>
>>>>> Your fs_loader node is purely describe sw configuration which
>>>>> shouldn't
>>>>> be here.
>>>>> You have there run time configuration via variables. I think
>>>>> using only
>>>>> this way is enough. Default variables will match what you would
>>>>> want to
>>>>> add to DT.
>>>> I think DT makes sense in the U-Boot context.
>>>>
>>>> We don't have a user space to handle policy decisions, and the
>>>> 'chosen' node is a good place to configure these common features.
>>>>
>>>> While you can argue that the partition or filesystem where an
>>>> image
>>>> comes from is a software config, it is something that has to be
>>>> configured. It has impact on hardware too, since the FPGA has to
>>>> get
>>>> its firmware from somewhere. We use the chosen node to specify
>>>> the
>>>> UART to use, and this is no different. Again, we don't have user-
>>>> space
>>>> config files in U-Boot.
>>>>
>>>> This argument comes up from time to time and I'd really like to
>>>> put it
>>>> to bed for U-Boot. I understand that Linux has its own approach
>>>> and
>>>> rules, but in some cases they serve U-Boot poorly.
>>> I want to second this as well. So long as we're using our prefix
>>> and
>>> we've thought through and discussed what we're trying to do here,
>>> it's
>>> OK to do things that might not be accepted for Linux.
>>>
>> I have not a problem with using chosen node with u-boot prefix
>> properties and my colleague hopefully with finish work about moving
>> u-boot,dm-pre-reloc; to chosen node where it should be (because
>> current
>> solution has also problem with ordering).
>>
>> In this loader case doc is saying that you can rewrite it with
>> variables
>> on the prompt (or via script).
>> For cases that you want to autodetect platform and pass/load correct
>> dtb
>> which setup u-boot this can be problematic and using DT is could be
>> considered as easier for use.
>>
>> In this case this is what was proposed:
>>
>> + fs_loader0: fs-loader@0 {
>> + u-boot,dm-pre-reloc;
>> + compatible = "u-boot,fs-loader";
>> + phandlepart = <&mmc 1>;
>> + };
>>
>> + fs_loader1: fs-loader@1 {
>> + u-boot,dm-pre-reloc;
>> + compatible = "u-boot,fs-loader";
>> + mtdpart = "UBI",
>> + ubivol = "ubi0";
>> + };
>>
>> u-boot,dm-pre-reloc; requires DM_FLAG_PRE_RELOC which is not setup
>> for
>> this driver - it means this should be here.
> You are right, i missed this one. The intention of design enables user
> to call any loader with default storage through the sequence number if
> fs loader is not defined in chosen. For example, there is a case where
> system loading the file from SDMMC, NAND and QSPI.
>>
>> compatible = "u-boot,fs-loader"; - bind and probe are empty that's
>> why
>> this is only used for filling platdata but driver has no user that's
>> why
>> this is unused till someone calls that functions.
>>
>> phandlepart/mtdpart/ubivol is just for setup.
> There are some benefits with driver model:
> 1. Saving space, calling when need.
> 2. Handle memory allocation and deallocation automatically.
>>
>> For the first case you can just use in chosen node:
>> u-boot,fs-loader = <&mmc 1>;
>>
>> And for UBIfs. I have never played with that but I expect it
>> shouldn't
>> be big problem to describe it differently too (something like)
>> u-boot,fs-loader = <0 ubi0>;
> Need consider description for UBIFS, using fs-loader seems not working
> for UBIFS, since more arguments such as mtdpartition and mtd volume
> need passing into driver. In order to avoid messing, fs_loader can act
> the pointer to the chosen.
>
> Anyway, i have no strong opinion with driver designed via platdata or
> driver model if we can resolve the problem for UBIFS and maintainers
> agree with it.
The driver is still using DM. It is only about way how driver is binded.
Take a look for example on board/hisilicon/hikey/hikey.c
Thanks,
Michal
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
