GDB crashed when trying to enable MMU

[Kendidi]

Hi,

I use OpenOCD, GDB to load and run Linux Kernel on Ariane FPGA. GDB session appears crashing every time when the code tries to enable MMU in "relocate" session of ...\linux-ariane-v0.7\arch\riscv\kernel\head.S:

    csrw sptbr, a0

Is it OK to to enable MMU with code running from GDB? How do we debug this? And is there a way to temporary disable MMU usage?

Many thanks in advance!

[Moschn]

Debugging virtual memory with GDB is a bit of a hassle. I think you must use updated openOCD and gdb versions and even then it is pretty weird. See https://github.com/riscv/riscv-openocd/pull/386

[Kendidi]

Which GDB should we use? riscv-gdb or the build tool version?

On Tuesday, September 1, 2020, 1:29 AM, Moritz Schneider notifications@github.com wrote:

Debugging virtual memory with GDB is a bit of a hassle. I think you must use updated openOCD and gdb versions and even then it is pretty weird. See riscv/riscv-openocd#386

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Moschn]

The newest openOCD and GDB

[Kendidi]

Thanks Moschn!.

Currently, when it tries to read fdt header at fdt32_ld( ) (called from fdt_check_header( )), it will ended up trapped in Lsecondary_park in head.S.

Before MMU started, I read the FDT header via GDB and it looks good (0xedfe0dd0).

So does that mean there is an issue with address translation? How can we verify if that's the case? Please advise. Thanks.

[Kendidi]

The newest openOCD and GDB

I believe I am already using the latest OpenOCD and GDB I could find. Thanks.

[Moschn]

I cannot really comment on these functions as I do not know where they are from. I guess no one tried to boot the entire linux image with single stepping in GDB. I myself only had success in stepping through phyiscal adresses withouth virtual memory. What exactly are you aiming to do? If you want to debug a certain application, I would suggest you do that on qemu. If you want to debug certain additions to Ariane, I would suggest doing that without virtual memory.

[Kendidi]

I am trying to run Linux on Ariane FPGA with DDR starting from 0x2_0000_0000. 

I initially just want to be able to load and run bbl. It started but not printing anything once left bbl, so I started to step through the code to debug.  Would you please advise on how to not enabling MMU?  Is there a macro in Kernel to control that? Many thanks in advance!

On Thursday, September 3, 2020, 1:18 AM, Moritz Schneider notifications@github.com wrote:

I cannot really comment on these functions as I do not know where they are from. I guess no one tried to boot the entire linux image with single stepping in GDB. I myself only had success in stepping through phyiscal adresses withouth virtual memory. What exactly are you aiming to do? If you want to debug a certain application, I would suggest you do that on qemu. If you want to debug certain additions to Ariane, I would suggest doing that without virtual memory.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Moschn]

I believe there is a nommu patchset for linux on risc-v. However, I do not think it is stable yet and I have never used it.

Since fdt is part of the device tree, I would assume you are having device tree issues. I would try to see if some code (i.e., linux boot code before MMU) can read the entire device tree and parse it correctly.

[Kendidi]

I have modified BBL to print the device tree before calling _boot_otherhart(). It printed OK.

[Kendidi]

@Moschn

Are we supposed to supply a filesystem by adding something like the following into ariane.dts?

  chosen {
    bootargs = "root=/dev/xxx console=hvc earlycon=sbi";
    stdout-path = "/soc/uart@10000000:115200";
  };

If yes, what FS should we use? If not, will Kernel generate one during bootup? Many thanks in advance!

[Moschn]

I do not know. I never had to modify the bootrom to get linux to boot

[Kendidi]

@Moschn

Cool! Thanks! I was under the impression that a filesystem is needed for Linux to boot to prompt, therefore "bootargs = "root=/dev/xxx..." is a must.

[Moschn]

We use initramfs and as such do not have any filesystem. Everything is put on a ramdisk that is created on boot

[Kendidi]

Thank you @Moschn !!