Re: [U-Boot] [PATCH v3 08/14] fit: fdt overlays doc

[Pantelis Antoniou]

Hi Lukasz,

On Wed, 2017-09-06 at 21:06 +0200, Łukasz Majewski wrote:
> On 09/04/2017 10:12 PM, Pantelis Antoniou wrote:
> > Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
> > ---
> >   doc/uImage.FIT/command_syntax_extensions.txt |  12 +-
> >   doc/uImage.FIT/overlay-fdt-boot.txt  | 221 
> > +++
> >   doc/uImage.FIT/source_file_format.txt|   6 +-
> >   3 files changed, 236 insertions(+), 3 deletions(-)
> >   create mode 100644 doc/uImage.FIT/overlay-fdt-boot.txt
> > 
> > diff --git a/doc/uImage.FIT/command_syntax_extensions.txt 
> > b/doc/uImage.FIT/command_syntax_extensions.txt
> > index 6c99b1c..676f992 100644
> > --- a/doc/uImage.FIT/command_syntax_extensions.txt
> > +++ b/doc/uImage.FIT/command_syntax_extensions.txt
> > @@ -36,7 +36,7 @@ Old uImage:
> >   New uImage:
> >   8.  bootm 
> >   9.  bootm []:
> > -10. bootm []#
> > +10. bootm []#[#<extra-conf[#...]]
> >   11. bootm []: []:
> >   12. bootm []: []: []:
> >   13. bootm []: []: 
> > @@ -129,6 +129,12 @@ following syntax:
> >   - new uImage configuration specification
> >   #
> >   
> > +- new uImage configuration specification with extra configuration 
> > components
> > +#[#[#..]]
> > +
> > +The extra configuration currently is supported only for additional device 
> > tree
> > +overlays to apply on the base device tree supplied by the first 
> > configuration
> > +unit.
> >   
> >   Examples:
> >   
> > @@ -138,6 +144,10 @@ bootm 20:kernel@1
> >   - boot configuration "cfg@1" from a new uImage located at 20:
> >   bootm 20#cfg@1
> >   
> > +- boot configuration "cfg@1" with extra "cfg@2" from a new uImage located
> > +  at 20:
> > +bootm 20#cfg@1#cfg@2
> > +
> >   - boot "kernel@1" from a new uImage at 20 with initrd "ramdisk@2" 
> > found in
> > some other new uImage stored at address 80:
> >   bootm 20:kernel@1 80:ramdisk@2
> > diff --git a/doc/uImage.FIT/overlay-fdt-boot.txt 
> > b/doc/uImage.FIT/overlay-fdt-boot.txt
> > new file mode 100644
> > index 000..dbdf2a1
> > --- /dev/null
> > +++ b/doc/uImage.FIT/overlay-fdt-boot.txt
> > @@ -0,0 +1,221 @@
> > +U-Boot FDT Overlay usage
> > +
> > +
> > +Introduction
> > +
> > +In many cases it is desirable to have a single FIT image support a 
> > multitude
> > +of similar boards and their expansion options. The same kernel on DT 
> > enabled
> > +platforms can support this easily enough by providing a DT blob upon boot
> > +that matches the desired configuration.
> > +
> > +Configuration without overlays
> > +--
> > +
> > +Take a hypothetical board named 'foo' where there are different supported
> > +revisions, reva and revb. Assume that both board revisions can use add a 
> > bar
> > +add-on board, while only the revb board can use a baz add-on board.
> > +
> > +Without using overlays the configuration would be as follows for every 
> > case.
> > +
> > +   /dts-v1/;
> > +   / {
> > +   images {
> > +   kernel@1 {
> > +   data = /incbin/("./zImage");
> > +   type = "kernel";
> > +   arch = "arm";
> > +   os = "linux";
> > +   load = <0x8200>;
> > +   entry = <0x8200>;
> > +   };
> > +   fdt@1 {
> > +   data = /incbin/("./foo-reva.dtb");
> > +   type = "flat_dt";
> > +   arch = "arm";
> > +   };
> > +   fdt@2 {
> > +   data = /incbin/("./foo-revb.dtb");
> > +   type = "flat_dt";
> > +   arch = "arm";
> > +   };
> > +   fdt@3 {
> > +   data = /incbin/("./foo-reva-bar.dtb");
> > +   type = "flat_dt";
> > +   arch = "arm";
> > +   };
> > +   fdt@4 {
> > +   dat

[U-Boot] [PATCH v3 12/14] config: sandbox: Add unit tests

[Pantelis Antoniou]

Add unit tests for sandbox default config.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 configs/sandbox_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 4c4e480..54120c2 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -189,7 +189,9 @@ CONFIG_CMD_DHRYSTONE=y
 CONFIG_TPM=y
 CONFIG_LZ4=y
 CONFIG_ERRNO_STR=y
+CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_UNIT_TEST=y
 CONFIG_UT_TIME=y
 CONFIG_UT_DM=y
 CONFIG_UT_ENV=y
+CONFIG_UT_OVERLAY=y
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 08/14] fit: fdt overlays doc

[Pantelis Antoniou]

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 doc/uImage.FIT/command_syntax_extensions.txt |  12 +-
 doc/uImage.FIT/overlay-fdt-boot.txt  | 221 +++
 doc/uImage.FIT/source_file_format.txt|   6 +-
 3 files changed, 236 insertions(+), 3 deletions(-)
 create mode 100644 doc/uImage.FIT/overlay-fdt-boot.txt

diff --git a/doc/uImage.FIT/command_syntax_extensions.txt 
b/doc/uImage.FIT/command_syntax_extensions.txt
index 6c99b1c..676f992 100644
--- a/doc/uImage.FIT/command_syntax_extensions.txt
+++ b/doc/uImage.FIT/command_syntax_extensions.txt
@@ -36,7 +36,7 @@ Old uImage:
 New uImage:
 8.  bootm 
 9.  bootm []:
-10. bootm []#
+10. bootm []#[#<extra-conf[#...]]
 11. bootm []: []:
 12. bootm []: []: []:
 13. bootm []: []: 
@@ -129,6 +129,12 @@ following syntax:
 - new uImage configuration specification
 #
 
+- new uImage configuration specification with extra configuration components
+#[#[#..]]
+
+The extra configuration currently is supported only for additional device tree
+overlays to apply on the base device tree supplied by the first configuration
+unit.
 
 Examples:
 
@@ -138,6 +144,10 @@ bootm 20:kernel@1
 - boot configuration "cfg@1" from a new uImage located at 20:
 bootm 20#cfg@1
 
+- boot configuration "cfg@1" with extra "cfg@2" from a new uImage located
+  at 20:
+bootm 20#cfg@1#cfg@2
+
 - boot "kernel@1" from a new uImage at 20 with initrd "ramdisk@2" found in
   some other new uImage stored at address 80:
 bootm 20:kernel@1 80:ramdisk@2
diff --git a/doc/uImage.FIT/overlay-fdt-boot.txt 
b/doc/uImage.FIT/overlay-fdt-boot.txt
new file mode 100644
index 000..dbdf2a1
--- /dev/null
+++ b/doc/uImage.FIT/overlay-fdt-boot.txt
@@ -0,0 +1,221 @@
+U-Boot FDT Overlay usage
+
+
+Introduction
+
+In many cases it is desirable to have a single FIT image support a multitude
+of similar boards and their expansion options. The same kernel on DT enabled
+platforms can support this easily enough by providing a DT blob upon boot
+that matches the desired configuration.
+
+Configuration without overlays
+--
+
+Take a hypothetical board named 'foo' where there are different supported
+revisions, reva and revb. Assume that both board revisions can use add a bar
+add-on board, while only the revb board can use a baz add-on board.
+
+Without using overlays the configuration would be as follows for every case.
+
+   /dts-v1/;
+   / {
+   images {
+   kernel@1 {
+   data = /incbin/("./zImage");
+   type = "kernel";
+   arch = "arm";
+   os = "linux";
+   load = <0x8200>;
+   entry = <0x8200>;
+   };
+   fdt@1 {
+   data = /incbin/("./foo-reva.dtb");
+   type = "flat_dt";
+   arch = "arm";
+   };
+   fdt@2 {
+   data = /incbin/("./foo-revb.dtb");
+   type = "flat_dt";
+   arch = "arm";
+   };
+   fdt@3 {
+   data = /incbin/("./foo-reva-bar.dtb");
+   type = "flat_dt";
+   arch = "arm";
+   };
+   fdt@4 {
+   data = /incbin/("./foo-revb-bar.dtb");
+   type = "flat_dt";
+   arch = "arm";
+   };
+   fdt@5 {
+   data = /incbin/("./foo-revb-baz.dtb");
+   type = "flat_dt";
+   arch = "arm";
+   };
+   fdt@6 {
+   data = /incbin/("./foo-revb-bar-baz.dtb");
+   type = "flat_dt";
+   arch = "arm";
+   };
+   };
+
+   configurations {
+   default = "foo-reva.dtb;
+   foo-reva.dtb {
+   kernel = "kernel@1";
+   fdt = "fdt@1";
+   };
+   foo-revb.dtb {
+   kernel = "kernel@1";
+  

[U-Boot] [PATCH v3 14/14] test: overlay: Add unit test for stacked overlay

[Pantelis Antoniou]

Verify that stacked overlays work.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 test/overlay/Makefile |  1 +
 test/overlay/cmd_ut_overlay.c | 34 ++-
 test/overlay/test-fdt-overlay-stacked.dts | 21 +++
 3 files changed, 55 insertions(+), 1 deletion(-)
 create mode 100644 test/overlay/test-fdt-overlay-stacked.dts

diff --git a/test/overlay/Makefile b/test/overlay/Makefile
index 907f085..416645c 100644
--- a/test/overlay/Makefile
+++ b/test/overlay/Makefile
@@ -13,3 +13,4 @@ DTC_FLAGS += -@
 # DT overlays
 obj-y += test-fdt-base.dtb.o
 obj-y += test-fdt-overlay.dtb.o
+obj-y += test-fdt-overlay-stacked.dtb.o
diff --git a/test/overlay/cmd_ut_overlay.c b/test/overlay/cmd_ut_overlay.c
index 7106f42..24891ee 100644
--- a/test/overlay/cmd_ut_overlay.c
+++ b/test/overlay/cmd_ut_overlay.c
@@ -20,6 +20,7 @@
 
 extern u32 __dtb_test_fdt_base_begin;
 extern u32 __dtb_test_fdt_overlay_begin;
+extern u32 __dtb_test_fdt_overlay_stacked_begin;
 
 static int ut_fdt_getprop_u32_by_index(void *fdt, const char *path,
const char *name, int index,
@@ -201,6 +202,19 @@ static int fdt_overlay_local_phandles(struct 
unit_test_state *uts)
 }
 OVERLAY_TEST(fdt_overlay_local_phandles, 0);
 
+static int fdt_overlay_stacked(struct unit_test_state *uts)
+{
+   void *fdt = uts->priv;
+   u32 val = 0;
+
+   ut_assertok(ut_fdt_getprop_u32(fdt, "/new-local-node",
+  "stacked-test-int-property", ));
+   ut_asserteq(43, val);
+
+   return CMD_RET_SUCCESS;
+}
+OVERLAY_TEST(fdt_overlay_stacked, 0);
+
 int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
struct unit_test *tests = ll_entry_start(struct unit_test,
@@ -210,7 +224,8 @@ int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
struct unit_test *test;
void *fdt_base = &__dtb_test_fdt_base_begin;
void *fdt_overlay = &__dtb_test_fdt_overlay_begin;
-   void *fdt_base_copy, *fdt_overlay_copy;
+   void *fdt_overlay_stacked = &__dtb_test_fdt_overlay_stacked_begin;
+   void *fdt_base_copy, *fdt_overlay_copy, *fdt_overlay_stacked_copy;
 
uts = calloc(1, sizeof(*uts));
if (!uts)
@@ -228,6 +243,10 @@ int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
if (!fdt_overlay_copy)
return -ENOMEM;
 
+   fdt_overlay_stacked_copy = malloc(FDT_COPY_SIZE);
+   if (!fdt_overlay_stacked_copy)
+   return -ENOMEM;
+
/*
 * Resize the FDT to 4k so that we have room to operate on
 *
@@ -245,9 +264,21 @@ int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
ut_assertok(fdt_open_into(fdt_overlay, fdt_overlay_copy,
  FDT_COPY_SIZE));
 
+   /*
+* Resize the stacked overlay to 4k so that we have room to operate on
+*
+* (and relocate it since the memory might be mapped
+* read-only)
+*/
+   ut_assertok(fdt_open_into(fdt_overlay_stacked, fdt_overlay_stacked_copy,
+ FDT_COPY_SIZE));
+
/* Apply the overlay */
ut_assertok(fdt_overlay_apply(fdt_base_copy, fdt_overlay_copy));
 
+   /* Apply the stacked overlay */
+   ut_assertok(fdt_overlay_apply(fdt_base_copy, fdt_overlay_stacked_copy));
+
if (argc == 1)
printf("Running %d environment tests\n", n_ents);
 
@@ -263,6 +294,7 @@ int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 
printf("Failures: %d\n", uts->fail_count);
 
+   free(fdt_overlay_stacked_copy);
free(fdt_overlay_copy);
free(fdt_base_copy);
free(uts);
diff --git a/test/overlay/test-fdt-overlay-stacked.dts 
b/test/overlay/test-fdt-overlay-stacked.dts
new file mode 100644
index 000..9fb7c7b
--- /dev/null
+++ b/test/overlay/test-fdt-overlay-stacked.dts
@@ -0,0 +1,21 @@
+/*
+ * Copyright (c) 2016 NextThing Co
+ * Copyright (c) 2016 Free Electrons
+ * Copyright (c) 2018 Konsulko Group
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+/plugin/;
+
+/ {
+   /* Test that we can reference an overlay symbol */
+   fragment@0 {
+   target = <>;
+
+   __overlay__ {
+   stacked-test-int-property = <43>;
+   };
+   };
+};
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 03/14] fdt: Switch to using the verbose overlay application method

[Pantelis Antoniou]

The verbose overlay application method prints out more helpful
messages, so switch to it.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 cmd/fdt.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/cmd/fdt.c b/cmd/fdt.c
index 118613f..362a621 100644
--- a/cmd/fdt.c
+++ b/cmd/fdt.c
@@ -669,11 +669,10 @@ static int do_fdt(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
if (!fdt_valid())
return CMD_RET_FAILURE;
 
-   ret = fdt_overlay_apply(working_fdt, blob);
-   if (ret) {
-   printf("fdt_overlay_apply(): %s\n", fdt_strerror(ret));
+   /* apply method prints messages on error */
+   ret = fdt_overlay_apply_verbose(working_fdt, blob);
+   if (ret)
return CMD_RET_FAILURE;
-   }
}
 #endif
/* resize the fdt */
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 11/14] dtbo: make dtbos special

[Pantelis Antoniou]

Special rule for dtbo generation

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 scripts/Makefile.lib | 17 +
 1 file changed, 17 insertions(+)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 9ce47b4..2a7ed70 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -321,6 +321,23 @@ $(obj)/%.dtb: $(src)/%.dts FORCE
 
 dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
 
+# DTCO
+# ---
+
+quiet_cmd_dtco = DTCO$@
+# Rule for objects only; does not put specific u-boot include at the end
+# No generation of assembly file either
+# Modified for U-Boot
+cmd_dtco = mkdir -p $(dir ${dtc-tmp}) ; \
+   $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) - ; \
+   $(DTC) -@ -O dtb -o $@ -b 0 \
+   -i $(dir $<) $(DTC_FLAGS) \
+   -d $(depfile).dtc.tmp $(dtc-tmp) ; \
+   cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile)
+
+$(obj)/%.dtbo: $(src)/%.dts FORCE
+   $(call if_changed_dep,dtco)
+
 # Fonts
 # ---
 
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 04/14] fdt: Allow stacked overlays phandle references

[Pantelis Antoniou]

This patch enables an overlay to refer to a previous overlay's
labels by performing a merge of symbol information at application
time.

In a nutshell it allows an overlay to refer to a symbol that a previous
overlay has defined. It requires both the base and all the overlays
to be compiled with the -@ command line switch so that symbol
information is included.

base.dts


/dts-v1/;
/ {
foo: foonode {
foo-property;
};
};

$ dtc -@ -I dts -O dtb -o base.dtb base.dts

bar.dts
---

/dts-v1/;
/plugin/;
/ {
fragment@1 {
target = <>;
__overlay__ {
overlay-1-property;
bar: barnode {
bar-property;
};
};
};
};

$ dtc -@ -I dts -O dtb -o bar.dtb bar.dts

baz.dts
---

/dts-v1/;
/plugin/;
/ {
fragment@1 {
target = <>;
__overlay__ {
overlay-2-property;
baz: baznode {
baz-property;
};
};
};
};

$ dtc -@ -I dts -O dtb -o baz.dtb baz.dts

Applying the overlays:

$ fdtoverlay -i base.dtb -o target.dtb bar.dtb baz.dtb

Dumping:

$ fdtdump target.dtb
/ {
foonode {
overlay-1-property;
foo-property;
linux,phandle = <0x0001>;
phandle = <0x0001>;
barnode {
overlay-2-property;
phandle = <0x0002>;
linux,phandle = <0x0002>;
bar-property;
baznode {
phandle = <0x0003>;
linux,phandle = <0x0003>;
baz-property;
};
};
};
__symbols__ {
baz = "/foonode/barnode/baznode";
bar = "/foonode/barnode";
foo = "/foonode";
};
};

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
---
 lib/libfdt/fdt_overlay.c | 228 ++-
 1 file changed, 206 insertions(+), 22 deletions(-)

diff --git a/lib/libfdt/fdt_overlay.c b/lib/libfdt/fdt_overlay.c
index ceb9687..bd81241 100644
--- a/lib/libfdt/fdt_overlay.c
+++ b/lib/libfdt/fdt_overlay.c
@@ -39,6 +39,7 @@ static uint32_t overlay_get_target_phandle(const void *fdto, 
int fragment)
  * @fdt: Base device tree blob
  * @fdto: Device tree overlay blob
  * @fragment: node offset of the fragment in the overlay
+ * @pathp: pointer which receives the path of the target (or NULL)
  *
  * overlay_get_target() retrieves the target offset in the base
  * device tree of a fragment, no matter how the actual targetting is
