Date: Sun, 11 Oct 2020 17:13:52 -0700 From: Mark Millard <marklmi@yahoo.com> To: Robert Crowston <crowston@protonmail.com> Cc: Klaus Cucinauomo <maciphone2@googlemail.com>, Kyle Evans <kevans@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, "gonzo@freebsd.org" <gonzo@FreeBSD.org> Subject: Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]? Message-ID: <05BC0444-07EB-461C-AEEF-3ABED5F0FA54@yahoo.com> In-Reply-To: <pVDfTV9C_icBNLv2nwUHBdb_KAugcw9cmC2Gw9D4LCp3ujNCHOTtH3kIhlUTpZRlGymrxDaFr8YILkbiUG6cace4KR-k7fKi_IXTvwqzZxU=@protonmail.com> References: <2B1B21CB-1A63-42CE-8917-98870C88CACE@yahoo.com> <F8DBF042-FD57-4AE3-8F98-0E36945469A9@yahoo.com> <3E9D015B-5702-4A52-9366-49E20BDDA5F4@googlemail.com> <tN5C4jzmxPmrt22GDxOfVidCT4I48oCyxVjfwxOdPAZpkQC1qBbhegOnnbkamnvGD-x81AxG5CorI1NIzfLf-91zcgOmQR0WtLrJ83PJJtI=@protonmail.com> <E07B6781-50E3-4A52-B582-F9EE81FE6743@googlemail.com> <cbC3hMQdQvaguB9vLBwvByx3_6cRzhxoJrMKL56_7RBNdwwPBudHiZpwfDEqUz2w34Ksv-fuo-5Iq-_0L_lfNdR5YEZDYudY1YGvshFl3Co=@protonmail.com> <79AA6AB2-9FE6-4A80-9E72-F6D7B7E6803F@googlemail.com> <3577889D-3102-4B50-955B-798717F93F92@googlemail.com> <0m0EOJpW7j-ziTjqjNz5Ldul7r8DT9bCjmgmsm5-kr9dX5pt2PEoQrZcFJ9nxtB8YXpqdrBk2ecMIjfijv3DEV26M9fzu3nwwQ90msFZBmw=@protonmail.com> <22B0D423-CEF4-4B74-846D-6F668A0F0B9F@googlemail.com> <pVDfTV9C_icBNLv2nwUHBdb_KAugcw9cmC2Gw9D4LCp3ujNCHOTtH3kIhlUTpZRlGymrxDaFr8YILkbiUG6cace4KR-k7fKi_IXTvwqzZxU=@protonmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>=20
> On 2020-Oct-11, at 16:13, Robert Crowston <crowston@protonmail.com> =
wrote:
>=20
>>> mmc0 is current device
>>=20
>> should not be mmc0 if you boot from USB/SSD
>=20
> I'm still using sd cards.
>=20
> armstub or not has no effect. Seems like a counter is overflowing in =
the internals of malloc(). Not even when booting, just when interpreting =
the bootcmd. I tried raising CONFIG_SYS_MALLOC_F_LEN, but it didn't =
change much. The malloc() code in question is from 2002, so I doubt it's =
a bug there. I tried rolling back from HEAD to v2020.10. Same problem.
Are you able to look at the content of the boot command, or at least the =
beginning
of it? Does it look reasonable and have the expected termination at the =
expected
place?
The backtrace that you reported involves:
case '|':
done_word(dest, ctx);
if (next=3D=3D'|') {
b_getch(input);
done_pipe(ctx,PIPE_OR);
but having piped commands (|) seems possibly odd for the
context. Garbage memory content may be more likely.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?05BC0444-07EB-461C-AEEF-3ABED5F0FA54>