view target-utils/compalstage/compalstage.S @ 965:2969032bdfac

fcup-smsend[mult]: fix buglet in K&R C NULL pointer passing The only 100% safe way to pass a NULL pointer as a function argument in K&R C is to cast 0 to a pointer type; failing to do so may cause mysterious bugs (invalid stack frames or garbage in argument registers) on 64-bit machines. This issue has already been fixed in most of FC host tools, but I just found some missed spots: passing of NULL UDH to PDU encoding functions in fcup-smsend[mult] in the case of single (not concatenated) SMS.
author Mychaela Falconia <falcon@freecalypso.org>
date Fri, 01 Sep 2023 07:33:51 +0000
parents 21eec7569eb8
children
line wrap: on
line source

	.text
	.org	0

#if THUMB_ENTRY
	.code	16
	bx	pc
	nop
#endif
	.code	32

/* delay loop like OsmocomBB does */
	mov	r1, #0xa0000
1:	subs	r1, r1, #1
	bne	1b
/* enable the Calypso boot ROM */
	ldr	r1, reg_addr
	mov	r2, #0x0100
	strh	r2, [r1]
/* jump to it! */
	mov	pc, #0
reg_addr:
	.word	0xFFFFFB10

#if PAD_TO_1003
/*
 * The older and most familiar versions of C139/140 boot code expect the
 * signature bytes to be "1003" or greater, but a recently encountered
 * newer version expects them to be "1004" or greater instead.  As the
 * actual comparison check in all currently known boot code versions is
 * an inequality (the signature bytes in the downloaded image need to be
 * greater than or equal to the hard-coded reference values), always
 * putting "1004" in our compalstage image instead of "1003" should satisfy
 * all existing C1xx boot code versions, or at least all currently known
 * ones.  However, having an image named compalstage-1003.bin with the
 * corresponding -c 1003 loadtools option that is actually "1004" inside
 * feels a little "wrong" in some sense, while getting rid of the -c 1003
 * option would break old user instructions, hence let's go ahead and do the
 * silly exercise of building both "1003" and "1004" versions.
 */
	.org	0x3be0
#if MAGIC_1004
	.ascii	"1004"
#else
	.ascii	"1003"
#endif
#endif