Hello Gedare,
I get linker errors with this BSP:
Waf: Entering directory `/tmp/sh/b-rtems/aarch64/xilinx_versal_ilp32_vck190'
10:51:14 runner 'git rev-parse HEAD'
[1334/4030] Compiling bsps/aarch64/shared/start/start.S
10:51:16 runner ['/opt/rtems/6/bin/aarch64-rtems6-gcc', '-MMD',
'-mcpu=corte
The existing fix for the ZynqMP UART hardware bug only caught the vast
majority of instances where it could occur. To fully fix the data
corruption, this fix must be applied after every baud rate change. This
makes the logic reset and kick apply in any locations where the baud
rate could be changed
Move the moduleid register to the correct offset according to Cadence IP
documentation.
---
bsps/include/dev/spi/cadence-spi-regs.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/bsps/include/dev/spi/cadence-spi-regs.h
b/bsps/include/dev/spi/cadence-spi-regs.h
index b4b2366b3d..207d056fb1 10
Hi,
The current RTEMS 6/master branch does not seem to work on the
Raspberry Pi single core models, while the 5 branch does.
I was able to track it down to a commit where it stopped working:
272534eb725f2486b7a32b39d998202a101bd36e
In that commit, the call:
/* Clear Secure or Non-secure Vector B
Hi,
I am just catching up and missed this one until I saw the patch was pushed. I am
sorry but I am confused by this patch.
Could someone please explain this reason for this addition to the BSP and
approach being taken? Is there something in the BSP that requires this
information be provided here
Hello Alan,
On 29/06/2021 03:13, Alan Cudmore wrote:
The current RTEMS 6/master branch does not seem to work on the
Raspberry Pi single core models, while the 5 branch does.
I was able to track it down to a commit where it stopped working:
272534eb725f2486b7a32b39d998202a101bd36e
In that commi
