* [PATCH 1/5] x86: Use multiple images
2020-09-04 1:28 [PATCH 0/5] edison: Support for writing an xFSTK image Simon Glass
@ 2020-09-04 1:28 ` Simon Glass
2020-09-04 9:30 ` Andy Shevchenko
2020-09-04 1:28 ` [PATCH 2/5] binman: Show an error when a file is missing Simon Glass
` (5 subsequent siblings)
6 siblings, 1 reply; 26+ messages in thread
From: Simon Glass @ 2020-09-04 1:28 UTC (permalink / raw)
To: u-boot
We already use binman's 'multiple-images' feature with Chrome OS and we
want to use it for Edison. There is no real down-side.
Adjust x86 to always use multiple-images.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
arch/x86/dts/u-boot.dtsi | 7 -------
1 file changed, 7 deletions(-)
diff --git a/arch/x86/dts/u-boot.dtsi b/arch/x86/dts/u-boot.dtsi
index fa8106c8b8c..90badcc15c9 100644
--- a/arch/x86/dts/u-boot.dtsi
+++ b/arch/x86/dts/u-boot.dtsi
@@ -6,7 +6,6 @@
#include <config.h>
-#ifdef CONFIG_CHROMEOS
/ {
binman {
multiple-images;
@@ -14,12 +13,6 @@
};
};
};
-#else
-/ {
- rom: binman {
- };
-};
-#endif
#ifdef CONFIG_ROM_SIZE
&rom {
--
2.28.0.526.ge36021eeef-goog
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH 1/5] x86: Use multiple images
2020-09-04 1:28 ` [PATCH 1/5] x86: Use multiple images Simon Glass
@ 2020-09-04 9:30 ` Andy Shevchenko
0 siblings, 0 replies; 26+ messages in thread
From: Andy Shevchenko @ 2020-09-04 9:30 UTC (permalink / raw)
To: u-boot
On Thu, Sep 03, 2020 at 07:28:52PM -0600, Simon Glass wrote:
> We already use binman's 'multiple-images' feature with Chrome OS and we
> want to use it for Edison. There is no real down-side.
>
> Adjust x86 to always use multiple-images.
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> arch/x86/dts/u-boot.dtsi | 7 -------
> 1 file changed, 7 deletions(-)
>
> diff --git a/arch/x86/dts/u-boot.dtsi b/arch/x86/dts/u-boot.dtsi
> index fa8106c8b8c..90badcc15c9 100644
> --- a/arch/x86/dts/u-boot.dtsi
> +++ b/arch/x86/dts/u-boot.dtsi
> @@ -6,7 +6,6 @@
>
> #include <config.h>
>
> -#ifdef CONFIG_CHROMEOS
> / {
> binman {
> multiple-images;
> @@ -14,12 +13,6 @@
> };
> };
> };
> -#else
> -/ {
> - rom: binman {
> - };
> -};
> -#endif
>
> #ifdef CONFIG_ROM_SIZE
> &rom {
> --
> 2.28.0.526.ge36021eeef-goog
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 2/5] binman: Show an error when a file is missing
2020-09-04 1:28 [PATCH 0/5] edison: Support for writing an xFSTK image Simon Glass
2020-09-04 1:28 ` [PATCH 1/5] x86: Use multiple images Simon Glass
@ 2020-09-04 1:28 ` Simon Glass
2020-09-04 9:33 ` Andy Shevchenko
2020-09-04 1:28 ` [PATCH 3/5] binman: Support adding a U-Boot environment Simon Glass
` (4 subsequent siblings)
6 siblings, 1 reply; 26+ messages in thread
From: Simon Glass @ 2020-09-04 1:28 UTC (permalink / raw)
To: u-boot
The recent support for missing external binaries does not show an error
message when a file is genuinely missing (i.e. it is missing but not
marked as 'external'). This means that when -m is passed to binman, it
will never report a missing file.
Fix this and add a test.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
tools/binman/etype/blob.py | 7 ++++---
tools/binman/ftest.py | 7 +++++++
tools/binman/test/173_missing_blob.dts | 14 ++++++++++++++
3 files changed, 25 insertions(+), 3 deletions(-)
create mode 100644 tools/binman/test/173_missing_blob.dts
diff --git a/tools/binman/etype/blob.py b/tools/binman/etype/blob.py
index c5f97c85a38..66cf243976e 100644
--- a/tools/binman/etype/blob.py
+++ b/tools/binman/etype/blob.py
@@ -37,13 +37,14 @@ class Entry_blob(Entry):
def ObtainContents(self):
self._filename = self.GetDefaultFilename()
- self._pathname = tools.GetInputFilename(self._filename,
- self.section.GetAllowMissing())
+ self._pathname = tools.GetInputFilename(
+ self._filename, self.external and self.section.GetAllowMissing())
# Allow the file to be missing
- if self.external and not self._pathname:
+ if not self._pathname:
self.SetContents(b'')
self.missing = True
return True
+
self.ReadBlobContents()
return True
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 95b17d0b749..91225459162 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -3708,5 +3708,12 @@ class TestFunctional(unittest.TestCase):
self.assertIn('Wibble test', err)
self.assertIn('Another test', err)
+ def testMissingBlob(self):
+ """Test handling of a blob containing a missing file"""
+ with self.assertRaises(ValueError) as e:
+ self._DoTestFile('173_missing_blob.dts', allow_missing=True)
+ self.assertIn("Filename 'missing' not found in input path",
+ str(e.exception))
+
if __name__ == "__main__":
unittest.main()
diff --git a/tools/binman/test/173_missing_blob.dts b/tools/binman/test/173_missing_blob.dts
new file mode 100644
index 00000000000..ffb655a1cb4
--- /dev/null
+++ b/tools/binman/test/173_missing_blob.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ binman {
+ blob {
+ filename = "missing";
+ };
+ };
+};
--
2.28.0.526.ge36021eeef-goog
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH 2/5] binman: Show an error when a file is missing
2020-09-04 1:28 ` [PATCH 2/5] binman: Show an error when a file is missing Simon Glass
@ 2020-09-04 9:33 ` Andy Shevchenko
2020-09-07 1:43 ` Simon Glass
0 siblings, 1 reply; 26+ messages in thread
From: Andy Shevchenko @ 2020-09-04 9:33 UTC (permalink / raw)
To: u-boot
On Thu, Sep 03, 2020 at 07:28:53PM -0600, Simon Glass wrote:
> The recent support for missing external binaries does not show an error
> message when a file is genuinely missing (i.e. it is missing but not
> marked as 'external'). This means that when -m is passed to binman, it
> will never report a missing file.
>
> Fix this and add a test.
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
One note below.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> tools/binman/etype/blob.py | 7 ++++---
> tools/binman/ftest.py | 7 +++++++
> tools/binman/test/173_missing_blob.dts | 14 ++++++++++++++
> 3 files changed, 25 insertions(+), 3 deletions(-)
> create mode 100644 tools/binman/test/173_missing_blob.dts
>
> diff --git a/tools/binman/etype/blob.py b/tools/binman/etype/blob.py
> index c5f97c85a38..66cf243976e 100644
> --- a/tools/binman/etype/blob.py
> +++ b/tools/binman/etype/blob.py
> @@ -37,13 +37,14 @@ class Entry_blob(Entry):
>
> def ObtainContents(self):
> self._filename = self.GetDefaultFilename()
> - self._pathname = tools.GetInputFilename(self._filename,
> - self.section.GetAllowMissing())
> + self._pathname = tools.GetInputFilename(
> + self._filename, self.external and self.section.GetAllowMissing())
I hope you know that 'and' has a bit different semantics in Python than in C for example.
And why to move first parameter to new line?
> # Allow the file to be missing
> - if self.external and not self._pathname:
> + if not self._pathname:
> self.SetContents(b'')
> self.missing = True
> return True
> +
> self.ReadBlobContents()
> return True
>
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> index 95b17d0b749..91225459162 100644
> --- a/tools/binman/ftest.py
> +++ b/tools/binman/ftest.py
> @@ -3708,5 +3708,12 @@ class TestFunctional(unittest.TestCase):
> self.assertIn('Wibble test', err)
> self.assertIn('Another test', err)
>
> + def testMissingBlob(self):
> + """Test handling of a blob containing a missing file"""
> + with self.assertRaises(ValueError) as e:
> + self._DoTestFile('173_missing_blob.dts', allow_missing=True)
> + self.assertIn("Filename 'missing' not found in input path",
> + str(e.exception))
> +
> if __name__ == "__main__":
> unittest.main()
> diff --git a/tools/binman/test/173_missing_blob.dts b/tools/binman/test/173_missing_blob.dts
> new file mode 100644
> index 00000000000..ffb655a1cb4
> --- /dev/null
> +++ b/tools/binman/test/173_missing_blob.dts
> @@ -0,0 +1,14 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/dts-v1/;
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + binman {
> + blob {
> + filename = "missing";
> + };
> + };
> +};
> --
> 2.28.0.526.ge36021eeef-goog
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 2/5] binman: Show an error when a file is missing
2020-09-04 9:33 ` Andy Shevchenko
@ 2020-09-07 1:43 ` Simon Glass
2020-09-07 9:05 ` Andy Shevchenko
0 siblings, 1 reply; 26+ messages in thread
From: Simon Glass @ 2020-09-07 1:43 UTC (permalink / raw)
To: u-boot
Hi Andy,
On Fri, 4 Sep 2020 at 03:33, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Thu, Sep 03, 2020 at 07:28:53PM -0600, Simon Glass wrote:
> > The recent support for missing external binaries does not show an error
> > message when a file is genuinely missing (i.e. it is missing but not
> > marked as 'external'). This means that when -m is passed to binman, it
> > will never report a missing file.
> >
> > Fix this and add a test.
>
> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> One note below.
>
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > tools/binman/etype/blob.py | 7 ++++---
> > tools/binman/ftest.py | 7 +++++++
> > tools/binman/test/173_missing_blob.dts | 14 ++++++++++++++
> > 3 files changed, 25 insertions(+), 3 deletions(-)
> > create mode 100644 tools/binman/test/173_missing_blob.dts
> >
> > diff --git a/tools/binman/etype/blob.py b/tools/binman/etype/blob.py
> > index c5f97c85a38..66cf243976e 100644
> > --- a/tools/binman/etype/blob.py
> > +++ b/tools/binman/etype/blob.py
> > @@ -37,13 +37,14 @@ class Entry_blob(Entry):
> >
> > def ObtainContents(self):
> > self._filename = self.GetDefaultFilename()
> > - self._pathname = tools.GetInputFilename(self._filename,
> > - self.section.GetAllowMissing())
> > + self._pathname = tools.GetInputFilename(
> > + self._filename, self.external and self.section.GetAllowMissing())
>
> I hope you know that 'and' has a bit different semantics in Python than in C for example.
I think I understand it, in the sense that 'x and y' returns y if x is
true. Is that what you mean?
> And why to move first parameter to new line?
I think the style is to either line up the params agained the '(' or
indented 4 from the start of the line. I'll flip it back as pylint3
doesn't seem to mind either way.
Regards,
Simon
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 2/5] binman: Show an error when a file is missing
2020-09-07 1:43 ` Simon Glass
@ 2020-09-07 9:05 ` Andy Shevchenko
2020-09-07 13:57 ` Simon Glass
0 siblings, 1 reply; 26+ messages in thread
From: Andy Shevchenko @ 2020-09-07 9:05 UTC (permalink / raw)
To: u-boot
On Sun, Sep 06, 2020 at 07:43:39PM -0600, Simon Glass wrote:
> On Fri, 4 Sep 2020 at 03:33, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Thu, Sep 03, 2020 at 07:28:53PM -0600, Simon Glass wrote:
> > > - self._pathname = tools.GetInputFilename(self._filename,
> > > - self.section.GetAllowMissing())
> > > + self._pathname = tools.GetInputFilename(
> > > + self._filename, self.external and self.section.GetAllowMissing())
> >
> > I hope you know that 'and' has a bit different semantics in Python than in C for example.
>
> I think I understand it, in the sense that 'x and y' returns y if x is
> true. Is that what you mean?
There is no boolean object involved!
"Note that neither and nor or restrict the value and type they return to False
and True, but rather return the last evaluated argument."
If x is last evaluated argument (false), it will be returned. Means that there
are possibilities to get None, False, empty container, etc as returned value of
'and'.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 2/5] binman: Show an error when a file is missing
2020-09-07 9:05 ` Andy Shevchenko
@ 2020-09-07 13:57 ` Simon Glass
0 siblings, 0 replies; 26+ messages in thread
From: Simon Glass @ 2020-09-07 13:57 UTC (permalink / raw)
To: u-boot
Hi Andy,
On Mon, 7 Sep 2020 at 03:08, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Sun, Sep 06, 2020 at 07:43:39PM -0600, Simon Glass wrote:
> > On Fri, 4 Sep 2020 at 03:33, Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Thu, Sep 03, 2020 at 07:28:53PM -0600, Simon Glass wrote:
>
> > > > - self._pathname = tools.GetInputFilename(self._filename,
> > > > - self.section.GetAllowMissing())
> > > > + self._pathname = tools.GetInputFilename(
> > > > + self._filename, self.external and self.section.GetAllowMissing())
> > >
> > > I hope you know that 'and' has a bit different semantics in Python than in C for example.
> >
> > I think I understand it, in the sense that 'x and y' returns y if x is
> > true. Is that what you mean?
>
> There is no boolean object involved!
>
> "Note that neither and nor or restrict the value and type they return to False
> and True, but rather return the last evaluated argument."
>
> If x is last evaluated argument (false), it will be returned. Means that there
> are possibilities to get None, False, empty container, etc as returned value of
> 'and'.
Yes I think that matches with my understanding. It's more like
'if...else' in this case. Anyway, both x and y are booleans in the
code above.
Regards,
Simon
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 3/5] binman: Support adding a U-Boot environment
2020-09-04 1:28 [PATCH 0/5] edison: Support for writing an xFSTK image Simon Glass
2020-09-04 1:28 ` [PATCH 1/5] x86: Use multiple images Simon Glass
2020-09-04 1:28 ` [PATCH 2/5] binman: Show an error when a file is missing Simon Glass
@ 2020-09-04 1:28 ` Simon Glass
2020-09-04 9:37 ` Andy Shevchenko
2020-09-04 1:28 ` [PATCH 4/5] x86: edison: Generate an image suitable for xFSTK Simon Glass
` (3 subsequent siblings)
6 siblings, 1 reply; 26+ messages in thread
From: Simon Glass @ 2020-09-04 1:28 UTC (permalink / raw)
To: u-boot
In some cases it is useful to include a U-Boot environment region in an
image. This allows the board to start up with an environment ready to go.
Add a new entry type for this. The input is a text file containing the
environment entries, one per line, in the format:
var=value
Signed-off-by: Simon Glass <sjg@chromium.org>
---
tools/binman/etype/u_boot_env.py | 42 +++++++++++++++++++++++++
tools/binman/ftest.py | 31 ++++++++++++++++++
tools/binman/test/174_env.dts | 20 ++++++++++++
tools/binman/test/175_env_no_size.dts | 19 +++++++++++
tools/binman/test/176_env_too_small.dts | 20 ++++++++++++
5 files changed, 132 insertions(+)
create mode 100644 tools/binman/etype/u_boot_env.py
create mode 100644 tools/binman/test/174_env.dts
create mode 100644 tools/binman/test/175_env_no_size.dts
create mode 100644 tools/binman/test/176_env_too_small.dts
diff --git a/tools/binman/etype/u_boot_env.py b/tools/binman/etype/u_boot_env.py
new file mode 100644
index 00000000000..1694c2a6eef
--- /dev/null
+++ b/tools/binman/etype/u_boot_env.py
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (c) 2018 Google, Inc
+# Written by Simon Glass <sjg@chromium.org>
+#
+
+import struct
+import zlib
+
+from binman.etype.blob import Entry_blob
+from dtoc import fdt_util
+from patman import tools
+
+class Entry_u_boot_env(Entry_blob):
+ """An entry which contains a U-Boot environment
+
+ Properties / Entry arguments:
+ - filename: File containing the environment text, with each line in the
+ form var=value
+ """
+ def __init__(self, section, etype, node):
+ super().__init__(section, etype, node)
+
+ def ReadNode(self):
+ super().ReadNode()
+ if self.size is None:
+ self.Raise("'u-boot-env' entry must have a size property")
+ self.fill_value = fdt_util.GetByte(self._node, 'fill-byte', 0)
+
+ def ReadBlobContents(self):
+ indata = tools.ReadFile(self._pathname)
+ data = b''
+ for line in indata.splitlines():
+ data += line + b'\0'
+ data += b'\0';
+ pad = self.size - len(data) - 5
+ if pad < 0:
+ self.Raise("'u-boot-env' entry too small to hold data (need %#x more bytes)" % -pad)
+ data += tools.GetBytes(self.fill_value, pad)
+ crc = zlib.crc32(data)
+ buf = struct.pack('<I', crc) + b'\x01' + data
+ self.SetContents(buf)
+ return True
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 91225459162..b771b9d5df7 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -77,6 +77,7 @@ FSP_T_DATA = b'fsp_t'
ATF_BL31_DATA = b'bl31'
TEST_FDT1_DATA = b'fdt1'
TEST_FDT2_DATA = b'test-fdt2'
+ENV_DATA = b'var1=1\nvar2="2"'
# Subdirectory of the input dir to use to put test FDTs
TEST_FDT_SUBDIR = 'fdts'
@@ -181,6 +182,8 @@ class TestFunctional(unittest.TestCase):
TestFunctional._MakeInputFile('%s/test-fdt2.dtb' % TEST_FDT_SUBDIR,
TEST_FDT2_DATA)
+ TestFunctional._MakeInputFile('env.txt', ENV_DATA)
+
# Travis-CI may have an old lz4
cls.have_lz4 = True
try:
@@ -3715,5 +3718,33 @@ class TestFunctional(unittest.TestCase):
self.assertIn("Filename 'missing' not found in input path",
str(e.exception))
+ def testEnvironment(self):
+ """Test adding a U-Boot environment"""
+ data = self._DoReadFile('174_env.dts')
+ self.assertEqual(U_BOOT_DATA, data[:len(U_BOOT_DATA)])
+ self.assertEqual(U_BOOT_NODTB_DATA, data[-len(U_BOOT_NODTB_DATA):])
+ env = data[len(U_BOOT_DATA):-len(U_BOOT_NODTB_DATA)]
+ self.assertEqual(b'\x1b\x97\x22\x7c\x01var1=1\0var2="2"\0\0\xff\xff',
+ env)
+
+ def testEnvironmentNoSize(self):
+ """Test that a missing 'size' property is detected"""
+ with self.assertRaises(ValueError) as e:
+ data = self._DoTestFile('175_env_no_size.dts')
+ self.assertIn("'u-boot-env' entry must have a size property",
+ str(e.exception))
+
+ def testEnvironmentTooSmall(self):
+ """Test handling of an environment that does not fit"""
+ with self.assertRaises(ValueError) as e:
+ data = self._DoTestFile('176_env_too_small.dts')
+
+ # checksum, start byte, environment with \0 terminator, final \0
+ need = 4 + 1 + len(ENV_DATA) + 1 + 1
+ short = need - 0x8
+ self.assertIn("too small to hold data (need %#x more bytes)" % short,
+ str(e.exception))
+
+
if __name__ == "__main__":
unittest.main()
diff --git a/tools/binman/test/174_env.dts b/tools/binman/test/174_env.dts
new file mode 100644
index 00000000000..d1393d2db93
--- /dev/null
+++ b/tools/binman/test/174_env.dts
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ binman {
+ u-boot {
+ };
+ u-boot-env {
+ filename = "env.txt";
+ size = <0x18>;
+ fill-byte = [ff];
+ };
+ u-boot-nodtb {
+ };
+ };
+};
diff --git a/tools/binman/test/175_env_no_size.dts b/tools/binman/test/175_env_no_size.dts
new file mode 100644
index 00000000000..267acd15491
--- /dev/null
+++ b/tools/binman/test/175_env_no_size.dts
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ binman {
+ u-boot {
+ };
+ u-boot-env {
+ filename = "env.txt";
+ fill-byte = [ff];
+ };
+ u-boot-nodtb {
+ };
+ };
+};
diff --git a/tools/binman/test/176_env_too_small.dts b/tools/binman/test/176_env_too_small.dts
new file mode 100644
index 00000000000..2db8d054639
--- /dev/null
+++ b/tools/binman/test/176_env_too_small.dts
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ binman {
+ u-boot {
+ };
+ u-boot-env {
+ filename = "env.txt";
+ size = <0x8>;
+ fill-byte = [ff];
+ };
+ u-boot-nodtb {
+ };
+ };
+};
--
2.28.0.526.ge36021eeef-goog
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH 3/5] binman: Support adding a U-Boot environment
2020-09-04 1:28 ` [PATCH 3/5] binman: Support adding a U-Boot environment Simon Glass
@ 2020-09-04 9:37 ` Andy Shevchenko
0 siblings, 0 replies; 26+ messages in thread
From: Andy Shevchenko @ 2020-09-04 9:37 UTC (permalink / raw)
To: u-boot
On Thu, Sep 03, 2020 at 07:28:54PM -0600, Simon Glass wrote:
> In some cases it is useful to include a U-Boot environment region in an
> image. This allows the board to start up with an environment ready to go.
>
> Add a new entry type for this. The input is a text file containing the
> environment entries, one per line, in the format:
>
> var=value
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> tools/binman/etype/u_boot_env.py | 42 +++++++++++++++++++++++++
> tools/binman/ftest.py | 31 ++++++++++++++++++
> tools/binman/test/174_env.dts | 20 ++++++++++++
> tools/binman/test/175_env_no_size.dts | 19 +++++++++++
> tools/binman/test/176_env_too_small.dts | 20 ++++++++++++
> 5 files changed, 132 insertions(+)
> create mode 100644 tools/binman/etype/u_boot_env.py
> create mode 100644 tools/binman/test/174_env.dts
> create mode 100644 tools/binman/test/175_env_no_size.dts
> create mode 100644 tools/binman/test/176_env_too_small.dts
>
> diff --git a/tools/binman/etype/u_boot_env.py b/tools/binman/etype/u_boot_env.py
> new file mode 100644
> index 00000000000..1694c2a6eef
> --- /dev/null
> +++ b/tools/binman/etype/u_boot_env.py
> @@ -0,0 +1,42 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +# Copyright (c) 2018 Google, Inc
> +# Written by Simon Glass <sjg@chromium.org>
> +#
> +
> +import struct
> +import zlib
> +
> +from binman.etype.blob import Entry_blob
> +from dtoc import fdt_util
> +from patman import tools
> +
> +class Entry_u_boot_env(Entry_blob):
> + """An entry which contains a U-Boot environment
> +
> + Properties / Entry arguments:
> + - filename: File containing the environment text, with each line in the
> + form var=value
> + """
> + def __init__(self, section, etype, node):
> + super().__init__(section, etype, node)
> +
> + def ReadNode(self):
> + super().ReadNode()
> + if self.size is None:
> + self.Raise("'u-boot-env' entry must have a size property")
> + self.fill_value = fdt_util.GetByte(self._node, 'fill-byte', 0)
> +
> + def ReadBlobContents(self):
> + indata = tools.ReadFile(self._pathname)
> + data = b''
> + for line in indata.splitlines():
> + data += line + b'\0'
> + data += b'\0';
> + pad = self.size - len(data) - 5
> + if pad < 0:
> + self.Raise("'u-boot-env' entry too small to hold data (need %#x more bytes)" % -pad)
> + data += tools.GetBytes(self.fill_value, pad)
> + crc = zlib.crc32(data)
> + buf = struct.pack('<I', crc) + b'\x01' + data
> + self.SetContents(buf)
> + return True
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> index 91225459162..b771b9d5df7 100644
> --- a/tools/binman/ftest.py
> +++ b/tools/binman/ftest.py
> @@ -77,6 +77,7 @@ FSP_T_DATA = b'fsp_t'
> ATF_BL31_DATA = b'bl31'
> TEST_FDT1_DATA = b'fdt1'
> TEST_FDT2_DATA = b'test-fdt2'
> +ENV_DATA = b'var1=1\nvar2="2"'
>
> # Subdirectory of the input dir to use to put test FDTs
> TEST_FDT_SUBDIR = 'fdts'
> @@ -181,6 +182,8 @@ class TestFunctional(unittest.TestCase):
> TestFunctional._MakeInputFile('%s/test-fdt2.dtb' % TEST_FDT_SUBDIR,
> TEST_FDT2_DATA)
>
> + TestFunctional._MakeInputFile('env.txt', ENV_DATA)
> +
> # Travis-CI may have an old lz4
> cls.have_lz4 = True
> try:
> @@ -3715,5 +3718,33 @@ class TestFunctional(unittest.TestCase):
> self.assertIn("Filename 'missing' not found in input path",
> str(e.exception))
>
> + def testEnvironment(self):
> + """Test adding a U-Boot environment"""
> + data = self._DoReadFile('174_env.dts')
> + self.assertEqual(U_BOOT_DATA, data[:len(U_BOOT_DATA)])
> + self.assertEqual(U_BOOT_NODTB_DATA, data[-len(U_BOOT_NODTB_DATA):])
> + env = data[len(U_BOOT_DATA):-len(U_BOOT_NODTB_DATA)]
> + self.assertEqual(b'\x1b\x97\x22\x7c\x01var1=1\0var2="2"\0\0\xff\xff',
> + env)
> +
> + def testEnvironmentNoSize(self):
> + """Test that a missing 'size' property is detected"""
> + with self.assertRaises(ValueError) as e:
> + data = self._DoTestFile('175_env_no_size.dts')
> + self.assertIn("'u-boot-env' entry must have a size property",
> + str(e.exception))
> +
> + def testEnvironmentTooSmall(self):
> + """Test handling of an environment that does not fit"""
> + with self.assertRaises(ValueError) as e:
> + data = self._DoTestFile('176_env_too_small.dts')
> +
> + # checksum, start byte, environment with \0 terminator, final \0
> + need = 4 + 1 + len(ENV_DATA) + 1 + 1
> + short = need - 0x8
> + self.assertIn("too small to hold data (need %#x more bytes)" % short,
> + str(e.exception))
> +
> +
> if __name__ == "__main__":
> unittest.main()
> diff --git a/tools/binman/test/174_env.dts b/tools/binman/test/174_env.dts
> new file mode 100644
> index 00000000000..d1393d2db93
> --- /dev/null
> +++ b/tools/binman/test/174_env.dts
> @@ -0,0 +1,20 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/dts-v1/;
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + binman {
> + u-boot {
> + };
> + u-boot-env {
> + filename = "env.txt";
> + size = <0x18>;
> + fill-byte = [ff];
> + };
> + u-boot-nodtb {
> + };
> + };
> +};
> diff --git a/tools/binman/test/175_env_no_size.dts b/tools/binman/test/175_env_no_size.dts
> new file mode 100644
> index 00000000000..267acd15491
> --- /dev/null
> +++ b/tools/binman/test/175_env_no_size.dts
> @@ -0,0 +1,19 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/dts-v1/;
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + binman {
> + u-boot {
> + };
> + u-boot-env {
> + filename = "env.txt";
> + fill-byte = [ff];
> + };
> + u-boot-nodtb {
> + };
> + };
> +};
> diff --git a/tools/binman/test/176_env_too_small.dts b/tools/binman/test/176_env_too_small.dts
> new file mode 100644
> index 00000000000..2db8d054639
> --- /dev/null
> +++ b/tools/binman/test/176_env_too_small.dts
> @@ -0,0 +1,20 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/dts-v1/;
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + binman {
> + u-boot {
> + };
> + u-boot-env {
> + filename = "env.txt";
> + size = <0x8>;
> + fill-byte = [ff];
> + };
> + u-boot-nodtb {
> + };
> + };
> +};
> --
> 2.28.0.526.ge36021eeef-goog
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 4/5] x86: edison: Generate an image suitable for xFSTK
2020-09-04 1:28 [PATCH 0/5] edison: Support for writing an xFSTK image Simon Glass
` (2 preceding siblings ...)
2020-09-04 1:28 ` [PATCH 3/5] binman: Support adding a U-Boot environment Simon Glass
@ 2020-09-04 1:28 ` Simon Glass
2020-09-04 9:39 ` Andy Shevchenko
2020-09-04 1:28 ` [PATCH 5/5] x86: edison: Add documentation for using am xFSTK image Simon Glass
` (2 subsequent siblings)
6 siblings, 1 reply; 26+ messages in thread
From: Simon Glass @ 2020-09-04 1:28 UTC (permalink / raw)
To: u-boot
It is useful to be able to flash Edison directly without relying on the
installed U-Boot being functional.
Add a binman image for this. It includes a master-boot record, U-Boot
binary and an environment.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
arch/x86/cpu/tangier/Kconfig | 1 +
arch/x86/dts/edison.dts | 34 +++++++++++++++
board/intel/edison/edison-environment.txt | 48 ++++++++++++++++++++++
board/intel/edison/edison-mbr.dat | Bin 0 -> 512 bytes
4 files changed, 83 insertions(+)
create mode 100644 board/intel/edison/edison-environment.txt
create mode 100644 board/intel/edison/edison-mbr.dat
diff --git a/arch/x86/cpu/tangier/Kconfig b/arch/x86/cpu/tangier/Kconfig
index d2b7edecd60..571470c74b2 100644
--- a/arch/x86/cpu/tangier/Kconfig
+++ b/arch/x86/cpu/tangier/Kconfig
@@ -12,6 +12,7 @@ config INTEL_TANGIER
imply MMC_SDHCI_TANGIER
imply USB
imply USB_DWC3
+ imply BINMAN
if INTEL_TANGIER
diff --git a/arch/x86/dts/edison.dts b/arch/x86/dts/edison.dts
index df24aa0d26a..b5aac6b7349 100644
--- a/arch/x86/dts/edison.dts
+++ b/arch/x86/dts/edison.dts
@@ -22,6 +22,10 @@
serial2 = &serial2;
};
+ binman: binman {
+ multiple-images;
+ };
+
chosen {
stdout-path = &serial2;
};
@@ -130,3 +134,33 @@
};
};
};
+
+&binman {
+ u-boot-edison {
+ filename = "u-boot-edison.img";
+
+ /* This is Master-Boot Record */
+ blob {
+ filename = "edison-mbr.dat";
+ };
+
+ u-boot {
+ offset = <0x200>;
+ };
+
+ u-boot-env {
+ offset = <0x200200>;
+ filename = "edison-environment.txt";
+ size = <0x10000>;
+ fill-byte = [ff];
+ };
+
+ u-boot-env2 {
+ type = "u-boot-env";
+ offset = <0x500200>;
+ filename = "edison-environment.txt";
+ size = <0x10000>;
+ fill-byte = [ff];
+ };
+ };
+};
diff --git a/board/intel/edison/edison-environment.txt b/board/intel/edison/edison-environment.txt
new file mode 100644
index 00000000000..afe00920461
--- /dev/null
+++ b/board/intel/edison/edison-environment.txt
@@ -0,0 +1,48 @@
+partitions=uuid_disk=${uuid_disk};name=u-boot0,start=1MiB,size=2MiB,uuid=${uuid_uboot0};name=u-boot-env0,size=1MiB,uuid=${uuid_uboot_env0};name=u-boot1,size=2MiB,uuid=${uuid_uboot1};name=u-boot-env1,size=1MiB,uuid=${uuid_uboot_env1};name=factory,size=1MiB,uuid=${uuid_factory};name=panic,size=24MiB,uuid=${uuid_panic};name=boot,size=32MiB,uuid=${uuid_boot};name=rootfs,size=1536MiB,uuid=${uuid_rootfs};name=update,size=768MiB,uuid=${uuid_update};name=home,size=-,uuid=${uuid_home};
+do_dfu_alt_info_mmc=setenv dfu_alt_info "ifwi${hardware_id} raw 0 8192 mmcpart 1;ifwib${hardware_id} raw 0 8192 mmcpart 2;u-boot0 part 0 1;u-boot-env0 part 0 2;u-boot1 part 0 3;u-boot-env1 part 0 4;boot part 0 7;rootfs part 0 8;update part 0 9;home part 0 10;vmlinuz fat 0 7;initrd fat 0 7"
+dfu_alt_info_ram=kernel ram ${loadaddr} 0x800000
+do_dfu_alt_info_ifwi=setenv dfu_alt_info "ifwi${hardware_id} raw 0 8192 mmcpart 1;ifwib${hardware_id} raw 0 8192 mmcpart 2"
+dfu_alt_info_reset=reset ram 0x0 0x0
+bootargs_console=console=ttyMFD2 earlyprintk=ttyMFD2,keep
+bootargs_debug=loglevel=4
+do_bootargs_rootfs=setenv bootargs_rootfs rootwait root=PARTUUID=${uuid_rootfs} rootfstype=ext4
+first_install_retry=0
+first_install_max_retries=3
+ota_update_retry=0
+ota_update_max_retries=3
+audio_codec_name=audio_codec="dummy"
+do_audio_support=setenv audio_support platform_mrfld_audio.${audio_codec_name}
+do_compute_target=if itest.b ${first_install_retry} -gt ${first_install_max_retries} || itest.b ${ota_update_retry} -gt ${ota_update_max_retries}; then echo "Switch to Rescue target"; setenv bootargs_target rescue; saveenv; fi
+mmc-bootargs=run do_bootargs_rootfs; run do_audio_support; setenv bootargs ${bootargs_rootfs} ${bootargs_console} ${bootargs_debug} g_multi.ethernet_config=${bootargs_ethconfig} systemd.unit=${bootargs_target}.target hardware_id=${hardware_id} g_multi.iSerialNumber=${serial#} g_multi.dev_addr=${usb0addr} ${audio_support}
+loadaddr=0x100000
+load_kernel=fatload mmc 0:7 ${loadaddr} vmlinuz
+do_partition_done=0
+do_partition=if itest.b ${do_partition_done} -eq 1; then echo "Partitioning already done..."; else run do_force_partition ; fi
+do_force_partition=echo "Partitioning using GPT"; gpt write mmc 0 ${partitions} ; mmc rescan; setenv do_partition_done 1 ; saveenv
+do_flash_ifwi=run do_dfu_alt_info_ifwi ; dfu 0 mmc 0 $dfu_to_sec
+do_flash_os=if itest.b ${do_flash_os_done} -eq 1 ; then echo "Flashing already done..." ; else run do_force_flash_os; fi
+do_force_flash_os=run do_dfu_alt_info_mmc ; sleep 1 ; setenv do_flash_os_done 1 ; saveenv ; dfu 0 mmc 0 $dfu_to_sec
+do_flashall=run do_partition;run do_flash_ifwi;run do_flash_os
+do_dnx=setenv dfu_alt_info ${dfu_alt_info_ram};dfu 0 ram 0 ram;run bootcmd
+init_dfu=run do_dfu_alt_info_mmc ; saveenv
+bootcmd=echo "Target:${target_name}"; run do_partition; run do_handle_bootargs_mode;
+do_handle_bootargs_mode=run do_preprocess_bootargs_mode; if itest.s $bootargs_mode == "ota" ; then run do_ota; fi; if itest.s $bootargs_mode == "boot" ; then run do_boot; fi; if itest.s $bootargs_mode == "flash"; then run do_flash; fi; run do_fallback; exit;
+do_preprocess_bootargs_mode=if env exists bootargs_mode ; then ; else setenv bootargs_mode "boot" ;fi;
+do_fallback=echo "Unknown boot mode: $bootargs_mode"; env delete -f bootargs_mode; saveenv; echo "Resetting to default boot mode and reboot..."; reset;
+do_boot=run boot_target_cmd;
+do_flash=run do_force_flash_os;
+ota_done=0
+ota_script_addr=0x100000
+do_ota_init=setenv ota_status 1 ; env delete -f bootargs_mode
+do_load_ota_scr=if fatload mmc 0:9 $ota_script_addr ota_update.scr ; then setenv ota_status 0 ; else setenv ota_status 1 ; fi
+do_source_ota_scr=if test $ota_status -eq 0 ; then if source $ota_script_addr ; then setenv ota_status 0 ; else setenv ota_status 2 ; fi ; fi
+do_ota_clean=saveenv ; reset
+do_ota=run do_ota_init ; run do_load_ota_scr ; run do_source_ota_scr ; run do_ota_clean
+target_name=blank
+bootdelay=1
+do_flash_os_done=1
+bootargs_target=multi-user
+bootargs_ethconfig=cdc
+dfu_to_sec=3
+do_probe_dfu=run do_dfu_alt_info_mmc ; dfu 0 mmc 0 $dfu_to_sec
+boot_target_cmd=run do_flash_os;run do_probe_dfu;run do_compute_target;run mmc-bootargs;run load_kernel;zboot ${loadaddr}
diff --git a/board/intel/edison/edison-mbr.dat b/board/intel/edison/edison-mbr.dat
new file mode 100644
index 0000000000000000000000000000000000000000..c984e99f247c54253f1d950ece602d44c10cb6eb
GIT binary patch
literal 512
zcmY%K4_0AdU}R!sv|zvqI6yK2j0^%mY{0<459IwH1p^uah`4$OWHN%d4;C{cM2TaC
Gt^xr56@#Pz
literal 0
HcmV?d00001
--
2.28.0.526.ge36021eeef-goog
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH 4/5] x86: edison: Generate an image suitable for xFSTK
2020-09-04 1:28 ` [PATCH 4/5] x86: edison: Generate an image suitable for xFSTK Simon Glass
@ 2020-09-04 9:39 ` Andy Shevchenko
0 siblings, 0 replies; 26+ messages in thread
From: Andy Shevchenko @ 2020-09-04 9:39 UTC (permalink / raw)
To: u-boot
On Thu, Sep 03, 2020 at 07:28:55PM -0600, Simon Glass wrote:
> It is useful to be able to flash Edison directly without relying on the
> installed U-Boot being functional.
>
> Add a binman image for this. It includes a master-boot record, U-Boot
> binary and an environment.
master-boot record -> OSIP header
It's a part of DnX (Download'n'Execute) protocol. Let's say it's coincidence it
looks like MBR.
With above and below changes made,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> arch/x86/cpu/tangier/Kconfig | 1 +
> arch/x86/dts/edison.dts | 34 +++++++++++++++
> board/intel/edison/edison-environment.txt | 48 ++++++++++++++++++++++
> board/intel/edison/edison-mbr.dat | Bin 0 -> 512 bytes
mbr -> osip
> 4 files changed, 83 insertions(+)
> create mode 100644 board/intel/edison/edison-environment.txt
> create mode 100644 board/intel/edison/edison-mbr.dat
>
> diff --git a/arch/x86/cpu/tangier/Kconfig b/arch/x86/cpu/tangier/Kconfig
> index d2b7edecd60..571470c74b2 100644
> --- a/arch/x86/cpu/tangier/Kconfig
> +++ b/arch/x86/cpu/tangier/Kconfig
> @@ -12,6 +12,7 @@ config INTEL_TANGIER
> imply MMC_SDHCI_TANGIER
> imply USB
> imply USB_DWC3
> + imply BINMAN
>
> if INTEL_TANGIER
>
> diff --git a/arch/x86/dts/edison.dts b/arch/x86/dts/edison.dts
> index df24aa0d26a..b5aac6b7349 100644
> --- a/arch/x86/dts/edison.dts
> +++ b/arch/x86/dts/edison.dts
> @@ -22,6 +22,10 @@
> serial2 = &serial2;
> };
>
> + binman: binman {
> + multiple-images;
> + };
> +
> chosen {
> stdout-path = &serial2;
> };
> @@ -130,3 +134,33 @@
> };
> };
> };
> +
> +&binman {
> + u-boot-edison {
> + filename = "u-boot-edison.img";
> +
> + /* This is Master-Boot Record */
> + blob {
> + filename = "edison-mbr.dat";
> + };
> +
> + u-boot {
> + offset = <0x200>;
> + };
> +
> + u-boot-env {
> + offset = <0x200200>;
> + filename = "edison-environment.txt";
> + size = <0x10000>;
> + fill-byte = [ff];
> + };
> +
> + u-boot-env2 {
> + type = "u-boot-env";
> + offset = <0x500200>;
> + filename = "edison-environment.txt";
> + size = <0x10000>;
> + fill-byte = [ff];
> + };
> + };
> +};
> diff --git a/board/intel/edison/edison-environment.txt b/board/intel/edison/edison-environment.txt
> new file mode 100644
> index 00000000000..afe00920461
> --- /dev/null
> +++ b/board/intel/edison/edison-environment.txt
> @@ -0,0 +1,48 @@
> +partitions=uuid_disk=${uuid_disk};name=u-boot0,start=1MiB,size=2MiB,uuid=${uuid_uboot0};name=u-boot-env0,size=1MiB,uuid=${uuid_uboot_env0};name=u-boot1,size=2MiB,uuid=${uuid_uboot1};name=u-boot-env1,size=1MiB,uuid=${uuid_uboot_env1};name=factory,size=1MiB,uuid=${uuid_factory};name=panic,size=24MiB,uuid=${uuid_panic};name=boot,size=32MiB,uuid=${uuid_boot};name=rootfs,size=1536MiB,uuid=${uuid_rootfs};name=update,size=768MiB,uuid=${uuid_update};name=home,size=-,uuid=${uuid_home};
> +do_dfu_alt_info_mmc=setenv dfu_alt_info "ifwi${hardware_id} raw 0 8192 mmcpart 1;ifwib${hardware_id} raw 0 8192 mmcpart 2;u-boot0 part 0 1;u-boot-env0 part 0 2;u-boot1 part 0 3;u-boot-env1 part 0 4;boot part 0 7;rootfs part 0 8;update part 0 9;home part 0 10;vmlinuz fat 0 7;initrd fat 0 7"
> +dfu_alt_info_ram=kernel ram ${loadaddr} 0x800000
> +do_dfu_alt_info_ifwi=setenv dfu_alt_info "ifwi${hardware_id} raw 0 8192 mmcpart 1;ifwib${hardware_id} raw 0 8192 mmcpart 2"
> +dfu_alt_info_reset=reset ram 0x0 0x0
> +bootargs_console=console=ttyMFD2 earlyprintk=ttyMFD2,keep
> +bootargs_debug=loglevel=4
> +do_bootargs_rootfs=setenv bootargs_rootfs rootwait root=PARTUUID=${uuid_rootfs} rootfstype=ext4
> +first_install_retry=0
> +first_install_max_retries=3
> +ota_update_retry=0
> +ota_update_max_retries=3
> +audio_codec_name=audio_codec="dummy"
> +do_audio_support=setenv audio_support platform_mrfld_audio.${audio_codec_name}
> +do_compute_target=if itest.b ${first_install_retry} -gt ${first_install_max_retries} || itest.b ${ota_update_retry} -gt ${ota_update_max_retries}; then echo "Switch to Rescue target"; setenv bootargs_target rescue; saveenv; fi
> +mmc-bootargs=run do_bootargs_rootfs; run do_audio_support; setenv bootargs ${bootargs_rootfs} ${bootargs_console} ${bootargs_debug} g_multi.ethernet_config=${bootargs_ethconfig} systemd.unit=${bootargs_target}.target hardware_id=${hardware_id} g_multi.iSerialNumber=${serial#} g_multi.dev_addr=${usb0addr} ${audio_support}
> +loadaddr=0x100000
> +load_kernel=fatload mmc 0:7 ${loadaddr} vmlinuz
> +do_partition_done=0
> +do_partition=if itest.b ${do_partition_done} -eq 1; then echo "Partitioning already done..."; else run do_force_partition ; fi
> +do_force_partition=echo "Partitioning using GPT"; gpt write mmc 0 ${partitions} ; mmc rescan; setenv do_partition_done 1 ; saveenv
> +do_flash_ifwi=run do_dfu_alt_info_ifwi ; dfu 0 mmc 0 $dfu_to_sec
> +do_flash_os=if itest.b ${do_flash_os_done} -eq 1 ; then echo "Flashing already done..." ; else run do_force_flash_os; fi
> +do_force_flash_os=run do_dfu_alt_info_mmc ; sleep 1 ; setenv do_flash_os_done 1 ; saveenv ; dfu 0 mmc 0 $dfu_to_sec
> +do_flashall=run do_partition;run do_flash_ifwi;run do_flash_os
> +do_dnx=setenv dfu_alt_info ${dfu_alt_info_ram};dfu 0 ram 0 ram;run bootcmd
> +init_dfu=run do_dfu_alt_info_mmc ; saveenv
> +bootcmd=echo "Target:${target_name}"; run do_partition; run do_handle_bootargs_mode;
> +do_handle_bootargs_mode=run do_preprocess_bootargs_mode; if itest.s $bootargs_mode == "ota" ; then run do_ota; fi; if itest.s $bootargs_mode == "boot" ; then run do_boot; fi; if itest.s $bootargs_mode == "flash"; then run do_flash; fi; run do_fallback; exit;
> +do_preprocess_bootargs_mode=if env exists bootargs_mode ; then ; else setenv bootargs_mode "boot" ;fi;
> +do_fallback=echo "Unknown boot mode: $bootargs_mode"; env delete -f bootargs_mode; saveenv; echo "Resetting to default boot mode and reboot..."; reset;
> +do_boot=run boot_target_cmd;
> +do_flash=run do_force_flash_os;
> +ota_done=0
> +ota_script_addr=0x100000
> +do_ota_init=setenv ota_status 1 ; env delete -f bootargs_mode
> +do_load_ota_scr=if fatload mmc 0:9 $ota_script_addr ota_update.scr ; then setenv ota_status 0 ; else setenv ota_status 1 ; fi
> +do_source_ota_scr=if test $ota_status -eq 0 ; then if source $ota_script_addr ; then setenv ota_status 0 ; else setenv ota_status 2 ; fi ; fi
> +do_ota_clean=saveenv ; reset
> +do_ota=run do_ota_init ; run do_load_ota_scr ; run do_source_ota_scr ; run do_ota_clean
> +target_name=blank
> +bootdelay=1
> +do_flash_os_done=1
> +bootargs_target=multi-user
> +bootargs_ethconfig=cdc
> +dfu_to_sec=3
> +do_probe_dfu=run do_dfu_alt_info_mmc ; dfu 0 mmc 0 $dfu_to_sec
> +boot_target_cmd=run do_flash_os;run do_probe_dfu;run do_compute_target;run mmc-bootargs;run load_kernel;zboot ${loadaddr}
> diff --git a/board/intel/edison/edison-mbr.dat b/board/intel/edison/edison-mbr.dat
> new file mode 100644
> index 0000000000000000000000000000000000000000..c984e99f247c54253f1d950ece602d44c10cb6eb
> GIT binary patch
> literal 512
> zcmY%K4_0AdU}R!sv|zvqI6yK2j0^%mY{0<459IwH1p^uah`4$OWHN%d4;C{cM2TaC
> Gt^xr56@#Pz
>
> literal 0
> HcmV?d00001
>
> --
> 2.28.0.526.ge36021eeef-goog
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 5/5] x86: edison: Add documentation for using am xFSTK image
2020-09-04 1:28 [PATCH 0/5] edison: Support for writing an xFSTK image Simon Glass
` (3 preceding siblings ...)
2020-09-04 1:28 ` [PATCH 4/5] x86: edison: Generate an image suitable for xFSTK Simon Glass
@ 2020-09-04 1:28 ` Simon Glass
2020-09-04 9:43 ` Andy Shevchenko
2020-09-04 9:46 ` [PATCH 0/5] edison: Support for writing an " Andy Shevchenko
2020-09-22 7:11 ` Bin Meng
6 siblings, 1 reply; 26+ messages in thread
From: Simon Glass @ 2020-09-04 1:28 UTC (permalink / raw)
To: u-boot
Add a description of how to flash Edison using the XFSTK tool.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
doc/board/intel/edison.rst | 120 +++++++++++++++++++++++++++++++++++++
1 file changed, 120 insertions(+)
diff --git a/doc/board/intel/edison.rst b/doc/board/intel/edison.rst
index 1aee2a1fc0d..40acd80a051 100644
--- a/doc/board/intel/edison.rst
+++ b/doc/board/intel/edison.rst
@@ -39,3 +39,123 @@ use.
reset the board::
=> reset
+
+
+Updating U-Boot using xFSTK
+---------------------------
+
+You can also update U-Boot using the xfstk-dldr-solo tool if you can build it.
+One way to do that is to follow the `xFSTK`_ instructions. You may need to use
+a virtual machine running Ubuntu Trusty. Once you have built it and installed
+libboost-all-dev, you can copy xfstk-dldr-solo to /usr/local/bin and
+libboost_program_options.so.1.54.0 to /usr/lib/i386-linux-gnu/ and with luck
+it will work. You might fine this `drive`_ helpful.
+
+If it does, then you can download and unpack the Edison reocovery image,
+install dfu-util, reset your board and flash U-Boot like this::
+
+ $ xfstk-dldr-solo --gpflags 0x80000007 \
+ --osimage u-boot-edison.img \
+ --fwdnx recover/edison_dnx_fwr.bin \
+ --fwimage recover/edison_ifwi-dbg-00.bin \
+ --osdnx recover/edison_dnx_osr.bin
+
+This should show the following
+
+.. code-block:: none
+
+ XFSTK Downloader Solo 0.0.0
+ Copyright (c) 2015 Intel Corporation
+ Build date and time: Aug 15 2020 15:07:13
+
+ .Intel SoC Device Detection Found
+ Parsing Commandline....
+ Registering Status Callback....
+ .Initiating Download Process....
+ .......(lots of dots)........XFSTK-STATUS--Reconnecting to device - Attempt #1
+ .......(even more dots)......................
+
+
+You have about 10 seconds after resetting the board to type the above command.
+If you want to check if the board is ready, type:
+
+.. code-block:: none
+
+ lsusb |egrep "8087|8086"
+ Bus 001 Device 004: ID 8086:e005 Intel Corp.
+
+If you see a device with the same ID as above, the board is waiting for your
+command.
+
+After about 5 seconds you should see some console output from the board:
+
+.. code-block:: none
+
+ ******************************
+ PSH KERNEL VERSION: b0182b2b
+ WR: 20104000
+ ******************************
+
+ SCU IPC: 0x800000d0 0xfffce92c
+
+ PSH miaHOB version: TNG.B0.VVBD.0000000c
+
+ microkernel built 11:24:08 Feb 5 2015
+
+ ******* PSH loader *******
+ PCM page cache size = 192 KB
+ Cache Constraint = 0 Pages
+ Arming IPC driver ..
+ Adding page store pool ..
+ PagestoreAddr(IMR Start Address) = 0x04899000
+ pageStoreSize(IMR Size) = 0x00080000
+
+ *** Ready to receive application ***
+
+ After another 10 seconds the xFSTK tool completes and the board resets. About
+ 10 seconds after that should see the above message again and then within a
+ few seconds U-Boot should start on your board:
+
+.. code-block:: none
+
+ U-Boot 2020.10-rc3-00032-gd9f6680e925-dirty (Sep 03 2020 - 18:44:28 -0600)
+
+ CPU: Genuine Intel(R) CPU 4000 @ 500MHz
+ DRAM: 980.6 MiB
+ WDT: Started with servicing (60s timeout)
+ MMC: mmc at ff3fc000: 0, mmc at ff3fa000: 1
+ Loading Environment from MMC... OK
+ In: serial
+ Out: serial
+ Err: serial
+ Saving Environment to MMC... Writing to redundant MMC(0)... OK
+ Saving Environment to MMC... Writing to MMC(0)... OK
+ Net: No ethernet found.
+ Hit any key to stop autoboot: 0
+ Target:blank
+ Partitioning using GPT
+ Writing GPT: success!
+ Saving Environment to MMC... Writing to redundant MMC(0)... OK
+ Flashing already done...
+ 5442816 bytes read in 238 ms (21.8 MiB/s)
+ Valid Boot Flag
+ Setup Size = 0x00003c00
+ Magic signature found
+ Using boot protocol version 2.0c
+ Linux kernel version 3.10.17-poky-edison+ (ferry at kalamata) #1 SMP PREEMPT Mon Jan 11 14:54:18 CET 2016
+ Building boot_params at 0x00090000
+ Loading bzImage at address 100000 (5427456 bytes)
+ Magic signature found
+ Kernel command line: "rootwait root=PARTUUID=ada722ed-6410-764e-8619-abff6f66e10e rootfstype=ext4 console=ttyMFD2 earlyprintk=ttyMFD2,keep loglevel=4 g_multi.ethernet_config=cdc systemd.unit=multi-user.target hardware_id=00 g_multi.iSerialNumber=2249baf774c675598661a63098c0ad41 g_multi.dev_addr=02:00:86:c0:ad:41 platform_mrfld_audio.audio_codec=dummy"
+ Magic signature found
+
+ Starting kernel ...
+
+ ...
+
+ Poky (Yocto Project Reference Distro) 1.7.2 edison ttyMFD2
+
+ edison login:
+
+.. _xFSTK: https://community.intel.com/t5/Intel-Makers/Building-xFSTK-on-Ubuntu-14-04-32-bit-for-flashing-Edison/td-p/538081
+.. _drive: https://drive.google.com/drive/u/0/folders/1URPHrOk9-UBsh8hjv-7WwC0W6Fy61uAJ
--
2.28.0.526.ge36021eeef-goog
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH 5/5] x86: edison: Add documentation for using am xFSTK image
2020-09-04 1:28 ` [PATCH 5/5] x86: edison: Add documentation for using am xFSTK image Simon Glass
@ 2020-09-04 9:43 ` Andy Shevchenko
0 siblings, 0 replies; 26+ messages in thread
From: Andy Shevchenko @ 2020-09-04 9:43 UTC (permalink / raw)
To: u-boot
On Thu, Sep 03, 2020 at 07:28:56PM -0600, Simon Glass wrote:
> Add a description of how to flash Edison using the XFSTK tool.
Switch to OSIP and mentioned DnX may affect the wording here, though I didn't
see if it really the case. Also, please update with using clean U-Boot version
(no Git hash, no dirty suffix).
After addressing,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> doc/board/intel/edison.rst | 120 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 120 insertions(+)
>
> diff --git a/doc/board/intel/edison.rst b/doc/board/intel/edison.rst
> index 1aee2a1fc0d..40acd80a051 100644
> --- a/doc/board/intel/edison.rst
> +++ b/doc/board/intel/edison.rst
> @@ -39,3 +39,123 @@ use.
> reset the board::
>
> => reset
> +
> +
> +Updating U-Boot using xFSTK
> +---------------------------
> +
> +You can also update U-Boot using the xfstk-dldr-solo tool if you can build it.
> +One way to do that is to follow the `xFSTK`_ instructions. You may need to use
> +a virtual machine running Ubuntu Trusty. Once you have built it and installed
> +libboost-all-dev, you can copy xfstk-dldr-solo to /usr/local/bin and
> +libboost_program_options.so.1.54.0 to /usr/lib/i386-linux-gnu/ and with luck
> +it will work. You might fine this `drive`_ helpful.
> +
> +If it does, then you can download and unpack the Edison reocovery image,
> +install dfu-util, reset your board and flash U-Boot like this::
> +
> + $ xfstk-dldr-solo --gpflags 0x80000007 \
> + --osimage u-boot-edison.img \
> + --fwdnx recover/edison_dnx_fwr.bin \
> + --fwimage recover/edison_ifwi-dbg-00.bin \
> + --osdnx recover/edison_dnx_osr.bin
> +
> +This should show the following
> +
> +.. code-block:: none
> +
> + XFSTK Downloader Solo 0.0.0
> + Copyright (c) 2015 Intel Corporation
> + Build date and time: Aug 15 2020 15:07:13
> +
> + .Intel SoC Device Detection Found
> + Parsing Commandline....
> + Registering Status Callback....
> + .Initiating Download Process....
> + .......(lots of dots)........XFSTK-STATUS--Reconnecting to device - Attempt #1
> + .......(even more dots)......................
> +
> +
> +You have about 10 seconds after resetting the board to type the above command.
> +If you want to check if the board is ready, type:
> +
> +.. code-block:: none
> +
> + lsusb |egrep "8087|8086"
> + Bus 001 Device 004: ID 8086:e005 Intel Corp.
> +
> +If you see a device with the same ID as above, the board is waiting for your
> +command.
> +
> +After about 5 seconds you should see some console output from the board:
> +
> +.. code-block:: none
> +
> + ******************************
> + PSH KERNEL VERSION: b0182b2b
> + WR: 20104000
> + ******************************
> +
> + SCU IPC: 0x800000d0 0xfffce92c
> +
> + PSH miaHOB version: TNG.B0.VVBD.0000000c
> +
> + microkernel built 11:24:08 Feb 5 2015
> +
> + ******* PSH loader *******
> + PCM page cache size = 192 KB
> + Cache Constraint = 0 Pages
> + Arming IPC driver ..
> + Adding page store pool ..
> + PagestoreAddr(IMR Start Address) = 0x04899000
> + pageStoreSize(IMR Size) = 0x00080000
> +
> + *** Ready to receive application ***
> +
> + After another 10 seconds the xFSTK tool completes and the board resets. About
> + 10 seconds after that should see the above message again and then within a
> + few seconds U-Boot should start on your board:
> +
> +.. code-block:: none
> +
> + U-Boot 2020.10-rc3-00032-gd9f6680e925-dirty (Sep 03 2020 - 18:44:28 -0600)
> +
> + CPU: Genuine Intel(R) CPU 4000 @ 500MHz
> + DRAM: 980.6 MiB
> + WDT: Started with servicing (60s timeout)
> + MMC: mmc at ff3fc000: 0, mmc at ff3fa000: 1
> + Loading Environment from MMC... OK
> + In: serial
> + Out: serial
> + Err: serial
> + Saving Environment to MMC... Writing to redundant MMC(0)... OK
> + Saving Environment to MMC... Writing to MMC(0)... OK
> + Net: No ethernet found.
> + Hit any key to stop autoboot: 0
> + Target:blank
> + Partitioning using GPT
> + Writing GPT: success!
> + Saving Environment to MMC... Writing to redundant MMC(0)... OK
> + Flashing already done...
> + 5442816 bytes read in 238 ms (21.8 MiB/s)
> + Valid Boot Flag
> + Setup Size = 0x00003c00
> + Magic signature found
> + Using boot protocol version 2.0c
> + Linux kernel version 3.10.17-poky-edison+ (ferry at kalamata) #1 SMP PREEMPT Mon Jan 11 14:54:18 CET 2016
> + Building boot_params at 0x00090000
> + Loading bzImage at address 100000 (5427456 bytes)
> + Magic signature found
> + Kernel command line: "rootwait root=PARTUUID=ada722ed-6410-764e-8619-abff6f66e10e rootfstype=ext4 console=ttyMFD2 earlyprintk=ttyMFD2,keep loglevel=4 g_multi.ethernet_config=cdc systemd.unit=multi-user.target hardware_id=00 g_multi.iSerialNumber=2249baf774c675598661a63098c0ad41 g_multi.dev_addr=02:00:86:c0:ad:41 platform_mrfld_audio.audio_codec=dummy"
> + Magic signature found
> +
> + Starting kernel ...
> +
> + ...
> +
> + Poky (Yocto Project Reference Distro) 1.7.2 edison ttyMFD2
> +
> + edison login:
> +
> +.. _xFSTK: https://community.intel.com/t5/Intel-Makers/Building-xFSTK-on-Ubuntu-14-04-32-bit-for-flashing-Edison/td-p/538081
> +.. _drive: https://drive.google.com/drive/u/0/folders/1URPHrOk9-UBsh8hjv-7WwC0W6Fy61uAJ
> --
> 2.28.0.526.ge36021eeef-goog
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 0/5] edison: Support for writing an xFSTK image
2020-09-04 1:28 [PATCH 0/5] edison: Support for writing an xFSTK image Simon Glass
` (4 preceding siblings ...)
2020-09-04 1:28 ` [PATCH 5/5] x86: edison: Add documentation for using am xFSTK image Simon Glass
@ 2020-09-04 9:46 ` Andy Shevchenko
2020-09-05 3:23 ` Simon Glass
2020-09-22 7:11 ` Bin Meng
6 siblings, 1 reply; 26+ messages in thread
From: Andy Shevchenko @ 2020-09-04 9:46 UTC (permalink / raw)
To: u-boot
On Thu, Sep 03, 2020 at 07:28:51PM -0600, Simon Glass wrote:
> At present it is painful to put Edison in a hardware lab because it has
> two separate recovery modes. When the board has a functioning U-Boot, DFU
> can be used. Otherwise an xFSTK image must be used.
>
> This series converts Andy's script to a binman description so that U-Boot
> can produce an xFSTK image directly.
>
> With this, I can put an Edison in my lab fairly easily.
>
> The series is available at u-boot-dm/edison-working and is based on the
> reset binman series for sunxi.
Thanks for doing this! It will reduce burden when unbricking the board!
I have few minor comments (individually per patch) and one ask to Cc next
version to Ferry Toth <fntoth@gmail.com>.
> [1] https://gist.github.com/andy-shev/2c388310f2773ead647d9c1a3f1c813f
>
>
> Simon Glass (5):
> x86: Use multiple images
> binman: Show an error when a file is missing
> binman: Support adding a U-Boot environment
> x86: edison: Generate an image suitable for xFSTK
> x86: edison: Add documentation for using am xFSTK image
>
> arch/x86/cpu/tangier/Kconfig | 1 +
> arch/x86/dts/edison.dts | 34 ++++++
> arch/x86/dts/u-boot.dtsi | 7 --
> board/intel/edison/edison-environment.txt | 48 +++++++++
> board/intel/edison/edison-mbr.dat | Bin 0 -> 512 bytes
> doc/board/intel/edison.rst | 120 ++++++++++++++++++++++
> tools/binman/etype/blob.py | 7 +-
> tools/binman/etype/u_boot_env.py | 42 ++++++++
> tools/binman/ftest.py | 38 +++++++
> tools/binman/test/173_missing_blob.dts | 14 +++
> tools/binman/test/174_env.dts | 20 ++++
> tools/binman/test/175_env_no_size.dts | 19 ++++
> tools/binman/test/176_env_too_small.dts | 20 ++++
> 13 files changed, 360 insertions(+), 10 deletions(-)
> create mode 100644 board/intel/edison/edison-environment.txt
> create mode 100644 board/intel/edison/edison-mbr.dat
> create mode 100644 tools/binman/etype/u_boot_env.py
> create mode 100644 tools/binman/test/173_missing_blob.dts
> create mode 100644 tools/binman/test/174_env.dts
> create mode 100644 tools/binman/test/175_env_no_size.dts
> create mode 100644 tools/binman/test/176_env_too_small.dts
>
> --
> 2.28.0.526.ge36021eeef-goog
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 0/5] edison: Support for writing an xFSTK image
2020-09-04 9:46 ` [PATCH 0/5] edison: Support for writing an " Andy Shevchenko
@ 2020-09-05 3:23 ` Simon Glass
2020-09-07 8:04 ` Andy Shevchenko
0 siblings, 1 reply; 26+ messages in thread
From: Simon Glass @ 2020-09-05 3:23 UTC (permalink / raw)
To: u-boot
Hi Andy,
On Fri, 4 Sep 2020 at 03:46, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Thu, Sep 03, 2020 at 07:28:51PM -0600, Simon Glass wrote:
> > At present it is painful to put Edison in a hardware lab because it has
> > two separate recovery modes. When the board has a functioning U-Boot, DFU
> > can be used. Otherwise an xFSTK image must be used.
> >
> > This series converts Andy's script to a binman description so that U-Boot
> > can produce an xFSTK image directly.
> >
> > With this, I can put an Edison in my lab fairly easily.
> >
> > The series is available at u-boot-dm/edison-working and is based on the
> > reset binman series for sunxi.
>
> Thanks for doing this! It will reduce burden when unbricking the board!
> I have few minor comments (individually per patch) and one ask to Cc next
> version to Ferry Toth <fntoth@gmail.com>.
OK will do.
I do have a question though. How does the board decide whether to wait
for the xFSTK tool to connect? Sometimes when I reset it it, it does.
Sometimes it goes straight into receiving application. I am not
pressing any button other than reset. Once it makes it mind up, it
seems to stick to it until the power is removed? But it is powered by
USB too, so removing power is not so easy.
Regards,
Simon
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 0/5] edison: Support for writing an xFSTK image
2020-09-05 3:23 ` Simon Glass
@ 2020-09-07 8:04 ` Andy Shevchenko
2020-09-07 13:57 ` Simon Glass
0 siblings, 1 reply; 26+ messages in thread
From: Andy Shevchenko @ 2020-09-07 8:04 UTC (permalink / raw)
To: u-boot
On Sat, Sep 5, 2020 at 6:23 AM Simon Glass <sjg@chromium.org> wrote:
> On Fri, 4 Sep 2020 at 03:46, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Thu, Sep 03, 2020 at 07:28:51PM -0600, Simon Glass wrote:
> I do have a question though. How does the board decide whether to wait
> for the xFSTK tool to connect? Sometimes when I reset it it, it does.
> Sometimes it goes straight into receiving application. I am not
> pressing any button other than reset. Once it makes it mind up, it
> seems to stick to it until the power is removed? But it is powered by
> USB too, so removing power is not so easy.
It's a good question. I don't know the answer unfortunately. I think
the parties that are involved here are PMIC and thus its firmware (I
don't have access to it and even if ask will not get), DnX protocol,
USB implementation on IFWI level (no access to me either). And I truly
believe there are bugs in all of them, though I dunno if they are
related to the above behaviour.
Btw, pressing the reset button helps?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 0/5] edison: Support for writing an xFSTK image
2020-09-07 8:04 ` Andy Shevchenko
@ 2020-09-07 13:57 ` Simon Glass
2020-09-07 14:12 ` Tom Rini
0 siblings, 1 reply; 26+ messages in thread
From: Simon Glass @ 2020-09-07 13:57 UTC (permalink / raw)
To: u-boot
Hi Andy,
On Mon, 7 Sep 2020 at 02:04, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>
> On Sat, Sep 5, 2020 at 6:23 AM Simon Glass <sjg@chromium.org> wrote:
> > On Fri, 4 Sep 2020 at 03:46, Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Thu, Sep 03, 2020 at 07:28:51PM -0600, Simon Glass wrote:
>
> > I do have a question though. How does the board decide whether to wait
> > for the xFSTK tool to connect? Sometimes when I reset it it, it does.
> > Sometimes it goes straight into receiving application. I am not
> > pressing any button other than reset. Once it makes it mind up, it
> > seems to stick to it until the power is removed? But it is powered by
> > USB too, so removing power is not so easy.
>
> It's a good question. I don't know the answer unfortunately. I think
> the parties that are involved here are PMIC and thus its firmware (I
> don't have access to it and even if ask will not get), DnX protocol,
> USB implementation on IFWI level (no access to me either). And I truly
> believe there are bugs in all of them, though I dunno if they are
> related to the above behaviour.
> Btw, pressing the reset button helps?
Pressing reset either boots quickly or waits 10 seconds for xFSTK to
connect. It's like cracking a code and I haven't cracked it yet. I'll
have another go at some point, and maybe finally get this board into
my lab.
Regards,
Simon
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 0/5] edison: Support for writing an xFSTK image
2020-09-07 13:57 ` Simon Glass
@ 2020-09-07 14:12 ` Tom Rini
2020-09-07 14:15 ` Simon Glass
0 siblings, 1 reply; 26+ messages in thread
From: Tom Rini @ 2020-09-07 14:12 UTC (permalink / raw)
To: u-boot
On Mon, Sep 07, 2020 at 07:57:12AM -0600, Simon Glass wrote:
> Hi Andy,
>
> On Mon, 7 Sep 2020 at 02:04, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> >
> > On Sat, Sep 5, 2020 at 6:23 AM Simon Glass <sjg@chromium.org> wrote:
> > > On Fri, 4 Sep 2020 at 03:46, Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Thu, Sep 03, 2020 at 07:28:51PM -0600, Simon Glass wrote:
> >
> > > I do have a question though. How does the board decide whether to wait
> > > for the xFSTK tool to connect? Sometimes when I reset it it, it does.
> > > Sometimes it goes straight into receiving application. I am not
> > > pressing any button other than reset. Once it makes it mind up, it
> > > seems to stick to it until the power is removed? But it is powered by
> > > USB too, so removing power is not so easy.
> >
> > It's a good question. I don't know the answer unfortunately. I think
> > the parties that are involved here are PMIC and thus its firmware (I
> > don't have access to it and even if ask will not get), DnX protocol,
> > USB implementation on IFWI level (no access to me either). And I truly
> > believe there are bugs in all of them, though I dunno if they are
> > related to the above behaviour.
> > Btw, pressing the reset button helps?
>
> Pressing reset either boots quickly or waits 10 seconds for xFSTK to
> connect. It's like cracking a code and I haven't cracked it yet. I'll
> have another go at some point, and maybe finally get this board into
> my lab.
On a tangent, when it comes to lab stuff I picked up
https://www.yepkit.com/products/ykush a while back precisely for "device
can be USB powered on purpose/accident" in order to have
software-controlled USB ports I can bring up/down.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200907/e6db814c/attachment.sig>
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 0/5] edison: Support for writing an xFSTK image
2020-09-07 14:12 ` Tom Rini
@ 2020-09-07 14:15 ` Simon Glass
2020-09-07 15:10 ` Andy Shevchenko
0 siblings, 1 reply; 26+ messages in thread
From: Simon Glass @ 2020-09-07 14:15 UTC (permalink / raw)
To: u-boot
Hi Tom,
On Mon, 7 Sep 2020 at 08:12, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Sep 07, 2020 at 07:57:12AM -0600, Simon Glass wrote:
> > Hi Andy,
> >
> > On Mon, 7 Sep 2020 at 02:04, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > >
> > > On Sat, Sep 5, 2020 at 6:23 AM Simon Glass <sjg@chromium.org> wrote:
> > > > On Fri, 4 Sep 2020 at 03:46, Andy Shevchenko
> > > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > > On Thu, Sep 03, 2020 at 07:28:51PM -0600, Simon Glass wrote:
> > >
> > > > I do have a question though. How does the board decide whether to wait
> > > > for the xFSTK tool to connect? Sometimes when I reset it it, it does.
> > > > Sometimes it goes straight into receiving application. I am not
> > > > pressing any button other than reset. Once it makes it mind up, it
> > > > seems to stick to it until the power is removed? But it is powered by
> > > > USB too, so removing power is not so easy.
> > >
> > > It's a good question. I don't know the answer unfortunately. I think
> > > the parties that are involved here are PMIC and thus its firmware (I
> > > don't have access to it and even if ask will not get), DnX protocol,
> > > USB implementation on IFWI level (no access to me either). And I truly
> > > believe there are bugs in all of them, though I dunno if they are
> > > related to the above behaviour.
> > > Btw, pressing the reset button helps?
> >
> > Pressing reset either boots quickly or waits 10 seconds for xFSTK to
> > connect. It's like cracking a code and I haven't cracked it yet. I'll
> > have another go at some point, and maybe finally get this board into
> > my lab.
>
> On a tangent, when it comes to lab stuff I picked up
> https://www.yepkit.com/products/ykush a while back precisely for "device
> can be USB powered on purpose/accident" in order to have
> software-controlled USB ports I can bring up/down.
Actually that's very relevant. I did try that with Edison and it
definitely does power off the board now. I keep thinking with just a
bit more messing around I can nut it out. My first board turned out to
have a problem with the slider switch which could have been part of
the issue.
Regards,
Simon
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 0/5] edison: Support for writing an xFSTK image
2020-09-07 14:15 ` Simon Glass
@ 2020-09-07 15:10 ` Andy Shevchenko
0 siblings, 0 replies; 26+ messages in thread
From: Andy Shevchenko @ 2020-09-07 15:10 UTC (permalink / raw)
To: u-boot
On Mon, Sep 07, 2020 at 08:15:13AM -0600, Simon Glass wrote:
> On Mon, 7 Sep 2020 at 08:12, Tom Rini <trini@konsulko.com> wrote:
> > On Mon, Sep 07, 2020 at 07:57:12AM -0600, Simon Glass wrote:
...
> > On a tangent, when it comes to lab stuff I picked up
> > https://www.yepkit.com/products/ykush a while back precisely for "device
> > can be USB powered on purpose/accident" in order to have
> > software-controlled USB ports I can bring up/down.
>
> Actually that's very relevant. I did try that with Edison and it
> definitely does power off the board now. I keep thinking with just a
> bit more messing around I can nut it out. My first board turned out to
> have a problem with the slider switch which could have been part of
> the issue.
Btw, seems you are using Edison/Arduino one. It has more (electrical) issues
that slider switch and so. I would recommend rather to buy another base board
for it, like SparkFun or DFRobot (I recently bought the latter one, i.e. IO
Expander for Intel Edison, and it works nicely, but I didn't check xFSTK
extensively, only DFU).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 0/5] edison: Support for writing an xFSTK image
2020-09-04 1:28 [PATCH 0/5] edison: Support for writing an xFSTK image Simon Glass
` (5 preceding siblings ...)
2020-09-04 9:46 ` [PATCH 0/5] edison: Support for writing an " Andy Shevchenko
@ 2020-09-22 7:11 ` Bin Meng
2020-09-22 22:03 ` Simon Glass
6 siblings, 1 reply; 26+ messages in thread
From: Bin Meng @ 2020-09-22 7:11 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Fri, Sep 4, 2020 at 9:28 AM Simon Glass <sjg@chromium.org> wrote:
>
> At present it is painful to put Edison in a hardware lab because it has
> two separate recovery modes. When the board has a functioning U-Boot, DFU
> can be used. Otherwise an xFSTK image must be used.
>
> This series converts Andy's script to a binman description so that U-Boot
> can produce an xFSTK image directly.
>
> With this, I can put an Edison in my lab fairly easily.
>
> The series is available at u-boot-dm/edison-working and is based on the
> reset binman series for sunxi.
>
> [1] https://gist.github.com/andy-shev/2c388310f2773ead647d9c1a3f1c813f
>
>
This series does not apply on u-boot-x86/next.
Is this due to "the reset binman series for sunxi" not applied yet?
Regards,
Bin
^ permalink raw reply [flat|nested] 26+ messages in thread* [PATCH 0/5] edison: Support for writing an xFSTK image
2020-09-22 7:11 ` Bin Meng
@ 2020-09-22 22:03 ` Simon Glass
2020-09-24 3:22 ` Bin Meng
0 siblings, 1 reply; 26+ messages in thread
From: Simon Glass @ 2020-09-22 22:03 UTC (permalink / raw)
To: u-boot
Hi Bin,
On Tue, 22 Sep 2020 at 01:11, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Simon,
>
> On Fri, Sep 4, 2020 at 9:28 AM Simon Glass <sjg@chromium.org> wrote:
> >
> > At present it is painful to put Edison in a hardware lab because it has
> > two separate recovery modes. When the board has a functioning U-Boot, DFU
> > can be used. Otherwise an xFSTK image must be used.
> >
> > This series converts Andy's script to a binman description so that U-Boot
> > can produce an xFSTK image directly.
> >
> > With this, I can put an Edison in my lab fairly easily.
> >
> > The series is available at u-boot-dm/edison-working and is based on the
> > reset binman series for sunxi.
> >
> > [1] https://gist.github.com/andy-shev/2c388310f2773ead647d9c1a3f1c813f
> >
> >
>
> This series does not apply on u-boot-x86/next.
>
> Is this due to "the reset binman series for sunxi" not applied yet?
Yes. It's in dm/next but I'll send a pull request upstream.
Regards,
Simon
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 0/5] edison: Support for writing an xFSTK image
2020-09-22 22:03 ` Simon Glass
@ 2020-09-24 3:22 ` Bin Meng
2020-09-24 3:27 ` Bin Meng
0 siblings, 1 reply; 26+ messages in thread
From: Bin Meng @ 2020-09-24 3:22 UTC (permalink / raw)
To: u-boot
On Wed, Sep 23, 2020 at 6:04 AM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Bin,
>
> On Tue, 22 Sep 2020 at 01:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Simon,
> >
> > On Fri, Sep 4, 2020 at 9:28 AM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > At present it is painful to put Edison in a hardware lab because it has
> > > two separate recovery modes. When the board has a functioning U-Boot, DFU
> > > can be used. Otherwise an xFSTK image must be used.
> > >
> > > This series converts Andy's script to a binman description so that U-Boot
> > > can produce an xFSTK image directly.
> > >
> > > With this, I can put an Edison in my lab fairly easily.
> > >
> > > The series is available at u-boot-dm/edison-working and is based on the
> > > reset binman series for sunxi.
> > >
> > > [1] https://gist.github.com/andy-shev/2c388310f2773ead647d9c1a3f1c813f
> > >
> > >
> >
> > This series does not apply on u-boot-x86/next.
> >
> > Is this due to "the reset binman series for sunxi" not applied yet?
>
> Yes. It's in dm/next but I'll send a pull request upstream.
Series applied to u-boot-x86/next, thanks!
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 0/5] edison: Support for writing an xFSTK image
2020-09-24 3:22 ` Bin Meng
@ 2020-09-24 3:27 ` Bin Meng
2020-09-25 1:00 ` Simon Glass
0 siblings, 1 reply; 26+ messages in thread
From: Bin Meng @ 2020-09-24 3:27 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Thu, Sep 24, 2020 at 11:22 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> On Wed, Sep 23, 2020 at 6:04 AM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Bin,
> >
> > On Tue, 22 Sep 2020 at 01:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Fri, Sep 4, 2020 at 9:28 AM Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > At present it is painful to put Edison in a hardware lab because it has
> > > > two separate recovery modes. When the board has a functioning U-Boot, DFU
> > > > can be used. Otherwise an xFSTK image must be used.
> > > >
> > > > This series converts Andy's script to a binman description so that U-Boot
> > > > can produce an xFSTK image directly.
> > > >
> > > > With this, I can put an Edison in my lab fairly easily.
> > > >
> > > > The series is available at u-boot-dm/edison-working and is based on the
> > > > reset binman series for sunxi.
> > > >
> > > > [1] https://gist.github.com/andy-shev/2c388310f2773ead647d9c1a3f1c813f
> > > >
> > > >
> > >
> > > This series does not apply on u-boot-x86/next.
> > >
> > > Is this due to "the reset binman series for sunxi" not applied yet?
> >
> > Yes. It's in dm/next but I'll send a pull request upstream.
>
> Series applied to u-boot-x86/next, thanks!
This seems to break the build.
Could you please help look at it?
https://dev.azure.com/bmeng/GitHub/_build/results?buildId=295&view=results
Regards,
Bin
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH 0/5] edison: Support for writing an xFSTK image
2020-09-24 3:27 ` Bin Meng
@ 2020-09-25 1:00 ` Simon Glass
0 siblings, 0 replies; 26+ messages in thread
From: Simon Glass @ 2020-09-25 1:00 UTC (permalink / raw)
To: u-boot
Hi Bin,
On Wed, 23 Sep 2020 at 21:27, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Simon,
>
> On Thu, Sep 24, 2020 at 11:22 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > On Wed, Sep 23, 2020 at 6:04 AM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Bin,
> > >
> > > On Tue, 22 Sep 2020 at 01:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Fri, Sep 4, 2020 at 9:28 AM Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > At present it is painful to put Edison in a hardware lab because it has
> > > > > two separate recovery modes. When the board has a functioning U-Boot, DFU
> > > > > can be used. Otherwise an xFSTK image must be used.
> > > > >
> > > > > This series converts Andy's script to a binman description so that U-Boot
> > > > > can produce an xFSTK image directly.
> > > > >
> > > > > With this, I can put an Edison in my lab fairly easily.
> > > > >
> > > > > The series is available at u-boot-dm/edison-working and is based on the
> > > > > reset binman series for sunxi.
> > > > >
> > > > > [1] https://gist.github.com/andy-shev/2c388310f2773ead647d9c1a3f1c813f
> > > > >
> > > > >
> > > >
> > > > This series does not apply on u-boot-x86/next.
> > > >
> > > > Is this due to "the reset binman series for sunxi" not applied yet?
> > >
> > > Yes. It's in dm/next but I'll send a pull request upstream.
> >
> > Series applied to u-boot-x86/next, thanks!
>
> This seems to break the build.
>
> Could you please help look at it?
> https://dev.azure.com/bmeng/GitHub/_build/results?buildId=295&view=results
OK yes it looks like I dropped a patch perhaps. I'll send a fix-up.
Regards,
Simon
^ permalink raw reply [flat|nested] 26+ messages in thread