@@ -49,37 +50,47 @@ static uint32_t overlay_get_target_phandle(const void 
*fdto, int fragment)
  *  Negative error code on error
  */
 static int overlay_get_target(const void *fdt, const void *fdto,
- int fragment)
+ int fragment, char const **pathp)
 {
uint32_t phandle;
-   const char *path;
-   int path_len;
+   const char *path = NULL;
+   int path_len = 0, ret;
 
/* Try first to do a phandle based lookup */
phandle = overlay_get_target_phandle(fdto, fragment);
if (phandle == (uint32_t)-1)
return -FDT_ERR_BADPHANDLE;
 
-   if (phandle)
-   return fdt_node_offset_by_phandle(fdt, phandle);
+   /* no phandle, try path */
+   if (!phandle) {
+   /* And then a path based lookup */
+   path = fdt_getprop(fdto, fragment, "target-path", _len);
+   if (path)
+   ret = fdt_path_offset(fdt, path);
+   else
+   ret = path_len;
+   } else
+   ret = fdt_node_offset_by_phandle(fdt, phandle);
 
-   /* And then a path based lookup */
-   path = fdt_getprop(fdto, fragment, "target-path", _len);
-   if (!path) {
-   /*
-* If we haven't found either a target or a
-* target-path property in a node that contains a
-* __overlay__ subnode (we wouldn't be called
-* otherwise), consider it a improperly written
-* overlay
-*/
-   if (path_len == -

[U-Boot] [PATCH v3 09/14] doc: Document how to apply fdt overlays

[Pantelis Antoniou]

We have the capability to apply overlays on the command line but
we didn't have a document explaining how.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 doc/README.fdt-overlays | 37 +
 1 file changed, 37 insertions(+)
 create mode 100644 doc/README.fdt-overlays

diff --git a/doc/README.fdt-overlays b/doc/README.fdt-overlays
new file mode 100644
index 000..ee868ec
--- /dev/null
+++ b/doc/README.fdt-overlays
@@ -0,0 +1,37 @@
+U-Boot FDT Overlay usage (without FIT images)
+=
+
+FDT overlays are now available for use even without FIT images.
+It is not as automagic as with FIT images though and require a few
+manual steps.
+
+1. Figure out where to place both the base device tree blob and the
+overlay. Make sure you have enough space to grow the base tree without
+overlapping anything.
+
+=> setenv fdtaddr 0x87f0
+=> setenv fdtovaddr 0x87fc
+
+2. Load the base blob and overlay blobs
+
+=> load ${devtype} ${bootpart} ${fdtaddr} ${bootdir}/base.dtb
+=> load ${devtype} ${bootpart} ${fdtovaddr} ${bootdir}/overlay.dtb
+
+3. Set it as the working fdt tree.
+
+=> fdtaddr $fdtaddr
+
+4. Grow it enough so it can 'fit' all the applied overlays
+
+=> fdt resize 8192
+
+5. You are now ready to apply the overlay.
+
+=> fdt apply $fdtovaddr
+
+Please note that in case of an error, both the base and overlays are going
+to be invalidated, so keep copies to avoid reloading.
+
+Pantelis Antoniou
+pantelis.anton...@konsulko.com
+11/7/2017
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 13/14] ut: fix fdt_getprop_u32() change

[Pantelis Antoniou]

fdt_getprop_u32 is not exported and it's different than what the
unit test uses. Rename u32 prop access methods to something that's
unit test specific.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 test/overlay/cmd_ut_overlay.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/test/overlay/cmd_ut_overlay.c b/test/overlay/cmd_ut_overlay.c
index cbef720..7106f42 100644
--- a/test/overlay/cmd_ut_overlay.c
+++ b/test/overlay/cmd_ut_overlay.c
@@ -21,7 +21,7 @@
 extern u32 __dtb_test_fdt_base_begin;
 extern u32 __dtb_test_fdt_overlay_begin;
 
-static int fdt_getprop_u32_by_index(void *fdt, const char *path,
+static int ut_fdt_getprop_u32_by_index(void *fdt, const char *path,
const char *name, int index,
u32 *out)
 {
@@ -42,10 +42,10 @@ static int fdt_getprop_u32_by_index(void *fdt, const char 
*path,
return 0;
 }
 
-static int fdt_getprop_u32(void *fdt, const char *path, const char *name,
+static int ut_fdt_getprop_u32(void *fdt, const char *path, const char *name,
   u32 *out)
 {
-   return fdt_getprop_u32_by_index(fdt, path, name, 0, out);
+   return ut_fdt_getprop_u32_by_index(fdt, path, name, 0, out);
 }
 
 static int fdt_getprop_str(void *fdt, const char *path, const char *name,
@@ -68,7 +68,7 @@ static int fdt_overlay_change_int_property(struct 
unit_test_state *uts)
void *fdt = uts->priv;
u32 val = 0;
 
-   ut_assertok(fdt_getprop_u32(fdt, "/test-node", "test-int-property",
+   ut_assertok(ut_fdt_getprop_u32(fdt, "/test-node", "test-int-property",
));
ut_asserteq(43, val);
 
@@ -158,11 +158,11 @@ static int fdt_overlay_local_phandle(struct 
unit_test_state *uts)
local_phandle = fdt_get_phandle(fdt, off);
ut_assert(local_phandle);
 
-   ut_assertok(fdt_getprop_u32_by_index(fdt, "/", "test-several-phandle",
+   ut_assertok(ut_fdt_getprop_u32_by_index(fdt, "/", 
"test-several-phandle",
 0, ));
ut_asserteq(local_phandle, val);
 
-   ut_assertok(fdt_getprop_u32_by_index(fdt, "/", "test-several-phandle",
+   ut_assertok(ut_fdt_getprop_u32_by_index(fdt, "/", 
"test-several-phandle",
 1, ));
ut_asserteq(local_phandle, val);
 
@@ -189,11 +189,11 @@ static int fdt_overlay_local_phandles(struct 
unit_test_state *uts)
test_phandle = fdt_get_phandle(fdt, off);
ut_assert(test_phandle);
 
-   ut_assertok(fdt_getprop_u32_by_index(fdt, "/", "test-phandle", 0,
+   ut_assertok(ut_fdt_getprop_u32_by_index(fdt, "/", "test-phandle", 0,
 ));
ut_asserteq(test_phandle, val);
 
-   ut_assertok(fdt_getprop_u32_by_index(fdt, "/", "test-phandle", 1,
+   ut_assertok(ut_fdt_getprop_u32_by_index(fdt, "/", "test-phandle", 1,
 ));
ut_asserteq(local_phandle, val);
 
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 05/14] fit: Allow multiple images per property

[Pantelis Antoniou]

As part of the fdt overlay support which need it, allow
a list of configurations per property.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 common/image-fit.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index 109ecfa..74e5557 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1484,20 +1484,32 @@ int fit_conf_get_node(const void *fit, const char 
*conf_uname)
return noffset;
 }
 
-int fit_conf_get_prop_node(const void *fit, int noffset,
+int fit_conf_get_prop_node_count(const void *fit, int noffset,
const char *prop_name)
 {
-   char *uname;
+   return fdt_stringlist_count(fit, noffset, prop_name);
+}
+
+int fit_conf_get_prop_node_index(const void *fit, int noffset,
+   const char *prop_name, int index)
+{
+   const char *uname;
int len;
 
/* get kernel image unit name from configuration kernel property */
-   uname = (char *)fdt_getprop(fit, noffset, prop_name, );
+   uname = fdt_stringlist_get(fit, noffset, prop_name, index, );
if (uname == NULL)
return len;
 
return fit_image_get_node(fit, uname);
 }
 
+int fit_conf_get_prop_node(const void *fit, int noffset,
+   const char *prop_name)
+{
+   return fit_conf_get_prop_node_index(fit, noffset, prop_name, 0);
+}
+
 /**
  * fit_conf_print - prints out the FIT configuration details
  * @fit: pointer to the FIT format image header
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 07/14] fit: Introduce methods for applying overlays on fit-load

[Pantelis Antoniou]

Introduce an overlay based method for constructing a base DT blob
to pass to the kernel.

It is based on a specific method now to get the FDT from a FIT image
named boot_get_fdt_fit().

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 common/image-fdt.c |   7 +--
 common/image-fit.c | 181 +++--
 include/image.h|  25 
 3 files changed, 205 insertions(+), 8 deletions(-)

diff --git a/common/image-fdt.c b/common/image-fdt.c
index da4d007..a2ef409 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -356,17 +356,16 @@ int boot_get_fdt(int flag, int argc, char * const argv[], 
uint8_t arch,
if (fit_check_format(buf)) {
ulong load, len;
 
-   fdt_noffset = fit_image_load(images,
+   fdt_noffset = boot_get_fdt_fit(images,
fdt_addr, _uname_fdt,
_uname_config,
-   arch, IH_TYPE_FLATDT,
-   BOOTSTAGE_ID_FIT_FDT_START,
-   FIT_LOAD_OPTIONAL, , );
+   arch, , );
 
images->fit_hdr_fdt = map_sysmem(fdt_addr, 0);
images->fit_uname_fdt = fit_uname_fdt;
images->fit_noffset_fdt = fdt_noffset;
fdt_addr = load;
+
break;
} else
 #endif
diff --git a/common/image-fit.c b/common/image-fit.c
index e75cb64..7f17fd1 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 DECLARE_GLOBAL_DATA_PTR;
 #endif /* !USE_HOSTCC*/
 
@@ -434,6 +435,10 @@ void fit_image_print(const void *fit, int image_noffset, 
const char *p)
printf("0x%08lx\n", load);
}
 
+   /* optional load address for FDT */
+   if (type == IH_TYPE_FLATDT && !fit_image_get_load(fit, image_noffset, 
))
+   printf("%s  Load Address: 0x%08lx\n", p, load);
+
if ((type == IH_TYPE_KERNEL) || (type == IH_TYPE_STANDALONE) ||
(type == IH_TYPE_RAMDISK)) {
ret = fit_image_get_entry(fit, image_noffset, );
@@ -1454,6 +1459,8 @@ int fit_conf_get_node(const void *fit, const char 
*conf_uname)
 {
int noffset, confs_noffset;
int len;
+   const char *s;
+   char *conf_uname_copy = NULL;
 
confs_noffset = fdt_path_offset(fit, FIT_CONFS_PATH);
if (confs_noffset < 0) {
@@ -1475,12 +1482,29 @@ int fit_conf_get_node(const void *fit, const char 
*conf_uname)
debug("Found default configuration: '%s'\n", conf_uname);
}
 
+   s = strchr(conf_uname, '#');
+   if (s) {
+   len = s - conf_uname;
+   conf_uname_copy = malloc(len + 1);
+   if (!conf_uname_copy) {
+   debug("Can't allocate uname copy: '%s'\n",
+   conf_uname);
+   return -ENOMEM;
+   }
+   memcpy(conf_uname_copy, conf_uname, len);
+   conf_uname_copy[len] = '\0';
+   conf_uname = conf_uname_copy;
+   }
+
noffset = fdt_subnode_offset(fit, confs_noffset, conf_uname);
if (noffset < 0) {
debug("Can't get node offset for configuration unit name: '%s' 
(%s)\n",
  conf_uname, fdt_strerror(noffset));
}
 
+   if (conf_uname_copy)
+   free(conf_uname_copy);
+
return noffset;
 }
 
@@ -1527,7 +1551,7 @@ void fit_conf_print(const void *fit, int noffset, const 
char *p)
char *desc;
const char *uname;
int ret;
-   int loadables_index;
+   int fdt_index, loadables_index;
 
/* Mandatory properties */
ret = fit_get_desc(fit, noffset, );
@@ -1549,9 +1573,17 @@ void fit_conf_print(const void *fit, int noffset, const 
char *p)
if (uname)
printf("%s  Init Ramdisk: %s\n", p, uname);
 
-   uname = fdt_getprop(fit, noffset, FIT_FDT_PROP, NULL);
-   if (uname)
-   printf("%s  FDT:  %s\n", p, uname);
+   for (fdt_index = 0;
+uname = fdt_stringlist_get(fit, noffset, FIT_FDT_PROP,
+   fdt_index, NULL), uname;
+fdt_index++) {
+
+   if (fdt_index == 0)
+   printf("%s  FDT:  ", p);
+   else
+   printf("%s", p);
+   printf("%s\n", uname);
+   }
 
uname = fdt_getprop(fit, noffset, FIT_FPGA_PROP, NULL);
if (

[U-Boot] [PATCH v3 10/14] doc: overlays: Tweak documentation regarding overlays

[Pantelis Antoniou]

From: Franklin S Cooper Jr 

Pull some information regarding overlays from commit messages and
put them directly within the documentation. Also add some information
regarding required dtc version to properly use overlays.

Signed-off-by: Franklin S Cooper Jr 
---
 doc/README.fdt-overlays | 85 +++--
 doc/uImage.FIT/overlay-fdt-boot.txt |  8 +++-
 2 files changed, 87 insertions(+), 6 deletions(-)

diff --git a/doc/README.fdt-overlays b/doc/README.fdt-overlays
index ee868ec..39139cb 100644
--- a/doc/README.fdt-overlays
+++ b/doc/README.fdt-overlays
@@ -1,9 +1,76 @@
-U-Boot FDT Overlay usage (without FIT images)
+U-Boot FDT Overlay usage
 =
 
-FDT overlays are now available for use even without FIT images.
-It is not as automagic as with FIT images though and require a few
-manual steps.
+Overlays Syntax
+---
+
+Overlays require slightly different syntax compared to traditional overlays.
+Please refer to dt-object-internal.txt in the dtc sources for information
+regarding the internal format of overlays:
+https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/Documentation/dt-object-internal.txt
+
+Building Overlays
+-
+
+In a nutshell overlays provides a means to manipulate a symbol a previous dtb
+or overlay has defined. It requires both the base and all the overlays
+to be compiled with the -@ command line switch so that symbol information is
+included.
+
+Note support for -@ option can only be found in dtc version 1.4.4 or newer.
+Only version 4.14 or higher of the Linux kernel includes a built in version
+of dtc that meets this requirement.
+
+Building an overlay follows the same process as building a traditional dtb.
+
+For example:
+
+base.dts
+
+
+   /dts-v1/;
+   / {
+   foo: foonode {
+   foo-property;
+   };
+   };
+
+   $ dtc -@ -I dts -O dtb -o base.dtb base.dts
+
+bar.dts
+---
+
+   /dts-v1/;
+   /plugin/;
+   / {
+   fragment@1 {
+   target = <>;
+   __overlay__ {
+   overlay-1-property;
+   bar: barnode {
+   bar-property;
+   };
+   };
+   };
+   };
+
+   $ dtc -@ -I dts -O dtb -o bar.dtb bar.dts
+
+Ways to Utilize Overlays in U-boot
+--
+
+There are two ways to apply overlays in U-boot.
+1. Include and define overlays within a FIT image and have overlays
+   automatically applied.
+
+2. Manually load and apply overlays
+
+The remainder of this document will discuss using overlays via the manual
+approach. For information on using overlays as part of a FIT image please see:
+doc/uImage.FIT/overlay-fdt-boot.txt
+
+Manually Loading and Applying Overlays
+--
 
 1. Figure out where to place both the base device tree blob and the
 overlay. Make sure you have enough space to grow the base tree without
@@ -29,6 +96,16 @@ overlapping anything.
 
 => fdt apply $fdtovaddr
 
+6. Boot system like you would do with a traditional dtb.
+
+For bootm:
+
+=> bootm ${kerneladdr} - ${fdtaddr}
+
+For bootz:
+
+=> bootz ${kerneladdr} - ${fdtaddr}
+
 Please note that in case of an error, both the base and overlays are going
 to be invalidated, so keep copies to avoid reloading.
 
diff --git a/doc/uImage.FIT/overlay-fdt-boot.txt 
b/doc/uImage.FIT/overlay-fdt-boot.txt
index dbdf2a1..63e47da 100644
--- a/doc/uImage.FIT/overlay-fdt-boot.txt
+++ b/doc/uImage.FIT/overlay-fdt-boot.txt
@@ -1,5 +1,5 @@
-U-Boot FDT Overlay usage
-
+U-Boot FDT Overlay FIT usage
+
 
 Introduction
 
@@ -8,6 +8,10 @@ of similar boards and their expansion options. The same kernel 
on DT enabled
 platforms can support this easily enough by providing a DT blob upon boot
 that matches the desired configuration.
 
+This document focuses on specifically using overlays as part of a FIT image.
+General information regarding overlays including its syntax and building it
+can be found in doc/README.fdt-overlays
+
 Configuration without overlays
 --
 
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 01/14] Introduce fdt_setprop_placeholder() method

[Pantelis Antoniou]

In some cases you need to add a property but the contents of it
are not known at creation time, merely the extend of it.

This method allows you to create a property of a given size (filled
with garbage) while a pointer to the property data will be provided.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
[dwg: Corrected commit message]
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
---
 lib/libfdt/fdt_rw.c | 20 +---
 lib/libfdt/libfdt.h | 31 +++
 2 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/lib/libfdt/fdt_rw.c b/lib/libfdt/fdt_rw.c
index 80a3212..3dc7752 100644
--- a/lib/libfdt/fdt_rw.c
+++ b/lib/libfdt/fdt_rw.c
@@ -228,8 +228,8 @@ int fdt_set_name(void *fdt, int nodeoffset, const char 
*name)
return 0;
 }
 
-int fdt_setprop(void *fdt, int nodeoffset, const char *name,
-   const void *val, int len)
+int fdt_setprop_placeholder(void *fdt, int nodeoffset, const char *name,
+   int len, void **prop_data)
 {
struct fdt_property *prop;
int err;
@@ -242,8 +242,22 @@ int fdt_setprop(void *fdt, int nodeoffset, const char 
*name,
if (err)
return err;
 
+   *prop_data = prop->data;
+   return 0;
+}
+
+int fdt_setprop(void *fdt, int nodeoffset, const char *name,
+   const void *val, int len)
+{
+   void *prop_data;
+   int err;
+
+   err = fdt_setprop_placeholder(fdt, nodeoffset, name, len, _data);
+   if (err)
+   return err;
+
if (len)
-   memcpy(prop->data, val, len);
+   memcpy(prop_data, val, len);
return 0;
 }
 
diff --git a/lib/libfdt/libfdt.h b/lib/libfdt/libfdt.h
index f3f9cad..6af94cb 100644
--- a/lib/libfdt/libfdt.h
+++ b/lib/libfdt/libfdt.h
@@ -1405,6 +1405,37 @@ int fdt_setprop(void *fdt, int nodeoffset, const char 
*name,
const void *val, int len);
 
 /**
+ * fdt_setprop _placeholder - allocate space for a property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @len: length of the property value
+ * @prop_data: return pointer to property data
+ *
+ * fdt_setprop_placeholer() allocates the named property in the given node.
+ * If the property exists it is resized. In either case a pointer to the
+ * property data is returned.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ * contain the new property value
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_setprop_placeholder(void *fdt, int nodeoffset, const char *name,
+   int len, void **prop_data);
+
+/**
  * fdt_setprop_u32 - set a property to a 32-bit integer
  * @fdt: pointer to the device tree blob
  * @nodeoffset: offset of the node whose property to change
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 06/14] fit: Do not throw away extra configuration on fit_image_load()

[Pantelis Antoniou]

fit_image_load() threw away the extra configuration parts when
loading. We need them around for applying extra overlays for
building the boot fdt.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 common/image-fit.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index 74e5557..e75cb64 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1653,6 +1653,7 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
int cfg_noffset, noffset;
const char *fit_uname;
const char *fit_uname_config;
+   const char *fit_base_uname_config;
const void *fit;
const void *buf;
size_t size;
@@ -1668,6 +1669,7 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
fit = map_sysmem(addr, 0);
fit_uname = fit_unamep ? *fit_unamep : NULL;
fit_uname_config = fit_uname_configp ? *fit_uname_configp : NULL;
+   fit_base_uname_config = NULL;
prop_name = fit_get_image_type_property(image_type);
printf("## Loading %s from FIT Image at %08lx ...\n", prop_name, addr);
 
@@ -1701,11 +1703,11 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
BOOTSTAGE_SUB_NO_UNIT_NAME);
return -ENOENT;
}
-   fit_uname_config = fdt_get_name(fit, cfg_noffset, NULL);
-   printf("   Using '%s' configuration\n", fit_uname_config);
+   fit_base_uname_config = fdt_get_name(fit, cfg_noffset, NULL);
+   printf("   Using '%s' configuration\n", fit_base_uname_config);
if (image_type == IH_TYPE_KERNEL) {
/* Remember (and possibly verify) this config */
-   images->fit_uname_cfg = fit_uname_config;
+   images->fit_uname_cfg = fit_base_uname_config;
if (IMAGE_ENABLE_VERIFY && images->verify) {
puts("   Verifying Hash Integrity ... ");
if (fit_config_verify(fit, cfg_noffset)) {
@@ -1861,7 +1863,8 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
if (fit_unamep)
*fit_unamep = (char *)fit_uname;
if (fit_uname_configp)
-   *fit_uname_configp = (char *)fit_uname_config;
+   *fit_uname_configp = (char *)(fit_uname_config ? :
+ fit_base_uname_config);
 
return noffset;
 }
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 00/14] uboot overlays, FIT image & unittest

[Pantelis Antoniou]

This patchset allows uboot to handle overlays in a manner that uses
a base DT blob and an arbitrary number of DT overlays blobs.

While it is intended to be used with FIT images since handling a multitude
of device tree blobs manually is a chore, manual fdt overlay application
is supported and described.

Changes since v2:
* Addressed review comments by splitting patches and documenting methods.
* Patch preserving extra configuration on fit-load

The patchset is available at

https://github.com/pantoniou/u-boot/tree/uboot-overlays

and is against mainline u-boot as pulled today, 4/9/2017.

Franklin S Cooper Jr (1):
  doc: overlays: Tweak documentation regarding overlays

Pantelis Antoniou (13):
  Introduce fdt_setprop_placeholder() method
  fdt: Introduce helper method fdt_overlay_apply_verbose()
  fdt: Switch to using the verbose overlay application method
  fdt: Allow stacked overlays phandle references
  fit: Allow multiple images per property
  fit: Do not throw away extra configuration on fit_image_load()
  fit: Introduce methods for applying overlays on fit-load
  fit: fdt overlays doc
  doc: Document how to apply fdt overlays
  dtbo: make dtbos special
  config: sandbox: Add unit tests
  ut: fix fdt_getprop_u32() change
  test: overlay: Add unit test for stacked overlay

 cmd/fdt.c|   7 +-
 common/fdt_support.c |  31 
 common/image-fdt.c   |   7 +-
 common/image-fit.c   | 210 ++--
 configs/sandbox_defconfig|   2 +
 doc/README.fdt-overlays  | 114 ++
 doc/uImage.FIT/command_syntax_extensions.txt |  12 +-
 doc/uImage.FIT/overlay-fdt-boot.txt  | 225 ++
 doc/uImage.FIT/source_file_format.txt|   6 +-
 include/fdt_support.h|   2 +
 include/image.h  |  25 +++
 lib/libfdt/fdt_overlay.c | 228 ---
 lib/libfdt/fdt_rw.c  |  20 ++-
 lib/libfdt/libfdt.h  |  31 
 scripts/Makefile.lib |  17 ++
 test/overlay/Makefile|   1 +
 test/overlay/cmd_ut_overlay.c|  50 --
 test/overlay/test-fdt-overlay-stacked.dts|  21 +++
 18 files changed, 953 insertions(+), 56 deletions(-)
 create mode 100644 doc/README.fdt-overlays
 create mode 100644 doc/uImage.FIT/overlay-fdt-boot.txt
 create mode 100644 test/overlay/test-fdt-overlay-stacked.dts

-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 02/14] fdt: Introduce helper method fdt_overlay_apply_verbose()

[Pantelis Antoniou]

Introduce fdt_overlay_apply_verbose, a method that applies an
overlay but in the case of an error produces a helpful message.

In addition if a base tree is found to be missing the __symbols__
node the message will point out that the probable reason is that
the base tree was miscompiled without the -@ option.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 common/fdt_support.c  | 31 +++
 include/fdt_support.h |  2 ++
 2 files changed, 33 insertions(+)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index 916a448..f4f9543 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -1655,3 +1655,34 @@ int fdt_fixup_display(void *blob, const char *path, 
const char *display)
}
return toff;
 }
+
+#ifdef CONFIG_OF_LIBFDT_OVERLAY
+/**
+ * fdt_overlay_apply_verbose - Apply an overlay with verbose error reporting
+ *
+ * @fdt: ptr to device tree
+ * @fdto: ptr to device tree overlay
+ *
+ * Convenience function to apply an overlay and display helpful messages
+ * in the case of an error
+ */
+int fdt_overlay_apply_verbose(void *fdt, void *fdto)
+{
+   int err;
+   bool has_symbols;
+
+   err = fdt_path_offset(fdt, "/__symbols__");
+   has_symbols = err >= 0;
+
+   err = fdt_overlay_apply(fdt, fdto);
+   if (err < 0) {
+   printf("failed on fdt_overlay_apply(): %s\n",
+   fdt_strerror(err));
+   if (!has_symbols) {
+   printf("base fdt does did not have a /__symbols__ 
node\n");
+   printf("make sure you've compiled with -@\n");
+   }
+   }
+   return err;
+}
+#endif
diff --git a/include/fdt_support.h b/include/fdt_support.h
index 5ef78cc..2bca4d7 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -264,6 +264,8 @@ int arch_fixup_memory_node(void *blob);
 int fdt_setup_simplefb_node(void *fdt, int node, u64 base_address, u32 width,
u32 height, u32 stride, const char *format);
 
+int fdt_overlay_apply_verbose(void *fdt, void *fdto);
+
 #endif /* ifdef CONFIG_OF_LIBFDT */
 
 #ifdef USE_HOSTCC
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 08/10] config: sandbox: Add unit tests

[Pantelis Antoniou]

Hi Simon,

On Sat, 2017-08-26 at 07:37 -0600, Simon Glass wrote:
> On 11 August 2017 at 02:52, Pantelis Antoniou
> <pantelis.anton...@konsulko.com> wrote:
> > Add unit tests for sandbox default config.
> >
> > Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
> > ---
> >  configs/sandbox_defconfig | 2 ++
> >  1 file changed, 2 insertions(+)
> 
> I don't see any tests in this patch?
> 

Err, maybe the wording of the commit message needs to change.
There are no new tests, merely enabling overlays for the sandbox config
makes them available as unitests.

I will reword.

> >
> > diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> > index fd0b952..df8659a 100644
> > --- a/configs/sandbox_defconfig
> > +++ b/configs/sandbox_defconfig
> > @@ -187,7 +187,9 @@ CONFIG_CMD_DHRYSTONE=y
> >  CONFIG_TPM=y
> >  CONFIG_LZ4=y
> >  CONFIG_ERRNO_STR=y
> > +CONFIG_OF_LIBFDT_OVERLAY=y
> >  CONFIG_UNIT_TEST=y
> >  CONFIG_UT_TIME=y
> >  CONFIG_UT_DM=y
> >  CONFIG_UT_ENV=y
> > +CONFIG_UT_OVERLAY=y
> > --
> > 2.1.4
> >
> 
> Regards,
> Simon


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 09/10] ut: fix fdt_getprop_u32() change

[Pantelis Antoniou]

fdt_getprop_u32 is not exported and it's different than what the
unit test uses. Rename u32 prop access methods to something that's
unit test specific.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 test/overlay/cmd_ut_overlay.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/test/overlay/cmd_ut_overlay.c b/test/overlay/cmd_ut_overlay.c
index cbef720..7106f42 100644
--- a/test/overlay/cmd_ut_overlay.c
+++ b/test/overlay/cmd_ut_overlay.c
@@ -21,7 +21,7 @@
 extern u32 __dtb_test_fdt_base_begin;
 extern u32 __dtb_test_fdt_overlay_begin;
 
-static int fdt_getprop_u32_by_index(void *fdt, const char *path,
+static int ut_fdt_getprop_u32_by_index(void *fdt, const char *path,
const char *name, int index,
u32 *out)
 {
@@ -42,10 +42,10 @@ static int fdt_getprop_u32_by_index(void *fdt, const char 
*path,
return 0;
 }
 
-static int fdt_getprop_u32(void *fdt, const char *path, const char *name,
+static int ut_fdt_getprop_u32(void *fdt, const char *path, const char *name,
   u32 *out)
 {
-   return fdt_getprop_u32_by_index(fdt, path, name, 0, out);
+   return ut_fdt_getprop_u32_by_index(fdt, path, name, 0, out);
 }
 
 static int fdt_getprop_str(void *fdt, const char *path, const char *name,
@@ -68,7 +68,7 @@ static int fdt_overlay_change_int_property(struct 
unit_test_state *uts)
void *fdt = uts->priv;
u32 val = 0;
 
-   ut_assertok(fdt_getprop_u32(fdt, "/test-node", "test-int-property",
+   ut_assertok(ut_fdt_getprop_u32(fdt, "/test-node", "test-int-property",
));
ut_asserteq(43, val);
 
@@ -158,11 +158,11 @@ static int fdt_overlay_local_phandle(struct 
unit_test_state *uts)
local_phandle = fdt_get_phandle(fdt, off);
ut_assert(local_phandle);
 
-   ut_assertok(fdt_getprop_u32_by_index(fdt, "/", "test-several-phandle",
+   ut_assertok(ut_fdt_getprop_u32_by_index(fdt, "/", 
"test-several-phandle",
 0, ));
ut_asserteq(local_phandle, val);
 
-   ut_assertok(fdt_getprop_u32_by_index(fdt, "/", "test-several-phandle",
+   ut_assertok(ut_fdt_getprop_u32_by_index(fdt, "/", 
"test-several-phandle",
 1, ));
ut_asserteq(local_phandle, val);
 
@@ -189,11 +189,11 @@ static int fdt_overlay_local_phandles(struct 
unit_test_state *uts)
test_phandle = fdt_get_phandle(fdt, off);
ut_assert(test_phandle);
 
-   ut_assertok(fdt_getprop_u32_by_index(fdt, "/", "test-phandle", 0,
+   ut_assertok(ut_fdt_getprop_u32_by_index(fdt, "/", "test-phandle", 0,
 ));
ut_asserteq(test_phandle, val);
 
-   ut_assertok(fdt_getprop_u32_by_index(fdt, "/", "test-phandle", 1,
+   ut_assertok(ut_fdt_getprop_u32_by_index(fdt, "/", "test-phandle", 1,
 ));
ut_asserteq(local_phandle, val);
 
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 04/10] fdt-overlay: Spit out a descriptive failure warning

[Pantelis Antoniou]

The most common trouble with overlays appears to be miscompiled
blobs without the -@ option.

In case of an error, spit out a descriptive error message.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 cmd/fdt.c  |  8 
 common/image-fit.c | 12 +++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/cmd/fdt.c b/cmd/fdt.c
index 05e19f8..9f192be 100644
--- a/cmd/fdt.c
+++ b/cmd/fdt.c
@@ -654,6 +654,7 @@ static int do_fdt(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
unsigned long addr;
struct fdt_header *blob;
int ret;
+   bool has_symbols;
 
if (argc != 3)
return CMD_RET_USAGE;
@@ -666,9 +667,16 @@ static int do_fdt(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
if (!fdt_valid())
return CMD_RET_FAILURE;
 
+   ret = fdt_path_offset(working_fdt, "/__symbols__");
+   has_symbols = ret >= 0;
+
ret = fdt_overlay_apply(working_fdt, blob);
if (ret) {
printf("fdt_overlay_apply(): %s\n", fdt_strerror(ret));
+   if (!has_symbols) {
+   printf("working fdt does did not have a 
/__symbols__ node\n");
+   printf("make sure you've compiled with -@\n");
+   }
return CMD_RET_FAILURE;
}
}
diff --git a/common/image-fit.c b/common/image-fit.c
index cb089ea..28140f1 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1946,6 +1946,7 @@ int boot_get_fdt_fit(bootm_headers_t *images, ulong addr,
const char *uname;
void *base, *ov;
int i, err, noffset, ov_noffset;
+   bool has_symbols;
 #endif
 
fit_uname = fit_unamep ? *fit_unamep : NULL;
@@ -2038,9 +2039,18 @@ int boot_get_fdt_fit(bootm_headers_t *images, ulong addr,
fdt_noffset = err;
goto out;
}
+
+   err = fdt_path_offset(base, "/__symbols__");
+   has_symbols = err >= 0;
+
err = fdt_overlay_apply(base, ov);
if (err < 0) {
-   printf("failed on fdt_overlay_apply\n");
+   printf("failed on fdt_overlay_apply(): %s\n",
+   fdt_strerror(err));
+   if (!has_symbols) {
+   printf("base fdt does did not have a 
/__symbols__ node\n");
+   printf("make sure you've compiled with -@\n");
+   }
fdt_noffset = err;
goto out;
}
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 08/10] config: sandbox: Add unit tests

[Pantelis Antoniou]

Add unit tests for sandbox default config.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 configs/sandbox_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index fd0b952..df8659a 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -187,7 +187,9 @@ CONFIG_CMD_DHRYSTONE=y
 CONFIG_TPM=y
 CONFIG_LZ4=y
 CONFIG_ERRNO_STR=y
+CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_UNIT_TEST=y
 CONFIG_UT_TIME=y
 CONFIG_UT_DM=y
 CONFIG_UT_ENV=y
+CONFIG_UT_OVERLAY=y
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 10/10] test: overlay: Add unit test for stacked overlay

[Pantelis Antoniou]

Verify that stacked overlays work.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 test/overlay/Makefile |  1 +
 test/overlay/cmd_ut_overlay.c | 34 ++-
 test/overlay/test-fdt-overlay-stacked.dts | 21 +++
 3 files changed, 55 insertions(+), 1 deletion(-)
 create mode 100644 test/overlay/test-fdt-overlay-stacked.dts

diff --git a/test/overlay/Makefile b/test/overlay/Makefile
index 907f085..416645c 100644
--- a/test/overlay/Makefile
+++ b/test/overlay/Makefile
@@ -13,3 +13,4 @@ DTC_FLAGS += -@
 # DT overlays
 obj-y += test-fdt-base.dtb.o
 obj-y += test-fdt-overlay.dtb.o
+obj-y += test-fdt-overlay-stacked.dtb.o
diff --git a/test/overlay/cmd_ut_overlay.c b/test/overlay/cmd_ut_overlay.c
index 7106f42..24891ee 100644
--- a/test/overlay/cmd_ut_overlay.c
+++ b/test/overlay/cmd_ut_overlay.c
@@ -20,6 +20,7 @@
 
 extern u32 __dtb_test_fdt_base_begin;
 extern u32 __dtb_test_fdt_overlay_begin;
+extern u32 __dtb_test_fdt_overlay_stacked_begin;
 
 static int ut_fdt_getprop_u32_by_index(void *fdt, const char *path,
const char *name, int index,
@@ -201,6 +202,19 @@ static int fdt_overlay_local_phandles(struct 
unit_test_state *uts)
 }
 OVERLAY_TEST(fdt_overlay_local_phandles, 0);
 
+static int fdt_overlay_stacked(struct unit_test_state *uts)
+{
+   void *fdt = uts->priv;
+   u32 val = 0;
+
+   ut_assertok(ut_fdt_getprop_u32(fdt, "/new-local-node",
+  "stacked-test-int-property", ));
+   ut_asserteq(43, val);
+
+   return CMD_RET_SUCCESS;
+}
+OVERLAY_TEST(fdt_overlay_stacked, 0);
+
 int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
struct unit_test *tests = ll_entry_start(struct unit_test,
@@ -210,7 +224,8 @@ int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
struct unit_test *test;
void *fdt_base = &__dtb_test_fdt_base_begin;
void *fdt_overlay = &__dtb_test_fdt_overlay_begin;
-   void *fdt_base_copy, *fdt_overlay_copy;
+   void *fdt_overlay_stacked = &__dtb_test_fdt_overlay_stacked_begin;
+   void *fdt_base_copy, *fdt_overlay_copy, *fdt_overlay_stacked_copy;
 
uts = calloc(1, sizeof(*uts));
if (!uts)
@@ -228,6 +243,10 @@ int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
if (!fdt_overlay_copy)
return -ENOMEM;
 
+   fdt_overlay_stacked_copy = malloc(FDT_COPY_SIZE);
+   if (!fdt_overlay_stacked_copy)
+   return -ENOMEM;
+
/*
 * Resize the FDT to 4k so that we have room to operate on
 *
@@ -245,9 +264,21 @@ int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
ut_assertok(fdt_open_into(fdt_overlay, fdt_overlay_copy,
  FDT_COPY_SIZE));
 
+   /*
+* Resize the stacked overlay to 4k so that we have room to operate on
+*
+* (and relocate it since the memory might be mapped
+* read-only)
+*/
+   ut_assertok(fdt_open_into(fdt_overlay_stacked, fdt_overlay_stacked_copy,
+ FDT_COPY_SIZE));
+
/* Apply the overlay */
ut_assertok(fdt_overlay_apply(fdt_base_copy, fdt_overlay_copy));
 
+   /* Apply the stacked overlay */
+   ut_assertok(fdt_overlay_apply(fdt_base_copy, fdt_overlay_stacked_copy));
+
if (argc == 1)
printf("Running %d environment tests\n", n_ents);
 
@@ -263,6 +294,7 @@ int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 
printf("Failures: %d\n", uts->fail_count);
 
+   free(fdt_overlay_stacked_copy);
free(fdt_overlay_copy);
free(fdt_base_copy);
free(uts);
diff --git a/test/overlay/test-fdt-overlay-stacked.dts 
b/test/overlay/test-fdt-overlay-stacked.dts
new file mode 100644
index 000..9fb7c7b
--- /dev/null
+++ b/test/overlay/test-fdt-overlay-stacked.dts
@@ -0,0 +1,21 @@
+/*
+ * Copyright (c) 2016 NextThing Co
+ * Copyright (c) 2016 Free Electrons
+ * Copyright (c) 2018 Konsulko Group
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+/plugin/;
+
+/ {
+   /* Test that we can reference an overlay symbol */
+   fragment@0 {
+   target = <>;
+
+   __overlay__ {
+   stacked-test-int-property = <43>;
+   };
+   };
+};
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 07/10] dtbo: make dtbos special

[Pantelis Antoniou]

Special rule for dtbo generation

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 scripts/Makefile.lib | 17 +
 1 file changed, 17 insertions(+)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 9ce47b4..2a7ed70 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -321,6 +321,23 @@ $(obj)/%.dtb: $(src)/%.dts FORCE
 
 dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
 
+# DTCO
+# ---
+
+quiet_cmd_dtco = DTCO$@
+# Rule for objects only; does not put specific u-boot include at the end
+# No generation of assembly file either
+# Modified for U-Boot
+cmd_dtco = mkdir -p $(dir ${dtc-tmp}) ; \
+   $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) - ; \
+   $(DTC) -@ -O dtb -o $@ -b 0 \
+   -i $(dir $<) $(DTC_FLAGS) \
+   -d $(depfile).dtc.tmp $(dtc-tmp) ; \
+   cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile)
+
+$(obj)/%.dtbo: $(src)/%.dts FORCE
+   $(call if_changed_dep,dtco)
+
 # Fonts
 # ---
 
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 03/10] fit: Introduce methods for applying overlays on fit-load

[Pantelis Antoniou]

Introduce an overlay based method for constructing a base DT blob
to pass to the kernel.

Both canned and runtime feature selection is supported.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 common/image-fdt.c   |   7 +-
 common/image-fit.c   | 216 --
 doc/uImage.FIT/command_syntax_extensions.txt |  12 +-
 doc/uImage.FIT/overlay-fdt-boot.txt  | 221 +++
 doc/uImage.FIT/source_file_format.txt|   6 +-
 include/image.h  |  10 ++
 6 files changed, 454 insertions(+), 18 deletions(-)
 create mode 100644 doc/uImage.FIT/overlay-fdt-boot.txt

diff --git a/common/image-fdt.c b/common/image-fdt.c
index c6e8832..a59134c 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -356,17 +356,16 @@ int boot_get_fdt(int flag, int argc, char * const argv[], 
uint8_t arch,
if (fit_check_format(buf)) {
ulong load, len;
 
-   fdt_noffset = fit_image_load(images,
+   fdt_noffset = boot_get_fdt_fit(images,
fdt_addr, _uname_fdt,
_uname_config,
-   arch, IH_TYPE_FLATDT,
-   BOOTSTAGE_ID_FIT_FDT_START,
-   FIT_LOAD_OPTIONAL, , );
+   arch, , );
 
images->fit_hdr_fdt = map_sysmem(fdt_addr, 0);
images->fit_uname_fdt = fit_uname_fdt;
images->fit_noffset_fdt = fdt_noffset;
fdt_addr = load;
+
break;
} else
 #endif
diff --git a/common/image-fit.c b/common/image-fit.c
index 109ecfa..cb089ea 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 DECLARE_GLOBAL_DATA_PTR;
 #endif /* !USE_HOSTCC*/
 
@@ -434,6 +435,10 @@ void fit_image_print(const void *fit, int image_noffset, 
const char *p)
printf("0x%08lx\n", load);
}
 
+   /* optional load address for FDT */
+   if (type == IH_TYPE_FLATDT && !fit_image_get_load(fit, image_noffset, 
))
+   printf("%s  Load Address: 0x%08lx\n", p, load);
+
if ((type == IH_TYPE_KERNEL) || (type == IH_TYPE_STANDALONE) ||
(type == IH_TYPE_RAMDISK)) {
ret = fit_image_get_entry(fit, image_noffset, );
@@ -1454,6 +1459,8 @@ int fit_conf_get_node(const void *fit, const char 
*conf_uname)
 {
int noffset, confs_noffset;
int len;
+   const char *s;
+   char *conf_uname_copy = NULL;
 
confs_noffset = fdt_path_offset(fit, FIT_CONFS_PATH);
if (confs_noffset < 0) {
@@ -1475,29 +1482,58 @@ int fit_conf_get_node(const void *fit, const char 
*conf_uname)
debug("Found default configuration: '%s'\n", conf_uname);
}
 
+   s = strchr(conf_uname, '#');
+   if (s) {
+   len = s - conf_uname;
+   conf_uname_copy = malloc(len + 1);
+   if (!conf_uname_copy) {
+   debug("Can't allocate uname copy: '%s'\n",
+   conf_uname);
+   return -ENOMEM;
+   }
+   memcpy(conf_uname_copy, conf_uname, len);
+   conf_uname_copy[len] = '\0';
+   conf_uname = conf_uname_copy;
+   }
+
noffset = fdt_subnode_offset(fit, confs_noffset, conf_uname);
if (noffset < 0) {
debug("Can't get node offset for configuration unit name: '%s' 
(%s)\n",
  conf_uname, fdt_strerror(noffset));
}
 
+   if (conf_uname_copy)
+   free(conf_uname_copy);
+
return noffset;
 }
 
-int fit_conf_get_prop_node(const void *fit, int noffset,
+int fit_conf_get_prop_node_count(const void *fit, int noffset,
const char *prop_name)
 {
-   char *uname;
+   return fdt_stringlist_count(fit, noffset, prop_name);
+}
+
+int fit_conf_get_prop_node_index(const void *fit, int noffset,
+   const char *prop_name, int index)
+{
+   const char *uname;
int len;
 
/* get kernel image unit name from configuration kernel property */
-   uname = (char *)fdt_getprop(fit, noffset, prop_name, );
+   uname = fdt_stringlist_get(fit, noffset, prop_name, index, );
if (uname == NULL)
return len;
 
return fit_image_get_node(fit, uname);
 }
 
+int fit_conf_get_prop_node(const void *fit, int noffset,
+   const char *prop_name)
+{
+   return fit_conf_get_prop_node_index(fit, noffset, prop_na

[U-Boot] [PATCH v2 05/10] doc: Document how to apply fdt overlays

[Pantelis Antoniou]

We have the capability to apply overlays on the command line but
we didn't have a document explaining how.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 doc/README.fdt-overlays | 37 +
 1 file changed, 37 insertions(+)
 create mode 100644 doc/README.fdt-overlays

diff --git a/doc/README.fdt-overlays b/doc/README.fdt-overlays
new file mode 100644
index 000..ee868ec
--- /dev/null
+++ b/doc/README.fdt-overlays
@@ -0,0 +1,37 @@
+U-Boot FDT Overlay usage (without FIT images)
+=
+
+FDT overlays are now available for use even without FIT images.
+It is not as automagic as with FIT images though and require a few
+manual steps.
+
+1. Figure out where to place both the base device tree blob and the
+overlay. Make sure you have enough space to grow the base tree without
+overlapping anything.
+
+=> setenv fdtaddr 0x87f0
+=> setenv fdtovaddr 0x87fc
+
+2. Load the base blob and overlay blobs
+
+=> load ${devtype} ${bootpart} ${fdtaddr} ${bootdir}/base.dtb
+=> load ${devtype} ${bootpart} ${fdtovaddr} ${bootdir}/overlay.dtb
+
+3. Set it as the working fdt tree.
+
+=> fdtaddr $fdtaddr
+
+4. Grow it enough so it can 'fit' all the applied overlays
+
+=> fdt resize 8192
+
+5. You are now ready to apply the overlay.
+
+=> fdt apply $fdtovaddr
+
+Please note that in case of an error, both the base and overlays are going
+to be invalidated, so keep copies to avoid reloading.
+
+Pantelis Antoniou
+pantelis.anton...@konsulko.com
+11/7/2017
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 06/10] doc: overlays: Tweak documentation regarding overlays

[Pantelis Antoniou]

From: Franklin S Cooper Jr 

Pull some information regarding overlays from commit messages and
put them directly within the documentation. Also add some information
regarding required dtc version to properly use overlays.

Signed-off-by: Franklin S Cooper Jr 
---
 doc/README.fdt-overlays | 85 +++--
 doc/uImage.FIT/overlay-fdt-boot.txt |  8 +++-
 2 files changed, 87 insertions(+), 6 deletions(-)

diff --git a/doc/README.fdt-overlays b/doc/README.fdt-overlays
index ee868ec..39139cb 100644
--- a/doc/README.fdt-overlays
+++ b/doc/README.fdt-overlays
@@ -1,9 +1,76 @@
-U-Boot FDT Overlay usage (without FIT images)
+U-Boot FDT Overlay usage
 =
 
-FDT overlays are now available for use even without FIT images.
-It is not as automagic as with FIT images though and require a few
-manual steps.
+Overlays Syntax
+---
+
+Overlays require slightly different syntax compared to traditional overlays.
+Please refer to dt-object-internal.txt in the dtc sources for information
+regarding the internal format of overlays:
+https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/Documentation/dt-object-internal.txt
+
+Building Overlays
+-
+
+In a nutshell overlays provides a means to manipulate a symbol a previous dtb
+or overlay has defined. It requires both the base and all the overlays
+to be compiled with the -@ command line switch so that symbol information is
+included.
+
+Note support for -@ option can only be found in dtc version 1.4.4 or newer.
+Only version 4.14 or higher of the Linux kernel includes a built in version
+of dtc that meets this requirement.
+
+Building an overlay follows the same process as building a traditional dtb.
+
+For example:
+
+base.dts
+
+
+   /dts-v1/;
+   / {
+   foo: foonode {
+   foo-property;
+   };
+   };
+
+   $ dtc -@ -I dts -O dtb -o base.dtb base.dts
+
+bar.dts
+---
+
+   /dts-v1/;
+   /plugin/;
+   / {
+   fragment@1 {
+   target = <>;
+   __overlay__ {
+   overlay-1-property;
+   bar: barnode {
+   bar-property;
+   };
+   };
+   };
+   };
+
+   $ dtc -@ -I dts -O dtb -o bar.dtb bar.dts
+
+Ways to Utilize Overlays in U-boot
+--
+
+There are two ways to apply overlays in U-boot.
+1. Include and define overlays within a FIT image and have overlays
+   automatically applied.
+
+2. Manually load and apply overlays
+
+The remainder of this document will discuss using overlays via the manual
+approach. For information on using overlays as part of a FIT image please see:
+doc/uImage.FIT/overlay-fdt-boot.txt
+
+Manually Loading and Applying Overlays
+--
 
 1. Figure out where to place both the base device tree blob and the
 overlay. Make sure you have enough space to grow the base tree without
@@ -29,6 +96,16 @@ overlapping anything.
 
 => fdt apply $fdtovaddr
 
+6. Boot system like you would do with a traditional dtb.
+
+For bootm:
+
+=> bootm ${kerneladdr} - ${fdtaddr}
+
+For bootz:
+
+=> bootz ${kerneladdr} - ${fdtaddr}
+
 Please note that in case of an error, both the base and overlays are going
 to be invalidated, so keep copies to avoid reloading.
 
diff --git a/doc/uImage.FIT/overlay-fdt-boot.txt 
b/doc/uImage.FIT/overlay-fdt-boot.txt
index dbdf2a1..63e47da 100644
--- a/doc/uImage.FIT/overlay-fdt-boot.txt
+++ b/doc/uImage.FIT/overlay-fdt-boot.txt
@@ -1,5 +1,5 @@
-U-Boot FDT Overlay usage
-
+U-Boot FDT Overlay FIT usage
+
 
 Introduction
 
@@ -8,6 +8,10 @@ of similar boards and their expansion options. The same kernel 
on DT enabled
 platforms can support this easily enough by providing a DT blob upon boot
 that matches the desired configuration.
 
+This document focuses on specifically using overlays as part of a FIT image.
+General information regarding overlays including its syntax and building it
+can be found in doc/README.fdt-overlays
+
 Configuration without overlays
 --
 
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 02/10] fdt: Allow stacked overlays phandle references

[Pantelis Antoniou]

This patch enables an overlay to refer to a previous overlay's
labels by performing a merge of symbol information at application
time.

In a nutshell it allows an overlay to refer to a symbol that a previous
overlay has defined. It requires both the base and all the overlays
to be compiled with the -@ command line switch so that symbol
information is included.

base.dts


/dts-v1/;
/ {
foo: foonode {
foo-property;
};
};

$ dtc -@ -I dts -O dtb -o base.dtb base.dts

bar.dts
---

/dts-v1/;
/plugin/;
/ {
fragment@1 {
target = <>;
__overlay__ {
overlay-1-property;
bar: barnode {
bar-property;
};
};
};
};

$ dtc -@ -I dts -O dtb -o bar.dtb bar.dts

baz.dts
---

/dts-v1/;
/plugin/;
/ {
fragment@1 {
target = <>;
__overlay__ {
overlay-2-property;
baz: baznode {
baz-property;
};
};
};
};

$ dtc -@ -I dts -O dtb -o baz.dtb baz.dts

Applying the overlays:

$ fdtoverlay -i base.dtb -o target.dtb bar.dtb baz.dtb

Dumping:

$ fdtdump target.dtb
/ {
foonode {
overlay-1-property;
foo-property;
linux,phandle = <0x0001>;
phandle = <0x0001>;
barnode {
overlay-2-property;
phandle = <0x0002>;
linux,phandle = <0x0002>;
bar-property;
baznode {
phandle = <0x0003>;
linux,phandle = <0x0003>;
baz-property;
};
};
};
__symbols__ {
baz = "/foonode/barnode/baznode";
bar = "/foonode/barnode";
foo = "/foonode";
};
};

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
---
 lib/libfdt/fdt_overlay.c | 228 ++-
 1 file changed, 206 insertions(+), 22 deletions(-)

diff --git a/lib/libfdt/fdt_overlay.c b/lib/libfdt/fdt_overlay.c
index ceb9687..bd81241 100644
--- a/lib/libfdt/fdt_overlay.c
+++ b/lib/libfdt/fdt_overlay.c
@@ -39,6 +39,7 @@ static uint32_t overlay_get_target_phandle(const void *fdto, 
int fragment)
  * @fdt: Base device tree blob
  * @fdto: Device tree overlay blob
  * @fragment: node offset of the fragment in the overlay
+ * @pathp: pointer which receives the path of the target (or NULL)
  *
  * overlay_get_target() retrieves the target offset in the base
  * device tree of a fragment, no matter how the actual targetting is
@@ -49,37 +50,47 @@ static uint32_t overlay_get_target_phandle(const void 
*fdto, int fragment)
  *  Negative error code on error
  */
 static int overlay_get_target(const void *fdt, const void *fdto,
- int fragment)
+ int fragment, char const **pathp)
 {
uint32_t phandle;
-   const char *path;
-   int path_len;
+   const char *path = NULL;
+   int path_len = 0, ret;
 
/* Try first to do a phandle based lookup */
phandle = overlay_get_target_phandle(fdto, fragment);
if (phandle == (uint32_t)-1)
return -FDT_ERR_BADPHANDLE;
 
-   if (phandle)
-   return fdt_node_offset_by_phandle(fdt, phandle);
+   /* no phandle, try path */
+   if (!phandle) {
+   /* And then a path based lookup */
+   path = fdt_getprop(fdto, fragment, "target-path", _len);
+   if (path)
+   ret = fdt_path_offset(fdt, path);
+   else
+   ret = path_len;
+   } else
+   ret = fdt_node_offset_by_phandle(fdt, phandle);
 
-   /* And then a path based lookup */
-   path = fdt_getprop(fdto, fragment, "target-path", _len);
-   if (!path) {
-   /*
-* If we haven't found either a target or a
-* target-path property in a node that contains a
-* __overlay__ subnode (we wouldn't be called
-* otherwise), consider it a improperly written
-* overlay
-*/
-   if (path_len == -

[U-Boot] [PATCH v2 01/10] Introduce fdt_setprop_placeholder() method

[Pantelis Antoniou]

In some cases you need to add a property but the contents of it
are not known at creation time, merely the extend of it.

This method allows you to create a property of a given size (filled
with garbage) while a pointer to the property data will be provided.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
[dwg: Corrected commit message]
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
---
 lib/libfdt/fdt_rw.c | 20 +---
 lib/libfdt/libfdt.h | 31 +++
 2 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/lib/libfdt/fdt_rw.c b/lib/libfdt/fdt_rw.c
index 80a3212..3dc7752 100644
--- a/lib/libfdt/fdt_rw.c
+++ b/lib/libfdt/fdt_rw.c
@@ -228,8 +228,8 @@ int fdt_set_name(void *fdt, int nodeoffset, const char 
*name)
return 0;
 }
 
-int fdt_setprop(void *fdt, int nodeoffset, const char *name,
-   const void *val, int len)
+int fdt_setprop_placeholder(void *fdt, int nodeoffset, const char *name,
+   int len, void **prop_data)
 {
struct fdt_property *prop;
int err;
@@ -242,8 +242,22 @@ int fdt_setprop(void *fdt, int nodeoffset, const char 
*name,
if (err)
return err;
 
+   *prop_data = prop->data;
+   return 0;
+}
+
+int fdt_setprop(void *fdt, int nodeoffset, const char *name,
+   const void *val, int len)
+{
+   void *prop_data;
+   int err;
+
+   err = fdt_setprop_placeholder(fdt, nodeoffset, name, len, _data);
+   if (err)
+   return err;
+
if (len)
-   memcpy(prop->data, val, len);
+   memcpy(prop_data, val, len);
return 0;
 }
 
diff --git a/lib/libfdt/libfdt.h b/lib/libfdt/libfdt.h
index f3f9cad..6af94cb 100644
--- a/lib/libfdt/libfdt.h
+++ b/lib/libfdt/libfdt.h
@@ -1405,6 +1405,37 @@ int fdt_setprop(void *fdt, int nodeoffset, const char 
*name,
const void *val, int len);
 
 /**
+ * fdt_setprop _placeholder - allocate space for a property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @len: length of the property value
+ * @prop_data: return pointer to property data
+ *
+ * fdt_setprop_placeholer() allocates the named property in the given node.
+ * If the property exists it is resized. In either case a pointer to the
+ * property data is returned.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ * contain the new property value
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_setprop_placeholder(void *fdt, int nodeoffset, const char *name,
+   int len, void **prop_data);
+
+/**
  * fdt_setprop_u32 - set a property to a 32-bit integer
  * @fdt: pointer to the device tree blob
  * @nodeoffset: offset of the node whose property to change
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 00/10] uboot overlays, FIT image & unittest

[Pantelis Antoniou]

This patchset allows uboot to handle overlays in a manner that uses
a base DT blob and an arbitrary number of DT overlays blobs.

While it is intended to be used with FIT images since handling a multitude
of device tree blobs manually is a chore, manual fdt overlay application
is supported and described.

The first 2 patches have already been accepted in DTC mainline.
We can apply them now, or expect the updated drop from mainline.

The next patch contains the FIT FDT blob generation logic as well
as documentation about how it works. 

Path #4 spits out an informative message in case of an overlay
failure that may be attribute to mis-compilation (which is
a common problem).

Patches 5 & 6 are documentation entries.

Patch #7 makes sure unit tests using overlays can be used on
non-sandbox boards.

Patch #8 adds overlay unit tests as part of sandbox's defconfig.

Patch #9 fixes a problem with unit tests using an already
present symbol.

Finally, #10 adds a unit test using a stacked overlay.

The patchset is available at

https://github.com/pantoniou/u-boot/tree/uboot-overlays

and is against mainline u-boot as pulled today, 11/8/2017.

Franklin S Cooper Jr (1):
  doc: overlays: Tweak documentation regarding overlays

Pantelis Antoniou (9):
  Introduce fdt_setprop_placeholder() method
  fdt: Allow stacked overlays phandle references
  fit: Introduce methods for applying overlays on fit-load
  fdt-overlay: Spit out a descriptive failure warning
  doc: Document how to apply fdt overlays
  dtbo: make dtbos special
  config: sandbox: Add unit tests
  ut: fix fdt_getprop_u32() change
  test: overlay: Add unit test for stacked overlay

 cmd/fdt.c|   8 +
 common/image-fdt.c   |   7 +-
 common/image-fit.c   | 226 --
 configs/sandbox_defconfig|   2 +
 doc/README.fdt-overlays  | 114 ++
 doc/uImage.FIT/command_syntax_extensions.txt |  12 +-
 doc/uImage.FIT/overlay-fdt-boot.txt  | 225 ++
 doc/uImage.FIT/source_file_format.txt|   6 +-
 include/image.h  |  10 ++
 lib/libfdt/fdt_overlay.c | 228 ---
 lib/libfdt/fdt_rw.c  |  20 ++-
 lib/libfdt/libfdt.h  |  31 
 scripts/Makefile.lib |  17 ++
 test/overlay/Makefile|   1 +
 test/overlay/cmd_ut_overlay.c|  50 --
 test/overlay/test-fdt-overlay-stacked.dts|  21 +++
 16 files changed, 926 insertions(+), 52 deletions(-)
 create mode 100644 doc/README.fdt-overlays
 create mode 100644 doc/uImage.FIT/overlay-fdt-boot.txt
 create mode 100644 test/overlay/test-fdt-overlay-stacked.dts

-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/5] test: overlay: Add unit test for stacked overlay

[Pantelis Antoniou]

On Fri, 2017-07-07 at 00:48 -0700, Moritz Fischer wrote:
> Hi Pantelis,
> 
> nit inline
> 
> On Fri, Jun 30, 2017 at 9:23 AM, Pantelis Antoniou
> <pantelis.anton...@konsulko.com> wrote:
> > Verify that stacked overlays work.
> >
> > Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
> 
> Reviewed-by: Moritz Fischer <moritz.fisc...@ettus.com>
> > ---
> >  test/overlay/Makefile |  1 +
> >  test/overlay/cmd_ut_overlay.c | 34 
> > ++-
> >  test/overlay/test-fdt-overlay-stacked.dts | 21 +++
> >  3 files changed, 55 insertions(+), 1 deletion(-)
> >  create mode 100644 test/overlay/test-fdt-overlay-stacked.dts
> >
> > diff --git a/test/overlay/Makefile b/test/overlay/Makefile
> > index 907f085..416645c 100644
> > --- a/test/overlay/Makefile
> > +++ b/test/overlay/Makefile
> > @@ -13,3 +13,4 @@ DTC_FLAGS += -@
> >  # DT overlays
> >  obj-y += test-fdt-base.dtb.o
> >  obj-y += test-fdt-overlay.dtb.o
> > +obj-y += test-fdt-overlay-stacked.dtb.o
> > diff --git a/test/overlay/cmd_ut_overlay.c b/test/overlay/cmd_ut_overlay.c
> > index cbef720..d8f5c8f 100644
> > --- a/test/overlay/cmd_ut_overlay.c
> > +++ b/test/overlay/cmd_ut_overlay.c
> > @@ -20,6 +20,7 @@
> >
> >  extern u32 __dtb_test_fdt_base_begin;
> >  extern u32 __dtb_test_fdt_overlay_begin;
> > +extern u32 __dtb_test_fdt_overlay_stacked_begin;
> >
> >  static int fdt_getprop_u32_by_index(void *fdt, const char *path,
> > const char *name, int index,
> > @@ -201,6 +202,19 @@ static int fdt_overlay_local_phandles(struct 
> > unit_test_state *uts)
> >  }
> >  OVERLAY_TEST(fdt_overlay_local_phandles, 0);
> >
> > +static int fdt_overlay_stacked(struct unit_test_state *uts)
> > +{
> > +   void *fdt = uts->priv;
> > +   u32 val = 0;
> > +
> > +   ut_assertok(fdt_getprop_u32(fdt, "/new-local-node", 
> > "stacked-test-int-property",
> > +   ));
> > +   ut_asserteq(43, val);
> > +
> > +   return CMD_RET_SUCCESS;
> > +}
> > +OVERLAY_TEST(fdt_overlay_stacked, 0);
> > +
> >  int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> > argv[])
> >  {
> > struct unit_test *tests = ll_entry_start(struct unit_test,
> > @@ -210,7 +224,8 @@ int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc, 
> > char * const argv[])
> > struct unit_test *test;
> > void *fdt_base = &__dtb_test_fdt_base_begin;
> > void *fdt_overlay = &__dtb_test_fdt_overlay_begin;
> > -   void *fdt_base_copy, *fdt_overlay_copy;
> > +   void *fdt_overlay_stacked = &__dtb_test_fdt_overlay_stacked_begin;
> > +   void *fdt_base_copy, *fdt_overlay_copy, *fdt_overlay_stacked_copy;
> >
> > uts = calloc(1, sizeof(*uts));
> > if (!uts)
> > @@ -228,6 +243,10 @@ int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int 
> > argc, char * const argv[])
> > if (!fdt_overlay_copy)
> > return -ENOMEM;
> >
> > +   fdt_overlay_stacked_copy = malloc(FDT_COPY_SIZE);
> > +   if (!fdt_overlay_stacked_copy)
> > +   return -ENOMEM;
> > +
> > /*
> >  * Resize the FDT to 4k so that we have room to operate on
> >  *
> > @@ -245,9 +264,21 @@ int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int 
> > argc, char * const argv[])
> > ut_assertok(fdt_open_into(fdt_overlay, fdt_overlay_copy,
> >   FDT_COPY_SIZE));
> >
> > +   /*
> > +* Resize the stacked overlay to 4k so that we have room to operate 
> > on
> > +*
> > +* (and relocate it since the memory might be mapped
> > +* read-only)
> > +*/
> > +   ut_assertok(fdt_open_into(fdt_overlay_stacked, 
> > fdt_overlay_stacked_copy,
> > + FDT_COPY_SIZE));
> > +
> > /* Apply the overlay */
> > ut_assertok(fdt_overlay_apply(fdt_base_copy, fdt_overlay_copy));
> >
> > +   /* Apply the stacked overlay */
> > +   ut_assertok(fdt_overlay_apply(fdt_base_copy, 
> > fdt_overlay_stacked_copy));
> > +
> > if (argc == 1)
> > printf("Running %d environment tests\n", n_ents);
> >
> > @@ -263,6 +294,7 @@ int do_ut_overlay(cmd_tbl_t *cmdtp, i

Re: [U-Boot] [PATCH 1/5] libfdt.h: Introduce FDT_PATH_MAX

[Pantelis Antoniou]

Hi Simon,

On Thu, 2017-07-06 at 21:58 -0600, Simon Glass wrote:
> Hi,
> 
> On 1 July 2017 at 08:01, Marek Vasut <ma...@denx.de> wrote:
> > On 06/30/2017 06:22 PM, Pantelis Antoniou wrote:
> >> Introduce FDT_PATH_MAX
> >
> > Because ... why ? The commit message is crap, please fix.
> 
> A better way of saying this is, please add a motivation to the commit
> message :-)
> 

Err, will do, but it's part of a patchset and it's so similar to what
PATH_MAX does. Yeah I guess :)

> Apart from that:
> 
> Reviewed-by: Simon Glass <s...@chromium.org>
> 
> We can just pick it from upstream if it is applied there first.
> 

Regards

-- Pantelis

> >
> >> Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
> >> ---
> >>  lib/libfdt/libfdt.h | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/lib/libfdt/libfdt.h b/lib/libfdt/libfdt.h
> >> index 2f7ebf8..c369015 100644
> >> --- a/lib/libfdt/libfdt.h
> >> +++ b/lib/libfdt/libfdt.h
> >> @@ -100,6 +100,9 @@
> >>
> >>  #define FDT_ERR_MAX  18
> >>
> >> +/* Maximum path size of a node (similar to PATH_MAX in *nix) */
> >> +#define FDT_PATH_MAX 4096
> >> +
> >>  /**/
> >>  /* Low-level functions (you probably don't need these)*/
> >>  /**/
> >>
> >
> >
> > --
> > Best regards,
> > Marek Vasut
> 
> Regards,
> Simon


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/5] fdt: Allow stacked overlays phandle references

[Pantelis Antoniou]

Hi Simon,

On Thu, 2017-07-06 at 21:58 -0600, Simon Glass wrote:
> On 30 June 2017 at 10:23, Pantelis Antoniou
> <pantelis.anton...@konsulko.com> wrote:
> > This patch enables an overlay to refer to a previous overlay's
> > labels by performing a merge of symbol information at application
> > time.
> >
> > In a nutshell it allows an overlay to refer to a symbol that a previous
> > overlay has defined. It requires both the base and all the overlays
> > to be compiled with the -@ command line switch so that symbol
> > information is included.
> >
> > base.dts
> > 
> >
> > /dts-v1/;
> > / {
> > foo: foonode {
> > foo-property;
> > };
> > };
> >
> > $ dtc -@ -I dts -O dtb -o base.dtb base.dts
> >
> > bar.dts
> > ---
> >
> > /dts-v1/;
> > /plugin/;
> > / {
> > fragment@1 {
> > target = <>;
> > __overlay__ {
> > overlay-1-property;
> > bar: barnode {
> > bar-property;
> > };
> > };
> > };
> > };
> >
> > $ dtc -@ -I dts -O dtb -o bar.dtb bar.dts
> >
> > baz.dts
> > ---
> >
> > /dts-v1/;
> > /plugin/;
> > / {
> > fragment@1 {
> > target = <>;
> > __overlay__ {
> > overlay-2-property;
> > baz: baznode {
> > baz-property;
> > };
> > };
> > };
> > };
> >
> > $ dtc -@ -I dts -O dtb -o baz.dtb baz.dts
> >
> > Applying the overlays:
> >
> > $ fdtoverlay -i base.dtb -o target.dtb bar.dtb baz.dtb
> >
> > Dumping:
> >
> > $ fdtdump target.dtb
> > / {
> > foonode {
> > overlay-1-property;
> > foo-property;
> > linux,phandle = <0x0001>;
> > phandle = <0x0001>;
> > barnode {
> > overlay-2-property;
> > phandle = <0x0002>;
> > linux,phandle = <0x0002>;
> >     bar-property;
> > baznode {
> > phandle = <0x0003>;
> > linux,phandle = <0x0003>;
> > baz-property;
> > };
> > };
> > };
> > __symbols__ {
> > baz = "/foonode/barnode/baznode";
> > bar = "/foonode/barnode";
> > foo = "/foonode";
> > };
> > };
> >
> > Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
> > ---
> >  lib/libfdt/fdt_overlay.c | 148 
> > ++-
> >  1 file changed, 147 insertions(+), 1 deletion(-)
> 
> Reviewed-by: Simon Glass <s...@chromium.org>
> 
> I suppose that the upstream version has tests?
> 

Yes, and I could use a couple reviewers in the dtc mailing list.
 
> Does it make sense to implement this in the live tree instead, or do
> you need to modify the DT before relocation?
> 

There is a port of a patch that works on the live tree; I guess I can
port it to u-boot's live tree as well.

Speaking of which I've done quite a bit of work on a different live tree
implementation as well. I would propose we split off u-boot's one in a
library and port my changes there. That way we can have a definitive
live tree implementation, and in the future move dtc's internal live
tree to it as well. We keep on implementing the same functionality in
different flavors for years, let's consolidate, and start working on
ideas for the future.

> - Simon

Regards

-- Pantelis


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] fit: Introduce methods for applying overlays on fit-load

[Pantelis Antoniou]

Hi Marek,

On Sat, 2017-07-01 at 16:11 +0200, Marek Vasut wrote:
> On 06/30/2017 06:23 PM, Pantelis Antoniou wrote:
> > Introduce an overlay based method for constructing a base DT blob
> > to pass to the kernel.
> > 
> > Both canned and runtime feature selection is supported.
> > 
> > Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
> 
> [...]
> 
> > @@ -1475,29 +1482,58 @@ int fit_conf_get_node(const void *fit, const char 
> > *conf_uname)
> > debug("Found default configuration: '%s'\n", conf_uname);
> > }
> >  
> > +   s = strchr(conf_uname, '#');
> > +   if (s) {
> > +   len = s - conf_uname;
> > +   conf_uname_copy = malloc(len + 1);
> > +   if (!conf_uname_copy) {
> > +   debug("Can't allocate uname copy: '%s'\n",
> > +   conf_uname);
> > +   return -ENOMEM;
> > +   }
> > +   memcpy(conf_uname_copy, conf_uname, len);
> 
> Is that like strdup() here ?
> 

No. The space allocated is not the full string, just the span until the
next #.

> > +   conf_uname_copy[len] = '\0';
> > +   conf_uname = conf_uname_copy;
> > +   }
> > +
> > noffset = fdt_subnode_offset(fit, confs_noffset, conf_uname);
> > if (noffset < 0) {
> > debug("Can't get node offset for configuration unit name: '%s' 
> > (%s)\n",
> >   conf_uname, fdt_strerror(noffset));
> > }
> >  
> > +   if (conf_uname_copy)
> > +   free(conf_uname_copy);
> > +
> > return noffset;
> >  }
> 
> [...]
> 
> 

Regards

-- Pantelis


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/5] fdt: Allow stacked overlays phandle references

[Pantelis Antoniou]

Hi Marek,

On Sat, 2017-07-01 at 16:07 +0200, Marek Vasut wrote:
> On 06/30/2017 06:23 PM, Pantelis Antoniou wrote:
> 
> [...]
> 
> > +static int overlay_symbol_update(void *fdt, void *fdto)
> > +{
> > +   int root_sym, ov_sym, prop, path_len, fragment, target;
> > +   int len, frag_name_len, ret, rel_path_len;
> > +   const char *s;
> > +   const char *path;
> > +   const char *name;
> > +   const char *frag_name;
> > +   const char *rel_path;
> > +   char *buf = NULL;
> > +
> > +   root_sym = fdt_subnode_offset(fdt, 0, "__symbols__");
> > +   ov_sym = fdt_subnode_offset(fdto, 0, "__symbols__");
> > +
> > +   /* if neither exist we can't update symbols, but that's OK */
> > +   if (root_sym < 0 || ov_sym < 0)
> > +   return 0;
> 
> If you have symbol table in either the DTO or the base DT, but not in
> the other one, wouldn't it make sense to use that one symbol table
> instead of bailing out ?
> 

It's bailing out without an error.

The logic is simple; if there's no symbol table in the base tree, that
means that there's no symbols in the base device tree, i.e. not compiled
with the option to generate it. No point in inserting overlay symbols.

If there's no symbol table in the overlay that perfectly fine, no symbol
work then.

> > +   buf = malloc(FDT_PATH_MAX);
> > +   if (!buf)
> > +   return -FDT_ERR_NOSPACE;
> 
> Would it make sense to allocate this on stack ?
> 

FDT_PATH_MAX = 4K, dubious if the u-boot stack will have enough space.
Especially in SPL cases. 

> > +   /* iterate over each overlay symbol */
> > +   fdt_for_each_property_offset(prop, fdto, ov_sym) {
> > +
> > +   path = fdt_getprop_by_offset(fdto, prop, , _len);
> > +   if (!path) {
> > +   ret = path_len;
> > +   goto out;
> > +   }
> > +
> > +   /* skip autogenerated properties */
> > +   if (!strcmp(name, "name"))
> > +   continue;
> > +
> > +   /* format: //__overlay__/ 
> > */
> > +
> > +   if (*path != '/') {
> > +   ret = -FDT_ERR_BADVALUE;
> > +   goto out;
> > +   }
> > +
> > +   /* get frag name first */
> 
> "frag name" ? What is this now, Unreal Tournament ? :)
> 

Fragment. There were computers before first person shooters.

> > +   s = strchr(path + 1, '/');
> > +   if (!s) {
> > +   ret = -FDT_ERR_BADVALUE;
> > +   goto out;
> > +   }
> > +   frag_name = path + 1;
> > +   frag_name_len = s - path - 1;
> > +
> > +   /* verify format */
> > +   len = strlen("/__overlay__/");
> > +   if (strncmp(s, "/__overlay__/", len)) {
> > +   ret = -FDT_ERR_NOTFOUND;
> > +   goto out;
> > +   }
> > +
> > +   rel_path = s + len;
> > +   rel_path_len = strlen(rel_path);
> > +
> > +   /* find the fragment index in which the symbol lies */
> > +   fdt_for_each_subnode(fragment, fdto, 0) {
> > +
> > +   s = fdt_get_name(fdto, fragment, );
> > +   if (!s)
> > +   continue;
> > +
> > +   /* name must match */
> > +   if (len == frag_name_len && !memcmp(s, frag_name, len))
> > +   break;
> > +   }
> > +
> > +   /* not found? */
> > +   if (fragment < 0) {
> > +   ret = -FDT_ERR_NOTFOUND;
> > +   goto out;
> > +   }
> > +
> > +   /* an __overlay__ subnode must exist */
> > +   ret = fdt_subnode_offset(fdto, fragment, "__overlay__");
> > +   if (ret < 0)
> > +   goto out;
> > +
> > +   /* get the target of the fragment */
> > +   ret = overlay_get_target(fdt, fdto, fragment);
> > +   if (ret < 0)
> > +   goto out;
> > +   target = ret;
> > +
> > +   /* get the path of the target */
> > +   ret = fdt_get_path(fdt, target, buf, FDT_PATH_MAX);
> > +   if (ret < 0)
> > +   goto out;
> > +
> > +   len = strlen(buf);
> > +
> > +   /* if the target is root strip leading / */
> > + 

Re: [U-Boot] [PATCH 2/5] libfdt_env.h: Add in libfdt environment

[Pantelis Antoniou]

Hi Marek,

On Sat, 2017-07-01 at 16:02 +0200, Marek Vasut wrote:
> On 06/30/2017 06:22 PM, Pantelis Antoniou wrote:
> > Overlays require malloc so add it in the libfdt environment.
> 
> Include this where it's actually used, not in some header.
> 

This follows the same method of libfdt adaption layer, that all required
headers are placed in the libfdt_env.h file so that upreving to a new
libfdt version is less painful.

Sorry, libfdt is not normal u-boot code :)

> > Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
> > ---
> >  include/libfdt_env.h | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/include/libfdt_env.h b/include/libfdt_env.h
> > index 6c6845f..59463c0 100644
> > --- a/include/libfdt_env.h
> > +++ b/include/libfdt_env.h
> > @@ -27,6 +27,7 @@ typedef __be64 fdt64_t;
> >  #include 
> >  
> >  #define strtoul(cp, endp, base)simple_strtoul(cp, endp, base)
> > +#include 
> >  #endif
> >  
> >  /* adding a ramdisk needs 0x44 bytes in version 2008.10 */
> > 
> 
> 

Regards

-- Pantelis


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 4/5] test: overlay: Add unit test for stacked overlay

[Pantelis Antoniou]

Verify that stacked overlays work.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 test/overlay/Makefile |  1 +
 test/overlay/cmd_ut_overlay.c | 34 ++-
 test/overlay/test-fdt-overlay-stacked.dts | 21 +++
 3 files changed, 55 insertions(+), 1 deletion(-)
 create mode 100644 test/overlay/test-fdt-overlay-stacked.dts

diff --git a/test/overlay/Makefile b/test/overlay/Makefile
index 907f085..416645c 100644
--- a/test/overlay/Makefile
+++ b/test/overlay/Makefile
@@ -13,3 +13,4 @@ DTC_FLAGS += -@
 # DT overlays
 obj-y += test-fdt-base.dtb.o
 obj-y += test-fdt-overlay.dtb.o
+obj-y += test-fdt-overlay-stacked.dtb.o
diff --git a/test/overlay/cmd_ut_overlay.c b/test/overlay/cmd_ut_overlay.c
index cbef720..d8f5c8f 100644
--- a/test/overlay/cmd_ut_overlay.c
+++ b/test/overlay/cmd_ut_overlay.c
@@ -20,6 +20,7 @@
 
 extern u32 __dtb_test_fdt_base_begin;
 extern u32 __dtb_test_fdt_overlay_begin;
+extern u32 __dtb_test_fdt_overlay_stacked_begin;
 
 static int fdt_getprop_u32_by_index(void *fdt, const char *path,
const char *name, int index,
@@ -201,6 +202,19 @@ static int fdt_overlay_local_phandles(struct 
unit_test_state *uts)
 }
 OVERLAY_TEST(fdt_overlay_local_phandles, 0);
 
+static int fdt_overlay_stacked(struct unit_test_state *uts)
+{
+   void *fdt = uts->priv;
+   u32 val = 0;
+
+   ut_assertok(fdt_getprop_u32(fdt, "/new-local-node", 
"stacked-test-int-property",
+   ));
+   ut_asserteq(43, val);
+
+   return CMD_RET_SUCCESS;
+}
+OVERLAY_TEST(fdt_overlay_stacked, 0);
+
 int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
struct unit_test *tests = ll_entry_start(struct unit_test,
@@ -210,7 +224,8 @@ int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
struct unit_test *test;
void *fdt_base = &__dtb_test_fdt_base_begin;
void *fdt_overlay = &__dtb_test_fdt_overlay_begin;
-   void *fdt_base_copy, *fdt_overlay_copy;
+   void *fdt_overlay_stacked = &__dtb_test_fdt_overlay_stacked_begin;
+   void *fdt_base_copy, *fdt_overlay_copy, *fdt_overlay_stacked_copy;
 
uts = calloc(1, sizeof(*uts));
if (!uts)
@@ -228,6 +243,10 @@ int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
if (!fdt_overlay_copy)
return -ENOMEM;
 
+   fdt_overlay_stacked_copy = malloc(FDT_COPY_SIZE);
+   if (!fdt_overlay_stacked_copy)
+   return -ENOMEM;
+
/*
 * Resize the FDT to 4k so that we have room to operate on
 *
@@ -245,9 +264,21 @@ int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
ut_assertok(fdt_open_into(fdt_overlay, fdt_overlay_copy,
  FDT_COPY_SIZE));
 
+   /*
+* Resize the stacked overlay to 4k so that we have room to operate on
+*
+* (and relocate it since the memory might be mapped
+* read-only)
+*/
+   ut_assertok(fdt_open_into(fdt_overlay_stacked, fdt_overlay_stacked_copy,
+ FDT_COPY_SIZE));
+
/* Apply the overlay */
ut_assertok(fdt_overlay_apply(fdt_base_copy, fdt_overlay_copy));
 
+   /* Apply the stacked overlay */
+   ut_assertok(fdt_overlay_apply(fdt_base_copy, fdt_overlay_stacked_copy));
+
if (argc == 1)
printf("Running %d environment tests\n", n_ents);
 
@@ -263,6 +294,7 @@ int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 
printf("Failures: %d\n", uts->fail_count);
 
+   free(fdt_overlay_stacked_copy);
free(fdt_overlay_copy);
free(fdt_base_copy);
free(uts);
diff --git a/test/overlay/test-fdt-overlay-stacked.dts 
b/test/overlay/test-fdt-overlay-stacked.dts
new file mode 100644
index 000..9fb7c7b
--- /dev/null
+++ b/test/overlay/test-fdt-overlay-stacked.dts
@@ -0,0 +1,21 @@
+/*
+ * Copyright (c) 2016 NextThing Co
+ * Copyright (c) 2016 Free Electrons
+ * Copyright (c) 2018 Konsulko Group
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+/plugin/;
+
+/ {
+   /* Test that we can reference an overlay symbol */
+   fragment@0 {
+   target = <>;
+
+   __overlay__ {
+   stacked-test-int-property = <43>;
+   };
+   };
+};
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 3/5] fdt: Allow stacked overlays phandle references

[Pantelis Antoniou]

This patch enables an overlay to refer to a previous overlay's
labels by performing a merge of symbol information at application
time.

In a nutshell it allows an overlay to refer to a symbol that a previous
overlay has defined. It requires both the base and all the overlays
to be compiled with the -@ command line switch so that symbol
information is included.

base.dts


/dts-v1/;
/ {
foo: foonode {
foo-property;
};
};

$ dtc -@ -I dts -O dtb -o base.dtb base.dts

bar.dts
---

/dts-v1/;
/plugin/;
/ {
fragment@1 {
target = <>;
__overlay__ {
overlay-1-property;
bar: barnode {
bar-property;
};
};
};
};

$ dtc -@ -I dts -O dtb -o bar.dtb bar.dts

baz.dts
---

/dts-v1/;
/plugin/;
/ {
fragment@1 {
target = <>;
__overlay__ {
overlay-2-property;
baz: baznode {
baz-property;
};
};
};
};

$ dtc -@ -I dts -O dtb -o baz.dtb baz.dts

Applying the overlays:

$ fdtoverlay -i base.dtb -o target.dtb bar.dtb baz.dtb

Dumping:

$ fdtdump target.dtb
/ {
foonode {
overlay-1-property;
foo-property;
linux,phandle = <0x0001>;
phandle = <0x0001>;
barnode {
overlay-2-property;
phandle = <0x0002>;
linux,phandle = <0x0002>;
bar-property;
baznode {
phandle = <0x0003>;
linux,phandle = <0x0003>;
baz-property;
};
};
};
__symbols__ {
baz = "/foonode/barnode/baznode";
bar = "/foonode/barnode";
foo = "/foonode";
};
};

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 lib/libfdt/fdt_overlay.c | 148 ++-
 1 file changed, 147 insertions(+), 1 deletion(-)

diff --git a/lib/libfdt/fdt_overlay.c b/lib/libfdt/fdt_overlay.c
index ceb9687..59fd7f3 100644
--- a/lib/libfdt/fdt_overlay.c
+++ b/lib/libfdt/fdt_overlay.c
@@ -590,7 +590,7 @@ static int overlay_apply_node(void *fdt, int target,
  *
  * overlay_merge() merges an overlay into its base device tree.
  *
- * This is the final step in the device tree overlay application
+ * This is the next to last step in the device tree overlay application
  * process, when all the phandles have been adjusted and resolved and
  * you just have to merge overlay into the base device tree.
  *
@@ -630,6 +630,148 @@ static int overlay_merge(void *fdt, void *fdto)
return 0;
 }
 
+/**
+ * overlay_symbol_update - Update the symbols of base tree after a merge
+ * @fdt: Base Device Tree blob
+ * @fdto: Device tree overlay blob
+ *
+ * overlay_symbol_update() updates the symbols of the base tree with the
+ * symbols of the applied overlay
+ *
+ * This is the last step in the device tree overlay application
+ * process, allowing the reference of overlay symbols by subsequent
+ * overlay operations.
+ *
+ * returns:
+ *  0 on success
+ *  Negative error code on failure
+ */
+static int overlay_symbol_update(void *fdt, void *fdto)
+{
+   int root_sym, ov_sym, prop, path_len, fragment, target;
+   int len, frag_name_len, ret, rel_path_len;
+   const char *s;
+   const char *path;
+   const char *name;
+   const char *frag_name;
+   const char *rel_path;
+   char *buf = NULL;
+
+   root_sym = fdt_subnode_offset(fdt, 0, "__symbols__");
+   ov_sym = fdt_subnode_offset(fdto, 0, "__symbols__");
+
+   /* if neither exist we can't update symbols, but that's OK */
+   if (root_sym < 0 || ov_sym < 0)
+   return 0;
+
+   buf = malloc(FDT_PATH_MAX);
+   if (!buf)
+   return -FDT_ERR_NOSPACE;
+
+   /* iterate over each overlay symbol */
+   fdt_for_each_property_offset(prop, fdto, ov_sym) {
+
+   path = fdt_getprop_by_offset(fdto, prop, , _len);
+   if (!path) {
+   ret = path_len;
+   goto out;
+   }
+
+   /* skip autogenerated properties */
+   if (!strcmp(name, "na

[U-Boot] [PATCH 5/5] fit: Introduce methods for applying overlays on fit-load

[Pantelis Antoniou]

Introduce an overlay based method for constructing a base DT blob
to pass to the kernel.

Both canned and runtime feature selection is supported.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 common/image-fdt.c   |   7 +-
 common/image-fit.c   | 215 --
 doc/uImage.FIT/command_syntax_extensions.txt |  12 +-
 doc/uImage.FIT/overlay-fdt-boot.txt  | 221 +++
 doc/uImage.FIT/source_file_format.txt|   6 +-
 include/image.h  |  10 ++
 6 files changed, 453 insertions(+), 18 deletions(-)
 create mode 100644 doc/uImage.FIT/overlay-fdt-boot.txt

diff --git a/common/image-fdt.c b/common/image-fdt.c
index c6e8832..a59134c 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -356,17 +356,16 @@ int boot_get_fdt(int flag, int argc, char * const argv[], 
uint8_t arch,
if (fit_check_format(buf)) {
ulong load, len;
 
-   fdt_noffset = fit_image_load(images,
+   fdt_noffset = boot_get_fdt_fit(images,
fdt_addr, _uname_fdt,
_uname_config,
-   arch, IH_TYPE_FLATDT,
-   BOOTSTAGE_ID_FIT_FDT_START,
-   FIT_LOAD_OPTIONAL, , );
+   arch, , );
 
images->fit_hdr_fdt = map_sysmem(fdt_addr, 0);
images->fit_uname_fdt = fit_uname_fdt;
images->fit_noffset_fdt = fdt_noffset;
fdt_addr = load;
+
break;
} else
 #endif
diff --git a/common/image-fit.c b/common/image-fit.c
index 109ecfa..f78c5cf 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 DECLARE_GLOBAL_DATA_PTR;
 #endif /* !USE_HOSTCC*/
 
@@ -434,6 +435,10 @@ void fit_image_print(const void *fit, int image_noffset, 
const char *p)
printf("0x%08lx\n", load);
}
 
+   /* optional load address for FDT */
+   if (type == IH_TYPE_FLATDT && !fit_image_get_load(fit, image_noffset, 
))
+   printf("%s  Load Address: 0x%08lx\n", p, load);
+
if ((type == IH_TYPE_KERNEL) || (type == IH_TYPE_STANDALONE) ||
(type == IH_TYPE_RAMDISK)) {
ret = fit_image_get_entry(fit, image_noffset, );
@@ -1454,6 +1459,8 @@ int fit_conf_get_node(const void *fit, const char 
*conf_uname)
 {
int noffset, confs_noffset;
int len;
+   const char *s;
+   char *conf_uname_copy = NULL;
 
confs_noffset = fdt_path_offset(fit, FIT_CONFS_PATH);
if (confs_noffset < 0) {
@@ -1475,29 +1482,58 @@ int fit_conf_get_node(const void *fit, const char 
*conf_uname)
debug("Found default configuration: '%s'\n", conf_uname);
}
 
+   s = strchr(conf_uname, '#');
+   if (s) {
+   len = s - conf_uname;
+   conf_uname_copy = malloc(len + 1);
+   if (!conf_uname_copy) {
+   debug("Can't allocate uname copy: '%s'\n",
+   conf_uname);
+   return -ENOMEM;
+   }
+   memcpy(conf_uname_copy, conf_uname, len);
+   conf_uname_copy[len] = '\0';
+   conf_uname = conf_uname_copy;
+   }
+
noffset = fdt_subnode_offset(fit, confs_noffset, conf_uname);
if (noffset < 0) {
debug("Can't get node offset for configuration unit name: '%s' 
(%s)\n",
  conf_uname, fdt_strerror(noffset));
}
 
+   if (conf_uname_copy)
+   free(conf_uname_copy);
+
return noffset;
 }
 
-int fit_conf_get_prop_node(const void *fit, int noffset,
+int fit_conf_get_prop_node_count(const void *fit, int noffset,
const char *prop_name)
 {
-   char *uname;
+   return fdt_stringlist_count(fit, noffset, prop_name);
+}
+
+int fit_conf_get_prop_node_index(const void *fit, int noffset,
+   const char *prop_name, int index)
+{
+   const char *uname;
int len;
 
/* get kernel image unit name from configuration kernel property */
-   uname = (char *)fdt_getprop(fit, noffset, prop_name, );
+   uname = fdt_stringlist_get(fit, noffset, prop_name, index, );
if (uname == NULL)
return len;
 
return fit_image_get_node(fit, uname);
 }
 
+int fit_conf_get_prop_node(const void *fit, int noffset,
+   const char *prop_name)
+{
+   return fit_conf_get_prop_node_index(fit, noffset, prop_na

[U-Boot] [PATCH 1/5] libfdt.h: Introduce FDT_PATH_MAX

[Pantelis Antoniou]

Introduce FDT_PATH_MAX

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 lib/libfdt/libfdt.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/libfdt/libfdt.h b/lib/libfdt/libfdt.h
index 2f7ebf8..c369015 100644
--- a/lib/libfdt/libfdt.h
+++ b/lib/libfdt/libfdt.h
@@ -100,6 +100,9 @@
 
 #define FDT_ERR_MAX18
 
+/* Maximum path size of a node (similar to PATH_MAX in *nix) */
+#define FDT_PATH_MAX   4096
+
 /**/
 /* Low-level functions (you probably don't need these)*/
 /**/
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/5] libfdt_env.h: Add in libfdt environment

[Pantelis Antoniou]

Overlays require malloc so add it in the libfdt environment.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 include/libfdt_env.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/libfdt_env.h b/include/libfdt_env.h
index 6c6845f..59463c0 100644
--- a/include/libfdt_env.h
+++ b/include/libfdt_env.h
@@ -27,6 +27,7 @@ typedef __be64 fdt64_t;
 #include 
 
 #define strtoul(cp, endp, base)simple_strtoul(cp, endp, base)
+#include 
 #endif
 
 /* adding a ramdisk needs 0x44 bytes in version 2008.10 */
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 0/5] uboot overlays and FIT image

[Pantelis Antoniou]

This patch allows uboot to handle overlays in a manner that uses
a base DT blob and an arbitrary number of DT overlays blobs.

It is intended to be used with FIT images since handling a multitude
of device tree blobs manually is a chore.

The first 3 patches have already been submitted to DTC for review, and
provide the plumbing in libfdt.

The next patch adds a unit test for a stacked overlay (in which an
overlay refers to a symbol contained in a previously applied overlay).

The last patch contains the FIT FDT blob generation logic as well
as documentation about how it all works.

The patchset is available at

https://github.com/pantoniou/u-boot/tree/uboot-overlays

and is against mainline u-boot as pulled today, 30/6/2017.

Pantelis Antoniou (5):
  libfdt.h: Introduce FDT_PATH_MAX
  libfdt_env.h: Add  in libfdt environment
  fdt: Allow stacked overlays phandle references
  test: overlay: Add unit test for stacked overlay
  fit: Introduce methods for applying overlays on fit-load

 common/image-fdt.c   |   7 +-
 common/image-fit.c   | 215 --
 doc/uImage.FIT/command_syntax_extensions.txt |  12 +-
 doc/uImage.FIT/overlay-fdt-boot.txt  | 221 +++
 doc/uImage.FIT/source_file_format.txt|   6 +-
 include/image.h  |  10 ++
 include/libfdt_env.h |   1 +
 lib/libfdt/fdt_overlay.c | 148 +-
 lib/libfdt/libfdt.h  |   3 +
 test/overlay/Makefile|   1 +
 test/overlay/cmd_ut_overlay.c|  34 -
 test/overlay/test-fdt-overlay-stacked.dts|  21 +++
 12 files changed, 659 insertions(+), 20 deletions(-)
 create mode 100644 doc/uImage.FIT/overlay-fdt-boot.txt
 create mode 100644 test/overlay/test-fdt-overlay-stacked.dts

-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] arm: Always keep the dtb section on objcopy

[Pantelis Antoniou]

The dtb blob section must always be present in the resulting image.
Either if OF_EMBEDED is used or if unit tests include dtb blobs.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 arch/arm/config.mk | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index a5eebb9..1a9 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -142,9 +142,11 @@ OBJCOPYFLAGS += -j .text -j .secure_text -j .secure_data 
-j .rodata -j .hash \
-j .data -j .got -j .got.plt -j .u_boot_list -j .rel.dyn
 endif
 
-ifdef CONFIG_OF_EMBED
+# if a dtb section exists we always have to include it
+# there are only two cases where it is generated
+# 1) OF_EMBEDED is turned on
+# 2) unit tests include device tree blobs
 OBJCOPYFLAGS += -j .dtb.init.rodata
-endif
 
 ifdef CONFIG_EFI_LOADER
 OBJCOPYFLAGS += -j .efi_runtime -j .efi_runtime_rel
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] malloc: Turn on DEBUG when enabling unit tests

[Pantelis Antoniou]

Unit tests require mallinfo which in turn requires DEBUG on
dlmalloc to be enabled.

The dependancy on CONFIG_SANDBOX is wrong.

Signed-off-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
---
 common/dlmalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index adc680e..fc1e8b3 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -1,6 +1,6 @@
 #include 
 
-#ifdef CONFIG_SANDBOX
+#if defined(CONFIG_UNIT_TEST)
 #define DEBUG
 #endif
 
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] scripts/Makefile.lib: Only apply u-boot.dtsi files in the target directory

[Pantelis Antoniou]

Hi Tom,

On Wed, 2017-05-24 at 11:04 -0400, Tom Rini wrote:
> We only want to apply files such as 'omap5-u-boot.dtsi', which resides
> in arch/arm/dts/ to other files in arch/arm/dts/ and not say
> test/overlay/.  Rework the make logic to check for -u-boot.dtsi files in
> the same directory as their target dts.
> 

Verified that it fixes the build breakage.

Tested-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>

> Cc: Simon Glass <s...@chromium.org>
> Reported-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>
> Signed-off-by: Tom Rini <tr...@konsulko.com>
> ---
>  scripts/Makefile.lib | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 774aa89a3fe6..80ddb08474cd 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -164,14 +164,12 @@ cpp_flags  = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) 
> $(UBOOTINCLUDE) \
>  
>  ld_flags   = $(LDFLAGS) $(ldflags-y)
>  
> -dts_dir = $(srctree)/arch/$(ARCH)/dts
> -
>  # Try these files in order to find the U-Boot-specific .dtsi include file
> -u_boot_dtsi_options = $(wildcard $(dts_dir)/$(basename $(notdir 
> $<))-u-boot.dtsi) \
> - $(wildcard $(dts_dir)/$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \
> - $(wildcard $(dts_dir)/$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \
> - $(wildcard $(dts_dir)/$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \
> - $(wildcard $(dts_dir)/u-boot.dtsi)
> +u_boot_dtsi_options = $(wildcard $(dir $<)$(basename $(notdir 
> $<))-u-boot.dtsi) \
> + $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \
> + $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \
> + $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \
> + $(wildcard $(dir $<)u-boot.dtsi)
>  
>  # Uncomment for debugging
>  # $(warning u_boot_dtsi_options: $(u_boot_dtsi_options))


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] MAINTAINERS, git-mailrc: Update the mmc maintainer

[Pantelis Antoniou]

Hi Jaehoon,

> On Aug 1, 2016, at 06:35 , Jaehoon Chung <jh80.ch...@samsung.com> wrote:
> 
> Update the mmc maintainer from Pantelis to me.
> 
> Signed-off-by: Jaehoon Chung <jh80.ch...@samsung.com>

Acked-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>

Good job!

> ---
> MAINTAINERS| 2 +-
> doc/git-mailrc | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1225ce2..8905f88 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -299,7 +299,7 @@ T:git git://git.denx.de/u-boot-mips.git
> F:arch/mips/
> 
> MMC
> -M:   Pantelis Antoniou <pa...@antoniou-consulting.com>
> +M:   Jaehoon Chung <jh80.ch...@samsung.com>
> S:Maintained
> T:git git://git.denx.de/u-boot-mmc.git
> F:drivers/mmc/
> diff --git a/doc/git-mailrc b/doc/git-mailrc
> index 8f0724f..a14629c 100644
> --- a/doc/git-mailrc
> +++ b/doc/git-mailrc
> @@ -23,6 +23,7 @@ alias galak  Kumar Gala <ga...@kernel.crashing.org>
> alias hs Heiko Schocher <h...@denx.de>
> alias ijcIan Campbell <ijc+ub...@hellion.org.uk>
> alias iwamatsu   Nobuhiro Iwamatsu <iwama...@nigauri.org>
> +alias jaehoonJaehoon Chung <jh80.ch...@samsung.com>
> alias jagan  Jagan Teki <jt...@openedev.com>
> alias jasonjin   Jason Jin <jason@freescale.com>
> alias jhersh Joe Hershberger <joe.hershber...@ni.com>
> @@ -35,7 +36,6 @@ alias marex  Marek Vasut <ma...@denx.de>
> alias masahiro   Masahiro Yamada <yamada.masah...@socionext.com>
> alias mateuszMateusz Kulikowski <mateusz.kulikow...@gmail.com>
> alias monstr Michal Simek <mon...@monstr.eu>
> -alias panto  Pantelis Antoniou <pa...@antoniou-consulting.com>
> alias prafulla   Prafulla Wadaskar <prafu...@marvell.com>
> alias bobenstein Przemyslaw Marczak <p.marc...@samsung.com>
> alias prom   Minkyu Kang <mk7.k...@samsung.com>
> @@ -124,7 +124,7 @@ alias kerneldoc  uboot, marex
> alias fdtuboot, sjg
> alias i2cuboot, hs
> alias kconfiguboot, masahiro
> -alias mmcuboot, panto
> +alias mmcuboot, jaehoon
> alias nand   uboot, scottwood
> alias netuboot, jhersh
> alias phyuboot, jhersh
> -- 
> 1.9.1
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] Auto-detecting touchscreen controller and dealing with hw configuration differences on q8 tablets

[Pantelis Antoniou]

Hi Rob,

> On Jun 20, 2016, at 21:20 , Rob Herring <r...@kernel.org> wrote:
> 
> On Mon, Jun 20, 2016 at 04:08:47PM +0300, Pantelis Antoniou wrote:
>> Hi Hans,
>> 
>>> On Jun 20, 2016, at 16:02 , Hans de Goede <hdego...@redhat.com> wrote:
>>> 
>>> Hi,
>>> 
>>> On 20-06-16 14:22, Pantelis Antoniou wrote:
>>>> Hi Hans,
>>>> 
>>>>> On Jun 20, 2016, at 14:03 , Hans de Goede <hdego...@redhat.com> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> On 20-06-16 11:27, Pantelis Antoniou wrote:
>>> 
>>> 
>>> 
>>>>>> Yes, it’s quite possible. You can even have stacked overlays.
>>>>> 
>>>>> Ok, is there any example code how to change an overlay before applying it 
>>>>> out there,
>>>>> or if not can you point to the functions to use to do this ?
>>>>> 
>>>> 
>>>> The canonical place for all the dynamic DT stuff is
>>>> 
>>>> https://github.com/pantoniou/linux-beagle-track-mainline/tree/bbb-overlays
>>>> 
>>>> The beaglebone cape manager is here.
>>>> 
>>>> https://github.com/pantoniou/linux-beagle-track-mainline/commit/5028d1ed3beb8c75b28fce37b1bb5ee551b2ae9e
>>>> 
>>>>> Specifically my plan is to:
>>>>> 
>>>>> 1) Have a single overlay for q8 tablets with gsl1680 tablets
>>>>> 
>>>>> 2) Write an in kernel overlay manager which when it detects a gsl1680 
>>>>> touchscreen
>>>>> will pick a best-default firmware-file + matching resolution + swap-x-y 
>>>>> based on
>>>>> which SoC (A13/A23/A33) the tablet is based on as well as the gsl1680's 
>>>>> chip-id
>>>>> and will then "patch" this info into the overlay before applying it. This
>>>>> means being able to set / modify several string, int and bool dt 
>>>>> properties.
>>>>> 
>>>>> 3) Offer a kernel-module option for the overlaymanager which will allows
>>>>> overriding the defaults for the firmware-filename, etc. This is also
>>>>> why I want to go with the patch approach instead of having multiple
>>>>> dt-overlay files.
>>>>> 
>>>> 
>>>> Hmm, your problem appears to be simpler. You already know all the possible
>>>> parts that your touchscreen/video/thingy is going to use.
>>>> 
>>>> You don’t have to use an overlay then. Overlays are built on top of
>>>> changesets.
>>>> 
>>>> For example, let’s say that you have various options for a touchscreen out
>>>> of a finite set.
>>>> 
>>>> You just put the basic configuration for each in a disable node and your
>>>> manager only needs to update the properties and set the status to enabled
>>>> for it to be enabled.
>>>> 
>>>> For instance let’s say you have an option of two devices (only one of them
>>>> being present).
>>>> 
>>>> devA {
>>>>status = “disabled”;
>>>>compatible = “foo,A”;
>>>> };
>>>> 
>>>> devB {
>>>>status = “disabled”;
>>>>compatible = “bar,B”;
>>>> };
>>>> 
>>>> Your manager can simply use a changeset to enable A and put a property 
>>>> there
>>>> (example done using the extended helper API for clarity).
>>>> 
>>>>struct of_changeset cset;
>>>>struct device_node *np = of_find_node_by_path(“/devA”);
>>>> 
>>>>of_changeset_init();
>>>>of_changeset_add_property_bool(, np, “invert-x”);
>>>>of_changeset_update_property_string(, np, “status”, “okay”);
>>>> 
>>>>of_changeset_apply();
>>> 
>>> Cool that looks quite nice / easy. 2 questions on the above:
>>> 
>>> 1) Is the functionality needed by the above snippet in mainline ?
>> 
>> Changesets are in mainline; The extended API for the example above is not.
> 
> The reason being that you sent it just before the merge window and there 
> was a comment on it that has not been addressed.
> 

True. I ran out of time and $JOB interfered. I hope I’ll be able to sent out
a new patchset this week.

> Rob

Regards

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] Auto-detecting touchscreen controller and dealing with hw configuration differences on q8 tablets

[Pantelis Antoniou]

Hi Hans,

> On Jun 20, 2016, at 16:02 , Hans de Goede <hdego...@redhat.com> wrote:
> 
> Hi,
> 
> On 20-06-16 14:22, Pantelis Antoniou wrote:
>> Hi Hans,
>> 
>>> On Jun 20, 2016, at 14:03 , Hans de Goede <hdego...@redhat.com> wrote:
>>> 
>>> Hi,
>>> 
>>> On 20-06-16 11:27, Pantelis Antoniou wrote:
> 
> 
> 
>>>> Yes, it’s quite possible. You can even have stacked overlays.
>>> 
>>> Ok, is there any example code how to change an overlay before applying it 
>>> out there,
>>> or if not can you point to the functions to use to do this ?
>>> 
>> 
>> The canonical place for all the dynamic DT stuff is
>> 
>> https://github.com/pantoniou/linux-beagle-track-mainline/tree/bbb-overlays
>> 
>> The beaglebone cape manager is here.
>> 
>> https://github.com/pantoniou/linux-beagle-track-mainline/commit/5028d1ed3beb8c75b28fce37b1bb5ee551b2ae9e
>> 
>>> Specifically my plan is to:
>>> 
>>> 1) Have a single overlay for q8 tablets with gsl1680 tablets
>>> 
>>> 2) Write an in kernel overlay manager which when it detects a gsl1680 
>>> touchscreen
>>> will pick a best-default firmware-file + matching resolution + swap-x-y 
>>> based on
>>> which SoC (A13/A23/A33) the tablet is based on as well as the gsl1680's 
>>> chip-id
>>> and will then "patch" this info into the overlay before applying it. This
>>> means being able to set / modify several string, int and bool dt properties.
>>> 
>>> 3) Offer a kernel-module option for the overlaymanager which will allows
>>> overriding the defaults for the firmware-filename, etc. This is also
>>> why I want to go with the patch approach instead of having multiple
>>> dt-overlay files.
>>> 
>> 
>> Hmm, your problem appears to be simpler. You already know all the possible
>> parts that your touchscreen/video/thingy is going to use.
>> 
>> You don’t have to use an overlay then. Overlays are built on top of
>> changesets.
>> 
>> For example, let’s say that you have various options for a touchscreen out
>> of a finite set.
>> 
>> You just put the basic configuration for each in a disable node and your
>> manager only needs to update the properties and set the status to enabled
>> for it to be enabled.
>> 
>> For instance let’s say you have an option of two devices (only one of them
>> being present).
>> 
>> devA {
>>  status = “disabled”;
>>  compatible = “foo,A”;
>> };
>> 
>> devB {
>>  status = “disabled”;
>>  compatible = “bar,B”;
>> };
>> 
>> Your manager can simply use a changeset to enable A and put a property there
>> (example done using the extended helper API for clarity).
>> 
>>  struct of_changeset cset;
>>  struct device_node *np = of_find_node_by_path(“/devA”);
>> 
>>  of_changeset_init();
>>  of_changeset_add_property_bool(, np, “invert-x”);
>>  of_changeset_update_property_string(, np, “status”, “okay”);
>> 
>>  of_changeset_apply();
> 
> Cool that looks quite nice / easy. 2 questions on the above:
> 
> 1) Is the functionality needed by the above snippet in mainline ?

Changesets are in mainline; The extended API for the example above is not.
So you’ll have to create the property/ies to pass to the bare 
of_changeset_update_property/of_changeset_add_property methods.

Dig into the bbb-overlays branch and you’ll figure it out.

> 2) I assume you'vc e left out error handling from the above
> for simplicity. I assume that of_changeset_apply() needs some
> error return checking ? What about the others ?

Error checking is removed for clarity. On error you simply
destroy the changeset. Changes to the tree apply atomically
or not at all.

> 
> And one new question, the overlay manager will need access
> to (several) i2c busses, preferably I can pass in a phandle
> to these in devicetree, do you have any experience with /
> examples of doing such a thing ?

No problems there. There’s an I2C API to get the bus from a phandle.

> 
> Regards,
> 
> Hans

Regards

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Auto-detecting touchscreen controller and dealing with hw configuration differences on q8 tablets

[Pantelis Antoniou]

Hi Hans,

> On Jun 20, 2016, at 14:03 , Hans de Goede <hdego...@redhat.com> wrote:
> 
> Hi,
> 
> On 20-06-16 11:27, Pantelis Antoniou wrote:
>> Hi Hans,
>> 
>> I’m going to commend only on the overlay related parts since I’m not I
>> get all the nuances right.
> 
> No problem and thanks for the answer anyways!
> 
>>> On Jun 19, 2016, at 14:06 , Hans de Goede <hdego...@redhat.com> wrote:
> 
> 
> 
>>> 2) Give the user some way to override the dts settings.
>>> 
>>> Which after a somewhat long intro brings me to the actual purpose of this 
>>> thread, discuss
>>> how to best deal with this. I again see 2 options:
>>> 
>>> 1) Put a disabled gsl1680 node in the dts file, have a q8_autodetect.c in 
>>> u-boot
>>> which probes i2c and if it finds the gsl1680 nodes enables it, and patches 
>>> in a best-effort
>>> default for which fw file to use. Allow the user to set a touchscreen_fw 
>>> u-boot env
>>> variable which will override this. Also allow the user to set a 
>>> touchscreen_inverted_x env
>>> variable to add inverted-x to the dt node for the gsl1680.
>>> 
>> 
>> That can work. The problem is that having anything requiring smarts in 
>> u-boot always
>> leads to trouble with users. It all depends on your user’s technical 
>> proficiency, if
>> they are comfortable tweaking things in u-boot it’s fine. If it’s not, 
>> expect lots of
>> bricked boards when they mess up.
>> 
>>> 2) Write an in kernel overlay manager which does auto-detect as described 
>>> by 1, and
>>> loads an overlay for the detected touchscreen controller, with module 
>>> options to allow
>>> specifying the fw-file, x-inversion, etc.
>>> 
>>> One things which worries me about 2. is that we would need to have 2 
>>> overlay files
>>> per fw-file, one regular config, one inverted-x, or is it possible for the 
>>> overlay
>>> manager to modify an overlay before applying it ?
>>> 
>> 
>> Yes, it’s quite possible. You can even have stacked overlays.
> 
> Ok, is there any example code how to change an overlay before applying it out 
> there,
> or if not can you point to the functions to use to do this ?
> 

The canonical place for all the dynamic DT stuff is

https://github.com/pantoniou/linux-beagle-track-mainline/tree/bbb-overlays

The beaglebone cape manager is here.

https://github.com/pantoniou/linux-beagle-track-mainline/commit/5028d1ed3beb8c75b28fce37b1bb5ee551b2ae9e

> Specifically my plan is to:
> 
> 1) Have a single overlay for q8 tablets with gsl1680 tablets
> 
> 2) Write an in kernel overlay manager which when it detects a gsl1680 
> touchscreen
> will pick a best-default firmware-file + matching resolution + swap-x-y based 
> on
> which SoC (A13/A23/A33) the tablet is based on as well as the gsl1680's 
> chip-id
> and will then "patch" this info into the overlay before applying it. This
> means being able to set / modify several string, int and bool dt properties.
> 
> 3) Offer a kernel-module option for the overlaymanager which will allows
> overriding the defaults for the firmware-filename, etc. This is also
> why I want to go with the patch approach instead of having multiple
> dt-overlay files.
> 

Hmm, your problem appears to be simpler. You already know all the possible
parts that your touchscreen/video/thingy is going to use.

You don’t have to use an overlay then. Overlays are built on top of
changesets.

For example, let’s say that you have various options for a touchscreen out
of a finite set.

You just put the basic configuration for each in a disable node and your
manager only needs to update the properties and set the status to enabled
for it to be enabled.

For instance let’s say you have an option of two devices (only one of them
being present).

devA {
status = “disabled”;
compatible = “foo,A”;
};

devB {
status = “disabled”;
compatible = “bar,B”;
};

Your manager can simply use a changeset to enable A and put a property there
(example done using the extended helper API for clarity).

struct of_changeset cset;
struct device_node *np = of_find_node_by_path(“/devA”);

of_changeset_init();
of_changeset_add_property_bool(, np, “invert-x”);
of_changeset_update_property_string(, np, “status”, “okay”);

of_changeset_apply();

> Thanks & Regards,
> 
> Hans

Regards

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Auto-detecting touchscreen controller and dealing with hw configuration differences on q8 tablets

[Pantelis Antoniou]

Hi Hans,

I’m going to commend only on the overlay related parts since I’m not I
get all the nuances right.

> On Jun 19, 2016, at 14:06 , Hans de Goede  wrote:
> 
> 
> 
> Hi All,
> 
> The sunxi support in the kernel supports (amongst many other devices) the 
> quite
> popular low cost q8 form factor 7" tablets.
> 
> These are all based on the same case, with an allwinner SoC inside (there
> are non allwinner versions, but those are out of scope) and typically all 
> based on
> the same reference design.
> 
> Currently we support any such tablet with 4 u-boot defconfigs / 4 dts files:
> 
> q8_a13_tablet
> q8_a23_tablet_800x480
> q8_a33_tablet_800x480
> q8_a33_tablet_1026x600
> 
> So all the user needs to know to get mainline running on these is which SoC 
> his
> tablet is using and which resolution his lcd has.
> 
> However the reference design gets completed by the manufacturers with whatever
> accelerometer, wifi chip and touchscreen controller are cheapest for the batch
> being produced that week.
> 
> The plan is (was ?) to use auto-detection to figure out which components are
> used and adjust the dts using e.g. overlays.
> 
> Recently I've been working together with some students from my local 
> university
> to get a driver for the gsl1680 touchscreen controller used in most of these
> tablets upstream.
> 
> So now I've been testing the touschscreen on all q8 tablets I own and
> unfortunately things are not so easy. The gsl1680 is quite flexible, it 
> features
> a number of capacitive sense pins and these can be routed in random order to
> sense lines in the display, during init the controller gets feed a 
> configuration
> data file with which pins go where and various lookup tables.
> 
> Here is a table of all tablets I've tested:
> 
> a13-94v-0:a082 a23-tj-a23-q88-v4.0_20140815/GSL1680E_700_FW.fw
> 1024x600 inverted-x
> a13-tzx-713b-v2.1:a082 a23-tj-a23-q88-v4.0_20140815/GSL1680E_700_FW.fw
> 1024x600
> a23-q8h-v3:   a082 a23-tj-a23-q88-v4.0_20140815/GSL1688_A70_FW.fw 
>  800x480 swapped-x-y
> a23-tj-a23-q88-v4.0:  a082 a23-tj-a23-q88-v4.0_20140815/GSL1680E_700_FW.fw
> 1024x600
> a23-ippo-q8h-v1.2:a082 a23-tj-a23-q88-v4.0_20140815/GSL1688_A70_FW.fw 
>  800x480 swapped-x-y
> a33-ippo-q8h-v1.2:a082 a23-tj-a23-q88-v4.0_20140815/GSL1688_A70_FW.fw 
>  800x480 swapped-x-y
> a33-tzx-723q4:b482 a33-Q8_V2.4_1118/GSL1680_FW_D702.fw
>  960x480 inverted-x
> a33-q8-v2.4-1118: b482 a33-Q8_V2.4_1118/GSL1680_FW_D702.fw
>  960x480
> a33-q8h-v1.5: b482 a33-q8h-v1.5/GSL1688_A70_FW.fw 
>  960x480
> 
> 
> The first column is -, the second is the chip-id from the 
> gsl1680 (this can be read
> via i2c), the third column is the configdata file used for testing, the 
> directory-name it is prefixed
> with is from which board's android image the firmware file was extracted. The 
> 4th column shows
> the resolution of the reported coordinates and any necessary flags.
> 
> Note that the resolution and if we need swapped-x-y actually is fixed for a 
> given fw file, so
> we need to keep this information paired.
> 
> So as you can see which fw file to use, and whether x is inverted or not vary 
> from board to board.
> 
> This leaves us with 2 options:
> 
> 1) Move to 1 dts file per PCB variant solution, of ALL the q8 tablets I've 
> seen I've only ever
> had 2 with identical PCB-s and those were from the same batch, so this seems 
> unmaintainable.
> Which leaves us with:
> 

Yeah, you’re going to be fighting a losing battle.

> 2) Give the user some way to override the dts settings.
> 
> Which after a somewhat long intro brings me to the actual purpose of this 
> thread, discuss
> how to best deal with this. I again see 2 options:
> 
> 1) Put a disabled gsl1680 node in the dts file, have a q8_autodetect.c in 
> u-boot
> which probes i2c and if it finds the gsl1680 nodes enables it, and patches in 
> a best-effort
> default for which fw file to use. Allow the user to set a touchscreen_fw 
> u-boot env
> variable which will override this. Also allow the user to set a 
> touchscreen_inverted_x env
> variable to add inverted-x to the dt node for the gsl1680.
> 

That can work. The problem is that having anything requiring smarts in u-boot 
always
leads to trouble with users. It all depends on your user’s technical 
proficiency, if
they are comfortable tweaking things in u-boot it’s fine. If it’s not, expect 
lots of
bricked boards when they mess up.

> 2) Write an in kernel overlay manager which does auto-detect as described by 
> 1, and
> loads an overlay for the detected touchscreen controller, with module options 
> to allow
> specifying the fw-file, x-inversion, etc.
> 
> One things which worries me about 2. is that we would need to have 2 overlay 
> files
> per fw-file, one regular config, one inverted-x, or is it possible for the 
> overlay
> manager to modify an 

Re: [U-Boot] [PATCH v2 7/9] libfdt: Add overlay application function

[Pantelis Antoniou]

Hi David,

> On Jun 15, 2016, at 13:19 , David Gibson <da...@gibson.dropbear.id.au> wrote:
> 
> On Wed, Jun 15, 2016 at 12:34:00PM +0300, Pantelis Antoniou wrote:
>> Hi David,
>> 
>>> On Jun 15, 2016, at 06:14 , David Gibson <da...@gibson.dropbear.id.au> 
>>> wrote:
>>> 
>>> On Tue, Jun 14, 2016 at 12:22:23PM +0300, Pantelis Antoniou wrote:
>>>> Hi David,
>>>>> On Jun 14, 2016, at 03:25 , David Gibson <da...@gibson.dropbear.id.au> 
>>>>> wrote:
>>>>> On Fri, Jun 10, 2016 at 05:28:11PM +0300, Pantelis Antoniou wrote:
>>> [snip]
>>>>>>> +static int fdt_overlay_merge(void *dt, void *dto)
>>>>>>> +{
>>>>>>> +   int root, fragment;
>>>>>>> +
>>>>>>> +   root = fdt_path_offset(dto, "/");
>>>>>>> +   if (root < 0)
>>>>>>> +   return root;
>>>>>>> +
>>>>>>> +   fdt_for_each_subnode(dto, fragment, root) {
>>>>>>> +   const char *name = fdt_get_name(dto, fragment, NULL);
>>>>>>> +   uint32_t target;
>>>>>>> +   int overlay;
>>>>>>> +   int ret;
>>>>>>> +
>>>>>>> +   if (strncmp(name, "fragment", 8))
>>>>>>> +   continue;
>>>>>>> +
>>>>>> 
>>>>>> This is incorrect. The use of “fragment” is a convention only.
>>>>>> The real test whether the node is an overlay fragment is that
>>>>>> it contains a target property.
>>>>> 
>>>>> Hmm.. I dislike that approach.  First, it means that if new target
>>>>> types are introduced in future, older code is likely to silently
>>>>> ignore such fragments instead of realizing that it doesn't know how to
>>>>> apply themm.  Second, it raises weird issues if some node down within
>>>>> a fragment also happens to have a property called "target”.
>>>> 
>>>> Not really. If new targets are introduced then the fragment will be 
>>>> ignored.
>>> 
>>> Yes.. and that's bad.
>> 
>> That’s arguable.
> 
> !?!  No, really, silent partial application is just horrible.
> 
>>>> We can have an argument about what is better to do (report an error or 
>>>> ignore a fragment) but what it comes down to is that that applicator
>>>> does not know how to handle the new target method.
>>> 
>>> Sure, let's have the argument.  The overlay is constructed on the
>>> assumption that all the pieces will be applied, or none of them.  A
>>> silent, partial application is an awful, awful failure mode.  We
>>> absolutely should report an error, and in order to do so we need to
>>> know what are applicable fragments, whether or not we understand the
>>> target designation (or any other meta-data the fragment has).
>> 
>> This way also allows having nodes being something other than fragments.
>> 
>> So instead of being painted into a corner (all subnodes that are not
>> named ‘fragment@X’ are errors), we have flexibility in introducing
>> nodes that contain configuration data for the loader.
> 
> There's no significant difference between the approaches from this
> point of view.  Metadata nodes are certainly possible (we already have
> __symbols__ and __fixups__) but calling them something other than
> fragment@ is no harder than leaving off the target property.  In fact
> even if it was workable, calling new metadata nodes fragment@ would be
> stupidly confusing.
> 

Err, we won’t ever call metadata nodes fragment@, that would be awfully 
confusing.

We’re bikeshedding, it’s just a philosophical argument right now.

The correct way is to get cracking on the machine readable yaml based bindings
and enforce it through there.

>>> Given what's established so far, checking the name seems the obvious
>>> way to do that.
>>> 
>> 
>> Again, it’s arguable. Stricter checking against future-proofing.
>> 
>>>> There is no issues with any target properties inside a fragment because
>>>> the check is not made recursively.
>>> 
>>> Ok, so the real test you're proposing is "at the top level AND has a
>>> target property”.
>> 
>> Yes
> 
> -- 
> David Gibson  | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au| minimalist, thank you.  NOT _the_ 
> _other_
>   | _way_ _around_!
> http://www.ozlabs.org/~dgibson

Regards

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 7/9] libfdt: Add overlay application function

[Pantelis Antoniou]

Hi David,

> On Jun 15, 2016, at 06:14 , David Gibson <da...@gibson.dropbear.id.au> wrote:
> 
> On Tue, Jun 14, 2016 at 12:22:23PM +0300, Pantelis Antoniou wrote:
>> Hi David,
>>> On Jun 14, 2016, at 03:25 , David Gibson <da...@gibson.dropbear.id.au> 
>>> wrote:
>>> On Fri, Jun 10, 2016 at 05:28:11PM +0300, Pantelis Antoniou wrote:
> [snip]
>>>>> +static int fdt_overlay_merge(void *dt, void *dto)
>>>>> +{
>>>>> + int root, fragment;
>>>>> +
>>>>> + root = fdt_path_offset(dto, "/");
>>>>> + if (root < 0)
>>>>> + return root;
>>>>> +
>>>>> + fdt_for_each_subnode(dto, fragment, root) {
>>>>> + const char *name = fdt_get_name(dto, fragment, NULL);
>>>>> + uint32_t target;
>>>>> + int overlay;
>>>>> + int ret;
>>>>> +
>>>>> + if (strncmp(name, "fragment", 8))
>>>>> + continue;
>>>>> +
>>>> 
>>>> This is incorrect. The use of “fragment” is a convention only.
>>>> The real test whether the node is an overlay fragment is that
>>>> it contains a target property.
>>> 
>>> Hmm.. I dislike that approach.  First, it means that if new target
>>> types are introduced in future, older code is likely to silently
>>> ignore such fragments instead of realizing that it doesn't know how to
>>> apply themm.  Second, it raises weird issues if some node down within
>>> a fragment also happens to have a property called "target”.
>> 
>> Not really. If new targets are introduced then the fragment will be ignored.
> 
> Yes.. and that's bad.
> 

That’s arguable.

>> We can have an argument about what is better to do (report an error or 
>> ignore a fragment) but what it comes down to is that that applicator
>> does not know how to handle the new target method.
> 
> Sure, let's have the argument.  The overlay is constructed on the
> assumption that all the pieces will be applied, or none of them.  A
> silent, partial application is an awful, awful failure mode.  We
> absolutely should report an error, and in order to do so we need to
> know what are applicable fragments, whether or not we understand the
> target designation (or any other meta-data the fragment has).
> 

This way also allows having nodes being something other than fragments.

So instead of being painted into a corner (all subnodes that are not
named ‘fragment@X’ are errors), we have flexibility in introducing
nodes that contain configuration data for the loader.
 
> Given what's established so far, checking the name seems the obvious
> way to do that.
> 

Again, it’s arguable. Stricter checking against future-proofing.

>> There is no issues with any target properties inside a fragment because
>> the check is not made recursively.
> 
> Ok, so the real test you're proposing is "at the top level AND has a
> target property”.

Yes

> 

> -- 
> David Gibson  | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au| minimalist, thank you.  NOT _the_ 
> _other_
>   | _way_ _around_!
> http://www.ozlabs.org/~dgibson

Regards

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 7/9] libfdt: Add overlay application function

[Pantelis Antoniou]

Hi David,

> On Jun 14, 2016, at 03:25 , David Gibson <da...@gibson.dropbear.id.au> wrote:
> 
> On Fri, Jun 10, 2016 at 05:28:11PM +0300, Pantelis Antoniou wrote:
>> Hi Maxime,
>> 
>>> On May 27, 2016, at 12:13 , Maxime Ripard 
>>> <maxime.rip...@free-electrons.com> wrote:
>>> 
>>> The device tree overlays are a good way to deal with user-modifyable
>>> boards or boards with some kind of an expansion mechanism where we can
>>> easily plug new board in (like the BBB, the Raspberry Pi or the CHIP).
>>> 
>>> Add a new function to merge overlays with a base device tree.
>>> 
>>> Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>
>>> ---
>>> include/libfdt.h |  30 
>>> lib/libfdt/Makefile  |   2 +-
>>> lib/libfdt/fdt_overlay.c | 414 
>>> +++
>>> 3 files changed, 445 insertions(+), 1 deletion(-)
>>> create mode 100644 lib/libfdt/fdt_overlay.c
>>> 
>>> diff --git a/include/libfdt.h b/include/libfdt.h
>>> index 1e01b2c7ebdf..783067e841a1 100644
>>> --- a/include/libfdt.h
>>> +++ b/include/libfdt.h
>>> @@ -1698,6 +1698,36 @@ int fdt_add_subnode(void *fdt, int parentoffset, 
>>> const char *name);
>>> */
>>> int fdt_del_node(void *fdt, int nodeoffset);
>>> 
>>> +/**
>>> + * fdt_overlay_apply - Applies a DT overlay on a base DT
>>> + * @fdt: pointer to the base device tree blob
>>> + * @fdto: pointer to the device tree overlay blob
>>> + *
>>> + * fdt_overlay_apply() will apply the given device tree overlay on the
>>> + * given base device tree.
>>> + *
>>> + * Expect the base device tree to be modified, even if the function
>>> + * returns an error.
>>> + *
>> 
>> If the base tree has been modified on an error it is unsafe to use it
>> for booting. A valid strategy would be to scribble over the DT magic
>> number so that that blob is invalidated.
>> 
>> What are the other people’s opinion on this?
>> 
>>> + * returns:
>>> + * 0, on success
>>> + * -FDT_ERR_NOSPACE, there's not enough space in the base device tree
>>> + * -FDT_ERR_NOTFOUND, the overlay points to some inexistant nodes or
>>> + * properties in the base DT
>>> + * -FDT_ERR_BADPHANDLE, the phandles in the overlay do not have the right
>>> + * magic
>>> + * -FDT_ERR_INTERNAL,
>>> + * -FDT_ERR_BADLAYOUT,
>>> + * -FDT_ERR_BADMAGIC,
>>> + * -FDT_ERR_BADOFFSET,
>>> + * -FDT_ERR_BADPATH,
>>> + * -FDT_ERR_BADVERSION,
>>> + * -FDT_ERR_BADSTRUCTURE,
>>> + * -FDT_ERR_BADSTATE,
>>> + * -FDT_ERR_TRUNCATED, standard meanings
>>> + */
>>> +int fdt_overlay_apply(void *fdt, void *fdto);
>>> +
>>> /**/
>>> /* Debugging / informational functions*/
>>> /**/
>>> diff --git a/lib/libfdt/Makefile b/lib/libfdt/Makefile
>>> index 934d6142c3e9..4935bf012a75 100644
>>> --- a/lib/libfdt/Makefile
>>> +++ b/lib/libfdt/Makefile
>>> @@ -6,4 +6,4 @@
>>> #
>>> 
>>> obj-y += fdt.o fdt_ro.o fdt_rw.o fdt_strerror.o fdt_sw.o fdt_wip.o \
>>> -   fdt_empty_tree.o fdt_addresses.o fdt_region.o
>>> +   fdt_empty_tree.o fdt_addresses.o fdt_region.o fdt_overlay.o
>>> diff --git a/lib/libfdt/fdt_overlay.c b/lib/libfdt/fdt_overlay.c
>>> new file mode 100644
>>> index ..1e68e903c734
>>> --- /dev/null
>>> +++ b/lib/libfdt/fdt_overlay.c
>>> @@ -0,0 +1,414 @@
>>> +#include "libfdt_env.h"
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +#include "libfdt_internal.h"
>>> +
>>> +static uint32_t fdt_overlay_get_target_phandle(const void *fdto, int node)
>>> +{
>>> +   const uint32_t *val;
>>> +   int len;
>>> +
>>> +   val = fdt_getprop(fdto, node, "target", );
>>> +   if (!val || (len != sizeof(*val)))
>>> +   return 0;
>>> +
>>> +   return fdt32_to_cpu(*val);
>>> +}
>>> +
>>> +static int fdt_overlay_get_target(const void *fdt, const void *fdto,
>>> + int fragment)
>>> +{
>>> +   uint32_t phandle;
>>> +  

Re: [U-Boot] [PATCH v2 9/9] tests: Introduce DT overlay tests

[Pantelis Antoniou]

e));
> + ut_assertok(fdt_check_header(fdt_overlay));
> +
> + uts = calloc(1, sizeof(*uts));
> + if (!uts)
> + return -ENOMEM;
> +
> + fdt_base_copy = malloc(FDT_COPY_SIZE);
> + if (!fdt_base_copy)
> + return -ENOMEM;
> + uts->priv = fdt_base_copy;
> +
> + /*
> +  * Resize the FDT to 4k so that we have room to operate on
> +  *
> +  * (and relocate it since the memory might be mapped
> +  * read-only)
> +  */
> + ut_assertok(fdt_open_into(fdt_base, fdt_base_copy, FDT_COPY_SIZE));
> +
> + /* Apply the overlay */
> + ut_assertok(fdt_overlay_apply(fdt_base_copy, fdt_overlay));
> +
> + if (argc == 1)
> + printf("Running %d environment tests\n", n_ents);
> +
> + for (test = tests; test < tests + n_ents; test++) {
> + if (argc > 1 && strcmp(argv[1], test->name))
> + continue;
> + printf("Test: %s\n", test->name);
> +
> + uts->start = mallinfo();
> +
> + test->func(uts);
> + }
> +
> + printf("Failures: %d\n", uts->fail_count);
> +
> + free(fdt_base_copy);
> + free(uts);
> +
> + return uts->fail_count ? CMD_RET_FAILURE : 0;
> +}
> diff --git a/test/overlay/test-fdt-base.dts b/test/overlay/test-fdt-base.dts
> new file mode 100644
> index ..e8fa9bb5be82
> --- /dev/null
> +++ b/test/overlay/test-fdt-base.dts
> @@ -0,0 +1,17 @@
> +/*
> + * Copyright (c) 2016 NextThing Co
> + * Copyright (c) 2016 Free Electrons
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +/dts-v1/;
> +
> +/ {
> + test: test-node {
> + test-int-property = <42>;
> + test-str-property = "foo";
> + };
> +};
> +
> +
> diff --git a/test/overlay/test-fdt-overlay.dts 
> b/test/overlay/test-fdt-overlay.dts
> new file mode 100644
> index ..ca3abcff287c
> --- /dev/null
> +++ b/test/overlay/test-fdt-overlay.dts
> @@ -0,0 +1,60 @@
> +/*
> + * Copyright (c) 2016 NextThing Co
> + * Copyright (c) 2016 Free Electrons
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +/ {
> + /* Test that we can change an int by another */
> + fragment@0 {
> + target = <>;
> +
> + __overlay__ {
> + test-int-property = <43>;
> + };
> + };
> +
> + /* Test that we can replace a string by a longer one */
> + fragment@1 {
> + target = <>;
> +
> + __overlay__ {
> + test-str-property = "foobar";
> + };
> + };
> +
> + /* Test that we add a new property */
> + fragment@2 {
> + target = <>;
> +
> + __overlay__ {
> + test-str-property-2 = "foobar2";
> + };
> + };
> +
> + /* Test that we add a new node (by phandle) */
> + fragment@3 {
> + target = <>;
> +
> + __overlay__ {
> + new-node {
> + new-property;
> + };
> + };
> + };
> +
> + /* Test that we add a new node (by path) */
> + fragment@4 {
> + target-path = "/";
> +
> + __overlay__ {
> + new-node {
> + new-property;
> + };
> + };
> + };
> +};
> -- 
> 2.8.2
> 

