P2 BOOT SEQUENCE: Serial, Flash, SD, Taqoz

Cluso99

Chip,
I have been chatting with Peter J about the boot sequence and how to fit everything into the 16KB ROM and make it work nicely.

We need something a little more friendly and specific than what the boot currently does. Here are our ideas (Peter will comment on anything wrong or missing).

* No Pullup on P61 (CSn) then goto Serial
* No Pullup on P60 (CLK) then goto Flash
* (Pullup on P60 (CLK)) then goto SD

If Flash fails, revert to Serial
If SD fails, revert to Serial

FLASH:
No checksum as it's not required and makes it more difficult for tools. Instead, check for all $00's and all $FF's (ie blank) and if all $00's or all $FF's fail and revert to Serial.
Override (eg code is corrupt or buggy) can be done in parallel with Serial (downloader continually sending autobaud sequence until recognised).

SD:
No checksum. Check for "Prop" in MBR or VOL sector at offset $17C-$17F. If present, the sector contents from $080-$17F is presumed correct and loads the whole sector into COG at $000+ and then JMP $080. This makes the code simple to write to this location on the SD card.

Otherwise, the two files "_BOOT_P2.BIX" and "_BOOT_P2.BIY" are searched, and if found will be loaded into hub from $00000+ with an upper limit of HUB RAM less 16KB (ie this P2 will be (512-16)KB, and then 496 longs from Hub $00000+ will be copied to COG $000+ and then JMP $000.
If not found, or initialisation failure, then revert to Serial

Override (eg code is corrupt or buggy) can be done in parallel with Serial (downloader continually sending autobaud sequence until recognised).

SERIAL:
What we would like is for the Serial Interrupt to be enabled for both the Flash Loader and SD Loader, such that Serial is being checked in parallel to the Flash/SD loaders. This way, if the Flash/SD code contains a bug that locks the P2 in a loop somewhere, the Serial can preempt the Flash/SD loading.

The serial should wait for the autobaud characters. Once received, serial should look for the download sequence, and/or a <Ctrl-?> or <esc> (Peter to decide) to run TAQOZ. If there is ROM space, then I propose putting the monitor/debug code in there too. It will be run by a different <Ctrl-?) key (tbd).

Peter & I can work on this. I am free Wednesday & Thursday.

Chip, does this make sense to you???

jmg

Cluso99 wrote: »

FLASH:
No checksum as it's not required and makes it more difficult for tools. Instead, check for all $00's and all $FF's (ie blank) and if all $00's or all $FF's fail and revert to Serial

Are you talking about flash content, or flash presence ?
The present boot code, does not allow for reset exit variations, and it tries to infer from the status register.
I think more stable, is to loop polling for the JED ID, 0x9F, and if that timeouts ( only returning all $00's or all $FF's) then FLASH is not connected (pin is floating).
Anything not all $00.$ff in the 24b ID fields, is considered a connected flash device. Exact ID value does not matter.
A light pullup on MISO would make this more reliable - otherwise induced mains can give a false positive as it 'floats' from $0000 to $ffff.

A problem with "check for all $00's and all $FF's" on the flash content, is what value of all do you use ?

A direct binary image has unknown first byte, but it is reasonable to have a very simple [HeaderTag][LoadCount][Binaryimage...]

Now, the header tag has to match "P2v1" or whatever is chosen & a new/blank device will not.

I'm not sure
[HeaderTag][LoadCount][$ff-Checksum][Binaryimage...] is much more difficult, and should catch erased blocks type errors.

Cluso99 wrote: »

Chip,

* No Pullup on P61 (CSn) then goto Serial
* No Pullup on P60 (CLK) then goto Flash
* (Pullup on P60 (CLK)) then goto SD

Note some systems might add a pullup to CSn, to try to ensure power up/floating pins reset, does not select the device.
That makes CSn less than ideal as a decision pivot.

David Betz

Why have both TAQOS and a monitor. Seem to me they do the same thing except that TAQOS can also be used to write programs and the monitor can not.

jmg

Cluso99 wrote: »

SERIAL:
What we would like is for the Serial Interrupt to be enabled for both the Flash Loader and SD Loader, such that Serial is being checked in parallel to the Flash/SD loaders. This way, if the Flash/SD code contains a bug that locks the P2 in a loop somewhere, the Serial can preempt the Flash/SD loading.

The serial should wait for the autobaud characters. Once received, serial should look for the download sequence, and/or a <Ctrl-?> or <esc> (Peter to decide) to run TAQOZ. If there is ROM space, then I propose putting the monitor/debug code in there too. It will be run by a different <Ctrl-?) key (tbd).

