Date: Sun, 11 Oct 2020 23:41:15 -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: <59CDAD8F-52D6-481E-8C3C-8FF53F67CBC9@yahoo.com> In-Reply-To: <3BB0EA68-D46E-4B4B-85E0-8D2D1EFFE2AF@yahoo.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> <05BC0444-07EB-461C-AEEF-3ABED5F0FA54@yahoo.com> <3BB0EA68-D46E-4B4B-85E0-8D2D1EFFE2AF@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Oct-11, at 17:23, Mark Millard <marklmi at yahoo.com> wrote:
> On 2020-Oct-11, at 17:13, Mark Millard <marklmi at yahoo.com> wrote:
>=20
>>>=20
>>> On 2020-Oct-11, at 16:13, Robert Crowston <crowston at =
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.
>>=20
>> 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?
>>=20
>> The backtrace that you reported involves:
>>=20
>> case '|':
>> done_word(dest, ctx);
>> if (next=3D=3D'|') {
>> b_getch(input);
>> done_pipe(ctx,PIPE_OR);
>>=20
>> but having piped commands (|) seems possibly odd for the
>> context. Garbage memory content may be more likely.
>>=20
>=20
> My wording was poor because the done_pipe is actually for
> || (or) involving the (potential) pipe symbol.
Looking at a "it will boot" context, u-boot's
printenv does report one definition with || involved:
scan_dev_for_boot_part=3Dpart list ${devtype} ${devnum} -bootable =
devplist; env exists devplist || setenv devplist 1; for distro_bootpart =
in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} =
bootfstype; then run scan_dev_for_boot; fi; done; setenv devplist
So that might be the context for the parse stage associated with
the failure you gave a back-trace for.
=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?59CDAD8F-52D6-481E-8C3C-8FF53F67CBC9>