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: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-28 9:07 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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox