From: Konstantin Kletschke <konstantin.kletschke@inside-m2m.de>
To: Ahmad Fatoum <a.fatoum@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: Reset on Beaglebone Black has become unreliable/broken
Date: Wed, 4 Dec 2024 17:29:36 +0100 [thread overview]
Message-ID: <Z1CDcFAPdlDBkGJ5@hephaistos> (raw)
In-Reply-To: <f7b92750-f3ec-42d1-aacb-deaa6fb408d9@pengutronix.de>
On Wed, Dec 04, 2024 at 07:14:17AM +0100, Ahmad Fatoum wrote:
> Very interesting. You can now try to move the 4 putc_ll`s to a later point in the
> startup code and then see which line of barebox code needed the delay in front of
> it.
Dear Ahmad, I will try my best to put across what I did to the code and
where I get exactly stuck.
There is lowlevel.c with beaglebone_sram_init():
am33xx_uart_soft_reset((void *)AM33XX_UART0_BASE);
am33xx_enable_uart0_pin_mux();
omap_debug_ll_init();
putc_ll('>');
putc_ll('6');
// putc_ll('6');
barebox_arm_entry(0x80000000, sdram_size, fdt);
Then I went to uncompress.c where there is barebox_pbl_start():
void *handoff_data;
putc_ll('A');
/* piggy data is not relocated, so determine the bounds now */
pg_start = runtime_address(input_data);
pg_end = runtime_address(input_data_end);
/*
* If we run from inside the memory just relocate the binary
* to the current address. Otherwise it may be a readonly location.
* Copy and relocate to the start of the memory in this case.
*/
if (pc > membase && pc - membase < memsize)
relocate_to_current_adr();
else
relocate_to_adr(membase);
pg_len = pg_end - pg_start;
uncompressed_len = get_unaligned((const u32 *)(pg_start + pg_len - 4));
putc_ll('B');
setup_c();
putc_ll('C');
pr_debug("memory at 0x%08lx, size 0x%08lx\n", membase, memsize);
putc_ll('D');
if (IS_ENABLED(CONFIG_MMU))
mmu_early_enable(membase, memsize);
In mmu_32.c there is mmu_early_enable():
set_ttbr(ttb);
putc_ll('E');
/* For the XN bit to take effect, we can't be using DOMAIN_MANAGER. */
if (cpu_architecture() >= CPU_ARCH_ARMv7)
set_domain(DOMAIN_CLIENT);
else
set_domain(DOMAIN_MANAGER);
putc_ll('F');
/*
* This marks the whole address space as uncachable as well as
* unexecutable if possible
*/
create_flat_mapping();
putc_ll('G');
/* maps main memory as cachable */
early_remap_range(membase, memsize - OPTEE_SIZE, MAP_CACHED);
putc_ll('H');
early_remap_range(membase + memsize - OPTEE_SIZE, OPTEE_SIZE, MAP_UNCACHED);
putc_ll('I');
early_remap_range(PAGE_ALIGN_DOWN((uintptr_t)_stext), PAGE_ALIGN(_etext - _stext), MAP_CACHED);
putc_ll('J');
__mmu_cache_on();
putc_ll('K');
For early_remap_range() I end up in __arch_remap_range() there is:
u32 pte_flags, pmd_flags;
putc_ll('-');
uint32_t *ttb = get_ttb();
putc_ll('|');
BUG_ON(!IS_ALIGNED(virt_addr, PAGE_SIZE));
putc_ll('!');
BUG_ON(!IS_ALIGNED(phys_addr, PAGE_SIZE));
putc_ll('_');
pte_flags = get_pte_flags(map_type);
Well, lets mark get_ttb():
static inline uint32_t *get_ttb(void)
{
putc_ll('%');
/* Clear unpredictable bits [13:0] */
return (uint32_t *)(get_ttbr() & ~0x3fff);
}
I _think_ this is the critical path, I have more putc_ll() inserted, but
they are not important.
If by any chance it is better readable for anyone I could provide a
complete diff, of course.
So, when I power up, I get:
2>6ABCDEF%G-%|!_H-%|!_I-%|!_%%%%JKLMNOPQZSwitch to console [cs0]
before the banner.
When I reset, S1, blabla, I get:
>6ABCDEF%G-%|
So I assume it dies at
BUG_ON(!IS_ALIGNED(virt_addr, PAGE_SIZE));
at _arch_remap_range() in mmu_32.c.
Which yields to get_ttbr(void) in mmu_32.h which contains something like
asm volatile ("mrc p15, 0, %0, c2, c0, 0" : "=r"(ttb));
*EEEK*
Now I triple check with the second 6 enabled in lowlevel.c, no I change
it to 5, so:
omap_debug_ll_init();
putc_ll('>');
putc_ll('6');
putc_ll('5 ');
barebox_arm_entry(0x80000000, sdram_size, fdt);
Powerup:
2>65ABCDEF%G-%|!_H-%|!_I-%|!_%%%%JKLMNOPQZSwitch to console [cs0]
reset:
>65ABCDEF%G-%|!_H-%|!_I-%|!_%%%%JKLMNOPQZSwitch to console [cs0]
S1:
>65ABCDEF%G-%|!_H-%|!_I-%|!_%%%%JKLMNOPQZSwitch to console [cs0]
mw 0x44e00f00 0x1:
�>65ABCDEF%G-%|!_H-%|!_I-%|!_%%%%JKLMNOPQZSwitch to console [cs0]
wd 1:
>65ABCDEF%G-%|!_H-%|!_I-%|!_%%%%JKLMNOPQZSwitch to console [cs0]
Booting linux, entering reboot there:
reboot: Restarting system
>65ABCDEF%G-%|!_H-%|!_I-%|!_%%%%JKLMNOPQZSwitch to console [cs0]
So each warm restart method gives me a proper reboot.
With an additional putc_ll() in lowlevel.c in beaglebone_sram_init().
The later debug putc_ll() have no influence on starting not starting.
Kind regards
Konsti
--
INSIDE M2M GmbH
Konstantin Kletschke
Berenbosteler Straße 76 B
30823 Garbsen
Telefon: +49 (0) 5137 90950136
Mobil: +49 (0) 151 15256238
Fax: +49 (0) 5137 9095010
konstantin.kletschke@inside-m2m.de
http://www.inside-m2m.de
Geschäftsführung: Michael Emmert, Derek Uhlig
HRB: 111204, AG Hannover
next prev parent reply other threads:[~2024-12-04 16:30 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-28 9:07 Reset on Beaglebone Black has become unreliable/broken Konstantin Kletschke
2024-11-28 9:23 ` Ahmad Fatoum
2024-11-28 9:46 ` Konstantin Kletschke
2024-11-28 11:18 ` Ahmad Fatoum
2024-11-28 12:02 ` Konstantin Kletschke
2024-11-28 15:25 ` Konstantin Kletschke
2024-12-02 12:41 ` Ahmad Fatoum
2024-12-02 14:15 ` Konstantin Kletschke
2024-12-03 18:28 ` Ahmad Fatoum
2024-12-03 18:51 ` Konstantin Kletschke
2024-12-03 20:28 ` Ahmad Fatoum
2024-12-03 21:45 ` Konstantin Kletschke
2024-12-04 6:14 ` Ahmad Fatoum
2024-12-04 16:29 ` Konstantin Kletschke [this message]
2024-12-10 21:52 ` Ahmad Fatoum
2024-12-11 14:52 ` Konstantin Kletschke
2024-12-20 11:05 ` Konstantin Kletschke
2025-01-07 11:17 ` Ahmad Fatoum
2025-01-07 13:12 ` Konstantin Kletschke
2025-01-07 14:29 ` Konstantin Kletschke
2025-01-07 14:35 ` Ahmad Fatoum
2025-01-07 15:03 ` Konstantin Kletschke
2024-12-03 18:34 ` Konstantin Kletschke
2024-12-03 18:46 ` Ahmad Fatoum
2024-12-03 19:03 ` Konstantin Kletschke
2024-12-04 11:07 ` Konstantin Kletschke
2024-12-04 11:20 ` Konstantin Kletschke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z1CDcFAPdlDBkGJ5@hephaistos \
--to=konstantin.kletschke@inside-m2m.de \
--cc=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.