Acked-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 6/9] libfdt: Add max phandle retrieval function

[Pantelis Antoniou]

> On May 27, 2016, at 12:13 , Maxime Ripard  
> wrote:
> 
> Add a function to retrieve the highest phandle in a given device tree.
> 
> Signed-off-by: Maxime Ripard 
> ---
> include/libfdt.h| 13 +
> lib/libfdt/fdt_ro.c | 15 +++
> 2 files changed, 28 insertions(+)
> 
> diff --git a/include/libfdt.h b/include/libfdt.h
> index 4e8eb9ede3a4..1e01b2c7ebdf 100644
> --- a/include/libfdt.h
> +++ b/include/libfdt.h
> @@ -284,6 +284,19 @@ int fdt_move(const void *fdt, void *buf, int bufsize);
> const char *fdt_string(const void *fdt, int stroffset);
> 
> /**
> + * fdt_get_max_phandle - retrieves the highest phandle in a tree
> + * @fdt: pointer to the device tree blob
> + *
> + * fdt_get_max_phandle retrieves the highest phandlle in the given
> + * device tree
> + *

^ typo; phandlle -> phandle
> + * returns:
> + *  the highest phandle on success
> + *  0, if an error occured
> + */
> +uint32_t fdt_get_max_phandle(const void *fdt);
> +
> +/**
>  * fdt_num_mem_rsv - retrieve the number of memory reserve map entries
>  * @fdt: pointer to the device tree blob
>  *
> diff --git a/lib/libfdt/fdt_ro.c b/lib/libfdt/fdt_ro.c
> index 7b0777b67eb3..9130ce718965 100644
> --- a/lib/libfdt/fdt_ro.c
> +++ b/lib/libfdt/fdt_ro.c
> @@ -47,6 +47,21 @@ static int _fdt_string_eq(const void *fdt, int stroffset,
>   return (strnlen(p, len + 1) == len) && (memcmp(p, s, len) == 0);
> }
> 
> +uint32_t fdt_get_max_phandle(const void *fdt)
> +{
> + uint32_t max_phandle = 0, phandle;
> + int offset;
> +
> + for (offset = fdt_next_node(fdt, -1, NULL); offset >= 0;
> +  offset = fdt_next_node(fdt, offset, NULL)) {
> + phandle = fdt_get_phandle(fdt, offset);
> + if (phandle > max_phandle)
> + max_phandle = phandle;
> + }
> +
> + return max_phandle;
> +}
> +
> int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size)
> {
>   FDT_CHECK_HEADER(fdt);
> -- 
> 2.8.2
> 

Regards

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 7/9] libfdt: Add overlay application function

[Pantelis Antoniou]

Hi Maxime,

> On May 27, 2016, at 12:13 , Maxime Ripard  
> wrote:
> 
> The device tree overlays are a good way to deal with user-modifyable
> boards or boards with some kind of an expansion mechanism where we can
> easily plug new board in (like the BBB, the Raspberry Pi or the CHIP).
> 
> Add a new function to merge overlays with a base device tree.
> 
> Signed-off-by: Maxime Ripard 
> ---
> include/libfdt.h |  30 
> lib/libfdt/Makefile  |   2 +-
> lib/libfdt/fdt_overlay.c | 414 +++
> 3 files changed, 445 insertions(+), 1 deletion(-)
> create mode 100644 lib/libfdt/fdt_overlay.c
> 
> diff --git a/include/libfdt.h b/include/libfdt.h
> index 1e01b2c7ebdf..783067e841a1 100644
> --- a/include/libfdt.h
> +++ b/include/libfdt.h
> @@ -1698,6 +1698,36 @@ int fdt_add_subnode(void *fdt, int parentoffset, const 
> char *name);
>  */
> int fdt_del_node(void *fdt, int nodeoffset);
> 
> +/**
> + * fdt_overlay_apply - Applies a DT overlay on a base DT
> + * @fdt: pointer to the base device tree blob
> + * @fdto: pointer to the device tree overlay blob
> + *
> + * fdt_overlay_apply() will apply the given device tree overlay on the
> + * given base device tree.
> + *
> + * Expect the base device tree to be modified, even if the function
> + * returns an error.
> + *

If the base tree has been modified on an error it is unsafe to use it
for booting. A valid strategy would be to scribble over the DT magic
number so that that blob is invalidated.

What are the other people’s opinion on this?

> + * returns:
> + *   0, on success
> + *   -FDT_ERR_NOSPACE, there's not enough space in the base device tree
> + *   -FDT_ERR_NOTFOUND, the overlay points to some inexistant nodes or
> + *   properties in the base DT
> + *   -FDT_ERR_BADPHANDLE, the phandles in the overlay do not have the right
> + *   magic
> + *   -FDT_ERR_INTERNAL,
> + *   -FDT_ERR_BADLAYOUT,
> + *   -FDT_ERR_BADMAGIC,
> + *   -FDT_ERR_BADOFFSET,
> + *   -FDT_ERR_BADPATH,
> + *   -FDT_ERR_BADVERSION,
> + *   -FDT_ERR_BADSTRUCTURE,
> + *   -FDT_ERR_BADSTATE,
> + *   -FDT_ERR_TRUNCATED, standard meanings
> + */
> +int fdt_overlay_apply(void *fdt, void *fdto);
> +
> /**/
> /* Debugging / informational functions*/
> /**/
> diff --git a/lib/libfdt/Makefile b/lib/libfdt/Makefile
> index 934d6142c3e9..4935bf012a75 100644
> --- a/lib/libfdt/Makefile
> +++ b/lib/libfdt/Makefile
> @@ -6,4 +6,4 @@
> #
> 
> obj-y += fdt.o fdt_ro.o fdt_rw.o fdt_strerror.o fdt_sw.o fdt_wip.o \
> - fdt_empty_tree.o fdt_addresses.o fdt_region.o
> + fdt_empty_tree.o fdt_addresses.o fdt_region.o fdt_overlay.o
> diff --git a/lib/libfdt/fdt_overlay.c b/lib/libfdt/fdt_overlay.c
> new file mode 100644
> index ..1e68e903c734
> --- /dev/null
> +++ b/lib/libfdt/fdt_overlay.c
> @@ -0,0 +1,414 @@
> +#include "libfdt_env.h"
> +
> +#include 
> +#include 
> +
> +#include "libfdt_internal.h"
> +
> +static uint32_t fdt_overlay_get_target_phandle(const void *fdto, int node)
> +{
> + const uint32_t *val;
> + int len;
> +
> + val = fdt_getprop(fdto, node, "target", );
> + if (!val || (len != sizeof(*val)))
> + return 0;
> +
> + return fdt32_to_cpu(*val);
> +}
> +
> +static int fdt_overlay_get_target(const void *fdt, const void *fdto,
> +   int fragment)
> +{
> + uint32_t phandle;
> + const char *path;
> +
> + /* Try first to do a phandle based lookup */
> + phandle = fdt_overlay_get_target_phandle(fdto, fragment);
> + if (phandle)
> + return fdt_node_offset_by_phandle(fdt, phandle);
> +
> + /* And then a path based lookup */
> + path = fdt_getprop(fdto, fragment, "target-path", NULL);
> + if (!path)
> + return -FDT_ERR_NOTFOUND;
> +
> + return fdt_path_offset(fdt, path);
> +}
> +

