emomaxd opened a new issue, #15916: URL: https://github.com/apache/nuttx/issues/15916
### Description I've spent the past week porting NuttX to the BeagleY-AI board. I've gone through all available forums, issue trackers, and documentation, carefully following the official guides, yet I still haven't been able to get it working. The BeagleY-AI is a Texas Instruments board featuring the TI AM67 SoC, a heterogeneous system-on-chip that includes an ARM Cortex-A53 processor and an ARM Cortex-R5F co-processor. On the A53 cores, we're running a Debian-based Linux distribution and using remoteproc to boot firmware on the MAIN R5F core. The system expects firmware in ELF format, but when attempting to boot the ELF output of the NuttX kernel, I encounter the following error: ```shell Invalid Argument Error. Boot failed: -22 ``` I've tried various configuration options, particularly tweaking the defconfig and linker scripts, but so far, I haven't made any progress. One of my biggest challenges is understanding which configurations need to be modified for a successful boot. I've experimented with various values for kernel load address, RAM start address, and linker load address, yet none of them worked. What should these values be? Additionally, I’m unsure whether the addresses configured in remoteproc matter or if Linux handles this dynamically. Right now, the A53 core boots Linux via U-Boot, but I don't know where exactly remoteproc is loading the firmware for the R5F core. Any guidance on these memory addresses and configurations would be greatly appreciated. From what I understand, the error seems to be caused by missing sections in the ELF file, preventing Linux's remoteproc mechanism from properly parsing and booting it. This is just my assumption, but when I used readelf to inspect other working ELF firmware files, I noticed that they contained certain boot-related sections that were missing in NuttX’s ELF output—particularly at the beginning of the file. These could be the vector table, boot section, resource table, or even the device tree. So, as a last resort, if I can't resolve this issue through configuration changes, I’d like to explore the possibility of passing device tree data to remoteproc and NuttX. If there is a way to do this, a guide on how to implement it would be greatly appreciated. Starting tomorrow, I plan to add images for further debugging. Additionally, I'm considering creating a PR that links to this issue—would that be preferable, or should I include my code directly in this issue? Looking for guidance on the best approach. Also, I expect **extremely detailed insights** on the **device tree**, **remoteproc configuration**, and **kernel configuration** since these seem to be critical areas that might be causing the issue and could be could be valuable for future reference. ### Verification - [x] I have verified before submitting the report. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
