FreeCalypso > hg > freecalypso-tools
view doc/Flash-boot-wa @ 465:003e48f8ebe1
rvinterf/etmsync/fsnew.c: cast 0 to (char *) for execl sentinel
I generally don't use NULL and use plain 0 instead, based on a "NULL
considered harmful" discussion on the classiccmp mailing list many aeons
ago (I couldn't find it, and I reason that it must have been 2005 or
earlier), but a recent complaint by a packager sent me searching, and I
found this:
https://ewontfix.com/11/
While I don't give a @#$% about "modern" systems and code-nazi tools,
I realized that passing a plain 0 as a pointer sentinel in execl is wrong
because it will break on systems where pointers are longer than the plain
int type. Again, I don't give a @#$% about the abomination of x86_64 and
the like, but if anyone ever manages to port my code to something like a
PDP-11 (16-bit int, 32-bit long and pointers), then passing a plain 0
as a function argument where a pointer is expected most definitely won't
work: if the most natural stack slot and SP alignment unit is 16 bits,
fitting an int, with longs and pointers taking up two such slots, then
the call stack will be totally wrong with a plain 0 passed for a pointer.
Casting the 0 to (char *) ought to be the most kosher solution for the
most retro systems possible.
| author | Mychaela Falconia <falcon@freecalypso.org> |
|---|---|
| date | Mon, 11 Feb 2019 00:00:19 +0000 |
| parents | efb93f3e4ac7 |
| children |
line wrap: on
line source
There is a tiny (120 bytes SREC file) program called flash-boot-wa that was written in the spring of 2017 for the purpose of working around a problem that happened on only one first-batch FCDEV3B board and never happened on any other board - but Murphy's law had it that this one troubled board just had to be the one on which my (Mother Mychaela's) very initial development and bring-up work was done. The defect exhibited on that one board was as follows: it had no problem booting serially (fc-iram, fc-loadtool, fc-xram) and it had no problem booting from flash in mode 0 (see the Flash-boot-modes article in the freecalypso-docs repository), but booting from flash in mode 1 (the flash boot mode used by FC Magnetite, which is our primary firmware) was troubled. The exact failure mode and the root cause were never solved, but the issue most likely involved the watchdog reset in some way (it occurs as part of flash boot mode 1 but not in mode 0 and not in serial downloading), and because Calypso's FDP output goes low during watchdog reset (or at least TI's CAL000 document says so), it is plausible that the root cause involved the Spansion flash chip getting unhappy as a result of being jerked with extra resets which don't meet its reset timing requirements. Our new FCDEV3B V2 boards no longer use Calypso's FDP output (it is left unconnected) and feature a new flash reset circuit of our own design that meets the reset timing requirements of our Spansion flash chip, hence the flash boot problem seen on that one FCDEV3B S/N 001 board is not expected to recur on any of our current or future boards. However, our little flash-boot-wa program is kept around: removing a previously-released 120-byte program for no good reason is not the way of FOSS. This flash-boot-wa program is loaded serially via fc-iram; it disables the boot ROM and jumps to address 0 (the opposite of what we do in compalstage for Mot C1xx phones), thereby indirectly booting the made-for-boot-mode-1 firmware image in the flash. The intended usage was as follows: fc-iram -h fcfam /dev/ttyXXX /opt/freecalypso/target-bin/flash-boot-wa.srec rvinterf It is also worth noting that fc-iram has been extended to support second program invokation just like fc-xram (used in the invokation line above) just for this peculiar use case. The flash-boot-wa.srec helper can also be booted via fc-xram.