Microchip Polarfire SoC FPGA libbsd driver fails due to not handling swi event?

Packages libBSD
, , , ,
1

Hi!

I’m writing a libbsd driver that resides in our RTEMs application code for handling TCP/IP communication that I need help to debug. As I’m new to RTEMS and libbsd any help would be greatly appreciated!

The application streams sensor data from the Polarfire Icicle kit, there is no reception besides TCP ACKs. After a few seconds / minutes of communication it suddenly stops.

First sign of trouble is that the send() function return with an error indicating that the send buffers are full. But nothing gets sent to the if_transmit() function in the driver. No other error messages are seen anywhere.

The if_tick() function keeps firing. I can see that the HW keeps receiving packages and tries to send them to the libbsd stack using netisr_queue(), but nothing seems to happen with them. After a while the netisr_queue() starts to return ENOBUFS error.

When the stack is stuck I can see that the “swi1: netisr 0” task has received an event, but it never seems to leave the EV state and go into READY. It looks fishy to me. But I don’t really know what to do with this information.

ID       NAME                 SHED PRI STATE  MODES    EVENTS WAITINFO
------------------------------------------------------------------------------
0a010001 UI1                  MEDF   1 EV     P:T:nA   NONE
0a010002 LOGT                 MEDF 110 MSG    P:T:nA   NONE   22010001
0a010003 TIME                 MEDF  98 SYSEV  P:T:nA   NONE
0a010004 IRQS                 MEDF  96 SYSEV  P:T:nA   NONE
0a010005 IRQS                 MEDF  96 SYSEV  P:T:nA   NONE
0a010006 IRQS                 MEDF  96 SYSEV  P:T:nA   NONE
0a010007 IRQS                 MEDF  96 SYSEV  P:T:nA   NONE
0a010008 _BSD inm_free taskq  MEDF 100 WK     P:T:nA   NONE   -
0a010009 _BSD in6m_free taskq MEDF 100 WK     P:T:nA   NONE   -
0a01000a _BSD kqueue_ctx task MEDF 100 WK     P:T:nA   NONE   -
0a01000b _BSD bus taskq       MEDF 100 WK     P:T:nA   NONE   -
0a01000c _BSD swi5: fast task MEDF 100 EV     P:T:nA   NONE
0a01000d _BSD thread taskq    MEDF 100 WK     P:T:nA   NONE   -
0a01000e _BSD swi6: Giant tas MEDF 100 EV     P:T:nA   NONE
0a01000f _BSD swi6: task queu MEDF 100 EV     P:T:nA   NONE
0a010010 _BSD deferred_unmoun MEDF 100 WK     P:T:nA   NONE   -
0a010011 _BSD swi1: netisr 0  MEDF 100 EV     P:T:nA 80000000
0a010012 _BSD bufdaemon       MEDF 100 WK     P:T:nA   NONE   psleep
0a010013 _BSD syncer          MEDF 100 WK     P:T:nA   NONE   syncer
0a010014 _BSD vnlru           MEDF 100 WK     P:T:nA   NONE   vlruwt
0a010015 _BSD bufspacedaemon- MEDF 100 WK     P:T:nA   NONE   -
0a010016 PFRW                 MEDF 200 MSG    P:T:nA   NONE   22010006
0a010017 PFTW                 MEDF 100 EV     P:T:nA   NONE
0a010019 DHCP                 MEDF 2147483646 WK P:T:nA   NONE   select
0a01001a EST0                 MEDF 100 TIME   P:T:nA   NONE
0a01001b SHPR                 MEDF 100 MSG    P:T:nA   NONE   2201000b
0a01001c TST0                 MEDF 100 TIME   P:T:nA   NONE
0a01001d MST0                 MEDF 100 MSG    P:T:nA   NONE   2201000c
0a01001e SHLL                 MEDF 100 READY  P:T:nA   NONE

The driver itself is pretty simple, it bridges the HW code provided by Microchip below with the libbsd networking stack.

The driver uses rtems_interrupt_handler_install() to provide the interrupt that the MSS Platform requires.

It has two RTEMs tasks, called PFRW and PRTW, for handling RX and TX respectively.

The TX uses three separate RTEMs queues for storing pointers to available, pending and done “packets”. These queues are called PFTA, PFTP and PFTD. TX worker wakes up on events, send packets from the PFTP queue and cleans up events from the PFTD queue and places them back into the PFTA queue. PFTD queue is filled from the ISR TX callback function from the MSS Platform code.

Rx side has a similar scheme but uses two queues called PFRA and PFRD.

Using the “queue” command from shell I can that PFTA and PFRA queues look healthy (just not doing anything) when the network stack is stuck.

  ID       NAME   ATTRIBUTES   PEND   MAXPEND  MAXSIZE
------------------------------------------------------------------------------
22010001   LOGQ    DEFAULT        0     512      260
22010002   BMQS    DEFAULT      390     400        8
22010003   BMQM    DEFAULT       50      50        8
22010004   BMQL    DEFAULT        9      20        8
22010005   PFRA    DEFAULT      127     128        8
22010006   PFRP    DEFAULT        0     128        8
22010007   PFTA    DEFAULT      256     256        8
22010008   PFTP    DEFAULT        0     256        8
22010009   PFTD    DEFAULT        0     256        8
2201000a   SHR0    DEFAULT       10      10      360
2201000b   SHTX    DEFAULT        0      10      360
2201000c   MSR0    DEFAULT        0       4       64

I’m using libbsd release version 6.2. And RTEMS as below.

rtems all
RTEMS: 6.0.0 (f6933b9c6ff6780c1b3a56d80aa9577f181e5763) SMP:4 cores
CPU: RISCV (RISCV)
BSP: mpfs64imafdc
Tools: 13.3.0 20240521 (RTEMS 6, RSB 3814cb0e7f86cca2be403eac831f9bf571984659-modified, Newlib 1b3dcfd)
Options: SMP
SHLL [/] #

task all look normal as well

Uptime: 2m52.753999          Period: 0.713986
Tasks:   34  Load Average:   18.233%  Load:   17.112%  Idle:  382.889%
Mem:   88M free 136M used 944K stack

 ID         | NAME                | RPRI | CPRI   | TIME                | TOTAL   | CURRENT