Those targets are fine; beware there are patches with more target options.

> +static int fdt_overlay_adjust_node_phandles(void *fdto, int node,
> + uint32_t delta)
> +{
> + int property;
> + int child;
> +
> + fdt_for_each_property(fdto, node, property) {
> + const uint32_t *val;
> + const char *name;
> + uint32_t adj_val;
> + int len;
> + int ret;
> +
> + val = fdt_getprop_by_offset(fdto, property,
> + , );
> + if (!val || (len != sizeof(*val)))

Superfluous parentheses.

> + continue;
> +
> + if (strcmp(name, "phandle") && strcmp(name, "linux,phandle"))
> + continue;
> +
> + adj_val = fdt32_to_cpu(*val);
> + adj_val += delta;
> + 

Re: [U-Boot] [PATCH v2 5/9] libfdt: Add iterator over properties

[Pantelis Antoniou]

> On May 27, 2016, at 12:13 , Maxime Ripard <maxime.rip...@free-electrons.com> 
> wrote:
> 
> Implement a macro based on fdt_first_property_offset and
> fdt_next_property_offset that provides a convenience to iterate over all
> the properties of a given node.
> 
> Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>
> ---
> include/libfdt.h | 24 
> 1 file changed, 24 insertions(+)
> 
> diff --git a/include/libfdt.h b/include/libfdt.h
> index 74b1d149c2dd..4e8eb9ede3a4 100644
> --- a/include/libfdt.h
> +++ b/include/libfdt.h
> @@ -441,6 +441,30 @@ int fdt_first_property_offset(const void *fdt, int 
> nodeoffset);
> int fdt_next_property_offset(const void *fdt, int offset);
> 
> /**
> + * fdt_for_each_property - iterate over all properties of a node
> + * @fdt: FDT blob (const void *)
> + * @node:node offset (int)
> + * @property:property offset (int)
> + *
> + * This is actually a wrapper around a for loop and would be used like so:
> + *
> + *   fdt_for_each_property(fdt, node, property) {
> + *   ...
> + *   use property
> + *   ...
> + *   }
> + *
> + * Note that this is implemented as a macro and property is used as
> + * iterator in the loop. It should therefore be a locally allocated
> + * variable. The node variable on the other hand is never modified, so
> + * it can be constant or even a literal.
> + */
> +#define fdt_for_each_property(fdt, node, property)   \
> + for (property = fdt_first_property_offset(fdt, node);   \
> +  property >= 0; \
> +  property = fdt_next_property_offset(fdt, property))
> +
> +/**
>  * fdt_get_property_by_offset - retrieve the property at a given offset
>  * @fdt: pointer to the device tree blob
>  * @offset: offset of the property to retrieve
> -- 
> 2.8.2
> 

Acked-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>

I’d like to see this merged in dtc upstream please too.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/9] libfdt: Add new headers and defines

[Pantelis Antoniou]

Hi Maxime,

> On May 27, 2016, at 12:13 , Maxime Ripard <maxime.rip...@free-electrons.com> 
> wrote:
> 
> The libfdt overlay support introduces a bunch of new includes and
> functions.
> 
> Make sure we are able to build it by adding the needed glue.
> 
> Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>
> ---
> include/libfdt_env.h | 7 +++
> 1 file changed, 7 insertions(+)
> 
> diff --git a/include/libfdt_env.h b/include/libfdt_env.h
> index 273b5d30f867..2d2196031332 100644
> --- a/include/libfdt_env.h
> +++ b/include/libfdt_env.h
> @@ -23,6 +23,13 @@ typedef __be64 fdt64_t;
> #define fdt64_to_cpu(x)   be64_to_cpu(x)
> #define cpu_to_fdt64(x)   cpu_to_be64(x)
> 
> +#ifdef __UBOOT__
> +#include "malloc.h"
> +#include "vsprintf.h"
> +
> +#define strtol(cp, endp, base)   simple_strtol(cp, endp, base)
> +#endif
> +
> /* adding a ramdisk needs 0x44 bytes in version 2008.10 */
> #define FDT_RAMDISK_OVERHEAD  0x80
> 

We need to figure out what the upstream libfdt/dtc maintainer’s take is on this 
is.
For u-boot we’re fine and for now it’s OK.

Acked-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>

> -- 
> 2.8.2
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/9] vsprintf: Include stdarg for va_list

[Pantelis Antoniou]

> On May 27, 2016, at 12:13 , Maxime Ripard <maxime.rip...@free-electrons.com> 
> wrote:
> 
> vsprintf.h doesn't include the stdarg.h file, which means that it relies on
> the files that include vsprintf.h to include stdarg.h as well.
> 
> Add an explicit include to avoid build errors when simply including that
> file.
> 
> Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>
> ---
> include/vsprintf.h | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/include/vsprintf.h b/include/vsprintf.h
> index 376f5dd32499..60e91d119eee 100644
> --- a/include/vsprintf.h
> +++ b/include/vsprintf.h
> @@ -8,6 +8,8 @@
> #ifndef __VSPRINTF_H
> #define __VSPRINTF_H
> 
> +#include 
> +
> ulong simple_strtoul(const char *cp, char **endp, unsigned int base);
> 
> /**
> -- 
> 2.8.2
> 

Acked-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/9] scripts: Makefile.lib: Sanitize DTB names

[Pantelis Antoniou]

> On May 27, 2016, at 12:13 , Maxime Ripard <maxime.rip...@free-electrons.com> 
> wrote:
> 
> Having dashes as a separator in the DTB name is a quite common practice.
> 
> However, the current code to generate objects from DTBs assumes the
> separator is an underscore, leading to a compilation error when building a
> device tree with dashes.
> 
> Replace all the dashes in the DTB name to generate the symbols name, which
> should solve this issue.
> 
> Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>
> ---
> scripts/Makefile.lib | 8 
> 1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index ad1d9b5d7dd2..df1b5a7b4150 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -275,11 +275,11 @@ cmd_dt_S_dtb=   
> \
> ( \
>   echo '.section .dtb.init.rodata,"a"';   \
>   echo '.balign 16';  \
> - echo '.global __dtb_$(*F)_begin';   \
> - echo '__dtb_$(*F)_begin:';  \
> + echo '.global __dtb_$(subst -,_,$(*F))_begin';  \
> + echo '__dtb_$(subst -,_,$(*F))_begin:'; \
>   echo '.incbin "$<" ';   \
> - echo '__dtb_$(*F)_end:';\
> - echo '.global __dtb_$(*F)_end'; \
> + echo '__dtb_$(subst -,_,$(*F))_end:';   \
> + echo '.global __dtb_$(subst -,_,$(*F))_end';\
>   echo '.balign 16';  \
> ) > $@
> 
> -- 
> 2.8.2
> 

Acked-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 8/9] cmd: fdt: add fdt overlay application subcommand

[Pantelis Antoniou]

> On May 27, 2016, at 12:13 , Maxime Ripard <maxime.rip...@free-electrons.com> 
> wrote:
> 
> The device tree overlays are a good way to deal with user-modifyable
> boards or boards with some kind of an expansion mechanism where we can
> easily plug new board in (like the BBB or the raspberry pi).
> 
> However, so far, the usual mechanism to deal with it was to have in Linux
> some driver detecting the expansion boards plugged in and then request
> these overlays using the firmware interface.
> 
> That works in most cases, but in some cases, you might want to have the
> overlays applied before the userspace comes in. Either because the new
> board requires some kind of an early initialization, or because your root
> filesystem is accessed through that expansion board.
> 
> The easiest solution in such a case is to simply have the component before
> Linux applying that overlay, removing all these drawbacks.
> 
> Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>
> ---
> cmd/fdt.c | 20 
> 1 file changed, 20 insertions(+)
> 
> diff --git a/cmd/fdt.c b/cmd/fdt.c
> index 0f5923e75a41..6cbc9e525d6c 100644
> --- a/cmd/fdt.c
> +++ b/cmd/fdt.c
> @@ -639,6 +639,25 @@ static int do_fdt(cmd_tbl_t *cmdtp, int flag, int argc, 
> char * const argv[])
> #endif
> 
>   }
> + /* apply an overlay */
> + else if (strncmp(argv[1], "ap", 2) == 0) {
> + unsigned long addr;
> + struct fdt_header *blob;
> +
> + if (argc != 3)
> + return CMD_RET_USAGE;
> +
> + if (!working_fdt)
> + return CMD_RET_FAILURE;
> +
> + addr = simple_strtoul(argv[2], NULL, 16);
> + blob = map_sysmem(addr, 0);
> + if (!fdt_valid())
> + return CMD_RET_FAILURE;
> +
> + if (fdt_overlay_apply(working_fdt, blob))
> + return CMD_RET_FAILURE;
> + }
>   /* resize the fdt */
>   else if (strncmp(argv[1], "re", 2) == 0) {
>   fdt_shrink_to_minimum(working_fdt);
> @@ -1025,6 +1044,7 @@ static int fdt_print(const char *pathp, char *prop, int 
> depth)
> #ifdef CONFIG_SYS_LONGHELP
> static char fdt_help_text[] =
>   "addr [-c]   []   - Set the [control] fdt location to 
> \n"
> + "fdt apply - Apply overlay to the DT\n"
> #ifdef CONFIG_OF_BOARD_SETUP
>   "fdt boardsetup  - Do board-specific set up\n"
> #endif
> -- 
> 2.8.2
> 

Acked-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/9] cmd: fdt: Narrow the check for fdt addr

[Pantelis Antoniou]

> On Jun 10, 2016, at 03:34 , Simon Glass <s...@chromium.org> wrote:
> 
> On 27 May 2016 at 03:13, Maxime Ripard <maxime.rip...@free-electrons.com> 
> wrote:
>> The current code only checks if the fdt subcommand is fdt addr by checking
>> whether it starts with 'a'.
>> 
>> Since this is a pretty widely used letter, narrow down that check a bit.
>> 
>> Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>
>> ---
>> cmd/fdt.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Acked-by: Simon Glass <s...@chromium.org>

Acked-by: Pantelis Antoniou <pantelis.anton...@konsulko.com>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH RESEND 2/2] cmd: fdt: add fdt overlay application subcommand

[Pantelis Antoniou]

Hi Maxime,

> On May 10, 2016, at 14:45 , Maxime Ripard  
> wrote:
> 

[snip]

> How do you want me to proceed?
> 
> Thanks!
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

FYI an updated dtc patch has been sent. Hopefully this time will get in.

Regards

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH RESEND 2/2] cmd: fdt: add fdt overlay application subcommand

[Pantelis Antoniou]

Hi Tom,

> On Apr 13, 2016, at 22:42 , Tom Rini <tr...@konsulko.com> wrote:
> 
> On Fri, Apr 08, 2016 at 04:29:40PM -0500, Rob Herring wrote:
>> On Tue, Apr 5, 2016 at 5:03 PM, Pantelis Antoniou
>> <pantelis.anton...@konsulko.com> wrote:
>>> Hi Maxime,
>>> 
>>>> On Apr 4, 2016, at 11:25 , Maxime Ripard 
>>>> <maxime.rip...@free-electrons.com> wrote:
>>>> 
>>>> The device tree overlays are a good way to deal with user-modifyable
>>>> boards or boards with some kind of an expansion mechanism where we can
>>>> easily plug new board in (like the BBB or the raspberry pi).
>>>> 
>>>> However, so far, the usual mechanism to deal with it was to have in Linux
>>>> some driver detecting the expansion boards plugged in and then request
>>>> these overlays using the firmware interface.
>>>> 
>>>> That works in most cases, but in some cases, you might want to have the
>>>> overlays applied before the userspace comes in. Either because the new
>>>> board requires some kind of an early initialization, or because your root
>>>> filesystem is accessed through that expansion board.
>>>> 
>>>> The easiest solution in such a case is to simply have the component before
>>>> Linux applying that overlay, removing all these drawbacks.
>>>> 
>> 
>> [...]
>> 
>>>> diff --git a/cmd/fdt_overlay.c b/cmd/fdt_overlay.c
>>> 
>>> This looks it’s general libfdt code.
>>> It should end up in libfdt/ so that others can use it, and eventually
>>> be pushed upstream.
>> 
>> +1. It really needs to go into libfdt first to avoid any re-licensing issues.
>> 
>> Another option which Grant has suggested would be to extend the FDT
>> format to include overlays as a whole. Then the kernel can apply them
>> during unflattening. This would simplify things on the bootloader
>> side.
> 
> Perhaps in some cases?  Part of the overall use case here is that
> something has to dynamically grab the N overlays that apply on the
> current hardware and make them available.  So the bootloader would still
> need to grab them and pass along to the kernel to apply.  And I've
> already received some pushback on saying it could wait until
> initrd/initramfs.
> 

There are a number of options about what to do.

This patch is made for a specific case of DRM drivers not handling overlays.
I expect this is because the DRM device core does not have a reconfig notifier.
I plan adding it when I get my CHIP setup.

Grant’s option is to have the kernel do the overlay application by appending
the overlay dtbos after the base tree blob. 

This patch is orthogonal to both, so let’s review and make up our minds on the
updated patch.

> -- 
> Tom

Regards

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH RESEND 2/2] cmd: fdt: add fdt overlay application subcommand

[Pantelis Antoniou]

Hi Maxime,

