inconsistent logging results when using atomics #160
Replies: 1 comment 10 replies
-
|
I don’t know your EMMC driver, and it is also not part of the tutorials here. To me, this looks more like something races between your emmc driver init and this fat_cache snippet than with the logging. If you have caching enabled anyways then there should be no issue with the atomics. |
Beta Was this translation helpful? Give feedback.
-
|
I don’t know if it has to do with the problem, but your current layout.ld is erroneous. code_end_exclusive is aligned 4KiB (PAGE_SIZE), and then there’s a gap and then data starts 64KiB aligned. |
Beta Was this translation helpful? Give feedback.
-
|
I guess it was worth a try - used a 64KiB page-size to ensure there are no gaps between still get the same result. /* SPDX-License-Identifier: MIT OR Apache-2.0
*
* Copyright (c) 2018-2021 Andre Richter <andre.o.richter@gmail.com>
*/
PAGE_SIZE = 64K;
PAGE_MASK = PAGE_SIZE - 1;
__rpi_phys_dram_start_addr = 0;
/* The physical address at which the the kernel binary will be loaded by the Raspberry's firmware */
__rpi_phys_binary_load_addr = 0x80000;
ENTRY(__rpi_phys_binary_load_addr)
/* Flags:
* 4 == R
* 5 == RX
* 6 == RW
*
* Segments are marked PT_LOAD below so that the ELF file provides virtual and physical addresses.
* It doesn't mean all of them need actually be loaded.
*/
PHDRS
{
segment_boot_core_stack PT_LOAD FLAGS(6);
segment_code PT_LOAD FLAGS(5);
segment_data PT_LOAD FLAGS(6);
}
SECTIONS
{
. = __rpi_phys_dram_start_addr;
/***********************************************************************************************
* Boot Core Stack
***********************************************************************************************/
.boot_core_stack (NOLOAD) :
{
/* ^ */
/* | stack */
. += __rpi_phys_binary_load_addr; /* | growth */
/* | direction */
__boot_core_stack_end_exclusive = .; /* | */
} :segment_boot_core_stack
ASSERT((. & PAGE_MASK) == 0, "End of boot core stack is not page aligned")
/***********************************************************************************************
* Code + RO Data + Global Offset Table
***********************************************************************************************/
__code_start = .;
.text :
{
KEEP(*(.text._start))
*(.text._start_arguments) /* Constants (or statics in Rust speak) read by _start(). */
*(.text._start_rust) /* The Rust entry point */
*(.text*) /* Everything else, add all other input .text sections (i.e. from other
input object files) to our main binary. */
} :segment_code
.rodata : ALIGN(8) { *(.rodata*) } :segment_code
.got : ALIGN(8) { *(.got) } :segment_code
. = ALIGN(PAGE_SIZE);
__code_end_exclusive = .;
/***********************************************************************************************
* Data + BSS
***********************************************************************************************/
.data : { *(.data*) } :segment_data /* align .data to a 64KiB boundary. */
/* As we enable the MMU and set the paging granularity to 64KiB. */
/* So, the end of `code + ro` section and start of data section needs to be 64KiB aligned.*/
/* Section is zeroed in pairs of u64. Align start and end to 16 bytes */
.bss (NOLOAD): ALIGN(16)
{
__bss_start = .;
*(.bss*);
. = ALIGN(16);
__bss_end_exclusive = .;
} :segment_data /* not a section that's loaded into memory, we just need to allocate as many zeroed bytes.*/
}grepped the symbol table for npashi@DESKTOP-M9O6B7J:/mnt/c/Users/Nil/devspace/rust/projects/rustBoot/boards/bootloaders/rpi4$ readelf -s ../../target/aarch64-unknown-none-softfloat/release/kernel | grep __code*
1581: 0000000000080000 0 NOTYPE GLOBAL DEFAULT 1 __code_start
1582: 00000000000b0000 0 NOTYPE GLOBAL DEFAULT 3 __code_end_exclusiveand assembly for the .data section Disassembly of section .data:
00000000000b0000 <log::LOGGER.1>:
b0000: 000a7350 00000000 Ps......
00000000000b0008 <rustBoot_hal::rpi::rpi4::bsp::global::GPIO>:
b0008: fe200000 00000000 .. .....
00000000000b0010 <rustBoot_hal::rpi::rpi4::bsp::global::PL011_UART>:
b0010: fe201000 00000000 00000000 00000000 .. .............
...
00000000000b0028 <rustBoot_hal::rpi::rpi4::bsp::drivers::emmc::EMMC_CARD>:
...
b0068: 000abc37 00000000 00000001 00000000 7...............
... |
Beta Was this translation helpful? Give feedback.
-
|
What happens if you define your own static atomic and cmp_exchange it during boot? |
Beta Was this translation helpful? Give feedback.
-
|
You need to get an idea where you are actually hanging. If you can’t get hold of a hw debugger, try something like implementing IRQ support, and periodically interrupt yourself and print ELR_EL1 to understand where the CPU was. You could set the timer compare value register and then kick off counting with timer IRQ enabled (see time.rs in the tutorials). In the ISR, reset the timer again to get infinite periodic IRQs. |
Beta Was this translation helpful? Give feedback.
-
|
Yep, that's the only option I have left. I'll circle back when I'm in possession of hw debugger. Hopefully soon. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
This seems like an odd issue.
I'm using the log crate to abstract over the (UART-based) logging implementation.
loguses atomics under the hood to initialize the global logger. In this case, I'm usingset_logger_racyset_logger_racyuses an atomic load + store, like in the casepanic_wait. I presume they are lowered to regular load/store operations onaarch64. However, initializing the global logger yields inconsistent results.exceptionhandling andmmu + cachingare enabled in all cases.Case 1:
In theory, this snippet simply caches the fat table and should have no bearing on our global logger but nonetheless, adding this, results in the system-hanging without any exception. What's weird is the call to initialize the global logger is supposed to happen after printing a few more logs. In other words, none of the
infologs fromkernel_mainget printed. It looks like the system simply hangs right afterkernel_init.Case 2:
[INFO]logs.Case 3:
Any idea why this could be happening? Am I missing something specific to the rpi4?
Beta Was this translation helpful? Give feedback.
All reactions