------------+---------------------+---------------+---------------------+---------+--^^----
 0x09010001 | IDLE                |  2147483647 |  2147483647   | 2m52.719866         |  24.995 |  99.997
 0x09010002 | IDLE                |  2147483647 |  2147483647   | 2m52.548196         |  24.970 |  99.986
 0x09010003 | IDLE                |  2147483647 |  2147483647   | 2m51.622244         |  24.836 |  99.800
 0x09010004 | IDLE                |  2147483647 |  2147483647   | 2m22.614902         |  20.638 |  83.105
 0x0a010001 | UI1                 |    1 |    1   | 3.275615            |   0.474 |   0.000
 0x0a010003 | TIME                |   98 |   98   | 0.150780            |   0.021 |   0.085
 0x0a01001d | MST0                |  100 |  100   | 19.678955           |   2.847 |  12.709
 0x0a01001a | EST0                |  100 |  100   | 7.371226            |   1.066 |   3.423
 0x0a01001b | SHPR                |  100 |  100   | 0.068704            |   0.009 |   0.046
 0x0a01001e | SHLL                |  100 |  100   | 0.036017            |   0.005 |   0.252
 0x0a010002 | LOGT                |  110 |  110   | 0.029288            |   0.004 |   0.020
 0x0a010004 | IRQS                |   96 |   96   | 0.000039            |   0.000 |   0.000
 0x0a010005 | IRQS                |   96 |   96   | 0.000028            |   0.000 |   0.000
 0x0a010006 | IRQS                |   96 |   96   | 0.000027            |   0.000 |   0.000
 0x0a010007 | IRQS                |   96 |   96   | 0.000007            |   0.000 |   0.000
 0x0a01001c | TST0                |  100 |  100   | 0.010689            |   0.001 |   0.006
 0x0a010012 | _BSD                |  100 |  100   | 0.005662            |   0.000 |   0.006
 0x0a010014 | _BSD                |  100 |  100   | 0.005576            |   0.000 |   0.004
 0x0a010013 | _BSD                |  100 |  100   | 0.004944            |   0.000 |   0.003
 0x0a010015 | _BSD                |  100 |  100   | 0.004848            |   0.000 |   0.004
 0x0a010018 | CPlt                |  100 |  100   | 0.004082            |   0.000 |   0.547
 0x0a010008 | _BSD                |  100 |  100   | 0.000017            |   0.000 |   0.000
 0x0a010009 | _BSD                |  100 |  100   | 0.000010            |   0.000 |   0.000
 0x0a01000a | _BSD                |  100 |  100   | 0.000009            |   0.000 |   0.000
 0x0a01000b | _BSD                |  100 |  100   | 0.000011            |   0.000 |   0.000
 0x0a01000c | _BSD                |  100 |  100   | 0.000012            |   0.000 |   0.000
 0x0a01000d | _BSD                |  100 |  100   | 0.001330            |   0.000 |   0.000
 0x0a01000e | _BSD                |  100 |  100   | 0.000009            |   0.000 |   0.000
 0x0a01000f | _BSD                |  100 |  100   | 0.000120            |   0.000 |   0.000
 0x0a010010 | _BSD                |  100 |  100   | 0.000010            |   0.000 |   0.000
 0x0a010011 | _BSD                |  100 |  100   | 0.265832            |   0.038 |   0.000
 0x0a010016 | PFRW                |  200 |  200   | 0.074205            |   0.010 |   0.002
 0x0a010017 | PFTW                |  100 |  100   | 0.503029            |   0.072 |   0.000
 0x0a010019 | DHCP                |  2147483646 |  2147483646   | 0.007700            |   0.001 |   0.000

The more data I try to send (larger / and or more packets) over the TCP/IP connection the faster it breaks down.

One final piece of information is that I’ve tried same code on RTEM7 (from 6 months ago since latest main don’t work at all with riscv/mpfs64imafdc for some reason) and I got the exact same error.

Thanks for reading and as I said above, any help debugging this would be greatly appreciated!

2

Thanks for the post and welcome to RTEMS. It is great to see you working on this.

Have you seen FreeBSD’s Microchip PolarFire SoC support page? I suggest you reach out to them and mention you are using RTEMS. They may have a working ethernet driver or something you can use and help improve.

I also suggest you consider working with RTEMS 7 and LibBSD 7-freebsd-14 for the development phase of the work. A working 7-freebsd-14 driver can be back ported to 6-freebsd-14.

When debugging at a low level the printk call is useful. A simple printk in the interrupt will let you know you are receiving interrupts.

A lack of buffers can mean:

  1. Blocked pipeline which means queues are holding the buffers. If you are not getting any interrupts or a DMA descriptor chain is wrong the pipe line is lost
  2. A buffer leak where a path is not returning the buffers and they are lost
3

Hi kiwichris,

Thanks for your fast reply. I reached out to the guys from the link you provided. Let’s see what they have to say!

I continued to debug the issue by using prinkt statements. Thanks for reminding me to do my job :joy:

The prinkt statements was quickly changed into counters which I printed in the if_tick function.

Every time without fail I could see that the function that sends the RTEMSBSD_SWI_WAKEUP_EVENT in kern_intr.c it sends the event. The task that is supposed to receive the event (kern_intr.c at line 1372) has called rtems_event_receive but it never wakes up.

Changing only the rtems_event_receive at line 1372 from

			rtems_status_code sc = rtems_event_receive(
				RTEMSBSD_SWI_WAKEUP_EVENT,
				RTEMS_WAIT | RTEMS_EVENT_ALL,
				RTEMS_NO_TIMEOUT,
				&event_out);
			BSD_ASSERT(sc == RTEMS_SUCCESSFUL);

to

			rtems_status_code sc = RTEMS_SUCCESSFUL;
			do
			{
				sc = rtems_event_receive(
				RTEMSBSD_SWI_WAKEUP_EVENT,
				RTEMS_WAIT | RTEMS_EVENT_ALL,
				RTEMS_MILLISECONDS_TO_TICKS(100),
				&event_out);
			} while (sc != RTEMS_SUCCESSFUL);

makes my application go from freezing after minutes to being possible to run for hours at 100%+ load. But there still seems to be something more that goes wrong in my driver which I need to continue to debug.

I have tried using RTEMS 7 and LibBSD 7-freebsd-14. But as I said the latest commit for RTEMS 7 for this BSP can’t even print hello world application for some reason. Using an earlier commit from 2025 for RTEMS 7 works. But I see the exact same error in my application.

I don’t know, to me it looks like an SMP race condition error in the rtems_event_send and rtems_event_receive :face_with_open_eyes_and_hand_over_mouth:

4

Great progress.

The event should work which means there could be a issue else where in RTEMS. It might be a good idea to run some of the tests in rtems.git to make sure events are working on your BSP and build of RTEMS.

Not being able to run on RTEMS 7 is a problem. If the samples hello world does not work then could you please raise an issue? I know @gedare has been working on this recently and maybe interested.

5

Yes, for sure hello.exe should be working still. It’s possible something broke from my recent work on the generic risc-v support. There is a bug I have to chase down when using 32-bit mode. Unknown error while running tests using qemu - #9 by gedare

6

Hi!

Been continuing to debug but unfortunately not that much progress.

I’m still having problem with libbsd, now the problem is a bit different. After like 30-40 minutes running TCP/IP at high load suddenly the libbsd callout function seems to stall (visible in that the periodic ticks stops). When this happens send() function reports error 11 (No more processes) after a while and comomunication breaks down.

TX and RX on the HW level still seems to work. Printing the state of the callout responsible for ticks show that it’s pending and not active meaning that it should fire sometime, but it never does. Resetting the callout again does no change.

I ran a few of the SMP tests manually, and they all passed on the earlier version. Currently, there is no way to run all the tests automated and running them on the HW is quite cumbersome.

Maybe making a script that does this, or would it be possible to update the rtems-test to do this automatically?

These are the steps needed to make for each separate test.

@gedare

Below is the output of the hello.exe test running on HW using HSS bootloader for an older RTEMS 7 commit.

DDR training ... Passed ( 2768 ms)
[2.862486] DDR-Lo size is   32 MiB
[2.867165] DDR-Hi size is 1888 MiB
[7.525825] Address to execute is 1000000000


*** BEGIN OF TEST HELLO WORLD ***
*** TEST VERSION: 7.0.0.f30157f988df3c9f75c201124573520c03edf6a3
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_SMP
*** TEST TOOLS: 13.4.0 20250605 (RTEMS 7, RSB ec63a83cd04a037b0d66fe38e8c25b09d6d9ab63-modified, Newlib 038afec1)
Hello World

*** END OF TEST HELLO WORLD ***


[ RTEMS shutdown ]
CPU: 0
RTEMS version: 7.0.0.f30157f988df3c9f75c201124573520c03edf6a3
RTEMS tools: 13.4.0 20250605 (RTEMS 7, RSB ec63a83cd04a037b0d66fe38e8c25b09d6d9ab63-modified, Newlib 038afec1)
executing thread ID: 0x0a010001
executing thread name: UI1

