RTEMS booting on PolarFire SoC FPGA

[Hesham Almatary]

On Wed, 6 Jan 2021 at 07:30, somesh deshmukh <someshdeshmukh07 at 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.almatary at 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 <someshdeshmukh07 at 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 at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel