Have you tested the identical ELF on the standard SD build, and did the LED blink then? If so, what diagnostics do you have from your current build? What does git diff between your build and mine show as different?
I think its a loading issue. Increasing the RTOS Ram in memmap
# ==============
# C906L FreeRTOS
# ==============
FREERTOS_SIZE = 24576 * SIZE_1K
# FreeRTOS is at the end of DRAM
FREERTOS_ADDR = DRAM_BASE + DRAM_SIZE - FREERTOS_SIZE
FSBL_C906L_START_ADDR = FREERTOS_ADDR
using this it failed to work because the ELF file is forced to load at 0x83f40000. But the new RTOS RUN ADDR is 0x82800000. If i change it back to using 768K is works though there is still an error if you upload via arduino. But if you run it from linux it works. I thought Elf files were relocatable. It seems that either arduino is forcing it to load that address or something is hardcoded.
Right now im looking at the compiler scripts on Arduinos end
For the linker
C:\Users[ User Name ]\AppData\Local\Arduino15\packages\sophgo\hardware\SG200X\0.2.4\variants\duo\link.ld
changed ORIGIN to 0x82800000. You also have to change LENGTH to the same value as duo.build.image_size in board.txt file assuming you changed it.
/* Define Memories in the system */
/* LENGTH is the Total Memory , Old ORIGIN = 0x83f40000 */
MEMORY
{
psu_ddr_0_MEM_0 : ORIGIN = 0x82800000 , LENGTH = 0xc0000
}
After that close arduino ide. And delete all the folders in the temporary folder "C:\Users[ User Name ]\AppData\Local\Temp\arduino". If you dont delete it arduino ide will use the precious duo settings because it precompiles some part of it.
dmesg output
[ 16.392603] random: fast init done
[ 16.395752] remoteproc remoteproc0: powering up c906l_rproc@0
[ 16.499160] remoteproc remoteproc0: Booting fw image arduino2.elf, size 576112
[ 16.518330] cvitek-rproc c906l_rproc@0: Allocated carveout doesn't fit device address request
[ 16.521571] cvitek-rproc c906l_rproc@0: Started from 0x82800000
[ 16.521592] remoteproc remoteproc0: remote processor c906l_rproc@0 is now up
Now going to check on the usb upload side of things
putting this mount -t tmpfs -o mode=0755,nosuid,nodev tmpfs /lib/firmware make it âworkâ
#!/bin/sh
/etc/uhubon.sh device >> /tmp/ncm.log 2>&1
/etc/run_usb.sh probe ncm >> /tmp/ncm.log 2>&1
if test -e /usr/bin/burnd; then
/etc/run_usb.sh probe acm >> /tmp/ncm.log 2>&1
fi
/etc/run_usb.sh start ncm >> /tmp/ncm.log 2>&1
sleep 0.5
ifconfig usb0 192.168.42.1
count=`ps | grep dnsmasq | grep -v grep | wc -l`
if [ ${count} -lt 1 ] ;then
echo "/etc/init.d/S80dnsmasq start" >> /tmp/ncm.log 2>&1
/etc/init.d/S80dnsmasq start >> /tmp/ncm.log 2>&1
fi
sleep 2
mount -t tmpfs -o mode=0755,nosuid,nodev tmpfs /lib/firmware
mkdir -p /lib/firmware
if test -e /usr/bin/burnd; then
burnd &
if test -e /lib/firmware/arduino.elf; then
sleep 2
echo stop > /sys/class/remoteproc/remoteproc0/state
echo start > /sys/class/remoteproc/remoteproc0/state
fi
fi
Now im looking to make 4MB from the bottom of flash into jffs2 so I can save the firmware but dont know much about how to do that. Modified the partition xml but builds fail with it so idk.
It fails if you dont have this mount -t tmpfs -o mode=0755,nosuid,nodev tmpfs /lib/firmware. The directory does exist in rootfs btw and even when the directory didnt exist it still need this.
for the jffs2 filesystem i did this in the makefile
the system.spinor just contain /lib/firmware folder. So i have successful got the partition made and flashed but I dont know if it automounts jffs2 or if i need mount it in some file.
Note in some places you have System.spinor and in others system.spinor. These should all be system.spinor. Check U-Boot writes it to flash and then try mounting the filesystem manually in Duo Linux. It it all works then decide when during boot you wish to mount this. Probably in /etc/fstab.
there is System.jffs2 and system.spinor. Systen.jffs2 is folder that just stores the files and folders to put in the jffs2 filesystem. In my case it stores /firmware folder and cvirtos.elf which i renamed to arduino.elf . I will mount it on /lib with fstab.
Do they have executable (+x) flag set? If not, you should make them executable. If it is on a read-only filesystem, then they should be marked executable in the process of firmware generation.