Re: [PATCH 0/5] edison: Support for writing an xFSTK image
Hi Bin, On Wed, 23 Sep 2020 at 21:27, Bin Meng wrote: > > Hi Simon, > > On Thu, Sep 24, 2020 at 11:22 AM Bin Meng wrote: > > > > On Wed, Sep 23, 2020 at 6:04 AM Simon Glass wrote: > > > > > > Hi Bin, > > > > > > On Tue, 22 Sep 2020 at 01:11, Bin Meng wrote: > > > > > > > > Hi Simon, > > > > > > > > On Fri, Sep 4, 2020 at 9:28 AM 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. > > > > > > > > > > [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
Re: [PATCH 0/5] edison: Support for writing an xFSTK image
Hi Simon, On Thu, Sep 24, 2020 at 11:22 AM Bin Meng wrote: > > On Wed, Sep 23, 2020 at 6:04 AM Simon Glass wrote: > > > > Hi Bin, > > > > On Tue, 22 Sep 2020 at 01:11, Bin Meng wrote: > > > > > > Hi Simon, > > > > > > On Fri, Sep 4, 2020 at 9:28 AM 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. > > > > > > > > [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
Re: [PATCH 0/5] edison: Support for writing an xFSTK image
On Wed, Sep 23, 2020 at 6:04 AM Simon Glass wrote: > > Hi Bin, > > On Tue, 22 Sep 2020 at 01:11, Bin Meng wrote: > > > > Hi Simon, > > > > On Fri, Sep 4, 2020 at 9:28 AM 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. > > > > > > [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!
Re: [PATCH 0/5] edison: Support for writing an xFSTK image
Hi Bin, On Tue, 22 Sep 2020 at 01:11, Bin Meng wrote: > > Hi Simon, > > On Fri, Sep 4, 2020 at 9:28 AM 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. > > > > [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
Re: [PATCH 0/5] edison: Support for writing an xFSTK image
Hi Simon, On Fri, Sep 4, 2020 at 9:28 AM 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. > > [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
Re: [PATCH 0/5] edison: Support for writing an xFSTK image
On Mon, Sep 07, 2020 at 08:15:13AM -0600, Simon Glass wrote: > On Mon, 7 Sep 2020 at 08:12, Tom Rini 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
Re: [PATCH 0/5] edison: Support for writing an xFSTK image
Hi Tom, On Mon, 7 Sep 2020 at 08:12, Tom Rini 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 > > wrote: > > > > > > On Sat, Sep 5, 2020 at 6:23 AM Simon Glass wrote: > > > > On Fri, 4 Sep 2020 at 03:46, Andy Shevchenko > > > > 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
Re: [PATCH 0/5] edison: Support for writing an xFSTK image
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 > wrote: > > > > On Sat, Sep 5, 2020 at 6:23 AM Simon Glass wrote: > > > On Fri, 4 Sep 2020 at 03:46, Andy Shevchenko > > > 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 signature.asc Description: PGP signature
Re: [PATCH 0/5] edison: Support for writing an xFSTK image
Hi Andy, On Mon, 7 Sep 2020 at 02:04, Andy Shevchenko wrote: > > On Sat, Sep 5, 2020 at 6:23 AM Simon Glass wrote: > > On Fri, 4 Sep 2020 at 03:46, Andy Shevchenko > > 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
Re: [PATCH 0/5] edison: Support for writing an xFSTK image
On Sat, Sep 5, 2020 at 6:23 AM Simon Glass wrote: > On Fri, 4 Sep 2020 at 03:46, Andy Shevchenko > 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
Re: [PATCH 0/5] edison: Support for writing an xFSTK image
Hi Andy, On Fri, 4 Sep 2020 at 03:46, Andy Shevchenko 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 . 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
Re: [PATCH 0/5] edison: Support for writing an xFSTK image
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 . > [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
[PATCH 0/5] edison: Support for writing an xFSTK image
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 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