[MinnowBoard] Minnowboard MAX with Dediprog em100 pro SPI emulator

[Simon Glass]

Hi,

On 19 January 2015 at 01:02, Krause Martin <Martin.Krause at tq-group.com> wrote:
> Hi Simon,
>
>> -----Ursprüngliche Nachricht-----
>> Von: elinux-MinnowBoard [mailto:elinux-minnowboard-
>> bounces at lists.elinux.org] Im Auftrag von Simon Glass
>> Gesendet: Sonntag, 18. Januar 2015 22:12
>> An: MinnowBoard Development and Community Discussion
>> Betreff: Re: [MinnowBoard] Minnowboard MAX with Dediprog em100 pro
>> SPI emulator
>>
>> Hi Martin,
>>
>> On 9 January 2015 at 00:06, Krause Martin <Martin.Krause at tq-group.com>
>> wrote:
>> > Hi,
>> >
>> >> On 7 January 2015 at 01:14, Krause Martin
>> >> <Martin.Krause at tq-group.com>
>> >> wrote:
>> >> > Hi Simon,
>> >> >
>> >> > I'm using both - the SF100 programmer and the EM100Pro emulator -
>> >> > on the Minnowboard Max with success.
>> >> >
>> >> > You could adapt the EM100Pro without soldering with the EM-TC-8
>> >> > SO8 Test Clip:
>> >> > http://www.dediprog.com/pd/programmer-accessories/EM-TC-8
>> >> > This clip is directly plugged "over" the SPI flash chip. With
>> >> > around
>> >> > 50 USD it is not really cheap, but you could save a lot of time
>> >> > during development if you have to update the BIOS a lot compared to
>> >> > the SF100
>> >> programmer.
>> >> >
>> >> > One erase-program cycle with the SF100 programmer needs around 85 s
>> >> > on my board (55 s for erase and 30 s for program). Compared to this
>> >> > it only takes 4-5 s to update the BIOS image in the EM100 emulator.
>> >> >
>> >>
>> >> In my case I'm only updating around 512KB each time so it should be
>> faster.
>> >> But still the EM100 is better.
>> >
>> > Since I've not mentioned it. My time measurement was to erase and
>> > program the whole Chip, which is 8 MiB.
>> >
>> >> > On the EM100Pro I configured the following to use it with the
>> >> > Minnowboard Max:
>> >> >
>> >> >   Memory Type: W25Q64DW, Manufacturer: Winbond, Size: 8192 (KB)
>> >> >   Hold Pin Status While Emulation: Default Low
>> >>
>> >> I'm not sure I have the hold pin status option - I'm using the 'em100'
>> >> Linux utility. Maybe I have an old version.
>> >
>> > I only know the windows utility, but since the EM100 is an emulator, I
>> > would assume, that it is the default to drive the hold pin low also
>> > with the Linux utility, to deactivate  all other devices which are
>> > connected to the SPI bus to not interfere with the emulator.
>> >
>> > On the Minnow Max board the hold pin is connected to VCC 1V8 over a
>> > 10k pull up, so you could pull this pin fix to ground without harm,
>> > for example if you connect the hold pin of the EM-TC-8 clip to ground.
>> > This should work without an soldering iron, but I do not think that
>> > this is necessary at all with the linux utility.
>> >
>> >> > And please note, that the EM100Pro does not support a SPI-Clock of
>> >> > 50 MHz. I configured all SPI-Clocks (Read, Write and Fast Read) in
>> >> > the Component Section of the BIOS Flash Descriptor to 20 MHz, when
>> >> > I use the EM100PRO (you could do this with the intel FITC tool when
>> >> > you combine the UEFI BIOS with the TXE firmware). If you use the
>> >> > prebuild Minnowboard Max images you do not need to worry about the
>> >> > SPI clock speed, because there the default seems already to be
>> >> > 20 MHz.
>> >> >
>> >>
>> >> Thanks very much for this info. I didn't realise that those clips
>> >> could overwrite the SPI flash chip. Maybe I don't need to break out
>> >> the soldering iron after all.
>> >
>> > If the hold pin of the SPI flash chip is pulled low, then the whole
>> > Chip goes into tri-state, thus behaves as if not placed. So the
>> > emulator which is connected over the EM-TC-8 clip replaces the flash chip.
>> >
>> > Please note that, the EM100 is no flash programmer, so it could not
>> > change the content of the onboard flash. It only emulates the flash
>> > for the time it is connected. If the emulator is unplugged, the system
>> > boots from the onboard flash again, with the original content of the
>> > flash.
>>
>> I got one of these clips and it seems to work well.
>>
>> Unfortunately the em100 utility that I have for Linux does not work - the
>> board does not boot. I found an old Windows XP laptop and managed to get
>> cygwin on it, so now I can scp the file each time and write it to the em100
>> with the cmdline tool. Horrible, but I can put up with it until I figure out the
>> problem. I suppose I could ssh to the windows machine and therefore do it
>> as part of my build flow.
> [Krause Martin]
>
> Thanks for the info! I unfortunately haven't used em100 under linux yet,
> so I don't have any tips for it.
>
> Within the windows tool there is a trace feature integrated, which logs all
> SPI communication on the bus between the flash and the emulator. Maybe
> you could figure out the not-booting-with-the-linux-utility problem by
> analyzing the SPI traffic - if the linux utility does alos have the trace feature.
> It helped me to figure out the fact, that the em100 does not support a
> 50 MHz clock, at least.

Actually it turns out that the em100 Linux utility does work I wonder
whether I just had some arguments wrong. The tracing feature seems
broken though - it displays a few lines and stops. I haven't dug into
it.

Thanks for the tip on tracing, it certainly helps. Once SPI caching is
turned on it seems to read ahead a few blocks (at least I assume that
is what is happening) which makes the trace less useful. But I have
managed to get into the FSP init black box, which is progress.

Regards,
Simon