On Sat, Jun 06, 2026 at 07:55:48AM -0600, Simon Glass wrote: > On Mon, 1 Jun 2026 at 04:17, Andy Shevchenko > <[email protected]> wrote: > > On Sun, May 31, 2026 at 08:31:38PM -0600, Simon Glass wrote:
> > > I've dusted off the Edison and have confirmed that it starts up: ... > > > 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@ff3fc000: 0, mmc@ff3fa000: 1 > > > Loading Environment from MMC... OK > > > In: serial > > > Out: serial > > > Err: serial > > > Net: No ethernet found. > > > Hit any key to stop autoboot: 0 > > > => > > > > > > Now I can see the instructions in doc/board/intel/edison.rst but I am > > > not sure how to translate that into a lab. Basically I have: > > > > > > - UART > > > - Relay hooked up to the RESET button (SW1 U15) > > > - power control > > > > > > The instructions in edison.rst are quite complex. I can run the > > > xfstk-dldr-solo tool but I don't want to have to download and install > > > a recovery image even time I want to try a new U-Boot > > > > > > Basically what I want is to be able to send U-Boot to the board over > > > USB and then have it boot into that U-Boot. It seems that once U-Boot > > > is installed the board behaves differently, but there must be a way > > > around that. > > > > If you need just U-Boot and you don't care about its default environment > > the `dfu-util` is the only what you need. > > > > Note, I have a helper script to setup U-Boot environment here: > > https://gist.github.com/andy-shev/2c388310f2773ead647d9c1a3f1c813f > > > > It has comments and examples how to do in different scenarios (working DFU > > and recovery). > > > > Based on your experience, please, feel free to update documentation to make > > it easier, because the process is not so complex. The current one most > > likely > > describes more steps that are needed for the old U-Boot (which came on a > > stock > > image in 2014) to replace. > > OK, so after a considerable amount of effort this is what I have found: > > I have Edison OTG/DFU on a Coolgear per-power power hub, plugged > straight into the lab machine (no hub). The 1-hub depth (board -> hub > -> host) seems to be required for reliable xfstk DnX transfers. > > The board seems happy drawing power through the OTG VBUS (the > Coolgear), so does not need the power connector to be powered (at > least until it uses too many watts). In any case both must be off for > the board to actually power off. Yes, both mini-B connectors add to the power, so the board is required to be fully off the connections in order to get coldboot. > There are two cases: > 1. A bricked board auto-enters DnX (8086:e005) on power-up - no straps needed. > 2. FM/RM straps are only to force a HEALTHY board into recovery. > > However, from the point of view of my lab, I can't assume the board is > healthy and handling case (2) adds complexity. > > So I run: > > sudo xfstk-dldr-solo --gpflags 0x80000007 --osimage u-boot-edison.img \ > --fwdnx edison_dnx_fwr.bin --fwimage edison_ifwi-dbg-00.bin \ This is not needed as long as you have the firmware block correct, otherwise you wear off the eMMC quicker. > --osdnx edison_dnx_osr.bin --verbose > > then power-cycle via the Coolgear; it flashes IFWI + U-Boot and the > board comes up as 8087:0a99 with a full dfu-util alt list, including > u-boot0 > > I also need a udev rule, of course. True, this is somewhere documented, but maybe not in U-Boot documentation. > I ended up with some rather complex Labgrid logic (no chance of > upstreaming it, but I suppose that's OK). I also created a Binman > etype. Building the image with binman, I found the OSIP sector also > needs a valid GPT-protective MBR (a 0xee entry) or the ROM won't boot > it. > > Finally I found that the board doesn't actually boot on mainline for > me. It might be that some patches as usually broke it as there is lack of testing. > I suspect I am doing something wrong, but in any case I am going > to send a small series for your review. > > Here's the successful job: > > https://concept.u-boot.org/u-boot/u-boot/-/jobs/524065 Wow, thanks for the efforts! The problem is I can't see anything right now: HTTP 502: Waiting for GitLab to boot It can take up to a few minutes for GitLab to boot completely. This page will automatically reload every 5 seconds. -- With Best Regards, Andy Shevchenko
