Quantcast
Channel: Raspberry Pi Forums
Viewing all articles
Browse latest Browse all 4416

Bare metal, Assembly language • Raspberry Pi 5 Memory address confusion

$
0
0
I'm trying to port the demo HDMI audio driver that I wrote for the Raspberry Pi 4 to the Raspberry pi 5, and so far have only managed to get the always-on UART and the Mailbox to work. This implies two things: that I can deduce at least some memory addresses as mapped to the ARM cores from the device tree sources, and that at least the VC still maps the first gigabyte of RAM to the address space of the fourth gigabyte, because otherwise I'd get no serial output or the VC wouldn't find my Mailbox requests or reply in the expected location.

Unfortunately and while the Mailbox works properly, I'm not having any luck configuring a frame buffer through the set plane property tag that is used in the firmware KMS Linux driver, and the problem, I believe, is that the rest of the hardware doesn't seem to have the first gigabyte of RAM mapped to the uncached region starting at 0xC000_0000. I believe this because I have only changed the memory addresses in my HDMI driver to match the registers in the BCM2712 and am not even getting my frame buffer with green pixels to be displayed, plus when I configure the DMA controller (the one in the BCM2712 SoC) to read the audio buffer, it doesn't find my control block in memory. Another thing adding to the confusion is that when I ask the VC to allocate memory (using the frame buffer tags as the alloc and lock memory tags no longer work), I get an address at the top of the first gigabyte of memory instead of the top of the fourth gigabyte of memory as I expected.

While I know that the addresses that I used for the always-on UART and Mailbox are correct, I'm not even sure that the address that I'm using for the DMA controller is correct in the perspective of the ARM core, but reading /proc/iomem as root on Linux gives me some confidence about the correctness of its location.

The following is the output that I get from querying the firmware about the available memory, the memory reserved to the VC, and the location of the active frame buffer:

Code:

Physical memory at 0x0 with size 0x3F800000VC memory at 0xFDB00000 with size 0x2100000FB memory at 0x3F800000 with size 0x3F4800
And the following is the bare metal code that generated that output:

Code:

    let mem_out: (u32, u32);    mbox! {0x10005: _ => mem_out};    println!("Physical memory at 0x{:X} with size 0x{:X}", mem_out.0, mem_out.1);    let vc_mem_out: (u32, u32);    mbox! {0x10006: _ => vc_mem_out};    println!("VC memory at 0x{:X} with size 0x{:X}", vc_mem_out.0, vc_mem_out.1);    let fb_mem_out: (u32, u32);    mbox! {0x40001: _ => fb_mem_out};    println!("FB memory at 0x{:X} with size 0x{:X}", fb_mem_out.0, fb_mem_out.1);
My questions:

1. When the VC returns a frame buffer pointer to 00x3F80_0000, where exactly is that in the perspective of the ARM cores?

2. What is or are the bus master base address or addresses of the RAM in the perspective of BCM2712 peripherals like the DMA controller or the HVS?

3. Is the BCM2712 DMA controller really at 0x10_0001_0000 in the perspective of the ARM cores?

Thanks in advance!

Statistics: Posted by Fridux — Fri May 10, 2024 3:41 pm — Replies 0 — Views 17



Viewing all articles
Browse latest Browse all 4416

Trending Articles