On 8/3/20 2:20 PM, Heinrich Schuchardt wrote:
On 03.08.20 16:08, Sean Anderson wrote:
Maybe. Because we are configuring the PLL, the CPU clock is temporarily set to the in0 oscillator, so the timer would give an incorrect delay. However, it would probably be fine even if incorrect. The original reason I used nops is because that is what the SDK does in its PLL configuration function [1]. I believe I tried using udelay at one point, but I don't remember whether I had any issues with it.
--Sean
[1] https://github.com/kendryte/kendryte-standalone-sdk/blob/develop/lib/drivers...
This is what udelay(1) gets compiled to:
000000000000004a <.LBE106>: udelay(1); 4a: 4505 li a0,1
000000000000004c <.LVL21>: 4c: 00000097 auipc ra,0x0 50: 000080e7 jalr ra # 4c <.LVL21>
Somehow udelay() seems not to be fully implemented and the platform. So I think we should stay with the nop() macro.
Hm, I don't see this generated code. What function is that a disassembly of?
$ riscv64-linux-gnu-objdump -S --disassemble=__udelay u-boot
u-boot: file format elf64-littleriscv
Disassembly of section .text:
Disassembly of section .text_rest:
00000000800197f8 <__udelay>: do_div(tick, 1000000); return tick; }
void __weak __udelay(unsigned long usec) { 800197f8: 1101 addi sp,sp,-32 800197fa: ec06 sd ra,24(sp) 800197fc: e822 sd s0,16(sp) 800197fe: e426 sd s1,8(sp) 80019800: 84aa mv s1,a0 uint64_t tmp;
tmp = get_ticks() + usec_to_tick(usec); /* get current timestamp */ 80019802: f7bff0ef jal ra,8001977c <get_ticks> 80019806: 842a mv s0,a0 80019808: 8526 mv a0,s1 8001980a: fcbff0ef jal ra,800197d4 <usec_to_tick> 8001980e: 942a add s0,s0,a0
while (get_ticks() < tmp+1) /* loop till event */ 80019810: 0405 addi s0,s0,1 80019812: f6bff0ef jal ra,8001977c <get_ticks> 80019816: fe856ee3 bltu a0,s0,80019812 <__udelay+0x1a> /*NOP*/; } 8001981a: 60e2 ld ra,24(sp) 8001981c: 6442 ld s0,16(sp) 8001981e: 64a2 ld s1,8(sp) 80019820: 6105 addi sp,sp,32 80019822: 8082 ret
--Sean