How does a Serial interrupt enabled, work with Autobaud ?
ie, you do not know what baud rate is, so cannot yet set baud to enable the serial interrupt ?
Chip currently looks for ">" on a dual test of Edge/High basis, and derives Baud from that.
The expectation is nothing else will false-trigger that, so it can discard partial or wrong ASCII chars, of any baud.

Once the coarse baud is done on the first ">", there is provision for any following ">" to fine tune the baud, but they do need to be seen as ">" via the serial HW.
This is supposed to track RCFAST oscillator drift.


For fastest serial boot, the host will send continually repeating "> Prop_Chk 0 0 0 0 "
When P2 exits reset, it will autobaud trigger on the next whole ">" and then echo CR+LF+“Prop_Ver Au”+CR+LF

Peter Jakacki

I favor having a signature, a source address, and a byte count. That way the bootloader knows it isn't blank, knows where to load it from and how much. A destination could be used too although I'm not sure where other than location 0 we would load it but it might be useful. If the Flash has a header then that means that the actual image can be anywhere in the Flash and only loads what's required.

When it comes to loading from named SD files then I assume that the loader would be using the file size always and a signature in the boot sector.

However it is strapped for Flash or SD I believe that the serial line should always be checked for continuous synch characters so that serial can always override Flash or SD which may be buggy or simply in need of an update. Since SD needs some time to "warm up" then this check can be made while that is happening and even Flash loading and execution should be aborted but not delayed.

As for TAQOZ I will try to talk more about that on its thread but suffice to say that I can't see how this version of Forth can run from high memory since it uses a 16-bit wordcode to address most of the first 64kB of code and that still permits additional schemes for more code. So in view of this and the limited amount of ROM that we have (even P1 has 32kB) I am limiting TAQOZ to be copied into low memory from where it will run as a very useful tool in lieu of user code, not in conjunction with it. Hardware can certainly be debugged and if you had nothing else but a smartphone/tablet you could still program a P2 by pasting in plain text source code. However I would like to build a version of SPLAT into TAQOZ as a logic analyzer. Since Cluso's SD loader will be present there is no need for TAQOZ to support SD directly and also there is no room for it. If SD is present then a full version of Tachyon can be loaded that does handle FAT32 including file creation etc.

David Betz

Peter Jakacki wrote: »

I favor having a signature, a source address, and a byte count. That way the bootloader knows it isn't blank, knows where to load it from and how much. A destination could be used too although I'm not sure where other than location 0 we would load it but it might be useful. If the Flash has a header then that means that the actual image can be anywhere in the Flash and only loads what's required.

When it comes to loading from named SD files then I assume that the loader would be using the file size always and a signature in the boot sector.

However it is strapped for Flash or SD I believe that the serial line should always be checked for continuous synch characters so that serial can always override Flash or SD which may be buggy or simply in need of an update. Since SD needs some time to "warm up" then this check can be made while that is happening and even Flash loading and execution should be aborted but not delayed.

As for TAQOZ I will try to talk more about that on its thread but suffice to say that I can't see how this version of Forth can run from high memory since it uses a 16-bit wordcode to address most of the first 64kB of code and that still permits additional schemes for more code. So in view of this and the limited amount of ROM that we have (even P1 has 32kB) I am limiting TAQOZ to be copied into low memory from where it will run as a very useful tool in lieu of user code, not in conjunction with it. Hardware can certainly be debugged and if you had nothing else but a smartphone/tablet you could still program a P2 by pasting in plain text source code. However I would like to build a version of SPLAT into TAQOZ as a logic analyzer. Since Cluso's SD loader will be present there is no need for TAQOZ to support SD directly and also there is no room for it. If SD is present then a full version of Tachyon can be loaded that does handle FAT32 including file creation etc.

That's too bad. Isn't there a way to allow TAQOS to be resident in low memory but still allow applications to take advantage of it? Couldn't the application code be linked to a higher start address? Just how would an application take advantage of TAQOS anyway even ignoring the load address issues? Is there a way to call into TAQOS with a pointer to some Forth code to execute and have it return a result? Or would it be more appropriate for the application to extend TAQOS rather than having it call into it?

jmg

Peter Jakacki wrote: »

I favor having a signature, a source address, and a byte count. That way the bootloader knows it isn't blank, knows where to load it from and how much. A destination could be used too although I'm not sure where other than location 0 we would load it but it might be useful. If the Flash has a header then that means that the actual image can be anywhere in the Flash and only loads what's required.