> On Apr 4, 2016, at 11:25 , Maxime Ripard  
> wrote:
> 
> The device tree overlays are a good way to deal with user-modifyable
> boards or boards with some kind of an expansion mechanism where we can
> easily plug new board in (like the BBB or the raspberry pi).
> 
> However, so far, the usual mechanism to deal with it was to have in Linux
> some driver detecting the expansion boards plugged in and then request
> these overlays using the firmware interface.
> 
> That works in most cases, but in some cases, you might want to have the
> overlays applied before the userspace comes in. Either because the new
> board requires some kind of an early initialization, or because your root
> filesystem is accessed through that expansion board.
> 
> The easiest solution in such a case is to simply have the component before
> Linux applying that overlay, removing all these drawbacks.
> 

This is an interesting patch. My comments inline.

> Signed-off-by: Maxime Ripard 
> ---
> cmd/Makefile  |   2 +-
> cmd/fdt.c |  19 +++
> cmd/fdt_overlay.c | 464 ++
> include/fdt_support.h |   2 +-
> 4 files changed, 485 insertions(+), 2 deletions(-)
> create mode 100644 cmd/fdt_overlay.c
> 
> diff --git a/cmd/Makefile b/cmd/Makefile
> index 03f7e0a21d2f..09f993971d93 100644
> --- a/cmd/Makefile
> +++ b/cmd/Makefile
> @@ -52,7 +52,7 @@ obj-$(CONFIG_CMD_EXT4) += ext4.o
> obj-$(CONFIG_CMD_EXT2) += ext2.o
> obj-$(CONFIG_CMD_FAT) += fat.o
> obj-$(CONFIG_CMD_FDC) += fdc.o
> -obj-$(CONFIG_OF_LIBFDT) += fdt.o
> +obj-$(CONFIG_OF_LIBFDT) += fdt.o fdt_overlay.o
> obj-$(CONFIG_CMD_FITUPD) += fitupd.o
> obj-$(CONFIG_CMD_FLASH) += flash.o
> ifdef CONFIG_FPGA
> diff --git a/cmd/fdt.c b/cmd/fdt.c
> index ca6c707dfb48..c875ba688d3b 100644
> --- a/cmd/fdt.c
> +++ b/cmd/fdt.c
> @@ -639,6 +639,24 @@ static int do_fdt(cmd_tbl_t *cmdtp, int flag, int argc, 
> char * const argv[])
> #endif
> 
>   }
> + /* apply an overlay */
> + else if (strncmp(argv[1], "ap", 2) == 0) {
> + unsigned long addr;
> + struct fdt_header *blob;
> +
> + if (argc != 3)
> + return CMD_RET_USAGE;
> +
> + if (!working_fdt)
> + return CMD_RET_FAILURE;
> +
> + addr = simple_strtoul(argv[2], NULL, 16);
> + blob = map_sysmem(addr, 0);
> + if (!fdt_valid())
> + return CMD_RET_FAILURE;
> +
> + fdt_overlay_apply(working_fdt, blob);
> + }
>   /* resize the fdt */
>   else if (strncmp(argv[1], "re", 2) == 0) {
>   fdt_shrink_to_minimum(working_fdt);
> @@ -1025,6 +1043,7 @@ static int fdt_print(const char *pathp, char *prop, int 
> depth)
> #ifdef CONFIG_SYS_LONGHELP
> static char fdt_help_text[] =
>   "addr [-c]   []   - Set the [control] fdt location to 
> \n"
> + "fdt apply - Apply overlay to the DT\n"
> #ifdef CONFIG_OF_BOARD_SETUP
>   "fdt boardsetup  - Do board-specific set up\n"
> #endif
> diff --git a/cmd/fdt_overlay.c b/cmd/fdt_overlay.c

This looks it’s general libfdt code.
It should end up in libfdt/ so that others can use it, and eventually
be pushed upstream.

> new file mode 100644
> index ..d2784d791a09
> --- /dev/null
> +++ b/cmd/fdt_overlay.c
> @@ -0,0 +1,464 @@
> +#include 
> +#include 
> +#include 
> +
> +#define fdt_for_each_property(fdt, node, property)   \
> + for (property = fdt_first_property_offset(fdt, node);   \
> +  property >= 0; \
> +  property = fdt_next_property_offset(fdt, property))
> +
> +struct fdt_overlay_fixup {
> + charlabel[64];
> + charname[64];
> + charpath[64];
^ I understand why you’re using fixed character arrays but there is no
guarantee that the sizes are going to be large enough.
The path is especially worrisome.

Since you’re going to dynamically allocate the fixup, make them pointers;

char *label, *name, *path;

> + int index;
> +};
> +
> +static int fdt_get_max_phandle(const void *dt)
> +{
> + int offset, phandle = 0, new_phandle;
> +

phandle is a uint32_t or u32. Since this is libfdt uint32_t.


> + for (offset = fdt_next_node(dt, -1, NULL); offset >= 0;
> +  offset = fdt_next_node(dt, offset, NULL)) {
> + new_phandle = fdt_get_phandle(dt, offset);
> + if (new_phandle > phandle)
> + phandle = new_phandle;
> + }
> +
> + return phandle;
> +}
> +
> +static uint32_t fdt_overlay_get_target_phandle(const void *dt, int node)
> +{
> + const uint32_t *val;
> + int len;
> +
> + val = fdt_getprop(dt, node, "target", );
> + if (!val || (len != sizeof(*val)))
> + return 0;
> +
> + return fdt32_to_cpu(*val);
> +}
> +
> +static int fdt_overlay_get_target(const 

Re: [U-Boot] [PATCH 1/2] mmc: dw_mmc: Increase timeout to 20 seconds

[Pantelis Antoniou]

Hi Tom,

> On Sep 18, 2015, at 22:27 , Tom Rini  wrote:
> 
> On Fri, Sep 18, 2015 at 09:32:47AM +0200, Lukasz Majewski wrote:
>> Hi Tom,
>> 
>>> On Thu, Sep 17, 2015 at 04:43:33PM +0200, Lukasz Majewski wrote:
>>> 
 Hi Tom,
 
> On Monday, September 14, 2015 at 01:22:20 PM, Lukasz Majewski
> wrote:
>> Hi Alexey,
>> 
>>> Hi Marek, Lukasz,
>>> 
>>> On Sun, 2015-09-13 at 16:00 +0200, Marek Vasut wrote:
 On Sunday, September 13, 2015 at 12:03:18 PM, Lukasz
 Majewski wrote:
> Hi Marek,
 
 Hi,
 
 [...]
 
 Still we need to fix regression first with virtually
 infinite timeout :) I would even thing that simple
 revert of Marek's patch may make sense for now.
>>> 
>>> +1 - unfortunately there were some other patches
>>> applied to this particular patch. Simple revert might
>>> be a bit tricky here.
>> 
>> -1 - In case the card gets removed during the DMA
>> transfer and the board doesn't have a watchdog, it will
>> get stuck indefinitelly.
> 
> I'm just wondering here - why the indefinite loop was
> working previously? Was anybody complaining (on the ML)
> about the problem of removing the SD card when some
> operation is ongoing?
 
 It worked for me for all the workloads I used. Noone was
 complaining.
>>> 
>>> The same story here - previous code with infinite loop was
>>> working for my boards. And now I do see a problem with pretty
>>> simple scenario that we do use in our products.
>>> 
> The problem with potential removal of SD card (after
> booting the board) is with us for quite long time. Even
> with indefinite loop (without your patch) we also could
> "hang" the board if the SD card was removed during a
> transfer.
 
 Which is why we should weed out the unbounded loops.
 
>> We
>> absolutelly don't want this sort of behavior in U-Boot.
>> I understand that this is the easiest way for everyone
>> to achieve some sort of "working" solution, but it is
>> definitelly not the correct one. While I do agree to
>> increasing the timeout, I do not agree to unbounded
>> loops, sorry.
> 
> We have agreed to not agree :-)
 
 Yes :-)
>>> 
>>> The first thing I care is working U-Boot v2015.10 out of the
>>> box on my boards. And so I may agree on any temporary
>>> solution. I see it as timeout value either being infinite or
>>> obviously very high like 60 seconds.
>>> 
>>> 60 seconds might sound stupid but my thought behind this is to
>>> make sure even long transfers succeed. Imagine 100 Mb rootfs
>>> or update file downloaded from slow SD-card.
>> 
>> Transfer of rootfs to SD-card (downloaded to memory via tftp) is
>> definitely valid scenario.
>> 
 From both points of view for keeping history
 clean (compared to stacked fixes/workarounds) and
 from removal of regression root cause.
>>> 
>>> As I said before - +1 from me.
>> 
>> As I said before, -1 from me. Btw. did anything regress
>> in here? To me, this seems like a newly discovered
>> bug ...
> 
> Yes, this is a bug. We had similar problem with Samsung's
> SDHCI, before we switched to dw_mmc. This issue is new at
> dw_mmc.
> 
 It's not that I like to have infinite loops but
 given previous implementation worked fine for
 people in the previous U-Boot release.
>>> 
>>> Good justification
>> 
>> It is never a justified to return to a potentially
>> problematic version
> 
> IMHO revering the change (before the release) is from the
> software development point of view better solution than
> adding some heuristic delta to timeout.
> 
>> for the sake of getting some sort of crappy hardware
>> operational.
> 
> Unfortunately this "crappy hardware" is pervasive and we
> cannot do anything about it.
> 
> To sum up (my point of view):
> 1. The best would be to revert the patch - but if simple
> "git revert" is not working then,
>>> 
>>> Well even if clean revert won't work we may do manual tweaks
>>> so that functionally it is "revert". If of any interest I may
>>> come up with that sort of patch.
>>> 
> 2. We should increase the timeout (with my patch) for
> v2015.10 release
>>> 
>>> If everybody is OK with that let's go do it. Because release
>>> is around the corner and I don't want to explain each and
>>> every 

Re: [U-Boot] [PATCH] mmc: sdhci: Fix the SD clock stop sequence

[Pantelis Antoniou]

Hi Wenyou,

> On Sep 16, 2015, at 11:22 , Wenyou Yang  wrote:
> 
> According to the SDHC specification, stopping the SD Clock is by setting
> the SD Clock Enable bit in the Clock Control register at 0, instead of
> setting all bits at 0.
> 
> Before stopping the SD clock, we need to make sure all SD transactions
> to complete, so add checking the CMD and DAT bits in the Presen State
> register, before stopping the SD clock.
> 
> Signed-off-by: Wenyou Yang 
> ---
> 
> drivers/mmc/sdhci.c |   10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> index d89e302..f02db4e 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -286,9 +286,15 @@ static int sdhci_send_command(struct mmc *mmc, struct 
> mmc_cmd *cmd,
> static int sdhci_set_clock(struct mmc *mmc, unsigned int clock)
> {
>   struct sdhci_host *host = mmc->priv;
> - unsigned int div, clk, timeout;
> + unsigned int div, clk, timeout, reg;
> 
> - sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
> + while (sdhci_readl(host, SDHCI_PRESENT_STATE) &
> +(SDHCI_CMD_INHIBIT | SDHCI_DATA_INHIBIT))
> + ;
> +

Put a timeout here in case something is broken.

> + reg = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
> + reg &= ~SDHCI_CLOCK_CARD_EN;
> + sdhci_writew(host, reg, SDHCI_CLOCK_CONTROL);
> 
>   if (clock == 0)
>   return 0;
> -- 
> 1.7.9.5
> 

Regards

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] mmc: dw_mmc: Increase timeout to 20 seconds

[Pantelis Antoniou]

Hi Marek,

> On Aug 29, 2015, at 22:19 , Marek Vasut  wrote:
> 
> On Saturday, August 29, 2015 at 06:38:48 PM, Lukasz Majewski wrote:
>> Hi Marek,
> 
> Hi Lukasz,
> 
>>> On Saturday, August 29, 2015 at 01:55:36 PM, Lukasz Majewski wrote:
 On Fri, 28 Aug 2015 23:55:17 +0200
>>> 
>>> Hi!
>>> 
 Marek Vasut  wrote:
> On Friday, August 28, 2015 at 03:50:20 PM, Lukasz Majewski wrote:
>> The commit: d9dbb97be0e4a550457aec5f11afefb446169c90
>> "mmc: dw_mmc: Zap endless timeout" removed endless loop waiting
>> for end of dw mmc transfer.
>> 
>> For some workloads - dfu test @ Odroid XU3 (sending 8MiB file) -
>> and SD cards (e.g. MicroSD Kingston 4GiB, Adata 4GiB)
>> the default timeout is to short.
>> 
>> The new value - 20 seconds - takes into account the situation
>> when SD card triggers internal clean up. Such process may take
>> more than 10 seconds on some cards.
> 
> What happens if you pull the SD card out of the slot during such a
> process?
 
 Then we would wait 20 seconds :-) to proceed.
>>> 
>>> Oops, I think I was not clear here. I was wondering what happens to
>>> the card if you yank it out of the slot whole it's performing it's
>>> internal cleanup or whatever. Is it possible that the card suffers
>>> data corruption, effectively trashing user data ?
>> 
>> I think that only the card manufacturer may reveal what can happen with
>> the card (what policy have been implemented in their FW).
>> 
>> I guess that you may lost data in such case.
> 
> Uuuurgh, that's seriously shitty.
> 

Welcome to the world of managed flash. Manufacturers tend not to follow the
spec to the letter. What matters is standard consumer usage benchmarks.

>>> Is this behavior
>>> specific to Samsung SD cards ?
>> 
>> I've experienced the problem with Kingston (brand new one) and Adata
>> MicroSD HC (4GiB) cards.
> 
> I had bad previous experience with Kingston too.
> 
 To be clear - the mentioned patch introduced regression.
>>> 
>>> That's a bug, not a regression, but anyway,
>>> that's not the point. I do
>>> agree with you that we do have a problem and I'm inclined to Ack this
>>> patch, I'd like to understand what the real implications of such a
>>> behavior of these cards are.
>>> 
 It works for
 small files on a commonly available SD cards (like 4 GiB
 Kingston/Adata).
 
 When I ran DFU tests I've discovered that there is a problem with
 storing 8MiB file (dat_8M.img).
 
 Even worse - when one wants to store Image.itb file (which might be
 4-6 MiB) it sometimes works and sometimes not. Nightmare for
 debugging.
>>> 
>>> Ew, that's one crappy card you have there. I'm reading the SD card
>>> "Physical Layer Simplified Specification Version 4.10" (part1_410.pdf)
>>> section 4.6.2.2 and it states that for SDHC cards, the write operation
>>> should take at most 250mS, for SDXC it's 500mS. Could it be that your
>>> card is violating the spec ?
>> 
>> I'll look into the spec and then comment :-).
>> 
>> For my boards the time was 1.2 seconds for storing 8 MiB file.
> 
> OK, but that's weird. The transfer should always be up to 512B long and not
> any longer, unless it's a multiblock transfer.
> 
 Please correct me if I'm wrong - but is seems like we are now using
 1 second timeout for detection if SD card has been removed?
 
 Shouldn't we use polling on the card detect IO pin instead? We
 could add such polling in several places in the MMC subsystem (like
 we do it with watchdog).
 
 Marek, Pantelis, what do you think about this?
>>> 
>>> If you implement board_mmc_getcd(), you can check if the card is
>>> present this way instead of waiting for command to time out. The
>>> infrastructure for that is already in place. Right ?
>> 
>> So you suggest adding board_mmc_getcd() in several places in the mmc
>> subsystem driver to detect removal of the SD card?
> 
> H, I'm not sure about this one. Panto ?
> 

I’m fine with this. Perhaps we can avoid spamming this all over the place,
and that would be better.

>>> It'd be cool if the MMC subsystem could pull the wp-gpios and cd-gpios
>>> from DT though :)
>> 
>> +1
>> 

Indeed. I would expect this to be a per-board thing. I would not expect
all platforms to provide that capability.

> Also, where did you find out there is such "cleanup" mechanism
> please ?
 
 Internally we did some tests with several SD cards. We were stunned
 when it turned out that for some workloads it took up to 15 seconds
 to end write operation for small data.
 
 The culprit is the SD Card embedded controller responsible for FTL -
 flash translation layer.
 It allows NAND memory on the card to be visible as the block device.
 More importantly it also takes care of wear leveling and bad block
 management.
 
 Hence, we don't know when it would start housekeeping operations.

Re: [U-Boot] [PATCH V2 4/4] mmc: dw_mmc: Probe the MMC from OF

[Pantelis Antoniou]

Plumbers :)

Στάλθηκε από το iPhone μου

19 Αυγ 2015, 14:58, ο/η Marek Vasut ma...@denx.de έγραψε:

 On Wednesday, August 12, 2015 at 10:43:26 PM, Marek Vasut wrote:
 Rework the driver to probe the MMC controller from Device Tree
 and make it mandatory. There is no longer support for probing
 from the ancient qts-generated header files.
 
 Signed-off-by: Marek Vasut ma...@denx.de
 Cc: Dinh Nguyen dingu...@opensource.altera.com
 Cc: Pantelis Antoniou pa...@antoniou-consulting.com
 Cc: Tom Rini tr...@konsulko.com
 
 Bump?
 
 Best regards,
 Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 01/11] dm: serial: Update binding for PL01x serial UART

[Pantelis Antoniou]

Hi Ian,

 On Aug 13, 2015, at 22:04 , Ian Lepore i...@freebsd.org wrote:
 
 On Thu, 2015-08-13 at 14:13 -0400, Tom Rini wrote:
 On Thu, Aug 13, 2015 at 10:02:58AM -0600, Stephen Warren wrote:
 On 08/13/2015 09:59 AM, Simon Glass wrote:
 Hi Linus,
 
 On 11 August 2015 at 07:00, Linus Walleij linus.wall...@linaro.org wrote:
 On Fri, Aug 7, 2015 at 3:42 PM, Simon Glass s...@chromium.org wrote:
 
 This binding differs from that of Linux. Update it and change existing
 users.
 
 Signed-off-by: Simon Glass s...@chromium.org
 (...)
 doc/device-tree-bindings/serial/pl01x.txt | 55 
 ---
 
 So why does U-Boot have its own copy of any bindings at all?
 
 This is forking the ontology of who gets to define bindings I fear.
 It's a bit like have two bibles both claiming to be the word of god.
 (OK maybe a hyperbolic statement, but you see what I mean.)
 
 Can't we just have the bindings in the Linux kernel tree please?
 
 Is there any plan to move them out of Linux and put them in a separate 
 place?
 
 We should make an effort to sync the device tree files with Linux 
 periodically.
 
 I quite like having the bindings in U-Boot since it makes people think
 about what they are adding. Are you worried that the bindings in
 U-Boot might evolve separately? Certainly there has been some of that.
 
 However I recently sent a series to add a few things for Raspberry Pi
 (arm: rpi: Device tree modifications for U-Boot) and I don't yet see
 a willingness to add what some see as 'U-Boot things' to the binding.
 How do we address that?
 
 DT isn't supposed to contain U-Boot things, but an OS-agnostic
 description of the hardware. So, I imagine the solution is not to
 attempt to do that:-)
 
 This always makes me ask if the FreeBSD folks or VxWorks folks have
 adopted the Linux bindings or if the DT files continue to be
 OS-agnostic and only functional with Linux.  It was a while ago last
 I looked but it made my head hurt a little doing a quick translation for
 an SoC that I was familiar with.
 
 
 As the FreeBSD person who got our first SoC (imx6, only partially
 supported) converted to use the Linux DT files rather than our own
 homebrew mess we started with, I would say that my opinion of the
 existing DT information is that it is an extension of Linux device
 drivers written in a different language.
 
 The information available is in no way independent of the Linux device
 drivers, it is exactly the information those drivers need.  It is often
 not the information needed in another OS with independently written
 drivers.  And especially it is not ordered and structured in a way that
 works well with the device enumeration and instantiation models used by
 another OS.
 

As one that had to suffer under an alternative OS’s definition of what DT
is, and how bindings work (VxWorks) I would like to have some concrete
example about any cases like that.

In my experience the mismatch may come from exactly two things:

1) From the lack of involvement in the DT process that’s going on devicetree.
True, there’s a very big Linux bias but the maintainers are reasonable
and they are open on any kind of collaboration in that area.

2) From the completely half-assed way that internally DT has been implemented
in other OSes besides Linux. I am still scared by the VxWorks stuff, but
things are not much better in u-boot either. You just can’t slap in
libfdt in there and expect all the modern bindings to work (like clock tree,
pinmuxing, etc.) I would hope we’ll get things better in u-boot and I would
certainly like to coordinate with FreeBSD or whoever to get something
done with a reasonable API (and license) that anyone can use.

Due to this, DT bindings end up OS specific which is rather insane if you
think about it.

 A great case in point would be i2c eeproms.  What a perfect opportunity
 DT would be to describe everything about the eeprom parts (total
 capacity, page read/write size, whether the page address bits extend
 into the bus-slave address bits, etc).  It seems to me that anything
 claiming to be an independent description of the hardware would have to
 include such things.  Instead, all the bindings define is the compatible
 string.  That's crazy.  Why?  Well, when I went and looked at the Linux
 eeprom drivers it became clear why:  that's all they need to know,
 because everything else is hard-coded in tables in the driver source.
 
 So if I want to write a FreeBSD i2c eeprom driver that uses DT data,
 what are my choices?  I have exactly one:  make my driver essentially a
 clone of the Linux driver, with all the same data hard-coded in source.
 

I would like to point out that picking i2c eeproms as an example is
rather disingenuous. i2c eeproms until recently were in the land of
drivers/misc where all the oddballs are located.

I’m very happy to point out that Linux does now have (in -next) an 
EEPROM (nvmem) framework that _is_ sane.

Re: [U-Boot] Pull request: u-boot-mmc 12082015

[Pantelis Antoniou]

Hi Tom,

 On Aug 12, 2015, at 12:19 , Marek Vasut ma...@denx.de wrote:
 
 On Wednesday, August 12, 2015 at 09:48:28 AM, Pantelis Antoniou wrote:
 Hi Tom,
 
 The following changes since commit
 e2c1c5bae619d2e87505de99f907a26237640bc9:
 
  Merge git://git.denx.de/u-boot-dm (2015-08-10 10:06:07 -0400)
 
 are available in the git repository at:
 
 
  git://git.denx.de/u-boot-mmc.git master
 
 for you to fetch changes up to 956f662b1f79ae7455bc6aaa9defc2a756e8e9ca:
 
  mmc_spi: Big-endian support (2015-08-12 10:41:14 +0300)
 
 
 Marek Vasut (3):
  mmc: dw_mmc: Stop bounce buffer even in case of failure
  mmc: dw_mmc: Zap endless timeout
  mmc: dw_mmc: Improve handling of data transfer failure
 
 Simon Glass (3):
  mmc: dw_mmc: Avoid using printf() for errors
  mmc: dw_mmc: Support bypass mode with the get_mmc_clk() method
 
 This patch still has open questions, I think you should drop it for now.
 
 Best regards,
 Marek Vasut

After all the hoopla, I’ve removed the offending patch; here’s a new pull 
request.

The following changes since commit e2c1c5bae619d2e87505de99f907a26237640bc9:

  Merge git://git.denx.de/u-boot-dm (2015-08-10 10:06:07 -0400)

are available in the git repository at:


  git://git.denx.de/u-boot-mmc.git master

for you to fetch changes up to 6f67b69b1592662ec49485101a2358b71070bf57:

  mmc_spi: Big-endian support (2015-08-13 11:24:26 +0300)


Marek Vasut (3):
  mmc: dw_mmc: Stop bounce buffer even in case of failure
  mmc: dw_mmc: Zap endless timeout
  mmc: dw_mmc: Improve handling of data transfer failure

Simon Glass (2):
  mmc: dw_mmc: Avoid using printf() for errors
  dw_mmc: Calculate dwmmc FIFO threshold size if not provided

Yoshinori Sato (1):
  mmc_spi: Big-endian support

 drivers/mmc/dw_mmc.c  | 59 
++-
 drivers/mmc/mmc_spi.c | 10 +-
 2 files changed, 47 insertions(+), 22 deletions(-)

Regards

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] mmc: dw_mmc: Improve handling of data transfer failure

[Pantelis Antoniou]

Hi Marek,

 On Jul 27, 2015, at 23:39 , Marek Vasut ma...@denx.de wrote:
 
 In case the data transfer failure happens, instead of returning
 immediatelly, make sure the DMA is disabled, status register is
 cleared and the bounce buffer is stopped.
 
 Signed-off-by: Marek Vasut ma...@denx.de
 Cc: Dinh Nguyen dingu...@opensource.altera.com
 Cc: Pantelis Antoniou pa...@antoniou-consulting.com
 Cc: Tom Rini tr...@konsulko.com
 ---
 drivers/mmc/dw_mmc.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)
 
 diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
 index 0f61f16..fcd5784 100644
 --- a/drivers/mmc/dw_mmc.c
 +++ b/drivers/mmc/dw_mmc.c
 @@ -110,7 +110,7 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd 
 *cmd,
   struct dwmci_host *host = mmc-priv;
   ALLOC_CACHE_ALIGN_BUFFER(struct dwmci_idmac, cur_idmac,
data ? DIV_ROUND_UP(data-blocks, 8) : 0);
 - int flags = 0, i;
 + int ret = 0, flags = 0, i;
   unsigned int timeout = 10;
   u32 retry = 1;
   u32 mask, ctrl;
 @@ -218,20 +218,22 @@ static int dwmci_send_cmd(struct mmc *mmc, struct 
 mmc_cmd *cmd,
   /* Error during data transfer. */
   if (mask  (DWMCI_DATA_ERR | DWMCI_DATA_TOUT)) {
   printf(%s: DATA ERROR!\n, __func__);
 - bounce_buffer_stop(bbstate);
 - return -1;
 + ret = -EINVAL;
 + break;
   }
 
   /* Data arrived correctly. */
 - if (mask  DWMCI_INTMSK_DTO)
 + if (mask  DWMCI_INTMSK_DTO) {
 + ret = 0;
   break;
 + }
 
   /* Check for timeout. */
   if (get_timer(start)  timeout) {
   printf(%s: Timeout waiting for data!\n,
  __func__);
 - bounce_buffer_stop(bbstate);
 - return TIMEOUT;
 + ret = TIMEOUT;
 + break;
   }
   }
 
 @@ -246,7 +248,7 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd 
 *cmd,
 
   udelay(100);
 
 - return 0;
 + return ret;
 }
 
 static int dwmci_setup_bus(struct dwmci_host *host, u32 freq)
 -- 
 2.1.4

Applied, thanks

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mmc_spi: Big-endian support

[Pantelis Antoniou]

