Date: Tue, 13 Oct 2020 18:13:08 -0700 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: 64-bit RPi4B u-boot hangup with modern rpi firmware: some information (but investigative-toolbox limited) Message-ID: <290E51C0-0AF5-4C75-AA7B-BA56DF1AFDFB@yahoo.com> References: <290E51C0-0AF5-4C75-AA7B-BA56DF1AFDFB.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I tried building u-boot with:
CONFIG_LOG=3Dy
CONFIG_LOG_CONSOLE=3Dy
CONFIG_LOG_MAX_LEVEL=3D7
and the first console output with the somewhat older
firmware (for which the combination boots) was:
initcall: 00000000000ec7b4
U-Boot 2020.10 (Oct 13 2020 - 20:26:59 +0000)
That is display_options, just after serial_init
and console_init_f are executed.
No such output occurs with more modern firmware
(same u-boot).
That means, in the 4 GIByte RPi4B context that
I have access to, that the hang up happens at
some point during the sequence of initialization
steps, on or before display_options:
static const init_fnc_t init_sequence_f[] =3D {
setup_mon_len,
#ifdef CONFIG_OF_CONTROL
fdtdec_setup,
#endif
#ifdef CONFIG_TRACE_EARLY
trace_early_init,
#endif
initf_malloc,
log_init,
initf_bootstage, /* uses its own timer, so does not need =
DM */
#ifdef CONFIG_BLOBLIST
bloblist_init,
#endif
setup_spl_handoff,
initf_console_record,
#if defined(CONFIG_HAVE_FSP)
arch_fsp_init,
#endif
arch_cpu_init, /* basic arch cpu dependent setup */
mach_cpu_init, /* SoC/machine dependent CPU setup */
initf_dm,
arch_cpu_init_dm,
#if defined(CONFIG_BOARD_EARLY_INIT_F)
board_early_init_f,
#endif
#if defined(CONFIG_PPC) || defined(CONFIG_SYS_FSL_CLK) || =
defined(CONFIG_M68K)
/* get CPU and bus clocks according to the environment variable =
*/
get_clocks, /* get CPU and bus clocks (etc.) */
#endif
#if !defined(CONFIG_M68K)
timer_init, /* initialize timer */
#endif
#if defined(CONFIG_BOARD_POSTCLK_INIT)
board_postclk_init,
#endif
env_init, /* initialize environment */
init_baud_rate, /* initialze baudrate settings */
serial_init, /* serial communications setup */
console_init_f, /* stage 1 init of console */
display_options, /* say that we are here */
. . .
I'll note that the use of the list is via:
void board_init_f(ulong boot_flags)
{
gd->flags =3D boot_flags;
gd->have_console =3D 0;
=20
if (initcall_run_list(init_sequence_f))
hang();
. . .
where:
/**
* hang - stop processing by staying in an endless loop
*
* The purpose of this function is to stop further execution of code =
cause
* something went completely wrong. To catch this and give some =
feedback to
* the user one needs to catch the bootstage_error (see =
show_boot_progress())
* in the board code.
*/
void hang(void)
{
#if !defined(CONFIG_SPL_BUILD) || \
(CONFIG_IS_ENABLED(LIBCOMMON_SUPPORT) && \
CONFIG_IS_ENABLED(SERIAL_SUPPORT))
puts("### ERROR ### Please RESET the board ###\n");
#endif
bootstage_error(BOOTSTAGE_ID_NEED_RESET);
if (IS_ENABLED(CONFIG_SANDBOX))
os_exit(1);
for (;;)
;
}
With the tools I have around, I do not see a way to
find out what was the last element of init_sequence_f
to (at least start to) be called (or if it stopped even
before initcall_run_list would start).
Note: CONFIG_LOG_MAX_LEVEL=3D7 (without something like
CONFIG_LOG_DEFAULT_LEVEL being a smaller figure) is not
reasonable for general use: Its output is massive.
=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?290E51C0-0AF5-4C75-AA7B-BA56DF1AFDFB>