U-Boot 2021.10 (Aug 04 2024 - 15:05:57 -0300)cvitek_cv180x
DRAM: 63.3 MiB
gd->relocaddr=0x823f3000. offset=0x21f3000
MMC: cv-sd@4310000: 0
Loading Environment from SPIFlash... spinor id = EF 40 19
SF: Detected W25Q256JV-IQ with page size 256 Bytes, erase size 4 KiB, total 32 MiB
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Net:
Warning: ethernet@4070000 (eth0) using random MAC address - ee:69:b0:67:14:0a
eth0: ethernet@4070000
Hit any key to stop autoboot: 1 0
spinor id = EF 40 19
SF: Detected W25Q256JV-IQ with page size 256 Bytes, erase size 4 KiB, total 32 MiB
device 0 offset 0xa0000, size 0x400000
SF: 4194304 bytes @ 0xa0000 Read: OK
sf read speed 31.775 MB/s
Wrong Image Format for bootm command
ERROR: can't get kernel image!
## Error: "nandboot" not defined
## Error: "emmcboot" not defined
cv180x_c906#
so yeh it doesnt like the other chip. Flashing this chip works but as you can see the first byte is somehow corrupted when using sf and it fails to load kernel And if for example you wanted to load the kernel which is at 0xA0000 , you would have to do sf read 0x813FFFFF 256 and then md.b 0x81400000 so the first byte wouldnt be corrupted…so
That is very strange since you are using the flash image I extracted from mtdblock over ssh from my running Duo. Does the read result in the same issue every time, e.g. for 5 times?
Yep. But its even stranger…if boot.spinor supposed to be the “linux image”. Why doesnt manually loading the whole 3 MB image into memory work… cuz i tried using both bootm and booti after loading the image to memory with sf read. But it still says wrong image format
I also tried modifying where it loads the linux image and made it display some values
This is from bootm.c
static int bootm_find_os(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
const void *os_hdr;
bool ep_found = false;
int ret;
/* get kernel image header, start address and length */
os_hdr = boot_get_kernel(cmdtp, flag, argc, argv,
&images, &images.os.image_start, &images.os.image_len);
/*if (images.os.image_len == 0) {
puts("ERROR: can't get kernel image!\n");
return 1;
}*/
if (images.os.image_start == 0) {
puts("ERROR: Kernel Start is 0 \n");
}
else{
char buffer[21]; // 20 digits for unsigned long plus null terminator
snprintf(buffer, sizeof(buffer), "%lu", images.os.image_start);
puts("Start Address : ");
puts(buffer);
puts(" \n");
}
but apparently The start address is 0 along with the length of the image…
I dont know much about the image format uboot expects the os to be in…but looking around it seems there are many different images supported even architectures which makes the code all the more confusing.
The flash address I was focussing on was 0x0. This is from where the ROM boots the FSBL fip.bin. So we can see the CPU can technically read this correctly using its ROM code. However the U-Boot read behaves differently. Could you increase u-boot verbosity and retry. Append CONFIG_LOGLEVEL=7 to
@hannahKobain had built me images with and without ion from the start and they did the same thing
If youre using the milk v duo S then something could be different from the board i have.
Even flashing with memory card seems to not work good run to run. When i had the milk v sd img on there. It worked but as i said earlier in the thread. It practically wear out the sdcard causing it to be undetectable. When i flash the chip(s) manually with a custom programmer the data on chip is identical to the source fip.bin and boot.spinor…but only fip.bin works.
So only thing that can possible work rn is fip.bin also had the kernel embed in it.
i wanted to try executing “go” cmd but again i dont know much about image format uboot expects to load. If i did i might be able to “hack” something in. Like for example if the kernel main() is located at address 0x8000 then just force uboot to load that address if it doesnt find any “valid” image. The crc thing also concerns me but again the image on the flash is identical lmao.
Honestly i really want it to work as i planned to use this as the base cpu for a 2nd version of a custom Gaming console. esp32 p4 is $55 , stm32 @500Mhz is around $16. But dont have funds yet for these (life struggles). My console software is written in arduino so thats why i bought this milk v since it supported arduino. This turned out to be a semi rant but yeh lmao.
One last thing to try (before adding debugging and/or different Duo) is to check the power rails – especially on the NOR. I have found I need 100nF capacitance on the NOR power rails typically. What is your circuit? Is NOR powered from 3.3V from Duo or elsewhere? Could you probe the rails with an oscilloscope? Try adding 100nF and then also 10uF to the power rails.
How is the NOR connected to the Duo (PCB, etc.)? How much capacitance is added to the NOR and how close is it to the IC?
Your PCB revision is the same as mine. I do have custom PCBs to connect all sorts of SPI flash to this Duo. I’ve been using those in my demonstrations.
Its connected with female to female jumper wires. All same length. flash is mounted on a small pcb with headers. each same length. The pin holes on the milk v have been populated with the included headers
I had reliability issues when I started in this manner, hence ended up creating a PCB. Even a ‘home-made’ one made things rock solid for me. The SPI lines are quite fast so I recommend avoiding flying leads. In any case, use short cables and try and get the silicone ‘luxury’ ones.
Definitely try soldering a 100nF capacitor across the power pins on the flash IC. If you do not have 100nF, then use whatever you find. You could also try soldering short leads directly between Duo and breakout PCB. Anything to help with integrity and noise on power rails.
What pull-up resistors have you used and with what values?
I shortened the wires by half. And it seems to work…though the first few times it wasnt working. So idk what made it work. Hopefully it was the length of wire. Rn the current length is about 10 cm.
I also found out that Just the 4.7k resistor connected between GND and WP pin is enough to get it to boot to NOR Flash.
@hannahKobain how do you build the image for arduino support. Because it doesnt even show the serial port when fully booted
SF: Detected W25Q256JV-IQ with page size 256 Bytes, erase size 4 KiB, total 32 MiB
device 0 offset 0xa0000, size 0x400000
SF: 4194304 bytes @ 0xa0000 Read: OK
sf read speed 31.536 MB/s
## Loading kernel from FIT Image at 81400000 ...
Using 'config-cv1800b_milkv_duo_spinor' configuration
Trying 'kernel-1' kernel subimage
Description: cvitek kernel
Type: Kernel Image
Compression: lzma compressed
Data Start: 0x814000d8
Data Size: 3124897 Bytes = 3 MiB
Architecture: RISC-V
OS: Linux
Load Address: 0x80200000
Entry Point: 0x80200000
Hash algo: crc32
Hash value: b9a96e97
Verifying Hash Integrity ... crc32+ OK
Start Address : 2168455384
## Loading fdt from FIT Image at 81400000 ...
Using 'config-cv1800b_milkv_duo_spinor' configuration
Trying 'fdt-cv1800b_milkv_duo_spinor' fdt subimage
Description: cvitek device tree - cv1800b_milkv_duo_spinor
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x816fb098
Data Size: 19789 Bytes = 19.3 KiB
Architecture: RISC-V
Hash algo: sha256
Hash value: 23567893e78ba317dac653460c316f91dd1aa25bfe2339293b24dd12d7267f8e
Verifying Hash Integrity ... sha256+ OK
Booting using the fdt blob at 0x816fb098
Uncompressing Kernel Image
Decompressing 6936064 bytes used 1152ms
Loading Device Tree to 0000000081bc3000, end 0000000081bcad4c ... OK
That’s weird, I didn’t remove anything, nor did I reconfigure the UART.
$ git checkout arduino; && ./build.sh milkv-duo-spinor — this is what I do when I want to build me an image for Duo (64M) & SPI NOR flash.
But for myself, I edited its RAM division configs so that no RAM is being reserved for ION. Also, this allows us leave more RAM to the second core, or the 80c51 core.
If it was higher than 40 Mhz then you’d need to shorten it further. On my Esp32 it doesnt pose a problem until 60-80 MHz. I probably will shorten it but i want to get the Arduino part working then i will make " short traces" on a solderable pcb board i have.