| Message ID | 20200904012856.1175506-1-sjg@chromium.org |
|---|---|
| Headers | show |
| Series | edison: Support for writing an xFSTK image | expand |
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 >
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
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?
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
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.
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
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).
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
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
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!
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
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