When I run hello.exe from the RTEMs 7 with commit hash 1d90aa13b7a41876753c588c951c1da204628725 from a couple of days ago. I get no ouput at all from the test but I get an error from e51 monitor core running the HSS bootloader. Testing with or without SMP seems to make no difference.

From bootloader core I get this error:

[51.856128] u54_1: BEU event:              Load or store TileLink bus error

One thing that I noted is that there now is a bunch of redefinition errors between this header

build\rtems\7\riscv-rtems7\mpfs64imafdc\lib\include\rtems\score\riscv-utility.h

and one used in the HSS and in my application code. It’s should not be used when building the hello.exe test however but maybe it’s a clue to something?

I don’t know. Quite stuck :slight_smile:

7

What is your config.ini?

8

Possibly the hello.exe will be fixed by riscv: use unsigned comparison for address check (!1221) · Merge requests · RTEMS / RTOS / RTEMS · GitLab if your FDT is located at a high address. The error was manifesting in 32-bit riscv as a NULL pointer instruction because the FDT doesn’t get copied. If not, we’ll have to dig a little more. I have a beaglevfire here that I could try to see if it has a similar problem.

I don’t have any insights about the libbsd issues. You could ask about testing over in Tools

9

We should probably consider using the stock encoding.h file (from riscv-tools) and add our own bits on top of it internally. see riscv: refactor riscv-utility.h (!1222) · Merge requests · RTEMS / RTOS / RTEMS · GitLab

10 
[riscv/mpfs64imafdc]
BUILD_TESTS = True
RTEMS_POSIX_API = False
RTEMS_SMP = True
BSP_START_COPY_FDT_FROM_U_BOOT = False
BSP_VERBOSE_FATAL_EXTENSION = True
RISCV_ENABLE_MPFS_SUPPORT = True

Here is my config.ini

11

@gedare I tested to include the changes from your commit to start.S and retesting hello.exe.

But since BSP_START_COPY_FDT_FROM_U_BOOT is not defined this change unfortunately did not have any effect.

There are quite some changes from start.S from this commit (my last known working one) f30157f988df3c9f75c201124573520c03edf6a3 compared to main.

I could try to test a few commits to try to narrow down when the bsp stops to work perhaps?

One thing that I’m unsure of, do I need to rebuild the entire tool set? using

../source-builder/sb-set-builder

Or is it OK to just check out a newer commit on the same RTEMS branch and run Waf configure install etc?

12

You’ll be fine to to just rerun waf, I would recommend waf distclean && waf configure && waf (no need to install either for testing).

If you can attach a debugger and break at at the first dispatch into _RISCV_Vector_table and print a backtrace we might be able to identify if the issue looks the same. Or with a debugger in general, find out where execution is “hanging” (spinning).

I’ll try to brush off my beaglevfire and test it in the meanwhile.

13

@gedare

Ok, I spent the morning to get a debugger up and running. I’m running OpenOCD from Microchips Softconsole in Windows and then connecting to it from WSL. Works. Kinda. Very slow so far though.

If I just let the program run until spinning this is what I see

#0  0x00000010000043aa in _Atomic_Fetch_or_ulong (obj=0x1080000220, arg=1, order=memory_order_release) at ../../../cpukit/include/rtems/score/atomic.h:673
#1  _SMP_Request_shutdown () at ../../../cpukit/score/src/smp.c:299
#2  0x000000100000882a in bsp_fatal_extension (source=RTEMS_FATAL_SOURCE_EXCEPTION, always_set_to_false=<optimized out>, code=68719570656) at ../../../bsps/shared/start/bspfatal-default.c:72
#3  0x0000001000003c04 in _User_extensions_Iterate (arg=arg@entry=0x1000016ec0 <riscv_fill_up_htif_section+3776>, visitor=0x1000003b92 <_User_extensions_Fatal_visitor>, direction=direction@entry=CHAIN_ITERATOR_FORWARD) at ../../../cpukit/score/src/userextiterate.c:200
#4  0x00000010000023f8 in _User_extensions_Fatal (source=<optimized out>, error=<optimized out>) at ../../../cpukit/include/rtems/score/userextimpl.h:463
#5  _Terminate (the_source=<optimized out>, the_error=<optimized out>) at ../../../cpukit/score/src/interr.c:66
#6  0x00000010000040ea in _RISCV_Vector_table () at ../../../cpukit/score/cpu/riscv/riscv-exception-handler.S:354
Backtrace stopped: frame did not save the PC

-exec info registers mcause
mcause         0x4	4
-exec info registers mepc
mepc           0x100000dfaa	68719533994
-exec info registers mtval
mtval          0x10000148de	68719560926

image
image2238×723 112 KB

Placing a breakpoint at _RISCV_Vector_table this is the first time it’s being called.

-exec t 2
[Switching to thread 2 (Thread 2)]
#0  _RISCV_Vector_table () at ../../../cpukit/score/cpu/riscv/riscv-exception-handler.S:63
63		j .LRISCV_Exception_handler
-exec bt
#0  _RISCV_Vector_table () at ../../../cpukit/score/cpu/riscv/riscv-exception-handler.S:63
#1  0x000000100000a29a in fdt_string_eq_ (fdt=0x10000131b8 <system_dtb>, stroffset=<optimized out>, s=0x1000011560 "compatible", len=10) at ../../../cpukit/dtc/libfdt/fdt_ro.c:111
#2  fdt_get_property_namelen_ (fdt=fdt@entry=0x10000131b8 <system_dtb>, offset=88, offset@entry=0, name=name@entry=0x1000011560 "compatible", namelen=namelen@entry=10, lenp=lenp@entry=0x100001c52c <_ISR_Stack_area_begin+7980>, poffset=poffset@entry=0x100001c50c <_ISR_Stack_area_begin+7948>) at ../../../cpukit/dtc/libfdt/fdt_ro.c:414
#3  0x000000100000a4e2 in fdt_getprop_namelen (fdt=fdt@entry=0x10000131b8 <system_dtb>, nodeoffset=nodeoffset@entry=0, name=name@entry=0x1000011560 "compatible", namelen=namelen@entry=10, lenp=lenp@entry=0x100001c52c <_ISR_Stack_area_begin+7980>) at ../../../cpukit/dtc/libfdt/fdt_ro.c:460
#4  0x000000100000a97a in fdt_getprop (fdt=0x10000131b8 <system_dtb>, nodeoffset=0, name=0x1000011560 "compatible", lenp=0x100001c52c <_ISR_Stack_area_begin+7980>) at ../../../cpukit/dtc/libfdt/fdt_ro.c:508
#5  fdt_node_check_compatible (fdt=0x10000131b8 <system_dtb>, nodeoffset=0, compatible=0x1000011680 "riscv") at ../../../cpukit/dtc/libfdt/fdt_ro.c:858
#6  fdt_node_offset_by_compatible (fdt=fdt@entry=0x10000131b8 <system_dtb>, startoffset=startoffset@entry=-1, compatible=compatible@entry=0x1000011680 "riscv") at ../../../cpukit/dtc/libfdt/fdt_ro.c:880
#7  0x0000001000009386 in riscv_find_harts () at ../../../bsps/riscv/riscv/start/bspstart.c:100
#8  bsp_start () at ../../../bsps/riscv/riscv/start/bspstart.c:271
#9  0x00000010000051b6 in rtems_initialize_executive () at ../../../cpukit/sapi/src/exinit.c:152
#10 0x0000001000008806 in boot_card (cmdline=<optimized out>) at ../../../bsps/shared/start/bootcard.c:74
#11 0x000000100000002a in bsp_section_start_begin () at ../../../bsps/riscv/shared/start/start.S:102
Backtrace stopped: frame did not save the PC
-exec info registers mcause
mcause         0x4	4
-exec info registers mepc
mepc           0x100000dfaa	68719533994
-exec info registers mtval
mtval          0x10000148c1	68719560897

