mail archive of the barebox mailing list
 help / color / mirror / Atom feed
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




  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