So that becomes like this ?
[HeaderTag][LoadCount][FlashAddressOffset][P2Address][$ff-Checksum][Binaryimage...]
which is commonly
[HeaderTag][LoadCountBytes][0][0][$ff-Checksum][Binaryimage...]

if FlashAddressOffset is not 0 (packed Binary image), then a new CS+Read.Address command is needed.
I think that offset case should expect the same header structure - makes sense to have blobs location independent, except for offset ?

Cluso99

@jmg
Flash: I am referring to the data being all $00 or all $FF (ie blank). IIRC Flash reads all $FF but in case of future FLASH or equivalent that may read all $00, I think it prudent to check for both. If the preamble to the Flash fails, then it clearly should revert to Serial.

Note some systems might add a pullup to CSn, to try to ensure power up/floating pins reset, does not select the device.
That makes CSn less than ideal as a decision pivot.

There are always restrictions and caveats. The pullups are IMHO the best and simplest way. There are no internal fuses to check.

jmg

Cluso99 wrote: »

There are always restrictions and caveats. The pullups are IMHO the best and simplest way. There are no internal fuses to check.

Pullups are fine, the point was to not use CSn as one, as commonly designs already pull that up, for safety reasons.

Cluso99

On the way to work, I thought about the pullups/pulldowns with Flash/SD.

If Flash used
P61 = CSn (with pullup)
P60 = CLK (no pullup)
and the SD used
P61 = CLK (no pullup)
P60 = CSn (with pullup which can be internal to the card)
we would only require 1 pullup for either Flash or SD.

Now, by having a pullup on both P61 & P60, both Flash & SD could most likely co-exist. The boot should then assume Flash to be the priority and boot from it.

Cluso99

David Betz wrote: »

Why have both TAQOS and a monitor. Seem to me they do the same thing except that TAQOS can also be used to write programs and the monitor can not.

A monitor can examine and also load code (also in the examine output format, and in pnut display format). It can be simply called from the user program. But there needs to be space in the ROM for it.

TAQOZ is a special language so the user will need to understand TAQOZ. It looks like it will not be able to be called from the user program.

Tor

I thought the monitor would *be* TAQOZ (like the Forth that is the monitor for Sun boxes). If it's not then I'm scratching my head ast to why it's even needed.

cgracey

This is the sequence I think we should use:

if pull-up on P62 (CSn)

    (SPI or SD may be present)

    if neither pull-up nor pull-down on P61 (CLK)

        if SPI present
            read first 256 longs into cog RAM
            if data okay
                wait short time for serial (done?)
                no serial, execute data (done)
        else
            wait long time for serial (done)

    if pull-up on P61 (CLK)
        if SPI present
            read first 256 longs into cog RAM
            if data okay
                execute data (done)
        else
            wait long time for serial (done)

    if pull-down on P61 (CLK)
        if SD present
            read data from SD
            if data okay
                execute data (done)
        else
            power down (done)

else

    wait long time for serial (done)

You can see that if SD boot fails, we don't attempt serial, because an indeterminant amount of time as has passed by. By doing what JMG proposes, where we just keep sending the connect string until we get a response, we could recover to serial after an SD boot failure.

We need to figure out how/when to turn things over to TAQOZ. TAQOZ can relocate itself to lower memory, no problem.

What do you guys think?

cgracey

jmg wrote: »

Cluso99 wrote: »

There are always restrictions and caveats. The pullups are IMHO the best and simplest way. There are no internal fuses to check.

Pullups are fine, the point was to not use CSn as one, as commonly designs already pull that up, for safety reasons.

But they only pull-up P61 CSn if they've got some memory connected, in which case we pursue booting from it.

No pull up on P61 means NO memory is connected, so don't twiddle any more I/O's. Just wait for serial.

David Betz

Cluso99 wrote: »

David Betz wrote: »

Why have both TAQOZ and a monitor. Seem to me they do the same thing except that TAQOZ can also be used to write programs and the monitor can not.

A monitor can examine and also load code (also in the examine output format, and in pnut display format). It can be simply called from the user program. But there needs to be space in the ROM for it.

TAQOZ is a special language so the user will need to understand TAQOZ. It looks like it will not be able to be called from the user program.

I think TAQOZ can do all of those things and more. Simple monitor-like commands will be simple in TAQOZ. You only get into complexity when you want to write programs and you can't even do that at all with a monitor. TAQOZ should be a superset of any monitor you might be able to provide. Peter will have to comment on a program being able to call into TAQOZ. He's already said it will live in low memory but maybe it can have some callable code in the 16K reserved for debug.

