ARM: imx: enhance support for the cm-fx6 module
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest3 patches 0 repliesNew
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | ARM: configs: cm_fx6: improve default environment | +0 | 0 replies | |
| 2/3 | ARM: board: cm_fx6: fixup mtd partitions in the fdt | +0 | 0 replies | |
| 2/3 | ARM: board: cm_fx6: fixup mtd partitions in the fdt | +0 | 4 replies | |
| 2/3 | ARM: board: cm_fx6: fixup mtd partitions in the fdt | +0 | 0 replies | |
| 3/3 | ARM: configs: cm_fx6: add mtd support | +0 | 0 replies | |
| 3/3 | ARM: configs: cm_fx6: add mtd support | +0 | 0 replies |
Reviews trailers per patch
1 of 6 patches has a Reviewed-by or Acked-by.
| Patch | Igor Grinberg |
|---|---|
| 1/3 | R-b |
| 2/3 | |
| 2/3 | |
| 2/3 | |
| 3/3 | |
| 3/3 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [U-Boot] [PATCH 0/3] ARM: imx: enhance support for the cm-fx6 module
Hi Christopher,
Thanks for doing this work.
Quoted 18 lines · Christopher Spinrath
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).
Quoted 1 line
IMHO defining the mtd partitioning has the following (dis-)advantages:
You mean defining it in U-Boot instead of upstream DT.
Quoted 4 lines
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.
Quoted 2 lines
- 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.
Quoted 4 lines
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.
Quoted 4 lines
- 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.
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 13 lines
- 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
Signature · 2 lines
Regards, Igor.