FreeCalypso > hg > freecalypso-tools
view target-utils/compalstage/README @ 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 | 56b1bab3e09b |
| children |
line wrap: on
line source
FreeCalypso loadtools have been designed from the beginning to work through the Calypso chip's own boot ROM. This approach works great for Openmoko and Pirelli targets, but Compal phones unfortunately have this Calypso boot ROM disabled at the board level. To run our own code in these phones instead of booting the regular firmware, we need to go through Compal's own boot code. The latter allows loading code into IRAM and jumping to it, but not in the same way as how we do it through the Calypso boot ROM. One could argue that the "proper" way to support these Compal phones would be to build a different version of our loadagent that is designed to be loaded through Compal's boot code instead of the Calypso boot ROM, and then redesign our fc-loadtool and fc-xram utilities to work with different loadagents loaded in different ways on different target devices. But I don't feel like doing that - too invasive to the once-clean design of loadtools. Hence I am adopting a different solution that works in the same way as OsmocomBB's "chain loading": the IRAM image that is fed to Compal's boot code is not our real loadagent, but a tiny piece of code that enables the Calypso boot ROM and jumps to it. All loadtools host programs will include this optional "Compal stage" at the beginning, enabled for targets that need it, but will then always fall into the Calypso boot ROM IRAM download path. The approach I'm adopting is doubly inefficient for Mot C139/140 phones whose bootloader effectively requires that the downloaded image be ~15 KiB long even when we only need to download 32 bytes. But hey, our ultimate goal is to produce our own Calypso phones, rather than hack those made by diabolical manufacturers who do not Respect Your Freedom; running our own firmware on the Mot C139 is only a transitional step, so making fc-loadtool/fc-xram entry slower by a second or two is probably an acceptable price for keeping the code clean for the boot-ROM-enabled free world. In this directory we build the several different versions of compalstage needed for different C1xx models.