30 Aug
2015
30 Aug
'15
8:55 a.m.
On 8/30/15 8:45 AM, Guy Sotomayor wrote:
On 8/30/15 12:50 AM, Henk Gooijen wrote:
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
-----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.