David Betz

Cluso99 wrote: »

A monitor can examine and also load code (also in the examine output format, and in pnut display format).

I missed this. Do you mean the monitor will have a disassembler? That would be helpful. Does TAQOZ have one?

ozpropdev

BTW Ihave a interactive debugger for P2 V32b that has a FULL disassembler that supports user test code register names.
Here's a sample disas output.

(P2 Debugger V3.29_V32b)================================================================================================
00000: F6043C00              MOV     result0,#$000
Flags (CZ) = __
>DIS 0 F
00000: F6043C00              MOV     result0,#$000
00001: F6043E00              MOV     result1,#$000
00002: F780401C              ENCOD   length,myreg
00003: F1044001              ADD     length,#$001
00004: F6004220              MOV     shift,length
00005: F2C44220              SUBR    shift,#$020
00006: F0603821              SHL     myreg,shift
00007: FCDC0A08              REP     #$005,#$008
00008: F8783A1E              GETNIB  myreg2,result0,#7
00009: F21C3A04              CMP     myreg2,#$004 WCZ
0000A: 11043A03 IF_NC_AND_NZ ADD     myreg2,#$003
0000B: F8383C1D              SETNIB  result0,myreg2,#7
0000C: F0243C04              ROL     result0,#$004
0000D: FB943E08              TJZ     result1,#$008 (8)
0000E: F8403A1F              GETNIB  myreg2,result1,#0
0000F: F21C3A04              CMP     myreg2,#$004 WCZ

I hope to finish the docs for this in the next few days and post the code.
The debugger is rich in features and uses the hardware single-step and break features of the P2.
Support for bytecode engine debug is also included.

Dave Hein

How does your debugger get the symbolic names such as myreg, length, shift and result1? Do you extract a symbol table from the source code?

ErNa

we should not hesitate as we see, the world is not perfect. Generations following us will solve issues we event don't know and they will ask, how was it possible to create such a processor in such a short time at such an early time in history. Like we still ask, how the Egyptian managed wireless communication as we never found residues of wires, that could be tapped. So let us go forward and overcome the dark age of current P and enter a bright future. And I'm not sure if the current P will resign or the P2 will come down to earth first, and what I should ask for in my daily prayer ;-)

ozpropdev

Dave Hein wrote: »

How does your debugger get the symbolic names such as myreg, length, shift and result1? Do you extract a symbol table from the source code?

I simply add the required names into hub like so

'Watchlist addresses and text labels.

watchlist		long	myreg
			long	myreg2
			long	length
			long	shift
			long	result1
			long	result0
			long	-1
	

'text labels for watchlist above (Must be in same order as above.)

w_labels		byte	"myreg",0
			byte	"myreg2",0
			byte	"length",0
			byte	"shift",0
			byte	"result1",0
			byte	"result0",0
eol			byte	$ff		'label end marker

The disassembler checks reg addresses for a match and inserts the names.

Dave Hein

OK. It's not as automatic as I'd like, but the symbols could be extracted with a utility and then inserted into the code.

Cluso99

David Betz wrote: »

Cluso99 wrote: »

A monitor can examine and also load code (also in the examine output format, and in pnut display format).

I missed this. Do you mean the monitor will have a disassembler? That would be helpful. Does TAQOZ have one?

My monitor outputs and inputs in this format (3 digits for cog & lut, 5 digits for hub). Input is WIP tomorrow (I had it working before P2Hot).

  000- 00 FE 65 FD 00 00 00 00 1A 6C 60 FD C2 EB 0B FF  '..e......l`.....'
  004- 00 6C 64 FA 24 22 60 FD 00 5B 01 FF 07 C0 07 F6  '.ld.$"`..[......'
  008- 00 40 A0 FD 00 C0 07 F6 48 40 A0 FD 80 C2 07 F6  '.@......H@......'

00000- 00 FE 65 FD 00 00 00 00 1A 6C 60 FD C2 EB 0B FF  '..e......l`.....'
00010- 00 6C 64 FA 24 22 60 FD 00 5B 01 FF 07 C0 07 F6  '.ld.$"`..[......'
00020- 00 40 A0 FD 00 C0 07 F6 48 40 A0 FD 80 C2 07 F6  '.@......H@......'
00030- 22 00 00 FF 5A C4 07 F6 DC 40 A0 FD A1 A7 23 FF  '"...Z....@....#.'

The monitor can be called by a user program to LIST code with parameters, or the monitor can be called to be interactive with the user via serial. The monitor can also be called to read a character or a string, as well as sending a character, string, hex or list (dump) cog, lut or hub with from/to addresses.
So, the monitor provides user callable routines which run in hubexec ROM. They require 16 cog longs at $1E0-$1EF for parameter passing and workarea for the hubexec routines.

Please tell me if you are not interested, as I will need to finish the input routine tomorrow. All else is working and has been tested. Here is a link to more info...

I don't know how much space Peter will require for TAQOZ, and if my monitor will fit with TAQOZ. Peter and I intend to chat tomorrow.

I had a disassembler in my monitor for P2 prior to P2Hot.

Ozprop now has a disassembler for V32, so there is no point in redoing it. His also works with single-step and break.

Cluso99

cgracey wrote: »

This is the sequence I think we should use:

if pull-up on P62 (CSn)

    (SPI or SD may be present)

    if neither pull-up nor pull-down on P61 (CLK)

        if SPI present
            read first 256 longs into cog RAM
            if data okay
                wait short time for serial (done?)
                no serial, execute data (done)
        else
            wait long time for serial (done)

    if pull-up on P61 (CLK)
        if SPI present
            read first 256 longs into cog RAM
            if data okay
                execute data (done)
        else
            wait long time for serial (done)

    if pull-down on P61 (CLK)
        if SD present
            read data from SD
            if data okay
                execute data (done)
        else
            power down (done)

else

    wait long time for serial (done)

You can see that if SD boot fails, we don't attempt serial, because an indeterminant amount of time as has passed by. By doing what JMG proposes, where we just keep sending the connect string until we get a response, we could recover to serial after an SD boot failure.

We need to figure out how/when to turn things over to TAQOZ. TAQOZ can relocate itself to lower memory, no problem.

What do you guys think?

Chip,
I don't see why we cannot revert to serial if SD fails.
The same applies to Flash. If it fails, then revert to serial.

Why can't we...

Check for pullups on P60 & P61. This check is not going to interfere with either Flash or SD.

if no pullups then
    wait long time for serial (done)
else if pullup on P61 (Flash) then
    wait short time for serial, if found set serial-found-flag 
    --and in parallel in another cog--
    read first 256 longs into cog RAM (Flash P61=CSn, P60=CLK, P59=DO, P58=DI)
    if data okay 
        if not serial-found-flag
                execute data (done)
        else
            clear serial-found-flag
            stop cog
    else
        wait long time for serial (done)
        stop cog
else if pullup on P60 (SD) then
    wait short time for serial, if found set serial-found-flag 
    --and in parallel in another cog--
    read SD (P61=CLK, P60=CSn, P59=DO, P58=DI)
    if data okay 
        if not serial-found-flag
                execute data (done)
        else
            clear serial-found-flag
            stop cog
    else
        wait long time for serial (done)
        stop cog
end

The P2 has multiple cogs, so why not use them

The code to check for autoboard can set the serial-found-flag. If Flash or SD is attempting to boot, it does not need to respond to the serial until the flag is cleared by the Flash/SD code.

So Flash & SD boot code just needs to check the flag before continuing to execute. This overcomes the problem where Flash or SD could overwrite serial code downloaded. Serial would overwrite any code read by flash/sd.

This allows for the situation where the Flash (or for that matter SD) code is corrupt/buggy and we want to override the flash/sd code with new downloaded code. No need for a pullup or no-pullup, so we don't have to modify a pcb to override the flash code!!!

Cluso99

Chip said...
We need to figure out how/when to turn things over to TAQOZ. TAQOZ can relocate itself to lower memory, no problem.

Hopefully, once serial autobauds (receives "< "), then a Ctl-? or Esc could be used to jump straight into TAQOZ. If we have my monitor too, then a different Ctl-? could invoke the monitor.

Peter & I will try to work thru this tomorrow. Are you available Chip?

cgracey

Cluso99 wrote: »

Chip said...
We need to figure out how/when to turn things over to TAQOZ. TAQOZ can relocate itself to lower memory, no problem.

Hopefully, once serial autobauds (receives "< "), then a Ctl-? or Esc could be used to jump straight into TAQOZ. If we have my monitor too, then a different Ctl-? could invoke the monitor.

Peter & I will try to work thru this tomorrow. Are you available Chip?

Yes, I am available. Just pm me.

jmg

Cluso99 wrote: »

