Re: [Emutos-devel] Cold boot trouble on 1040STF

[Christian Z. <cz...@gm...>]

Christian Zietz schrieb:

> Again, I don't think I will be able to make much sense of it without a
> longer logic analyzer capture. Michael will provide one next weekend.
> Until then I can only scratch my head and try to come up with theories.

OK, I have one; a theory, unproven yet, that might explain all of it.

Recall that I said that at least a little bit of RAM could always be
accessed, regardless of the configuration the MMU starts up with? My
reasoning was correct for all *valid* MMU configurations; but
unfortunately there is one *invalid* configuration: all one bits in the
memory config register 0xFF8001. Studying my reverse-engineering notes
about the MMU shows that RAM access is most likely not generated there
-- I'd have to measure, though, to be sure.

Also note that the MMU has no RESET input to reset its internal
registers to known values. [1] Hence, the values in the config register
can be arbitrary; though each MMU will have a preferred value that
however depends on tolerances during the manufacturing process. Thus,
just because my MMU starts up with a valid configuration, this does not
mean that Michael's does as well.

If I force the my ST's MMU config register to 0xF right at the EmuTOS
startup, I can reproduce Michael's issue that EmuTOS does not start but
crashes very early. (Since the config value is preserved across a reset,
see [1], this also can explain why warm boots work for him.) In fact
with this invalid MMU config, EmuTOS crashes after the first exception,
because reading the correct exception vector of course needs working RAM.

The reason why this crash was seemingly during the cache config -- as
reported in my previous mails -- can be explained by the fact that I
inadvertently commented out the setting of the VBR in startup.S, which
would have caused an exception earlier on. (The "special Falcon reset",
i.e. accessing 0xffff8006 does not raise an exception on my ST, BTW.)

To confirm this theory, I a) have to be lucky that by chance my MMU
starts up with the invalid config and b) have to wait for the weekend,
where Michael can do further tests.

Regards
Christian

[1] I have confirmed by testing that register values are preserved
across a reset or even a short power-cycle, confirming that there is no
(working) reset logic for the registers inside the MMU.
-- 
Christian Zietz  -  CHZ-Soft  -  cz...@gm...
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA