On Wed, 6 Jan 2021 at 07:30, somesh deshmukh <someshdeshmuk...@gmail.com> wrote: > > After testing multiple times I observed that the failing instruction is not > consistent but I am getting mcause as 2 every time, which represents Illegal > instruction. This sounds like memory is being overwritten.
> Is it compulsory to use the device tree to boot RTEMS? I am trying to boot it > using a simple bootloader application that will copy the executable at 0x8000 > and point the processor to that location to start execution. As the primary > goal is to execute the default hello world application on PolarFire SoC > Hardware. > Is BSP_START_COPY_FDT_FROM_U_BOOT macro in the start.S enabled by default? It is not compulsory to enable BSP_START_COPY_FDT_FROM_U_BOOT, but it's compulsory for RTEMS to have FDT passed to it in a1. That's how it knows about devices, CPU, etc. So even if you disable BSP_START_COPY_FDT_FROM_U_BOOT, this will get you a bit far ahead but will still fail during the FDT probing done later. > > Thanks and Regards, > Somesh > > On Tue, Jan 5, 2021 at 5:53 PM Hesham Almatary <hesham.almat...@cl.cam.ac.uk> > wrote: >> >> I don't see why the "auipc" would fail. Are you sure that's the >> faulting instruction? Can you read mcause/mepc from your debugger >> after it hangs? >> How/where do you prepare the FDT and pass it to RTEMS? bsp_fdt_copy >> expects the bootloader to pass the HARTID in a0, and the FDT pointer >> in a1. >> >> >> On Tue, 5 Jan 2021 at 13:16, somesh deshmukh <someshdeshmuk...@gmail.com> >> wrote: >> > >> > Hi All, >> > I am trying to boot RTEMS on PolarFire SoC FPGA using rv64imafdc_medany >> > BSP. >> > I am using a simple bare-metal bootloader application to copy the >> > hello.bin(I generated a hello.bin file from hello.exe from >> > testsuits/samples directory) at the address 0x80000000. >> > Attached is the disassembly of the example that I am using to boot the >> > RTEMS. I kept breakpoint at 0x80000032 and the breakpoint gets a hit. >> > After this instruction, the processor just hangs in some unknown state, >> > and the breakpoints after this don't get hit as the processor is in the >> > unknown state, the register values cant be read. >> > >> > Does anyone have any idea how to debug this issue? Any leads will be >> > helpful. >> > >> > >> > Thanks and Regards, >> > Somesh >> > _______________________________________________ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
