On Fri, Jan 12, 2018 at 07:30:16AM +1100, Anthony Nixon wrote:
> [...]
> It never occurred to me that a boot loader can rewrite over the top of
> itself. To save myself a lot of code fuss, I tried this approach and
> it works fine.
>=20
> The only caveat is that the new boot code must not modify (or very
> carefully modify) any of the code target addresses that reside inside
> the operating part of the boot code.

Yes.  Reminds me of my youth pre-internet, on TRS-80, audio tape media
of a program was degrading and my audio-only copies were unreliable,
so I worked to understand the copy protection scheme.

The media contained a boot loader, followed by the main program with
byte XOR loaded backwards through memory.  The last part overwrote the
running boot loader, changing it from what it was originally but
letting it run to completion.

As it was executing from dynamic RAM, and the CPU had no cache, there
were no issues of concurrency.

Stepping forward to today, CPUs with cache may need a nudge to drop
their cache, and not changing the data being executed is certainly a
good way to avoid this uncertainty.

Vague recent memory of ARM product datasheets with internal Flash IP
that suggests, paraphrased, either "don't do that", or "you can really
do that because we thought about it."

--=20
James Cameron
http://quozl.netrek.org/
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.