PowerPC/e500: how is FDT access supposed to work?

[Daniel Wohllebe]

Hello everyone,


I am in need of some friendly advice. I am working on getting an application running, which I compiled for PowerPC using the qoriq_e500 BSP (https://docs.rtems.org/branches/master/user/bsps/bsps-powerpc.html#qoriq-qoriq).

Due to the current lack of a physical board, I want to have it run in QEMU on the ppce500 machine (https://www.qemu.org/docs/master/system/ppc/ppce500.html).

I have RTEMS on head 25ba67963aa23dff4fbe87a2e0c56b8c011cdf8a and set everything up via the source builder at head 423d98d2058a7dac0921f9a13113b024696236b9 (so my state is from early June).

 

I have created the application image und started it up inside QEMU via the U-Boot bootloader.

However, my application runs into a fatal error (QORIQ_FATAL_FDT_NO_BUS_FREQUENCY) early on, and then gets stuck trying to print (what I assume is) an error message (see the following stack trace):

 

```

(gdb) bt

#0  ns16550_polled_putchar (base=0x2001148 <qoriq_uart_context_0>, out=13 '\r')

    at ../../../bsps/shared/dev/serial/ns16550-context.c:535

#1  0x0004f1e0 in rtems_putc (c=10 '\n') at ../../../cpukit/libcsupport/src/rtems_putc.c:49

#2  0x0004d264 in _IO_Vprintf (put_char=0x4f1a8 <rtems_put_char>, arg=arg at entry=0x0, fmt=0x1004311 "%s\n",

    fmt at entry=0x1004310 "\n%s\n", ap=ap at entry=0x2389e80 <_ISR_Stack_area_begin+7872>) at ../../../cpukit/dev/iovprintf.c:133

#3  0x00044e44 in vprintk (fmt=fmt at entry=0x1004310 "\n%s\n", ap=ap at entry=0x2389e80 <_ISR_Stack_area_begin+7872>)

    at ../../../cpukit/libcsupport/src/vprintk.c:45

#4  0x00040df4 in printk (fmt=fmt at entry=0x1004310 "\n%s\n") at ../../../cpukit/libcsupport/src/printk.c:41

#5  0x0003d410 in bsp_fatal_extension (source=RTEMS_FATAL_SOURCE_BSP, always_set_to_false=<optimized out>, code=2561)

    at ../../../bsps/shared/start/bspfatal-default.c:66

#6  0x0004cc90 in _User_extensions_Iterate (arg=arg at entry=0x2389f48 <_ISR_Stack_area_begin+8072>,

    visitor=0x4cb88 <_User_extensions_Fatal_visitor>, direction=direction at entry=CHAIN_ITERATOR_FORWARD)

    at ../../../cpukit/score/src/userextiterate.c:194

#7  0x0004889c in _User_extensions_Fatal (error=2561, source=RTEMS_FATAL_SOURCE_BSP)

    at ../../../cpukit/include/rtems/score/userextimpl.h:467

#8  _Terminate (the_source=the_source at entry=RTEMS_FATAL_SOURCE_BSP, the_error=the_error at entry=2561)

    at ../../../cpukit/score/src/interr.c:55

#9  0x0003d0b8 in rtems_fatal (fatal_code=2561, fatal_source=RTEMS_FATAL_SOURCE_BSP) at ../../../cpukit/include/rtems/fatal.h:160

#10 bsp_fatal (code=QORIQ_FATAL_FDT_NO_BUS_FREQUENCY) at ../../../bsps/include/bsp/fatal.h:222

#11 initialize_frequency_parameters () at ../../../bsps/powerpc/qoriq/start/bspstart.c:89

#12 bsp_start () at ../../../bsps/powerpc/qoriq/start/bspstart.c:178

#13 0x00047808 in rtems_initialize_executive () at ../../../cpukit/sapi/src/exinit.c:135

#14 0x0003c68c in boot_card (cmdline=<optimized out>) at ../../../bsps/shared/start/bootca

#15 0x0000412c in bsp_section_start_begin () at ../../../bsps/powerpc/qoriq/start/start.S:

```

 

I suspect that the flattened device tree is not being loaded correctly, which also leads to the application not being able to push out characters to UART.

 

Further investigation went as follows:

During initialize_frequency_parameters() in bsps/powerpc/qoriq/start/bspstart.c (https://gitlab.rtems.org/rtems/rtos/rtems/-/blob/main/bsps/powerpc/qoriq/start/bspstart.c), the first call to fdt_node_offset_by_prop_value() returns the negative node integer -9, which, if I traced everything correctly, means I have run into the error FDT_ERR_BADMAGIC, telling me I don't have a real device tree present at all.

I then went a step back and followed the flow of initialize_frequency_parameters() from the beginning, ending up in bsp_fdt_get() of bsps/shared/start/bsp-fdt.c (https://gitlab.rtems.org/rtems/rtos/rtems/-/blob/main/bsps/shared/start/bsp-fdt.c).

At this point I found out that BSP_DTB_IS_SUPPORTED is not defined, as only the array bp_fdt_blob exists and is accessed. This array is filled with the pre-initialized `0xdeadbeef` values and does not contain any meaningful data.

 

My question is:

I fail to see the mechanism by which a real FDT should have been available at this point. Is there a detail or some magic that I am missing here that would make this work usually? I could not find any trace of any linker scripts or any routines that are used to add content to the blob/array.


Kind Regards,

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20240701/139b73a4/attachment.htm>