Why can't we...

Check for pullups on P60 & P61. This check is not going to interfere with either Flash or SD.

if no pullups then
    wait long time for serial (done)
else if pullup on P61 (Flash) then
    wait short time for serial, if found set serial-found-flag 
    --and in parallel in another cog--
    read first 256 longs into cog RAM (Flash P61=CSn, P60=CLK, P59=DO, P58=DI)
    if data okay 
        if not serial-found-flag
                execute data (done)
        else
            clear serial-found-flag
            stop cog
    else
        wait long time for serial (done)
        stop cog
....

Don't forget the time to exit reset varies, so the code needs to include the reset-from-Quad, and flash-is-awake test (SD may need similar)

if no pullups then
    wait long time for serial (done)
else if pullup on P61 (Flash) then
    Reset preamble, exit Quad/Dual SPI, also possible to have hardware reset exit 
    poll N times for the JED ID, 0x9F - exit when ID <> 000000 or 0xffffff, timeout is no flash connected
    read first 256 longs into cog RAM (Flash P61=CSn, P60=CLK, P59=DO, P58=DI)
    if data okay 
         execute data (done)
    else
        wait long time for serial (done)
        stop cog
....

I would also be quite wary of any code like this

else if pullup on P61 (Flash) then
    wait short time for serial, if found set serial-found-flag 

That gives a simple attack vector, and also means any watchdog reset while a host is streaming serial data, can disturb a reboot.

msrobots

I also think it would be useful to have a pull up or down for permanently disable serial boot, while development it is important to have, but on a final product it might be nice to disable loading from serial.

And if TAQOZ can not coexist with other running software, it might be better to include @ozpropdev's debugger instead.

Else the P2 will go down as the FORTH processor and then we also can include the beany-propeller-hat.

Mike

jmg

msrobots wrote: »

I also think it would be useful to have a pull up or down for permanently disable serial boot, while development it is important to have, but on a final product it might be nice to disable loading from serial.

For someone wanting to have nimble (no hands) Serial/Flash/Serial/Flash mixed testing & development, perhaps a simple serial command that forces boot from flash can do ?
This simply jumps from serial parser, into the reset header of flash loader code.

I think "~" is `run from memory`, so another key char could be `load from flash and run` ( or 'Prop_fla 0 0 0 0 FlashStart FlashCount', if you tacked on to existing Prop_xxx keystrings ?
Addit:: and 'Prop_bsd 0 0 0 0 SDindex SDCount', for boot from SD ?


Very useful here could be a Code Start address and Byte count. Then a PC/host can use the boot command to select from a whole range of known firmware, saving flash wear.

jmg

cgracey wrote: »

jmg wrote: »

Pullups are fine, the point was to not use CSn as one, as commonly designs already pull that up, for safety reasons.

But they only pull-up P61 CSn if they've got some memory connected, in which case we pursue booting from it.
No pull up on P61 means NO memory is connected, so don't twiddle any more I/O's. Just wait for serial.

Well, yes... but I can see a use case where someone uses both a Serial small MCU for secure stage 1 loading, and a Flash memory.

In this case, the CSn pullup is there, but you want serial first.
ie can another pin like CLK or MOSI be used for the pullup, rather than CSn ?

Personally, I prefer to avoid a Serial within flash gateway, as that has watchdog issues and attack issues.

Hence the suggestion to also allow a command for `Serial mode to jump to flash boot` - useful for simple host firmware selection, and factory testing.

Seairth

It seems that there's still some work to be done on the new boot sequence. Assuming that it's easy to re-synthesize the ROM prior to final production, it seems that the prudent action right now would be to get the test chips made with a minimal boot ROM that provides only serial and a single external device (such as SPI flash). This would reduce the risk of unintended problems with the test chip due to rushed work, and would still allow development of the full-featured boot ROM for the production run.

jmg

Seairth wrote: »

It seems that there's still some work to be done on the new boot sequence. Assuming that it's easy to re-synthesize the ROM prior to final production, it seems that the prudent action right now would be to get the test chips made with a minimal boot ROM that provides only serial and a single external device (such as SPI flash). This would reduce the risk of unintended problems with the test chip due to rushed work, and would still allow development of the full-featured boot ROM for the production run.

Good question. Some ROMs are designed as top-layer only changes, not sure about this OnSemi ROM ?
It is also quite rare for chip vendors to release revision A parts to full production.

A related question is with the lowered logic usage, from refined timing, is there room to bump the ROM to more than 16k (32k? 48k? 64k?)