image
image2176×1252 294 KB

14

Good, both of these are showing the same root issue. mcause=4 is Load address misaligned. That’s a good hint. Use riscv-rtems7-objdump -d blah.exe > blah.txt to generate a disassembly and see what is at address 0x100000dfaa to find the faulting instruction, that should help narrow down the problematic/misaligned data load. Although, that might actually be part of the system_dtb in which case you would need to dig in to that.

Regarding the source of misalignment, based on the backtrace you have given, my best guess is that there is some kind of unaligned data within the compiled FDT. That’s just a guess though.

Why it shows up now and didn’t before is also unclear to me, but it could have to do just with memory layout changes.

15

it might be related to this thread: Add BSP for BeagleV-Fire board (!194) · Merge requests · RTEMS / RTOS / RTEMS · GitLab

which is now an open issue: risc-v: improve DTS/DTB/FDT handling, naming, and alignment (#5137) · Issues · RTEMS / RTOS / RTEMS · GitLab

16

@gedare First thanks for the help to debug this.

Looks like your best guess seems to be pretty good and looks close to the first link that you posted.

The disassembly points to memcmp. From the stack trace from the image I pasted above it should be fdt_ro.c:111 that is the culprit.

So if I understand it correctly mpfs.dts gets compiled into mpfs-dtb.h. The compiled FDT itself is correctly aligned so it must be some of the fields inside it that are not aligned properly as you said.

So I guess that either the thing that compiles the mpfs-dtb.h needs to ensure that all the internal fields have the correct alignment (adding padding?) or that memcmp is compiled with -mstrict-align to make sure that compiler ensures that all loads are aligned?

disassembly looks like this

000000100000dfa4 <memcmp>:
  100000dfa4:   469d                    li      a3,7
  100000dfa6:   00c6fb63                bgeu    a3,a2,100000dfbc <memcmp+0x18>
  100000dfaa:   6118                    ld      a4,0(a0)
17

If you can, you could see what is the a0 register at the fault. That will pinpoint the “bad address”.

Newlib should be handling the unaligned memcmp itself. This may be a bug in how we configure newlib’s riscv implementation of memcmp.

18

I took a deeper lock at newlib.
in memcmp.c:
if (!TOO_SMALL_LITTLE_BLOCK(n) && !UNALIGNED_X_Y(s1,s2))
In the generated assembly, it looks like the UNALIGNED_X_Y(s1,s2)) is being optimized out. Tracing this through defines, I think that this should get set by newlib probing the compiler for __riscv_misaligned_fast or __riscv_misaligned_slow, but it is not. Getting this fixed properly will take a bit of time to work through the RSB. I’ll try to look some more soon.

1 Like
19

Thanks.

I checked a0 and it’s pointing to 0x10000148c1. This is inside the FDT but not 8 byte aligned.

I’ll let this issue rest for a while then if it is inside the RSB. Feels like nothing more for me to do?

My original problem is that I experience a race error between rtems_event_send and rtems_event_receive between two threads in SMP configuration. Then I discovered another unknown error causing the scheduled events to never be fired in libbsd.

Is there anything in your findings above that could explain any of these two things?

Particularly the first one which to me is not a libbsd-issue it just happens that libbsd is the one calling the RTEMS functions. It feels far-fetched to me that they are related since I don’t see any exception or any other errors but not impossible I guess since we don’t know the entire scope of what goes wrong?

20

I would not expect the newlib alignment bug to be related to your problems with libbsd, since alignment errors should appear for you as fatal crashes. Hopefully someone else can chime in on that to provide some more ideas.

You’re right that the race error would seem unrelated to libbsd also. It would be helpful if it were possible to create a minimal repro on rtems, but obviously challenging since it’s apparently a race.