[rtems-tools]rtems-ld issue?
Hi, I use the latest rtems-tools to generate RAP file, I found the object file become too small(elf,2184bytes==>rap,736bytes) and the file loaded failed, error message like this "load app.out error:offset past end of file: offset=736 size=736 error." I reverted the rtl-rap.cpp commit( 0ad4aaafc20afcb5aacb7a82b0b3a8150b638975 linker/rap: Ignore relocation records with no section), the rap file can be loaded. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-tools] Fix shlex.join on python 3.8 and earlier
Hello Chris, if I did not make any mistake, this patch works fine on OpenSUSE 15.5. I had some headaches because the source-builder tries to download the rtems-tools as tar.bz2 and the version with the patch is not yet on that server. I fumbled your patch into the cached tar.bz2. That seemed to work in the end. Greetings Frank On 8/30/23 01:54, chr...@rtems.org wrote: Hi Frabnk and Joel, Can you please test this patch and let me know if the issue has been fixed? Thanks Chris -- embedded brains GmbH & Co. KG Herr Frank KÜHNDEL Dornierstr. 4 82178 Puchheim Germany email: frank.kuehn...@embedded-brains.de phone: +49-89-18 94 741 - 23 mobile: +49-176-15 22 06 - 11 Registergericht: Amtsgericht München Registernummer: HRA 117265 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-tools]rtems-ld issue?
On 31/8/2023 12:48 am, zhengxiaojun wrote: > Hi, > I use the latest rtems-tools to generate RAP file, I found the object file > become too small(elf,2184bytes==>rap,736bytes) and the file loaded failed, > error > message like this "load app.out error:offset past end of file: offset=736 > size=736 error." What arch and BSP? > I reverted the rtl-rap.cpp commit( 0ad4aaafc20afcb5aacb7a82b0b3a8150b638975 > linker/rap: Ignore relocation records with no section), the rap file can be > loaded. I think the commit has the wrong ticket id, it should be 4069 ... https://devel.rtems.org/ticket/4069 My guess is the length includes the relocs that have been dropped because they do not have a symbol section. A reloc without a symbol section cannot be located because you do not know the section to locate it against. Are you able to review the rtems-ld code for the issue? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/3] bsps/xnandpsu: Ensure correct cache maintenance
The changes here ensure correct cache maintenance around DMA operations.
One cache flush was missing and two cache invalidations occurred before
the corresponding read that would make them necessary.
---
bsps/shared/dev/nand/xnandpsu.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/bsps/shared/dev/nand/xnandpsu.c b/bsps/shared/dev/nand/xnandpsu.c
index 89451d19f8..85e6ba8532 100644
--- a/bsps/shared/dev/nand/xnandpsu.c
+++ b/bsps/shared/dev/nand/xnandpsu.c
@@ -2002,6 +2002,14 @@ static s32 XNandPsu_ReadPage(XNandPsu *InstancePtr, u32
Target, u32 Page,
Status = XNandPsu_Data_ReadWrite(InstancePtr, Buf, PktCount, PktSize,
0, 1);
+#ifdef __rtems__
+ if (InstancePtr->DmaMode == XNANDPSU_MDMA) {
+ if (InstancePtr->Config.IsCacheCoherent == 0) {
+ Xil_DCacheInvalidateRange((INTPTR)(void *)Buf, (PktSize
* PktCount));
+ }
+ }
+#endif
+
/* Check ECC Errors */
if (InstancePtr->EccMode == XNANDPSU_HWECC) {
/* Hamming Multi Bit Errors */
@@ -2115,6 +2123,14 @@ s32 XNandPsu_ReadSpareBytes(XNandPsu *InstancePtr, u32
Page, u8 *Buf)
Status = XNandPsu_Data_ReadWrite(InstancePtr, Buf, PktCount, PktSize,
0, 1);
+#ifdef __rtems__
+ if (InstancePtr->DmaMode == XNANDPSU_MDMA) {
+ if (InstancePtr->Config.IsCacheCoherent == 0) {
+ Xil_DCacheInvalidateRange((INTPTR)(void *)Buf, (PktSize
* PktCount));
+ }
+ }
+#endif
+
return Status;
}
@@ -2557,6 +2573,11 @@ static s32 XNandPsu_ChangeWriteColumn(XNandPsu
*InstancePtr, u32 Target,
if (InstancePtr->DmaMode == XNANDPSU_MDMA) {
RegVal = XNANDPSU_INTR_STS_EN_TRANS_COMP_STS_EN_MASK |
XNANDPSU_INTR_STS_EN_DMA_INT_STS_EN_MASK;
+#ifdef __rtems__
+ if (InstancePtr->Config.IsCacheCoherent == 0) {
+ Xil_DCacheFlushRange((INTPTR)(void *)Buf, (PktSize *
PktCount));
+ }
+#endif
XNandPsu_Update_DmaAddr(InstancePtr, Buf);
} else {
RegVal = XNANDPSU_INTR_STS_EN_BUFF_WR_RDY_STS_EN_MASK;
--
2.39.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/3] cpukit/jffs2: Avoid delayed work lock inversion
This moves delayed work to a temporary chain to prevent a locking
inversion between the delayed work lock and the alloc_sem lock. Delayed
work is now processed after the delayed work lock is released. Locking
order is any JFFS2 locks before the delayed work lock.
---
cpukit/libfs/src/jffs2/src/fs-rtems.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/cpukit/libfs/src/jffs2/src/fs-rtems.c
b/cpukit/libfs/src/jffs2/src/fs-rtems.c
index 59d03effe6..1a677c9772 100644
--- a/cpukit/libfs/src/jffs2/src/fs-rtems.c
+++ b/cpukit/libfs/src/jffs2/src/fs-rtems.c
@@ -1282,6 +1282,8 @@ static void process_delayed_work(void)
rtems_chain_node*node;
mutex_lock(&delayed_work_mutex);
+ rtems_chain_control process_work_chain;
+ rtems_chain_initialize_empty(&process_work_chain);
if (rtems_chain_is_empty(&delayed_work_chain)) {
mutex_unlock(&delayed_work_mutex);
@@ -1294,12 +1296,22 @@ static void process_delayed_work(void)
rtems_chain_node* next_node = rtems_chain_next(node);
if (rtems_clock_get_uptime_nanoseconds() >=
work->execution_time) {
rtems_chain_extract(node);
- work->callback(&work->work);
+ rtems_chain_append(&process_work_chain, node);
}
node = next_node;
}
mutex_unlock(&delayed_work_mutex);
+
+ node = rtems_chain_first(&process_work_chain);
+ while (!rtems_chain_is_tail(&process_work_chain, node)) {
+ work = (struct delayed_work*) node;
+ rtems_chain_node* next_node = rtems_chain_next(node);
+ rtems_chain_extract(node);
+ work->callback(&work->work);
+ node = next_node;
+ }
}
+
/* Task for processing delayed work */
static rtems_task delayed_work_task(
rtems_task_argument unused
--
2.39.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 3/3] bsps/zynqmp: Add locking around JFFS2 NAND adapter
The internal JFFS2 locking does not guarantee that delayed writes will
not step on other reads and writes to the device. This adds locking to
prevent that in the JFFS2 NAND interworking layer.
---
bsps/aarch64/xilinx-zynqmp/jffs2_xnandpsu.c | 30 ++---
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/bsps/aarch64/xilinx-zynqmp/jffs2_xnandpsu.c
b/bsps/aarch64/xilinx-zynqmp/jffs2_xnandpsu.c
index a64be91058..5fb00d5eeb 100644
--- a/bsps/aarch64/xilinx-zynqmp/jffs2_xnandpsu.c
+++ b/bsps/aarch64/xilinx-zynqmp/jffs2_xnandpsu.c
@@ -46,11 +46,13 @@
#include
#include
#include
+#include
#include
typedef struct {
rtems_jffs2_flash_control super;
XNandPsu *nandpsu;
+ rtems_mutex access_lock;
} flash_control;
static flash_control *get_flash_control(rtems_jffs2_flash_control *super)
@@ -68,7 +70,9 @@ static int flash_read(
XNandPsu *nandpsu = get_flash_control(super)->nandpsu;
rtems_status_code sc;
+ rtems_mutex_lock(&(get_flash_control(super)->access_lock));
sc = XNandPsu_Read(nandpsu, offset, size_of_buffer, buffer);
+ rtems_mutex_unlock(&(get_flash_control(super)->access_lock));
if (sc) {
return -EIO;
}
@@ -85,7 +89,9 @@ static int flash_write(
XNandPsu *nandpsu = get_flash_control(super)->nandpsu;
rtems_status_code sc;
+ rtems_mutex_lock(&(get_flash_control(super)->access_lock));
sc = XNandPsu_Write(nandpsu, offset, size_of_buffer, (void *)buffer);
+ rtems_mutex_unlock(&(get_flash_control(super)->access_lock));
if (sc) {
return -EIO;
}
@@ -112,7 +118,9 @@ static int flash_erase(
BlockIndex = (offset % DeviceSize) / BlockSize;
/* Perform erase operation. */
+ rtems_mutex_lock(&(get_flash_control(super)->access_lock));
sc = XNandPsu_EraseBlock(nandpsu, DeviceIndex, BlockIndex);
+ rtems_mutex_unlock(&(get_flash_control(super)->access_lock));
if (sc ) {
return -EIO;
}
@@ -137,7 +145,9 @@ static int flash_block_is_bad(
BlockIndex = offset / nandpsu->Geometry.BlockSize;
+ rtems_mutex_lock(&(get_flash_control(super)->access_lock));
*bad = (XNandPsu_IsBlockBad(nandpsu, BlockIndex) == XST_SUCCESS);
+ rtems_mutex_unlock(&(get_flash_control(super)->access_lock));
return 0;
}
@@ -146,6 +156,7 @@ static int flash_block_mark_bad(
uint32_t offset
)
{
+ rtems_status_code sc;
XNandPsu *nandpsu = get_flash_control(super)->nandpsu;
uint32_t BlockIndex;
@@ -155,7 +166,10 @@ static int flash_block_mark_bad(
BlockIndex = offset / nandpsu->Geometry.BlockSize;
- if ( XNandPsu_MarkBlockBad(nandpsu, BlockIndex) != XST_SUCCESS ) {
+ rtems_mutex_lock(&(get_flash_control(super)->access_lock));
+ sc = XNandPsu_MarkBlockBad(nandpsu, BlockIndex);
+ rtems_mutex_unlock(&(get_flash_control(super)->access_lock));
+ if ( sc != XST_SUCCESS ) {
return -EIO;
}
return RTEMS_SUCCESSFUL;
@@ -189,6 +203,7 @@ static int flash_read_oob(
return -ENOMEM;
}
+ rtems_mutex_lock(&(get_flash_control(super)->access_lock));
while (ooblen) {
int rv = XNandPsu_ReadSpareBytes(nandpsu, PageIndex, spare_bytes);
/* no guarantee oobbuf can hold all of spare bytes, so read and then copy
*/
@@ -198,6 +213,7 @@ static int flash_read_oob(
}
if (rv) {
+ rtems_mutex_unlock(&(get_flash_control(super)->access_lock));
free(spare_bytes);
return -EIO;
}
@@ -208,6 +224,7 @@ static int flash_read_oob(
ooblen -= readlen;
oobbuf += readlen;
}
+ rtems_mutex_unlock(&(get_flash_control(super)->access_lock));
free(spare_bytes);
return RTEMS_SUCCESSFUL;
}
@@ -219,6 +236,7 @@ static int flash_write_oob(
uint32_t ooblen
)
{
+ rtems_status_code sc;
uint8_t *spare_bytes;
uint8_t *buffer = oobbuf;
XNandPsu *nandpsu = get_flash_control(super)->nandpsu;
@@ -252,11 +270,14 @@ static int flash_write_oob(
/* Get page index */
uint32_t PageIndex = offset / nandpsu->Geometry.BytesPerPage;
- if ( XNandPsu_WriteSpareBytes(nandpsu, PageIndex, buffer) != XST_SUCCESS ) {
-free(spare_bytes);
+ rtems_mutex_lock(&(get_flash_control(super)->access_lock));
+ sc = XNandPsu_WriteSpareBytes(nandpsu, PageIndex, buffer);
+ rtems_mutex_unlock(&(get_flash_control(super)->access_lock));
+ free(spare_bytes);
+
+ if ( sc != XST_SUCCESS ) {
return -EIO;
}
- free(spare_bytes);
return RTEMS_SUCCESSFUL;
}
@@ -307,6 +328,7 @@ int xilinx_zynqmp_nand_jffs2_initialize(
flash_instance.super.write_size = NandInstPtr->Geometry.BytesPerPage;
flash_instance.nandpsu = NandInstPtr;
+ rtems_mutex_init(&flash_instance.access_lock, "XNandPsu JFFS2 adapter lock");
mount_data.flash_control = &flash_instance.super;
mount_data.compressor_control = &compressor_instance;
--
2.39.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-tools] Fix shlex.join on python 3.8 and earlier
On 31/8/2023 4:14 am, Frank Kühndel wrote: > Hello Chris, > > if I did not make any mistake, this patch works fine on OpenSUSE 15.5. Thanks, I have pushed the change. > I had some headaches because the source-builder tries to download the > rtems-tools as tar.bz2 and the version with the patch is not yet on that > server. > I fumbled your patch into the cached tar.bz2. That seemed to work in the end. Ah, a clone of rtems-tools and then a `distclean configure` showed the issue :) Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[RSB PATCH] rtems/tools: Execute use of shlex.join fix for python < 3.8
From: Chris Johns
Updates #4951
---
rtems/config/tools/rtems-tools-6.cfg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/rtems/config/tools/rtems-tools-6.cfg
b/rtems/config/tools/rtems-tools-6.cfg
index b360f7e..9632d5b 100644
--- a/rtems/config/tools/rtems-tools-6.cfg
+++ b/rtems/config/tools/rtems-tools-6.cfg
@@ -10,14 +10,14 @@
%define rtems_tools_source rtems-tools-%{rtems_tools_version}
%define rtems_tools_ext xz
%else
- %define rtems_tools_version 3ea0c249346fda427bf0d3c169aa3e7c2a521df8
+ %define rtems_tools_version eda9325e583f761c53ee3db83124cc77cb4fefb5
%define rtems_tools_ext bz2
%endif
%define rtems_tools_source rtems-tools-%{rtems_tools_version}
%source set rtems-tools
https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
%hash sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
-
+wrMxGHJp5cd/hpgoGwTH65IvwZQsAWOb8JNmDZKdFqUbhUuUYq1zK1p5NJnvCUkHudxgDmghAe/5kaFE5DJ4w==
+
kdrwOv0iUKYjWud2g/9aSnduIniNWnQKry04zwKEiwlKdg1KnMhGu4b0mpQD2PnsYxGha/ksPEnHLPnahQTarg==
#
# Optionally enable/disable building the RTEMS Tools via the command line.
--
2.37.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-tools]rtems-ld issue?
在 2023/8/31 6:05, Chris Johns 写道: On 31/8/2023 12:48 am, zhengxiaojun wrote: Hi, I use the latest rtems-tools to generate RAP file, I found the object file become too small(elf,2184bytes==>rap,736bytes) and the file loaded failed, error message like this "load app.out error:offset past end of file: offset=736 size=736 error." What arch and BSP? ARM, imx6ull I reverted the rtl-rap.cpp commit( 0ad4aaafc20afcb5aacb7a82b0b3a8150b638975 linker/rap: Ignore relocation records with no section), the rap file can be loaded. I think the commit has the wrong ticket id, it should be 4069 ... https://devel.rtems.org/ticket/4069 My guess is the length includes the relocs that have been dropped because they do not have a symbol section. A reloc without a symbol section cannot be located because you do not know the section to locate it against. Are you able to review the rtems-ld code for the issue? I am trying to find something, but I do not know elf/rap format well. I found when ignore synsect==0, the GLOBAL symbol will be ignore too. Should the GLOBAL symbol be dealt with? Here is part of ELF: Symbol table (.symtab) [ Nr ] ValueSize TypeBind Sect Name [0] NOTYPE LOCAL0 [1] NOTYPE LOCAL4 $d [2] 0001 011e FUNCLOCAL1 task_test [3] NOTYPE LOCAL1 $t [4] NOTYPE LOCAL3 $d [5] NOTYPE LOCAL4 .LC0 [6] 0030 NOTYPE LOCAL4 .LC3 [7] NOTYPE LOCAL3 .LANCHOR0 [8] 000c NOTYPE LOCAL4 .LC1 [9] 0038 NOTYPE LOCAL4 .LC4 [ 10] NOTYPE GLOBAL 0 putchar [ 11] NOTYPE GLOBAL 0 printf [ 12] NOTYPE GLOBAL 0 rtems_task_wake_after [ 13] NOTYPE GLOBAL 0 puts [ 14] NOTYPE GLOBAL 0 tcflush [ 15] 0121 0054 FUNCGLOBAL 1 appmain [ 16] NOTYPE GLOBAL 0 rtems_task_start [ 17] NOTYPE GLOBAL 0 cfsetispeed [ 18] NOTYPE GLOBAL 0 write [ 19] NOTYPE GLOBAL 0 cfsetospeed [ 20] NOTYPE GLOBAL 0 read [ 21] NOTYPE GLOBAL 0 tcgetattr [ 22] NOTYPE GLOBAL 0 open [ 23] NOTYPE GLOBAL 0 tcsetattr [ 24] NOTYPE GLOBAL 0 rtems_task_create Chris ___ 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
Re: [rtems-tools]rtems-ld issue?
On 31/8/2023 1:51 pm, zhengxiaojun wrote: > 在 2023/8/31 6:05, Chris Johns 写道: >> On 31/8/2023 12:48 am, zhengxiaojun wrote: >>> Hi, >>> I use the latest rtems-tools to generate RAP file, I found the object >>> file >>> become too small(elf,2184bytes==>rap,736bytes) and the file loaded failed, >>> error >>> message like this "load app.out error:offset past end of file: offset=736 >>> size=736 error." >> >> What arch and BSP? > ARM, imx6ull > >> >>> I reverted the rtl-rap.cpp commit( >>> 0ad4aaafc20afcb5aacb7a82b0b3a8150b638975 >>> linker/rap: Ignore relocation records with no section), the rap file can be >>> loaded. >> >> I think the commit has the wrong ticket id, it should be 4069 ... >> >> https://devel.rtems.org/ticket/4069 >> >> My guess is the length includes the relocs that have been dropped because >> they >> do not have a symbol section. A reloc without a symbol section cannot be >> located >> because you do not know the section to locate it against. >> >> Are you able to review the rtems-ld code for the issue? > I am trying to find something, but I do not know elf/rap format well. I found > when ignore synsect==0, the GLOBAL symbol will be ignore too. > Should the GLOBAL symbol be dealt with? > > Here is part of ELF: > Symbol table (.symtab) > [ Nr ] Value Size Type Bind Sect Name > [ 0] NOTYPE LOCAL 0 > [ 1] NOTYPE LOCAL 4 $d > [ 2] 0001 011e FUNC LOCAL 1 task_test > [ 3] NOTYPE LOCAL 1 $t > [ 4] NOTYPE LOCAL 3 $d > [ 5] NOTYPE LOCAL 4 .LC0 > [ 6] 0030 NOTYPE LOCAL 4 .LC3 > [ 7] NOTYPE LOCAL 3 .LANCHOR0 > [ 8] 000c NOTYPE LOCAL 4 .LC1 > [ 9] 0038 NOTYPE LOCAL 4 .LC4 > [ 10] NOTYPE GLOBAL 0 putchar > [ 11] NOTYPE GLOBAL 0 printf > [ 12] NOTYPE GLOBAL 0 rtems_task_wake_after > [ 13] NOTYPE GLOBAL 0 puts > [ 14] NOTYPE GLOBAL 0 tcflush > [ 15] 0121 0054 FUNC GLOBAL 1 appmain > [ 16] NOTYPE GLOBAL 0 rtems_task_start > [ 17] NOTYPE GLOBAL 0 cfsetispeed > [ 18] NOTYPE GLOBAL 0 write > [ 19] NOTYPE GLOBAL 0 cfsetospeed > [ 20] NOTYPE GLOBAL 0 read > [ 21] NOTYPE GLOBAL 0 tcgetattr > [ 22] NOTYPE GLOBAL 0 open > [ 23] NOTYPE GLOBAL 0 tcsetattr > [ 24] NOTYPE GLOBAL 0 rtems_task_create Looking at this the change does not seem right. I cannot remember why it was added. It may require building the supported archs without the patch to see what happens, specifically RISCV. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 0/4] New UART drivers for PL011 and Mini UART
A gentle reminder for this patch. Please have a look at this and let me
know what changes are required. Once this is merged, I have a few more
patches building upon this.
Regards,
Utkarsh
On Wed, Aug 30, 2023 at 9:47 AM Utkarsh Verma wrote:
> This patch series adds two drivers, PL011 and Mini UART. Both support
> interrupts and implement the termios API.
>
> Why add a new driver for the PL011 when we already have one?
>
> The existing driver is a very basic one and uses memory-mapped structs
> to access the registers. This proved to be problematic for the
> 'aarch64/raspberrypi4b' BSP as the RPi 4B's MMU does not reserve the
> entirety of the space required by the PL011 register struct.
>
> Even the existing driver doesn't use all the struct members. So, in the
> new driver, macros were used instead. This has the benefit of minimalism
> and ensures that we only add tested features to the driver.
>
> This driver builds upon the PL011 driver present in the Xilinx Versal
> BSP and addresses the IRQ startup hack.
>
> In short, the new PL011 driver has the features provided by the
> existing driver, and it meshes well with the termios API.
>
> Lastly, there's one thing I need feedback on. The PL011 has a hardware
> limitation which requires me to invoke the IRQ handler manually, the
> first time. For this, I need access to the `tty` struct in the
> `write_buffer` function.
>
>
> https://github.com/UtkarshVerma/rtems/blob/uart-drivers/bsps/shared/dev/serial/pl011.c#L301
>
> For now, I store the tty in the device context and then pass the context
> to the IRQ handler. Is this a good approach? Are there better ways to do
> this?
>
> For convenience, feel free to check out my GitHub fork which has these
> changes:
>
> https://github.com/UtkarshVerma/rtems/tree/uart-drivers
>
> Utkarsh Verma (4):
> bsps/shared: Add new PL011 driver with IRQ support
> bsps/shared: Add new Mini UART driver
> spec: Add Mini UART and PL011 drivers to build spec
> bsps: Update BSPs to use the new PL011 driver
>
> bsps/aarch64/a53/console/console.c| 15 +-
> bsps/aarch64/a72/console/console.c| 15 +-
> bsps/aarch64/raspberrypi/console/console.c| 29 +-
> bsps/arm/raspberrypi/console/console-config.c | 27 +-
> .../realview-pbx-a9/console/console-polled.c | 5 +-
> .../arm/realview-pbx-a9/include/bsp/console.h | 4 +-
> bsps/arm/xen/console/console.c| 15 +-
> bsps/include/dev/serial/arm-pl011-regs.h | 143 --
> .../dev/serial/{arm-pl011.h => mini-uart.h} | 52 +-
> bsps/include/dev/serial/pl011.h | 68 +++
> bsps/shared/dev/serial/arm-pl011.c| 104
> bsps/shared/dev/serial/mini-uart.c| 316
> bsps/shared/dev/serial/pl011.c| 470 ++
> .../aarch64/raspberrypi/bspraspberrypi4.yml | 1 -
> spec/build/bsps/obj.yml | 7 +-
> 15 files changed, 934 insertions(+), 337 deletions(-)
> delete mode 100644 bsps/include/dev/serial/arm-pl011-regs.h
> rename bsps/include/dev/serial/{arm-pl011.h => mini-uart.h} (64%)
> create mode 100644 bsps/include/dev/serial/pl011.h
> delete mode 100644 bsps/shared/dev/serial/arm-pl011.c
> create mode 100644 bsps/shared/dev/serial/mini-uart.c
> create mode 100644 bsps/shared/dev/serial/pl011.c
>
> --
> 2.41.0
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-tools]rtems-ld issue?
在 2023/8/31 6:05, Chris Johns 写道: On 31/8/2023 12:48 am, zhengxiaojun wrote: Hi, I use the latest rtems-tools to generate RAP file, I found the object file become too small(elf,2184bytes==>rap,736bytes) and the file loaded failed, error message like this "load app.out error:offset past end of file: offset=736 size=736 error." What arch and BSP? I reverted the rtl-rap.cpp commit( 0ad4aaafc20afcb5aacb7a82b0b3a8150b638975 linker/rap: Ignore relocation records with no section), the rap file can be loaded. I think the commit has the wrong ticket id, it should be 4069 ... https://devel.rtems.org/ticket/4069 My guess is the length includes the relocs that have been dropped because they do not have a symbol section. A reloc without a symbol section cannot be located because you do not know the section to locate it against. Are you able to review the rtems-ld code for the issue? I found something suspicious, get_relocations(s) return all the count of relocation and write to rap file, but actual count is less, because ignore the reloc with section=0. This issue is similar to ticket #4781, maybe the same. reduce count or write all relocs in rap ? I do not know which is the right solution. Chris ___ 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
Re: [rtems-tools]rtems-ld issue?
On 31/8/2023 3:12 pm, zhengxiaojun wrote: > > > 在 2023/8/31 6:05, Chris Johns 写道: >> On 31/8/2023 12:48 am, zhengxiaojun wrote: >>> Hi, >>> I use the latest rtems-tools to generate RAP file, I found the object >>> file >>> become too small(elf,2184bytes==>rap,736bytes) and the file loaded failed, >>> error >>> message like this "load app.out error:offset past end of file: offset=736 >>> size=736 error." >> >> What arch and BSP? >> >>> I reverted the rtl-rap.cpp commit( >>> 0ad4aaafc20afcb5aacb7a82b0b3a8150b638975 >>> linker/rap: Ignore relocation records with no section), the rap file can be >>> loaded. >> >> I think the commit has the wrong ticket id, it should be 4069 ... >> >> https://devel.rtems.org/ticket/4069 >> >> My guess is the length includes the relocs that have been dropped because >> they >> do not have a symbol section. A reloc without a symbol section cannot be >> located >> because you do not know the section to locate it against. >> >> Are you able to review the rtems-ld code for the issue? >> > I found something suspicious, get_relocations(s) return all the count of > relocation and write to rap file, but actual count is less, because ignore the > reloc with section=0. Right, this aligns with my guess. That value should the number written out and it should not assume all are written. > This issue is similar to ticket #4781, maybe the same. Yeah it could. It would be nice if it is. > reduce count or write all relocs in rap ? I do not know which is the right > solution. I am not sure. If relocs are needed then we have to have them and the patch you isolated is wrong or needs more understanding to know why it is there. I suspect an arch had an issue and this was the solution but that is guess on my part. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
