Closed KarlK90 closed 10 months ago
Hi @KarlK90 , I also didn't know what is happening in gd32v bootrom(it is not a chip made by Nuclei, we just provided RISC-V CORE ip to Gigabyte), maybe you need to check the datasheet for more details.
@fanghuaqi Thanks for clarification! I share my findings with you or others that maybe have the same question.
Some further investigation in the disassembly of the bootloader revealed that it wasn't compiled to be position independent. E.g in the startup assembly the gp
and sp
pointers are calculated from the current pc
which produces invalid addresses if the bootloader is not aliased to 0x0. Unfortunately there is no way to change the memory aliasing at runtime (like on some STM32 with the SYSCFG register).
I tried to rewrite the startup code and vector table with the correct values and jump over the original startup assembly. but it just traps at runtime. Maybe I did an error but it seems ATM as if this is just not possible with the current bootloader code.
See below update.
; Init gp
0x0000018c auipc gp, 0x20001
0x00000190 addi gp, gp, -684
; Bootloader running from 0x1FFFB000 gives invalid address
; 0x1FFFB18C + 0x20001000 = 0x3FFFBEE0
;
; Bootloader running from 0x0 gives valid address
; 0x0000018C + 0x20001000 = 0x20000EE0
;
; Init sp
0x00000194 auipc sp, 0x20001
0x00000198 addi sp, sp, 1644
; Bootloader running from 0x1FFFB000 gives invalid address
; 0x1FFFB194 + 0x20001000 + 1644 = 0x3FFFC800
;
; Bootloader running from 0x0 gives valid address
; 0x00000194 + 0x20001000 + 1644 = 0x20001800
Actually I got the numbers for the data section wrong and the vector table was outside the SRAM region... After updating the numbers the bootloader doesn't trap anymore and tries to enumerate as a USB device now. But it fails the setup, the code is caught in a loop. This is very similar to the behavior often seen when putting the device into bootloader mode via BOOT0 pin.
[ 8837.860409] usb 1-1.3: new full-speed USB device number 9 using xhci_hcd
[ 8837.968448] usb 1-1.3: device descriptor read/64, error -32
[ 8838.156448] usb 1-1.3: device descriptor read/64, error -32
[ 8838.262241] usb 1-1-port3: attempt power cycle
Hi @KarlK90 , sorry I can't give you more help with this issue, I didn't know too much details in side the bootrom of gd32v.
@fanghuaqi no problem, as stated above jumping into the bootloader is not an easily accomplished. Therefore I have started to port the tinyuf2 userland bootloader for the GD32VF103. There are some problems with the USB peripheral, but when this is sorted this should solve my problems.
I'm wondering if it is possible to jump to the embedded bootloader that is present at
0x1FFFB000
in the devices ROM without a reset and externally pulling Boot0 high?So far I have tried to jump to
0x1FFFB000
immediately after the device has been reset in the startup code. Observing the execution path with a debugger I can confirm that this indeed produced a valid jump, but the bootloader code is not executed successfully e.g. with a USB connection it doesn't show up as a USB-DFU device.I know that this is possible with STM32F103 and GD32F103, so there is a chance that this possible as well?