I built the latest image from the arduino branch and see the same kernel oops.
1 Like
Nearly there 
I applied all Arduino branch changes to the memory map, u-boot, Linux and root filesystem. Now it boots, just some things to fix due to flash being read-only. You’ll need to think about how to make your Arduino firmware persistent across reboots.
Starting app...
[root@milkv-duo]~# mkdir: can't create directory '/lib/firmware': Read-only file system
From the Arduino IDE:
burntool.py v0.3
upload firmware /tmp/arduino/sketches/56CCA581BF3E1D2E097D05132C443CF3/Blink.ino.elf
start upload...
communication and testing...
connecting...
connection successful...
stop firmware...
ready to update firmware...
start to update firmware...
send data... 10.00%
send data... 20.00%
send data... 30.00%
send data... 40.00%
send data... 50.00%
send data... 60.00%
send data... 70.00%
send data... 80.00%
send data... 89.99%
send data... 99.99%
send data... 100.00%
update firmware done...
restart firmware...
upload and runing success...
Then another message on Duo (and no firmware execution):
[ 166.056620] remoteproc remoteproc0: request_firmware failed: -2
[ 166.063588] remoteproc remoteproc0: Boot failed: -2
Possible fix is to mount /lib/firmware as a ramdisk.
1 Like
Fixed and uploaded to GitHub.
Let me know how you get on, then I’ll raise a PR to merge into the mainline. You’ll have to re-upload the arduino code each reboot and may not have many GPIOs remaining due to the SPI flash pins being in use. The blink sketch works.
1 Like
Unfortunately it fails to upload (in Arduino) to Milk V like most of the time. Sometimes it succeeds sometimes it fails until you reboot
Also theres no serial output.
1 Like
If it helps, I am not seeing problems myself. I added some lines to the blink sketch:
// the setup function runs once when you press reset or power the board
void setup() {
// initialize digital pin LED_BUILTIN as an output.
pinMode(LED_BUILTIN, OUTPUT);
Serial.begin(115200);
}
// the loop function runs over and over again forever
void loop() {
digitalWrite(LED_BUILTIN, HIGH); // turn the LED on (HIGH is the voltage level)
Serial.println("Hello");
delay(1000); // wait for a second
digitalWrite(LED_BUILTIN, LOW); // turn the LED off by making the voltage LOW
Serial.println("Risc-V");
delay(1000); // wait for a second
}
The result is a blinking LED and serial output on UART2/3:
Hello
Risc-V
Hello
Risc-V
Hello
Risc-V
Pin 6 is TX, 7 is RX as per duo-datasheet-v1.2.
1 Like
@ewp if its not too much trouble. Can you tell me what changes you made to arduino branch of buildroot to get it not to panic. I downloaded the source code you provided but it wont even build.
Will retry the serial to see if it works. But i remember trying all the uarts.
1 Like
Please run git show on my latest commits to get the full changes. In essence I freed some RAM to fix the oops caused by OOM. The image was built from this code so there should be no compilation errors. Please let me know what the errors are.
1 Like
I mistook the Pin header number 6 & 7 for GPIO number 6 & 7 for uart. Thats why i wasnt getting serial. So GPIO4 is TX and GPIO5 is RX for uart 2/3.
I noticed that Milk v was disconnecting then reconnecting often. It might be why it wasnt uploading the code. But thats still an issue.
Also can the milk v not support read/write flash filesystem like other mcus have. You could maybe have a read/write flash file system on a seperate partition on there and make a copy of the image arduino sends to milk v then store it there and load it to rtos core when milk v boots up.
Another way is to rebuild fip.bin to include the new arduino image and flash only that part to the milk v but that would have to be done by the people who support milkvs arduino ide board library.
1 Like
The disconnections are likely caused by wiring and handling alone. I do not use jumper wires, but just touching my Duo is enough to corrupt I/O or crash it. The perils of a dev board.
The MCUs can support read-write flash. Perhaps look at my SPI NAND flash builds or experiment yourself with JFFS and UBI. Changing squashfs to JFFS might be the only change you need to make. Consider that if you are using SPI NOR for more resilience than a TF Card then you’ll need to severely limit and wear-level the write cycles.
This is a very open SDK and so making the tweaks you need should be achievable.
1 Like
How do you do that? is it from the Makefile?
1 Like
Yes, mostly the Makefile with some work on the root filesystem and partitions.
1 Like
The primary change was to reduce the ION size since this seems to be an issue with the Arduino branch’s available memory during boot. There are other things in this commit.
1 Like
Can confirm that the issue was indeed Ion even when i let it have 8MB kernel went into panic.
1 Like
Also does the script duo-init in /mnt/system get run after bootup @ewp. Also i noticed the cpu frequency is 850 Mhz. I wanna put both of the cores at maximum frequency. Ik about cooling and other stuff. I just want to know where i will find those settings
1 Like
There are a few people that have solved the clock issue, e.g. bare metal and Debian.
For startup, look in /etc/initttab. It all starts from there.
1 Like
It seems the maximum free ram i can allocate to rtos is around 26 MB which is what ION was using. i tried Allocating 32 MB but for someone reason uboot uses 15 MB , so i tried decreasing it to 12 and it wont load kernel
edit: If you adjust UIMAGE_SIZE and Kernel buffer size you can get 32 MB
1 Like
Curious what will you want it for, in the secondary core.
Also, there’s an 8051 microcontroller core as well, and it has its own static RAM, if I recall correctly, or you can give it some of the system RAM too.
More or less for graphics. But havent got it yet to save arduino firmware so
1 Like
i changed those things in my build but although arduino code gets uploaded it doesnt seem like it runs the code
1 Like