Well, the same SDK in full version produces certainly an installation where things work just fine (which doesn’t solve the problem your’re facing); are ls and other commands just BusyBox applets? If so, this can explain why other executables are different in this regard.
Here the result with my SPINOR image. @WeiMouMou please check the below and also rebiew your git commits. It should work.
[root@milkv-duo]~# mount | grep root
/dev/root on / type squashfs (ro,relatime)
[root@milkv-duo]~# duo-pinmux
pinmux for duo
duo-pinmux -p <== List all pins
duo-pinmux -l <== List all pins and its func
duo-pinmux -r pin <== Get func from pin
duo-pinmux -w pin/func <== Set func to pin
[root@milkv-duo]~# which duo-pinmux
/usr/bin/duo-pinmux
[root@milkv-duo]~# ls -l /usr/bin/duo-pinmux
-rwxr-xr-x 1 root root 19224 Aug 11 14:12 /usr/bin/duo-pinmux
1 Like
it was a problem with the mountpoint of jffs2 partition. I was mounting it on /lib so that it can be accessed like this /lib/firmware. But it seems to be breaking some files in /lib folder.
i have this fstab now.
# <file system> <mount pt> <type> <options> <dump> <pass>
/dev/root / ext2 rw,noauto 0 1
proc /proc proc defaults 0 0
devpts /dev/pts devpts defaults,gid=5,mode=620,ptmxmode=0666 0 0
tmpfs /dev/shm tmpfs mode=0777 0 0
tmpfs /tmp tmpfs mode=1777 0 0
tmpfs /run tmpfs mode=0755,nosuid,nodev 0 0
sysfs /sys sysfs defaults 0 0
debug /sys/kernel/debug debugfs defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 0
/dev/mtdblock4 /mnt jffs2 rw,defaults 0 0
# Bind mount the /mnt/flash0/firmware directory to /lib/firmware
/mnt/flash0/firmware /lib/firmware none bind 0 0
not sure yet how know how exactly binds works…i dont want a case of it being /lib/firmware/firmware. I also created the firmware folder device/common/br_overlay/lib/firmware and device/common/overlay/mnt/flash0
1 Like
Why not mount /dev/mtdblock4 directly onto /lib/firmware? Or if you need more stored in the jffs2 filesystem, use a soft link instead?
1 Like
when I mount it directly on it it causes issues . Like it would be mounted as /lib/firmware/firmware. if i mount it at /lib its path would be /lib/firmware but it will corrupt some of file libs there which was what was causing cvi-pinmux and duo-pinux to not function. Right now the binding works well. If arduino code gets upload to milk v , its written to /lib/firmware which actually writes to /mnt/flash0/firmware. So the changes are saved and when Milk V duo restarts it loads the arduino.elf from /lib/firmware which is actual /mnt/flash0/firmware. With that you can also store files in root of flash0.
Possible the only bad thing is elf executables take up alot of space. And it seems arduino file doesnt get deleted but renamed to arduino.old. So then a Sketch i have from arduino take 523 KB , so if i reupload the same code its 2x 523 KB. 1MB already used from 4 MB of flash.
in the sense of rtos on the arduino side the elf file format doesnt make sense because it will literally be loaded at the same address every single time because remoteproc doesnt “relocate” anything. it simple loads the elf at the exact address specified in elf header lol which in arduino is hardcoded to one value unless you modify the build files.
1 Like
That’s not great for wear levelling. However, for your purposes, you can remove a lot of the root filesystem and hence allocate more of the 32 MB to JFFS2.
1 Like
Btw is it not possible to get serial out via the usb port rather than uart pins?
1 Like
Do you mean when using the little Arduino core?
1 Like
Yeah like using the same usb serial port it uses to upload the code
1 Like
I do not believe it is possible. If you need USB serial then perhaps add a CH340C or CH340E?
1 Like
Doesnt it support many different usb device modes. It is strange for a sbc to not have usb cdc supported. And using a usb to serial chip is basically the same issue. Instead of using 2 ports, one from milk v’s usb type c port and one from usb to serial adapter. it would be good if upload + serial used only the type c port rather than it only being used for uploading firmware.
It just more of a wanted feature rather than something that has a issue.
1 Like
Yes, you could use a composite USB device. However, the USB is controlled by Linux on the main core. So you’d probably need to write a bridge between the second serial port on the little core.
1 Like
Could you remind me please why exactly you didn’t like the full-sized firmware on a TF, in the first place?
Doesn’t it work well for you?
I dont have the need for a full linux image. As i said im using it for Arduino and i already have source code written in arduino for the project im gonna use it for which is a portable console. Hence why i said id use ram for graphics and the 700 Mhz rtos mcu is the fastest i can find for a low price. Plus its Risc V. I might want to use the sdcard slot for loading custom games/apps later so it would not be a good thing if the OS bricked when i removed sdcard.
I know you can infact do it with linux but it would be a hassle to write linux kernel stuff and rewrite all that code for linux not to mention I would not have the full control i have by writing my own firmware. Like graphics for example would be a major pain. I have always prefered writing my own stuff if possible because then I dont have to pull on my hair wondering what a function does. Arduino gives you just enough control to do whatever you want and anything else u can write custom drivers etc. Ig if milk v had something like espidf it would be better suited but for now it doesnt.
And ofc I did have trouble with the sd images, it got corrupted sometimes or couldnt connect till reboot.