[U-Boot] [PATCH 0/3] ARM: imx: enhance support for the cm-fx6 module

Igor Grinberg grinberg at compulab.co.il
Wed Jun 22 17:46:21 CEST 2016


Hi Christopher,

Thanks for doing this work.

On 06/19/2016 06:44 PM, Christopher Spinrath wrote:
> Hi,
> 
> this series aims at enhancing support for the cm-fx6 module. In
> particular, with respect to the upstream linux kernel.
> 
> The first patch improves the default environment. It is non-functional
> but makes it more convenient to adapt certain settings.
> 
> The later two patches add mtd partition support for the on-board spi
> flash chip. They pick up the discussion about specifying a default
> partitioning in the device tree from here [1]. In short: adding the
> default partitioning to the device tree was rejected by the linux/
> device tree community during mainlining large parts of the device tree.
> It was proposed to implement the partition/mtd handling in u-boot.
> On the other hand, it was argued that the flash chip becomes some
> kind of "black-box" since there will be no partition labeling (in
> particular, with old u-boot versions).
> 
> IMHO defining the mtd partitioning has the following (dis-)advantages:

You mean defining it in U-Boot instead of upstream DT.

> 
> Advantages:
> - It is easier for the user to change the partitioning (e.g. to use
>   the unsued 1MB free space).

I know it says reserved, but that is not exactly unused...
It is intended to hold a splash screen of up to 1MB size and may be other
things (like dtb, etc.).
By the time the partitioning layout was defined, it was still unclear
what requirements of that additional space will be.
So it was called reserved to provide a kind of warning to the users as
it might be used at some point.

> 
> - The flash ship is used entirely for u-boot.

Close, but not precise...
The spi flash chip is used for all boot purposes, so it might be beyond
U-Boot.

>   So it is quite natural
>   that u-boot manages it. Also, moving the partition table to it
>   allows us to change the layout in future versions of u-boot (almost
>   independently of the kernel - there are still non-device tree kernels).

Please don't change the layout as it will break backwards compatibility.
Also, there is not much you can change.

> 
> - U-Boot becomes the single point of definition for all device tree
>   kernels. Otherwise, each kernel (vendor vs. upstream + version)
>   would ship its own partitioning.

True.

>   Moreover, u-boot has to know
>   something about the partitioning, too, because it has to know where
>   the environment is saved.

It does, although the env address is hardcoded, but it should not be
changed.
The reason for providing a partition for it is purely for Linux to able
to change the environment variables.

> 
> Disadvantages:
> - Users of the upstream linux kernel have to use a recent u-boot
>   version to avoid the "black box" effect. A concrete impact is
>   that the update routine (described/proposed by CompuLab) does
>   not work out of the box with older u-boot versions.

True.

> 
> - Updating u-boot is something users might not want or miss to do.
> 
> However, I think nowadays it is ok to demand a recent u-boot in
> combination with the upstream kernel. The cm-fx6 wouldn't be
> the first board doing so. Hence, I propose these patches here.
> 
> Cheers,
> Christopher
> 
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/434562.html
> 
> 

-- 
Regards,
Igor.


More information about the U-Boot mailing list