Hi Yoshinori,

 On Jun 1, 2015, at 09:22 , Yoshinori Sato ys...@users.sourceforge.jp wrote:
 
 Currently implement always swap for big-endian value.
 So doesn't work big-endian environment.
 
 Signed-off-by: Yoshinori Sato ys...@users.sourceforge.jp
 ---
 drivers/mmc/mmc_spi.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/mmc/mmc_spi.c b/drivers/mmc/mmc_spi.c
 index 5b5b33a..9032a73 100644
 --- a/drivers/mmc/mmc_spi.c
 +++ b/drivers/mmc/mmc_spi.c
 @@ -11,7 +11,7 @@
 #include spi.h
 #include crc.h
 #include linux/crc7.h
 -#include linux/byteorder/swab.h
 +#include asm/byteorder.h
 
 /* MMC/SD in SPI mode reports R1 status always */
 #define R1_SPI_IDLE   (1  0)
 @@ -91,7 +91,7 @@ static uint mmc_spi_readdata(struct mmc *mmc, void *xbuf,
   spi_xfer(spi, bsize * 8, NULL, buf, 0);
   spi_xfer(spi, 2 * 8, NULL, crc, 0);
 #ifdef CONFIG_MMC_SPI_CRC_ON
 - if (swab16(cyg_crc16(buf, bsize)) != crc) {
 + if (be_to_cpu16(cyg_crc16(buf, bsize)) != crc) {
   debug(%s: CRC error\n, mmc-cfg-name);
   r1 = R1_SPI_COM_CRC;
   break;
 @@ -120,7 +120,7 @@ static uint mmc_spi_writedata(struct mmc *mmc, const void 
 *xbuf,
   tok[1] = multi ? SPI_TOKEN_MULTI_WRITE : SPI_TOKEN_SINGLE;
   while (bcnt--) {
 #ifdef CONFIG_MMC_SPI_CRC_ON
 - crc = swab16(cyg_crc16((u8 *)buf, bsize));
 + crc = cpu_to_be16(cyg_crc16((u8 *)buf, bsize));
 #endif
   spi_xfer(spi, 2 * 8, tok, NULL, 0);
   spi_xfer(spi, bsize * 8, buf, NULL, 0);
 @@ -193,7 +193,7 @@ static int mmc_spi_request(struct mmc *mmc, struct 
 mmc_cmd *cmd,
   } else if (cmd-resp_type == MMC_RSP_R2) {
   r1 = mmc_spi_readdata(mmc, cmd-response, 1, 16);
   for (i = 0; i  4; i++)
 - cmd-response[i] = swab32(cmd-response[i]);
 + cmd-response[i] = be32_to_cpu(cmd-response[i]);
   debug(r128 %x %x %x %x\n, cmd-response[0], cmd-response[1],
 cmd-response[2], cmd-response[3]);
   } else if (!data) {
 @@ -205,7 +205,7 @@ static int mmc_spi_request(struct mmc *mmc, struct 
 mmc_cmd *cmd,
   case SD_CMD_SEND_IF_COND:
   case MMC_CMD_SPI_READ_OCR:
   spi_xfer(spi, 4 * 8, NULL, cmd-response, 0);
 - cmd-response[0] = swab32(cmd-response[0]);
 + cmd-response[0] = be32_to_cpu(cmd-response[0]);
   debug(r32 %x\n, cmd-response[0]);
   break;
   case MMC_CMD_SEND_STATUS:
 -- 
 2.1.4
 

Applied, thanks.

— Pantelis


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] mmc: dw_mmc: Zap endless timeout

[Pantelis Antoniou]

Hi Marek,

 On Jul 27, 2015, at 23:39 , Marek Vasut ma...@denx.de wrote:
 
 Endless timeouts are bad, since if we get stuck in one, we have no
 way out. Zap this one by implementing proper timeout.
 
 Signed-off-by: Marek Vasut ma...@denx.de
 Cc: Dinh Nguyen dingu...@opensource.altera.com
 Cc: Pantelis Antoniou pa...@antoniou-consulting.com
 Cc: Tom Rini tr...@konsulko.com
 ---
 drivers/mmc/dw_mmc.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
 index 3fffa71..0f61f16 100644
 --- a/drivers/mmc/dw_mmc.c
 +++ b/drivers/mmc/dw_mmc.c
 @@ -211,14 +211,29 @@ static int dwmci_send_cmd(struct mmc *mmc, struct 
 mmc_cmd *cmd,
   }
 
   if (data) {
 - do {
 + start = get_timer(0);
 + timeout = 1000;
 + for (;;) {
   mask = dwmci_readl(host, DWMCI_RINTSTS);
 + /* Error during data transfer. */
   if (mask  (DWMCI_DATA_ERR | DWMCI_DATA_TOUT)) {
   printf(%s: DATA ERROR!\n, __func__);
   bounce_buffer_stop(bbstate);
   return -1;
   }
 - } while (!(mask  DWMCI_INTMSK_DTO));
 +
 + /* Data arrived correctly. */
 + if (mask  DWMCI_INTMSK_DTO)
 + break;
 +
 + /* Check for timeout. */
 + if (get_timer(start)  timeout) {
 + printf(%s: Timeout waiting for data!\n,
 +__func__);
 + bounce_buffer_stop(bbstate);
 + return TIMEOUT;
 + }
 + }
 
   dwmci_writel(host, DWMCI_RINTSTS, mask);
 
 -- 
 2.1.4

Applied, thanks

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/4] mmc: dw_mmc: Probe the MMC from OF

[Pantelis Antoniou]

Hi Marek,

 On Jul 27, 2015, at 23:39 , Marek Vasut ma...@denx.de wrote:
 
 Rework the driver to probe the MMC controller from Device Tree
 and make it mandatory. There is no longer support for probing
 from the ancient qts-generated header files.
 
 Signed-off-by: Marek Vasut ma...@denx.de
 Cc: Dinh Nguyen dingu...@opensource.altera.com
 Cc: Pantelis Antoniou pa...@antoniou-consulting.com
 Cc: Tom Rini tr...@konsulko.com
 ---
 arch/arm/mach-socfpga/include/mach/dwmmc.h |  2 +-
 arch/arm/mach-socfpga/misc.c   |  3 +-
 drivers/mmc/socfpga_dw_mmc.c   | 81 +-
 include/fdtdec.h   |  1 +
 lib/fdtdec.c   |  1 +
 5 files changed, 72 insertions(+), 16 deletions(-)
 
 diff --git a/arch/arm/mach-socfpga/include/mach/dwmmc.h 
 b/arch/arm/mach-socfpga/include/mach/dwmmc.h
 index 945eb64..e8ba901 100644
 --- a/arch/arm/mach-socfpga/include/mach/dwmmc.h
 +++ b/arch/arm/mach-socfpga/include/mach/dwmmc.h
 @@ -7,6 +7,6 @@
 #ifndef   _SOCFPGA_DWMMC_H_
 #define   _SOCFPGA_DWMMC_H_
 
 -extern int socfpga_dwmmc_init(u32 regbase, int bus_width, int index);
 +int socfpga_dwmmc_init(const void *blob);
 
 #endif /* _SOCFPGA_SDMMC_H_ */
 diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
 index 0f8b4d0..3ddac4c 100644
 --- a/arch/arm/mach-socfpga/misc.c
 +++ b/arch/arm/mach-socfpga/misc.c
 @@ -92,8 +92,7 @@ int cpu_eth_init(bd_t *bis)
  */
 int cpu_mmc_init(bd_t *bis)
 {
 - return socfpga_dwmmc_init(SOCFPGA_SDMMC_ADDRESS,
 -   CONFIG_HPS_SDMMC_BUSWIDTH, 0);
 + return socfpga_dwmmc_init(gd-fdt_blob);
 }
 #endif
 
 diff --git a/drivers/mmc/socfpga_dw_mmc.c b/drivers/mmc/socfpga_dw_mmc.c
 index eb69aed..8076761 100644
 --- a/drivers/mmc/socfpga_dw_mmc.c
 +++ b/drivers/mmc/socfpga_dw_mmc.c
 @@ -6,6 +6,8 @@
 
 #include common.h
 #include malloc.h
 +#include fdtdec.h
 +#include libfdt.h
 #include dwmmc.h
 #include errno.h
 #include asm/arch/dwmmc.h
 @@ -42,34 +44,87 @@ static void socfpga_dwmci_clksel(struct dwmci_host *host)
   CLKMGR_PERPLLGRP_EN_SDMMCCLK_MASK);
 }
 
 -int socfpga_dwmmc_init(u32 regbase, int bus_width, int index)
 +static int socfpga_dwmci_of_probe(const void *blob, int node, const int idx)
 {
 + /* FIXME: probe from DT eventually too/ */
 + const unsigned long clk = cm_get_mmc_controller_clk_hz();
 +
   struct dwmci_host *host;
 - unsigned long clk = cm_get_mmc_controller_clk_hz();
 + fdt_addr_t reg_base;
 + int bus_width, fifo_depth;
 
   if (clk == 0) {
 - printf(%s: MMC clock is zero!, __func__);
 + printf(DWMMC%d: MMC clock is zero!, idx);
   return -EINVAL;
   }
 
 - /* calloc for zero init */
 - host = calloc(1, sizeof(struct dwmci_host));
 - if (!host) {
 - printf(%s: calloc() failed!\n, __func__);
 - return -ENOMEM;
 + /* Get the register address from the device node */
 + reg_base = fdtdec_get_addr(blob, node, reg);
 + if (!reg_base) {
 + printf(DWMMC%d: Can't get base address\n, idx);
 + return -EINVAL;
 + }
 +
 + /* Get the bus width from the device node */
 + bus_width = fdtdec_get_int(blob, node, bus-width, 0);
 + if (bus_width = 0) {
 + printf(DWMMC%d: Can't get bus-width\n, idx);
 + return -EINVAL;
   }
 
 + fifo_depth = fdtdec_get_int(blob, node, fifo-depth, 0);
 + if (fifo_depth  0) {
 + printf(DWMMC%d: Can't get FIFO depth\n, idx);
 + return -EINVAL;
 + }
 +
 + /* Allocate the host */
 + host = calloc(1, sizeof(*host));
 + if (!host)
 + return -ENOMEM;
 +
   host-name = SOCFPGA DWMMC;
 - host-ioaddr = (void *)regbase;
 + host-ioaddr = (void *)reg_base;
   host-buswidth = bus_width;
   host-clksel = socfpga_dwmci_clksel;
 - host-dev_index = index;
 - /* fixed clock divide by 4 which due to the SDMMC wrapper */
 + host-dev_index = idx;
 + /* Fixed clock divide by 4 which due to the SDMMC wrapper */
   host-bus_hz = clk;
   host-fifoth_val = MSIZE(0x2) |
 - RX_WMARK(CONFIG_SOCFPGA_DWMMC_FIFO_DEPTH / 2 - 1) |
 - TX_WMARK(CONFIG_SOCFPGA_DWMMC_FIFO_DEPTH / 2);
 + RX_WMARK(fifo_depth / 2 - 1) | TX_WMARK(fifo_depth / 2);
 
   return add_dwmci(host, host-bus_hz, 40);
 }
 
 +static int socfpga_dwmci_process_node(const void *blob, int nodes[],
 +   int count)
 +{
 + int i, node, ret;
 +
 + for (i = 0; i  count; i++) {
 + node = nodes[i];
 + if (node = 0)
 + continue;
 +
 + ret = socfpga_dwmci_of_probe(blob, node, i);
 + if (ret) {
 + printf(%s: failed to decode dev %d\n, __func__, i);
 + return ret;
 + }
 + }
 + return 0;
 +}
 +
 +int

Re: [U-Boot] [PATCH v4 3/3] mmc: Calculate dwmmc FIFO threshold size if not provided

[Pantelis Antoniou]

Hi Simin,

 On Aug 7, 2015, at 05:16 , Simon Glass s...@chromium.org wrote:
 
 We can calculate this. Add code to do this if it is not provided.
 
 Signed-off-by: Simon Glass s...@chromium.org
 ---
 
 Changes in v4: None
 
 drivers/mmc/dw_mmc.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
 index a034c3f..cce2a5d 100644
 --- a/drivers/mmc/dw_mmc.c
 +++ b/drivers/mmc/dw_mmc.c
 @@ -355,9 +355,15 @@ static int dwmci_init(struct mmc *mmc)
   dwmci_writel(host, DWMCI_IDINTEN, 0);
   dwmci_writel(host, DWMCI_BMOD, 1);
 
 - if (host-fifoth_val) {
 - dwmci_writel(host, DWMCI_FIFOTH, host-fifoth_val);
 + if (!host-fifoth_val) {
 + uint32_t fifo_size;
 +
 + fifo_size = dwmci_readl(host, DWMCI_FIFOTH);
 + fifo_size = ((fifo_size  RX_WMARK_MASK)  RX_WMARK_SHIFT) + 1;
 + host-fifoth_val = MSIZE(0x2) | RX_WMARK(fifo_size / 2 - 1) |
 + TX_WMARK(fifo_size / 2);
   }
 + dwmci_writel(host, DWMCI_FIFOTH, host-fifoth_val);
 
   dwmci_writel(host, DWMCI_CLKENA, 0);
   dwmci_writel(host, DWMCI_CLKSRC, 0);
 -- 
 2.5.0.rc2.392.g76e840b
 

Thanks, applied (with prefix changed to dw_mmc :) )

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Pull request: u-boot-mmc 12082015

[Pantelis Antoniou]

Hi Tom,

The following changes since commit e2c1c5bae619d2e87505de99f907a26237640bc9:

  Merge git://git.denx.de/u-boot-dm (2015-08-10 10:06:07 -0400)

are available in the git repository at:


  git://git.denx.de/u-boot-mmc.git master

for you to fetch changes up to 956f662b1f79ae7455bc6aaa9defc2a756e8e9ca:

  mmc_spi: Big-endian support (2015-08-12 10:41:14 +0300)


Marek Vasut (3):
  mmc: dw_mmc: Stop bounce buffer even in case of failure
  mmc: dw_mmc: Zap endless timeout
  mmc: dw_mmc: Improve handling of data transfer failure

Simon Glass (3):
  mmc: dw_mmc: Avoid using printf() for errors
  mmc: dw_mmc: Support bypass mode with the get_mmc_clk() method
  dw_mmc: Calculate dwmmc FIFO threshold size if not provided

Yoshinori Sato (1):
  mmc_spi: Big-endian support

 drivers/mmc/dw_mmc.c| 61 
+++--
 drivers/mmc/exynos_dw_mmc.c |  2 +-
 drivers/mmc/mmc_spi.c   | 10 +-
 include/dwmmc.h | 16 +++-
 4 files changed, 64 insertions(+), 25 deletions(-)

Regards

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ls2085a: esdhc: flush D-cache before 'mmc read'

[Pantelis Antoniou]

Hi Yangbo,

 On Jun 24, 2015, at 05:13 , Yangbo Lu yangbo...@freescale.com wrote:
 
 It needs to flush D-cache before 'mmc read' so that
 we can see the right data in DDR. And fix parameter
 for invalidate_dcache_range() after 'mmc read'.
 
 Signed-off-by: Yangbo Lu yangbo...@freescale.com
 Cc: York Sun york...@freescale.com
 ---
 drivers/mmc/fsl_esdhc.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
 index c4719e6..3ca25bd 100644
 --- a/drivers/mmc/fsl_esdhc.c
 +++ b/drivers/mmc/fsl_esdhc.c
 @@ -192,6 +192,17 @@ static int esdhc_setup_data(struct mmc *mmc, struct 
 mmc_data *data)
   wml_value = data-blocksize/4;
 
   if (data-flags  MMC_DATA_READ) {
 +#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
 +#ifdef CONFIG_LS2085A
 + /*
 +  * It's temporary for ls2085a so that
 +  * we can see right data in DDR
 +  */
 + flush_dcache_range((ulong)data-dest,
 +(ulong)data-dest+data-blocks
 +  *data-blocksize);
 +#endif
 +#endif
   if (wml_value  WML_RD_WML_MAX)
   wml_value = WML_RD_WML_MAX_VAL;
 

This looks like not board/soc specific, more like whether a non-coherent 
architecture.

Please rework as a configuration option that’s suited for that kind of 
architectures.

It looks like you’re only doing this for reads? What about writes?

 @@ -278,14 +289,9 @@ static int esdhc_setup_data(struct mmc *mmc, struct 
 mmc_data *data)
 static void check_and_invalidate_dcache_range
   (struct mmc_cmd *cmd,
struct mmc_data *data) {
 -#ifdef CONFIG_LS2085A
 - unsigned start = 0;
 -#else
 - unsigned start = (unsigned)data-dest ;
 -#endif
 + unsigned start, end;
   unsigned size = roundup(ARCH_DMA_MINALIGN,
   data-blocks*data-blocksize);
 - unsigned end = start+size ;
 #ifdef CONFIG_LS2085A
   dma_addr_t addr;
 
 @@ -294,7 +300,10 @@ static void check_and_invalidate_dcache_range
   printf(Error found for upper 32 bits\n);
   else
   start = lower_32_bits(addr);
 +#else
 + start = (unsigned)data-dest;
 #endif
 + end = start + size;
   invalidate_dcache_range(start, end);
 }
 #endif
 -- 
 2.1.0.27.g96db324
 

Regards

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 2/3] mmc: dw_mmc: Support bypass mode with the get_mmc_clk() method

[Pantelis Antoniou]

Hi Simon,

 On Aug 7, 2015, at 05:16 , Simon Glass s...@chromium.org wrote:
 
 Some SoCs want to adjust the input clock to the DWMMC block as a way of
 controlling the MMC bus clock. Update the get_mmc_clk() method to support
 this.
 
 Signed-off-by: Simon Glass s...@chromium.org
 ---
 
 Changes in v4:
 - Update commit message to indicate this patch is for the dw_mmc driver
 
 drivers/mmc/dw_mmc.c|  2 +-
 drivers/mmc/exynos_dw_mmc.c |  2 +-
 include/dwmmc.h | 16 +++-
 3 files changed, 17 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
 index 8f28d7e..a034c3f 100644
 --- a/drivers/mmc/dw_mmc.c
 +++ b/drivers/mmc/dw_mmc.c
 @@ -248,7 +248,7 @@ static int dwmci_setup_bus(struct dwmci_host *host, u32 
 freq)
* host-bus_hz should be set by user.
*/
   if (host-get_mmc_clk)
 - sclk = host-get_mmc_clk(host);
 + sclk = host-get_mmc_clk(host, freq);
   else if (host-bus_hz)
   sclk = host-bus_hz;
   else {
 diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
 index e083745..3f702ba 100644
 --- a/drivers/mmc/exynos_dw_mmc.c
 +++ b/drivers/mmc/exynos_dw_mmc.c
 @@ -39,7 +39,7 @@ static void exynos_dwmci_clksel(struct dwmci_host *host)
   dwmci_writel(host, DWMCI_CLKSEL, priv-sdr_timing);
 }
 
 -unsigned int exynos_dwmci_get_clk(struct dwmci_host *host)
 +unsigned int exynos_dwmci_get_clk(struct dwmci_host *host, uint freq)
 {
   unsigned long sclk;
   int8_t clk_div;
 diff --git a/include/dwmmc.h b/include/dwmmc.h
 index 7a7555a..25cf42c 100644
 --- a/include/dwmmc.h
 +++ b/include/dwmmc.h
 @@ -163,7 +163,21 @@ struct dwmci_host {
 
   void (*clksel)(struct dwmci_host *host);
   void (*board_init)(struct dwmci_host *host);
 - unsigned int (*get_mmc_clk)(struct dwmci_host *host);
 +
 + /**
 +  * Get / set a particular MMC clock frequency
 +  *
 +  * This is used to request the current clock frequency of the clock
 +  * that drives the DWMMC peripheral. The caller will then use this
 +  * information to work out the divider it needs to achieve the
 +  * required MMC bus clock frequency. If you want to handle the
 +  * clock external to DWMMC, use @freq to select the frequency and
 +  * return that value too. Then DWMMC will put itself in bypass mode.
 +  *
 +  * @host:   DWMMC host
 +  * @freq:   Frequency the host is trying to achieve
 +  */
 + unsigned int (*get_mmc_clk)(struct dwmci_host *host, uint freq);
 
   struct mmc_config cfg;
 };
 -- 
 2.5.0.rc2.392.g76e840b

I’m applying this now. It makes sense. No, we don’t have a clock framework for 
now
so this will do.

Thanks

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 1/3] mmc: dw_mmc: Avoid using printf() for errors

[Pantelis Antoniou]

Hi Simon,

 On Aug 7, 2015, at 05:16 , Simon Glass s...@chromium.org wrote:
 
 The dw_mmc driver uses printf() in various places.
 
 These bloat the code and cause problems for SPL. Use debug() where possible
 and try to return a useful error code instead.
 
 Signed-off-by: Simon Glass s...@chromium.org
 ---
 
 Changes in v4:
 - Update commit message to indicate this patch is for the dw_mmc driver
 
 drivers/mmc/dw_mmc.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)
 
 diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
 index 53a8aca..8f28d7e 100644
 --- a/drivers/mmc/dw_mmc.c
 +++ b/drivers/mmc/dw_mmc.c
 @@ -8,6 +8,7 @@
 
 #include bouncebuf.h
 #include common.h
 +#include errno.h
 #include malloc.h
 #include mmc.h
 #include dwmmc.h
 @@ -119,7 +120,7 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd 
 *cmd,
 
   while (dwmci_readl(host, DWMCI_STATUS)  DWMCI_BUSY) {
   if (get_timer(start)  timeout) {
 - printf(%s: Timeout on data busy\n, __func__);
 + debug(%s: Timeout on data busy\n, __func__);
   return TIMEOUT;
   }
   }
 @@ -178,7 +179,7 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd 
 *cmd,
   }
 
   if (i == retry) {
 - printf(%s: Timeout.\n, __func__);
 + debug(%s: Timeout.\n, __func__);
   return TIMEOUT;
   }
 
 @@ -194,8 +195,8 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd 
 *cmd,
   debug(%s: Response Timeout.\n, __func__);
   return TIMEOUT;
   } else if (mask  DWMCI_INTMSK_RE) {
 - printf(%s: Response Error.\n, __func__);
 - return -1;
 + debug(%s: Response Error.\n, __func__);
 + return -EIO;
   }
 
 
 @@ -214,7 +215,7 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd 
 *cmd,
   do {
   mask = dwmci_readl(host, DWMCI_RINTSTS);
   if (mask  (DWMCI_DATA_ERR | DWMCI_DATA_TOUT)) {
 - printf(%s: DATA ERROR!\n, __func__);
 + debug(%s: DATA ERROR!\n, __func__);
   return -1;
   }
   } while (!(mask  DWMCI_INTMSK_DTO));
 @@ -251,7 +252,7 @@ static int dwmci_setup_bus(struct dwmci_host *host, u32 
 freq)
   else if (host-bus_hz)
   sclk = host-bus_hz;
   else {
 - printf(%s: Didn't get source clock value.\n, __func__);
 + debug(%s: Didn't get source clock value.\n, __func__);
   return -EINVAL;
   }
 
 @@ -270,7 +271,7 @@ static int dwmci_setup_bus(struct dwmci_host *host, u32 
 freq)
   do {
   status = dwmci_readl(host, DWMCI_CMD);
   if (timeout--  0) {
 - printf(%s: Timeout!\n, __func__);
 + debug(%s: Timeout!\n, __func__);
   return -ETIMEDOUT;
   }
   } while (status  DWMCI_CMD_START);
 @@ -285,7 +286,7 @@ static int dwmci_setup_bus(struct dwmci_host *host, u32 
 freq)
   do {
   status = dwmci_readl(host, DWMCI_CMD);
   if (timeout--  0) {
 - printf(%s: Timeout!\n, __func__);
 + debug(%s: Timeout!\n, __func__);
   return -ETIMEDOUT;
   }
   } while (status  DWMCI_CMD_START);
 @@ -339,8 +340,8 @@ static int dwmci_init(struct mmc *mmc)
   dwmci_writel(host, DWMCI_PWREN, 1);
 
   if (!dwmci_wait_reset(host, DWMCI_RESET_ALL)) {
 - printf(%s[%d] Fail-reset!!\n, __func__, __LINE__);
 - return -1;
 + debug(%s[%d] Fail-reset!!\n, __func__, __LINE__);
 + return -EIO;
   }
 
   /* Enumerate at 400KHz */
 -- 
 2.5.0.rc2.392.g76e840b
 

Applied, with a small rework to account for a couple of printfs that Marek’s 
patch
introduced.

Thanks

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] mmc: dw_mmc: Stop bounce buffer even in case of failure

[Pantelis Antoniou]

Hi Marek,

 On Jul 27, 2015, at 23:39 , Marek Vasut ma...@denx.de wrote:
 
 The driver didn't stop the bounce buffer in case a data transfer
 failed. This would lead to memory leakage if the communication
 between the CPU and the card is unreliable. Add the missing call
 to stop the bounce buffer.
 
 Signed-off-by: Marek Vasut ma...@denx.de
 Cc: Dinh Nguyen dingu...@opensource.altera.com
 Cc: Pantelis Antoniou pa...@antoniou-consulting.com
 Cc: Tom Rini tr...@konsulko.com
 ---
 drivers/mmc/dw_mmc.c | 1 +
 1 file changed, 1 insertion(+)
 
 diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
 index 53a8aca..3fffa71 100644
 --- a/drivers/mmc/dw_mmc.c
 +++ b/drivers/mmc/dw_mmc.c
 @@ -215,6 +215,7 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd 
 *cmd,
   mask = dwmci_readl(host, DWMCI_RINTSTS);
   if (mask  (DWMCI_DATA_ERR | DWMCI_DATA_TOUT)) {
   printf(%s: DATA ERROR!\n, __func__);
 + bounce_buffer_stop(bbstate);
   return -1;
   }
   } while (!(mask  DWMCI_INTMSK_DTO));
 -- 
 2.1.4
 

Applied, thanks.

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/6] mmc: Avoid extra duplicate entry in mmc device structure

[Pantelis Antoniou]

Hi Andrw,

 On Mar 19, 2015, at 14:44 , Andrew Gabbasov andrew_gabba...@mentor.com 
 wrote:
 
 The 'op_cond_response' field in mmc structure contains the response
 from the last SEND_OP_COND MMC command while making iterational
 polling of the card. Later it is copied to 'ocr' field, designed
 to contain the OCR register value, which is actually the same
 response from the same command. So, these fields have actually
 the same data, just in different time periods. It's easier to use
 the same 'ocr' field in both cases at once, without temporary using
 of the 'op_cond_response' field.
 
 Signed-off-by: Andrew Gabbasov andrew_gabba...@mentor.com
 ---
 drivers/mmc/mmc.c | 13 +++--
 include/mmc.h |  1 -
 2 files changed, 7 insertions(+), 7 deletions(-)
 
 diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
 index a13769e..fe00a19 100644
 --- a/drivers/mmc/mmc.c
 +++ b/drivers/mmc/mmc.c
 @@ -362,8 +362,8 @@ static int mmc_send_op_cond_iter(struct mmc *mmc, struct 
 mmc_cmd *cmd,
   if (use_arg  !mmc_host_is_spi(mmc)) {
   cmd-cmdarg =
   (mmc-cfg-voltages 
 - (mmc-op_cond_response  OCR_VOLTAGE_MASK)) |
 - (mmc-op_cond_response  OCR_ACCESS_MODE);
 + (mmc-ocr  OCR_VOLTAGE_MASK)) |
 + (mmc-ocr  OCR_ACCESS_MODE);
 
   if (mmc-cfg-host_caps  MMC_MODE_HC)
   cmd-cmdarg |= OCR_HCS;
 @@ -371,7 +371,7 @@ static int mmc_send_op_cond_iter(struct mmc *mmc, struct 
 mmc_cmd *cmd,
   err = mmc_send_cmd(mmc, cmd, NULL);
   if (err)
   return err;
 - mmc-op_cond_response = cmd-response[0];
 + mmc-ocr = cmd-response[0];
   return 0;
 }
 
 @@ -391,7 +391,7 @@ static int mmc_send_op_cond(struct mmc *mmc)
   return err;
 
   /* exit if not busy (flag seems to be inverted) */
 - if (mmc-op_cond_response  OCR_BUSY)
 + if (mmc-ocr  OCR_BUSY)
   return 0;
   }
   return IN_PROGRESS;
 @@ -413,7 +413,7 @@ static int mmc_complete_op_cond(struct mmc *mmc)
   if (get_timer(start)  timeout)
   return UNUSABLE_ERR;
   udelay(100);
 - } while (!(mmc-op_cond_response  OCR_BUSY));
 + } while (!(mmc-ocr  OCR_BUSY));
 
   if (mmc_host_is_spi(mmc)) { /* read OCR for spi */
   cmd.cmdidx = MMC_CMD_SPI_READ_OCR;
 @@ -424,10 +424,11 @@ static int mmc_complete_op_cond(struct mmc *mmc)
 
   if (err)
   return err;
 +
 + mmc-ocr = cmd.response[0];
   }
 
   mmc-version = MMC_VERSION_UNKNOWN;
 - mmc-ocr = cmd.response[0];
 
   mmc-high_capacity = ((mmc-ocr  OCR_HCS) == OCR_HCS);
   mmc-rca = 1;
 diff --git a/include/mmc.h b/include/mmc.h
 index a251531..644e3fa 100644
 --- a/include/mmc.h
 +++ b/include/mmc.h
 @@ -356,7 +356,6 @@ struct mmc {
   char op_cond_pending;   /* 1 if we are waiting on an op_cond command */
   char init_in_progress;  /* 1 if we have done mmc_start_init() */
   char preinit;   /* start init as early as possible */
 - uint op_cond_response;  /* the response byte from the last op_cond */
   int ddr_mode;
 };
 
 -- 
 2.1.0

Thanks, applied.

Regards

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/6] mmc: Do not pass external mmc_cmd structure to mmc_send_op_cond_iter()

[Pantelis Antoniou]

Hi Andrew,

 On Mar 19, 2015, at 14:44 , Andrew Gabbasov andrew_gabba...@mentor.com 
 wrote:
 
 The previous change to use 'ocr' structure field for storing send_op_cond
 command response also stopped using command response directly
 outside of mmc_send_op_cond_iter(). Now it becomes possible to use
 command structure in mmc_send_op_cond_iter() locally, removing a necessity
 to pass it as an argument from the caller.
 
 Signed-off-by: Andrew Gabbasov andrew_gabba...@mentor.com
 ---
 drivers/mmc/mmc.c | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)
 
 diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
 index fe00a19..d073d79 100644
 --- a/drivers/mmc/mmc.c
 +++ b/drivers/mmc/mmc.c
 @@ -350,34 +350,32 @@ static int sd_send_op_cond(struct mmc *mmc)
   return 0;
 }
 
 -/* We pass in the cmd since otherwise the init seems to fail */
 -static int mmc_send_op_cond_iter(struct mmc *mmc, struct mmc_cmd *cmd,
 - int use_arg)
 +static int mmc_send_op_cond_iter(struct mmc *mmc, int use_arg)
 {
 + struct mmc_cmd cmd;
   int err;
 
 - cmd-cmdidx = MMC_CMD_SEND_OP_COND;
 - cmd-resp_type = MMC_RSP_R3;
 - cmd-cmdarg = 0;
 + cmd.cmdidx = MMC_CMD_SEND_OP_COND;
 + cmd.resp_type = MMC_RSP_R3;
 + cmd.cmdarg = 0;
   if (use_arg  !mmc_host_is_spi(mmc)) {
 - cmd-cmdarg =
 + cmd.cmdarg =
   (mmc-cfg-voltages 
   (mmc-ocr  OCR_VOLTAGE_MASK)) |
   (mmc-ocr  OCR_ACCESS_MODE);
 
   if (mmc-cfg-host_caps  MMC_MODE_HC)
 - cmd-cmdarg |= OCR_HCS;
 + cmd.cmdarg |= OCR_HCS;
   }
 - err = mmc_send_cmd(mmc, cmd, NULL);
 + err = mmc_send_cmd(mmc, cmd, NULL);
   if (err)
   return err;
 - mmc-ocr = cmd-response[0];
 + mmc-ocr = cmd.response[0];
   return 0;
 }
 
 static int mmc_send_op_cond(struct mmc *mmc)
 {
 - struct mmc_cmd cmd;
   int err, i;
 
   /* Some cards seem to need this */
 @@ -386,7 +384,7 @@ static int mmc_send_op_cond(struct mmc *mmc)
   /* Asking to the card its capabilities */
   mmc-op_cond_pending = 1;
   for (i = 0; i  2; i++) {
 - err = mmc_send_op_cond_iter(mmc, cmd, i != 0);
 + err = mmc_send_op_cond_iter(mmc, i != 0);
   if (err)
   return err;
 
 @@ -407,7 +405,7 @@ static int mmc_complete_op_cond(struct mmc *mmc)
   mmc-op_cond_pending = 0;
   start = get_timer(0);
   do {
 - err = mmc_send_op_cond_iter(mmc, cmd, 1);
 + err = mmc_send_op_cond_iter(mmc, 1);
   if (err)
   return err;
   if (get_timer(start)  timeout)
 -- 
 2.1.0

Thanks, Applied.

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/6] mmc: Fix typo in MMC type checking macro

[Pantelis Antoniou]

Hi Andrew,

 On Mar 19, 2015, at 14:44 , Andrew Gabbasov andrew_gabba...@mentor.com 
 wrote:
 
 The version flag constant name used in IS_MMC macro is incorrect/undefined.
 
 Signed-off-by: Andrew Gabbasov andrew_gabba...@mentor.com
 ---
 include/mmc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/include/mmc.h b/include/mmc.h
 index 2ad0f19..a251531 100644
 --- a/include/mmc.h
 +++ b/include/mmc.h
 @@ -61,7 +61,7 @@
 #define SD_DATA_4BIT  0x0004
 
 #define IS_SD(x)  ((x)-version  SD_VERSION_SD)
 -#define IS_MMC(x)((x)-version  SD_VERSION_MMC)
 +#define IS_MMC(x)((x)-version  MMC_VERSION_MMC)
 
 #define MMC_DATA_READ 1
 #define MMC_DATA_WRITE2
 -- 
 2.1.0
 

Thanks, applied.

BTW, please make sure you CC me personally when sending patches since this 
slipped out of my attention.

Regards

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mmc: fix OCR Polling

[Pantelis Antoniou]

Hi Peng,

 On Mar 19, 2015, at 10:22 , Peng Fan peng@freescale.com wrote:
 
 If in mmc_send_op_cond, OCR_BUSY is set in CMD1's response, then
 state is transfered to Ready state, and there is no need to send
 CMD1 again. Otherwise following CMD1 will recieve no response, or
 timeour error from driver such as fsl_esdhc.c.
 
 If not into Ready state in previous CMD1, then continue CMD1 command.
 
 In mmc_complete_op_cond, we use the value mmc-op_cond_response
 from mmc_send_op_cond, since there should be no CMD1 command between
 mmc_send_op_cond and mmc_complete_op_cond
 
 Before fixing this, uboot log shows:
 
 CMD_SEND:0
ARG  0x
MMC_RSP_NONE
 CMD_SEND:8
ARG  0x01AA
MMC_RSP_R1,5,6,7 0x18EC1504
 CMD_SEND:55
ARG  0x
MMC_RSP_R1,5,6,7 0x18EC1504
 CMD_SEND:0
ARG  0x
MMC_RSP_NONE
 CMD_SEND:1
ARG  0x
MMC_RSP_R3,4 0x00FF8080
 CMD_SEND:1
ARG  0x4030
MMC_RSP_R3,4 0xC0FF8080 -- Already OCR_BUSY set
 CMD_SEND:1
ARG  0x4030
MMC_RSP_R3,4 0x0096850A -- Failed CMD1
 MMC init failed
 
 
 Using this patch, this issue is fixed, emmc can be detected correctly.
 
 
 Signed-off-by: Peng Fan peng@freescale.com
 ---
 drivers/mmc/mmc.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)
 


Thanks for the patch, but Andrew’s patchset is more complete.

I’ll pick up his fix instead.

Regards

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 6/6] mmc: Fix splitting device initialization

[Pantelis Antoniou]

Hi Andrew,

 On Mar 19, 2015, at 14:44 , Andrew Gabbasov andrew_gabba...@mentor.com 
 wrote:
 
 Starting part of device initialization sets the init_in_progress flag
 only if the MMC card did not yet come to ready state and needs to continue
 polling. If the card is SD or if the MMC card became ready quickly,
 the flag is not set and (if using pre-initialization) the starting
 phase will be re-executed from mmc_init function.
 
 Set the init_in_progress flag in all non-error cases. Also, move flags
 setting statements around so that the flags are not set in error paths.
 Also, IN_PROGRESS return status becomes unnecessary, so get rid of it.
 
 Signed-off-by: Andrew Gabbasov andrew_gabba...@mentor.com
 ---
 drivers/mmc/mmc.c | 16 
 include/mmc.h |  3 +--
 2 files changed, 9 insertions(+), 10 deletions(-)
 
 diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
 index b81533c..31f8647 100644
 --- a/drivers/mmc/mmc.c
 +++ b/drivers/mmc/mmc.c
 @@ -387,7 +387,6 @@ static int mmc_send_op_cond(struct mmc *mmc)
   mmc_go_idle(mmc);
 
   /* Asking to the card its capabilities */
 - mmc-op_cond_pending = 1;
   for (i = 0; i  2; i++) {
   err = mmc_send_op_cond_iter(mmc, i != 0);
   if (err)
 @@ -395,9 +394,10 @@ static int mmc_send_op_cond(struct mmc *mmc)
 
   /* exit if not busy (flag seems to be inverted) */
   if (mmc-ocr  OCR_BUSY)
 - return 0;
 + break;
   }
 - return IN_PROGRESS;
 + mmc-op_cond_pending = 1;
 + return 0;
 }
 
 static int mmc_complete_op_cond(struct mmc *mmc)
 @@ -1627,7 +1627,7 @@ int mmc_start_init(struct mmc *mmc)
   if (err == TIMEOUT) {
   err = mmc_send_op_cond(mmc);
 
 - if (err  err != IN_PROGRESS) {
 + if (err) {
 #if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
   printf(Card did not respond to voltage select!\n);
 #endif
 @@ -1635,7 +1635,7 @@ int mmc_start_init(struct mmc *mmc)
   }
   }
 
 - if (err == IN_PROGRESS)
 + if (!err)
   mmc-init_in_progress = 1;
 
   return err;
 @@ -1645,6 +1645,7 @@ static int mmc_complete_init(struct mmc *mmc)
 {
   int err = 0;
 
 + mmc-init_in_progress = 0;
   if (mmc-op_cond_pending)
   err = mmc_complete_op_cond(mmc);
 
 @@ -1654,13 +1655,12 @@ static int mmc_complete_init(struct mmc *mmc)
   mmc-has_init = 0;
   else
   mmc-has_init = 1;
 - mmc-init_in_progress = 0;
   return err;
 }
 
 int mmc_init(struct mmc *mmc)
 {
 - int err = IN_PROGRESS;
 + int err = 0;
   unsigned start;
 
   if (mmc-has_init)
 @@ -1671,7 +1671,7 @@ int mmc_init(struct mmc *mmc)
   if (!mmc-init_in_progress)
   err = mmc_start_init(mmc);
 
 - if (!err || err == IN_PROGRESS)
 + if (!err)
   err = mmc_complete_init(mmc);
   debug(%s: %d, time %lu\n, __func__, err, get_timer(start));
   return err;
 diff --git a/include/mmc.h b/include/mmc.h
 index 644e3fa..fbcbe35 100644
 --- a/include/mmc.h
 +++ b/include/mmc.h
 @@ -70,8 +70,7 @@
 #define UNUSABLE_ERR  -17 /* Unusable Card */
 #define COMM_ERR  -18 /* Communications Error */
 #define TIMEOUT   -19
 -#define IN_PROGRESS  -20 /* operation is in progress */
 -#define SWITCH_ERR   -21 /* Card reports failure to switch mode */
 +#define SWITCH_ERR   -20 /* Card reports failure to switch mode */
 
 #define MMC_CMD_GO_IDLE_STATE 0
 #define MMC_CMD_SEND_OP_COND  1
 -- 
 2.1.0

Thanks, Applied.

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR only if it is still not ready

[Pantelis Antoniou]

Hi Andrew,

 On Mar 24, 2015, at 21:02 , Andrew Gabbasov andrew_gabba...@mentor.com 
 wrote:
 
 From: Troy Kisky [mailto:troy.ki...@boundarydevices.com]
 Sent: Tuesday, March 24, 2015 9:03 PM
 To: Gabbasov, Andrew; peng@freescale.com; u-boot@lists.denx.de
 Cc: Eric Nelson
 Subject: Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR
 only if it is still not ready
 
 On 3/24/2015 9:33 AM, Andrew Gabbasov wrote:
 Hi Troy,
 
 From: Troy Kisky [mailto:troy.ki...@boundarydevices.com]
 Sent: Monday, March 23, 2015 11:09 PM
 To: Gabbasov, Andrew; peng@freescale.com; u-boot@lists.denx.de
 Cc: Eric Nelson
 Subject: Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for
 OCR only if it is still not ready
 
 On 3/23/2015 12:38 AM, Andrew Gabbasov wrote:
 Hi Troy,
 
 From: Troy Kisky [mailto:troy.ki...@boundarydevices.com]
 Sent: Friday, March 20, 2015 9:39 PM
 To: peng@freescale.com; Gabbasov, Andrew; u-boot@lists.denx.de
 Cc: Eric Nelson
 Subject: Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card
 for OCR only if it is still not ready
 
 [skipped]
 
 Here's another patch that solves the problem a little earlier. It
 has this disadvantage of being slightly bigger, though it makes the
 code look
 better.
 
 https://github.com/boundarydevices/u-boot-imx6/commit/c0260ca
 
 
 I have a couple of doubts regarding that patch.
 
 First, my personal taste objects to such duplicating of the code (I
 mean setting of version, ocr, rca, etc fields of mmc structure).
 If we'll have to change or add anything to these settings, we'll
 have to make the same change in 2 different place, which is
 error-prone and extremely inconvenient from maintenance point of view.
 
 Second, what about SPI mode? Doesn't this patch skip retrieving of
 OCR register with a special command for SPI host case (thus setting
 ocr field incorrectly), if the card comes to ready state with the
 first attempt?
 
 That's a good argument for a subroutine to be doing that work instead
 of
 in two
 places.
 
 In some sense the second function of these two
 (mmc_complete_op_cond()) is exactly such subroutine ;-) It is doing
 this work of final settings and actions after making OCR polling.
 Although completing the polling itself in some cases too.
 Actually, it seems that introducing of one more service function would
 make the code a little too chopped into too small pieces, and also
 further less similar to SD (as opposed to MMC) case.
 
 Thanks.
 
 
 I've already said that I'm fine with any patch that fixes the problem, so
 there is
 no need to convince me of anything. I just wanted to show that setting the
 pending flag, when the command is actually complete, does not make a lot
 of
 sense.
 
 I absolutely agree. In fact, this flag in current implementation just
 indicates
 the branch that the MMC card case is being processed. If the version field,
 differing SD and MMC cases, would be set a little earlier, for example,
 directly in mmc_start_init(), we could just use !IS_SD() instead of this
 pending flag. And thinking further, it's not quite clear why the splitting
 of OCR polling was done for MMC case only, but not for SD too.
 So, there is still the room for further improving the code, may be even
 some reorganizing, but I had to stop somewhere, unless there is
 the direct necessity ;-)
 

