Flashing Edison

[Andy Shevchenko]

On Sat, Jun 06, 2026 at 07:55:48AM -0600, Simon Glass wrote:
> On Mon, 1 Jun 2026 at 04:17, Andy Shevchenko
> <andriy.shevchenko at linux.intel.com> 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 at ff3fc000: 0, mmc at 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