MEM11 Status Update

[Guy Sotomayor]

On 8/30/15 8:45 AM, Guy Sotomayor wrote:
>
>
> On 8/30/15 12:50 AM, Henk Gooijen wrote:
>> -----Oorspronkelijk bericht----- From: Guy Sotomayor Sent: Sunday, 
>> August 30, 2015 7:05 AM To: General Discussion: On-Topic and 
>> Off-Topic Posts Subject: MEM11 Status Update
>> [... snip ...]
>> The biggest piece of work remaining on the emulator will be emulating 
>> the
>> Unibus interface.  The work here will mainly to create a means to script
>> various Unibus transactions.
>>
>> However, before doing that, I'll be testing out the boot loader code and
>> the configuration firmware since none of that is dependent upon the
>> existence of functional Unibus hardware.
>>
>> TTFN - Guy
>>
>> ------------
>> Guy,
>> as you have sort-of all possible UNIBUS transactions because
>> of the devices supported by the MEM11, I guess there is still
>> so work to do ;-)
>> One question came to my mind.
>> Suppose I manage to "crash" the board in such a bad way that
>> it does not start up anymore. Is there a jumper to force it to
>> execute a "golden boot"? That is, load a minimal "kernel" to
>> bring the MEM11 back to life to reload the bootloader and
>> firmware?
>> Shipping a dead MEM11 back to the Creator inside USA is
>> OK, but from Europe etc. might get costly. And Customs
>> probably wants to put tax on it when shipped back from you.
>>
>
> Yea, I'm trying to avoid having folks to send stuff back to me.
>
> The FRAM map that I'm currently working with has locations
> for 5 complete firmware images.  The bootloader and Config
> Mode firmware all have support for this.  Here's what they are for:
>      - 2 sets of Config Mode images.  This allows for downloading
>         a new image while still keeping the previous one around.
>      - 2 sets of Run Mode images.  This allows for downloading
>         a new image while still keeping the previous one around.
>      - a "safe" Config Mode image.  This image will be used when
>         the jumpers are set to "safe" mode or the boot loader
>         determines that the selected image isn't bootable.  This
>         image is *not* writable by the MEM11 firmware.  I *may*
>         decide to physically write protect it (the FRAM allows me to
>         write protect sections).
>
> I'm seriously contemplating putting something in the cold boot
> code (initial J1 RAM contents) that allows for downloading
> image contents into FRAM.  This would help me out when I'm
> bringing up an individual board for the first time (ie manufacturing).
> It would also allow for recovery if the safe boot image became
> corrupted for some reason.
>
> I'm hoping that with all of the above, the only time a board would
> have to be shipped back to me would be in the case of a HW failure.
>
I also forgot to mention that the cold boot code is contained within
the FPGA bitstream.  So if the cold boot code is corrupted, the FPGA
probably won't be programmed properly.  However, the FPGA bitstream
is located in its own flash part which is not writable/accessable by
the firmware.  It's only accessible through JTAG.  There will be a
header on the board since I won't have the flash parts pre-programmed
and it also allows me to update the FPGA bitstream after the board
has been built.

So, if the cold boot code doesn't run, I'd consider that a hardware
failure that would require the board to be sent back.  I'm hoping
that doesn't happen too often.  ;-)

TTFN - Guy