Your patch fixes the current problem nicely. There is a lot of cruft around, 
we’ll
get around looking it at some point in the future (yeah, maybe) :)

Thanks for the good work, it’s fine as it is right now.

 Thanks.
 
 Best regards,
 Andrew
 

Regards

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR only if it is still not ready

[Pantelis Antoniou]

Hi Andrew,

 On Mar 19, 2015, at 14:44 , Andrew Gabbasov andrew_gabba...@mentor.com 
 wrote:
 
 Some MMC cards come to ready state quite quickly, so that the respective
 flag appears to be set in mmc_send_op_cond already. In this case trying
 to continue polling the card with CMD1 in mmc_complete_op_cond is incorrect
 and may lead to unpredictable results. So check the flag before polling
 and skip it appropriately.
 
 Signed-off-by: Andrew Gabbasov andrew_gabba...@mentor.com
 ---
 drivers/mmc/mmc.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)
 
 diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
 index d073d79..42af47c 100644
 --- a/drivers/mmc/mmc.c
 +++ b/drivers/mmc/mmc.c
 @@ -403,15 +403,17 @@ static int mmc_complete_op_cond(struct mmc *mmc)
   int err;
 
   mmc-op_cond_pending = 0;
 - start = get_timer(0);
 - do {
 - err = mmc_send_op_cond_iter(mmc, 1);
 - if (err)
 - return err;
 - if (get_timer(start)  timeout)
 - return UNUSABLE_ERR;
 - udelay(100);
 - } while (!(mmc-ocr  OCR_BUSY));
 + if (!(mmc-ocr  OCR_BUSY)) {
 + start = get_timer(0);
 + do {
 + err = mmc_send_op_cond_iter(mmc, 1);
 + if (err)
 + return err;
 + if (get_timer(start)  timeout)
 + return UNUSABLE_ERR;
 + udelay(100);
 + } while (!(mmc-ocr  OCR_BUSY));
 + }
 
   if (mmc_host_is_spi(mmc)) { /* read OCR for spi */
   cmd.cmdidx = MMC_CMD_SPI_READ_OCR;
 -- 
 2.1.0
 


Thanks, Applied.

— Pantelis

PS. Peng, I’m picking up this instead of your patch.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/6] mmc: Restructure polling loops to avoid extra delays

[Pantelis Antoniou]

Hi Andrew,

 On Mar 19, 2015, at 14:44 , Andrew Gabbasov andrew_gabba...@mentor.com 
 wrote:
 
 The polling loops in sd_send_op_cond and mmc_complete_op_cond functions
 check the ready flag state at the end of the loop, that is after executing
 a delay inside the loop, which, in case of exiting with no error,
 is not needed. Also, one of these loops, as well as the loop
 in mmc_send_status, have the delay just before exiting on timeout
 conditions.
 
 Restructure all these loops to check the respective conditions before making
 a delay for the next loop pass, and to appropriately exit without the delay.
 
 Signed-off-by: Andrew Gabbasov andrew_gabba...@mentor.com
 ---
 drivers/mmc/mmc.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)
 
 diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
 index 42af47c..b81533c 100644
 --- a/drivers/mmc/mmc.c
 +++ b/drivers/mmc/mmc.c
 @@ -118,7 +118,7 @@ int mmc_send_status(struct mmc *mmc, int timeout)
   if (!mmc_host_is_spi(mmc))
   cmd.cmdarg = mmc-rca  16;
 
 - do {
 + while (1) {
   err = mmc_send_cmd(mmc, cmd, NULL);
   if (!err) {
   if ((cmd.response[0]  MMC_STATUS_RDY_FOR_DATA) 
 @@ -135,9 +135,11 @@ int mmc_send_status(struct mmc *mmc, int timeout)
   } else if (--retries  0)
   return err;
 
 - udelay(1000);
 + if (timeout-- = 0)
 + break;
 
 - } while (timeout--);
 + udelay(1000);
 + }
 
 #ifdef CONFIG_MMC_TRACE
   status = (cmd.response[0]  MMC_STATUS_CURR_STATE)  9;
 @@ -291,7 +293,7 @@ static int sd_send_op_cond(struct mmc *mmc)
   int err;
   struct mmc_cmd cmd;
 
 - do {
 + while (1) {
   cmd.cmdidx = MMC_CMD_APP_CMD;
   cmd.resp_type = MMC_RSP_R1;
   cmd.cmdarg = 0;
 @@ -322,11 +324,14 @@ static int sd_send_op_cond(struct mmc *mmc)
   if (err)
   return err;
 
 - udelay(1000);
 - } while ((!(cmd.response[0]  OCR_BUSY))  timeout--);
 + if (cmd.response[0]  OCR_BUSY)
 + break;
 
 - if (timeout = 0)
 - return UNUSABLE_ERR;
 + if (timeout-- = 0)
 + return UNUSABLE_ERR;
 +
 + udelay(1000);
 + }
 
   if (mmc-version != SD_VERSION_2)
   mmc-version = SD_VERSION_1_0;
 @@ -405,14 +410,16 @@ static int mmc_complete_op_cond(struct mmc *mmc)
   mmc-op_cond_pending = 0;
   if (!(mmc-ocr  OCR_BUSY)) {
   start = get_timer(0);
 - do {
 + while (1) {
   err = mmc_send_op_cond_iter(mmc, 1);
   if (err)
   return err;
 + if (mmc-ocr  OCR_BUSY)
 + break;
   if (get_timer(start)  timeout)
   return UNUSABLE_ERR;
   udelay(100);
 - } while (!(mmc-ocr  OCR_BUSY));
 + }
   }
 
   if (mmc_host_is_spi(mmc)) { /* read OCR for spi */
 -- 
 2.1.0

Thanks, Applied.

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 23/24] tegra: mmc: Set the removable flag correctly

[Pantelis Antoniou]

Hi Simon,

 On May 4, 2015, at 20:31 , Simon Glass s...@chromium.org wrote:
 
 If the mmc device is non-removable (as indicated by the device tree), set
 the flag so that users of the device know.
 
 Signed-off-by: Simon Glass s...@chromium.org
 ---
 
 drivers/mmc/tegra_mmc.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
 index 2cd8cf1..5c9c54a 100644
 --- a/drivers/mmc/tegra_mmc.c
 +++ b/drivers/mmc/tegra_mmc.c
 @@ -528,7 +528,7 @@ static const struct mmc_ops tegra_mmc_ops = {
   .getcd  = tegra_mmc_getcd,
 };
 
 -static int do_mmc_init(int dev_index)
 +static int do_mmc_init(int dev_index, bool removable)
 {
   struct mmc_host *host;
   struct mmc *mmc;
 @@ -573,6 +573,7 @@ static int do_mmc_init(int dev_index)
   host-cfg.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 
   mmc = mmc_create(host-cfg, host);
 + mmc-block_dev.removable = removable;
   if (mmc == NULL)
   return -1;
 
 @@ -586,7 +587,8 @@ static int do_mmc_init(int dev_index)
  * @param nodeDevice index (0-3)
  * @param hostStructure to fill in (reg, width, mmc_id)
  */
 -static int mmc_get_config(const void *blob, int node, struct mmc_host *host)
 +static int mmc_get_config(const void *blob, int node, struct mmc_host *host,
 +   bool *removablep)
 {
   debug(%s: node = %d\n, __func__, node);
 
 @@ -619,6 +621,7 @@ static int mmc_get_config(const void *blob, int node, 
 struct mmc_host *host)
  GPIOD_IS_IN);
   gpio_request_by_name_nodev(blob, node, power-gpios, 0,
  host-pwr_gpio, GPIOD_IS_OUT);
 + *removablep = !fdtdec_get_bool(blob, node, non-removable);
 
   debug(%s: found controller at %p, width = %d, periph_id = %d\n,
   __func__, host-reg, host-width, host-mmc_id);
 @@ -636,6 +639,7 @@ static int mmc_get_config(const void *blob, int node, 
 struct mmc_host *host)
 static int process_nodes(const void *blob, int node_list[], int count)
 {
   struct mmc_host *host;
 + bool removable;
   int i, node;
 
   debug(%s: count = %d\n, __func__, count);
 @@ -649,11 +653,11 @@ static int process_nodes(const void *blob, int 
 node_list[], int count)
   host = mmc_host[i];
   host-id = i;
 
 - if (mmc_get_config(blob, node, host)) {
 + if (mmc_get_config(blob, node, host, removable)) {
   printf(%s: failed to decode dev %d\n, __func__, i);
   return -1;
   }
 - do_mmc_init(i);
 + do_mmc_init(i, removable);
   }
   return 0;
 }
 -- 
 2.2.0.rc0.207.ga3a616c
 

Applied, thanks.

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] mmc: bcm2835_sdhci: Use calloc to allocate bcm2835_sdhci_host

[Pantelis Antoniou]

Hi Alexander,

 On Apr 17, 2015, at 18:33 , Alexander Stein alexander...@web.de wrote:
 
 We need to clear the allocated memory explicitly as the included
 struct sdhci_host has function pointers. Those are compared to NULL to
 test if this (optional) feature is supported. Leaving them undefined let
 u-boot jump to arbitrary memory.
 
 Signed-off-by: Alexander Stein alexander...@web.de
 ---
 drivers/mmc/bcm2835_sdhci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c
 index 92f7d89..127dbe3 100644
 --- a/drivers/mmc/bcm2835_sdhci.c
 +++ b/drivers/mmc/bcm2835_sdhci.c
 @@ -154,9 +154,9 @@ int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq)
   struct bcm2835_sdhci_host *bcm_host;
   struct sdhci_host *host;
 
 - bcm_host = malloc(sizeof(*bcm_host));
 + bcm_host = calloc(1, sizeof(*bcm_host));
   if (!bcm_host) {
 - printf(sdhci_host malloc fail!\n);
 + printf(sdhci_host calloc fail!\n);
   return 1;
   }
 
 -- 
 2.3.5
 

Applied, Thanks.

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] ARM: mmc: bcm283x: Remove get_timer_us() from mmc driver

[Pantelis Antoniou]

Hi Marek,

 On May 4, 2015, at 23:54 , Marek Vasut ma...@denx.de wrote:
 
 The get_timer_us() function is something which is no longer
 existing in case we use generic timer framework, so replace
 it with get_timer().
 
 Signed-off-by: Marek Vasut ma...@denx.de
 Cc: Stephen Warren swar...@wwwdotorg.org
 Cc: Tyler Baker tyler.ba...@linaro.org
 ---
 drivers/mmc/bcm2835_sdhci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c
 index 4ec2968..0f81add 100644
 --- a/drivers/mmc/bcm2835_sdhci.c
 +++ b/drivers/mmc/bcm2835_sdhci.c
 @@ -69,11 +69,11 @@ static inline void bcm2835_sdhci_raw_writel(struct 
 sdhci_host *host, u32 val,
* (Which is just as well - otherwise we'd have to nobble the DMA engine
* too)
*/
 - while (get_timer_us(bcm_host-last_write)  bcm_host-twoticks_delay)
 + while (get_timer(bcm_host-last_write)  bcm_host-twoticks_delay)
   ;
 
   writel(val, host-ioaddr + reg);
 - bcm_host-last_write = get_timer_us(0);
 + bcm_host-last_write = get_timer(0);
 }
 
 static inline u32 bcm2835_sdhci_raw_readl(struct sdhci_host *host, int reg)
 -- 
 2.1.4

Applied, thanks.

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Pull request: u-boot-mmc 05052015

[Pantelis Antoniou]

Hi Tom,

The following changes since commit ace97d26176a3ebc9ec07738450de93eea35975c:

  Merge branch 'zynq' of git://www.denx.de/git/u-boot-microblaze (2015-04-29 
06:46:33 -0400)

are available in the git repository at:


  git://git.denx.de/u-boot-mmc.git master

for you to fetch changes up to 33fe2fb8df01647f97a7bce96a1c7781a7f6d253:

  ARM: mmc: bcm283x: Remove get_timer_us() from mmc driver (2015-05-05 12:29:42 
+0300)


Alexander Stein (1):
  mmc: bcm2835_sdhci: Use calloc to allocate bcm2835_sdhci_host

Andrew Gabbasov (6):
  mmc: Fix typo in MMC type checking macro
  mmc: Avoid extra duplicate entry in mmc device structure
  mmc: Do not pass external mmc_cmd structure to mmc_send_op_cond_iter()
  mmc: Continue polling MMC card for OCR only if it is still not ready
  mmc: Restructure polling loops to avoid extra delays
  mmc: Fix splitting device initialization

Kevin Liu (1):
  mmc: sdhci: add timeout setting for response busy command

Marek Vasut (1):
  ARM: mmc: bcm283x: Remove get_timer_us() from mmc driver

Rob Herring (1):
  mmc: remove the MMC_MODE_HC flag

Simon Glass (1):
  tegra: mmc: Set the removable flag correctly

Yangbo Lu (1):
  mmc: fsl_esdhc: update eMMC44 adapter card erase timeout

 drivers/mmc/bcm2835_sdhci.c |  8 
 drivers/mmc/dw_mmc.c|  2 +-
 drivers/mmc/fsl_esdhc.c |  6 +++---
 drivers/mmc/kona_sdhci.c|  1 -
 drivers/mmc/mmc.c   | 93 
+
 drivers/mmc/mvebu_mmc.c |  2 +-
 drivers/mmc/mxsmmc.c|  3 +--
 drivers/mmc/omap_hsmmc.c|  3 +--
 drivers/mmc/s3c_sdi.c   |  2 +-
 drivers/mmc/s5p_sdhci.c |  1 -
 drivers/mmc/sdhci.c |  2 ++
 drivers/mmc/sh_mmcif.c  |  2 +-
 drivers/mmc/sunxi_mmc.c |  2 +-
 drivers/mmc/tegra_mmc.c | 14 +-
 drivers/mmc/zynq_sdhci.c|  2 --
 include/mmc.h   |  9 +++--
 16 files changed, 77 insertions(+), 75 deletions(-)

Regards

— Pantelis


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mmc: remove the MMC_MODE_HC flag

[Pantelis Antoniou]

Hi Rob,

 On Mar 24, 2015, at 00:56 , Rob Herring r...@kernel.org wrote:
 
 High capacity support is not a host capability, but a device capability
 that is queried via the OCR. The flag in the operating conditions
 request argument can just be set unconditionally. This matches the Linux
 implementation.
 
 Signed-off-by: Rob Herring r...@kernel.org
 Cc: Pantelis Antoniou pa...@antoniou-consulting.com
 ---
 drivers/mmc/dw_mmc.c | 2 +-
 drivers/mmc/fsl_esdhc.c  | 2 +-
 drivers/mmc/kona_sdhci.c | 1 -
 drivers/mmc/mmc.c| 7 ++-
 drivers/mmc/mvebu_mmc.c  | 2 +-
 drivers/mmc/mxsmmc.c | 3 +--
 drivers/mmc/omap_hsmmc.c | 3 +--
 drivers/mmc/s3c_sdi.c| 2 +-
 drivers/mmc/s5p_sdhci.c  | 1 -
 drivers/mmc/sh_mmcif.c   | 2 +-
 drivers/mmc/sunxi_mmc.c  | 2 +-
 drivers/mmc/tegra_mmc.c  | 2 +-
 drivers/mmc/zynq_sdhci.c | 2 --
 include/mmc.h| 1 -
 14 files changed, 11 insertions(+), 21 deletions(-)
 
 diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
 index 76fa0b0..53a8aca 100644
 --- a/drivers/mmc/dw_mmc.c
 +++ b/drivers/mmc/dw_mmc.c
 @@ -388,7 +388,7 @@ int add_dwmci(struct dwmci_host *host, u32 max_clk, u32 
 min_clk)
   host-cfg.host_caps |= MMC_MODE_4BIT;
   host-cfg.host_caps = ~MMC_MODE_8BIT;
   }
 - host-cfg.host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz | MMC_MODE_HC;
 + host-cfg.host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
 
   host-cfg.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 
 diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
 index db4d251..f99ad47 100644
 --- a/drivers/mmc/fsl_esdhc.c
 +++ b/drivers/mmc/fsl_esdhc.c
 @@ -620,7 +620,7 @@ int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg 
 *cfg)
   return -1;
   }
 
 - cfg-cfg.host_caps = MMC_MODE_4BIT | MMC_MODE_8BIT | MMC_MODE_HC;
 + cfg-cfg.host_caps = MMC_MODE_4BIT | MMC_MODE_8BIT;
 #ifdef CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE
   cfg-cfg.host_caps |= MMC_MODE_DDR_52MHz;
 #endif
 diff --git a/drivers/mmc/kona_sdhci.c b/drivers/mmc/kona_sdhci.c
 index f804f4c..3653d00 100644
 --- a/drivers/mmc/kona_sdhci.c
 +++ b/drivers/mmc/kona_sdhci.c
 @@ -121,7 +121,6 @@ int kona_sdhci_init(int dev_index, u32 min_clk, u32 
 quirks)
   host-name = kona-sdhci;
   host-ioaddr = reg_base;
   host-quirks = quirks;
 - host-host_caps = MMC_MODE_HC;
 
   if (init_kona_mmc_core(host)) {
   free(host);
 diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
 index a13769e..ea00753 100644
 --- a/drivers/mmc/mmc.c
 +++ b/drivers/mmc/mmc.c
 @@ -359,15 +359,12 @@ static int mmc_send_op_cond_iter(struct mmc *mmc, 
 struct mmc_cmd *cmd,
   cmd-cmdidx = MMC_CMD_SEND_OP_COND;
   cmd-resp_type = MMC_RSP_R3;
   cmd-cmdarg = 0;
 - if (use_arg  !mmc_host_is_spi(mmc)) {
 - cmd-cmdarg =
 + if (use_arg  !mmc_host_is_spi(mmc))
 + cmd-cmdarg = OCR_HCS |
   (mmc-cfg-voltages 
   (mmc-op_cond_response  OCR_VOLTAGE_MASK)) |
   (mmc-op_cond_response  OCR_ACCESS_MODE);
 
 - if (mmc-cfg-host_caps  MMC_MODE_HC)
 - cmd-cmdarg |= OCR_HCS;
 - }
   err = mmc_send_cmd(mmc, cmd, NULL);
   if (err)
   return err;
 diff --git a/drivers/mmc/mvebu_mmc.c b/drivers/mmc/mvebu_mmc.c
 index 8ca0904..056aef5 100644
 --- a/drivers/mmc/mvebu_mmc.c
 +++ b/drivers/mmc/mvebu_mmc.c
 @@ -418,7 +418,7 @@ static struct mmc_config mvebu_mmc_cfg = {
   .f_min  = MVEBU_MMC_BASE_FAST_CLOCK / MVEBU_MMC_BASE_DIV_MAX,
   .f_max  = MVEBU_MMC_CLOCKRATE_MAX,
   .voltages   = MMC_VDD_32_33 | MMC_VDD_33_34,
 - .host_caps  = MMC_MODE_4BIT | MMC_MODE_HS | MMC_MODE_HC |
 + .host_caps  = MMC_MODE_4BIT | MMC_MODE_HS |
 MMC_MODE_HS_52MHz,
   .part_type  = PART_TYPE_DOS,
   .b_max  = CONFIG_SYS_MMC_MAX_BLK_COUNT,
 diff --git a/drivers/mmc/mxsmmc.c b/drivers/mmc/mxsmmc.c
 index 2fa4eee..31fb3ab 100644
 --- a/drivers/mmc/mxsmmc.c
 +++ b/drivers/mmc/mxsmmc.c
 @@ -405,8 +405,7 @@ int mxsmmc_initialize(bd_t *bis, int id, int (*wp)(int), 
 int (*cd)(int))
   priv-cfg.voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
 
   priv-cfg.host_caps = MMC_MODE_4BIT | MMC_MODE_8BIT |
 -  MMC_MODE_HS_52MHz | MMC_MODE_HS |
 -  MMC_MODE_HC;
 +  MMC_MODE_HS_52MHz | MMC_MODE_HS;
 
   /*
* SSPCLK = 480 * 18 / 29 / 1 = 297.731 MHz
 diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
 index dc725cb..8238a7e 100644
 --- a/drivers/mmc/omap_hsmmc.c
 +++ b/drivers/mmc/omap_hsmmc.c
 @@ -651,8 +651,7 @@ int omap_mmc_init(int dev_index, uint host_caps_mask, 
 uint f_max, int cd_gpio,
   if (priv_data == NULL)
   return -1;
 
 - host_caps_val = MMC_MODE_4BIT | MMC_MODE_HS_52MHz | MMC_MODE_HS |
 -  MMC_MODE_HC;
 + host_caps_val = MMC_MODE_4BIT

Re: [U-Boot] [PATCH] mmc: sdhci: add timeout setting for response busy command

[Pantelis Antoniou]

Hi Rob,

 On Mar 24, 2015, at 00:57 , Rob Herring r...@kernel.org wrote:
 
 From: Kevin Liu kl...@marvell.com
 
 Timeout interrupt also work for response busy command(R1b) like
 cmd38/cmd6. So need to set it accordingly. Current code only
 set timeout for data command.
 
 Signed-off-by: Kevin Liu kl...@marvell.com
 Signed-off-by: Rob Herring r...@kernel.org
 Cc: Pantelis Antoniou pa...@antoniou-consulting.com
 ---
 drivers/mmc/sdhci.c | 2 ++
 1 file changed, 2 insertions(+)
 
 diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
 index 78e958e..8faeca3 100644
 --- a/drivers/mmc/sdhci.c
 +++ b/drivers/mmc/sdhci.c
 @@ -213,6 +213,8 @@ static int sdhci_send_command(struct mmc *mmc, struct 
 mmc_cmd *cmd,
   SDHCI_BLOCK_SIZE);
   sdhci_writew(host, data-blocks, SDHCI_BLOCK_COUNT);
   sdhci_writew(host, mode, SDHCI_TRANSFER_MODE);
 + } else if (cmd-resp_type  MMC_RSP_BUSY) {
 + sdhci_writeb(host, 0xe, SDHCI_TIMEOUT_CONTROL);
   }
 
   sdhci_writel(host, cmd-cmdarg, SDHCI_ARGUMENT);
 -- 
 2.1.0
 

Thanks, Applied.

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mmc: fsl_esdhc: update eMMC44 adapter card erase timeout

[Pantelis Antoniou]

Hi Yango,

 On Apr 15, 2015, at 05:13 , Yangbo Lu yangbo...@freescale.com wrote:
 
 Freescale eMMC44 adapter card uses Micron N2M400FDB311A3CF eMMC
 memory. According to the silicon datasheet, secure erase timeout
 is 600ms. So increase erase timeout value from 250ms to 600ms.
 
 Signed-off-by: Yangbo Lu yangbo...@freescale.com
 Cc: York Sun york...@freescale.com
 ---
 drivers/mmc/fsl_esdhc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
 index f5d2ccb..e879fc0 100644
 --- a/drivers/mmc/fsl_esdhc.c
 +++ b/drivers/mmc/fsl_esdhc.c
 @@ -344,9 +344,9 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, 
 struct mmc_data *data)
 
   /* Workaround for ESDHC errata ENGcm03648 */
   if (!data  (cmd-resp_type  MMC_RSP_BUSY)) {
 - int timeout = 2500;
 + int timeout = 6000;
 
 - /* Poll on DATA0 line for cmd with busy signal for 250 ms */
 + /* Poll on DATA0 line for cmd with busy signal for 600 ms */
   while (timeout  0  !(esdhc_read32(regs-prsstat) 
   PRSSTAT_DAT0)) {
   udelay(100);
 -- 
 2.1.0.27.g96db324

Applied, Thanks.

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mmc: fix OCR Polling

[Pantelis Antoniou]

Hi Andrew, Peng,

 On Mar 23, 2015, at 01:23 , Andrew Gabbasov andrew_gabba...@mentor.com 
 wrote:
 
 Hi Peng,
 
 From: Peng Fan [mailto:peng@freescale.com]
 Sent: Saturday, March 21, 2015 1:34 PM
 To: Gabbasov, Andrew; u-boot@lists.denx.de
 Subject: Re: [U-Boot] [PATCH] mmc: fix OCR Polling
 
 [skipped]
 
 After this patch, if the busy flag is indeed already set (so that the
 loop body is not executed), and it is not an SPI case
 (mmc_host_is_spi(mmc) is false), the cmd structure (which is local
 to mmc_complete_op_cond() function) is left uninitialized, and using
 cmd.response[0] later in the function becomes incorrect. And the OCR
 register value and the high capacity flag may be set incorrectly.
 Yeah. you are right.
 Maybe the following piece of code should be added to replace mmc-ocr =
 cmd.response[0]:
 
 if (mmc_host_is_spi(mmc))
 mmc-ocr = cmd.response[0];
 else
 mmc-ocr = mmc-op_cond_response;
 
 Thanks for correcting me.
 
 Well, there can be several ways to correct that. The easiest would be
 something
 similar to what you propose, but, just to avoid extra if, we could add
mmc-op_cond_response = cmd.response[0];
 to the end of existing if(mmc_host_is_spi(mmc)) and change
mmc-ocr = cmd.response[0];
 to
mmc-ocr = mmc-op_cond_response;
 at the end of function. Since op_cond_response should be already set from
 the function beginning, this can be used immediately.
 
 And, going further, since op_cond_response is actually the same contents
 as mmc-ocr, we could combine them and use mmc-ocr at once, from
 the beginning of polling loops. This is a little more complex, but makes
 the code cleaner. This is what is done in one of other patches in my series
 ;-)
 

This does seem like a case where a simple accessor structure would help until
we figure out how to process.

Something like mmc_get_ocr() as a private API perhaps?

 Thanks.
 
 Best regards,
 Andrew
 

Regards

— Pantelis

 
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mmc: sdhci: don't clobber adjacent registers

[Pantelis Antoniou]

Hi Matt,

 On Feb 23, 2015, at 23:56 , Matt Reimer mrei...@sdgsystems.com wrote:
 
 SDHCI_HOST_CONTROL is a byte-sized register, so don't write to it
 as if it were a long, as that would result in clobbering the three
 registers following.
 
 Signed-off-by: Matt Reimer mrei...@sdgsystems.com
 ---
 drivers/mmc/sdhci.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
 index 82d7984..1f8917b 100644
 --- a/drivers/mmc/sdhci.c
 +++ b/drivers/mmc/sdhci.c
 @@ -412,7 +412,7 @@ static int sdhci_init(struct mmc *mmc)
   if (host-quirks  SDHCI_QUIRK_NO_CD) {
   unsigned int status;
 
 - sdhci_writel(host, SDHCI_CTRL_CD_TEST_INS | SDHCI_CTRL_CD_TEST,
 + sdhci_writeb(host, SDHCI_CTRL_CD_TEST_INS | SDHCI_CTRL_CD_TEST,
   SDHCI_HOST_CONTROL);
 
   status = sdhci_readl(host, SDHCI_PRESENT_STATE);
 -- 
 1.7.9.5
 

Thanks, applied.

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mv_sdhci: fix warnings on 64-bit builds

[Pantelis Antoniou]

Hi Rob,

 On Mar 17, 2015, at 22:46 , Rob Herring r...@kernel.org wrote:
 
 Change addresses to unsigned long to be compatible with 64-bit builds.
 Regardless of fixing warnings, the device is still only 32-bit capable.
 
 Signed-off-by: Rob Herring r...@kernel.org
 Cc: Pantelis Antoniou pa...@antoniou-consulting.com
 ---
 drivers/mmc/mv_sdhci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
 index 63e1f90..75fa014 100644
 --- a/drivers/mmc/mv_sdhci.c
 +++ b/drivers/mmc/mv_sdhci.c
 @@ -12,7 +12,7 @@ static struct sdhci_ops mv_ops;
 static inline void mv_sdhci_writeb(struct sdhci_host *host, u8 val, int reg)
 {
   struct mmc *mmc = host-mmc;
 - u32 ata = (u32)host-ioaddr + SD_CE_ATA_2;
 + u32 ata = (unsigned long)host-ioaddr + SD_CE_ATA_2;
 
   if (!IS_SD(mmc)  reg == SDHCI_HOST_CONTROL) {
   if (mmc-bus_width == 8)
 @@ -30,7 +30,7 @@ static inline void mv_sdhci_writeb(struct sdhci_host *host, 
 u8 val, int reg)
 #endif /* CONFIG_MMC_SDHCI_IO_ACCESSORS */
 
 static char *MVSDH_NAME = mv_sdh;
 -int mv_sdh_init(u32 regbase, u32 max_clk, u32 min_clk, u32 quirks)
 +int mv_sdh_init(unsigned long regbase, u32 max_clk, u32 min_clk, u32 quirks)
 {
   struct sdhci_host *host = NULL;
   host = (struct sdhci_host *)malloc(sizeof(struct sdhci_host));
 -- 
 2.1.0
 

Thanks, applied.

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sdhci: fix warnings on 64-bit builds

[Pantelis Antoniou]

Hi Rob,

 On Mar 17, 2015, at 22:46 , Rob Herring r...@kernel.org wrote:
 
 Change addresses to unsigned long to be compatible with 64-bit builds.
 Regardless of fixing warnings, the device is still only 32-bit capable.
 
 Signed-off-by: Rob Herring r...@kernel.org
 Cc: Pantelis Antoniou pa...@antoniou-consulting.com
 ---
 drivers/mmc/sdhci.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
 index 82d7984..2d92204 100644
 --- a/drivers/mmc/sdhci.c
 +++ b/drivers/mmc/sdhci.c
 @@ -194,13 +194,13 @@ static int sdhci_send_command(struct mmc *mmc, struct 
 mmc_cmd *cmd,
 
 #ifdef CONFIG_MMC_SDMA
   if (data-flags == MMC_DATA_READ)
 - start_addr = (unsigned int)data-dest;
 + start_addr = (unsigned long)data-dest;
   else
 - start_addr = (unsigned int)data-src;
 + start_addr = (unsigned long)data-src;
   if ((host-quirks  SDHCI_QUIRK_32BIT_DMA_ADDR) 
   (start_addr  0x7) != 0x0) {
   is_aligned = 0;
 - start_addr = (unsigned int)aligned_buffer;
 + start_addr = (unsigned long)aligned_buffer;
   if (data-flags != MMC_DATA_READ)
   memcpy(aligned_buffer, data-src, trans_bytes);
   }
 -- 
 2.1.0
 

Thanks, applied.

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Pull request: u-boot-mmc 18032015

[Pantelis Antoniou]

Hi Tom,

Only bug fixes for now, rather uneventful.

The following changes since commit 3231e364bf8426a9c8fd5158fe2d155ae7b9:

  mmc: fsl_esdhc fix register offset (2015-03-17 09:09:47 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-mmc.git master

for you to fetch changes up to 3a48944bc9a7455fec97e9df74c3d5bb600d3d7c:

  mv_sdhci: fix warnings on 64-bit builds (2015-03-18 09:56:17 +0200)


Matt Reimer (2):
  mmc: s5p: properly mask SELBASECLK
  mmc: sdhci: don't clobber adjacent registers

Rob Herring (2):
  sdhci: fix warnings on 64-bit builds
  mv_sdhci: fix warnings on 64-bit builds

 drivers/mmc/mv_sdhci.c  | 4 ++--
 drivers/mmc/s5p_sdhci.c | 2 +-
 drivers/mmc/sdhci.c | 8 
 3 files changed, 7 insertions(+), 7 deletions(-)

Regards

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mmc: s5p: properly mask SELBASECLK

[Pantelis Antoniou]

Hi Matt,

 On Feb 23, 2015, at 23:52 , Matt Reimer mrei...@sdgsystems.com wrote:
 
 Properly mask SELBASECLK by using an actual mask rather than the
 number of bits to shift in order to create the mask.
 
 Signed-off-by: Matt Reimer mrei...@sdgsystems.com
 ---
 drivers/mmc/s5p_sdhci.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/mmc/s5p_sdhci.c b/drivers/mmc/s5p_sdhci.c
 index 3899372..0eec731 100644
 --- a/drivers/mmc/s5p_sdhci.c
 +++ b/drivers/mmc/s5p_sdhci.c
 @@ -30,7 +30,7 @@ static void s5p_sdhci_set_control_reg(struct sdhci_host 
 *host)
   sdhci_writel(host, SDHCI_CTRL4_DRIVE_MASK(0x3), SDHCI_CONTROL4);
 
   val = sdhci_readl(host, SDHCI_CONTROL2);
 - val = SDHCI_CTRL2_SELBASECLK_SHIFT;
 + val = SDHCI_CTRL2_SELBASECLK_MASK(3);
 
   val |=  SDHCI_CTRL2_ENSTAASYNCCLR |
   SDHCI_CTRL2_ENCMDCNFMSK |
 -- 
 1.7.9.5
 

Thanks, applied.

— Pantelis

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot