03-06-2015 06:13 AM
We are trying to boot linux and monitor all memory accesses through Programmable Logic. We're first trying to boot linux with a start address above #0x40000000.
So far, we're getting:
3453656 bytes read in 568 ms (5.8 MiB/s)
9209 bytes read in 16 ms (561.5 KiB/s)
5310018 bytes read in 865 ms (5.9 MiB/s)
memstart 0## Booting kernel from Legacy Image at 43000000 ...
Image Name: Linux-3.18.0-xilinx-06434-g1f570
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3453592 Bytes = 3.3 MiB
Load Address: 48008000
Entry Point: 48008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 42000000 ...
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 5309954 Bytes = 5.1 MiB
Load Address: 48000000
Entry Point: 48000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 42a00000
Booting using the fdt blob at 0x42a00000
Loading Kernel Image ... OK
## initrd_high = 0x5fff0000, copy_to_ram = 1
rddata 42000040 Loading Ramdisk to 1e812000, end 1ed22602 ... OK
Loading Device Tree to 1e80c000, end 1e8113f8 ... OK
## Transferring control to Linux (at address 48008000)...
Starting kernel ...
It looks like Linux hangs after trying to enable the mmu with the command:
mcr p15, 0, r0, c1, c0, 0 @ write control reg
Thank you for your time
03-06-2015 09:55 AM
So we see what the software siide is doing (during linux boot), what is the hardware you have in the PL to do what you claim?
If all memory access is done through the PL side, that implies you have a memory interface core in soft logic, in the PL, accessing external memory. If all of that is true, there are a lot of ways this might be an issue, as teh controller has to be up and running when the first stage boot loader gets loaded (memory interface must be working).
As you start to boot linux, is the FSBL loaded into the existing DDR through the PS side? If so, that is not the "memory access through PL"
Once booted, it then goes to the other memory? Not sure what is in the other memory at that point (chicken and egg program: how did that information get written to that memory?).
03-09-2015 01:09 AM
Our PL takes every memory read/write request above 0x40000000 and clears the most significant bit in the memory address to be memory accesses in the range of 0x0-1fffffff. We've verified that this works. The DDR is our only memory. We're just trying to access the DDR only through programmable logic.
03-09-2015 07:17 AM
OK, you beyond what I know now. I do not understand how you are able to do what you are doing. Regardless, that is my problem (not understanding), not yours.
I thought the MMU that directly controls the DDR for the PS was the only way to access the PS DDR,